测试执行记录示例要回答的是“这一轮测试里，谁在什么环境执行了哪条用例、结果如何、证据在哪”。下面用一次登录与订单提交的演示测试轮次，给出一张可直接照着填的执行记录表，并逐项说明字段填写口径、换项目时的调整方法以及示例的适用边界。示例为演示情景，不涉及真实客户数据。
要点总览（TL;DR）
- 测试执行记录的核心字段是：用例编号、执行人、执行时间、环境与构建版本、实际结果、状态、证据、缺陷编号，失败项通过缺陷编号与缺陷系统建立指向关系。
- 状态固定为通过、失败、阻塞、未执行四类；失败说明产品行为与预期不一致，阻塞说明本次执行未完成，两者不能混用。
- 实际结果写观察到的现象，证据按现象给截图、日志或接口响应，缺陷编号只做关联，修复过程放在缺陷系统中。
- 换项目时保持状态与证据口径不变，按测试层级增删字段：接口测试补请求参数与响应码，性能测试补并发数与响应时间。
- 示例为演示情景，探索性测试、性能测试等场景需要调整记录单位或补充专门字段，执行记录也不替代缺陷跟踪与测试报告。
示例要解决什么问题：一份能直接照着填的执行记录
很多团队在测试执行阶段并不缺用例，缺的是一份能说明执行过程的记录：用例写完了，执行情况散落在聊天记录、截图文件夹和个人笔记里，等到要追溯某条失败是哪个构建、在什么环境下出现的，往往只能靠回忆。本文的示例针对这一环节，给出一个可以照着填写的模板。
演示情景设定如下：某项目进入一轮功能测试，测试范围包含登录与订单提交两条主流程，共安排六条用例，由两名测试人员在同一轮次内完成执行。记录对象是这一轮次内的用例执行动作，每条记录对应一条用例的一次执行。
这份记录需要回答四个问题：
- 谁执行的：执行人是谁，便于后续追问和交接。
- 在什么环境执行：环境与构建版本，决定结果能否复现。
- 执行了什么、结果如何：用例编号与名称、实际结果、状态。
- 证据在哪：截图、日志或请求响应存放在哪里，失败项关联哪个缺陷编号。
需要说明边界：本文只覆盖测试运行过程的记录填写。失败项对应的缺陷如何修复、修复后如何验证关闭，属于缺陷跟踪环节；本轮执行结果如何汇总成测试报告、如何评估质量，属于报告与评估环节，这两部分不在本文展开。
完整示例：一轮测试的执行记录表
下表为上述演示情景的已填写执行记录，六条用例覆盖通过、失败、阻塞三种状态。表中数据均为示例构造，用于说明填写方式。
| 用例编号 | 用例名称 | 执行人 | 执行时间 | 环境/构建 | 实际结果 | 状态 | 证据 | 缺陷编号 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
| TC-LOGIN-001 | 正确账号密码登录 | 李敏 | 2025-03-11 10:05 | 测试环境 / v2.4.0-rc1 | 输入正确账号密码后跳转首页，右上角显示当前用户名 | 通过 | 截图 login-001-pass.png | — | |
| TC-LOGIN-002 | 错误密码登录提示 | 李敏 | 2025-03-11 10:12 | 测试环境 / v2.4.0-rc1 | 输入错误密码后页面无任何提示，停留在登录页 | 失败 | 截图 login-002-fail.png；控制台日志 login-002.log | BUG-1032 | 预期应提示“密码错误” |
| TC-LOGIN-003 | 连续五次错误密码锁定 | 李敏 | 2025-03-11 10:20 | 测试环境 / v2.4.0-rc1 | 未执行到锁定判断，依赖 TC-LOGIN-002 的提示逻辑 | 阻塞 | — | — | 阻塞原因：BUG-1032 未修复；解除条件：BUG-1032 修复并回归通过后重跑 |
| TC-ORDER-001 | 单商品正常下单 | 王磊 | 2025-03-11 14:02 | 测试环境 / v2.4.0-rc1 | 选择商品、填写地址、提交订单后生成订单号，订单列表可见该订单 | 通过 | 截图 order-001-pass.png；接口响应 order-001.json | — | |
| TC-ORDER-002 | 库存不足时下单 | 王磊 | 2025-03-11 14:18 | 测试环境 / v2.4.0-rc1 | 库存为 0 时点击提交，订单仍创建成功，库存变为 -1 | 失败 | 截图 order-002-fail.png；接口响应 order-002.json | BUG-1035 | 涉及库存扣减逻辑 |
| TC-ORDER-003 | 优惠券抵扣金额校验 | 王磊 | 2025-03-11 14:35 | 测试环境 / v2.4.0-rc1 | 优惠券服务未部署到当前环境，无法验证抵扣金额 | 阻塞 | — | — | 阻塞原因：环境缺少优惠券服务；解除条件：环境补齐服务后重跑 |
这张表体现了几条对应关系。失败项 TC-LOGIN-002 与 TC-ORDER-002 分别关联 BUG-1032 和 BUG-1035，缺陷编号只做指向，修复过程在缺陷系统中进行。阻塞项 TC-LOGIN-003 的阻塞原因是被依赖用例的缺陷未修复，解除条件是缺陷回归通过；TC-ORDER-003 的阻塞原因是环境缺服务，解除条件是环境补齐。两类阻塞的解除条件不同，备注中分别写明，便于下一轮判断能否重跑。
当执行记录需要多人协作、跨轮次追溯时，表格可以迁移到测试管理工具中承载。以 ONES 测试管理为例，用例执行后可记录执行结果与状态，失败项可关联缺陷工作项，执行记录随测试计划保留，便于按轮次查看和统计。具体字段配置以团队实际使用的版本为准。
逐项解释：每个字段为什么这样填
表格本身只是结果，字段口径才是可复用的部分。以下逐项说明填写依据，并给出常见正误对照。
状态取值口径
状态字段最容易出现口径不一。建议固定为四类：
- 通过：实际结果与预期一致，用例的全部步骤执行完毕。
- 失败：执行完毕，实际结果与预期不一致。
- 阻塞：因环境、依赖缺陷或数据缺失等原因无法执行或无法判定结果。
- 未执行：本轮次尚未安排或尚未开始执行。
常见错误是把“无法判定”写成失败，导致失败率虚高；或者把“执行了一部分发现前置条件不满足”写成通过。阻塞与失败的区别在于：失败说明产品行为有问题，阻塞说明这次执行本身没有完成。
环境与构建版本
环境与构建版本必须记录，原因是同一用例在不同构建上的结果可能不同。缺少这一字段，失败项无法复现，通过项也无法说明验证的是哪个版本。填写时写到可定位的粒度，例如“测试环境 / v2.4.0-rc1”，避免只写“测试环境”。
实际结果写现象而非结论
实际结果应描述观察到的现象，例如“页面无任何提示，停留在登录页”，而不是“登录功能有问题”。现象可以复核，结论带有判断，容易掩盖细节。若预期与实际差异需要说明，放在备注中写“预期应提示密码错误”，与现象分开。
证据链接的粒度
证据按失败项和关键通过项提供，粒度与现象对应：界面问题给截图，逻辑问题给日志或接口请求响应。示例中 TC-ORDER-002 同时给了截图和接口响应，因为库存扣减问题需要从响应中看到库存字段的变化。通过项不必逐条附证据，保留关键路径的截图即可。
缺陷编号只做关联
缺陷编号字段的作用是建立执行记录与缺陷之间的指向关系，填写缺陷系统中的编号即可。缺陷的描述、严重程度、修复状态在缺陷系统中维护，执行记录中不重复展开，避免两处信息不一致。
备注字段的用途与滥用风险
备注适合写三类内容：预期与实际的差异说明、阻塞原因与解除条件、需要下一轮关注的信息。风险在于把备注当成第二个实际结果字段，把现象、判断、待办混在一起，导致后续统计时无法区分。建议备注只写补充信息，核心结论仍放在状态和实际结果中。
可迁移规律：换项目、换团队怎么改这张表
这张表的结构可以拆成两层：稳定层和可调层。稳定层是状态取值与证据口径，换项目时保持不变；可调层是字段的增减，按测试层级和团队协作方式调整。
按测试层级调整字段
功能测试以界面操作为主，截图是主要证据，实际结果侧重页面表现。接口测试没有界面，证据以请求响应和日志为主，可增加“请求参数”“响应码”字段，实际结果写返回内容与断言结果。性能测试则需要补充并发数、响应时间、资源占用等指标字段，这些字段在功能测试表中没有位置。
按团队规模决定人员字段
小团队中执行人往往就是用例负责人，保留执行人字段即可。当执行与复核分离时，可增加“复核人”和“复核结论”字段，用于记录第二人确认的结果。团队规模扩大后，还可增加“所属测试计划”或“轮次”字段，便于按轮次汇总。字段增加的前提是有人真正填写和维护，否则会变成空列。
状态与证据口径保持稳定
无论字段如何增删，状态的四类取值和证据的粒度标准应保持一致。这样不同项目、不同轮次的记录才能放在一起统计，例如计算通过率、阻塞率，或按缺陷编号追溯某条失败用例的历次执行结果。字段可以随项目变化，口径变化会让历史数据失去可比性。
迁移时的检查点可以归纳为：新表是否仍能回答“谁、在哪、执行了什么、结果如何、证据在哪”五个问题；状态取值是否与原有口径一致；失败项是否都能关联到缺陷编号；阻塞项是否都写明了原因和解除条件。
适用边界：示例不能直接照搬的情况
首先需要明确，本文表格为演示情景构造，不是真实客户案例，也不代表任何实测成效。表中的项目名称、人员、缺陷编号均为示例，读者应替换为自己项目的实际信息。
其次，示例面向功能测试的手工执行场景。探索性测试没有预设用例步骤，执行记录更适合以“测试会话”为单位，记录探索范围、发现的问题和耗时，直接套用逐条用例的表格会显得笨重。性能测试、安全测试等需要专门指标和工具输出的场景，也应在示例基础上补充对应字段。
第三，执行记录与缺陷跟踪、测试报告有明确分工。执行记录回答“这一轮执行了什么、结果如何”，缺陷跟踪回答“问题如何修复、何时关闭”，测试报告回答“整体质量如何、能否发布”。把修复过程写进执行记录，或把执行表直接当报告使用，都会让记录变得臃肿且难以维护。
最后是记录粒度的权衡。逐条用例记录能提供最完整的追溯能力，但填写成本随用例数量上升。用例规模较大时，可以对通过项简化证据、只对失败和阻塞项详细记录；也可以按测试计划分批记录。粒度选择应结合团队协作成本和后续追溯需求，在两者之间取一个可持续执行的平衡点。
常见问题
一轮测试里既有通过项也有阻塞项，执行记录应该按用例逐条记，还是按测试轮次汇总记？
建议以用例为最小记录单位，再按轮次汇总。逐条记录保留了每条用例的执行人、环境、实际结果和证据，失败与阻塞项的原因也能落到具体用例上；轮次信息可以作为一列或一个分组维度附加在记录上，例如标注所属测试计划或轮次编号。这样既能在单轮内查看执行进度，也能跨轮次追溯同一条用例的历次结果。若用例数量很大，可以对通过项简化证据，只对失败和阻塞项保留完整记录。
阻塞项在下一轮重跑后，原记录应该修改还是新增一条？
建议新增一条执行记录，保留原阻塞记录不动。原记录中的阻塞原因和解除条件是判断这一轮执行状态的依据，直接改写会让历史轮次的数据失真。新增记录时填写新的执行时间、环境与构建版本、实际结果和状态，并在备注中注明“重跑原阻塞项”或关联原记录编号。这样通过率、阻塞率等统计才能按轮次分别计算，也能看出某个阻塞项从出现到解除经历了几个轮次。
团队已经有缺陷管理系统，执行记录里的缺陷编号字段还有必要保留吗？
有必要，但只作为指向关系使用。缺陷系统记录缺陷的描述、严重程度、负责人和修复状态，执行记录记录的是“这条用例这次执行失败了，对应哪个缺陷”。两者通过缺陷编号关联后，可以从执行记录直接找到缺陷，也可以从缺陷反查影响到的用例。填写时只写编号，不复制缺陷详情，避免两处信息不一致。若团队使用测试管理工具承载执行记录，失败项通常可以直接关联缺陷工作项，关联关系随执行记录一起保留。
探索性测试没有预设用例，执行记录该怎么记？
探索性测试适合以测试会话为单位记录，而不是逐条用例。一条会话记录可以包含探索的功能范围、时间盒、执行人、使用的环境和构建、发现的问题及对应缺陷编号、未覆盖的区域。会话内部的具体操作步骤可以简要记录在备注或附带的探索笔记中。这样既保留了可追溯的信息，也不会因为强行套用逐条用例的表格而增加无效填写。若团队同时有手工用例和探索性测试，可以在同一张表中用不同的记录类型区分。
执行记录填写到什么粒度比较合适，会不会增加测试人员负担？
粒度取决于后续要回答什么问题。如果只需要知道某轮哪些用例通过、哪些失败，记录到用例级别并保留失败项证据即可；如果需要复现问题或做质量分析，环境、构建版本和实际结果的现象描述就不能省略。控制成本的做法是分层：通过项记录状态和关键路径截图，失败项记录完整现象与证据，阻塞项写清原因和解除条件。填写字段一旦确定，应保证有人维护，长期空置的列可以删掉，避免表格越来越宽但信息没有增加。
