杀虫剂悖论是什么
杀虫剂悖论是 ISTQB 七原则之一：同一组测试用例反复运行后，发现新缺陷的能力会像昆虫产生抗药性一样下降——代码里的旧问题都被修完了，用例却还在原样重复。表现是对外看回归全绿，线上却持续冒出新问题。对策不是「跑更多次」，而是更新用例、补充新失效模式，并让探索式测试补位。
基本信息
| 出处 | ISTQB 七原则之一 |
|---|---|
| 现象 | 回归通过但线上仍出问题，缺陷检出率持续走低 |
| 成因 | 用例长期不更新、不淘汰、覆盖的都是已知路径 |
| 对策 | 用例评审、补充新失效模式、结合探索式测试 |
| 配套动作 | 把线上缺陷回溯纳入用例更新输入 |
典型使用场景
- 用例库年度评审：逐条判断是否仍在检出有效缺陷，淘汰僵尸用例。
- 线上缺陷回溯：每次事故评估现有回归为何没捕获，需要补哪类用例。
- 版本轮换探索：按版本节奏轮换探索式测试的章程，持续冲击未知区域。
- 回归时长治理：冻结并淘汰长期零缺陷且无需求关联的用例。
- 失效模式积累：把新发现的问题类型沉淀为用例设计清单。
- 新人引入变化：让不熟悉原用例的人评审，找出被忽视的盲区。
用例更新闭环
用例更新闭环
# 线上缺陷回溯三问
1. 现有回归为何没捕获？ # 判断是漏测还是用例失效
2. 属于哪类失效模式？ # 归入清单，检查同类区域
3. 应新增/修改哪条用例？ # 更新用例库并注明来源
# 输出：用例库增改记录 + 探索章程调整只增不减的用例库会同时推高执行时间与维护成本，淘汰与更新需要纳入例行工作。
新增用例要针对失效模式：复制既有用例的写法去覆盖同一逻辑，不会带来新的检出能力。
探索式测试与脚本化测试互补：探索发现的问题稳定化后，固化为新的回归用例，让用例库保持生长。