本文给出一条可直接照抄结构的测试执行记录示例，演示一条登录用例在同一轮次中分别以通过和失败两种结果留痕的填写方式。示例中的版本号、环境、执行人和时间均为演示设定，不代表任何真实项目；范围限于测试运行过程的记录填写，缺陷修复闭环与测试报告编制不在本文展开。记录需要承载在用例与工作项对象上时，ONES 测试管理支持用例分配执行人、未通过用例快速创建缺陷任务，可作为落地参考。
要点总览（TL;DR）
- 示例采用“一条用例一次执行”的粒度，每次执行单独成条，保留每轮历史，不按测试轮次汇总成一行。
- 一条可用记录至少覆盖用例标识、版本与构建号、环境、执行轮次、前置条件、步骤、预期结果、实际结果、判定结论、证据附件、缺陷标识、执行人与时间、记录状态。
- 实际结果写可观察现象，判定结论只写通过、失败、阻塞等执行结论；缺陷状态由缺陷单维护，三者不混写。
- 失败记录必须留下可复现线索和证据，缺陷关联只留编号与链接，修复闭环在缺陷单中完成。
- 示例中的版本、环境、人员、时间均为演示设定，探索性测试、性能测试与合规审计场景需按各自要求调整字段。
示例要示范到什么程度：一条可用的测试执行记录
这份示例的目标是交付一条已经填好的记录，读者可以对照自己的用例库逐字段替换内容。它需要同时回答四个问题：这条用例在什么版本、什么环境下由谁执行；实际结果与预期是否一致；不一致时留下了什么证据和缺陷线索；这条记录最终处于什么状态。四个问题都答上，记录才算可用；缺任何一项，后续复查或交接时都要重新找人确认。
一条记录应覆盖的最小信息集如下：
- 用例标识：用例编号与用例名称，保证记录能回指用例库中的原始条目。
- 执行上下文：被测版本与构建号、测试环境、执行轮次、执行人、执行时间。
- 执行内容：前置条件、执行步骤、预期结果。
- 执行结果：实际结果、判定结论、证据附件。
- 关联与状态：缺陷标识与链接、记录状态。
粒度上，示例采用“一条用例一次执行”的记录方式，即每次执行生成一条独立记录，而不是按测试轮次汇总成一行。按轮次汇总会把同一用例的多轮结果压成最终结论，中间失败过、修复后重测通过的过程随之丢失，排查回归问题时无法还原当时的现场。按单次执行留痕，历史轮次自然保留，汇总视图可以由记录聚合得出。
这份记录与相邻文档有明确分工：缺陷单承载问题描述、严重程度、修复过程和验证结论；测试报告承载版本级的通过率、遗留缺陷和质量判断。测试执行记录只负责“这一次执行发生了什么”，通过缺陷标识指向缺陷单，不复制缺陷单内容，也不承担报告职责。
完整示例：登录功能一条用例的执行记录
示例背景设定：被测版本为 V2.4.0，构建号 build 20240612.3；测试环境为测试服 staging，浏览器 Chrome 125，账号体系为测试账号池；执行轮次为第 2 轮回归；执行人为测试工程师 A。以下内容均为演示设定。
| 字段 | 填写内容 |
|---|---|
| 用例编号 | TC-LOGIN-014 |
| 用例名称 | 正确账号密码登录后跳转至工作台 |
| 被测版本 | V2.4.0 / build 20240612.3 |
| 测试环境 | staging，Chrome 125，测试账号池 |
| 执行轮次 | 第 2 轮回归 |
| 前置条件 | 测试账号 test_user_01 已注册且状态正常；账号未被锁定 |
| 执行步骤 | 1. 打开登录页；2. 输入 test_user_01 与正确密码；3. 点击“登录” |
| 预期结果 | 登录成功，页面在 3 秒内跳转至工作台，右上角显示当前用户名 |
| 实际结果（第 1 次执行） | 点击登录后页面停留 8 秒，随后提示“登录超时，请重试”，未跳转 |
| 判定结论（第 1 次执行） | 失败 |
| 证据附件（第 1 次执行） | login_timeout_20240612_chrome125.png；network_login_20240612.har |
| 缺陷关联（第 1 次执行） | BUG-2317（登录接口超时），链接指向缺陷单 |
| 实际结果（第 2 次执行） | 输入账号密码后 1.2 秒跳转至工作台，右上角显示 test_user_01 |
| 判定结论（第 2 次执行） | 通过 |
| 证据附件（第 2 次执行） | login_success_20240612_chrome125.png |
| 缺陷关联（第 2 次执行） | BUG-2317（已修复，本次为验证执行） |
| 执行人 / 执行时间 | 测试工程师 A / 2024-06-12 14:20（第 1 次）、2024-06-12 17:05（第 2 次） |
| 记录状态 | 第 1 次：已关闭（已转缺陷）；第 2 次：已完成 |
这份示例的关键在于两次执行各自成条：第 1 次失败记录保留原始现象、证据和缺陷标识，第 2 次通过记录只写本次观察到的结果并注明是缺陷验证执行。两条记录通过同一用例编号和同一缺陷标识串联，读者既能看到问题发生时的现场，也能看到修复后的确认结果，而不会因为后一次通过就抹掉前一次失败。
逐项解释：每个字段为什么这样填
版本与环境必须精确到构建号和具体配置。只写“V2.4.0”无法区分同一版本下的多次构建，问题复现时可能对着已经修复的包排查；环境只写“测试服”则无法排除浏览器、账号状态等变量。构建号、浏览器版本、账号来源这些配置信息，决定了别人能否在相同条件下重现。
实际结果要描述可观察现象，避免“正常”“有问题”这类判断词。“页面停留 8 秒后提示登录超时”是可以核对的事实，“登录有问题”只是结论，读者无法据此判断严重程度，也无法与预期结果逐条比对。写法上建议按“操作—观察到的现象—出现时机”组织，必要时附上具体提示文案和耗时。
判定结论与记录状态是两个不同层面的字段。判定结论回答“这次执行的结果是通过、失败还是阻塞”，只针对本次执行；记录状态回答“这条记录在流程中走到哪一步”，例如待执行、已完成、已关闭。缺陷状态又是第三个层面，由缺陷单自己维护。三者混写会导致一个已修复的缺陷让人误以为用例仍然失败。
证据附件按能否支撑判定来取舍。界面类问题优先保留截图，并让截图包含时间、账号等上下文；接口或超时类问题保留请求响应或网络日志，比截图更能说明问题；日志文件只截取相关时间段，避免整包上传导致复查成本上升。附件命名带上用例编号、日期和环境，便于在目录中检索。
缺陷关联只留标识与链接。执行记录里写清缺陷编号和一句话摘要即可，问题的详细描述、复现步骤、修复方案都在缺陷单中维护，两边各写一份会出现内容不一致。修复是否完成、验证是否通过，属于缺陷单的闭环信息，本记录只在验证执行时注明关联关系。
执行人与时间是可追溯性的最小要求。没有执行人，失败记录无法找到当时的环境信息；没有执行时间，无法判断记录对应的是哪个构建、哪一轮回归。时间建议精确到分钟，多人协作或跨时区团队还应统一时区口径。
| 字段 | 推荐写法 | 容易失效的写法 |
|---|---|---|
| 版本与环境 | V2.4.0 / build 20240612.3，staging，Chrome 125 | 最新版、测试环境 |
| 实际结果 | 点击登录后停留 8 秒，提示“登录超时，请重试” | 登录不正常 |
| 判定结论 | 失败 | 失败，缺陷未修复 |
| 证据附件 | login_timeout_20240612_chrome125.png | 截图1.png |
| 缺陷关联 | BUG-2317（登录接口超时） | 把缺陷复现步骤整段抄进记录 |
当这些记录需要长期留存并和用例、缺陷保持引用关系时，承载方式会影响填写成本。ONES 测试管理支持用例分配执行人，未通过的用例可快速创建缺陷任务，用例与需求、任务关联，测试计划与迭代关联；用例属性可自定义并支持筛选，便于把版本、环境、轮次这类字段固化为可检索的属性。这样执行记录不必散落在表格里，失败转缺陷的动作也在同一流程中完成。
可迁移规律：换一个功能模块怎么照样填
把“预期—实际—判定”作为记录主干，是这套写法最可迁移的部分。预期结果来自用例本身，实际结果描述本次观察，判定结论只做三选一或按团队约定枚举。换到支付、搜索、权限等任何模块，主干不变，变的只是预期结果的具体内容和证据形式。
失败记录必须留下可复现线索。线索包括触发条件、出现频率和关键输入，例如“连续点击 3 次均复现”“仅在弱网条件下出现”。只写“偶现失败”而不给频率和条件，后续排查只能靠猜。
同一用例多轮执行时，每轮新建记录并标注轮次，不覆盖上一轮结果。轮次可以用回归轮次编号，也可以用执行日期区分，关键是让读者能按时间顺序还原整个过程。需要看最终结论时，取最新一轮的判定；需要看历史时，逐条翻阅。
批量执行场景下，记录粒度可以适当调整。接口自动化一次运行覆盖上百条用例时，按批次保留运行日志和汇总结果，失败用例再单独展开成条，逐条填写实际结果与证据。调整的原则是：失败项必须可单独追溯，通过项可以合并呈现。
记录与用例库、缺陷库之间靠引用关系维护，而不是复制内容。用例编号指向用例库，缺陷编号指向缺陷库，记录本身只保存本次执行的上下文和结果。用例后续被修改时，历史记录仍指向当时的用例版本，这一点在用例频繁迭代的团队中尤其重要。
适用边界：这些情况不适合照搬本示例
示例中的版本号、环境、人员、时间和缺陷编号全部是演示设定，不代表任何真实项目，也不能当作团队规范直接下发。字段名称、枚举值和必填项应结合团队现有流程与工具配置调整，例如有的团队把执行轮次放在测试计划上而不是每条记录上，同样能达到追溯目的。
探索性测试没有预设步骤和预期结果，照搬“步骤—预期—实际”的结构会迫使测试人员事后补写步骤，记录反而失真。这类测试更适合记录探索范围、发现的疑点和会话时长。性能测试关注并发量、响应时间分布和资源占用，记录字段需要围绕指标和压测配置设计，单条用例的执行记录承载不了这些信息。
缺陷修复验证与测试报告编制不在本文范围。前者在缺陷单中闭环，后者按版本汇总执行记录生成，本文只在字段说明中交代引用关系。合规或审计场景对证据留存期限、附件完整性和操作日志另有要求，需要单独与相关方确认后再决定记录字段和留存方式。
常见问题
同一用例在一轮里执行了多次，记录应该怎么建？
每次执行单独建一条记录，并标注本次是第几次执行、对应哪个构建。同一轮内多次执行往往是因为环境波动、数据准备失败或前一次结果存疑，分开记录才能看出每次的差异。如果多次执行结论一致且过程无异常，可以在记录中注明重复次数，但失败的那次必须单独保留现象和证据。
执行记录里的判定结论写成“失败”，缺陷单里也写“失败”，两边需要保持一致吗？
两边回答的问题不同。执行记录的判定结论针对这一次执行，取值通常是通过、失败、阻塞；缺陷单的状态描述问题本身的处理进展，例如待修复、修复中、已验证。缺陷修复后重测通过，执行记录新增一条“通过”，原失败记录保持“失败”不变，缺陷单则流转到已验证或已关闭。三者各管一层，不需要强行对齐。
用例步骤和预期结果在记录里要原样抄一遍吗？
建议保留与本次执行相关的步骤和预期结果，尤其是失败记录。用例库中的用例可能后续被修改，记录里不留当时的步骤和预期，几个月后复查就无法判断当时的判定依据。如果工具支持记录引用用例版本，可以只存版本标识；否则把关键步骤和预期结果随记录保存更稳妥。
自动化用例批量跑出来的结果，也要逐条填执行记录吗？
可以按批次保留运行日志和汇总结果，失败用例再单独展开成条，写清实际结果、证据和缺陷关联。调整的原则是失败项必须能单独追溯，通过项可以合并呈现。全量逐条填写会带来大量重复内容，反而降低记录的可读性。
团队用表格记录执行结果，什么时候需要考虑换成测试管理工具？
当记录需要和用例、缺陷保持引用关系，或者需要按版本、环境、轮次筛选统计时，表格的维护成本会明显上升。ONES 测试管理支持用例分配执行人，未通过的用例可快速创建缺陷任务，用例属性可自定义并支持筛选，用例与需求、任务关联，测试计划与迭代关联。是否迁移取决于团队当前的记录量和协作人数，记录量小、参与人少的团队用表格也能运转。
