| name | yweb-test-quality |
| description | 审查和改进 pytest 测试的真实性,防止 Happy Path、浅层、实现驱动、同义反复等虚假测试;在测试失败时执行先诊断后改码流程。用于测试评审、测试重构、失败排查场景。 |
YWeb 测试真实性与失败处置 Skill
用于以下场景:
- 用户要求“评估测试是否合理”
- 需要修复“虚假测试”或“脆弱测试”
- pytest 失败后需要判断该改测试还是改源码
一、测试真实性审查步骤
Step 1:识别测试目标(规格)
- 先写出被测能力的外部契约(输入、输出、错误语义、权限语义)
- 如果契约缺失,标记为“规格缺口”,不要假设实现即规格
Step 2:对照七类风险
逐项判断是否存在:
- Happy Path Testing
- Shallow Testing
- Fragile Test
- Implementation-Driven Testing
- Self-Validating / Tautological
- Puppet Test
Step 3:检查同源自证
若出现以下模式,判定为高风险:
- 测试输入由 SUT 的另一能力直接生成,再由 SUT 自己验证
- 测试断言仅重复实现逻辑,而非验证规格结果
改进策略:
- 用“手工构造的已知输入 + 可预测存储状态”替代同源链路
- 增加负例与边界例,证明行为不是偶然通过
Step 4:增强断言深度
至少覆盖:
- 成功路径
- 缺失/非法输入
- 权限不足
- 失效状态(过期/禁用/撤销)
- 依赖不存在(如用户不存在)
- 优先级/冲突规则(如 Header > Query > Cookie)
二、测试失败处置(先诊断后改码)
强制流程
- 复现失败(固定命令、环境、失败用例)
- 缩小范围(最小化复现)
- 分类结论:
- 输出方案(至少 2 个):
- 等用户确认后再改动源码或测试
默认禁止“测试一红就直接改业务代码”。
三、输出模板(建议直接复用)
## 测试真实性评审结论
- 风险级别:
- 主要问题:
- 证据:
## 失败诊断
- 失败用例:
- 复现命令:
- 实际结果:
- 期望结果(规格依据):
- 分类(A/B/C):
## 可选修复方案
1. 方案 A(改测试)
2. 方案 B(改实现)
3. 方案 C(补规格)
## 待确认
- 请确认采用方案:
四、与现有规范协同
本 Skill 与以下文档配套使用:
.cursor/skills/yweb-testing/SKILL.md
.cursor/rules/yweb-testing.mdc
.cursor/rules/test-quality-and-failure-workflow.mdc
yweb-core/TEST_DOCS.md