缺陷记录读起来主观，通常源于两处缺口：期望结果没有可引用的来源，实际结果缺少可核对的证据。把记录拆成期望结果、实际结果、差异三个字段，分别规定取源、取证和对照写法，第三方按同样步骤就能复现并给出是或否的判断。下面给出可直接套用的字段规则、句式模板、角色分工和检查清单，并说明这类字段与证据在缺陷管理工具中如何承载。
要点总览（TL;DR）
- 期望结果从验收标准、需求条目、设计说明中取用，按贴近程度排序，引用原文并标注文档名与条款号，让判定有据可查。
- 实际结果只写环境、前置数据、操作步骤和观察到的现象或数值，用截图、日志、接口返回作为证据，把“卡顿”“异常”替换为可度量描述。
- 差异用“依据条款—期望值—实际值—偏差表现”的对照句写出，一条缺陷只对应一条偏差，多个问题拆分为多条缺陷。
- 提交人、评审人、开发各有记录职责：提交人负责取源与取证，评审人按可复现性检查，开发复现失败时补充环境差异而非改写现象。
- 达标判据是第三方按记录操作能复现同一现象并得出相同结论，提交前按检查清单逐项核对。
先定判定依据：期望结果从哪里取
期望结果回答的是“按什么标准判断这是缺陷”。它必须能指向一份可查阅的文档条款，而不是提交人凭经验写下的“应该正常显示”。来源不明确，后续实际结果再详细也无法形成判定。
三个合法来源与取用顺序
期望结果优先从以下三类材料中取用，按顺序选择最贴近当前功能的那一份：
- 验收标准：与当前功能直接对应、写明判定条件的条目，优先级最高，因为它本身就是为判定而写的。
- 需求条目：验收标准未覆盖时，取需求文档中描述该功能行为、数值或状态的条款。
- 设计说明：前两者都未涉及、而实现依赖具体设计约定时（如字段长度、接口返回结构、页面跳转规则），取设计文档中的对应描述。
三类来源出现冲突时，以评审通过时间更晚、且经需求方确认的版本为准，并在缺陷记录中写明所依据的文档版本号。冲突本身值得单独提出，但不要在缺陷描述里展开讨论，避免把判定依据写成争议过程。
写成可判定的单句
一条期望结果应包含对象、条件、预期值三个要素，读完后能直接回答“满足还是不满足”。引用时保留原文关键措辞，标注来源编号，不做概括性转述。
| 写法 | 示例 | 问题 |
|---|---|---|
| 不可判定 | 订单列表应该正常显示分页 | “正常”无标准，无法判断对错 |
| 可判定 | 依据《订单管理验收标准》AC-07：订单列表每页显示20条，超过20条时显示下一页按钮 | 对象、条件、预期值齐全，可核对 |
| 转述走样 | 需求里说分页要每页二十条左右 | “左右”改变了原文口径 |
来源编号建议采用“文档名+条款号”的形式，例如“AC-07”“REQ-ORDER-112”。编号的作用是让评审人和开发不必猜测提交人看的是哪一版材料。
实际结果只写可观察事实：字段与写法
实际结果记录“我做了什么、看到了什么”，不记录“我觉得哪里不对”。判断标准很简单：换一个人按记录操作，能否看到同样的现象或数值。
实际结果的必备字段
- 环境：应用版本、浏览器或客户端版本、操作系统、测试环境地址或数据集标识。
- 前置数据：账号角色、订单数量、配置项取值等复现所依赖的数据状态。
- 操作步骤：按顺序编号，每步一个动作，包含输入值。
- 观察到的现象或数值：页面显示内容、接口返回码与字段值、日志片段、耗时数值。
- 证据附件：截图、日志文件、接口返回报文、录屏，附件命名与步骤编号对应。
字段齐全后，实际结果就具备了被复核的基础。缺环境或缺前置数据，是复现失败最常见的原因。
把主观词替换为可度量描述
| 主观写法 | 替换为 |
|---|---|
| 页面卡顿 | 点击“查询”后，列表在12秒后返回；同一操作在测试环境平均耗时1.5秒（附录屏与浏览器性能面板截图） |
| 数据显示异常 | 订单号20240612-0031的“应付金额”显示为0.00，订单明细中商品金额合计为128.00 |
| 接口返回不对 | 调用GET /api/orders/20240612-0031返回HTTP 200，响应体totalAmount字段为0，与明细合计128.00不一致（附返回报文） |
| 偶尔失败 | 按步骤连续执行10次，其中3次出现上述现象，7次正常（附3次失败的时间点与截图） |
“卡顿”“异常”“不对”“偶尔”这类词本身不构成观察结果，它们是对观察的概括。记录时应回到原始现象：看到了什么数字、什么提示、什么返回内容。
区分一次观察与多次复现
只出现一次的现象，写明“执行1次，出现1次”，并保留当时的日志与截图，不写“必现”。多次执行的结果用“执行次数/出现次数”表达，例如“10次中3次”，同时记录失败发生的时间点，便于开发对照日志。复现概率是观察统计，不是推测，写清楚统计口径即可。
差异怎么对应：一条缺陷只写一条偏差
差异字段把期望与实际接上，写法是一句对照：依据哪条标准、期望是什么、实际是什么、偏差表现在哪里。它只描述不一致本身，不解释原因，也不判断是谁的责任。
差异句结构
推荐句式：“依据〔来源编号〕，〔对象〕在〔条件〕下应为〔期望值〕，实际为〔实际值〕，表现为〔偏差现象〕。”
示例：依据AC-07，订单列表在结果超过20条时应显示下一页按钮，实际订单共35条时未显示下一页按钮，列表仅展示前20条且无法翻页。
这句话包含四个可核对要素：条款、期望值、实际值、偏差表现。评审人读完即可判断是否成立，无需再追问。
多个偏差拆分为多条缺陷
一次操作中发现分页按钮缺失、金额显示为0两个问题，应拆成两条缺陷，各自引用对应条款、各自附证据。合并成一条会让修复验证无法逐项关闭，也会让严重程度难以分级。拆分规则可以概括为：一条缺陷对应一个可独立判定的偏差，对应一条验收条款或需求条目。
差异描述中不写“开发漏了判断”“可能是缓存问题”这类原因推测和责任判断。原因分析放在缺陷评论或关联的技术分析记录中，与差异描述分开，避免推测污染判定依据。
差异与严重程度分开记录。差异字段回答“哪里不一致”，严重程度按团队既有的分级规则另行评定，两者依据不同，不要在一句话里混写。
角色分工与提交前自检
记录质量由提交、评审、复现三个环节共同保证，每个角色有明确的交付物。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 提交人（测试或需求人员） | 引用期望来源编号，填写环境、步骤与观察事实，附证据，写出单条差异句 | 字段完整的缺陷记录与附件 |
| 评审人或测试负责人 | 按可复现性检查：来源是否可查、步骤是否可执行、证据是否对应、差异是否只有一条 | 通过检查的记录，或退回补充的具体意见 |
| 开发 | 复现失败时补充自己使用的环境、数据与操作差异，说明在哪一步与记录不同 | 环境差异说明，附复现尝试的日志 |
开发复现失败时，正确的动作是补充信息而非改写现象。把“未复现”写成“无此问题”，会让记录失去追溯价值；写明“在Chrome 126下按步骤执行3次均正常，与记录中的浏览器版本不同”，则把分歧定位到了环境变量上。
缺陷状态流转中，记录补充义务随状态延续：修复提交时注明修改的代码范围或配置项；验证时补充验证环境与验证结果；关闭前确认差异句中的实际值已变为期望值。每次状态变更都留下可核对的信息，缺陷记录才具备完整生命周期。
这些字段、附件和状态流转需要有承载位置。在ONES中，缺陷工作项可配置期望结果、实际结果、差异描述等字段，截图与日志作为附件随记录保存，状态流转与评论保留每次补充的环境信息和验证结论，评审人可直接在记录上完成提交前检查。
完整示例：从需求条款到差异记录
以下为演示情景，用于说明三个字段如何对应，不代表任何真实项目数据。
来源条款
需求条目REQ-ORDER-112：订单列表支持分页，每页20条。验收标准AC-07：订单总数超过20条时，列表底部显示“下一页”按钮，点击后展示第21条及之后的订单。
按字段填写的记录
- 期望结果：依据AC-07，订单总数超过20条时，列表底部显示“下一页”按钮，点击后展示第21条及之后的订单。
- 环境：测试环境，应用版本v2.4.1，Chrome 126，账号角色为普通运营。
- 前置数据：账号下订单共35条，状态均为已完成。
- 操作步骤：1. 登录测试环境；2. 进入“订单管理”页；3. 不设置筛选条件，点击“查询”；4. 滚动至列表底部查看。
- 观察到的事实：列表展示20条订单，底部无“下一页”按钮，页面无翻页控件；接口GET /api/orders?page=1返回total=35、pageSize=20（附返回报文与页面截图）。连续执行3次，3次结果一致。
- 差异：依据AC-07，订单总数35条超过20条时列表底部应显示“下一页”按钮并可翻页，实际未显示该按钮，第21至35条订单无法查看。
拆分出的第二条缺陷
同一场景下若还发现第3条订单的金额显示为0.00，应另立一条缺陷，引用金额相关的验收条款，附该订单明细截图与接口返回，差异句只描述金额不一致这一条偏差。
主观写法与规范写法对照
| 主观写法 | 规范写法 |
|---|---|
| 订单列表分页有问题，翻不了页，麻烦看下 | 依据AC-07，订单35条时未显示“下一页”按钮，第21至35条无法查看；环境v2.4.1/Chrome 126，步骤与接口返回见附件 |
| 金额显示不对，应该是128 | 依据AC-12，订单20240612-0031应付金额应为明细合计128.00，实际显示0.00；附明细截图与接口报文 |
完成检查：这条缺陷记录能否被第三方判定
提交前按以下清单逐项核对，全部满足即可认为记录达标。
- 期望结果引用了需求、设计或验收标准的具体编号，编号可在文档中查到对应原文。
- 期望结果包含对象、条件、预期值，读完后能直接判断满足或不满足。
- 实际结果写明了环境、前置数据、操作步骤和观察到的现象或数值。
- 截图、日志或接口返回等证据与步骤对应，能支撑所写的现象。
- 多次执行的结果注明了执行次数与出现次数，未使用“偶尔”“必现”等无口径表述。
- 差异句只描述一条偏差，包含条款、期望值、实际值和偏差表现。
- 差异描述中不含原因推测和责任判断。
- 严重程度按团队分级规则单独记录，未与差异描述混写。
- 换一位同事按记录操作，能复现同一现象并得出相同结论。
其中最后一条是整体判据：前八项是手段，第三方可复现、可判定才是目的。若某条记录在复现环节出现分歧，优先检查环境与前置数据是否写全，再检查期望来源是否为同一版本，这两处通常是分歧的来源。
常见问题
需求文档和验收标准对同一功能的描述不一致时，期望结果以哪个为准？
以评审通过时间更晚、且经需求方确认的版本为准，并在缺陷记录中写明所依据的文档版本号。验收标准通常为判定而写，优先级更高；当它与需求条目冲突时，说明两份材料存在版本差，冲突本身值得单独提出，但不要在缺陷描述里展开讨论，避免把判定依据写成争议过程。
开发按记录操作后无法复现，缺陷应该怎么处理？
开发应补充自己使用的环境、数据与操作差异，说明在哪一步与记录不同，并附复现尝试的日志，而不是把“未复现”写成“无此问题”。提交人收到环境差异说明后，核对记录中的浏览器版本、数据集或配置项是否写全，必要时补充缺失字段。分歧通常出在环境与前置数据上，把这两处写清楚，复现结论才能对齐。
一次操作中发现多个问题，是合并成一条缺陷还是拆开写？
拆开写。一条缺陷对应一个可独立判定的偏差，对应一条验收条款或需求条目。合并成一条会让修复验证无法逐项关闭，也会让严重程度难以分级。拆分后每条缺陷各自引用对应条款、各自附证据，差异句只描述本条的偏差。
现象只出现过一次，实际结果里怎么写才不算主观？
写明“执行1次，出现1次”，并保留当时的日志与截图，不写“必现”。多次执行的结果用“执行次数/出现次数”表达，例如“10次中3次”，同时记录失败发生的时间点，便于开发对照日志。复现概率是观察统计，写清楚统计口径即可，不需要推测原因。
缺陷记录里的严重程度应该和差异描述写在一起吗？
分开记录。差异字段回答“哪里不一致”，严重程度按团队既有的分级规则另行评定，两者依据不同。把分级结论混进差异句，会让判定依据和优先级判断纠缠在一起，评审时难以区分哪部分是事实、哪部分是评级。分级规则本身属于缺陷分类与分级的主题，本文不展开。
