测试执行记录、测试日志和执行证据常在同一轮测试中同时出现，区分的关键在于各自承担的回答任务不同：执行记录回答“谁在什么环境、按哪条用例、何时执行、结果如何、证据在哪里”，日志保留执行过程中按时间产生的原始输出，证据则是支撑结论的留存材料。三者构成记录层、原始层与凭证层的关系，执行记录引用后两者，日志和证据本身不替代执行记录。本文围绕这一区分口径，说明字段边界、留存方式，以及设计记录体系时如何避免同一信息反复录入。
要点总览（TL;DR）
- 测试执行记录是记录层，按“一次执行”登记用例、轮次、执行人、环境、版本、结果状态和证据引用；测试日志是原始层，由系统或脚本按时间顺序输出；执行证据是凭证层，用于独立复核结论。
- 执行记录建议保留用例与轮次标识、执行人与时间、环境与构建版本、结果状态、日志与证据引用；日志全文、缺陷修复过程和报告汇总结论不写入执行记录正文。
- 日志应原样归档，保持原始性与时间顺序；证据要自带定位信息，截图含时间与环境、日志片段保留上下文，两者集中存放、执行记录只保留引用。
- 避免重复记录的原则是“一次录入、多处引用”：日志与证据只存一份，不通过时从执行记录直接创建缺陷，报告从执行记录汇总统计。
- 常见误解是日志全文贴进执行记录、截图代替执行结论；正确做法是执行记录写结论，日志与证据作为支撑材料关联。
三者各自的定义与核心区别
测试执行记录是对一次测试运行的过程性登记。它以“一次执行”为单位，把用例、执行轮次、执行人、环境、构建版本、结果状态和证据引用组织在一起，让后续查看者不必翻找原始材料就能判断这轮测试做了什么、结论是什么。执行记录通常由执行人填写或由测试管理工具生成，属于结构化信息。
测试日志是执行过程中按时间顺序产生的原始输出与事件流，例如自动化脚本的控制台输出、接口请求与响应序列、服务端运行日志片段、客户端崩溃堆栈。日志由被测系统、测试脚本或运行环境产生，特点是原始、连续、技术细节密集，阅读成本较高，但能还原执行当时的真实状态。
执行证据是能够支撑某个结论的留存材料，如界面截图、关键日志片段、导出的报告文件、操作录屏。判断一份材料是否构成证据，看它能否被独立复核：看到这份材料的人，能否在不依赖执行人口头说明的情况下确认结果成立。证据强调完整性，例如截图应包含时间、环境标识和关键界面状态，日志片段应保留上下文而非只截一行报错。
三者的关系可以用一句话概括：执行记录是记录层，日志是原始层，证据是凭证层。执行记录引用日志与证据的位置，日志和证据为执行记录中的结论提供支撑。缺少执行记录，日志和证据散落各处难以按轮次检索；缺少日志和证据，执行记录中的“通过”或“不通过”就缺少可复核依据。
| 维度 | 测试执行记录 | 测试日志 | 执行证据 |
|---|---|---|---|
| 回答的问题 | 谁、何时、在什么环境、按哪条用例执行，结果如何 | 执行过程中系统与脚本实际输出了什么 | 凭什么确认这个结果成立 |
| 产生主体 | 执行人填写，或测试管理工具按执行动作生成 | 被测系统、测试脚本、运行环境 | 执行人主动留存，或工具自动归档 |
| 内容形态 | 结构化字段与状态 | 按时间排列的原始文本与事件 | 截图、日志片段、报告文件、录屏 |
| 主要用途 | 跟踪执行进度、汇总结果、支撑报告 | 定位问题、还原执行现场 | 复核结论、应对争议与审计 |
| 层次定位 | 记录层 | 原始层 | 凭证层 |
测试执行记录包含哪些执行过程信息
执行记录的字段设计应围绕“一次执行可被独立理解”展开，字段数量可以按团队流程裁剪，但以下几类信息建议保留，否则记录会退化为只有结论、无法追溯的空壳。
- 用例与执行轮次标识：用例编号或名称、所属测试计划、第几轮执行。同一用例多轮执行时，轮次标识决定记录之间不会互相覆盖。
- 执行人与时间：实际执行人、执行开始与完成时间。跨时区或跨团队协作时，时间口径需统一。
- 环境与构建版本：测试环境名称、被测版本号或构建号、必要的配置差异说明。结论只在特定环境下成立，这一字段是结论有效性的前提。
- 执行结果与结论状态：通过、不通过、阻塞、跳过等状态，以及不通过时的简要现象描述。现象描述写可观察到的表现，详细分析留给缺陷记录。
- 关联的日志与证据引用：日志文件位置或链接、截图与附件的引用标识。引用而非复制，是控制记录体积和避免重复的关键。
执行记录也有明确的边界。日志全文、完整请求响应报文、大段堆栈信息不纳入执行记录正文，它们属于原始层，应以附件或链接方式关联。缺陷的修复过程、责任人和验证结论属于缺陷记录，执行记录只保留“该次执行不通过并已创建缺陷”这一衔接信息。测试报告的汇总统计与质量评估结论属于报告层，执行记录提供明细，不承担汇总职责。
测试日志与执行证据的边界和留存方式
日志的核心特征是原始性与时间顺序。它按事件发生的先后排列，保留执行当时的完整上下文，包括正常输出和异常输出。日志一旦被裁剪、摘要或改写，就失去了原始层的作用，因此日志应原样归档，分析结论写在执行记录或缺陷记录中，而不是回写进日志文件。
证据的核心特征是可复核性与完整性。一份截图如果只截了报错弹窗、没有环境标识和操作路径，复核者无法判断它来自哪次执行；一段日志如果只保留最后一行异常，无法确认前序请求是否正常。留存证据时，应让材料自带定位信息：截图包含时间与界面状态，日志片段保留前后若干行上下文，录屏覆盖完整操作路径。
存储位置上，日志与证据适合集中存放在可长期访问的位置，执行记录中只保留引用。保留期限需要结合项目周期、合规要求和问题回溯需求确定：版本发布后仍需支持问题复现的周期内，相关日志与证据应保持可访问；超出回溯需求的历史材料可按团队策略归档或清理。哪些内容属于日志而非证据，可以用产生方式判断：由系统或脚本自动输出、未经人工挑选的连续记录属于日志；经执行人挑选、用于支撑特定结论的材料属于证据。同一份日志文件被截取一段作为证据时，截取片段是证据，完整文件仍是日志。
与相邻概念的区分：缺陷记录、测试报告
执行记录与缺陷记录的衔接点在“不通过”这一状态。一次执行不通过时，执行记录保留结果状态和现象描述，并关联由该次执行创建的缺陷；缺陷记录随后承载复现步骤、严重程度、修复过程与验证结论。两者通过关联关系衔接，各自维护自己的字段，避免把修复讨论写进执行记录，也避免在缺陷记录里重复登记执行环境与轮次。
测试报告与执行记录是汇总与明细的关系。报告从多轮执行记录中统计通过率、缺陷分布和风险结论，执行记录则是这些统计的原始明细来源。报告中的每个数字应能回溯到具体执行记录，执行记录不重复承载报告的结论性判断。
本文聚焦三个概念的区分与记录体系设计，缺陷修复闭环与验证跟踪、测试报告与质量评估的具体方法不在展开范围内，相关衔接仅说明边界位置。
设计记录体系时如何避免重复记录
避免重复记录的核心原则是“一次录入、多处引用”：每类信息只在它最自然的产生位置录入一次，其他位置通过引用关联。执行记录录入结构化字段和结论，日志与证据在原位保存一份，执行记录中保留链接或引用标识，报告从执行记录汇总，缺陷从执行记录创建并反向关联。
落地时可以按以下分工组织：
- 执行人在执行记录中填写用例、轮次、环境、版本、结果状态和现象描述，完成一次录入。
- 日志由脚本或环境自动输出并归档，执行记录只登记日志位置，不粘贴全文。
- 证据由执行人按结论需要留存，截图与附件挂在执行记录或缺陷上，保留一份。
- 不通过时从执行记录直接创建缺陷，缺陷继承环境与轮次信息，不再手工重填。
- 报告按计划或版本从执行记录汇总，统计口径统一取自执行记录字段。
两种常见误解需要纠正。其一，把日志全文贴进执行记录：这会让记录体积膨胀、检索困难，且日志更新后记录中的副本随即过期，正确做法是保留引用。其二，把截图当作执行结论：截图只能证明某个瞬间的界面状态，无法说明执行了哪条用例、覆盖了哪些步骤，结论仍应写在执行记录的结果字段中，截图作为支撑材料关联。
以一个执行轮次为例：某版本回归测试中，执行人按用例“订单提交后库存扣减”在预发布环境执行，构建号为当日版本，结果为不通过，现象为库存数量未变化。执行记录登记用例编号、第二轮执行、执行人、环境与构建号、不通过状态和现象描述，并关联接口日志文件位置与两张关键截图；随后从该记录创建缺陷，缺陷中补充复现步骤与请求报文。整个过程中，日志只归档一份，截图只上传一次，环境与版本信息只录入一次，报告统计直接读取执行记录状态。这样一轮执行产生的信息各归其位，回溯时从执行记录出发即可找到全部原始材料。
在测试管理工具中落地这套分工时，执行记录通常对应测试计划下的用例执行工作项，日志与截图作为附件或关联内容挂载，缺陷从执行记录直接创建并在测试与研发之间流转。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，支持将用例分配执行人，未通过的用例可快速创建缺陷任务，并提供测试计划的多维度进度概览。这些能力可以承载执行记录的结构化登记与引用关系；执行记录的具体字段结构、日志与证据的存储保留机制，需结合产品文档或实际试用确认后再定方案。
常见问题
同一用例多轮执行时，执行记录应该覆盖旧记录还是每轮单独留一条？
建议每轮执行单独留一条记录，用轮次标识区分，而不是覆盖上一轮。覆盖会让历史结论失去追溯依据，也无法解释同一用例在不同构建版本下结果变化的原因。轮次标识与构建版本、执行时间一起构成记录的唯一性基础，报告统计时按轮次汇总即可。
自动化测试产生的日志很长，执行记录里需要保留多少？
执行记录正文不需要保留日志内容，登记日志文件的存放位置或链接即可。日志由脚本自动输出并原样归档，保持原始性与时间顺序。如果某个结论需要引用日志中的具体片段，把该片段截取为证据挂在执行记录上，完整日志文件仍作为原始层保留，两者不互相替代。
截图作为执行证据，需要满足什么条件才算可复核？
截图应自带定位信息：能看出执行时间、测试环境标识和关键界面状态，必要时配合操作路径说明。只截一个报错弹窗、没有环境和步骤信息的截图，复核者无法判断它来自哪次执行。截图证明的是某个瞬间的界面状态，执行了哪条用例、覆盖哪些步骤仍应写在执行记录的结果字段中。
执行记录、日志和证据的保留期限应该怎么定？
保留期限结合项目周期、合规要求和问题回溯需求确定。版本发布后仍需支持问题复现的周期内，相关日志与证据应保持可访问；超出回溯需求的历史材料可按团队策略归档或清理。执行记录作为结构化登记，通常需要覆盖报告统计和审计所需的时间跨度，具体期限由团队与合规要求共同决定。
用测试管理工具落地这套分工时，需要重点确认哪些能力？
重点确认三件事：执行记录能否按用例和轮次结构化登记并关联环境与版本；日志、截图等材料能否作为附件或关联内容挂载而不必复制进记录正文；不通过时能否从执行记录直接创建缺陷并继承环境与轮次信息。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，支持将用例分配执行人，未通过的用例可快速创建缺陷任务，并提供测试计划的多维度进度概览。执行记录的具体字段结构、日志与证据的存储保留机制，建议结合产品文档或实际试用确认后再定方案。
