7.6.5 系统测试阶段
测试阶段回答的是“测到多大的范围”。同样一个登录功能，在单元测试里关注密码校验函数，在集成测试里关注认证服务与用户库的接口，在系统测试里关注完整登录流程，在验收测试里关注用户是否能完成真实业务。
从小到大的四个阶段
| 阶段 | 测试对象 | 主要责任 | 常见依据 | 典型缺陷 |
|---|---|---|---|---|
| 单元测试 | 函数、类、模块 | 开发人员为主 | 详细设计、代码逻辑 | 分支错误、边界错误、局部算法错误 |
| 集成测试 | 模块组装后的子系统 | 开发/测试协作 | 概要设计、接口设计 | 参数不一致、调用顺序错误、数据格式错误 |
| 系统测试 | 完整软件系统 | 独立测试人员为主 | 需求规格说明书 | 功能遗漏、性能不足、安全和兼容问题 |
| 验收测试 | 可交付系统 | 用户或用户代表 | 合同、需求、验收标准 | 不符合业务期望、交付条件不满足 |
范围越往后越大，定位缺陷通常越困难。所以单元和集成阶段发现问题非常重要。
单元测试
单元测试关注模块内部逻辑。它常结合白盒测试方法，例如语句覆盖、判定覆盖、条件覆盖、基本路径测试。
单元测试常检查：
- 模块接口是否正确接收和返回数据。
- 局部数据结构是否正确。
- 重要执行路径是否被覆盖。
- 边界条件和错误处理是否正确。
- 资源申请与释放是否匹配。
单元测试通常由程序员承担，但这不意味着“程序员只测试自己的代码就足够”。它只是质量防线的第一层。
集成测试
集成测试关注模块之间的接口和协作。模块单独正确，不代表组合后正确。接口字段含义、调用顺序、异常传递、共享数据都可能出问题。
桩模块与驱动模块
集成测试经常需要辅助模块：
| 辅助模块 | 作用 | 常出现于 |
|---|---|---|
| 桩模块 Stub | 模拟被调用的下层模块 | 自顶向下集成 |
| 驱动模块 Driver | 模拟调用者，调用被测模块 | 自底向上集成 |
例如测试上层“订单服务”时，下层“支付服务”还没完成，就可以用桩模块模拟支付结果。反过来，测试底层“金额计算模块”时，上层界面还没完成，就用驱动模块给它传入参数。
集成策略对比
| 策略 | 做法 | 优点 | 缺点 | 常考关键词 |
|---|---|---|---|---|
| 自顶向下集成 | 从主控模块开始，逐步替换下层桩模块 | 早验证高层控制和主要业务流程 | 需要较多桩模块，底层细节验证较晚 | 桩模块 |
| 自底向上集成 | 先测底层模块，再逐步组合到上层 | 底层模块测试充分，不需要大量桩模块 | 需要驱动模块，高层流程验证较晚 | 驱动模块 |
| 三明治集成 | 上层自顶向下、下层自底向上，中间汇合 | 并行度高，能较早兼顾高层控制和底层服务 | 计划和协调更复杂，中间层接口风险较高 | 混合集成 |
不要把三明治集成简单理解为“辅助模块最少”。它的优势更多在于并行推进和兼顾上下层验证，但管理复杂度会增加。
系统测试
系统测试把软件作为一个完整系统来验证，通常依据需求规格说明书。它不仅测试功能，还会测试性能、安全、恢复、兼容性、易用性等非功能需求。
| 系统测试类型 | 关注点 |
|---|---|
| 功能测试 | 功能是否符合需求 |
| 性能测试 | 响应时间、吞吐量、资源利用率 |
| 压力测试 | 超负载时是否崩溃、是否可恢复 |
| 安全测试 | 权限、认证、敏感数据、攻击防护 |
| 安装测试 | 安装、升级、卸载是否正常 |
| 恢复测试 | 故障后数据和服务能否恢复 |
系统测试阶段常以黑盒测试为主，因为它更关注完整系统对外表现。
验收测试
验收测试从用户角度确认系统是否达到交付条件。它关心的不只是“程序有没有按代码逻辑运行”，而是“业务能不能用，合同和验收标准是否满足”。
| 类型 | 说明 |
|---|---|
| Alpha 测试 | 用户在开发方场所、受控环境下测试 |
| Beta 测试 | 用户在实际使用环境中测试，开发方不在现场直接控制 |
Alpha 和 Beta 在其他章节也可能出现，注意它们都属于验收相关的用户测试视角。
回归测试
回归测试贯穿维护和迭代。只要软件被修改，就要评估影响范围并重新测试相关功能。
回归测试不是“把所有用例永远全跑一遍”这么机械。实际项目会根据影响分析选择核心用例、相关模块用例和高风险用例；自动化测试常用于降低回归成本。
例题
本节小结
测试阶段按范围扩大：单元测模块内部，集成测接口协作，系统测完整规格，验收测用户交付。集成策略要重点区分桩模块和驱动模块：自顶向下常用桩，自底向上常用驱动，三明治集成上下并行但协调更复杂。