测试：全绿之前，先看它验证了什么

本页归纳以 2024—2026 年相关工程讨论为基础，重点是自动化测试与验收之间的关系。

把要求落在工具里

一个重复出现的观点是：人和 AI 都会遗漏要求。能执行的测试，比只存在于文档里的要求更有约束力；编译错误与 CI 拒绝可以把问题明确暴露出来。

这不意味着文档无用。文档适合记录意图、原因、导航和取舍，测试则负责约束可检验的行为。

测试全绿的含义有前提

在讨论大规模修改的验收时，一个关键条件是：原有测试覆盖充分，而且这次改动没有为了放行而改变那些验证。

缺少这个条件，不能用全绿推导出目标已完成。可以继续追问：

• 测试是否真的覆盖了此次修改影响到的行为？
• 失败路径、兼容要求和回归风险是否被检查？
• 测试的预期结果是否来自独立的正确性定义？
• AI 有没有通过修改验证条件，让错误结果变得可接受？

测试也需要被 review

测试代码存在，不代表它表达了正确要求。检查用例是否有效，有时比逐行检查实现更能发现根本问题。

对于已有充分验证的组件，可组合性和正交设计还可能让原有数据帮助验证新组合。但这依赖设计和既有验证的可靠性，不能把任意函数拼在一起就当成性质证明。

为什么还要看代码

自动化测试不等于完整地衡量了可维护性、结构和性能。一个行为正确的实现，仍可能新增很多不必要的结构，或者让接口的使用异常别扭。

在 2026 年关于 AI 修改的讨论里，充分的测试与人工观察过度工程化是配套的，而不是互相取代的。

用这页分析一个问题

不要只问“测试过了吗”，还要问“什么条件被这些测试排除了，什么条件没有”。对不能覆盖的部分，明确安排其他验收，而不是把不确定性藏在绿色标记里。

这套观点特别来自复杂、长期维护的工程场景。一次性低风险任务需要多大验证投入，应另按后果决定。