Day26-02｜5.4.2 测试阶段
Day26-02｜5.4.2 测试阶段：让不同层次的验证形成连续质量证据
本文对应《系统架构设计师教程（第2版）》第5章“软件工程基础知识”5.4.2“测试阶段”。测试阶段是按照软件生命周期组织测试活动的阶段划分，重点解决“在什么时机、对什么对象、用什么环境、由谁验证、达到什么条件”的问题。系统架构师需要把单元、集成、系统、确认、验收、回归和维护测试连接起来，并把性能、安全、可靠性、可用性和恢复等质量属性纳入全过程。
一、学习目标与考试定位
完成本节后，应能够说明软件测试阶段的主要类型、对象和目标；理解单元测试、集成测试、确认测试、系统测试、验收测试和维护测试的区别；掌握测试计划、测试设计、环境、数据、入口准则、出口准则、缺陷管理和回归策略；能够分析测试阶段之间的衔接和责任边界；能够在案例题中判断测试遗漏的根因；能够在论文中描述分阶段测试如何验证架构质量。
考试中常出现“单元测试通过但系统失败”“集成测试没有覆盖第三方”“验收测试被当成找缺陷”“修改一个模块导致旧功能回归”等问题。答题要指出测试对象和目标不同，不能用一个阶段替代另一个阶段；还要说明测试环境、数据、配置、版本和结果证据如何管理。
二、测试阶段的总体结构
软件测试可以按被测对象和验证目标分层。单元测试关注最小可测试单元，集成测试关注模块之间的接口和协作，确认测试关注系统是否满足软件需求，系统测试关注完整系统在目标环境中的功能与质量，验收测试关注用户和业务是否接受，维护测试关注修改、迁移和运行期间的影响。
测试阶段不是严格一次性顺序。单元测试可能在每次提交中执行，集成测试持续运行，系统和验收测试在迭代增量和发布前执行，维护测试在每次补丁、配置变化和环境迁移后触发。测试层次之间通过需求、接口、缺陷和版本追踪连接。
可以把质量证据链记为：
单元正确 → 接口协作正确 → 需求实现正确 → 完整系统可用 → 用户接受 → 变更后仍正确
三、测试计划和入口、出口准则
测试计划应说明范围、目标、策略、资源、角色、环境、数据、进度、工具、风险、缺陷流程和交付物。对架构相关项目，还要写明性能模型、故障注入、灾备、容量、安全、部署和第三方依赖的验证安排。
入口准则规定开始测试前必须具备的条件，例如需求和验收标准已确认、版本可构建、环境可用、测试数据准备完成、关键接口可访问、阻塞缺陷已处理。出口准则规定测试可以结束或进入下一阶段的条件，例如关键用例通过、严重缺陷关闭或有批准的例外、性能达到目标、测试报告完成、残余风险可接受。
入口和出口准则不能写成“测试完成”这种循环描述，应尽可能可观察、可度量。若入口不满足就强行测试，结果可能混入环境和版本问题；若出口只看通过率而忽略高风险未测场景，发布决策会失真。
四、单元测试
单元测试验证函数、类、组件或服务内部的最小逻辑单元，重点是输入输出、分支、异常、边界、不变量和局部状态。单元测试通常由开发人员编写和维护，执行速度快，便于在代码提交时反馈。外部数据库、网络、时间、随机数和第三方服务可以通过模拟、桩、驱动器或测试替身隔离。
单元测试不应过度依赖实现细节，否则重构就会导致大量无价值失败；也不能只测试简单成功路径。业务规则、权限判断、状态迁移、金额计算、错误处理和幂等约束应有明确断言。单元测试无法证明模块之间的序列化、事务、配置和真实依赖一定正确，因此必须与集成测试结合。
五、集成测试
集成测试验证两个或多个模块、服务、数据库、消息系统、设备或外部平台之间的接口和协作。常见集成策略包括一次性大集成、增量集成、自顶向下、自底向上、三明治和持续集成。复杂分布式系统更适合逐步集成，先验证关键接口和架构路径，再扩大范围。
集成测试应覆盖接口契约、数据格式、版本兼容、认证授权、超时重试、异常码、事务、一致性、消息重复和依赖不可用。测试环境要尽量接近真实拓扑，不能只用本地模拟服务得出生产结论。第三方接口无法完全控制时，应使用沙箱、契约测试、故障模拟和对账验证共同覆盖。
六、确认测试
确认测试检查软件是否满足软件需求规格，通常包括功能、接口、性能、安全、可靠性和其他约束。它关注“做出来的产品是否符合已确认需求”，需要依据需求、用例、验收标准和测试基线设计。确认测试可以由独立测试团队执行，也可以由开发、业务和测试共同完成，但应保持评价的客观性。
确认测试特别要关注需求中明确的边界和异常。若需求只写“支持批量导入”，确认测试就应澄清文件大小、字段错误、重复数据、部分成功、失败重试、权限、审计和结果通知，而不是只验证一份正常文件能导入。
七、系统测试
系统测试把完整系统作为整体，在接近目标运行环境的条件下验证功能和质量。功能系统测试覆盖端到端业务流程，非功能系统测试覆盖性能、负载、压力、容量、可靠性、可用性、安全、兼容性、恢复和部署。
系统测试需要真实的部署拓扑、配置、网络、依赖和代表性数据。对于微服务，不能只逐个测试服务，还要验证服务发现、配置中心、网关、链路追踪、消息、缓存、数据库和故障处理。对于高可用系统，要模拟节点故障、网络分区、数据库主备切换、消息积压、证书过期和磁盘空间不足等架构场景。
八、验收测试
验收测试由用户、客户或业务代表依据合同、业务目标和验收标准判断产品是否可以接受。它关注真实使用场景、业务价值、操作流程、报表、权限、培训、数据迁移和服务等级，不应被简化为测试团队再做一轮功能测试。
验收测试前需要明确参与者、数据、环境、时间、通过标准和问题处理方式。验收发现问题后，应区分缺陷、需求变化、环境问题和培训问题，不能把所有问题都直接视为代码缺陷。对于未达到目标但业务愿意接受的风险，要形成明确的例外、责任和后续计划。
九、回归测试与维护测试
回归测试验证修改后原有功能和质量没有被破坏。修改可能来自新功能、缺陷修复、重构、依赖升级、配置变更、数据库迁移、基础设施变化或安全补丁。回归范围应依据变更影响、依赖关系、风险和历史缺陷选择，既不能每次只测改动点，也不能毫无选择地执行全部测试。
维护测试发生在软件运行和演化阶段。包括纠正性维护、适应性维护、完善性维护和预防性维护后的验证；也包括版本升级、数据迁移、系统切换和灾备恢复后的测试。维护测试要关注兼容性、历史数据、配置、接口消费者、监控、备份和回滚，而不仅是新代码。
十、测试环境与数据管理
测试环境包括硬件、操作系统、中间件、数据库、网络、容器、云资源、配置、证书、依赖服务和监控。环境差异会造成“测试通过、生产失败”，因此应对环境版本和配置进行基线管理，使用基础设施即代码或自动化脚本提高可重复性。
测试数据应覆盖正常、边界、异常、权限、并发、历史和大规模场景。使用真实数据时必须脱敏并限制访问；合成数据要保持业务关联和分布特征。数据初始化、清理、回滚和版本也要自动化，否则测试结果难以复现。
十一、缺陷管理和测试度量
缺陷报告应包括编号、版本、环境、前置条件、步骤、输入、实际结果、预期结果、日志、截图、严重度、优先级和责任人。严重度表示对系统的影响，优先级表示处理的先后，两者不能混为一谈。缺陷状态应从新建、确认、修复、待验证、关闭或拒绝等阶段可追踪。
测试度量包括需求覆盖率、风险覆盖率、用例通过率、缺陷发现阶段、缺陷逃逸率、回归失败率、自动化稳定性、平均修复时间和环境可用率。指标要用于识别趋势和决策，不能为了好看而压低报告缺陷或删除失败用例。
十二、案例分析：银行核心系统升级
某银行升级核心交易系统，单元和接口测试通过，但联调时出现历史账户余额不一致、批量对账失败和夜间批处理超时。项目组发现测试环境使用了新建的少量数据，未模拟真实历史数据和批处理窗口；第三方支付使用模拟响应，没有验证超时和重复回调。
改进应按阶段补齐证据。单元层增加金额、状态和异常规则测试；集成层验证核心系统、支付、对账、消息和数据库之间的接口、版本、事务和幂等；系统层使用脱敏后的代表性历史数据，覆盖日终、月末、高峰、批量和故障切换；验收层由业务人员执行真实操作、报表、对账和异常处理；维护层安排灰度迁移、双写或比对、回滚、备份恢复和监控验证。
性能测试不能只测平均响应时间，还要观察高峰交易、批处理并发、锁竞争、数据库连接、消息积压和恢复后补偿。第三方故障要覆盖超时、重复、乱序和部分成功。每个出口条件必须关联实际报告和风险批准。
十三、常见误区
第一，单元测试通过等于系统正确。单元测试无法证明接口、环境和依赖协作。第二，集成测试只验证接口能调用。还要验证数据、认证、异常、超时、版本和一致性。第三，验收测试只是测试团队的最后一轮测试。它应由业务依据目标和标准接受产品。第四，回归测试只测修改代码。影响可能扩散到调用者、数据库、配置和部署。第五，测试阶段结束后质量活动结束。维护、升级和运行仍需持续验证。
十四、课后练习
练习一：单项选择
某模块单元测试全部通过，但与数据库和消息系统联调失败，最可能说明（ ）。
A. 单元测试一定无价值；B. 集成接口、配置或协作行为未被充分验证；C. 立即删除单元测试；D. 只增加页面测试。
答案：B。单元测试和集成测试验证目标不同，真实依赖、数据格式、事务和消息行为需要通过集成测试验证。
练习二：简答题
请说明入口准则和出口准则的作用。
参考答案：入口准则规定开始某测试活动前必须具备的需求、版本、环境、数据、接口和人员条件，防止在不可测试状态下执行；出口准则规定结束测试或进入下一阶段的客观条件，如关键场景通过、严重缺陷处理、质量指标达标、报告完成和残余风险获批。二者应可观察、可度量并与风险相匹配。
练习三：案例分析
某系统修复一个权限缺陷后只执行了该接口的回归测试，结果其他租户数据被误读。请分析原因并提出测试方案。
参考答案：权限修改可能影响共享授权组件、缓存、租户上下文、数据库查询和其他接口，只测一个接口没有覆盖影响范围；测试数据和角色组合不足，也可能没有验证缓存失效和跨租户场景。应根据变更影响建立回归集合，覆盖所有使用授权组件的接口、角色、租户、管理员和边界条件；验证认证、授权、数据过滤、缓存、日志和审计；执行跨租户、无权限、权限撤销、会话刷新和并发场景；在接近生产的多租户环境中测试，并通过代码审查、接口契约、安全扫描和端到端验收共同确认。
十五、论文素材
论文可写：我按照风险和生命周期组织测试活动，在单元阶段验证核心规则和异常分支，在集成阶段验证服务、数据库、消息和第三方接口的契约、一致性和故障处理，在系统阶段验证端到端业务以及性能、安全、可靠性、恢复和部署能力，在验收阶段由业务依据真实场景确认价值。对每个阶段设置入口和出口准则，统一管理环境、数据、版本和缺陷；变更和补丁通过影响分析选择回归范围，维护阶段继续验证历史数据、兼容性、监控和回滚，形成连续质量证据。
十六、今日复盘
测试阶段按被测对象和验证目标分层：单元验证局部逻辑，集成验证协作，确认验证需求，系统验证完整产品和质量，验收验证业务接受，回归和维护验证变化后仍然正确。测试必须有计划、环境、数据、入口准则、出口准则、缺陷闭环和追踪证据。阶段之间不能互相替代，架构师要把质量属性和故障场景纳入全过程。下一篇进入 5.5.1 净室软件工程理论基础。
