dsh-ci-test-reliability

1# 设计有效测试，修复不可靠的验证
2 
3阅读[项目上下文](references/project-context.md)和[验证证据](references/evidence.md)。新增覆盖或审查覆盖情况时选择测试设计；已经观察到间歇性失败时选择偶发失败诊断。任务需要时才组合两者。诊断或测试计划请求保持只读，除非用户要求实现。
4 
5## 设计或审查测试覆盖
6 
71. 阅读[测试选择](references/test-strategy.md)。将变化的行为对应到真实调用方和失败风险，再检查已有覆盖与必需检查。
82. 对每个重要缺口，选择测试层级、真实入口、测试替身和独立断言。说明 mock 会绕过什么。手工组装的单元样例无法检出缺陷时，使用真实入口验证组件组装。
93. 复用已经能够发现风险的测试。只有用户要求实现覆盖时才添加测试；计划任务给出具体用例和期望结果。
104. 已实现的回归测试或防护检查，应有会失败的错误对照和会通过的合法样例。执行相关检查和项目必需检查，分清实际执行、建议执行与受阻的检查。
11 
12## 诊断偶发失败
13 
14阅读[测试可靠性](references/test-reliability.md)。
15 
161. 保留原始失败、随机种子、工作进程数量、进程和 CI 任务的组织方式及相关日志。区分产品断言失败与环境准备、网络或工具失败。
172. 从分配到清理，追踪资源归属。检查固定临时名称、端口、数据库键、缓存、环境变量、工作目录、计时器和子孙进程。
183. 用同步屏障或可观察状态重现导致失败的执行交错。检查启动、等待期间取消、部分初始化，以及工作仍在运行时开始清理的情况。建立能通过真实测试入口检出原始缺陷的错误对照。
194. 修复资源负责方：原子分配资源、限定可变状态范围、等待真实就绪，并确保释放后没有使用者继续运行。依赖可能在调用方仍运行时被释放，就读[生命周期](references/lifecycle.md)。失败时也要继续完成相互独立的清理。
205. 按原有进程与任务组织方式运行，并执行针对性回归。重复执行可用于观察偶发故障，但不能代替确定性的回归断言。确认初始化失败和正常完成后，资源都已释放。
21 
22报告竞争或隔离缺陷、新测试为何能检出它、实际验证的并发方式及剩余不确定性。没有相应证据时，不得将延长超时、跳过、重试或单工作进程运行称为根因修复。