三个术语的区别
ISTQB 术语体系区分三个层次：error（人的失误，如理解错需求）、defect/fault（工作产物中的缺陷，如代码写错条件）、failure（运行时的失效表现，如用户看到错误结果）。三者构成因果链：失误引入缺陷，缺陷在特定条件下触发失效。缺陷可以长期潜伏而不立即引发失效，所以「测试通过」不等于「不存在缺陷」。
基本信息
| 术语来源 | ISTQB 标准术语表 |
|---|---|
| 因果链 | error 失误 → defect 缺陷 → failure 失效 |
| 关键认知 | 缺陷潜伏期可很长，未触发不等于不存在 |
| 沟通价值 | 缺陷记录指向原因而非现象 |
术语对照
| 术语 | 含义 | 示例 |
|---|---|---|
| error（失误） | 人产生的错误行为 | 需求理解错、条件写反 |
| defect（缺陷） | 工作产物中的问题 | 代码错误条件、设计缺失 |
| failure（失效） | 运行时的错误表现 | 金额算错、接口返回 500 |
| root cause（根因） | 缺陷背后的引入原因 | 缺少评审、需求歧义、赶工期 |
典型使用场景
- 缺陷报告：把现象（失效）与原因（缺陷）分开记录，修复指向缺陷本身
- 根因分析：连续追问为什么，定位引入环节（需求、设计、编码或配置）
- 缺陷分类统计：按引入阶段归类，指导过程改进
- 复盘会议：用统一术语描述问题，避免各说各话
- 测试结论沟通：说明「通过」只代表采样范围内未观察到失效
团队内「bug、问题、异常」混用时先对齐定义：一句话说清「谁做错了什么、产物哪里有问题、运行时表现是什么」。
潜伏缺陷（未被执行到的分支、低频路径）靠评审、静态分析与覆盖分析发现，而不是等失效出现后再补救。
缺陷报告的最小要素：环境与版本、复现步骤、预期与实际结果、数据与日志附件；缺少任何一项，修复者都要反复往返确认，平均修复时长被拉长。