测试执行记录围绕一次测试运行留下可追溯的过程信息，核心回答“谁、在什么环境、按哪版用例、对哪个构建、执行了什么、得到什么结果、何时完成、异常如何处置”。设计记录体系时，容易把系统日志、截图附件、缺陷处理过程和报告结论一并塞入，造成重复。本文给出可直接使用的定义、分组字段清单，并说明执行记录与测试日志、执行证据的边界，帮助你把记录范围定在过程判断所需的信息上。ONES 可作为承载执行记录字段与状态流转的管理工具，下文在相关管理动作处自然衔接。
要点总览（TL;DR）
- 测试执行记录是围绕一次测试运行的结构化过程信息集合，核心回答谁、何时、在什么环境、按哪版用例、对哪个构建、执行了什么、得到什么结果、异常如何处置。
- 记录字段可按运行上下文、执行对象、执行结果、异常与关联四组组织；执行人、时间、环境、构建是追溯的最小集合。
- 测试执行记录承载结论与索引，测试日志提供原始运行细节，执行证据提供截图、报文等证明材料，三者互补而不互相替代。
- 缺陷修复闭环、测试报告结论、用例设计正文和日志全文各有归属环节，执行记录只保留编号或链接引用，避免同一信息多处维护。
- 字段粒度应结合团队执行方式确定：手工执行偏重步骤级状态与实际结果描述，自动化执行偏重批次、构建标识与失败步骤定位。
测试执行记录是什么：一句话定义与核心范围
测试执行记录是对一次测试运行过程的结构化描述，它把执行批次、构建版本、环境配置、用例版本、步骤级状态、实际结果、执行人与时间、异常处置等信息组织在一起，用于回答“这次运行是否可信、结果能否追溯、问题出在哪里”。
它回答的核心问题可以拆成一组：
- 谁执行的，在什么时间执行，耗时多少；
- 在什么测试环境和配置下执行；
- 依据哪一版用例、针对哪个构建或版本；
- 执行了哪些用例和步骤，各自得到什么状态；
- 实际结果与预期是否存在偏差，偏差如何描述；
- 未执行、跳过或阻塞的原因是什么；
- 异常关联到哪个缺陷或问题编号。
测试执行是动作本身，测试结果跟踪是对状态和结论的持续关注，测试执行记录则是两者之间的载体：执行产生记录，跟踪读取记录并推动后续处置。记录的质量决定了跟踪是否有据可依，也决定了事后回溯能否还原当时的判断条件。
记录哪些执行过程信息：按字段分组的过程信息清单
设计记录体系时，可以按“运行上下文—执行对象—执行结果—异常与关联”四类分组组织字段。每组字段服务于一个具体判断，避免为记录而记录。
| 字段组 | 示例字段 | 服务的判断 |
|---|---|---|
| 执行批次与构建/版本标识 | 批次编号、构建号、代码分支或提交标识、被测版本号 | 确认这批结果对应哪个可交付物，支持按版本追溯和回归对比 |
| 测试环境与配置 | 环境名称、操作系统与浏览器版本、数据库版本、服务地址、特殊配置项 | 判断结果是否可复现，区分环境问题与产品问题 |
| 用例标识、版本与步骤级状态 | 用例编号、用例版本、步骤序号、步骤状态（通过/失败/阻塞/跳过/未执行） | 定位失败发生在哪一步，确认执行依据的用例版本是否最新 |
| 实际结果与预期偏差 | 实际现象描述、预期结果、偏差说明、错误码或提示信息摘要 | 支撑失败判定，为缺陷描述提供原始素材 |
| 执行人与时间 | 执行人、开始时间、结束时间、单步或单用例耗时 | 明确责任人与执行节奏，支持进度统计和工时分析 |
| 阻塞、跳过、未执行原因 | 原因分类、原因说明、关联依赖项 | 区分“没测”和“测了没过”，避免覆盖率被误读 |
| 关联缺陷或问题编号 | 缺陷编号、问题单链接、关联状态引用 | 把失败结果与后续处置连接起来，不重复记录处置过程 |
字段粒度需要与团队规模和执行频率匹配。手工执行占比较高时，步骤级状态和实际结果描述更有价值；自动化执行占比较高时，批次、构建标识和失败步骤的定位信息更关键。无论哪种情况，执行人、时间、环境和构建这四项都应保留，它们是追溯的最小集合。
在工具承载层面，ONES 支持将测试用例与执行任务关联，记录执行状态、执行人和执行时间，并可将失败结果关联到缺陷工作项，使上述字段组在同一处形成可查询的记录。这类承载方式适合需要按批次和版本回溯执行情况的团队，具体字段配置仍应结合自身流程确定。
边界在哪里：哪些内容不属于测试执行记录
执行记录的范围止于“这次运行发生了什么”。以下内容有各自的归属环节，执行记录只保留引用，不复制正文。
- 缺陷修复与验证闭环：缺陷的指派、修复提交、复测结论属于缺陷跟踪流程。执行记录保留缺陷编号和当前状态引用即可，修复讨论和变更历史留在缺陷单中。
- 测试报告与质量评估结论：通过率统计、质量趋势、发布建议属于报告环节。执行记录提供原始状态数据，报告在此基础上汇总，两者不互相替代。
- 测试计划与用例设计：测试范围、策略、用例步骤和预期结果的编写属于前置产物。执行记录引用用例编号和版本，不重复存放用例全文。
- 原始日志与证据材料：系统输出、截图、报文等材料体量大、格式杂，适合存放在附件库或日志系统中，执行记录保存引用位置和必要摘要。
划清边界的实际收益是减少维护成本：同一信息只在一个地方维护，其他环节通过编号或链接引用。当缺陷状态变化或报告结论更新时，执行记录不需要同步改写，追溯链仍然完整。
测试执行记录、测试日志与执行证据的区别
三者经常被混用，但产生方式、形态和用途不同。用同一口径对照，可以看清各自承载什么、如何配合。
| 维度 | 测试执行记录 | 测试日志 | 执行证据 |
|---|---|---|---|
| 定义 | 围绕一次运行的结构化过程信息集合 | 系统或工具在运行中自动产生的原始输出 | 支撑结论的截图、报文、附件等材料 |
| 产生方式 | 执行人填写或工具按字段采集，含人工判断 | 程序自动写入，通常未经整理 | 执行过程中截取或导出，人工选择保留 |
| 主要用途 | 判断结果可信度、支持追溯与统计 | 排查具体错误、还原运行细节 | 证明现象确实发生，支撑失败判定 |
| 相互关系 | 记录中引用日志位置和证据附件，保存结论性状态 | 作为记录的底层依据，不进入记录正文 | 作为记录的附件或链接，按需调取 |
配合方式可以概括为：执行记录给出“结论和索引”，日志和证据提供“细节和证明”。例如某步骤判定失败，记录中写明失败状态、实际现象摘要和缺陷编号，同时附上日志片段位置和截图链接；复查时先看记录定位问题，再按引用调取原始材料。这样记录保持轻量，细节又不丢失。
避免重复记录：一个执行批次的记录示例
以下为演示情景：某团队在构建号 build-20240612-3 上执行一组登录相关用例，用于说明记录项与引用项的区分。
记录项（写入执行记录）：
- 批次编号 EXE-0612-01，构建号 build-20240612-3，被测版本 v2.4.0；
- 环境：测试环境 test-02，Chrome 125，测试库版本与配置说明；
- 用例 TC-LOGIN-001 至 TC-LOGIN-008，用例版本 v3；
- 步骤级状态：TC-LOGIN-003 第 4 步失败，其余通过；TC-LOGIN-007 因依赖服务未就绪标记阻塞；
- 实际结果摘要：输入正确凭证后提示“会话创建失败”，预期为跳转首页；
- 执行人、开始与结束时间、总耗时；
- 关联缺陷 BUG-2214，状态引用为“待修复”。
引用项（只存位置，不复制内容）：
- 失败步骤的完整服务端日志，存放在日志系统，记录中保存查询标识；
- 失败页面截图和接口报文，作为附件挂在执行记录或缺陷单上；
- 缺陷 BUG-2214 的修复讨论和复测结论，留在缺陷跟踪流程中；
- 本批次的通过率与发布建议，留给测试报告汇总。
常见误解有三类：把日志全文粘贴进执行记录，导致记录臃肿且难以比对；把缺陷从发现到关闭的全过程写进记录，与缺陷单形成两份事实；把报告结论提前写进记录，使记录承担了评估职能。三者都会造成同一信息多处维护，状态变化时容易不一致。
可迁移的原则是：执行记录只写“这次运行的事实与判断”，凡是有独立归属环节的信息，一律用编号或链接引用；引用要稳定可查，避免只写“见截图”而不留位置。按此原则设计字段，记录体系既能支撑追溯，也不会随关联环节的变化而反复返工。
常见问题
测试执行记录和测试用例是什么关系，记录里需要复制用例步骤吗？
不需要复制用例全文。用例设计属于前置产物，执行记录引用用例编号和用例版本即可，步骤级状态按步骤序号记录。这样用例修订后，执行记录仍能通过版本号对应到当时依据的用例内容，避免两处维护同一份步骤描述。
如果团队需要保留执行当时的步骤快照，可以在记录中保存用例版本的引用标识，由用例库保留历史版本，执行记录不重复存放正文。
自动化测试产生的执行结果，还需要人工填写执行记录吗？
取决于记录要支撑的判断。自动化执行通常由工具自动写入批次、构建标识、用例状态和失败步骤，人工补充的重点是失败原因归类、环境异常说明和关联缺陷编号。人工判断部分无法由日志自动得出，仍需在执行记录中体现。
建议把自动采集字段与人工填写字段分开设计，自动字段保证完整性和一致性，人工字段聚焦解释性信息，减少重复录入。
执行记录中的环境信息要记到什么程度？
以“结果能否复现”为判断标准。至少记录环境名称、操作系统与浏览器或客户端版本、被测服务版本和影响结果的关键配置项。与本次执行无关的通用配置可以引用环境说明文档，不必逐条抄录。
当失败与环境相关时，再补充数据库版本、依赖服务状态等细节。环境信息过粗会导致问题无法复现，过细则增加每次执行的填写负担，按失败排查的实际需要取舍。
执行记录里的缺陷编号状态变化后，需要回头更新记录吗？
通常不需要同步改写执行记录。记录保存的是执行当时的事实和缺陷编号引用，缺陷的修复、复测和关闭状态在缺陷跟踪流程中维护。查看时通过编号跳转到缺陷单获取最新状态，两边各自保持单一事实来源。
如果团队需要在执行视图中直接看到缺陷当前状态，可由工具按编号做状态引用展示，避免人工复制状态值造成不一致。
小团队执行频率不高，字段清单可以精简到哪些？
可以保留最小集合：执行人、执行时间、环境、构建或版本、用例编号与版本、执行状态、实际结果摘要、关联缺陷编号。阻塞和跳过原因在有发生时补充记录，耗时统计按需保留。
精简的依据是这些字段支撑追溯和失败定位；通过率统计、质量趋势等结论留给报告环节汇总，不必在执行记录中提前计算。
