缺陷报告中差异与期望结果、实际结果是什么关系

缺陷报告里的期望结果、实际结果是两条各自独立的事实记录，差异是二者在同一操作、同一输入条件下对比后得出的具体偏离。三者构成一条证据链：先固定复现条件，再分别写清“应该怎样”和“实际怎样”，最后由对比归纳出差异。差异不能替代前两栏，也不能只写一句“结果不对”。

要点总览（TL;DR）

• 期望结果是提交人对系统应有行为的描述，实际结果是同一条件下系统真实表现的可观察记录，差异是两者对比后得到的具体偏离。
• 三者构成一条证据链：先固定操作与输入，再写期望，再写实际，最后由对比归纳差异；条件不一致时对比出的差异不成立。
• 期望结果写到可判定的行为与输出并引用需求出处，实际结果写到可复现的观察，差异写到最小偏离点且一条缺陷聚焦一个差异。
• 差异只描述现象偏离，原因分析属于定位阶段，严重程度判定属于分级环节，三者分栏记录。
• 常见错误包括只写差异不写期望与实际、把期望写成实现方案、实际结果写成推测、一条缺陷塞多个差异。

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

三个术语对应缺陷记录中三种不同性质的信息。理解它们的区别，先要分清哪些是原始事实，哪些是对比后的结论。

期望结果：对正确行为的描述

期望结果是缺陷提交人对系统应有行为的说明，通常包含输入条件和在该条件下应产生的输出。它回答的是“按照需求、设计或业务规则，这里应该发生什么”。一条合格的期望结果应当能指向具体依据，例如需求文档中的某条规则、接口约定中的返回结构、界面设计稿中的提示文案。期望结果写的是行为与输出，不写实现方式。

实际结果：对真实表现的可观察记录

实际结果是同一操作、同一输入条件下，系统真实表现的可观察记录。它回答的是“我实际看到了什么”。可观察意味着记录的是能够被他人复核的现象：界面显示了什么提示、接口返回了什么状态码和内容、数据状态发生了怎样的变化、页面停留或跳转到了哪里。实际结果只记录观察到的现象，不掺入对原因的猜测。

差异：对比之后得到的具体偏离点

差异是期望结果与实际结果对照后得到的具体偏离。它回答的是“两者在哪里不一致”。差异是结论性描述，由前两栏推导而来，本身不构成独立事实。例如期望“提交后跳转至订单列表页”，实际“提交后停留在当前页且无任何提示”，差异可以归纳为“提交成功后未发生页面跳转，也缺少成功反馈”。差异写得越具体，后续判断是否构成缺陷、影响多大就越有依据。

字段	信息性质	回答的问题	粒度要求
期望结果	原始事实（应有行为）	应该发生什么	可判定的行为与输出，附需求或规则出处
实际结果	原始事实（真实表现）	实际看到了什么	可复现的观察，含提示、返回值、状态变化
差异	对比结论	两者在哪里不一致	最小偏离点，一条缺陷聚焦一个差异

三者在一条缺陷记录里如何形成证据链

三者的关系是先后记录、对比推导。差异由期望与实际对照产生，不能脱离任何一方单独成立。理解这条推导链，有助于在填写时保持各栏的信息纯度。

记录顺序：先固定条件，再写两端，最后归纳差异

一条缺陷记录的自然顺序是：先写清操作步骤与输入数据，把复现条件固定下来；再写期望结果，说明在该条件下应有怎样的行为；然后写实际结果，记录在该条件下真实观察到的表现；最后归纳差异，指出两者的具体偏离点。这个顺序保证了对比发生在同一条件下，也让阅读者能够按同样步骤复核。

差异的来源是对照，条件不一致时差异不成立

差异成立的前提是期望与实际描述的是同一操作、同一输入、同一环境。如果期望结果基于账号 A 的权限，实际结果却在账号 B 下观察，或者期望针对的是提交成功场景，实际记录的是网络异常场景，那么两者对比出的“差异”并不成立，属于伪差异。填写时应先核对两栏的条件描述是否一致，条件不同就先修正条件，再谈差异。

差异是判断入口，不是独立事实

差异的作用是引出判断：这个偏离是否构成缺陷、影响范围有多大、需要怎样定级。它把期望与实际之间的落差集中呈现出来，供评审和定位使用。差异本身不提供原因，也不提供分级结论，它只是把“哪里不对”说清楚。把差异当作独立事实来写，容易滑向原因推测或影响夸大，反而削弱了记录的可核查性。

各自应记录到什么粒度

粒度标准的核心是“够用即可”：写到他人能据此判断和复现的程度，不追求穷尽细节，也不停留在笼统描述。三栏各有侧重。

期望结果：写到可判定的行为与输出

期望结果应写到能够明确判定对错的程度，并尽量引用需求或规则出处。可判定的写法是描述具体行为与输出，例如“输入正确手机号后点击获取验证码，按钮进入 60 秒倒计时并提示‘验证码已发送’”。不可判定的写法是“验证码功能正常”。引用出处可以是需求编号、接口文档章节或业务规则说明，便于评审时核对期望是否成立。

实际结果：写到可复现的观察

实际结果应记录能够被他人按相同步骤观察到的现象，包括界面提示文案、接口返回值、数据状态变化、页面跳转结果等。写法上尽量使用客观描述，例如“点击后按钮无变化，页面未出现任何提示，倒计时未启动”。避免“好像没反应”“感觉有问题”这类无法复核的表述。如果现象与时间、环境有关，把观察时的条件一并写明。

差异：写到最小偏离点，一条缺陷一个差异

差异应聚焦到最小的偏离点，一条缺陷记录一个差异。如果一次操作暴露出多个不一致，例如提示文案错误、倒计时未启动、日志缺失同时出现，应拆分记录或明确主差异，避免一条缺陷承载多个问题导致定位和验证混乱。拆分的好处是每条记录都能独立判断、独立修复、独立回归。

容易混淆的相邻概念：差异、缺陷原因与严重程度

差异描述的是现象层面的偏离，原因分析和严重程度判定属于后续环节。三者分属不同栏位，混写会让记录失去可追溯性。

差异与原因分析分栏记录

差异回答“哪里不对”，原因分析回答“为什么不对”。原因分析通常在定位阶段完成，可能涉及代码逻辑、配置、数据或环境因素，结论往往需要开发人员介入。缺陷提交阶段把差异写清即可，原因推测可以放在备注中并标明是推测，不与差异栏混写。这样在定位结论与初始描述不一致时，仍能回溯最初的观察事实。

严重程度判定归分级环节

严重程度是对缺陷影响的分类结论，依据组织约定的分级规则判定，例如是否阻断主流程、是否影响数据正确性、是否有可用替代路径。差异本身只提供判断依据，不直接等于分级结论。把“严重”写进差异栏，既没有增加信息，也容易让分级讨论失去客观基础。差异写得具体，分级才有据可依。

服务事件受理与问题管理属于另一条流程

面向用户的服务事件受理、问题管理等流程有其独立的记录字段和处理路径，与研发缺陷记录中的差异字段不是同一套结构。本文讨论的范围限于缺陷记录本身的填写质量，服务事件与问题管理流程不在差异字段内展开。

一个具体例子与常见误解

下面用一个登录场景演示三栏的完整写法，再列出实际填写中反复出现的几类错误，便于对照检查。

示例：登录场景的三栏填写

操作步骤：在登录页输入已注册手机号与正确密码，点击“登录”。

• 期望结果：依据需求文档“登录成功后跳转至工作台首页，并展示当前用户名”，点击登录后应跳转至工作台首页，页面右上角显示当前用户名。
• 实际结果：点击登录后页面停留在登录页，顶部出现提示“登录失败，请重试”，浏览器地址未变化，再次点击仍为相同提示。
• 差异：凭证正确的情况下登录未成功，未发生页面跳转，且提示文案指向登录失败，与预期成功登录的行为不一致。

这个例子里，期望引用了需求出处，实际记录了可观察的提示与页面状态，差异聚焦在“凭证正确却登录失败”这一最小偏离点上。三者条件一致，复核者按相同步骤即可重现。

常见误解清单

• 只写差异，不写期望与实际。读者无法判断偏离的依据，也无法复核，差异变成无源结论。
• 把期望写成实现方案。例如期望栏写“应在前端做防抖处理”，这属于实现建议，应写用户可感知的行为与输出。
• 实际结果写成推测。例如“应该是接口超时了”，这是原因猜测，实际结果只记录看到的提示、返回值和状态。
• 条件不一致造成伪差异。例如期望基于管理员权限，实际在普通用户下观察，两者本就不是同一场景，对比出的差异不成立。
• 一条缺陷塞多个差异。提示文案、跳转、日志问题混在一条记录里，定位和回归时难以逐项确认。

当缺陷记录需要在团队间流转时，期望、实际、差异与复现步骤需要有稳定的承载位置。ONES Project 适配缺陷管理等研发场景，支持一键提交 Bug 至对应项目或迭代，用于记录和跟踪缺陷修复情况；ONES TestCase 支持未通过用例快速创建缺陷任务，使缺陷在测试与研发团队间流转，并可将测试用例与需求、任务关联，形成测试流程闭环。把三栏信息结构化地写入工作项，评审、定位和回归各环节都能基于同一份记录推进。

常见问题

期望结果和实际结果的条件描述必须完全一致吗？

需要一致到能够支撑对比的程度。操作步骤、输入数据、账号权限、环境等影响结果的条件，两栏应描述同一组。如果期望基于管理员权限、实际在普通用户下观察，对比出的差异不成立。填写时先核对两栏条件，条件不同就先修正条件，再归纳差异。

一次操作暴露出多个不一致，应该合并成一条缺陷还是拆开记录？

建议按最小偏离点拆分，一条缺陷聚焦一个差异。提示文案错误、倒计时未启动、日志缺失同时出现时，合并记录会让定位和回归难以逐项确认。拆分后每条记录可以独立判断、独立修复、独立回归；如果确实存在主次关系，可以明确主差异，其余作为关联记录。

缺陷提交时还不清楚原因，差异栏可以写推测吗？

差异栏写现象层面的偏离，原因推测放在备注中并标明是推测。差异回答“哪里不对”，原因分析回答“为什么不对”，后者通常在定位阶段由开发人员介入完成。分开记录的好处是，当定位结论与初始描述不一致时，仍能回溯最初的观察事实。

期望结果引用不到需求文档时怎么写？

尽量找到可指向的依据，例如接口约定、设计稿、业务规则说明或同类功能的既有行为。确实没有书面依据时，把期望写成可判定的行为与输出，并在记录中说明依据来源，便于评审时确认期望是否成立。期望结果写行为与输出，不写实现方式。

团队用工具管理缺陷时，这三栏信息放在哪里比较合适？

需要让期望、实际、差异与复现步骤在缺陷工作项中有稳定的承载位置，评审、定位和回归各环节基于同一份记录推进。ONES Project 适配缺陷管理等研发场景，支持一键提交 Bug 至对应项目或迭代，用于记录和跟踪缺陷修复情况；ONES TestCase 支持未通过用例快速创建缺陷任务，使缺陷在测试与研发团队间流转。具体字段形态可按团队缺陷模板配置。