软件工程——软件测试的策略详解

• 单元测试
• • 单元测试的内容
  • 单元测试的步骤
• 组装测试
• • 一次性组装方式
  • 增值式组装方式
• 增值组装有以下3种做法
• • 自顶向下的增值方式
  • 自底向上的增值方式
  • 混合增值式测试
  • 确认测试
  • 进行有效性测试（黑盒测试）
  • 软件配置复查
  • α测试和β测试
  • 验收测试
  • 确认测试的结果

通常软件测试过程按4个步骤进行，即 单元测
试、组装测试、确认测试和系统测试。
如下图所示。

1. 模块接口测试。在单元测试的开始，应对通过被测模块的数据流进行测试。
   对模块接口可能需要如下的测试项目：
   1.调用本模块时的输入参数与模块的形式参数的匹配情况；
   2.本模块调用子模块时，它输入给子模块的参数与子模块中的形式参数的匹配情况；
   3.是否修改了只作输入用的形式参数；
   4.全局量的定义在各模块中是否一致；
   5.限制是否通过形式参数来传送。

3. 路径测试。选择适当的测试用例，对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。对基本执行路径和循环进行测试可以发现大量的路径错误。

4. 错误处理测试。比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重作安排，保证其逻辑上的正确性。
   若出现下列情况之一，则表明模块的错误处理功能包含有错误或缺陷：
   1.出错的描述难以理解；
   2.出错的描述不足以对错误定义，不足以确定出错的原因；
   3.显示的错误与实际的错误不符；
   4.对错误条件的处理不正确；
   5.在对错误进行处理之前，错误条件已经引起系统的干预等。

5. 边界测试。在边界上出现错误是常见的, 要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性，对这些地方要仔细地选择测试用例，认真加以测试。

单元测试的步骤

• 通常单元测试是在编码阶段进行的。在源程序代码编制完成，经过评审和验证，肯定没有语法错误之后，就开始进行单元测试的测试用例设计。
• 模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其他模块。
• 这些辅助模块分为如下两种:

1. 驱动模块（driver）——相当于被测模块的主程序，它接收测试数据，并把这些数据传送给被测模块，最后再输出实测结果。

增值式组装方式

1. 增值式组装方式。这种组装方式又称渐增式组装，首先是对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增值逐步组装成为要求的软件系统。

增值组装有以下3种做法

自顶向下的增值方式

自顶向下的增值方式。这种组装方式是将模块按系统程序结构，沿控制层次自顶向下进行组装，其步骤如下：

1. 以主模块为被测模块兼驱动模块，所有直属于主模块 的下属模块全部用桩模块代替，对主模块进行测试。

2. 采用深度优先（如下图）或宽度优先的策略，逐步用实际模块替换已用过的桩模块，再用新的桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。
   

自底向上的增值方式

这种组装方式是从程序模块结构的最底层的模块开始组装和测试。
因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以由直接运行子模块得到。

自底向上增值的步骤如下：

1. 由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。
2. 用实际模块代替驱动模块，与它已测试的直属子模块组装成为子系统。
3. 为子系统配备驱动模块，进行新的测试。
4. 判断是否已组装到达主模块。若是则结束测试，否则执行步骤2。

自底向上进行组装和测试时，需要为被测模块或子系统编制相应的驱动模块。常见的几种类型的驱动模块如下图所示。

进行有效性测试（黑盒测试）

• 有效性测试是在模拟的环境（可能就是开发的环境）下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。
• 需要首先制订测试计划，规定要进行测试的种类。还需要制订一组测试步骤，描述具体的测试用例。通过实施预定的测试计划和测试步骤，确定软件的特性是否与需求相符，确保所有的软件功能需求都能得到满足，所有的软件性能需求都能达到，所有的文档都正确且便于使用。同时，对其他软件需求，如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试，确认是否满足。

软件配置复查

• 软件配置复查的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必须的细节，而且已经编排好分类的目录。
• 除了按合同规定的内容和要求，由人工审查软件配置之外，在确认测试的过程中，应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。必须仔细记录发现的遗漏和错误，并且适当地补充和改正。

α测试和β测试

• α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用，开发者坐在用户旁边，随时记下错误情况和使用中的问题。
• α测试的目的是评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持），尤其注重产品的界面和特色。
• β测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签定了支持产品预发行合同的外部客户。
• 与α测试不同的是，开发者通常不在β测试现场，由用户记下遇到的所有问题。开发者在综合用户的 告之后进行修改，最后将软件产品交付给全体用户使用。
• 只有当α测试达到一定的可靠程度时，才能开始β测试。
• 由于β测试的主要目标是测试可支持性，所以β测试应尽可能由主持产品发行的人员管理。

验收测试

• 在通过了系统的有效性测试及软件配置审查之后，应开始系统的验收测试（acceptance
  testing）。验收测试是以用户为主的测试，软件开发人员和QA（质量保证）人员也应参加。由用户参加设计测试用例，使用用户界面输入测试数据，并分析测试的输出结果。
• 一般使用生产中的实际数据进行测试，在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。

确认测试的结果

在全部确认测试的测试用例运行完后，所有的测试结果可以分为两类。

1. 测试结果与预期的结果相符，这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序可以接受。
2. 测试结果与预期的结果不符，这说明软件的这部分功能或性能特征与需求规格说明不一致，因此，需要开列一张软件各项缺陷表或软件问题 告，通过与用户的协商，解决所发现的缺陷和错误。