软件工程复习 第十一章
第十一章 软件测试
软件测试是发现软件中错误和缺陷的主要手段。为了保证软件产品的质量，软件开发人员通过软件测试发现产品中存在的问题，并及时修改
软件缺陷是指软件产品中存在的问题，具体表现为用户所需的功能没有实现，无法满足用户的需求。
在软件开发过程的任何阶段都可能引入缺陷。缺陷被引入的阶段越早，在软件开发后期修复这些缺陷造成的成本损失就越大。
软件测试工作应该贯穿于整个开发过程。
原则
完全测试是不可能的
测试中存在风险
软件测试只能表明缺陷存在，而不能证明软件产品已经没有缺陷
软件产品中潜在的错误数与已发现的错误数成正比
让不同的测试人员参与到测试工作中
让开发小组和测试小组分立，开发工作和测试工作不能由同一部分人来完成
尽早并不断地进行测试，使测试工作贯穿于整个软件开发的过程中
在设计测试用例时，应包括输入数据和预期的输出结果两个部分，并且输入数据不仅包括合法的情况，还应该包括非法的输入情况
要集中测试容易出错或错误较多的模块
应该长期保留所有的测试用例
软件测试模型
要素
测试的时间
测试的步骤
如何计划测试
不同阶段的测试中应该关注哪些测试对象
测试过程中应该考虑哪些问题
测试需要达到的目标等。
模型
V
W
H
按照质量因素划分的软件测试
功能测试。，检验最终的软件产品是否实现了需求规格说明书中的所有功能需求
可靠性测试。关注于程序输出结果的准确性
可用性测试。用来衡量处理服务请求时，应用程序的可用频率
性能测试
安全性测试
配置测试。考察软件系统是否能在多种硬件平台上正常运行
兼容性测试.主要关注软件的运行平台和应用系统的版本、标准和规范、数据的共享性
安装测试
文档测试
软件国际化测试和本地化测试
α测试和β测试。它们都属于验收测试的范畴，是在系统测试之后，产品发布之前进行的测试过程的最后一个阶段。
测试用例
为达到最佳的测试效果或高效地揭露隐藏的错误而精心设计并执行的少量测试数据，称为测试用例。
我们不可能进行穷举测试，为了节省时间和资源，提高测试效率，必须从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。
测试用例=测试数据+预期测试结果( +测试环境)
测试结果=测试数据+期望结果+实际结果
一个好的测试用例是在于它能发现至今未发现的错误。
软件测试方法
静态审查
自查
会审
走查
动态审查
黑盒测试
定义
- 在黑盒测试中，测试人员把被测试的软件系统看成是一个黑盒子，不需要关心盒子的内部结构和内部特性，只关注软件产品的输入数据和输出结果，从而检查软件产品是否符合它的功能说明。
等价类划分法
把被测对象的输入域划分为有限个等价区段——“等价类”，以有针对性的等价类少量测试，代替漫无边际的、数量较大的“穷尽”测试或随机测试。
分类
有效等价类是指对程序的规格说明是有意义的、由合理的输入数据构成的集合
无效等价类是指对程序的规格说明是无意义的、由不合理的输入数据构成的集合
原则
如果输入条件规定了取值范围或个数，则可确定一个有效等价类和两个无效等价类
如果输入条件规定了输入值的集合或是规定了“必须如何”的条件，则可确定一个有效等价类和一个无效等价类
如果输入条件是布尔表达式，则可以分为一个有效等价类和一个无效等价类
如果输入条件是一组值，且程序对不同的值有不同的处理方式，则每个允许的输入值对应一个有效等价类，所有不允许的输入值的集合为一个无效等价类
如果规定了输入数据必须遵循的规则，则可以划分出一个有效的等价类（符合规则）和若干无效的等价类（从不同的角度违反规则）
如已划分的等价类各元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类
边界值分析法
定义
经验表明，处理边界情况时程序最容易发生错误
边界类型:下标、数据结构、循环、选择等的边界附近
通常选用等价类边界值作为边界值测试的数据
一般边界值分析法作为等价类划分法的补充与细化。
原则
以输入条件的边界的值作为测试用例
若规定了值的数量的边界作为测试用例
针对每个输出条件
输入或输出范围是有序的集合，应注意选取有序集的第一个和最后一个元素作为测试用例
分析规格说明，找出其他的可能边界条件
错误推测法
- 错误推测法在很大程度上靠直觉和经验进行。它的基本想法是列举出程序中可能有的错误和容易发生错误的特殊情况，并且根据它们选择测试方案。
因果图法
定义
等价类划分法和边界值分析法都主要考虑输入条件，而没有考虑输入条件的各种组合以及各个输入条件之间的相互制约关系。因此，必须考虑描述多种条件的组合，相应地产生多个动作的形式来考虑设计测试用例。这就需要利用因果图法。
因果图法是一种黑盒测试方法，它从用自然语言书写的程序规格说明书中寻找因果关系，即利用输入条件与输出和程序状态的改变，由因果图产生判定表。它能够帮助人们按照一定的步骤高效地选择测试用例，还能指出程序规格说明书中存在的问题。
使用
用C表示原因，E表示结果
各节点表示状态
取值0表示某状态不出现，取值1表示某状态出现
四种关系符号
表示约束的符号
E约束（互斥）：表示a和b两个原因不会同时成立，最多有一个可以成立
I约束（包含）：表示a和b两个原因至少有一个必须成立
O约束（唯一）：表示a和b两个条件必须有且仅有一个成立
R约束（要求）：表示a出现时，b也必须出现。
M约束（强制）表示a是1时，b必须为0。
步骤
分析程序规格说明书的描述中，哪些是原因，哪些是结果
分析程序规格说明书中描述的语义内容，并将其表示成连接各个原因与各个结果的因果图
有些原因和结果的组合情况是不可能出现的，为表明这些特定的情况，在因果图上使用若干特殊的符号标明约束条件
把因果图转化为决策表
为决策表中每一列表示的情况设计测试用例
决策表法
定义
在一些数据处理问题中，某些操作是否实施依赖于多个逻辑条件的取值。在由这些逻辑条件取值的组合构成的多种情况下，分别执行不同的操作。处理这类问题的一个非常有力的工具就是决策表
决策表（也称判定表）是分析和表达多逻辑条件下执行不同操作的情况的工具，可以比较明确地表达复杂的逻辑关系和多种条件组合的情况
组成
条件桩：列出问题的所有条件
条件项：列出所列条件下的取值，以及在所有可能情况下的真假值
动作桩：列出问题规定可能采取的动作
动作项：列出在条件项的各种取值情况下应采取的动作
在简化并得到最终决策表后，只要选择适当的输入，满足决策表每一列的输入条件，即可生成测试用例。
场景法
定义
- 现在很多软件都是用事件触发来控制流程，事件触发时的情形变形成场景，而同一事件不同的触发顺序和处理结果就形成了事件流。这种在软件设计中的思想也可以应用到软件测试中，可生动地描绘出事件触发时的情形，有利于测试者执行测试用例，也更容易理解和执行测试用例。
组成
基本流：采用黑直线表示，是经过用例的最简单路径，表示无任何差错，程序从开始执行到结束
采用不同颜色表示，一个备选流可以从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不再加入基本流中。
步骤
根据规格说明，描述出程序的基本流和各个备选流
根据基本流和各个备选流生成不同的场景
对每一个场景生成相应的测试用例
复审生成的所有测试用例，去掉多余的测试用例，确定每一个测试用例的测试数据。
选择
在任何情况下都必须选择边界值分析方法。经验表明用这种方法设计出的测试用例发现程序错误的能力最强
必要时用等价类划分法补充-些测试用例
用错误推测法再追加一些测试用例
如果程序的功能说明中含有输入条件的组合情况,则可选用因果图法和决策表法
白盒测试
白盒测试有时也被称为玻璃盒测试，它关注软件产品的内部细节和逻辑结构，即把被测的程序看成是一个透明的盒子。
白盒测试利用构建层设计的一部分而描述控制结果来生成测试用例。白盒测试需要清楚了解系统内部结构和工作原理。
逻辑覆盖法
逻辑覆盖法以程序内在的逻辑结构为基础，根据程序的流程图设计测试用例
测试步骤
选择逻辑覆盖标准
按照覆盖标准列出所有情况
选择确定测试用例
验证分析运行结果与预期结果
语句覆盖：指选择足够的测试用例，使被测语句的每个语句至少执行一次
判定覆盖：指选择足够的测试用例，使每个判定的所有可能结果至少出现一次。
条件覆盖：指选择足够的测试用例，使判定中的每个条件的所有可能结果至少出现一次
判定/条件覆盖：指选择足够的测试用例，使判定中的每个条件的所有可能结果至少出现一次，并且每个判定中条件结果的所有可能组合也至少出现一次。
条件组合覆盖：指选择足够的测试用例，使每个判定中条件结果的所有可能组合至少出现一次。
路径覆盖：指选择足够的测试用例，使流程图中的每条路径至少经过一次。
基本路径法
基本路径法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行的路径集合，从而设计测试用例的方法。使用基本路径法设计出的测试用例要保证在测试中程序的每条可执行语句至少执行一次。
步骤
画出控制流图
计算环路复杂度
导出测试数据
准备测试用例
圈复杂度的计算
给定流图G的圈复杂度=流图中边的数量,-流图中结点的数量
给定流图G的圈复杂度=流图G中判定结点的数量+1
白盒方法的选择
白盒测试还有静态质量度量、域测试、Z路径覆盖等方法
选择方法的几条经验
在测试中，可采取先静态再动态的组合方式，先进行代码检查和静态结构分析，再进行覆盖测试
将静态分析的结果作为引导，通过代码检查和动态测试的方式进一步确认静态分析的结果
覆盖测试是白盒测试的重点，一般可使用基本路径法达到语句覆盖标准，对于软件的重点模块，应使用多种覆盖标准衡量测试的覆盖率
不同测试阶段的测试重点不同，在单元测试阶段，以代码检查、覆盖测试为主，在集成测试阶段，需要增加静态结构分析等，在系统测试阶段，应根据黑盒测试的结果，采用相应的白盒测试方法。
白盒与黑盒的比较
- | 白盒测试 | 黑盒测试 |
| — | — |
| 考察程序逻辑结构 | 不涉及程序结构 |
| 用程序结构信息生成测试用例 | 用软件规格说明书生成测试用例 |
| 主要适用于单元测试和集成测试 | 可适用于从单元测试到系统验收测试 |
| 测试所有逻辑路径 | 某些代码段得不到测试 |
- | 白盒测试 | 黑盒测试 |
灰盒测试
灰盒测试是介于白盒测试和黑盒测试之间的测试方法，它关注输出对于输入的正确性，也关注内部表现，但是不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。有时候输出是正确的，但是程序内部已经是错误的，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此可采取灰盒测试这种方法。
灰盒测试结合了白盒测试和黑盒测试的要素，考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。可以认为，集成测试就是一类灰盒测试。
测试的步骤
单元测试
在进行单元测试时，被测试的单元本身不是独立的程序，需要为其开发驱动模块和桩模块。
驱动模块是用来模拟待测试模块的上级模块。驱动模块在集成测试中接受测试数据，将相关的数据传送给待测模块，启动待测模块，并打印出相应的结果
桩模块也称为存根程序，用以模拟待测模块工作过程中调用的模块。
桩模块由待测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验待测模块与下级模块的接口。
集成测试
组装测试也称集成测试，是在单元测试的基础上，将所有模块按照软件设计要求组装成执行子系统、功能子系统直至应用系统并进行测试的过程。
测试内容：主要是模块间的结构和通信,发现软件设计阶段产生的错误
测试方法：黑盒测试
注意问题
接口数据丢失：连接各模块时，穿越模块接口的数据是否会丢失
模块功能干扰：一个模块的功能是否对其他模块的功能产生不利影响。
组合成功：各个子功能组合起来，能否达到预期的父功能。
整体数据结构：全局数据结构是否有问题
误差积累：单个模块的误差是否会累积、放大
影响数据库：单个模块的错误是否会导致数据库错误
非增量组装测试方式一次组装，然后测试
不使用
增量组装测试方式
增量式集成测试中单元的集成是逐步实现的，集成测试也是逐步完成的
一边测试一边组装
自顶向下增量式集成测试
这种组装方式是将模块按系统程序结构，沿控制层次自项向下进行组装。
这种方式在测试过程中较早地验证了主要的控制点和判断点。在一个功能划分合理的程序结构中，判断常出现在较高的层次，因而能较早地遇到。如果主要控制有问题，尽早发现能够大大减少以后的返工。
优点：能够尽早发现系统主控方面的问题，驱动真实，上层测试充分。
缺点：需要设计大量桩模块、进行大里回归测试,测试用例设计麻烦。
自底向上增量式集成测试
这种组装方式从程序结构的最底层模块开始组装和测试。
由于模块是由底向.上进行组装的,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)已经组装并测试完成,以不再要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接得到。
基本增殖步骤
编写驱动模块，把最底层的模块组合成子功能模块族。
用实际模块替换驱动模块，把子功能族组合起来形成更大的功能族。
为子系统编写驱动模块，进行新的测试过程。
重复步骤②、③,直到完成所有的模块组装测试。
优点：桩模块真实，驱动模块和测试用例容易编写;能够尽早查出底层涉及较复杂的算法和实际的I/0模块中的错误。
缺点：系统结构建立晚，系统协调、功能接口问题发现的晚。
深度优先与宽度优先
- 无论是自顶向下还是由底向上的方式，都可以选择深度优先或者宽度优先增量方式
混合方式（实际使用）
确认测试
确进一步验证软件的有效性,即验证软件的功能、性能及其他特性是否与用户的要求一致。
测试依据：需求规格说明书
测试人员：专门测试部门、专业用户、典型用户、专家
有效性测试：制定测试计划,运用黑盒法验证软件特性是否与需求符合。
软件配置复查：软件配置指软件工程过程中所产生的所有信息项一一文档、报告、程序、表格、数据。随着软件工程过程的进展,软件配置项(SCI software Configuration Item)快速增加和变化，应复查SCI是否齐全。
确认测试结果
在全部确认测试的测试用例运行完后，所有的测试结果可以分为两类:
测试结果与预期的结果相符-一这说明软件的这部分功能或性能特征与需求说明书相符合，从而这部分程序可以接受。
测试结果与预期的结果不符一-这说明软件的这部分功能或性能特征与需求说明书不一致，因此需要开列一张软件各项缺陷表或软件问题报告，通过与用户的交流，解决所发现的缺陷和错误。
测试类型
功能测试：根据需求规格说明书和测试需求列表，验证产品的功能是否符合需求规格
性能测试：用来测试软件系统在实际的集成系统中的运行性能
安装测试：用来确保软件在正常情况和异常情况的不同条件下都不丢失数据或者功能，具体测试活动包括首次安装、升级、完整安装、自定义安装、卸载等
可用性测试：检验其是否达到可用性标准
压力测试：不是在常规条件下运行手动或自动测试，而是长时间或超大负荷地运行测试软件来测试被测系统的性能、可靠性、稳定性等
容量测试：目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在该极限值下没有出现任何软件故障或还能保持主要功能正常运行
安全性测试：目的是验证系统的保护机制是否能够在实际的环境中抵御非法入侵、恶意攻击等非法行为
健壮性测试：指在故障存在的情况下，软件还能正常运行的能力
图形用户界面测试：包含两方面内容，一是界面实现与界面设计是否吻合，二是界面功能是否正确
文档测试：文档包括开发文档、管理文档和用户文档3种
验收测试
验收测试是在系统测试之后进行的测试，目的是验证新建系统产品是否能够满足用户的需要，产品通过验收测试工作才能最终结束。具体说来，验收测试就是根据各自需求说明书的标准，利用工具进行的一项检查工作，其中包括对进程的验收、进程质量是否达到需求说明书的要求，以及是否符合工程的设计要求等，验收测试可分为前阶段验收和竣工验收两个阶段。
验收测试是依据软件开发商和用户之间的合同、软件需求说明书以及相关行业标准、国家标准、法律法规等的要求对软件的功能、性能、可靠性、易用性、可维护性、可移植性等特性进行严格的测试，验证软件的功能、性能及其他特性是否与用户需求一致。
α测试：是用户在开发环境下的测试，或者是开发公司组织内部人员模拟各类用户行为，对即将面市的软件产品进行的测试，它是由开发人员或测试人员进行的测试。在α测试中，主要是确认使用的功能和任务，测试的内容由用户需求说明书决定。α测试是试图发现软件产品的错误的测试，它的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作，并尽最大努力涵盖所有可能的用户操作方式。
β测试：β测试由最终用户实施，通常开发（或其他非最终用户）组织对其的管理很少或不管理。β测试是所有验收测试策略中最主观的：测试员负责创建自己的环境、选择数据，并决定要研究的功能、特性或任务，采用的方法完全由测试员决定。
回归测试
回归测试是指软件系统被修改或扩充后重新进行的测试，回归测试是为了保证软件修改后，没有引入新的错误而重复进行的测试
面向对象的软件测试
在基于面向对象思想的软件开发中，由于面向对象的软件工程方法与传统的软件工程方法有诸多不同，所以传统的软件测试模型对面向对象的软件系统已经不再适用。
在面向对象的软件开发中，人们已经抛弃了传统的测试模型。针对面向对象的开发模型中的面向对象分析（OOA）、面向对象设计（OOD）、面向对象实现（OOP）3个阶段
面向对象分析的测试
结构化需求分析把目标系统看成是一个由若干功能模块组成的集合，而面向对象需求分析以现实世界中的概念为模型结构。前者关注系统的行为，即功能结构，后者更关注于系统的逻辑结构。对面向对象需求分析的测试，要考虑以下方面：
对认定的对象或类的测试
对定义的属性和操作的测试
对类之间层次关系的测试
对对象之间交互行为的测试
对系统逻辑模型的测试等
面向对象设计的测试
与传统的软件工程方法不同的是，面向对象分析和面向对象设计之间并没有严格的界限。实际上，面向对象设计是对面向对象分析结果的进一步细化、纠正和完善。对面向对象设计的测试涉及了面向对象分析的测试内容，但是会更加关注对类及其类之间关系的测试和对类库支持情况的测试。
面向对象实现的测试
面向对象的程序具有封装、继承和多态的特性。测试多态的特性时要尤为注意，因为它使得同一段代码的行为复杂化，测试时需要考虑不同的执行情况和行为。由于系统功能的实现分布在类中，所以本阶段的测试中还要重点评判类是否实现了要求的功能。
面向对象的单元测试
面向对象的单元测试以类或对象为单位。由于类包含一组不同的操作，并且某些特殊的操作可能被多个类共享，因此单元测试不能孤立地测试某个操作，而是将操作作为类的一部分。
面向对象的集成测试
面向对象的集成测试采用基于线程或者基于使用的测试方法。基于线程的测试是指把回应系统外界输入的一组相关的类集成起来，对线程进行集成并测试。基于使用的测试方法按照类对服务器的依赖以及对其他类的依赖程度，把类划分为独立类和依赖类。
独立类是指那些几乎不使用服务器的类。在进行基于使用的测试时，先测试独立类。
依赖类是使用独立类的类，即它们对独立类存在某种程度的依赖。
在测试完独立类后，就可以测试依赖类了。依赖类可能还划分为多个层次，测试时按照逐层向下的顺序，直到测试完整个系统。
面向对象的系统测试及验收测试
在系统测试的过程中，软件开发人员要尽量搭建与用户的实际使用环境相同的平台，检测和评估目标系统是否能作为一个整体，满足用户在性能、功能、安全性、可靠性等各个方面的要求。面向对象的系统测试要以面向对象需求分析的结果为依据，验证需求分析中描述的对象模型、交互模型等各种分析模型。
软件调试
调试（也称为纠错）是在测试发现错误之后排除错误的过程。
虽然调试可以而且应该是一个有序的过程，但是在很大程度上它仍然是一项技巧。软件工程师在评估测试结果时，往往仅面对软件问题的症状，也就是说，错误的外部表现和它的内在原因之间可能并没有明显的联系。调试就是把症状和原因联系起来的尚未被人很好理解的智力过程。
强行排错
适合于结构比较简单的程序。是使用较多，效率较低的方法。
在程序中插入打印语句
- 将内存和寄存器的内容打印或显示出来，然后从中找出错误的原因
屏蔽部分程序
把不需要执行的语句段加上注释符号，使其不再运行
在不需要执行的语句段前加上判断值为假的if语句，使其不再运行
调试完成后再恢复
借助于调试工具
回溯排错
演绎排错