GeoXMind

可测试性需要观察与控制

说明测试为何依赖可观察状态、可控制输入和可隔离边界，以及结构怎样降低诊断成本。

可测试性需要观察与控制

可测试性不是测试框架的数量，而是系统在给定成本下能否被有效控制、观察和判断。若测试无法建立所需状态，或结果只能靠人工猜测，即使代码覆盖率很高，也难以证明关键行为正确。

测试必须能建立条件

验证一个行为之前，需要可重复地准备输入、身份、时间、依赖响应和数据状态。随机时间、全局单例、不可替换的外部服务以及共享数据库都会削弱控制能力，使同一测试在不同环境得到不同结果。

可控制不等于所有实现都暴露给测试。更稳妥的做法是通过稳定边界注入时钟、存储或远程客户端，并用公开行为设置前置条件。测试专用后门容易偏离真实路径，也可能在生产环境留下风险。

结果必须可以被观察

HTTP 状态码只能说明部分结果。持久化是否正确、异步任务是否启动、审计记录是否完整、缓存是否失效，都可能是业务行为的一部分。系统需要提供足够的返回值、事件、日志和查询接口，使测试能够区分成功、部分成功和失败。

观察信息必须稳定且有语义。依赖完整日志文本或页面像素位置的测试很脆弱，因为无关改动也会触发失败。适合断言的是契约化结果，例如状态转换、结构化事件、资源版本和明确错误代码。

确定性降低诊断成本

并发、重试和异步处理不能全部变成同步，但测试需要知道何时达到可判断状态。固定等待几秒既慢又不可靠。更好的边界会提供完成信号、可查询状态或受控调度器，让测试等待条件而不是猜测时间。

随机算法应允许固定种子，时间相关逻辑应使用可替换时钟，外部响应则需要可重放的契约样本。确定性不是改变生产语义，而是把环境中的不确定因素显式纳入设计。

分层测试对应不同风险

单元测试适合快速检查局部规则，组件测试验证模块与数据库等真实依赖的协作，契约测试保护服务边界，端到端测试覆盖少量关键旅程。只保留端到端测试会使反馈慢且定位困难，只保留单元测试则可能错过配置、序列化和事务问题。

测试层次应由故障后果和接口稳定性决定。高风险状态转换需要更接近真实环境的验证，纯计算规则则可在进程内充分覆盖。测试替身也应与目的相称，不能让模拟对象重新实现一套与生产不同的业务规则。

从失败能否定位来评估

一个测试失败后，如果团队必须翻阅多套日志、重跑整个环境并手工比对数据库，系统的可测试性仍然很弱。可关联的请求标识、清晰的失败原因、隔离的数据空间和可重现输入能显著缩短诊断时间。

SEI 的质量属性方法要求把测试刺激、环境和响应写成场景。可操作的目标可以是：在持续集成环境中建立指定状态，执行一次发布动作，并在限定时间内从响应和审计事件判断结果。这样的要求能反过来约束架构接口，而不是把验证问题留到开发结束。

资料依据