缺陷期望结果写得含糊，往往不是表达问题，而是写之前没有找到可追溯的判定依据。本文从需求条目、验收标准和设计说明中提取判定点，给出可判定的句式模板、期望与实际结果的对照记录方式，以及提交前的自查和评审分工，帮助缺陷记录能被复现、评审和关闭。
要点总览（TL;DR）
- 期望结果要能指回需求条目、验收标准或设计说明的原文，依据缺失时先澄清需求，不凭经验补写。
- 用“前置条件、操作对象、执行动作、可观测结果”四要素组织句子，把“正常”“正确”换成具体数值、状态、字段值或提示文案。
- 一条期望结果只对应一个判定点，多个判定点分行列出，实际结果按同一口径逐项对照，差异只写偏离内容。
- 提交人负责写、需求负责人确认依据、开发核对差异、评审人检查可追溯与可观测，提交前按依据、句式、数值、拆分、证据、对应六项自查。
- 验收标准本身要写到可观测的粒度，原文只有“需校验”这类描述时，先推动标准细化再写缺陷期望结果。
先找判定依据：期望结果从哪里来
期望结果不是写缺陷的人凭经验想出来的，它应当能在需求、设计或验收文档中找到对应原文。写之前先定位依据，再从中抽取判定点，是让期望结果可判定的第一步。找不到依据时，正确动作是回到需求澄清，而不是用个人理解补写。
常见依据类型和可提取的判定点如下：
| 依据类型 | 可提取的判定点 | 引用方式 |
|---|---|---|
| 需求条目 | 业务规则、字段取值范围、状态流转条件 | 需求编号 + 条目名称 |
| 验收标准 | 给定条件、操作、预期输出 | 验收标准条目编号 |
| 设计说明 | 页面元素、交互顺序、异常处理方式 | 设计文档章节号 |
| 接口约定 | 请求参数、返回码、字段结构与取值 | 接口文档名称 + 接口路径 |
| 原型标注 | 提示文案、按钮状态、必填项、默认值 | 原型页面名称 + 标注编号 |
抽取判定点时，优先找能被观察和核对的内容：一个数值范围、一个状态值、一句提示文案、一个字段是否必填。需求里写“支持批量导入”属于功能描述，验收标准里写“单次最多导入 500 条，超出时提示‘单次导入不能超过 500 条’”才是可判定的判定点。
依据缺失的处理要形成固定动作：记录缺失的是哪一条规则、影响哪个判定点，向需求负责人提出澄清，澄清结论补入需求或验收标准后再写期望结果。缺陷记录中标注依据来源，例如“依据：验收标准 AC-03”“依据：接口文档 3.2 节返回码约定”，评审人才能快速核对期望结果是否站得住。
当需求、验收标准和设计说明对同一行为描述不一致时，以评审确认的版本为准，并在缺陷中写明采用的依据和冲突点，避免开发与测试各按一份文档理解。
把期望结果写成可判定的句式
可判定的期望结果通常包含四个要素：前置条件、操作对象、执行动作、可观测结果。四要素齐全，任何人按同样步骤操作都能得到同样的判断结论。
可直接套用的句式模板：
- 在【前置条件】下，对【对象】执行【操作】，应【可观测结果】。
- 当【输入数据】提交时，【对象】应显示/返回【具体值或文案】。
- 【对象】处于【状态】时，【操作入口】应【可用/不可用/显示指定提示】。
把主观词替换成可核对的内容，是改写的核心动作：
- “提示信息正确”改为“页面顶部显示提示文案‘手机号格式不正确’，输入框边框变为红色”。
- “金额计算正常”改为“订单金额为 199.00 元、优惠 20.00 元时，应付金额显示 179.00 元”。
- “列表展示合理”改为“列表按创建时间倒序排列，每页显示 20 条，分页控件显示总条数 137”。
一条期望结果只对应一个判定点。当验收标准同时约束字段校验、提示文案和按钮状态时，拆成三行分别写，实际结果也按三行对应记录，评审时才能逐项确认哪一项偏离。
改写前后对照示例：
| 改写前 | 改写后 |
|---|---|
| 导出功能正常 | 在订单列表筛选“已支付”状态后点击导出，应生成包含当前筛选结果的 Excel 文件，文件名格式为“订单导出_YYYYMMDD.xlsx”，行数与列表总条数一致 |
| 密码错误提示友好 | 输入已注册手机号和错误密码点击登录，应停留在登录页，密码输入框下方显示“账号或密码错误”，连续错误 5 次后按钮置灰 60 秒 |
| 审批流程正确 | 金额 8000 元的报销单提交后，审批流应流转至部门经理节点，状态显示“待部门经理审批”，部门经理账号的待办列表中出现该单据 |
改写时保留依据中的原始数值和文案，不自行换算或润色。提示文案以原型标注或需求原文为准，逐字引用，标点和空格也纳入判定范围。
实际结果与差异的对应记录
实际结果按与期望结果相同的口径记录，才能形成可对照的差异。记录内容包括复现步骤、测试环境、输入数据和观察到的现象，现象描述同样使用具体数值、状态和文案。
推荐使用三列对照格式：
| 期望结果（判定点） | 实际结果 | 差异说明 |
|---|---|---|
| 应付金额显示 179.00 元 | 应付金额显示 199.00 元 | 优惠金额未从应付金额中扣除，差额 20.00 元 |
| 提示文案为“手机号格式不正确” | 提示文案为“请输入正确的手机号” | 文案与验收标准 AC-05 不一致 |
| 导出文件行数与列表总条数一致 | 列表 137 条，导出文件 100 行 | 导出结果被截断，缺少 37 行 |
证据按判定点取舍：界面文案和状态差异附截图并圈出位置；金额、条数等数据差异附输入数据和返回报文；流程流转问题附操作录屏或状态变更日志。证据服务于让评审人独立复现，不必堆砌全部截图。
实际结果中只写观察到的现象，原因推测放到备注或评论中单独说明。把“疑似缓存未刷新导致金额错误”写进实际结果，会干扰评审人对现象本身的判断，也可能把排查方向带偏。
缺陷记录需要同时承载依据引用、期望与实际对照和评审流转时，可以把需求条目、验收标准文档与缺陷工作项放在同一协作环境中。ONES Project 支持缺陷跟踪管理，与 TestCase 数据互通并可一键提 Bug，缺陷可提交至对应项目或迭代；ONES Wiki 支持文档关联任务，便于把验收标准条目与缺陷记录相互引用。具体字段配置以实际环境为准。
角色分工与提交前自查
期望结果的质量由提交人负责，依据的准确性由需求负责人确认，开发在修复前核对期望与实际差异，测试负责人组织评审。职责清晰，退回和返工就会减少。
| 角色 | 在期望结果确认中的职责 |
|---|---|
| 提交人（测试或发现问题的成员） | 定位判定依据，按句式写出期望结果，记录实际结果与差异，附证据 |
| 需求负责人 | 确认依据条目有效，澄清缺失或冲突的规则，确认期望结果与需求意图一致 |
| 开发 | 修复前核对差异项，对期望结果有异议时提出并附依据，不以“设计如此”口头回复 |
| 测试负责人或评审人 | 核对依据是否可追溯、判定点是否可观测、期望与实际是否逐项对应 |
评审时重点看三件事：每条期望结果能否指回具体依据；判定点是否用数值、状态、字段值或文案表达；期望与实际是否按同一判定点一一对应。三项都通过，缺陷才进入修复流程。
提交前自查清单：
- 依据：每条期望结果都标注了需求编号、验收标准条目或设计文档章节。
- 句式：包含前置条件、操作对象、执行动作和可观测结果。
- 数值：金额、条数、时间、状态值、提示文案与依据原文一致。
- 拆分：一条期望结果只对应一个判定点，多个判定点已分行。
- 证据：截图、日志或报文能支撑实际结果的每一项差异。
- 对应：期望、实际、差异三列逐项对齐，没有遗漏或合并。
完整示例：从验收标准到缺陷记录
以下为演示情景，用于说明填写方式，不指向具体系统。
验收标准原文（AC-07）：用户提交报销单时，金额字段必填，取值范围为 0.01 至 50000.00 元，保留两位小数；金额超过 50000.00 元时提示“单笔报销金额不能超过 50000 元”，提交按钮不可点击。
提取出的判定点：
- 金额为空时不可提交，提示必填。
- 金额输入 50000.01 时显示指定提示文案，提交按钮置灰。
- 金额输入 1234.5 时按两位小数处理为 1234.50。
按句式写出的期望结果：
- 在报销单填写页金额为空时点击提交，应停留在当前页，金额字段下方显示“请输入报销金额”，单据不生成。
- 在金额字段输入 50000.01 后，字段下方应显示“单笔报销金额不能超过 50000 元”，提交按钮为不可点击状态。
- 在金额字段输入 1234.5 并失焦后，字段应显示 1234.50，提交后单据金额记录为 1234.50 元。
实际结果与差异对照：
| 期望结果 | 实际结果 | 差异说明 |
|---|---|---|
| 金额为空提交时提示“请输入报销金额” | 提示“金额不能为空” | 文案与 AC-07 不一致 |
| 输入 50000.01 时提示指定文案且按钮置灰 | 提示文案正确，提交按钮仍可点击 | 按钮状态未按规则禁用 |
| 输入 1234.5 失焦后显示 1234.50 | 显示 1234.5 | 未按两位小数格式化 |
这个示例可迁移的规律是：验收标准中的每个条件、每个提示文案、每个状态约束都单独成为一个判定点；实际结果按判定点逐行记录，差异只描述偏离内容。适用边界在于，验收标准本身需要写到可观测的粒度；如果原文只有“金额需校验”这类描述，应先推动验收标准细化，再写缺陷期望结果。
完成检查：什么样的期望结果算写好了
用四项标准判断一条期望结果是否达标：
| 标准 | 通过条件 |
|---|---|
| 可判定 | 结果用数值、状态、字段值、提示文案或界面元素表达，不同人操作得到同一结论 |
| 可追溯 | 标注了需求编号、验收标准条目或设计文档章节，评审人可回查原文 |
| 可复现 | 前置条件、操作步骤、输入数据和环境齐全，他人能按记录重现现象 |
| 单一判定点 | 一条期望结果只约束一个可观测结果，多个判定点已分行列出 |
常见退回原因集中在四类：使用“正常”“正确”“友好”等主观词；缺少依据来源，无法核对期望是否成立；多个判定点混写在一段中，差异无法逐项对应；实际结果没有证据支撑，评审人无法复现。退回时指出具体属于哪一类，提交人按类修改，比笼统要求“补充详细”更有效。
团队层面把方法固化为可复用的资产：在缺陷模板中设置依据来源、期望结果、实际结果、差异说明等填写项；维护验收标准写作样例库，收录判定点拆分得当的条目；定期把退回原因整理成反例清单，在新成员提交前培训中使用。模板和样例随项目迭代更新，保持与当前验收标准写法一致。
常见问题
验收标准只写了“金额需校验”，没有具体数值和提示文案，期望结果还能写吗？
这种情况下先不要直接写期望结果。可以先把缺失的内容列出来：校验的边界值是多少、超出边界时提示什么文案、按钮是否禁用。带着这几个问题找需求负责人澄清，把结论补进验收标准或需求条目，再按补全后的原文写期望结果。
如果时间紧需要先提缺陷，可以在缺陷中写明“依据：验收标准 AC-07，具体边界待澄清”，并把已确认的判定点写清楚，避免用个人理解代替规则。
需求、验收标准和设计说明对同一行为描述不一致时，期望结果以哪个为准？
以评审确认的版本为准，并在缺陷记录中写明采用的依据和冲突点，例如“依据：验收标准 AC-03；设计说明 4.2 节描述与此不一致，已由需求负责人确认以 AC-03 为准”。
这样开发和评审人都能看到判断口径，避免各按一份文档理解。冲突本身也值得单独记录，推动文档后续统一。
实际结果里能不能写“疑似缓存未刷新导致金额错误”这类原因推测？
实际结果只写观察到的现象，原因推测放到备注或评论中单独说明。把推测混进实际结果，会干扰评审人对现象本身的判断，也可能把排查方向带偏。
现象描述同样使用具体数值、状态和文案，例如“应付金额显示 199.00 元，期望 179.00 元，差额 20.00 元”，再附上输入数据和返回报文作为证据。
一个缺陷里发现多个判定点都不符合，应该合并成一条还是拆开提交？
建议按判定点拆分。一条期望结果只约束一个可观测结果，多个判定点分行列出，实际结果也逐行对应，评审时才能逐项确认哪一项偏离、修复到什么程度算完成。
如果多个判定点来自同一条验收标准、由同一处代码改动引起，可以在缺陷描述中说明关联关系，但判定点本身仍分行写，避免差异无法逐项对应。
团队刚推行这种写法，评审时最容易在哪些地方退回？
常见退回集中在四类：使用“正常”“正确”“友好”等主观词；缺少依据来源，无法核对期望是否成立；多个判定点混写在一段中；实际结果没有证据支撑，评审人无法复现。
退回时指出具体属于哪一类，提交人按类修改，比笼统要求“补充详细”更有效。团队可以把退回原因整理成反例清单，在新成员提交前培训中使用。
