缺陷的期望结果与实际结果应记录到什么粒度

缺陷记录里的期望结果和实际结果，写到“第三方能据此复现并判断对错”就够了：期望结果说明在什么条件下应出现什么行为或状态，实际结果按同一口径记录真实表现和关键证据，差异用一句话点明两者在哪个具体点上不一致。三者共用同一观察口径，过粗无法判定，过细会混入实现方案、推测原因等无关信息。

要点总览（TL;DR）

• 期望结果记录到“在什么条件下应出现什么行为或状态”，用可验证的表述给出判断基准。
• 实际结果按同一观察口径记录真实表现，附关键证据和出现频率，不写推测原因。
• 差异用一句话点明两者在哪个具体观察点不一致，不重复期望与实际的完整内容。
• 粒度以“第三方能据此复现并判断对错”为准，过粗无法判定，过细会混入实现方案和无关细节。
• 严重程度判定、原因分析、需求描述属于相邻概念，应与期望、实际分开记录。

期望结果、实际结果与差异分别指什么

这三个字段共同回答一个问题：在某个确定条件下，系统应该怎样、实际怎样、两者差在哪里。它们是一条判断链上的三个环节，各自承担不同的信息任务。

期望结果是在给定条件下应当出现的行为或状态。它描述的是判断基准，例如“在订单金额满 200 元且使用指定优惠券时，结算页应付金额显示为 180 元”。这个基准来自需求、设计稿、接口约定或业务规则，写进缺陷时应当已经转化为可观察的表现。

实际结果是在同一条件下真实观察到的表现。它记录的是事实，例如“同一订单在结算页显示应付金额 200 元，优惠未抵扣”。实际结果需要带上触发条件和观察到的现象，必要时附截图、日志或报错文本。

差异是两者在具体观察点上的不一致。它不重复前两项的完整内容，只指出分歧所在，例如“优惠券金额未从应付金额中扣减”。

三者共用同一观察口径，是这组字段能成立的前提。期望写的是结算页金额，实际也要记录结算页金额；期望写的是接口返回码，实际就不能只写页面提示。口径一旦错位，差异就无从比较，后续定位也会被带偏。

粒度标准：记录到可观察、可判定为止

判断粒度是否合适，可以用两条标准检验：可观察、可判定。达到这两条即可停笔，继续往下写往往开始混入不属于这个字段的内容。

可观察指有明确的触发条件和观察对象。读者能知道在什么前置条件下、操作哪个入口、观察哪个界面元素、接口字段或日志输出。缺少触发条件，记录就变成孤立结论；缺少观察对象，读者不知道该看哪里。

可判定指第三方依据记录能判断通过或不通过。把期望结果和实际结果放在一起，一个没有参与测试的人应当能得出结论：这两者一致还是不一致。如果还需要追问“你说的正常是指什么”“失败是哪个环节失败”，说明粒度还不够。

粒度也有明确边界。期望结果和实际结果不写实现方案，例如“应该改用缓存命中判断”；不写推测原因，例如“可能是优惠计算顺序有问题”；不写与判断无关的环境细节，例如测试机的完整配置清单。这些内容属于定位阶段或其他字段。

偏差类型	表现	后果
过粗	期望写“结算金额正确”，实际写“金额不对”	无法判断对错，开发需要重新询问和复现
过细	期望里写数据库表结构和计算逻辑，实际里写排查过程和怀疑对象	判断基准被淹没，字段之间职责混乱

期望结果写到什么程度

期望结果的记录目标是给出一个可验证的判断基准。写法上可以按以下要素组织，按实际情况取用，不必逐条凑齐。

• 前置条件：账号状态、数据准备、开关配置、时间或环境条件。只写与本次判断相关的条件。
• 操作入口：从哪个页面、接口或功能入口触发，执行了什么操作。
• 应出现的行为或状态：用可验证的表述描述结果，例如“提交后返回成功并跳转至列表页”“接口返回 200 且响应体中 status 为 approved”。
• 涉及数据时给出具体值或范围：金额、数量、状态码、字段值、时间范围等，用具体数字或明确区间代替“正确”“合理”。

期望结果要避免写成修复建议。“应增加对空值的判断”是方案，“输入为空时点击保存，页面提示‘请输入名称’且不提交请求”是期望。前者把实现方式塞进了判断基准，后者才是可观察、可判定的表述。期望结果也不宜直接复制需求原文，需求文档里的业务描述往往包含背景和多个场景，需要提炼出本次缺陷对应的那一个观察点。

实际结果写到什么程度

实际结果与期望结果使用同一组前置条件和操作入口，记录真实发生的表现。它的记录要素包括：

• 真实表现：在同一条件下观察到的行为或状态，描述到具体现象，例如“点击保存后页面无提示，请求返回 500，列表未新增记录”。
• 关键证据：截图、日志片段、报错文本、接口响应。证据用于支撑现象描述，选取能说明问题的那一段，不需要附上完整日志。
• 出现频率：必现、偶现或特定条件下出现。频率与复现步骤相关，写清在什么操作序列下出现、尝试了几次，比单独标注“偶现”更有信息量。

实际结果要避免“不对”“失败”“有问题”这类无信息表述。它们只表达了判断结论，没有提供判断依据，读者无法区分是功能未生效、报错中断还是显示异常。把现象写到具体对象和具体表现，才能让差异和后续定位有落脚点。实际结果同样不写原因分析，“失败”之后接“应该是接口超时导致”会把观察和推测混在一起，推测应留到定位阶段。

差异怎么写才不重复前两项

差异字段的独立价值在于压缩信息：读者看完期望和实际后，用一句话确认分歧点。它的写法是点明两者在哪个具体观察点上不一致，通常可以采用“某条件下，某对象的表现与预期不符”的结构。

例如期望是“使用满 200 减 20 优惠券后，应付金额显示 180 元”，实际是“应付金额仍显示 200 元，优惠券状态显示已使用”，差异可以写为“优惠券已核销但应付金额未扣减 20 元”。这句话没有复述完整的操作步骤和页面细节，只把分歧定位到“核销与金额扣减不同步”这个点上。

差异与期望、实际的分工是：期望给基准，实际给事实，差异给结论。差异不整段复制前两项，也不引入新的观察内容。如果差异里出现了期望和实际都没提过的现象，说明前面的记录有遗漏，应回到对应字段补齐。写清差异对后续定位有直接作用：开发可以先看差异判断问题落在哪个环节，再回到实际结果查看证据，减少在长段描述里找重点的时间。

具体例子与常见误解

下面是一个填写完整的示例，场景为演示用途。

字段	内容
前置条件	测试账号已领取“满 200 减 20”优惠券，购物车商品金额合计 200 元
操作入口	购物车页点击“去结算”，在结算页选择该优惠券后点击“提交订单”
期望结果	结算页应付金额显示 180 元，提交后订单实付金额为 180 元，优惠券状态变为已使用
实际结果	结算页应付金额仍显示 200 元；提交后订单实付 200 元；优惠券状态已变为已使用。附结算页截图和订单详情截图，3 次操作均复现
差异	优惠券已核销，但应付金额和订单实付金额均未扣减 20 元

这个例子里，期望和实际都围绕“应付金额、实付金额、优惠券状态”三个观察点，差异只指出核销与扣减不同步这一处不一致，没有重复截图内容和操作步骤。

常见误解有三类。第一类是把期望写成需求原文，整段粘贴业务规则，导致判断基准模糊，读者需要自己从中找本次对应的观察点。第二类是把实际写成原因分析，在现象后面直接给出结论，观察和推测混在一起，后续定位若推翻推测，记录本身也失去可信度。第三类是粒度随人变化，同一类问题由不同人提交时，有人只写一句“金额不对”，有人附上完整排查过程，评审和定位的成本因此波动。

这些偏差带来的返工是具体的：开发需要重新询问复现条件，测试需要补充截图和日志，缺陷在状态流转中来回退回。把三个字段的粒度统一到可观察、可判定，能减少这类往返。

在缺陷记录与流转环节，ONES Project 提供缺陷跟踪管理，支持一键提交 Bug 至对应项目或迭代，并记录和跟踪修复情况；ONES TestCase 中未通过的用例也可快速创建缺陷任务，使缺陷在测试与研发团队间流转。团队可以把期望结果、实际结果、差异作为缺陷工作项的描述内容，配合状态流转完成提交、评审与修复跟踪。具体字段配置与流转规则需结合实际项目设置核验。

与相邻记录的区别：严重程度、原因分析与需求描述

期望结果和实际结果容易与几个相邻概念混写，划清边界有助于保持字段职责稳定。

相邻概念	回答的问题	与期望、实际的关系
严重程度	这个缺陷造成多大影响，应多快处理	属于缺陷分类与分级，依据影响范围和业务重要性判定，不写进期望与实际
原因分析	为什么会发生	属于定位阶段，在观察和复现之后进行，不写进实际结果
需求描述	业务上要做什么、为什么做	是期望结果的来源之一，但包含背景、目标和多个场景，需要提炼为单一观察点

严重程度判定依赖缺陷的影响，而不是期望与实际写得有多详细。把“建议优先修复”写进期望结果，会让判断基准带上优先级诉求，评审时难以区分事实与主张。原因分析放在定位阶段，是因为它依赖对实际结果的进一步排查，提前写入实际结果会让观察记录带上未经验证的假设。需求描述与期望结果的区别在于范围：需求描述面向业务目标，期望结果面向本次可观察的单一行为或状态，前者需要转化为后者才能用于判断。

常见问题

期望结果和实际结果必须使用完全相同的观察口径吗？

需要。期望写的是结算页应付金额，实际也要记录结算页应付金额；期望写的是接口返回码，实际就不能只写页面提示。口径错位时，差异无法比较，读者也无法判断两者是否一致。如果实际观察中出现了期望未覆盖的现象，应回到期望结果补齐对应的观察点，再写差异。

偶现缺陷的实际结果应该记录到什么程度？

偶现缺陷同样写到可观察、可判定为止，额外补充出现频率和尝试次数。例如说明在什么操作序列下出现、执行了几次、成功几次失败几次，并附上失败时的截图或日志。只标注“偶现”信息量不足，读者无法判断复现条件；把完整排查过程写进实际结果又会混入定位内容，超出该字段的职责。

期望结果可以直接复制需求文档里的描述吗？

不建议直接复制。需求描述通常包含业务背景、目标和多个场景，范围大于本次缺陷对应的单一观察点。期望结果需要从需求中提炼出本次可观察、可判定的那一个行为或状态，涉及数据时给出具体值或范围。直接粘贴整段需求会让判断基准模糊，评审时读者需要自己从中找对应内容。

差异字段和期望、实际重复写会有什么影响？

重复写会拉长记录，让读者在长段描述里找重点。差异的独立价值是压缩信息：期望给基准，实际给事实，差异给结论。差异只点明分歧所在，例如“优惠券已核销但应付金额未扣减”，不复述操作步骤和页面细节。如果差异里出现期望和实际都没提过的现象，说明前面记录有遗漏，应回到对应字段补齐。

在缺陷管理工具中，这三个字段如何承载和流转？

团队可以把期望结果、实际结果、差异作为缺陷工作项的描述内容，配合状态流转完成提交、评审与修复跟踪。ONES Project 提供缺陷跟踪管理，支持一键提交 Bug 至对应项目或迭代，并记录和跟踪修复情况；ONES TestCase 中未通过的用例也可快速创建缺陷任务，使缺陷在测试与研发团队间流转。具体字段配置与流转规则需结合实际项目设置核验。