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

Posted 2021-07-17 安之ccy

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

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

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

单元测试

• 单元测试（unit testing）又称模块测试，是针对软件设计的最小单位—程序模块，进行正确性检验的测试工作。
• 单元测试目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

单元测试的内容

• 单元测试主要采用白盒测试方法设计测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。
• 在单元测试中进行的测试工作如下图所示，需要在5个方面对被测模块进行检查。

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

2. 局部数据结构测试。
   模块的局部数据结构是最常见的错误来源，应设计测试用例以检查以下各种错误：
   1.不正确或不一致的数据类型说明；
   2.使用尚未赋值或尚未初始化的变量；
   3.错误的初始值或错误的默认值；
   4.变量名拼写错；
   5.不一致的数据类型。
   6.可能的话，除局部数据之外的全局数据对模块的影响也需要查清。

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

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

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

单元测试的步骤

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

1. 驱动模块（driver）——相当于被测模块的主程序，它接收测试数据，并把这些数据传送给被测模块，最后再输出实测结果。
2. 桩模块（stub）——也叫做存根模块，用以代替被测
   模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。被测模块、与它相关的驱动模块及桩模块共同构成一个“测试环境”，如下图所示。
   

组装测试

组装测试（integrated testing）也叫做集成测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统，
把模块组装为系统的方式有两种：一次性组装方式（big bang）和增值式组装方式。

一次性组装方式

1. 一次性组装方式。它是一种非增值式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。
2. 例如，有一个模块系统结构，如下图（a）所示，其单元测试和组装顺序（b）所示。
   
   图中，模块d1，d2，d3，d4，d5是对各个模块作单
   元测试时建立的驱动模块，s1，s2，s3，s4，s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下，在分别完成模块单元测试的基础上，将被测模块连接起来进行测试。但是，由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性不很大。

增值式组装方式

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

增值组装有以下3种做法

自顶向下的增值方式

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

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

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

3. 进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引入新的错误的可能。

4. 判断是否所有的模块都已组装到系统中，若是则结束测试，否则转到步骤2去执行。

5. 自顶向下的组装和测试存在一个逻辑次序问题。在为了充分测试较高层的处理而需要较低层处理的信息时，就会出现这类问题。在自顶向下组装阶段，还需要用桩模块代替较低层的模块，

6. 根据不同情况，桩模块的编写，可能如下所示的几种选择。
   
   为了能够准确地实施测试，应当让桩模块正确而有效地
   模拟子模块的功能和合理的接口，不能是只包含返回语句或只显示该模块已调用信息，不执行任何功能的哑模块。

自底向上的增值方式

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

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

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

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

混合增值式测试

自顶向下增值的方式和自底向上增值的方式各有优缺点。自顶向下增值方式的缺点是需要建立桩模块。

自底向上增值方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。

通常是把以上两种方式结合起来进行组装和测试。

确认测试

确认测试（validation testing）又称有效性测试。它的任务是验证软件的有效性，即验证软件的功能和性能及其他特性是否与用户的要求一致。在确认测试阶段需要做的工作如下图所示。
从上图中可看出，首先要进行有效性测试以及软件配置复审，然后进行验收测试和安装测试，在通过了鉴定之后，才能成为可交付的软件。

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

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

软件配置复查

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

α测试和β测试

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

验收测试

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

确认测试的结果

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

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

版权声明：本文为CSDN博主「过往将来」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_43408367/article/details/114087451