章节概述
软件测试与评审是软件质量保证的主要手段之一，也是在将软件交付给客户之前所必须完成的步骤。目前，软件的正确性证明尚未得到根本解决，软件测试与评审仍是发现软件错误（缺陷）的主要手段。软件测试的目的，是在软件投入生产性运行之前，尽可能多地发现软件产品中的错误（缺陷），追求以尽可能少的时间和人力发现尽可能多的缺陷。
评审则是对软件元素或项目状态进行评估的手段，用以确定其是否与计划的结果保持一致并使其得到改进。许多缺陷在早期阶段引入，越晚发现纠正费用越高，评审可在测试无法覆盖的阶段（如需求、设计）提前发现问题，从而减少泄漏到测试阶段的缺陷。本章重点要求掌握测试方法、评审方法、验证与确认、测试自动化、面向对象的测试等五个方面的知识。
知识结构框架
- 11.1 测试方法 — 测试目的与原则、错误与缺陷的概念
- 11.1.1 软件测试阶段 — 单元测试、集成测试（非渐增式/渐增式、自顶向下/自底向上）、系统测试（确认测试、验收测试、Alpha/Beta 测试）
- 11.1.2 白盒测试和黑盒测试 — 白盒逻辑覆盖 6 种标准；黑盒等价类划分、边界值分析、错误推测、因果图
- 11.1.3 缺陷的分类和级别 — 输入/输出、逻辑、计算、接口、数据 5 类；Beizer 10 级严重程度
- 11.1.4 调试 — 原始类、回溯类、排除类三种排错策略
- 11.2 评审方法 — 需求评审、概要设计评审、详细设计评审、验证与确认评审、功能检查、物理检查、综合检查、管理评审；评审注意事项
- 11.3 验证与确认 — 验证（合同/过程/需求/设计/编码/集成/文档）与确认
- 11.4 测试自动化 — 用例生成、执行控制、结果对比、分析通报、统计报表
- 11.5 面向对象的测试 — OOA/OOD/OOP 测试、OO 单元/集成/系统测试；基于线程与基于使用的集成
核心概念
白盒测试
又称结构测试，主要用于单元测试阶段。把程序看成透明白箱，测试者完全知道程序的结构和处理算法，按程序内部逻辑设计测试用例，检测主要执行通路是否按预定要求工作。常用技术是逻辑覆盖。
黑盒测试
又称功能测试，主要用于集成测试和确认测试阶段。把软件看作不透明黑箱，不考虑内部结构和处理算法，只检查功能能否按需求说明书正常使用，能否正确接收输入并产生正确输出。
等价类划分
用得最多的一种黑盒方法。将输入域划分成若干等价类，有效等价类检验功能实现，无效等价类检验容错性。每个无效等价类都应单独设计一个测试用例。
边界值分析
软件处理边界情况时最易出错。为每个等价类边界着重测试，选取恰好等于、稍小于或稍大于边界值的数据。常与等价类划分结合使用。
因果图
根据输入条件与输出结果之间的因果关系设计测试用例，先检查输入条件各种组合，找出输出对输入的依赖关系，再为每种组合设计测试用例。
单元测试
也称模块测试，放在编程阶段由程序员自行测试，检查模块是否实现详细设计规定的功能和算法。着重测试模块接口、局部数据结构、重要执行通路、出错处理通路和边界条件，需编写驱动模块和桩模块。
集成测试（自顶向下/自底向上）
对组装后的程序进行测试，发现模块间接口和通信问题。自顶向下集成先测上层模块，测试下层时上层已测过，不必另编驱动模块；自底向上集成先测下层，测试上层时下层已测过，不必另编桩模块。
确认测试与验收测试
确认测试依据需求说明书检查软件功能、性能及其他特征是否与用户需求一致，并复查软件配置。验收测试由客户实施确认需求是否满足。Alpha 测试在开发者场所受控环境进行，Beta 测试在用户现场不受控环境进行。
调试（排错）
测试成功的标志是发现了错误，调试则根据错误迹象确定原因和准确位置并加以改正。常用策略分原始类（最低效，"计算机找错"）、回溯类（沿控制流程回追）、排除类（归纳演绎，分治排除）三种。
软件评审
据 IEEE 1028，是对软件元素或项目状态的评估手段。狭义指文档和源程序评审，广义还包括与测试结合的评审及管理评审。评审不应以测试代替，应关注产品而非评论人，应聚焦实质问题，不应变为问题解决方案讨论会。
白盒测试覆盖强度
白盒测试常用逻辑覆盖技术，考察测试数据对程序逻辑的覆盖程度。主要的覆盖标准有 6 种，覆盖强度由弱到强递增（条件组合覆盖是前 5 种中最强的，路径覆盖考察所有可能路径但未考虑条件组合，不能替代条件覆盖）。
注：覆盖强度由弱到强递增。条件组合覆盖是上述 5 种覆盖标准中最强的一种，但还不能保证所有路径都经过一次；路径覆盖未考虑条件结果组合，不能替代条件覆盖和条件组合覆盖。
关键公式与规则
考试要点
- 白盒覆盖 6 种及强度排序必考：语句 < 判定 < 条件 < 判定/条件 < 条件组合 < 路径。注意条件组合覆盖是前 5 种中最强的，路径覆盖未考虑条件组合不能替代条件覆盖。
- 等价类划分：有效等价类检验功能，无效等价类检验容错性；每个无效等价类必须单独设计一个测试用例（易考点）。
- 边界值分析：取恰好等于、稍小于、稍大于边界值，与等价类划分结合使用效果更好。
- 因果图法：根据输入条件与输出结果的因果关系设计用例，检查输入条件的各种组合。
- 集成测试自顶向下 vs 自底向上易混：自顶向下需桩模块（stub），自底向上需驱动模块（driver）。口诀"上桩下驱"——自顶向下测上层时下层未测需 stub，自底向上测下层时上层未测需 driver。
- Alpha 测试 vs Beta 测试：Alpha 测试由用户在开发者场所进行、受控环境、开发者记录错误；Beta 测试在用户现场、不受控环境、用户负责记录并报告。
- 测试计划制定阶段：单元测试计划在详细设计阶段、集成测试计划在概要设计阶段、系统测试计划在需求分析阶段制订（易混考点）。
- 评审注意事项：不以测试代替评审；关注产品而非评论人；关注实质问题；评审会议不是问题解决讨论会；评审应纳入项目计划；参与者应了解评审过程并事先熟悉材料。
- 验证 vs 确认：验证适用于分析/设计/编码/测试/评审等过程（"做对了没有"），确认通常用于验收过程（"做了对的东西没有"）。
- 调试三类策略：原始类（最低效）、回溯类（程序大时路线过多）、排除类（归纳演绎、分治）。
- 面向对象测试：最小可测试单位变为类或对象；OO 集成测试两种策略——基于线程的测试、基于使用的测试；测试焦点从过程构件移向类，视角扩大到分析和设计模型。
关键图示
下表对比白盒测试与黑盒测试的核心差异，是本章最常考的对比知识点。上方"白盒测试覆盖强度"的阶梯图即为另一关键图示。
| 对比维度 | 白盒测试（结构测试） | 黑盒测试（功能测试） |
|---|---|---|
| 测试依据 | 程序内部逻辑、结构 | 软件需求说明书规定的功能 |
| 关注点 | 主要执行通路是否按预定要求工作 | 功能能否正常使用、输入输出正确性、外部信息完整性 |
| 是否了解内部结构 | 完全知道程序结构和处理算法 | 不考虑/不了解内部结构和处理算法 |
| 常用方法 | 逻辑覆盖（语句/判定/条件/判定-条件/条件组合/路径覆盖） | 等价类划分、边界值分析、错误推测、因果图 |
| 主要适用阶段 | 单元测试阶段 | 集成测试、确认测试阶段 |
| 优点 | 能检测程序内部逻辑，覆盖路径较充分 | 从用户视角验证功能，不受内部实现影响 |
| 缺点 | 无法发现功能遗漏、需求不匹配等错误 | 无法发现程序内部逻辑错误，用例覆盖难以穷尽 |