测试结果记录常被混用成“测试过程里所有记录”的总称，实际它只覆盖一次执行中某条用例跑出的结论与证据。团队把执行进度、缺陷修复和发布判断都塞进同一处，后续复核和汇报就会失真。本文给出可引用的定义，并用同一口径对照结果记录、执行记录与测试报告，帮助判断一条信息该记在哪一层。
要点总览（TL;DR）
- 测试结果记录指一次执行中某条用例跑出的结论与证据，最小单位是“单次执行 × 单条用例”，回答“这条用例这次跑出了什么”。
- 测试执行记录按轮次组织，回答“这一轮跑到哪、谁在跑、还剩什么”；测试报告面向决策，回答“整体质量如何、能否发布”。
- 三者是单向汇总关系：结果记录汇总为执行记录，执行记录提炼为报告；报告数字应能逐层回溯到原始条目。
- 归属判断可用问题倒推法：先写出信息要回答的问题，再匹配载体；同时服务多个问题时，原始条目留在结果记录，汇总表达放上层。
- 常见误解包括把整轮进度写进单条记录、把明细当报告、在结果记录里跟踪缺陷修复、只记结论不留证据。
测试结果记录指什么：一句话定义与最小单位
测试结果记录指在一次测试执行中，对某个测试用例（或测试项）实际运行后所得结论及其关键证据的留存，核心回答“这一条用例跑出了什么结果、依据是什么”。这个定义包含两个限定：一是绑定具体用例，二是绑定某一次执行，同一用例在不同轮次、不同环境下的结果分别成条。
它的最小记录单位是“单次执行 × 单条用例”。一条记录不承担整轮测试的进度说明，也不承担版本质量结论，只对这一次运行负责。团队在讨论记录粒度时，可以先确认是否落到这个单位，再决定是否需要向上汇总。
一条完整的结果记录通常包含以下要素：
- 用例标识：用例编号或名称，必要时带所属模块与优先级，确保能定位到被执行的条目。
- 执行时间：本次运行发生的日期与时间，用于区分同一用例的多次执行。
- 执行人：实际运行并给出结论的人，便于后续追问与复核。
- 执行环境：设备、系统版本、浏览器、测试数据或服务地址等影响结果判断的条件。
- 实际结果：运行后观察到的现象，与预期结果对照后写明差异。
- 结论状态：通过、失败、阻塞等，表示本次执行的判定；状态口径应在团队内统一。
- 证据附件：截图、日志、录屏或请求响应片段，支撑结论可被他人复核。
需要区分“测试结果”作为汇总数据的用法。当有人说“本轮测试结果通过率 85%”，指的是多条结果记录聚合后的统计值，属于执行记录或报告层面的表达；而“测试结果记录”强调的是逐条留痕的原始条目。前者由后者汇总而来，不能反过来用汇总值替代单条记录。
边界在哪里：属于与不属于测试结果记录的内容
判断一条信息是否属于测试结果记录，可以看它是否服务于“这一条用例这次跑出了什么”这个问题。服务于该问题的写入结果记录，服务于其他问题的交给对应载体。
| 信息类型 | 归属 | 说明 |
|---|---|---|
| 单条用例的实际结果与结论状态 | 属于结果记录 | 记录的核心内容，需与用例和执行轮次绑定 |
| 本次执行的环境与测试数据 | 属于结果记录 | 影响结论可复现性，应随记录留存 |
| 支撑结论的截图、日志等证据 | 属于结果记录 | 使结论可被他人复核 |
| 整轮测试的进度、排期与人员分工 | 不属于结果记录 | 属于测试执行记录层面，按轮次或计划管理 |
| 缺陷的提交、修复与复测闭环 | 不属于结果记录 | 归缺陷修复与验证跟踪，结果记录只保留失败结论与证据 |
| 质量结论、趋势分析与发布建议 | 不属于结果记录 | 归测试报告与质量评估，由汇总数据提炼 |
边界模糊时，可以用“问题倒推法”判断：先写出这条信息要回答的问题，再匹配载体。问“这条用例这次跑出了什么”，写入结果记录；问“这一轮跑到哪、还剩多少”，写入执行记录；问“整体质量如何、能否发布”，写入测试报告。若一条信息同时服务多个问题，保留原始条目在结果记录，汇总表达放到上层载体，避免在两处重复维护同一份内容。
还有一种常见情况是失败用例的处理。失败结论与证据属于结果记录；由此产生的缺陷单、修复过程和复测结论属于缺陷跟踪。结果记录中可以保留关联缺陷的标识，便于追溯，但修复状态的变化不在结果记录里逐日更新。
三个概念各回答什么问题：结果记录、执行记录与测试报告
三者不是同一份内容的不同叫法，而是三个层级：结果记录是原始条目，执行记录是按轮次组织的进度视图，测试报告是面向决策的结论提炼。用同一口径对照，可以看清各自的时间视角与读者。
| 维度 | 测试结果记录 | 测试执行记录 | 测试报告 |
|---|---|---|---|
| 回答的问题 | 这条用例这次跑出了什么 | 这一轮测试跑到哪、谁在跑、还剩什么 | 整体质量如何、能否发布 |
| 粒度 | 单次执行 × 单条用例 | 一轮测试计划或轮次 | 一个版本、一次迭代或一个发布批次 |
| 时间视角 | 执行发生的那一刻 | 执行进行中的实时状态 | 阶段性回顾与发布前判断 |
| 主要读者 | 执行人、复核人、后续排查者 | 测试负责人、项目成员 | 项目负责人、研发与业务决策者 |
| 更新频率 | 每次执行即产生或更新 | 随执行进展持续更新 | 按里程碑或发布节点生成 |
| 数据流向 | 汇总为执行记录的进度与通过率 | 提炼为测试报告的结论与趋势 | 引用下层汇总，不反向修改原始记录 |
数据流向是单向的：结果记录汇总成执行记录，执行记录提炼成报告。报告中的通过率、失败分布等数字应能回溯到执行记录，再回溯到具体的结果条目。若报告数字与底层记录对不上，通常说明某一层被手工改写或口径不一致，需要先统一状态定义再核对。
读者不同也决定了内容取舍。执行记录关注“还剩多少没跑、谁负责”，适合展示进度与阻塞；报告关注“风险在哪、能否放行”，适合展示结论与依据。把逐条结果明细直接贴进报告，会增加阅读负担；把报告结论写进单条结果记录，则会让原始条目承担它无法验证的判断。
机制与组成：一条结果记录如何产生并向上汇总
结果记录的产生始于执行动作：执行人按用例步骤运行，比对预期结果与实际现象，给出结论状态，并留存必要证据。这个环节的完成标志是“结论可被他人依据记录复现或复核”，而不只是填了一个状态。
结论状态的确定需要统一口径。通过表示实际结果符合预期；失败表示存在明确差异；阻塞表示因环境、依赖或数据问题无法完成判定。状态定义一旦确定，执行人与复核人按同一口径填写，后续汇总才有可比性。
结果记录按轮次或测试计划汇总，形成执行进度。汇总环节通常由测试负责人或计划维护人负责，把已执行、未执行、失败、阻塞的数量组织成进度视图，识别剩余工作与阻塞项。这个环节不修改单条结论，只做归集与呈现。
从执行数据提炼报告结论，通常由测试负责人牵头，结合版本范围、风险等级和发布要求撰写。报告引用汇总数据，说明质量状况与遗留风险，给出发布建议。报告作者对结论负责，原始记录的责任仍在执行人与复核人。
状态变更需要在记录中体现。失败用例在修复后重跑，应产生新的执行结果，保留原失败记录，而不是覆盖旧结论；因环境问题转为阻塞的，应更新状态并注明原因。保留变更轨迹，才能解释同一用例在不同时间点的结论差异。
在工具承载上，ONES 测试管理支持测试计划的规划和执行，并可多维度概览全部测试计划、查看进度；用例可分配执行人，便于合作测试；测试情况概览可快速了解测试计划的进度和通过率。未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，使失败结论与缺陷跟踪衔接而不混写。报告环节支持自动生成测试报告，并支持自定义组装报告模板以适配不同业务场景。这些能力对应的是“结果条目—执行进度—报告结论”的分层承载，团队仍需先约定状态口径与记录要素，工具才能稳定支撑汇总与复核。
具体例子与常见误解
以一条登录用例为例：用例要求正确账号在指定环境下登录成功并跳转首页。某次执行中，输入正确账号后页面提示“服务异常”，未跳转。结果记录写的是：用例标识为登录-正常账号，执行时间与执行人，环境为测试环境某版本，实际结果为提示服务异常且未跳转，结论为失败，附上页面截图与接口返回日志。执行记录写的是：本轮计划共若干条用例，已执行多少、失败多少、阻塞多少，该条失败已关联缺陷单，剩余用例由谁继续执行。测试报告写的是：本轮登录相关功能存在服务异常问题，影响范围与风险等级，缺陷当前状态，以及是否建议在修复后放行。三层各写各的，数字可以逐层回溯。
常见误解有四类，纠正方式如下：
- 把整轮进度写进单条结果记录。单条记录只对这一次执行负责，进度属于执行记录。纠正方式是把进度信息从结果条目中移出，在执行记录中按轮次维护。
- 把结果记录直接当测试报告使用。逐条明细无法直接回答“能否发布”，报告需要结论、风险与建议。纠正方式是保留明细作为依据，另行按报告模板提炼结论。
- 在结果记录里跟踪缺陷修复过程。结果记录保留失败结论与证据，修复与复测属于缺陷跟踪。纠正方式是记录关联缺陷标识，修复状态在缺陷单中更新，复测后产生新的执行结果。
- 只记结论不留证据。没有截图、日志或环境信息，结论无法复核，也无法判断失败是否由环境引起。纠正方式是把证据留存作为记录完成的必要条件，并在复核时抽查。
团队规模较小时，可以先保证每条结果记录的要素齐全、状态口径统一，再逐步规范执行记录的进度视图与报告模板；流程较成熟的团队，可以进一步明确三层载体各自的维护人与更新节点，减少同一信息在多处重复填写。
常见问题
同一用例在不同轮次重跑，结果记录应该覆盖旧记录还是新增一条？
建议新增一条执行结果，保留原失败记录。结果记录绑定的是“某一次执行”，覆盖旧结论会让后续复核无法解释同一用例在不同时间点的结论差异。修复后重跑产生的新结果与旧记录并存，执行记录按轮次归集，报告引用最新一轮的汇总数据。
失败用例关联了缺陷单，结果记录里还要不要写修复状态？
结果记录保留失败结论、证据和关联缺陷的标识即可，修复状态在缺陷单中更新。缺陷修复与复测闭环属于缺陷跟踪的范围，若在结果记录里逐日更新修复状态，同一信息会在两处维护，容易出现口径不一致。复测完成后产生新的执行结果，与缺陷单形成追溯关系。
团队规模小、没有专职测试负责人时，三层载体如何简化？
可以先保证每条结果记录的要素齐全、状态口径统一，执行进度用轮次视图简单归集，报告按发布节点提炼结论。三层载体的划分依据是回答的问题不同，与团队人数无关；简化的是维护频率和模板复杂度，而不是把进度、缺陷修复和发布判断混写进单条记录。流程成熟后再明确各层的维护人与更新节点。
报告里的通过率和执行记录里的数字对不上，通常是什么原因？
常见原因是状态口径不一致或某一层被手工改写。比如结果记录中“阻塞”在执行记录里被计为“未执行”，或在报告中把重跑后的结果替换了首轮数据。核对时先统一通过、失败、阻塞的定义，再从报告数字回溯到执行记录、再到具体结果条目，确认每一层的统计范围一致。
用工具承载结果记录时，需要先约定哪些内容？
先约定状态口径（通过、失败、阻塞的判定标准）和记录要素（用例标识、执行时间、执行人、环境、实际结果、证据）。ONES 测试管理支持测试计划的规划和执行，可多维度概览测试计划与进度，支持用例分配执行人，未通过用例可快速创建缺陷任务，并支持自动生成测试报告与自定义报告模板。工具提供的是分层承载能力，状态口径与要素规范仍需团队自行确定，汇总与复核才能稳定进行。
