测试结果记录指在一次测试运行中，针对具体测试用例或检查项记录实际执行结果与判定结论的最小事实单元，回答“这一项测了什么、实际得到什么、判定通过还是失败”。团队常把结果记录、执行记录和测试报告混在一起使用，导致统计口径不一致、责任归属模糊。本文按定义、边界、形成机制和相邻概念对照逐层说明，帮助团队统一用法。
要点总览（TL;DR）
- 测试结果记录是以单个测试用例或检查项为单位的最小事实单元，回答“测了哪一项、实际得到什么、判定是什么”。
- 一条结果记录至少包含用例或检查项标识、实际结果、判定结论、执行时间和执行人五项信息。
- 结果记录是执行记录的组成单元，执行记录回答这一轮怎么执行、执行到哪一步，测试报告回答整体质量如何、能否发布。
- 判断归属可以按顺序提问：描述单项实际表现归结果记录，描述批次执行情况归执行记录，描述整体结论归测试报告。
- 常见误解包括把缺陷处理过程写进结果记录、把阶段结论当作结果记录、只记录失败项而省略通过项。
测试结果记录指什么：一条记录回答哪三个问题
测试结果记录是测试执行过程中产生的最小事实单元。它以单个测试用例或检查项为对象，记录这一次运行的实际表现和判定结论。把它称为“最小”，是因为它不再向下拆分：一条记录对应一个可独立判定的检查点，而不是一组用例的集合，也不是一轮测试的整体评价。
一条合格的结果记录需要回答三个问题：测了哪一项、实际得到什么、判定结论是什么。第一个问题确定对象，第二个问题保留事实，第三个问题给出结论。三者缺一，记录就无法被后续统计或复核使用。例如只写“登录功能测试失败”，缺少具体检查项和实际现象，其他人在汇总或排查时就无法判断失败发生在哪个环节。
围绕这三个问题，一条结果记录的最小信息项可以整理为：
- 用例或检查项标识：说明这条记录对应哪一项测试内容，通常包含用例编号或名称。
- 实际结果：记录执行时观察到的现象、返回值或输出，尽量写具体事实而非笼统评价。
- 判定结论：给出通过、失败、阻塞等状态，表示这一项是否达到预期。
- 执行时间：记录这次运行发生的时间，用于区分不同轮次和追溯历史。
- 执行人：记录由谁执行，便于复核和沟通。
这五项构成结果记录的骨架。不同团队可以增加环境、数据版本、附件截图等补充信息，但上述五项是判断一条记录是否成立的基本条件。缺少判定结论的记录只是执行痕迹，缺少实际结果的记录无法支撑复核，两者都不足以作为统计依据。
边界在哪里：属于结果记录、不属于结果记录的内容
划清边界最有效的方法是看这条信息回答什么问题。结果记录只回答“这一项的结果是什么”。凡是回答“这个缺陷怎么处理”“整体质量能不能发布”的内容，都应归入其他环节。这个判断标准简单，但能覆盖大多数日常混淆场景。
属于结果记录的内容包括：单次运行中逐项的实际结果与判定；同一用例在不同轮次或不同环境下的多次结果；阻塞状态下记录的原因说明，例如依赖环境未就绪导致该项无法执行。这些内容都围绕单项事实，粒度一致，可以直接进入统计。
不属于结果记录的内容主要有两类。第一类是缺陷修复闭环，包括缺陷的提交、分配、修复、验证和关闭过程。缺陷处理回答的是“问题怎么被解决”，它有自己的状态流转和责任人，属于缺陷修复与验证跟踪的范围。结果记录可以在判定失败时触发缺陷创建，但缺陷后续的处理过程不写回结果记录本身。第二类是阶段性质量结论，包括版本质量评价、发布建议、风险汇总等。这类内容回答“整体如何”，需要汇总多条结果记录后才能形成，属于测试报告与质量评估的范围。
实际工作中可以用一个提问顺序来判断归属：先问这条信息描述的是某一项的实际表现吗，如果是，归入结果记录；再问它描述的是这一轮测试如何组织、执行到哪一步吗，如果是，归入执行记录；最后问它描述的是整体质量判断或发布结论吗，如果是，归入测试报告。按这个顺序判断，大多数信息都能找到明确归属，减少同一内容被重复记录在不同文档里的情况。
结果记录如何组成：从执行动作到可汇总的数据
结果记录的形成过程可以拆成四个连续动作：执行用例或检查项、记录实际结果、给出判定、留存执行人与时间。执行是产生事实的环节，记录是把事实固定下来，判定是把事实与预期比较后给出结论，留存执行信息则保证这条记录可追溯。四个动作完成后，一条结果记录才具备被汇总的条件。
从结构上看，结果记录沿三个维度组织。用例或检查项维度决定记录的粒度，每条记录对应一个可判定的检查点；运行批次维度决定记录属于哪一轮测试，同一用例在不同轮次会产生不同记录，不能相互覆盖；判定状态维度决定记录在统计中的归类，通过、失败、阻塞等状态分别进入不同的统计口径。三个维度共同保证记录既能单独查看，也能按批次和状态聚合。
汇总发生在记录之后。执行进度通常按已执行项数与计划项数的比例计算，通过率通常按通过项数与已执行项数的比例计算。这两个指标的口径依赖记录是否完整：如果只记录失败项，通过率会被低估；如果失败项没有及时判定，进度和通过率都会失真。因此结果记录的完整性直接决定统计结果的可信度。团队在定义统计口径时，应同时明确哪些状态计入已执行、哪些状态单独列出，避免同一批数据在不同报表中得出不同结论。
当结果记录按批次稳定积累后，汇总动作可以借助测试管理工具承载。ONES 测试管理支持将用例分配执行人，并快速了解测试计划的进度和通过率，使逐项记录与计划层面的统计衔接在同一套数据上；未通过的用例可快速创建缺陷任务，让失败结果进入缺陷流转，而结果记录本身仍保留单项判定的事实。
结果记录、执行记录与测试报告各自回答什么问题
三个概念容易混淆，是因为它们都出现在测试执行阶段，且数据相互引用。区分的关键在于各自回答的问题不同：结果记录回答单项结果，执行记录回答这一轮怎么执行，测试报告回答整体质量结论。三者是组成与汇总的关系，而不是并列的三种文档。
| 概念 | 回答的问题 | 典型内容 | 粒度 | 与其他两者的关系 |
|---|---|---|---|---|
| 测试结果记录 | 这一项测了什么、实际得到什么、判定是什么 | 用例标识、实际结果、判定状态、执行时间与执行人 | 单个用例或检查项 | 执行记录的组成单元，报告的汇总来源 |
| 测试执行记录 | 这一轮测试怎么执行、执行到哪一步、覆盖了哪些范围 | 执行批次、执行范围、环境与版本、执行进度、人员分工 | 一轮测试或一个执行批次 | 由多条结果记录构成，为报告提供过程依据 |
| 测试报告 | 整体质量如何、能否发布 | 结果汇总、通过率、缺陷分布、风险与结论建议 | 版本或阶段 | 基于结果记录与执行记录汇总形成 |
从关系上看，结果记录是执行记录的组成单元。一轮测试的执行记录描述范围、环境和进度，这些描述需要逐项结果来支撑；没有结果记录，执行记录只能说明“执行过”，无法说明“执行出了什么”。测试报告则是结果记录的汇总产物，它把分散的单项判定聚合成通过率、缺陷分布和发布建议。三者顺序清晰：先有逐项结果，再有批次执行情况，最后形成阶段结论。
这个关系也解释了为什么不能把三者混写。把缺陷处理过程写进结果记录，会让单项判定混入处置状态；把阶段结论写进执行记录，会让过程描述带上评价色彩；把逐项明细全部搬进测试报告，则会让报告失去结论性。各归其位，数据才能在每一层被正确使用。
具体例子与常见误解
以一个登录功能用例为例。用例要求验证正确账号密码可以登录成功。执行人运行后观察到页面跳转至首页并显示用户名，判定为通过，记录执行时间和执行人。这条记录就是一条完整的结果记录。随后它被计入本轮测试的执行进度，通过项进入通过率统计，最终在测试报告中被汇总为登录模块的通过情况。整个过程中，结果记录只承担单项事实，进度统计和报告结论分别在其他层面完成。
如果同一用例在另一轮回归中因验证码服务异常而无法完成，执行人记录实际现象并判定为阻塞，这条记录同样属于结果记录。阻塞原因写清楚即可，不需要在结果记录里跟踪验证码服务的修复过程，那属于缺陷或问题跟踪的范围。
常见误解有三个。第一个是把缺陷处理过程写进结果记录，例如在失败项后面追加“已提缺陷、开发已修复、待验证”等状态。这些信息属于缺陷修复与验证跟踪，写进结果记录会让单项判定变得含混，也会让统计时难以区分“测试失败”和“缺陷未关闭”。正确做法是结果记录保留失败判定，缺陷处理在缺陷任务中流转。
第二个是把阶段性结论当作结果记录，例如在某一项记录中写“本版本质量风险较高，建议延期发布”。这是汇总多条记录后才能形成的判断，应放在测试报告中。结果记录只描述这一项的实际表现，不承担整体评价职能。
第三个是只记录失败项、不记录通过项。这种做法看似节省时间，实际会让通过率失去分母，执行进度也无法准确反映。通过项同样是结果记录，只有逐项记录完整，统计口径才成立。团队如果担心记录负担，可以通过用例模板预置判定选项、批量执行等方式降低录入成本，而不是省略通过项。
当结果记录、执行记录和报告各归其位后，汇总工作可以借助工具减少手工整理。ONES 测试管理支持自动生成测试报告，并提供可自定义组装的报告模板，使逐项结果在批次层面汇总为进度与通过率，再进一步形成版本质量反馈；测试报告的具体维度和模板配置以项目实际设置为准。
常见问题
测试结果记录和测试执行记录在实际工作中需要分开维护吗？
是否需要分开维护，取决于团队当前的记录载体和统计需求。如果使用测试管理工具，结果记录通常以用例执行结果的形式存在，执行记录则由测试计划或执行批次承载，两者在同一套数据中自然分层，不需要额外维护两份文档。
如果团队仍用表格管理，建议至少把逐项结果和批次信息放在不同工作表或不同区域：逐项结果按用例一行记录，批次信息单独记录范围、环境、版本和进度。这样统计通过率时直接取逐项结果，查看执行范围时取批次信息，避免同一张表里混入两种粒度。
需要分开维护的前提是团队要按批次追溯执行情况；如果只是临时验证、不涉及多轮统计，合并记录也能用，但要在表头明确哪些列属于单项结果、哪些列属于批次说明。
一条测试结果记录判定为失败后，缺陷修复进展要不要回写到这条记录里？
建议不回写。结果记录保留的是这次运行的实际表现和判定，失败就是失败；缺陷的提交、分配、修复和验证属于缺陷修复与验证跟踪的范围，有自己的状态和责任人。
如果团队希望在查看结果记录时了解缺陷进展，可以通过关联关系实现：结果记录关联对应的缺陷任务，查看时跳转或引用缺陷状态，而不是把“已修复待验证”等处置状态直接写进结果记录的判定字段。这样统计通过率时，失败项仍然计入失败，不会被缺陷状态覆盖，口径保持稳定。
例外情况是团队明确把“失败且缺陷已关闭”作为复测通过的判定条件，这时应在复测轮次产生新的结果记录，而不是修改原记录。
只记录失败项、通过项不记录，会带来哪些具体影响？
最直接的影响是通过率失去分母。通过率通常按通过项数与已执行项数的比例计算，省略通过项后，已执行项数只剩失败项，通过率会被严重低估甚至无法计算。
其次是执行进度失真。进度一般按已执行项数与计划项数的比例计算，只记失败项会让进度看起来远低于实际情况，团队难以判断这一轮测试到底完成了多少。
第三是复核困难。后续排查问题时，无法确认某一项是执行过且通过，还是根本没有执行，责任和覆盖范围都说不清楚。降低录入负担的可行做法是用例模板预置判定选项、批量提交执行结果，而不是省略通过项。
阻塞状态应该算在结果记录里，还是单独作为执行问题处理？
阻塞属于结果记录的一种判定状态，应当记录在结果记录中，写明哪一项无法执行以及阻塞原因，例如依赖环境未就绪、前置用例失败等。这样这一项在统计中不会被误算为通过或失败，也不会从已执行范围中消失。
阻塞原因的处置可以另行走问题跟踪或缺陷流程，但结果记录本身只需保留“这一项因何阻塞、判定为阻塞”的事实。团队在定义统计口径时，应明确阻塞项是否计入已执行项数、是否单独列出，避免不同报表对同一批数据给出不同结论。
同一用例在多轮回归中产生多条结果记录，统计时以哪一条为准？
统计时应按轮次区分，不能相互覆盖。每一轮运行产生的结果记录属于该轮批次，进度和通过率按轮次分别计算；跨轮次比较时，看的是同一用例在不同轮次判定状态的变化，而不是用最新一条记录替换历史记录。
如果团队需要看版本的最终质量，通常以最后一轮完整回归的结果为准，并在测试报告中说明所依据的轮次和范围。历史轮次的结果记录保留下来，用于追溯失败是否复现、修复是否有效。把多轮记录混在一起统计，会让通过率的分母重复计算，结论失去意义。
