测试结果记录的价值在于让一次执行可以被他人复核：谁在什么版本、什么环境下执行了哪条用例，看到了什么现象，据此得出什么判定，证据在哪里。本文用一个虚构的登录用例演示情景，给出一份填写完整的记录表和同批次汇总表，再逐字段解释取值理由，归纳可迁移到其他用例的填写规律，并说明缺陷跟踪与测试报告应另行承载的内容。测试执行记录最终要落到工作项上，文中也会自然提及ONES测试管理如何承接这类记录。
要点总览（TL;DR）
- 测试结果记录以“一条用例、一次运行、一条记录”为单位，必备字段包括用例标识、版本与环境、前置条件、执行步骤、预期结果、实际结果、判定、证据、执行人和执行时间。
- 示例以登录用例演示：实际结果写观察到的现象（停留约3秒、弹出网络异常提示、重试两次一致），判定为失败，并附录屏与日志，使他人可直接复现。
- 失败项以可复现为最低标准，写清操作路径、现象和复现次数；阻塞项写明依赖原因；批次汇总由单条记录聚合，不另行编造结论。
- 重测应另起新记录并写明新构建号，不在原记录上覆盖；字段可随用例类型增减，但执行条件、实际结果、判定、证据、执行人和时间这几类语义应保留。
- 缺陷修复与验证跟踪、测试报告与质量评估不在本记录内闭环，记录只负责把一次执行的现象、证据和判定写清楚。
这份示例要解决什么问题
本文的示例为虚构演示情景，用于说明填写方法，不涉及真实客户、真实项目或实测效果数据。演示对象是一条登录用例的一次执行，记录颗粒度定位到“一条用例、一次运行、一条记录”。读者可以对照示例，填出一份可复核、可交接的结果记录：复核者不需要询问执行人，就能判断这条用例当时是怎么跑的、结论是否站得住。
之所以选择登录用例作为线索，是因为它足够常见，前置条件、步骤和预期结果都容易理解，便于把注意力放在记录字段本身，而不是业务复杂度上。示例中的版本号、设备型号、执行人均为演示设定，读者替换为自己项目的真实信息即可使用。
读者对照本文可以完成三件事：一是照着示例填出一条完整记录；二是理解每个字段为什么这样取值，避免常见偏差；三是把写法迁移到自己项目中的其他用例和整个批次的汇总。
完整示例：一条登录用例的测试结果记录
下面先给出单条用例填写完成后的记录表，再给出同批次执行结果的汇总视图。两张表共同构成一次测试运行的留痕：单条记录承载细节，汇总表承载批次层面的分布与失败项指向。
单条用例记录表（填写完成）
| 字段 | 填写内容 |
|---|---|
| 用例编号 | LOGIN-012 |
| 用例标题 | 已注册用户使用正确账号密码登录，跳转至工作台首页 |
| 版本与环境 | 构建号 v2.4.0-rc3；Android 14；机型 Pixel 7；测试环境 staging；网络 Wi-Fi |
| 前置条件 | 账号 test_user_01 已注册且状态正常；应用为全新安装，无历史登录态 |
| 执行步骤 | 1. 打开应用，进入登录页；2. 输入账号 test_user_01；3. 输入正确密码；4. 点击“登录” |
| 预期结果 | 登录成功，页面跳转至工作台首页，顶部显示当前用户名 |
| 实际结果 | 点击登录后停留登录页约 3 秒，随后弹出提示“网络异常，请重试”；重复操作两次现象一致；同一账号在 iOS 设备上登录正常 |
| 判定 | 失败 |
| 证据附件 | 录屏 login-012-fail.mp4（含两次重试过程）；日志片段 login-012-log.txt（含请求超时记录） |
| 执行人 | 张演示 |
| 执行时间 | 2025-03-11 14:20–14:32 |
同批次执行结果汇总表
| 用例编号 | 用例标题 | 判定 | 失败/阻塞指向 |
|---|---|---|---|
| LOGIN-010 | 未登录用户访问首页跳转登录页 | 通过 | — |
| LOGIN-011 | 账号格式校验提示 | 通过 | — |
| LOGIN-012 | 正确账号密码登录跳转首页 | 失败 | 见 LOGIN-012 记录，疑似登录接口超时 |
| LOGIN-013 | 密码错误提示与次数限制 | 阻塞 | 依赖 LOGIN-012 登录成功链路，暂无法验证 |
| LOGIN-014 | 第三方账号登录 | 未执行 | 本批次未安排 |
批次汇总：本批次共 5 条，通过 2 条，失败 1 条，阻塞 1 条，未执行 1 条。失败项指向 LOGIN-012，阻塞项 LOGIN-013 因依赖失败链路而无法继续。汇总表中的每一行都能回溯到对应的单条记录，没有另行编造结论。
失败项的记录写法值得单独说明：实际结果写的是观察到的现象（停留约 3 秒、弹出“网络异常”提示、重复两次一致、iOS 正常），判定写“失败”，证据附上录屏和日志。这样的写法让后续处理的人可以直接复现，而不需要再找执行人询问细节。
逐项解释：每个字段为什么这样填
字段填写的共同目标是让记录可复核。下面挑出示例中几个关键字段，说明取值理由和常见偏差。
版本与环境要具体到构建号和设备/浏览器。示例写的是“v2.4.0-rc3；Android 14；Pixel 7；staging；Wi-Fi”，而不是笼统的“最新版、安卓手机”。原因是同一个功能在不同构建号、不同系统版本、不同网络条件下表现可能不同，只写“最新版”会让复核者无法判断问题是否已被后续构建修复，也无法判断是否只在特定设备上出现。常见偏差是只写产品版本号、漏掉构建号和设备信息。
实际结果写观察到的现象，而非复述预期。示例中实际结果记录了停留时长、提示文案、重试次数和跨平台对比，这些都是执行人直接看到的事实。如果实际结果写成“登录失败”，信息量不足；如果写成“应该跳转首页但没有”，则混入了预期，复核者难以区分现象和判断。把现象和预期分开写，判定才有依据。
判定结论与证据附件保持一致。判定为“失败”，附件就必须能支撑这个判定。示例附了录屏和日志，录屏覆盖两次重试，日志包含请求超时记录，二者与“网络异常提示”的现象对应。常见偏差是判定写了失败，附件却只有一张静态截图，无法证明重试后现象一致；或者附件是另一条用例的录屏，导致证据与结论错位。
失败项描述以他人能复现为最低标准。示例中的失败描述包含操作路径、现象、复现次数和对照信息（iOS 正常），他人按同样步骤操作应能得到相同现象。如果只写“登录有问题”，接手的人需要重新摸索，记录就失去了交接价值。
执行人与执行时间用于追溯和交接。执行人字段让复核者知道找谁确认细节，执行时间让团队判断这条记录对应哪次构建、哪轮测试，也便于在批次汇总中按时间排序。常见偏差是执行人只写团队名、执行时间只写日期不写时段，追溯时仍需额外询问。
从这条示例能迁移出哪些填写规律
单条示例可以抽象为几条适用于其他用例和批次的规律，读者可以直接套用。
- 一条记录对应一次执行，重测另起记录。示例中的 LOGIN-012 在 v2.4.0-rc3 上执行了一次，形成一条记录。如果修复后在 rc4 上重测，应新建一条记录并写明新的构建号，而不是在原记录上覆盖实际结果。覆盖会丢失历史，也无法对比两次执行的差异。
- 判定与证据成对出现。每条记录的判定都应有对应附件或可核查的信息支撑。通过项可以附关键页面截图，失败项附录屏和日志，阻塞项附阻塞原因的说明。判定与证据分离的记录，复核成本会显著上升。
- 失败记录以可复现为最低标准。无论用例类型如何，失败描述都应包含操作路径、观察到的现象和复现情况。对于偶现问题，写明出现次数和尝试次数，例如“尝试 5 次出现 2 次”，比只写“偶现”更有用。
- 批次汇总由单条记录聚合，而非另行编造。示例中的汇总表每一行都来自对应的单条记录，通过、失败、阻塞、未执行的数量由记录统计得出。汇总时如果发现数字对不上，应回到单条记录核对，而不是在汇总表里调整。
- 字段随用例类型增减，语义保留。接口用例可能不需要设备型号，但需要请求参数和响应码；性能用例需要并发数和响应时间分布。字段可以按用例类型调整，但“执行条件、实际结果、判定、证据、执行人、时间”这几类语义应当保留，否则记录的可复核性会被削弱。
这几条规律同样适用于批次层面：一个批次开始前确定记录字段口径，执行中按单条记录填写，结束后由记录聚合出汇总。这样汇总数据才有来源，质量判断才有依据。
当记录需要落到团队协作系统中时，ONES 测试管理提供了承接方式：用例可分配执行人，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转；测试计划可与迭代关联，测试情况概览可查看进度和通过率。这些能力对应的是记录之后的流转与汇总环节，具体字段与状态以实际环境配置为准。
适用边界：哪些内容不放进测试结果记录
测试结果记录的范围是测试运行过程的留痕，它回答“这条用例这次跑得怎么样”，不承担缺陷修复闭环和整体质量评估的职责。明确这条边界，可以避免记录表被塞入过多内容而失去可读性。
缺陷修复与验证跟踪不在本记录内闭环。示例中 LOGIN-012 判定失败后，记录只负责把现象、证据和判定写清楚。缺陷的提交、指派、修复、回归验证属于另一条流程，通常在缺陷跟踪中完成。记录中可以指向缺陷编号，但修复过程和验证结论不写回原记录，重测时另起新记录。
测试报告与质量评估结论另行输出。批次汇总表提供的是通过、失败、阻塞、未执行的分布，它是测试报告的输入之一，但报告还需要覆盖范围说明、风险判断和发布建议。这些内容超出单条记录和批次汇总的范围，应在测试报告中单独撰写。ONES 测试管理支持自定义组装测试报告模板并自动生成测试报告，可作为报告输出的承载方式，报告口径需按团队实际配置。
示例不构成对具体工具字段的强制要求。本文给出的字段是演示情景下的填写示范，不同团队使用的工具和字段命名可能不同。团队可以调整字段名称、增减字段，但应保留执行条件、实际结果、判定、证据、执行人和时间这几类语义，确保记录仍然可复核、可交接。
把边界划清之后，测试结果记录就能保持简洁：一条记录聚焦一次执行，批次汇总由记录聚合，缺陷和报告各自在对应的流程中完成。这样的分工让每个环节的产出都有明确用途，也便于团队在评审和交接时快速定位信息。
常见问题
同一条用例在修复后重测，记录应该新建还是修改原来那条？
建议新建一条记录，并写明新的构建号和执行时间。原记录保留当时的实际结果、判定和证据，作为历史留痕；新记录承载重测后的现象和结论。这样两次执行可以对比，也能判断问题是否在某个构建上被修复。如果在原记录上直接覆盖实际结果，历史信息会丢失，复核时无法还原当时的执行情况。
偶现问题在测试结果记录里怎么写才算清楚？
偶现问题同样按“现象、复现情况、证据”来写。实际结果中记录尝试次数和出现次数，例如“尝试 5 次出现 2 次”，并写明每次出现时的现象是否一致；证据尽量附上出现时的录屏或日志片段。判定可以写失败，并在描述中说明是偶现。只写“偶现”两个字，接手的人无法判断复现条件，记录的可交接性会明显下降。
阻塞和未执行在记录与汇总里有什么区别？
阻塞表示这条用例本应执行，但因依赖条件不满足而无法继续，例如示例中 LOGIN-013 依赖登录成功链路。记录中要写明阻塞原因和依赖对象。未执行表示本批次没有安排这条用例，例如 LOGIN-014。两者在批次汇总中分开统计，因为阻塞往往意味着覆盖缺口需要补测，未执行则可能是排期安排的结果。把两者混为一谈，会让批次通过率和覆盖判断失真。
团队使用的工具字段和示例不一致，还能照这套写法用吗？
可以。示例给出的是演示情景下的字段示范，字段名称和数量可以按团队工具调整。需要保留的是几类语义：执行条件（版本、环境）、实际结果、判定、证据、执行人和执行时间。只要这些语义在记录中有着落，记录就仍然可复核、可交接。调整字段时建议团队先统一口径，避免同一批次里有人写构建号、有人只写产品版本，导致汇总时无法对齐。
记录里判定失败后，缺陷单号和修复结论要不要写回原记录？
可以在原记录中指向缺陷单号，方便追溯；修复过程和验证结论建议留在缺陷跟踪流程中，不写回原记录。原记录保持“这次执行看到了什么、判定是什么”的原始状态，重测时另起新记录承载验证结果。这样记录与缺陷各自职责清晰，评审时也能区分执行事实和处理过程。ONES 测试管理支持对未通过的用例快速创建缺陷任务，并在测试与研发团队间流转，可作为记录之后的衔接方式，具体字段与状态以实际环境配置为准。
