| 关注点 | 本次变更涉及功能的正确性 |
|---|---|
| 与冒烟的区别 | 冒烟验证整体可测性；健全性验证变更意图是否成立 |
| 执行时机 | 修复或小改动提交后 |
术语边界在不同组织中有所漂移，沟通时以「范围与目的」对齐比纠结名称更有效。
执行要点（示意）
| 时点 | 做法 |
|---|---|
| 变更提交后 | 直接打到变更点：主路径用例先过核心行为 |
| 修复验证时 | 先按原步骤确认已修复，再抽查邻近功能 |
| 判定不通过 | 基础功能不可用即退回开发，附现象与日志，不深挖 |
健全性测试（Sanity Test）
在冒烟通过后对变更相关的核心功能做窄而深的验证，判断本次修改是否值得继续深入测试；范围比冒烟窄，比回归聚焦。
易错点
- 把健全性测试做成全量回归，拖慢快速修复节奏
- 只测变更点不测关联影响，修复可能引入新问题而不自知
数据来源与参考
- ISTQB 术语表（sanity test 相关条目）