缺陷记录里，期望结果和实际结果写到什么粒度才够用，关键看另一位同事能否按同一条操作路径独立复现，并据此判断“确实不符合预期”。期望结果要写到可判定的具体行为或数值，实际结果要写到可复现的观察证据，差异则落到最小可定位的偏离点。本文围绕缺陷提交与信息规范，解释三者的含义、粒度标准、在缺陷单中的组织方式，以及容易混淆的相邻概念。
要点总览（TL;DR）
- 期望结果是依据需求、设计或规则应当出现的行为与数据；实际结果是缺陷发生时系统真实呈现的行为与数据；差异是两者在同一操作、同一输入、同一观察点上的比对结论。
- 粒度总标准是他人能否在同一操作路径和判断口径下独立复现并判定：期望写到可用“是/否”判定的具体行为或数值，实际写到可复现的观察证据，差异写到最小可定位的偏离点。
- 缺陷单中先写前置条件与操作步骤作为公共场景，期望与实际分栏对照，差异紧随其后，截图和日志就近挂接到对应描述。
- 常见写法问题包括期望写“功能正常”、实际结果混入推测原因、差异与原因分析混写；观察、比对、分析三段分开，记录才便于评审。
- 复现步骤描述操作路径，严重程度判定属于缺陷分类与分级，服务事件受理归服务事件与问题管理，这些都不应写进期望结果或实际结果字段。
期望结果、实际结果和差异分别指什么
期望结果是缺陷发生之前，依据需求、设计文档或既定业务规则，系统“应当”呈现的行为与数据。它回答的是“按约定应该怎样”，来源可以是需求条目、接口约定、设计稿、业务规则说明，也可以是测试用例中已经写明的预期。期望结果带有依据属性：写它的时候，最好能指向某条需求或某条规则，这样后续判断才有共同基准。
实际结果是缺陷发生时，系统真实呈现的行为与数据。它来自实际观察，而不是推测。观察方式包括在指定环境、指定账号、指定数据下执行操作后看到的页面反馈、接口返回、日志输出、数据库记录等。实际结果回答的是“现在实际怎样”，它的可信度取决于观察是否可重复：换一个人按同样条件操作，应当看到同样的现象。
差异是期望结果与实际结果在同一操作、同一输入、同一观察点上的比对结论。它本身不是独立事实，而是把两者放在一起后得出的落差描述。比如期望“提交后订单状态变为已支付”，实际“提交后订单状态仍为待支付”，差异就是“订单状态未按预期从待支付变为已支付”。差异必须依附于前两者存在，单独写一句“状态不对”无法构成可比对的差异。
三者共用同一条操作路径和判断口径，是它们能够比对的前提。如果期望结果描述的是页面 A 的按钮行为，实际结果记录的却是页面 B 的报错，两者就不在同一观察点上，差异也无从谈起。因此写缺陷时，先固定前置条件、操作步骤和观察点，再分别填写期望与实际，最后归纳差异，这个顺序能有效避免“各说各话”。
记录粒度到什么程度算合适
合适的粒度有一条总标准：他人能否在同一操作路径和判断口径下独立复现并判定。达到这条标准，记录就够用；明显超出复现和判定所需，就是过细；不足以让他人做出判断，就是过粗。下面分别说明三者的粒度要求。
期望结果：写到可判定的行为或数值
期望结果要具体到能够用“是/否”判断的程度。行为类期望写清触发条件、对象和结果状态，例如“在收货地址为空时点击提交，页面提示‘请填写收货地址’且不生成订单”。数值类期望写清字段、单位和边界，例如“优惠券满 100 减 20，订单金额 120 元时应付 100 元”。涉及多个判断点时，逐条列出，避免用“正常”“正确”“符合预期”这类无法判定的表述收尾。
实际结果：写到可复现的观察证据
实际结果要写到别人照着步骤能观察到同样现象。描述应包含观察到的具体反馈：页面显示了什么文字、接口返回了什么状态码和字段值、日志里出现了哪条错误、数据表里哪个字段是什么值。必要时附截图、录屏或日志片段作为证据。实际结果只记录“看到了什么”，把“为什么这样”留给原因分析环节，避免在观察描述里混入猜测。
差异：写到最小可定位的偏离点
差异描述要指出期望与实际之间最小的、可定位的偏离。比如期望“提示‘请填写收货地址’”，实际“提示‘系统异常’”，差异就是“提示文案与预期不一致，且未阻止订单生成”。最小偏离点的作用是让修复者一眼看到问题落在哪个环节，而不必重新比对整段期望和实际。差异写到这个程度即可，继续往下追根因属于原因分析，不属于差异描述本身。
过粗与过细的识别
过粗的典型表现是：期望写“功能正常”，实际写“报错了”，差异写“不符合需求”。这类记录无法复现，也无法判定，接手人只能回头找提交者追问。过细的典型表现是：把整篇需求文档复制进期望结果，把完整日志全文贴进实际结果，或者在差异里展开大段根因推理和修复建议。过细会增加阅读负担，也会让关键偏离点被淹没。判断办法仍然是那条总标准：复现和判定需要的信息保留，超出这个范围的内容移到附件或原因分析中。
| 项目 | 定义 | 粒度要求 | 常见错误 |
|---|---|---|---|
| 期望结果 | 依据需求、设计或规则应当出现的行为与数据 | 写到可用“是/否”判定的具体行为或数值 | 写“功能正常”“符合预期”等空泛表述；整段照抄需求原文 |
| 实际结果 | 缺陷发生时系统真实呈现的行为与数据 | 写到他人按步骤可观察到同样现象，附必要证据 | 只写“报错”“不对”；把推测原因写进观察描述 |
| 差异 | 期望与实际在同一观察点上的比对结论 | 写到最小可定位的偏离点 | 写“不一致”却不指明偏离在哪；与原因分析混写 |
一条缺陷记录中三者如何组织
缺陷单的结构应当让读者先建立共同场景，再看到两边的对照，最后落到偏离点。常见的组织顺序是：前置条件与操作步骤作为公共部分放在前面，期望结果与实际结果分栏或分段书写，差异紧随其后，证据挂接到对应描述旁边。
前置条件和操作步骤是三者共用的场景基础。前置条件写清环境、账号、数据状态，操作步骤写清按什么顺序做了什么。这部分只描述路径，不夹带观察结论。把公共部分前置，可以避免在期望和实际里重复交代“在什么情况下操作”。
期望结果与实际结果分栏书写的理由在于可比对。分栏后，读者可以逐条对照同一观察点上的两边内容，差异也更容易被识别。如果混在一段叙述里，期望和实际容易交织，判断口径也会模糊。分栏不要求格式完全对称，但应保证两边描述的是同一操作、同一观察点。
差异描述要与复现步骤衔接。读者看完步骤和两边结果后，差异应当直接指出“在哪一步、哪个观察点上出现了偏离”。这样差异既是比对结论，也是复现时的关注点。差异之后可以进入原因分析或修复建议，但这部分内容应与差异描述分开，保持观察与推断的边界。
截图、日志等证据挂在对应描述的位置，而不是集中堆在文末。期望结果旁可以放需求截图或规则说明，实际结果旁放现象截图、接口返回或日志片段。证据与描述就近挂接，能减少读者来回翻找，也让每条证据服务于一个具体判断点。
在缺陷单需要多人填写和评审的团队里，这类字段的组织方式可以借助工作项承载。ONES Project 适配缺陷管理等场景，支持一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况；ONES TestCase 中未通过的用例可快速创建缺陷任务，使缺陷在测试与研发团队间流转。团队可以把前置条件、步骤、期望、实际和差异按上述顺序填入缺陷工作项，让提交、评审和修复围绕同一份记录推进。
与复现步骤、严重程度等相邻概念的区别
复现步骤描述的是操作路径，结果描述的是观察内容，两者职责不同。步骤回答“怎么做才能看到”，结果回答“看到了什么、应该看到什么”。步骤写得再详细，也不能替代期望与实际；反过来，结果写得再清楚，缺少可执行步骤仍然难以复现。规范的做法是步骤只写操作，结果只写观察，各司其职。
严重程度判定属于缺陷分类与分级，不在本文讨论范围。期望结果和实际结果解决的是“问题是什么、偏离在哪”，严重程度解决的是“这个问题影响多大、应优先处理到什么程度”。两者依据不同：前者依据观察与比对，后者依据影响范围、业务后果等分级规则。把分级判断塞进结果描述，会让记录混杂，也不利于后续统计。
服务事件受理归服务事件与问题管理，与缺陷记录的结果描述属于不同管理环节。服务事件关注的是服务请求的接收、响应和闭环，缺陷记录关注的是产品行为与预期的偏离。两者可能相互引用，但受理流程和分级规则不应写进期望结果或实际结果字段。
期望结果不等于需求原文照抄。需求原文往往包含背景、范围和多种场景，直接复制进缺陷单会让判断点变得模糊。期望结果应当是从需求中提炼出的、针对当前操作和观察点的可判定表述。照抄原文看似有依据，实际增加了读者的筛选成本，也容易掩盖真正的偏离点。
具体例子与常见误解
下面用一条完整示例示范合适的粒度。场景为演示用途，便于说明写法。
前置条件：测试环境，普通用户账号，购物车中有一件库存充足的商品。操作步骤：进入结算页，不填写收货地址，点击“提交订单”。期望结果：页面提示“请填写收货地址”，订单不生成，购物车商品保留。实际结果：页面提示“系统异常，请稍后重试”，订单未生成，但购物车被清空。差异：提示文案与预期不一致；提交失败后购物车商品被清空，与“商品保留”的预期不符。证据：结算页提示截图、提交前后购物车截图各一张。
这条示例中，期望写到可判定的提示文案和订单、购物车状态，实际写到可观察的提示与状态变化，差异落到两个最小偏离点，证据就近挂接。另一位同事按步骤操作，能够独立复现并判断是否符合预期。
常见误解之一是把期望写成“功能正常”一类空泛表述。这类写法没有给出判断依据，接手人无法知道“正常”具体指什么。纠正办法是把“正常”拆成具体行为或数值，必要时指向对应需求条目。
常见误解之二是把实际结果写成推测原因，例如“实际结果：因为地址校验逻辑缺失导致报错”。观察描述里出现“因为”，往往已经进入原因分析。纠正办法是只写看到的提示、状态和数据，把原因判断移到分析环节。
常见误解之三是差异描述与原因分析混写，例如“差异：开发漏了地址校验，需要补上”。差异应停留在偏离点本身，修复建议和根因判断另起一段。保持观察、比对、分析三段分离，缺陷记录才既清楚又便于评审。
常见问题
期望结果必须逐字引用需求原文吗？
不需要逐字引用。需求原文常包含背景、范围和多个场景，直接复制会让判断点变模糊。更合适的做法是从需求中提炼出针对当前操作和观察点的可判定表述，例如写明触发条件、对象和结果状态，并在需要时标注对应的需求条目，方便评审时回溯依据。
实际结果里能不能写初步判断的原因？
建议把原因判断放到原因分析环节。实际结果只记录观察到的现象，例如页面提示文字、接口返回的状态码与字段值、日志中的错误条目、数据表里的字段值。观察与推断分开写，接手人才能先独立复现现象，再讨论根因，避免推测影响对问题本身的判断。
同一缺陷涉及多个偏离点时，差异要合并成一条写吗？
可以按观察点逐条列出，不必强行合并。每个偏离点对应一个可定位的环节，逐条写便于修复者分别确认。若偏离点较多，可先写主要偏离，其余在附件或补充说明中展开。关键是每条差异都能对应到期望与实际中的同一观察点，保持可比对。
团队如何约束缺陷记录的粒度，避免提交过于空泛？
常见做法是在缺陷模板中固定前置条件、操作步骤、期望结果、实际结果、差异几个部分，并在评审环节检查是否达到“他人可独立复现并判定”的标准。ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代并记录修复情况；ONES TestCase 中未通过的用例可快速创建缺陷任务，让测试与研发围绕同一份记录流转。字段是否必填、模板如何配置，需按团队实际使用情况确定。
期望结果和验收标准是一回事吗？
两者相关但用途不同。验收标准通常面向需求或用户故事，描述整体交付需要满足的条件；期望结果面向一条具体缺陷，聚焦当前操作和观察点上应当出现的行为或数值。写缺陷时可以从验收标准中取用相关条目，再收窄到本次操作对应的判断点，避免把整条验收标准搬进缺陷单。
