缺陷提交规范的关键，是让开发人员拿到记录后无需追问就能判断问题。本文给出一条完整填写的登录失败缺陷示例，逐字段解释写法，并归纳可迁移到不同项目的填写规律与适用边界。示例为演示情景，只讨论缺陷记录本身的质量。
要点总览（TL;DR）
- 一条合格的缺陷记录要让开发无需追问就能判断问题，核心字段是复现步骤、实际结果与预期结果、环境与版本、影响范围。
- 标题按“现象+条件+对象”写，例如“Chrome 120下登录页点击登录无响应”，避免“登录有问题”这类笼统描述。
- 复现步骤写最小可复现路径并标注前置数据（如账号已激活），实际结果与预期结果分开写，预期结果写成可验证的判定条件。
- 这套写法适用于功能缺陷；性能、安全类缺陷需补充专门字段，字段命名与必填项按团队本地规范调整。
- 记录提交后进入评审与流转环节，ONES Project 支持一键提交 Bug 并跟踪修复情况，ONES TestCase 中未通过的用例可快速创建缺陷任务。
这份示例要解决什么问题
本文的示例要达成的目标有三个：可复现、可判断、可交接。可复现指他人按记录中的步骤能再次触发问题；可判断指开发读完实际结果与预期结果后，能直接判断这是否是缺陷、大致在哪个环节；可交接指记录离开提交人之手后，测试、开发、产品之间传递时信息不丢失。
需要说明的是，本文中的登录失败缺陷是演示情景，用于展示字段如何填写，不来自真实客户案例，也不附带实测数据。读者可以把它当作一张填写模板来对照，而不是某个系统的真实缺陷档案。
本文范围限于缺陷记录本身，即一条缺陷从标题到附件的填写质量。缺陷提交之后的严重程度分级、优先级判定方法，以及服务事件受理与问题管理流程，属于另外的话题，本文不展开。阅读方式上，建议先看第二节的完整示例，再回到第三节理解每个字段的写法依据。
完整示例：一条登录失败缺陷的填写
示例背景设定为：某Web系统的登录页，在特定浏览器下点击登录按钮后提交失败，页面停留在原处且无错误提示。以下是一条按常见字段填写的完整缺陷记录。
| 字段 | 填写内容 |
|---|---|
| 标题 | Chrome 120下登录页输入正确账号密码点击登录无响应，页面停留原处 |
| 复现步骤 | 1. 使用测试账号 test_user_01（已激活、密码未过期）登录；2. 打开登录页 /login；3. 在账号、密码框输入正确凭据；4. 点击“登录”按钮；5. 观察页面变化 |
| 实际结果 | 点击后按钮短暂置灰约1秒，随后恢复可点击状态，页面停留在 /login，地址栏未跳转，控制台出现一条 401 响应，页面无任何错误提示 |
| 预期结果 | 点击登录后跳转至首页 /home，页面右上角显示当前登录用户名；凭据正确时不应返回 401 |
| 环境与版本 | 浏览器 Chrome 120.0.6099.71（64位）；操作系统 Windows 11 22H2；构建号 build-20240612-3；测试环境 staging |
| 影响范围 | 当前仅在 Chrome 120 复现，Firefox 121 与 Edge 120 下登录正常；影响所有使用 Chrome 120 访问登录页的用户，阻塞主流程 |
| 附件 | 操作录屏1段（约15秒）、控制台401响应截图1张、请求响应日志片段1份 |
| 优先级建议 | 建议高：登录为进入系统的主路径，Chrome 为常用浏览器，影响面较大 |
这条记录的自洽之处在于：标题中的条件（Chrome 120）、现象（点击无响应）、对象（登录页）与复现步骤、环境字段相互对应；实际结果与预期结果形成可直接对照的一对；影响范围说明了波及的用户与功能，附件提供了可核对的证据。开发拿到这条记录，可以按步骤在相同环境下复现，并直接看到401响应这一线索。
逐项解释：每个字段为什么这样写
标题采用“现象+条件+对象”的结构。示例标题写明了现象（点击登录无响应、页面停留原处）、条件（Chrome 120）、对象（登录页）。常见错误是写成“登录有问题”“登录失败”这类笼统描述，读者无法从标题判断问题范围，也无法在缺陷列表中快速检索。标题不必写全所有细节，但要让读者一眼知道在哪里、什么条件下、发生了什么。
复现步骤要给出最小可复现路径，并写明前置数据。示例中特意标注了测试账号已激活、密码未过期，因为账号状态本身可能就是触发条件；如果省略这一句，开发用自己的账号复现时可能得到不同结果。常见错误是把操作环境、前置准备混进步骤，或步骤写得过粗（如“登录一下”），导致他人无法按图操作。步骤应编号、按时间顺序、每步一个动作。
实际结果与预期结果要分开写，并且可对照。示例的实际结果描述了按钮置灰、页面停留、控制台401、无错误提示四个可观察事实；预期结果写成“跳转至首页、显示用户名、凭据正确时不返回401”这样可验证的判定条件。常见错误是把两者混在一段里，或预期结果写成“应该正常登录”这类无法判定的表述。分开写的好处是评审时可以直接比对差异，定位问题出在跳转、鉴权还是提示环节。
环境与版本是开发复现的前提。示例记录了浏览器具体版本号、操作系统、构建号、测试环境四项。常见错误是只写“Chrome”而不写版本，或漏掉构建号，导致开发在本地环境复现不出。浏览器、系统、构建号、环境这几类信息中，凡是可能影响结果的都应记录；如果团队有固定字段，按字段填即可。
影响范围说明波及的用户与功能，附件提供证据形式。示例的影响范围写明了复现边界（仅Chrome 120）、对比结果（其他浏览器正常）、波及用户（Chrome 120用户）和业务影响（阻塞主流程）。附件选择了录屏、截图、日志三种形式，分别对应操作过程、界面状态和接口响应。常见错误是影响范围只写“影响较大”而不给依据，或附件只放一张截图而缺少可核对的日志。
可迁移规律：换一个缺陷也能照此填写
从上面的示例可以提炼出几条适用于多数功能缺陷的填写规律，换一个缺陷类型也能照此操作。
- 先写清复现路径，再补环境与证据。复现路径是记录的主干，环境与附件是支撑；顺序上先保证他人能按步骤触发，再补充定位信息。
- 用可观察事实描述现象，避免主观判断。写“按钮置灰约1秒后恢复”“控制台出现401响应”，比写“登录好像坏了”“感觉是后端问题”更有用；主观判断可以放在备注里，但不应替代事实描述。
- 把预期结果写成可验证的判定条件。用“跳转至/home并显示用户名”替代“应该能登录”，让评审时能明确比对实际与预期的差异。
- 按团队字段约定补齐必填项。不同团队的字段命名和必填项可能不同，示例中的字段是常见组合，实际填写时以本地规范为准，缺项要补齐而不是留空。
这几条规律的共同点是：每条信息都服务于“让他人无需追问就能判断”。填写时可以自问，开发读完这条记录，还需要问我什么？把答案补进记录，规范就基本到位了。
适用边界与需要调整的情况
本文示例适用于功能缺陷的记录，即界面操作、业务流程、接口返回等可观察的功能异常。性能问题、安全问题需要补充专门字段：性能缺陷通常要记录响应时间、并发量、资源占用等指标；安全缺陷通常要记录复现条件、影响资产、敏感信息范围，并按团队的安全流程处理。直接套用功能缺陷的字段会遗漏关键信息。
不同团队的字段命名与必填项可能不同。有的团队把“环境与版本”拆成浏览器、系统、构建号三个独立字段，有的团队把“影响范围”并入优先级说明。示例给出的是常见组合，实际使用时按本地规范调整字段名称和必填要求，不必照搬字段名。
严重程度与优先级判定不在本文展开。示例中的“优先级建议”只是提交人的初步判断，最终分级通常由团队按既定规则评审确定，提交人不必在记录中完成定级。
记录提交后进入评审与流转，需要与团队流程衔接。缺陷记录不是终点，提交后通常要经过确认、分配、修复、验证等环节。以ONES为例，ONES Project 适配缺陷管理等场景，支持一键提交 Bug 至对应的项目或迭代中，记录和跟踪缺陷修复情况，并可统计缺陷状态分布；在测试环节，ONES TestCase 中未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转。这些能力承接的是记录提交之后的管理动作，填写规范本身仍按本文的字段要求执行。
常见问题
缺陷标题已经写清楚了，复现步骤还需要写前置数据吗？
需要。前置数据往往是触发条件的一部分。示例中标注了测试账号已激活、密码未过期，如果省略这一句，开发用自己的账号复现时可能得到不同结果，反而增加一轮沟通。凡是可能影响结果的状态、数据、权限配置，都建议在步骤中写明。
预期结果写成“应该能正常登录”可以吗？
这类表述无法在评审时直接比对。建议写成可验证的判定条件，例如“点击登录后跳转至 /home，页面右上角显示当前登录用户名，凭据正确时不返回 401”。这样开发可以逐条对照实际结果，快速定位问题出在跳转、鉴权还是提示环节。
性能或安全类缺陷能直接套用这套字段吗？
不建议直接套用。功能缺陷的字段组合覆盖的是可观察的操作异常；性能缺陷通常还需记录响应时间、并发量、资源占用等指标，安全缺陷需记录复现条件、影响资产与敏感信息范围，并按团队安全流程处理。字段可以沿用，但需补充对应类型的专门信息。
提交人需要在记录里直接定级吗？
通常不需要。示例中的“优先级建议”只是提交人的初步判断，最终严重程度与优先级一般由团队按既定规则评审确定。提交人把影响范围写清楚，例如波及哪些用户、是否阻塞主流程，比自行定级更有助于评审。
缺陷提交后如何在系统中流转和跟踪？
记录提交后一般要经过确认、分配、修复、验证等环节。以 ONES 为例，ONES Project 适配缺陷管理等场景，支持一键提交 Bug 至对应的项目或迭代中，记录和跟踪缺陷修复情况，并可统计缺陷状态分布；ONES TestCase 中未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转。填写规范本身仍按本文的字段要求执行。
