【现代软件工程】第八章

软件测试

基本概念

狭义：为了发现软件错误而执行软件的过程。
广义：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
测试是为了证明程序中有错误，而不是证明程序中无错误
一个好的测试用例指的是它可能发现至今尚未发现的缺陷
一次成功的测试指的是发现了新的软件缺陷的测试

软件测试原则

足够好原则：制定最低测试通过标准和测试内容
Pareto法则（ 80/20定律）：测试中发现的80%的错误可能来自于20%的程序代码，充分注意测试中的群集现象。经验表明，测试后程序残存的错误数目与该程序中已发现的错误数目成正比。
应该“尽早和不断地进行软件测试”，测试计划在需求分析阶段,测试用例设计在设计阶段
穷举测试是不可能的
应当避免由程序员检查自己的程序。（指后期系统测试阶段，不包括单元测试）
在设计测试用例时，应包括合理的输入条件和不合理的输入条件
严格执行测试计划，排除测试的随意性
应当对每一个测试结果做全面检查
妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便
检查程序是否做了应做的事仅是成功的一半，另一半是检查程序是否做了不该做的事

测试用例

测试用例（ Test Case ）是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

用例设计

设计尽可能少的测试用例来发现尽可能多的错误
设计最有可能发现软件错误的测试用例，同时避免使用发现错误效果相同的测试用例
测试用例的设计方法大体可分为两类：白盒测试和黑盒测试，也称白箱测试和黑箱测试

白盒测试

白盒测试（又称为结构测试）把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作,白盒测试主要用于对模块的测试.

黑盒测试

黑盒测试（又称行为测试）把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能需求,黑盒测试可用于各种测试.

软件测试的分类

按测试方式分类

静态测试（不需要执行所测试的程序，查询代码是否符合规范，对程序的数据流和控制流进行分析）
动态测试（选择实际测试用例运行测试程序，模拟用户输入）

按测试过程分类

单元测试:是针对程序中的模块或构件，主要揭露编码阶段产生的错误
集成测试:针对集成的软件系统，主要揭露设计阶段产生的错误
确认测试:是根据软件需求规约对集成的软件进行确认，主要揭露不符合需求规约的错误
系统测试:对于基于计算机系统中的软件，还需将它集成到基于计算机系统中，并进行系统测试，以揭露不符合系统工程中对软件要求的错误

按测试目的分类

功能测试，健壮性测试，接口测试，性能测试，强度测试，压力测试，用户界面测试，安全测试，可靠性测试，安装/反安装测试，文档测试，恢复测试，兼容性测试

测试策略

软件测试的组织

应由什么人来组织测试：
测试贯穿于整个软件的开发过程中，开发人员必须参与测试
对即将交付软件的集成测试，开发人员往往也要参加
集成测试中，有独立测试组（ITG）的介入
ITG应从一开始就要介入项目，只是不像开发人员过多地注意细节

测试完成的标准

测试只能是在某个阶段告一段落。
由于软件使用的软环境可能要永恒地变化。所以，它时刻、永远地面临考验，没有尽头。
测试是永远也完不成的。

测试策略

开始于 ‘小范围测试’ ，并移向 ‘大范围测试’
对于传统的软件：开始集中在模块 (构件) ，之后进行模块集成
对于面向对象的软件：当进行 ‘小范围测试’时，关注点从单个模块（传统上的）转变到面向对象的类，类封装了属性和操作，并意味着通信和协作。

单元测试

指对软件中的最小可测试单元进行检查和验证。
主要对模块的五个基本特性进行评价：

由于模块并不是独立的程序，所以必须为每个测试单元开发驱动程序和桩程序
驱动程序：是“主程序”，接收测试用例数据，将这些数据传递给待测试模块
桩程序：替换那些被测模块所调用的模块

测试时机：

通常在编码完成后进行，在前期应准备，如写单元测试计划,编测试用例、单元测试代码等。开发人员完成。

单元测试的依据

源程序，项目的《详细设计》文档。
进行单元测试：一般先静态地检查代码是否符合规范，然后动态地运行代码并检查运行结果。

单元测试代码应该与单元代码保持一致，每当单元代码发生变化，需确认单元测试代码是否需要更新；单元测试代码通常不完全等同于所模拟的真实模块，一般只模拟一个或一些运行情况，返回一个执行所需要的值。

集成测试

构造软件体系结构的系统化技术，同时也进行一些旨在发现与接口相关错误的测试
一步到位的集成：需要桩程序和驱动程序去分别测试每一模块，难于排查错误

增量集成：程序以小增量方式进行构造和测试

自顶向下测试：从主控模块开始，沿着控制层次结构逐步向下，利用深度优先或广度优先的方式将从属于主控模块的模块集成到结构中去，可能要编写很多桩程序，主控模块错误可能发现得比较早

自底向上测试：从原子模块开始进行构造和测试，要写驱动程序，主控模块错误发现得比较迟

组合方法（三明治）：用自顶向下方法测试程序结构较高层，用自底向上方法测试其从属层

回归测试：

回归测试是重新运行已经进行过的测试子集，以确保变更没有引发非预期的副作用。
每次对软件进行修改时，就改变了软件配置的某些方面（软件、文档及支持软件的数据）。
回归测试有助于确保变更（由于测试或者其他原因）不会引入非预期的行为或者增加的错误。
回归测试可以手动进行，通过重新运行一部分测试用例或者全部测试用例，也可以使用自动的捕获/回放工具。

冒烟测试：

是对产品软件进行“每日构造”的一种常见方法。
已经被翻译为代码的软件构件被集成到构造（ “build” ）中（一个构造包括所有的数据文件、库、可重用的模块、以及工程化的构件，其中一个构件需要实现一项或多项产品功能。）
设计一系列测试来揭示错误，使得此构造不能正确地执行其功能（目的是揭示“显示阻塞” 错误，这种错误最有可能使软件项目滞后于进度计划。）
将此构造与其他构造集成在一起，每天都对整个产品（以其当前的形式）进行冒烟测试。(集成方法可以是自顶向下，也可以是自底向上。)

面向对象软件的测试

类测试：
不再孤立地测试单个操作，而是将其作为类的一部分，相当于传统软件的单元测试
要考虑类的层次，测试顺序由父类到子类

集成测试：
基于线程的测试
基于使用的测试：

确认测试

侧重于需求级的错误，即对最终用户是显而易见的错误
软件规格说明中包含的信息是确认测试的基础
配置评审：确保所有软件配置元素已正确开发、编目，且具有软件生命周期各阶段的必要细节
α测试：最终用户在开发场所完成，软件在自然的环境下使用，开发者在旁边观看，并记录错误和使用问题
β测试：在最终用户场所执行，开发者通常不在场

系统测试

系统测试是将已经开发好的软件系统，作为计算机系统的一个元素，与计算机硬件、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的集成测试和确认测试。

恢复测试：通过各种方式强制地让系统发生故障，并验证其能适当恢复
安全测试：验证系统内的保护机制能够保护系统不受非法入侵，使攻破系统所付出的代价大于攻破系统之后获取信息的价值
压力测试：能将系统折腾到什么程度而不会出错？以一种反常数量、频率或容量的方式执行系统
性能测试：测试软件的运行性能，常和压力测试一起进行，常需要硬件和软件配合

测试方法

白盒测试

白盒测试是有选择地执行（或覆盖）程序中某些最有代表性路径的测试方法，所以也称为逻辑覆盖测试
逻辑覆盖法，基本路径测试法，循环测试方法

逻辑覆盖法

语句覆盖：选择足够的测试用例，使得程序中每个语句至少都能执行一次
判定覆盖：执行足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值，即使得程序中的每一个分支至少都通过一次
条件覆盖：执行足够的测试用例，使得判定中每个条件获得各种可能的结果
判定／条件覆盖：执行足够的测试用例，同时满足判定覆盖和条件覆盖的要求
条件组合覆盖：执行足够的测试用例，使得每个判定中条件的各种可能组合都至少执行一次
白箱测试技术的最强覆盖准则就是条件组合覆盖

基本路径测试法

基本路径测试法是根据程序的控制流路径设计测试用例的一种最基本的白盒测试技术，设计的测试用例保证程序中的每条语句至少执行一次。
考察测试路径的有用工具：程序控制流图

任何过程设计描述方法（如PDL、流程图、N-S图、PAD图等）都可以映射到一个相应的程序控制流图描述，其映射要点为：
一个或多个顺序语句可映射为程序图的一个节点，用带标识的圆表示。
一个处理框序列和一个判别框可映射为程序图的一个节点。
程序控制流向可映射为程序控制流图的边（或称为连接），用方向箭头表示（类似于流程图中的方向箭头）。一条边必须终止于一个节点，即使该节点不代表任何语句。
有边和节点限定的范围称为区域（区域应包括图外部的范围）

确定程序图的环形复杂性

环形复杂性是一种以图论为基础的，为程序逻辑复杂性提供定量测度的软件度量
独立路径是指程序中至少引进一个新的处理语句集合，或一个新条件的任何一条路径
路径中至少存在1条边在前面路径中没出现过

程序图G的环形复杂性V(G)计算三种方法：
1.V(G)等于程序图G的区域数
2.V(G)= E﹣N + 2，E是程序图G的边数，N是程序图G的节点数。
3.V(G)= P + 1，P是程序图G中判定的节点数
环形复杂度定义独立路径数，保证所有语句至少执行一次所需测试数量的上限。

循环测试

简单循环，嵌套循环，串接循环，无结构循环

简单循环

零次循环：从循环入口直接跳到循环出口。
一次循环：查找循环初始值方面的错误。
二次循环：检查在多次循环时才能暴露的错误。
m次循环：此时的m＜n，也是检查在多次循环时才能暴露的错误。
n(最大)次数循环、n+1(比最大次数多一)次的循环、n-1(比最大次数少一)次的循环。

嵌套循环

从最内层循环开始，设置所有其他层的循环为最小值；
对最内层循环做简单循环的全部测试。测试时保持所有外层循环的循环变量为最小值。另外，对越界值和非法值做类似的测试。
逐步外推，对其外面一层循环进行测试。测试时保持所有外层循环的循环变量取最小值，所有其它嵌套内层循环的循环变量取“典型”值。
反复进行，直到所有各层循环测试完毕。
对全部各层循环同时取最小循环次数，或者同时取最大循环次数。

串接循环

如果各个循环互相独立，则串接循环可以用与简单循环相同的方法进行测试。
如果有两个循环处于串接状态，而前一个循环的循环变量的值是后一个循环的初值。则这几个循环不是互相独立的，则需要使用测试嵌套循环的办法来处理

黑盒测试

黑盒测试是根据程序组件的规格说明测试软件功能的方法，所以也称为功能测试
被测对象作为一个黑盒子，它的功能行为只能通过研究其输入和输出来确定，所以又称为软件输入/输出接口测试
黑盒测试注重于功能和数据信息域的测试

等价类划分

由于不能穷举所有可能的输入数据来进行测试，所以只能选择少量有代表性的输入数据，来揭露尽可能多的程序错误
等价类划分的办法是把程序的输入域划或者输出域分成若干等价类，然后从每个部分中选取少数代表性数据当作测试用例
等价类是指输入域的某个子集，该子集中的每个输入数据对揭露软件中的错误都是等效的，测试等价类的某个代表值就等价于对这一类其他值的测试。
根据输出数据等价类导出输入数据等价类

确定等价类的原则

如果输入条件规定了取值范围或值的个数，则可确定一个有效等价类和两个无效等价类。
输入条件规定了输入值的集合，或是规定了“必须如何”的条件，则可确定一个有效等价类和一个无效等价类。
已划分的等价类中各元素在程序中的处理方式是不同的，则应将此等价类进一步划分成更小的等价类。

根据等价类设计测试用例的步骤

为每一个等价类规定一个唯一的编号。
设计一个新的测试用例，使其能够尽量覆盖尚未覆盖的有效等价类。重复这个步骤，直到所有有效等价类均被测试用例所覆盖。
设计一个新的测试用例，使其仅覆盖一个尚未覆盖的无效等价类。重复这个步骤，直到所有无效等价类均被测试用例所覆盖。

边值分析法

大量的错误是发生在输入或输出范围的边界上，边界值揭露程序中错误的可能性就更大，边值分析法是对等价类划分方法的补充，这种情况下，测试用例来自等价类的边界。
应当选取正好等于，刚刚大于，刚刚小于边界的值做为测试

错误推测法

因果图法（条件组合，判定表）