在缺陷报告中，期望结果描述按需求或设计本应发生的行为，实际结果描述测试或使用中真实观察到的行为，差异则是把两者逐项对照后得出的具体偏离。三者构成一条因果链：先各自独立记录两条事实，再通过对照产生差异，差异成为判断缺陷是否成立、开发从哪里着手修复的依据。本文解释三个术语的定义、关系、书写粒度，并用示例说明常见误用。
要点总览（TL;DR）
- 期望结果描述按需求、设计或业务规则本应发生的行为，实际结果描述在特定步骤、环境和数据下真实观察到的现象，两者是并列的两条事实记录。
- 差异是期望结果与实际结果逐项对照后得出的具体偏离结论，依赖前两者存在，是判断缺陷是否成立、开发从何处修复的核心依据。
- 粒度标准不同：期望结果写到可判定的行为或数值，实际结果写到可复现的操作路径与观察点，差异写到具体偏离项，避免笼统写“不符合预期”。
- 复现步骤回答怎么触发，缺陷描述是整体概述，严重程度判定归缺陷分类与分级，差异字段只承担比对结论，不混入这些内容。
- 常见误用包括把期望写成需求原文、把实际写成原因推测、把差异写成情绪化判断，这些写法会让缺陷在评审、修复、验证环节反复返工。
三者各指什么：期望结果、实际结果与差异的定义
期望结果、实际结果和差异分别承担不同的记录任务。前两者是两条并列的事实，差异是对照后形成的判断。理解这一点，才能避免把三个字段写成同一句话的三种说法。
期望结果：来自需求与约定的应然行为
期望结果回答“按约定应该发生什么”。它的来源包括产品需求文档中的功能描述、交互设计稿中的状态与反馈、接口文档约定的返回结构与状态码、业务规则中规定的计算方式与边界条件。期望结果需要有明确出处，写的时候尽量落到可判定的行为或数值上，例如“提交成功后跳转至订单列表页，列表首行显示新订单号”，而不是复述一段需求原文。
实际结果：在特定条件下观察到的现象
实际结果回答“实际看到了什么”。它必须可观察：在给定的操作步骤、环境（浏览器、系统版本、设备型号）、测试数据下，测试人员看到的具体现象。实际结果只记录观察，不掺入原因推测。看到“点击提交后页面停留在原页，按钮置灰，控制台报 500”，就写这些现象；至于“可能是接口超时”属于分析，不放在实际结果里。
差异：对照之后得出的偏离结论
差异回答“哪里不一样”。它依赖期望结果和实际结果两条事实，通过逐项比对产生，本身不是独立采集到的事实。差异的写法应指向具体偏离项，例如“提交成功后未发生页面跳转，且未生成订单记录”，而不是笼统的“不符合预期”。差异是缺陷成立的核心依据，也是开发确认修复目标的起点。
| 字段 | 回答的问题 | 主要来源 | 记录性质 |
|---|---|---|---|
| 期望结果 | 按约定应该发生什么 | 需求、设计、接口约定、业务规则 | 事实（应然） |
| 实际结果 | 实际观察到了什么 | 测试或使用中的操作与观察 | 事实（实然） |
| 差异 | 两者在哪里不一样 | 对前两者的逐项对照 | 判断（结论） |
三者的关系：从两条事实到一条判断
三者的关系可以概括为一条因果链：期望结果与实际结果是并列输入，差异是对照输出，差异又支撑缺陷成立与修复决策。这个顺序决定了书写顺序——先写清两条事实，再写差异。
期望与实际是并列的两条事实记录
期望结果和实际结果各自独立成立，不互相定义。期望结果不因实际结果而改变，实际结果也不因期望结果而被修饰。两者并列记录的好处是：评审者可以分别核对期望是否有依据、实际是否描述准确，而不必先接受一个结论。
差异由对照产生，依赖前两者
差异不能脱离期望和实际单独存在。没有期望结果，差异失去判定基准；没有实际结果，差异失去比较对象。因此差异的写法通常可以还原为“期望是 A，实际是 B，偏离在 C”。当差异无法这样还原时，往往说明前两个字段写得不够具体，或者差异本身混入了推测和情绪。
差异是缺陷成立与修复的判断依据
缺陷是否成立，取决于差异是否真实存在且落在约定范围内；开发如何修复，取决于差异指向的具体偏离项。差异写得越具体，开发定位问题的路径越短。反过来，如果差异只写“功能异常”，开发需要重新对照需求和实际现象，等于把判断工作退回给阅读者。
三者缺一时会出现什么典型问题
- 缺期望结果：差异失去基准，开发无法判断这是缺陷还是需求未覆盖，容易产生“这是按设计实现的”争议。
- 缺实际结果：差异变成主观断言，无法复现和验证，修复后也难以确认是否真的解决。
- 缺差异：期望和实际都写了，但读者要自己比对，缺陷是否成立、修复目标是什么都不明确，评审和流转成本上升。
在缺陷记录需要多人协作时，这三个字段的分工可以通过工作项承载。例如 ONES Project 适配缺陷管理等场景，支持一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷任务在测试与研发团队间流转。字段内容仍由提交者按上述分工写清，工具承担的是记录与流转。
各自记录到什么粒度：可对照、可复现、可判断
三个字段的粒度标准不同：期望结果要可判定，实际结果要可复现，差异要可判断。粒度不足会让缺陷在评审、修复、验证三个环节反复返工。
期望结果：写到可判定的行为或数值
可判定意味着读者能据此给出“符合”或“不符合”的结论。行为层面写清触发条件、系统反馈和结果状态；数值层面写清具体值、单位和边界。例如“单笔订单金额满 199 元时免运费，运费显示为 0 元”比“满足条件免运费”更可判定。期望结果不必抄写整段需求，摘取与本缺陷直接相关的约定即可。
实际结果：写到可复现的操作路径与观察点
实际结果要与复现步骤配合：步骤说明怎么走到观察点，实际结果说明在观察点看到了什么。观察点包括页面状态、提示文案、数据变化、接口返回、日志报错等。环境信息（浏览器、系统、账号角色、测试数据）单独记录，实际结果中引用即可，不必重复展开。这样写出的实际结果，其他人按步骤操作应能看到相同现象。
差异：写到具体偏离项，避免笼统结论
差异应逐项列出偏离，一项一行或一句。常见写法是“期望 X，实际 Y”，或直接指出偏离点，如“免运费门槛判断使用了商品原价而非实付金额，导致满减后订单被收取运费”。避免写“不符合预期”“功能有问题”“和需求不一致”这类无法定位的表述。
与复现步骤、环境信息的分工
复现步骤回答“怎么触发”，环境信息回答“在什么条件下”，期望结果、实际结果和差异回答“应该怎样、实际怎样、差在哪”。把操作步骤塞进实际结果，或把环境描述写进差异，都会让字段职责混乱，增加阅读者提取信息的负担。
和相邻概念的区别：复现步骤、缺陷描述、严重程度
差异字段容易被写成其他内容。划清边界的关键是看每个部分回答的问题不同，各司其职。
| 部分 | 回答的问题 | 典型内容 |
|---|---|---|
| 复现步骤 | 怎么触发 | 按顺序的操作动作、输入数据、前置条件 |
| 缺陷描述 | 这个缺陷整体是什么 | 一句话概述问题现象与影响范围 |
| 期望结果 | 按约定应该怎样 | 需求或规则规定的行为、数值 |
| 实际结果 | 实际看到了什么 | 观察到的现象、数据、报错 |
| 差异 | 哪里不一样 | 逐项偏离结论 |
| 严重程度 | 影响多大、多急 | 分级结果与判定理由 |
复现步骤与差异的区别最直接：步骤是路径，差异是路径终点处的比对结论。缺陷描述是整体概述，差异是概述背后的对照证据，两者一简一详。严重程度判定属于缺陷分类与分级工作，依据影响范围、出现频率、是否有规避手段等因素确定，不在差异字段内展开；差异字段只需把偏离写清楚，为分级提供事实基础。
具体例子与常见误解
下面用一个完整示例演示三个字段的写法，再列出高频误用及其带来的成本。
完整示例：优惠券叠加使用
复现步骤：登录普通用户账号，购物车加入两件商品合计 260 元，依次选择一张满 200 减 30 的店铺券和一张满 100 减 10 的平台券，点击结算。
期望结果：按活动规则，店铺券与平台券可叠加使用，结算页应付金额为 260 − 30 − 10 = 220 元，优惠明细分别显示两张券的抵扣金额。
实际结果：结算页仅抵扣平台券 10 元，应付金额显示 250 元，店铺券在优惠明细中显示“不可用”，页面无进一步提示。
差异：店铺券在满足门槛（260 元 ≥ 200 元）的情况下被判定不可用，未参与抵扣；应付金额比规则计算值多 30 元；优惠明细缺少不可用原因提示。
这个示例中，期望结果来自活动规则且可计算，实际结果是可观察的页面状态，差异逐项列出偏离，三者互不重复。
常见误解与纠正
- 把期望写成需求原文。整段粘贴需求文档，读者仍需自己提炼判定点。纠正：摘取与本缺陷直接相关的约定，转成可判定的行为或数值。
- 把实际写成推测。写“接口可能超时导致提交失败”，把原因分析混入观察记录。纠正：只写看到的现象，原因分析放在评论或排查记录中。
- 把差异写成情绪化判断。写“这个功能根本不能用”“体验极差”，无法定位偏离项。纠正：逐项写出期望与实际的具体差别。
- 差异与复现步骤混写。在差异里重复操作路径，读者要自己找结论。纠正：步骤归步骤，差异只写比对结果。
误解带来的返工与沟通成本
期望结果不可判定，开发需要回头找产品确认规则，缺陷在“是否成立”上先消耗一轮沟通；实际结果不可复现，修复后无法验证，缺陷可能被反复重开；差异笼统，开发定位时间拉长，测试与研发之间来回补充信息。三个字段各写清楚，评审时一次通过的概率明显提高，缺陷流转也更顺畅。在测试与研发协作的场景中，ONES TestCase 支持用例与需求、任务关联，未通过的用例可快速创建缺陷任务并在团队间流转，缺陷分布统计也可用于沉淀问题与经验；字段内容的质量仍取决于提交时是否按上述粒度写清期望、实际与差异。
常见问题
期望结果和实际结果都写清楚了，差异字段还需要单独写吗？
建议单独写。期望结果和实际结果是两条并列事实，读者需要自己逐项比对才能得出偏离结论，这个过程容易遗漏或理解不一致。差异字段把比对结果直接写出来，评审者可以快速确认缺陷是否成立，开发也能直接看到修复目标。如果差异确实完全由前两者逐项对应得出，差异字段可以写得简短，但仍应明确列出偏离项，避免只留一句“见上”。
需求文档本身写得比较笼统，期望结果该怎么写才可判定？
先找到与本缺陷直接相关的约定，把笼统描述转成可判定的行为或数值。例如需求写“支持优惠叠加”，可以结合活动规则补充为“店铺券与平台券可同时抵扣，应付金额按两者之和扣减”。如果规则本身存在歧义，可以在期望结果中注明依据的文档位置，并在缺陷评论中请产品确认。期望结果写不清时，缺陷容易在“是否成立”上先消耗一轮沟通，这一点比字段格式更值得优先处理。
实际结果里能不能写“可能是接口超时”这类原因分析？
实际结果只记录观察到的现象，例如页面停留在原页、按钮置灰、控制台报 500。原因分析属于排查信息，可以放在评论、排查记录或单独的分析字段中。把推测混入实际结果，会让后续读者难以区分哪些是看到的事实、哪些是判断，修复后验证时也容易产生争议。如果确实需要记录初步判断，建议明确标注为“待验证的推测”，与观察记录分开。
差异写多细才算够？会不会和复现步骤重复？
差异写到能定位具体偏离项即可，通常一项偏离一行或一句，例如“免运费门槛使用了商品原价而非实付金额，导致满减后订单被收取运费”。复现步骤回答怎么触发，差异回答哪里不一样，两者职责不同。差异中重复操作路径会让读者自己找结论，降低阅读效率。判断粒度是否足够，可以看开发能否据此直接定位到需要检查的逻辑或数据，而不必回头重新对照需求和现象。
缺陷记录里的期望、实际和差异，在工具中如何承载和流转？
这三个字段的内容由提交者按分工写清，工具承担记录与流转。ONES Project 适配缺陷管理等场景，支持一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷任务在测试与研发团队间流转。具体工作项是否提供独立的期望结果、实际结果、差异字段，以及字段能否自定义，需要以实际使用版本的配置为准。
