Bug 是 defect 的口语说法，defect 是正式术语——都指「软件不符合要求」的缺陷；而 issue 是伞词，把缺陷、需求、任务、疑问都装进去。 三者其实是同一件事在不同「仪式感」下的叫法，真正制造混乱的，是同一个团队里三种词混着用。
这些区别在聊天里不重要，但在三个地方会直接影响钱和结论：你度量什么、合同里承诺什么、以及你要求报障人填什么。 这篇给一套能写进术语表、从此不用再争的分法。
一句话版本
| 术语 |
范围 |
常见场景 |
| Bug |
Defect 的口语词。通常指「以前能用」或「显然应该能用」的地方坏了 |
站会、聊天群、「结算页有个 bug」 |
| Defect（缺陷） |
正式术语：实际行为与预期行为之间的任何偏离，无论它曾经是否正常 |
QA 报告、审计、合同、度量 |
| Issue（问题/事项） |
伞词：任何需要决策的事项——缺陷、需求、任务、疑问 |
工具里的单号、发布说明 |
| Error（错误） |
人的行为导致了不正确的结果 |
根因分析、复盘 |
| Fault（故障/缺陷点） |
软件内部那段错误的指令或数据，是失败的成因 |
工程讨论、标准文档 |
| Failure（失效） |
可观测到的事件：系统没有做到它该做的 |
事故复盘、监控告警 |
只记一句：error → fault → failure 是一条因果链，而 defect 是你登记下来的那个东西（通常就是 fault），bug 是大家嘴上说的那个词。
因果链：Error / Fault / Failure
这套模型在标准和复盘里一直用得上：
Error（错误）：人犯了错——需求理解偏了、假设错了、检查跳过了。
Fault（缺陷点）：这个错变成了代码、配置或数据里一个具体的问题。
Failure（失效）：在特定条件触发下，用户看得见结果——页面白了、金额算错了、保存在无声中失败。
这条链解释了为什么「人为失误」永远不能单独作为根因：它只说明缺陷是怎么来的，没解释它为什么能上线。至于怎么给这些缺陷定级和排序，看缺陷分诊指南。
为什么工具里更适合叫 Issue
一个台账装的东西远不止缺陷。把对象定义为 issue（或保留 bug 作为口语），你才能在一处装下：
- feature request：行为本来就是缺的，是想要；
最大的坑是「只有 bug 一种类型」的台账。团队会把需求当 bug 提进去抢队列位置，于是你的缺陷度量被永久污染——你再也分不清质量是在变好，还是大家只是换了个标签。
如果你正在选工具，问题跟踪系统选型指南讲的是更外层的标准；只关心 QA 生命周期的话，看缺陷管理软件对比。
三个「叫对了能省钱」的场合
1. 合同与 SLA。 一份承诺「严重缺陷 24 小时内修复」的支持协议，必须附上 defect 和 critical 的书面定义。没有定义，每次讨论都变成谈判。合同里写「bug」通常模糊到无法执行。
2. 度量。 缺陷密度、逃逸率、重开率只有在统计口径稳定时才有意义。如果一半「bug」其实是需求，这些数字全部作废。
3. 审计与合规。 受监管的产品通常需要可追溯的缺陷记录：严重级、验证证据、关闭依据。这是正式产物，用 defect 这个词本身就在提示它的正式性。
Bug 还是需求？
最容易吵起来的分界线：
| 属于缺陷，如果…… |
属于需求，如果…… |
| 行为与书面要求或已确认的设计相矛盾 |
没有对应要求，这个行为从未被承诺过 |
| 用户做不成以前能做成的事 |
用户能完成，只是不是他偏好的方式 |
| 系统状态变得不一致，或数据丢失 |
系统是一致的，只是输出不是某人想要的 |
| 涉及可访问性、安全或数据完整性 |
只是布局、文案、流程上的偏好 |
真正难判的是「约定俗成」那一类：一个禁用的按钮点下去毫无反馈，在多数设计体系里算缺陷，哪怕需求文档没写。这类边界必须用书面规则定下来，否则每个迭代都要重吵一次。
Bug 还是「报错」？
屏幕上出现一条 error 提示，本身不是缺陷。「邮箱格式不正确」的校验提示是正确行为。缺陷是：提示内容错了、该提示时没提示、或不该提示时提示了。而「Console error」里的 error，指的是运行时打出的异常——它可能是缺陷，也可能完全是被正常捕获处理的预期情况。这也正是为什么报告要附上 Console 原文而不是拍一张截图：定级的人需要文本、堆栈和出现频次，不是一张图。
选一套词，写下来
大多数团队能落地的方案：
- Defect 是「行为错误」这个类型，也是度量、合同、报告里用的词。
- Error / Fault / Failure 只在根因分析里按这个顺序使用。
然后把这五行写进 QA 文档的术语表，连同上面那条「缺陷 vs 需求」的判定规则。目的不是语言洁癖，而是：只有术语稳定，报告才能复用，指标才能跨月比较。
这对报告本身意味着什么
不管你怎么叫，定级的人需要的字段是一样的：
这就是「两分钟能定级」和「十五分钟审讯」的差别。逐字段的写法看Bug 报告格式，第一行怎么写得可搜索看标题示例。
常见问题
Bug 和 defect 是一回事吗？
日常使用中就是一回事。严格说，defect 是对「偏离预期行为」的定义，bug 是它的口语名。合同和审计用 defect，因为可定义；团队说 bug，因为短。
Defect 和 failure 是一回事吗？
不是。Defect 是软件里存在的缺陷；failure 是它在合适条件下被执行时、可被观察到的事件。一个缺陷可以在代码里躺几年，一次都没触发过 failure。
工具里该叫 bug 还是 issue？
对象叫 issue，把 defect 作为一种类型。只有「bug」一种类型的台账，会逼着需求混进缺陷队列，最终毁掉质量度量。
Error 放在哪？
Error 是「人的行为引入了缺陷」，它是原因，不是工单类型。把「人为失误」当根因，会让分析提前一步停下。
需要用工具强制这套分类吗？
轻量即可。一个必填的「类型」字段，加上缺陷与需求的书面判定规则就够了。分类再细，通常只会更完整地记录错误的东西。