测试执行记录要解决的是复核与追溯问题：当一条用例失败、阻塞或需要重跑时，团队能凭记录还原当时执行了什么、在什么条件下执行、结果如何、证据在哪里。本文给出一份可直接落地的字段清单，并按执行前、执行中、执行后三个阶段说明填写步骤、角色分工和完成检查标准，帮助团队建立粒度合适、可复核的执行记录。
要点总览（TL;DR）
- 测试执行记录的最小字段集按三层组织：批次层记录版本、构建号、环境与时间；用例执行层记录用例标识与版本、执行人、结果状态、差异与重测标记；证据层记录截图日志与缺陷关联。
- 填写按执行前、执行中、执行后三步推进：执行前登记批次与环境，执行中逐条填写结果并即时留存证据，执行后核对数量、标记异常并完成交接。
- 执行人负责第一手填写，测试负责人负责批次完整性与汇总，复核人独立检查失败证据，开发人员通过缺陷关联参与下游处理。
- 记录是否可用看六项：批次信息齐全、用例状态无空白、失败有差异描述与证据及缺陷关联、阻塞与未执行有原因、重测可追溯、交接信息明确。
- 常见遗漏集中在环境差异、用例版本、证据缺失和重测标记四处，批次结束后记录转只读，补充说明以追加备注方式进行。
一条合格的测试执行记录包含哪些字段
测试执行记录的信息可以按三个层次组织：批次层描述“这一轮测试在什么条件下进行”，用例执行层描述“每条用例执行了什么、结果如何”，证据层描述“凭什么判断这个结果”。字段并非越多越好，判断标准是能否支撑复核、追溯和重跑。以下清单中，必填字段缺失会直接导致记录不可用；选填字段按项目风险和执行场景补充。
| 字段名 | 所属层级 | 填写要求 | 必填/选填 |
|---|---|---|---|
| 执行批次名称/编号 | 批次层 | 唯一标识一轮测试，建议包含迭代或版本信息，便于按批次检索 | 必填 |
| 执行日期与时间 | 批次层 | 记录开始与结束时间，精确到日；跨天执行时保留分段记录 | 必填 |
| 被测版本与构建号 | 批次层 | 填写实际部署的版本号和构建标识，与发布记录对应 | 必填 |
| 测试环境与配置 | 批次层 | 说明环境类型（如测试环境、预发布环境）、操作系统、浏览器、数据库及关键配置差异 | 必填 |
| 测试数据说明 | 批次层 | 记录使用的数据集、账号类型或数据构造方式，便于复现 | 选填 |
| 用例标识与版本 | 用例执行层 | 填写用例编号及用例版本号，确保执行的是当时确认的用例内容 | 必填 |
| 执行人 | 用例执行层 | 填写实际执行人姓名，多人协作时按用例分别记录 | 必填 |
| 执行结果 | 用例执行层 | 从通过、失败、阻塞、未执行中选择，不使用模糊描述 | 必填 |
| 实际结果与预期差异 | 用例执行层 | 失败时写明实际现象与预期的具体差异；通过时可简要记录关键验证点 | 失败必填，通过选填 |
| 证据附件 | 证据层 | 截图、日志片段、接口返回报文等，命名与用例编号对应 | 失败必填，通过按需 |
| 缺陷或问题关联 | 证据层 | 填写缺陷编号或问题链接，建立执行记录与问题单的对应关系 | 失败必填 |
| 重测与回归标记 | 用例执行层 | 标明本次是否为重测、回归执行，以及对应的原始执行记录 | 重测时必填 |
| 阻塞原因 | 用例执行层 | 说明阻塞来源，如环境不可用、依赖功能未就绪、数据缺失 | 阻塞时必填 |
| 备注 | 用例执行层 | 记录执行中的临时调整、特殊操作或需要交接的说明 | 选填 |
批次层字段的价值在于把一组执行结果绑定到同一个版本和环境上，避免出现“结果有了但不知道测的是哪一版”的情况。用例执行层字段解决单条用例的可追溯性，其中用例版本容易被忽略：用例在测试周期内被修改后，如果不记录版本，复核时无法判断当时执行的是哪一版内容。证据层字段则让失败结论有据可查，减少口头描述带来的理解偏差。
按执行流程填写记录的操作步骤
字段清单是静态的，实际填写需要嵌入测试执行流程。下面按执行前、执行中、执行后三个阶段说明每一步的输入、动作、输出和完成标志。
执行前：登记批次、版本与环境
- 输入：本轮测试计划、被测版本发布说明、环境准备清单。
- 动作：创建执行批次，填写批次名称、计划执行时间、被测版本与构建号、测试环境与配置；确认用例集及其版本已冻结。
- 输出：一条信息完整的批次记录，以及待执行的用例清单。
- 完成标志：批次记录中的版本、环境字段无空缺，执行人已明确到人。
执行中：逐条填写结果与证据
- 输入：批次记录、用例步骤与预期结果、测试数据。
- 动作：按用例逐条执行，执行完一条立即填写结果；失败时记录实际结果与预期差异，保存截图或日志并关联缺陷；阻塞时写明阻塞原因；未执行的用例标注原因而非留空。
- 输出：每条用例对应的执行结果、差异描述和证据附件。
- 完成标志：批次内所有用例均有明确结果状态，失败用例均有证据和缺陷关联。
执行后：汇总结果、标记异常并交接
- 输入：本轮全部执行记录。
- 动作：核对通过、失败、阻塞、未执行的数量与用例清单是否一致；对失败用例标注是否待重测；将需要开发处理的问题移交并注明交接时间；补充批次结束时间。
- 输出：一份结果状态完整、异常已标记、交接信息清晰的批次记录。
- 完成标志：结果汇总数量与用例总数吻合，无状态为空的用例，交接对象和时点已记录。
在执行记录需要与用例、计划和缺陷关联管理时，可以借助测试管理工具承载这些信息。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，并支持将用例分配执行人；未通过的用例可快速创建缺陷任务，使执行结果与问题处理之间保留对应关系。这些能力适合把上述字段落到统一的工作项中，具体字段名称和状态选项以团队实际配置为准。
角色分工与各环节交付物
记录责任悬空是执行记录质量下降的常见原因。明确谁填写、谁复核、谁使用，并在关键节点设置交接，可以让记录在测试周期内保持可用。
| 角色 | 主要职责 | 交付物 | 交接与复核时点 |
|---|---|---|---|
| 测试执行人 | 按用例执行并逐条填写结果、差异和证据；标注阻塞与未执行原因 | 单条用例的执行记录、证据附件、缺陷关联 | 每条用例执行完成后即时填写；当日执行结束前自查 |
| 测试负责人 | 创建并维护执行批次；分配执行人；复核记录完整性；汇总结果并组织交接 | 批次记录、结果汇总、异常清单 | 批次开始前确认批次信息；批次结束后复核全部记录 |
| 开发人员 | 接收失败与阻塞信息，确认问题归属；修复后反馈待重测范围 | 问题确认意见、修复说明、待重测清单 | 收到缺陷关联后确认；修复完成后通知测试 |
| 复核人（可由测试负责人或同行担任） | 抽查失败用例的证据充分性与差异描述准确性；核对重测标记 | 复核意见、需补充记录的清单 | 批次结束前完成抽查；重测执行前核对原始记录 |
分工的关键在于把“填写”和“复核”分开。执行人对自己执行的用例最熟悉，负责第一手信息；复核人从第三方视角检查证据是否足以支撑结论。测试负责人承担批次层面的完整性责任，开发人员则通过缺陷关联参与记录的下游使用。团队规模较小时，复核角色可以由测试负责人兼任，但复核动作仍应单独执行并留下意见。
填写示例：一条失败用例的记录长什么样
以下为演示情景，用于说明字段如何组合填写。假设某登录功能用例在测试环境中执行失败。
| 字段 | 填写内容 | 填写理由 |
|---|---|---|
| 执行批次 | 迭代 24.3 回归测试-批次02 | 标明所属迭代与轮次，便于按版本检索 |
| 执行时间 | 2024-06-12 10:20 至 10:35 | 保留执行时段，便于与环境变更时间对照 |
| 被测版本与构建号 | v2.4.0，构建号 20240611-03 | 锁定被测对象，避免与后续构建混淆 |
| 测试环境与配置 | 测试环境，Chrome 124，测试数据库，短信服务为模拟桩 | 说明环境差异，短信桩是本次失败的关键条件 |
| 用例标识与版本 | TC-LOGIN-018，用例版本 v3 | 确认执行的是当前确认版本的用例 |
| 执行人 | 张明 | 便于复核时追溯执行过程 |
| 执行结果 | 失败 | 使用标准状态，不写“有点问题”等模糊描述 |
| 实际结果与预期差异 | 预期输入正确验证码后登录成功；实际提示“验证码已过期”，重新获取验证码后仍复现 | 写明现象与复现条件，支撑问题定位 |
| 证据附件 | 截图 login-018-error.png；接口返回日志 login-018-log.txt | 附件命名与用例编号对应，便于检索 |
| 缺陷关联 | BUG-2317 | 建立执行记录与问题单的对应关系 |
| 重测标记 | 首轮执行，待修复后重测 | 标明当前轮次和后续动作 |
| 备注 | 短信桩返回延迟约 5 秒，可能与验证码有效期有关 | 保留执行中的观察，供开发参考 |
阻塞与未执行的记录方式与失败不同。阻塞用例应填写阻塞原因和影响范围，例如“依赖的支付服务未部署，无法执行”，并注明预计解除条件；未执行用例应写明未执行原因，如“本轮范围外”或“时间不足顺延至下轮”，避免用空白代替状态。两类情形都不需要填写实际结果差异，但都需要保留状态和原因，否则汇总时无法区分“没测”和“测了没过”。
记录完成检查与常见遗漏
判断一份执行记录是否完整可用，可以按以下清单逐项核对。检查对象是批次记录整体，而非单条用例。
- 批次层信息齐全：批次名称、执行时间、被测版本与构建号、测试环境与配置均有填写，且与发布记录一致。
- 用例覆盖完整：批次内用例总数与计划执行数一致，每条用例都有明确结果状态，无空白项。
- 失败记录可复核：每条失败用例均有实际结果与预期差异描述、至少一项证据附件、一个缺陷或问题关联。
- 阻塞与未执行有原因：两类状态均填写了原因，阻塞项注明解除条件或跟进人。
- 重测可追溯：重测记录标注了原始执行记录或缺陷编号，能看出本轮与上一轮的对应关系。
- 交接信息明确：需要开发处理的问题已注明交接对象和时间，批次结束时间已填写。
常见遗漏集中在四处。一是环境差异未记录，例如只在备注里写“环境问题”，没有说明具体配置，导致问题无法复现；二是用例版本缺失，用例在周期内修改后，旧执行结果无法对应到具体版本；三是证据缺失，失败只写一句“不符合预期”，复核时无法判断；四是重测标记缺失，重测结果覆盖了原始记录或与原始记录混在一起，看不出修复前后的对比。这些遗漏都会削弱记录的追溯价值。
记录留存方面，建议执行记录与对应版本的用例、缺陷保持关联，按迭代或发布周期归档，保留时长与团队的质量追溯要求一致。记录在批次结束后进入只读状态，后续补充说明以追加备注的方式进行，避免直接修改原始结果。当执行记录需要与用例库、测试计划和缺陷任务在同一处管理时，ONES 测试管理提供测试情况概览，可查看测试计划的进度和通过率，并支持为用例库、测试计划单独配置权限，便于执行人填写、负责人复核的分工落地。通过率等统计口径以产品实际配置为准，团队应结合自身流程确认字段与状态的对应关系。
常见问题
用例在测试周期内被修改过，执行记录应该记哪个版本？
记录执行当时实际使用的用例版本，而不是最新版本。用例在周期内修改后，旧执行结果对应的是旧版内容，如果只记用例编号，复核时无法判断当时执行的是哪一版。建议在用例执行层固定填写用例编号加版本号，例如 TC-LOGIN-018 v3；用例修改后重新执行时，作为新的执行记录保留，并标注与原始记录的对应关系。这样修复前后的对比才有依据。
执行到一半环境被占用或依赖服务未部署，这类用例怎么记录？
按阻塞状态记录，填写阻塞原因和影响范围，例如“依赖的支付服务未部署，无法执行”，并注明解除条件或跟进人。阻塞用例不需要填写实际结果差异，但状态和原因必须保留，否则汇总时无法区分“没测”和“测了没过”。如果阻塞在批次中途解除，重新执行时按重测处理，标注原始记录，避免覆盖之前的阻塞记录。
团队规模小，执行人同时兼任复核，记录质量怎么保证？
复核角色可以由测试负责人兼任，但复核动作应单独执行并留下意见，例如在批次结束后集中抽查失败用例的证据是否充分、差异描述是否准确。关键是填写与复核在时间上分开：执行时专注记录第一手信息，批次结束后再以第三方视角检查。抽查比例可以按失败用例数量确定，失败用例少时逐条检查，数量多时至少覆盖高风险模块。
执行记录需要保留多久，批次结束后还能修改吗？
保留时长与团队的质量追溯要求一致，通常按迭代或发布周期归档，并与对应版本的用例、缺陷保持关联。批次结束后建议将记录转为只读，后续补充说明以追加备注的方式进行，不直接修改原始结果。这样既保留了当时的执行事实，也能记录后续发现的信息。如果确实需要更正错误，应保留更正痕迹和更正人。
执行记录里的缺陷关联要写到什么程度，修复验证也记在这里吗？
执行记录只需保留缺陷编号或问题链接，建立执行结果与问题单的对应关系即可，例如填写 BUG-2317。缺陷的修复过程、修复验证和关闭判断属于缺陷修复与验证跟踪的范围，不在执行记录中展开。重测时在执行记录中标注本次为重测、对应哪条原始记录或哪个缺陷编号，这样执行记录与缺陷处理各自职责清晰，又能通过编号互相追溯。
