目录
2.5 单元测试
2.5.1 什么是测试单元
◆ 一个函数
◆ 类或类的成员函数
◆ 几个函数的集合
2.5.2 什么是单元测试
◆ 对软件基本组成单元进行测试，主要是为了发现单元内部可能存在的各种错误和不足。
◆ 主要工作分为两个步骤：人工静态检查和动态执行跟踪。
◆ 般由开发组在开发组长监督下进行。
2.5.3 单元测试的主要任务
◆ 在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试方法，辅之以黑盒测试方法设计测试用例，使之对任何合理的和不合理的输入，都能鉴别和响应。
◆ 模块接口测试
◆ 局部数据结构
◆ 测试路径测试
◆ 错误处理测试
◆ 边界测试
2.5.4 单元测试环境
驱动模块相当于程序中的主函数
2.5.5 单元测试用例设计思路
◆ 为系统运行设计测试用例
◆ 为正向测试设计用例
◆ 为逆向测试设计用例
◆ 为满足特殊需求设计测试用例
◆ 为代码覆盖设计用例
2.5.6 单元测试的优势
◆ 单元测试体现了尽早测试原则
◆ 单元测试有助于提高代码质量
◆ 单元测试也可以理解为一种编写文档的行为
2.5.7 单元测试的误区
2.6 集成测试
2.6.1 集成测试的定义
集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统所进行的测试。
2.6.2 集成测试关注的重点
◆ 模块接口的数据交换
◆ 各子功能组合起来能否达到预期的父功能要求
◆ 模块间是否有不利影响
◆ 全局数据结构
◆ 单个模块的误差是否会累积放大
2.6.3 单元测试与集成测试的区别
2.6.4 四种集成方法
一、大爆炸集成
目的
尽可能缩短测试时间，使用最少的测试用例验证系统。
定义
大爆炸集成也称为一次性组装或整体拼装，这种集成测试策略的做法就是把所有通过单元测试的模块—次性集成到一起进行测试，不考虑组件之间的互相依赖性及可能存在的风险。
优点
1）可以并行测试所有模块。
2）需要的测试用例数目少。
3）测试方法简单、易行。
缺点
1）由于不可避免存在模块间接口、全局数据结构等方面的问题，—次运行成功的可能性不大。
2）如果一次集成的模块数量多，集成测试后可能会出现大量的错误。另外，修改了一处错误之后，很可能引入更多的新错误，新旧错误混杂，给程序的错误定位与修改带来很大的麻烦。
3）即使集成测试通过，也会遗漏很多错误。
适用范围
1）只需要修改或增加少数几个模块的前期产品稳定的项目；
2）功能少、模块数量不多、程序逻辑简单，并且每个组件都已经过充分单元测试的小型项目；
3）基于严格的净室软件工程（由IBM公司开创的开发接近零缺陷的软件的成功做法)开发的产品，并且在每个开发阶段，产品质量和单元测试质量都相当高的产品。
二、自顶向下集成测试
具体步骤
1）对主控模块进行测试（测试时用桩模块代替直接附属于主控模块
的模块）；
2）根据选定的结合策略（深度优先或者广度优先)，每次用一个实
际模块代替一个桩模块（需要注意的是，新结合进来的模块通常也需要桩模块）；
3）在结合下一个模块的同时进行测试；
4）为了保证加入的模块没有引起新的错误，可能需要回归测试（即
全部或部分重复做前面做的测试）；
5）重复上述的第2～4步，直至所有模块都集成完毕。
自顶向下的按宽度优先的测试策略。前期完成的模块将是后期完成的模块的驱动模块。
特点
◆ 自顶向下集成能较早地发现错误。
◆ 测试较高层模块时，底层处理采用桩模块代替。
◆ 自顶向下集成不需要驱动模块。
◆ 自顶向下集成一旦发现问题，会导致过多的回归测试。
三、自底向上集成测试
定义
自底向上集成是从系统层次结构图的最底层模块开始按照层次结构图，逐层向上进行组装和集成测试的方式。
步骤
◆ 从最底层的模块开始组装；
◆ 编制驱动程序，协调测试用例的输入与输出；
◆ 测试集成后的构件；
◆ 使用实际模块代替驱动程序，按程序结构向上组装测试后的构件；
◆ 重复上面的第2～4步，直到系统的最顶层模块被加入到系统中为止。
最后一个模块添加上去，才能算一个完整的实体，之前一直都不是，可以把最容易出问题的部分在早期进行测试，可以实施多个模块的并行测试，提高测试效率。前期完成的模块将是后期完成的模块的方模块。
四、三明治集成（混合集成）
是一种混合增值式测试策略，综合了自顶向下和自底向上两种集成方法，把系统划分成三层，中间一层为目标层，目标层上采用自顶向下集成，目标层下采用自底向上集成。
五、持续集成测试
◆ 实际测试中，各种集成方法有机结合。
◆ 采用并行自顶向下，自底向上混合集成。
◆ 由于模块开发先后次序，尽早将已完成模块集成。
◆ 充分利用各种集成方式有效节省桩模块和驱动模块的开发费用。
2.7 系统测试
2.7.1 强度测试（压力测试）
是要检查在系统运行环境不正常乃至发生故障的情况下，系统可以运行到何种程度的测试。例如∶
◆ 把输入数据速率提高一个数量级，确定输入功能将如何响应。
◆ 设计需要占用最大存储量或其它资源的测试用例进行测试。
2.7.2 性能测试
是要检查系统是否满足在需求说明书中规定的性能。特别是对于实时系统或嵌入式系统。
◆ 性能测试常常需要与强度测试结合起来进行，并常常要求同时进行硬件和软件检测。
◆ 通常，对软件性能的检测表现在以下几个方面：响应时间、吞吐量、辅助存储区，例如缓冲区，工作区的大小、处理精度等。
2.7.3 恢复测试
恢复测试是要证实在克服硬件故障（包括掉电、硬件或网络出错等）后，系统能否正常地继续进行工作，并不对系统造成任何损害。
◆ 错误探测功能—─系统能否发现硬件失效与故障；
◆ 能否切换或启动备用的硬件；
◆ 在故障发生时能否保护正在运行的作业和系统状态；
◆ 在系统恢复后能否从最后记录下来的无错误状态开始继续执行作业等。
2.7.4 安全测试
安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞，以检查系统对非法侵入的防范能力。
◆ 测试人员扮演非法入侵者。
◆ 系统安全设计的准则：使非法侵入的代价超过被保护信息的价值。
2.7.5 可靠性测试
是为了检验系统的可靠性是否达到预期目标而进行的测试。
◆ 平均失效间隔时间 MTBF(Mean Time Between Failures) 是否超过规定时限?
◆ 因故障而停机的时间 MTTR(Mean Time To Repairs) 在一年中应不超过多少时间。
2.7.6 安装测试
安装测试的目的不是找软件错误，而是找安装错误。在安装软件系统时，会有多种选择：
◆ 要分配和装入文件与程序库
◆ 布置适用的硬件配置
◆ 进行程序的联结
安装测试就是要找出在这些安装过程中出现的错误，验证成功安装系统的能力。
2.7.7 容量测试
是根据预先分析出的某项指标极限值，测试系统在其极限值状态下是否能保持正常运行，即在使系统的全部资源达到“满负荷”的情形下，测试系统的承受能力。例如，
◆ 对于编译程序，让它处理特别长的源程序；
◆ 对于操作系统，让它的作业队列 “满员”；
◆ 对于信息检索系统，让它使用频率达到最大。
◆ 容量测试完成标准：所计划的测试已全部执行，而且达到或超出指定的系统限制而没有出现任何软件故障。
2.7.8 文档测试
检查用户文档的清晰性和精确性。文档测试目的：
◆ 检查文档所描述的是否在产品中提供;·检查产品中有的是否在文档中做了正确解释；
◆ 检查文档中的诸如拼写和语法错误等语言使用问题。
2.8 验收测试
2.8.1 验收测试
是以用户为主的测试，软件开发人员和QA（质量保证)人员也应参加。
◆ 由用户参加设计测试用例，使用用户界面输入测试数据，并分析测试的输出结果。
◆ 一般使用生产中的实际数据进行测试。
◆ 在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。
2.8.2 验收测试任务
◆ 制定验收测试计划；
◆ 指定验收标准和验收日程表；
◆ 规划安排验收测试活动如何执行；
◆ 进行验收测试；
◆ 依据验收测试的结果进行决策。
2.9 面向对象的软件测试
以对象为中心，以消息为驱动面向对象的软件测试
◆ 面向对象的单元测试：类测试
◆ 面向对象的集成测试：类簇测试
◆ 面向对象的系统测试
2.9.1 面向对象软件的单元测试
◆ 最小的可测试单位是封装的类或对象，而不再是个体的模块。
◆ 面向对象的单元测试通常也称为类测试。
◆ 主要考察封装在一个类中的方法和类的状态行为。
2.9.2 面向对象的集成测试：类簇测试
类簇是指一组相互有影响，联系比较紧密的类。它是一个相对独立的实体，在整体上是可执行和可测试的，并且实现了一个内聚的责任集合，但不提供被测试程序的全部功能，相当于一个子系统。
类簇测试主要根据系统中相关类的层次关系，检查类之间的相互作用的正确性，即检查各相关类之间消息连接的合法性、子类的继承性与父类的一致性、动态绑定执行的正确性、类簇协同完成系统功能的正确性等等。
2.9.3 面向对象软件的集成策略
1）基于类间协作关系的横向测试
2）基于类间继承关系的纵向测试
系统测试一般不考虑内部结构和中间结果，因此与传统的系统测试差别不大，可沿用传统的系统测试方法。