Day29-12｜8.3.3 阶段3——测试：用实验和证据验证架构质量目标

一、教材定位

ATAM 的阶段3“测试”不是只执行传统功能测试，而是针对阶段2识别出的质量属性场景、敏感点、权衡点和风险，设计实验和验证活动，判断架构策略是否真的能够产生预期响应。测试阶段把架构评估从“设计上应该可以”推进到“在明确条件下已经取得证据”。

二、测试阶段的目标

测试阶段主要有四个目标：验证高优先级质量属性场景是否满足；验证关键架构策略和敏感点；确认风险假设是否成立；为评估报告提供可重复、可追踪的证据。测试不一定在完整系统完成后进行，越早验证高风险决策，越能降低后期返工成本。

三、测试对象

测试对象包括架构原型、关键组件、服务组合、数据模型、通信链路、部署拓扑、配置基线和故障恢复机制。性能测试关注容量和长尾，可靠性测试关注异常和恢复，安全测试关注攻击面和权限边界，可修改性测试关注变更影响和回归范围，互操作性测试关注协议和语义兼容。

四、从质量场景设计测试

每个高优先级质量场景都应转化为测试条件、动作、观测指标和通过标准。比如性能场景“峰值每秒5000次查询，95%响应时间小于300毫秒”，测试需要明确请求分布、数据规模、节点数量、缓存状态、网络条件、持续时间、采样方式和失败判定。

可用性场景“一个应用节点宕机后五分钟内恢复”，测试需要明确宕机方式、健康检查阈值、切换时间、已有请求处理、数据是否丢失、用户错误率和恢复后的数据校验。若只关闭一个进程而不检查数据和依赖服务，测试证据是不完整的。

五、架构原型测试

架构原型用于验证关键不确定性，不要求实现完整业务。原型可以验证数据库分片、消息吞吐、跨地域复制、设备协议、密钥服务、缓存策略、服务治理或故障切换。

原型测试要避免“只展示成功路径”。应加入边界和异常，例如输入峰值、网络延迟、节点重启、消息重复、数据膨胀、配置错误和依赖不可用。原型结果还要说明与生产环境的差异，明确哪些结论可以外推，哪些只适用于当前实验。

六、性能和容量测试

性能测试包括基准测试、负载测试、压力测试、稳定性测试、容量测试和扩展性测试。基准测试用于比较单项机制；负载测试模拟预期负载；压力测试寻找极限；稳定性测试检查长时间运行；容量测试确定资源和业务上限；扩展性测试观察增加资源后的性能变化。

测试不能只关注平均响应时间，还要观察百分位、最大延迟、错误率、吞吐、CPU、内存、连接池、线程池、磁盘和网络。要区分系统本身瓶颈和测试工具、网络或外部依赖造成的瓶颈。

七、可靠性和故障注入测试

故障注入通过主动制造节点宕机、网络延迟、连接断开、磁盘满、消息重复、数据库不可用、配置错误和外部接口超时，观察系统是否按架构策略响应。故障注入应有范围、风险控制、停止条件和恢复方案，生产环境演练必须经过授权并做好数据保护。

可靠性测试关注检测、隔离、恢复和数据正确性四个阶段。系统发现故障并不等于恢复成功；恢复后还要检查未完成事务、重复消息、缓存、索引、审计和对账是否正确。故障演练报告应记录故障时间、发现时间、切换时间、恢复时间、影响范围和遗留问题。

八、安全与互操作测试

安全测试要根据威胁模型验证身份认证、授权、会话、输入、加密、密钥、审计和日志保护。架构评估阶段尤其要测试信任边界、跨服务权限、租户隔离、权限撤销和敏感数据泄露路径。

互操作测试要检查协议、数据格式、字段语义、编码、时间、错误码、幂等、重试和版本兼容。对于外部系统不可控的情况，应使用模拟器、契约测试和故障场景，不能只依赖一次联调成功。

九、可修改性和可测试性验证

可修改性测试选择具有代表性的变更，例如新增规则、增加外部渠道、调整流程、修改数据字段和升级协议，观察影响模块数、开发时间、回归范围、发布步骤和缺陷数量。测试的目的不是证明修改永远不影响系统，而是确认变化被隔离在预期边界内。

可测试性验证关注能否独立构造模块、替换依赖、清理数据、模拟外部系统、注入故障和追踪请求。如果测试必须启动所有系统、依赖真实第三方、手工准备大量数据，说明架构的测试边界和可观察性可能不足。

十、测试数据和环境

测试环境应尽可能代表目标生产环境，至少说明节点数量、规格、网络、数据库版本、中间件配置、数据量和安全设置。测试数据要覆盖正常、边界、异常、历史和高并发情况，敏感数据必须脱敏。

环境差异会导致错误结论。例如开发环境单节点测试无法证明生产集群的切换能力，少量数据无法证明索引和分片策略，理想网络无法证明跨地域复制和外部接口超时行为。因此测试报告要明确限制。

十一、测试结果与证据链

测试结果应与场景和架构决策建立追踪关系。建议记录场景编号、架构策略、测试用例、环境、输入、指标、结果、日志、结论和责任人。结果可分为满足、部分满足、不满足、未执行和无法判断。

“部分满足”需要说明差距和补救措施；“未执行”需要说明原因和后续计划；“无法判断”通常说明测试设计或观测能力不足。测试阶段不能为了得到“通过”而隐藏异常结果。

十二、案例分析：支付平台架构测试

某支付平台的高优先级场景包括峰值交易、重复回调、渠道超时、支付节点宕机和新增渠道。测试团队首先建立容量模型，在不同渠道延迟和不同数据库负载下进行压测，观察响应百分位、订单状态和资源使用。

随后注入渠道超时和重复回调，验证交易号幂等、状态机和补偿任务；关闭支付节点，验证负载切换和未完成请求；切换数据库主节点，验证数据一致性和恢复时间；实现一个模拟新渠道的适配器，验证核心订单模块无需修改。测试发现通知服务重试会产生重复消息，于是增加通知幂等和去重记录。

最终测试报告将每个场景与架构策略、指标和缺陷关联，给出条件通过结论：核心支付正确性满足，通知延迟在部分情况下超标，需要优化重试和死信处理后再复评。

十三、测试阶段常见错误

第一，只做功能测试，不验证质量属性。第二，只测正常负载，不测峰值和长时间运行。第三，只模拟应用故障，不验证数据恢复和外部依赖。第四，测试环境与生产差异过大，却直接外推结论。第五，只记录“通过”，没有原始指标、日志和条件。第六，测试发现风险后没有回到架构决策和设计方案进行修正。

十四、练习题

题1

为什么架构测试不能只在系统开发完成后进行？

参考答案

关键架构决策一旦落地，修改成本很高。早期使用原型、模型、压测和故障模拟验证高风险假设，可以在低成本阶段发现问题，避免完整实现后大规模返工。

题2

故障注入测试需要观察哪些阶段？

参考答案

需要观察故障检测、隔离、服务切换、请求处理、数据恢复、告警通知和业务补偿，不能只看节点是否重新启动。恢复后还应校验数据、缓存、消息和审计的一致性。

题3

为什么性能测试必须记录测试环境？

参考答案

响应时间和吞吐受节点规格、网络、数据量、中间件配置、缓存状态和外部依赖影响。没有环境信息，结果无法复现，也不能判断是否能够代表生产条件。

十五、论文写作素材

论文中可以写“在 ATAM 测试阶段，我将高优先级质量场景转化为性能、可靠性、安全、可修改性和互操作测试；通过原型和压测验证容量，利用故障注入验证节点、数据库和外部接口异常，利用重复请求和超时场景验证幂等与补偿，利用契约测试验证新增渠道；测试结果与架构决策和风险清单关联，部分不满足项经过整改和复评后再进入上线流程。”

十六、今日复盘

ATAM 测试阶段的核心是“场景驱动、风险优先、实验验证、证据可追踪”。测试不只是功能正确，还要证明质量属性策略在明确环境和负载下有效，并把测试发现反馈给架构决策和风险治理。