7.6 软件测试 (6课时)
软件测试这一组课不是在教“怎么随便跑一下程序”，而是在建立一套发现缺陷、控制风险、支撑交付的工程方法。考试会把它拆成概念判断、方法归类、覆盖准则、测试阶段和 McCabe 复杂度计算；真实项目里，它对应从需求评审到上线回归的整条质量防线。
测试在开发中的位置
测试越晚开始，发现的问题越容易变成返工。需求写错时改一句需求即可；设计错了要改架构；编码后才发现，往往要连同代码、接口、数据和文档一起改。因此测试不是编码结束后的附属环节，而应从需求、设计、编码到维护持续发生。
mermaid
flowchart LR
R["需求与规格说明"] --> D["概要/详细设计"]
D --> C["编码实现"]
C --> I["集成与系统运行"]
R -.评审/验收标准.-> RT["测试计划与用例"]
D -.接口/路径分析.-> RT
C -.单元/白盒.-> UT["单元测试"]
UT --> IT["集成测试"]
IT --> ST["系统测试"]
ST --> AT["验收测试"]
I -.缺陷修复后.-> REG["回归测试"]
REG --> ST这张图要抓住两点：第一，测试准备可以早于代码；第二，修复缺陷后不能只看被修的那一行，还要确认原来正确的功能没有被破坏。
六课时的知识地图
| 小节 | 要解决的问题 | 典型考法 |
|---|---|---|
| 7.6.1 软件测试概述 | 测试为什么做、能证明什么、不能证明什么 | “测试能证明程序无错吗”这类判断题 |
| 7.6.2 基本概念及分类 | 静态/动态、黑盒/白盒、有效/无效用例如何区分 | 给一个场景判断属于哪种测试 |
| 7.6.3 黑盒测试 | 不看代码时怎样用需求设计用例 | 等价类、边界值、错误推测、因果图 |
| 7.6.4 白盒测试 | 看代码结构时怎样衡量路径覆盖程度 | 语句覆盖、判定覆盖、条件覆盖、路径覆盖 |
| 7.6.5 系统测试阶段 | 不同阶段测什么、谁来测、用什么辅助模块 | 单元、集成、系统、验收；桩/驱动模块 |
| 7.6.6 McCabe 复杂度 | 如何由控制流图估算独立路径数量 |
先建立三组核心区分
静态测试与动态测试
静态测试不运行程序，靠人工阅读、评审、走查来发现需求、设计、代码中的错误。它适合在早期降低返工成本。动态测试要运行程序，通过输入数据、执行路径和实际输出发现问题。
| 维度 | 静态测试 | 动态测试 |
|---|---|---|
| 是否运行程序 | 不运行 | 运行 |
| 常见形式 | 桌前检查、代码审查、代码走查、文档评审 | 黑盒测试、白盒测试、性能测试、回归测试 |
| 擅长发现 | 需求遗漏、设计不一致、代码规范和明显逻辑问题 | 运行时错误、接口错误、边界错误、性能瓶颈 |
| 局限 | 不能看到真实运行行为 | 依赖用例质量，不能穷尽所有输入 |
黑盒测试与白盒测试
黑盒测试把程序看作一个只暴露输入和输出的盒子，依据需求规格来测功能。白盒测试打开盒子，依据程序内部控制结构、条件、路径来设计用例。
| 维度 | 黑盒测试 | 白盒测试 |
|---|---|---|
| 依据 | 需求、输入、输出、业务规则 | 源代码、控制流、条件和路径 |
| 典型方法 | 等价类划分、边界值分析、错误推测、因果图 | 语句覆盖、判定覆盖、条件覆盖、路径覆盖、基本路径测试 |
| 能发现 | 功能遗漏、输入校验错误、边界处理错误 | 逻辑分支遗漏、死代码、路径错误、循环错误 |
| 不擅长 | 内部不可达路径、隐藏逻辑问题 | 需求遗漏，因为代码里没有写的功能很难被白盒发现 |
测试阶段的范围扩大
测试阶段从小到大：单元测试看一个模块；集成测试看模块组合和接口；系统测试看完整系统是否满足规格；验收测试从用户业务角度确认能否交付。
复习时的主线
不要孤立背概念，按“测试对象 -> 设计用例依据 -> 覆盖目标 -> 缺陷反馈”这条线复习：
- 如果题目强调“不运行程序”，先想到静态测试。
- 如果题目强调“只看输入输出”，先想到黑盒测试。
- 如果题目强调“程序内部逻辑、路径、判定条件”，先想到白盒测试。
- 如果题目强调“模块接口”，先想到集成测试。
- 如果题目给了控制流图、节点边数或判定数，先想到 McCabe。
考试常见陷阱
| 说法 | 判断 | 原因 |
|---|---|---|
| 软件测试可以证明程序没有错误 | 错 | 测试只能显示缺陷存在，不能证明缺陷不存在 |
| 程序员完全不能参与测试自己的代码 | 过度绝对 | 原则上应避免自测偏见，但单元测试常由程序员承担 |
| 只要做了语句覆盖，逻辑就很充分 | 错 | 语句覆盖可能只走了判定的一个方向 |
| 黑盒测试不需要需求文档 | 错 | 黑盒测试主要依据需求规格和输入输出关系 |
| 修复缺陷后只验证这个缺陷即可 | 错 | 还要做回归测试，防止引入新错误 |
例题
软件测试的主要目标更接近：
本节小结
软件测试的本质是通过有目的的检查和执行来降低交付风险。复习本节要把分类、方法和阶段连起来：静态/动态回答“是否运行”，黑盒/白盒回答“是否看内部结构”，单元/集成/系统/验收回答“测试范围有多大”，McCabe 回答“控制路径有多复杂”。