测试结果记录要能回答四个问题：执行的是哪个用例、在什么环境和版本上执行、结果是什么、由谁在何时确认。字段不必求多，关键是每个字段都有明确填写人和判定口径，能支撑复测、统计和追溯。下面给出一份可直接套用的字段清单、填写流程、角色分工和合格检查项。
要点总览（TL;DR）
- 测试结果记录的最小字段集覆盖五类信息：用例标识与版本、被测对象与构建版本及环境、执行人与时间及轮次、执行结果状态与预期实际差异、证据附件与缺陷关联。
- 填写顺序按执行前准备、执行中记录、执行后核对、复测更新、归档追溯五步推进，每步都有明确的输入、输出和完成标志。
- 判定口径由测试负责人统一发布，执行人按口径填写，开发人员确认缺陷关联，项目或质量角色基于记录做统计与追溯。
- 合格记录需通过必填字段齐全、状态与证据一致、缺陷可追溯、复测轮次留痕、记录与用例和构建对应五项阻断检查。
- 记录量增大后，可把字段、状态流转和关联关系配置到测试管理工具中，用系统约束替代人工核对。
一条测试结果记录的最小字段集
建立测试结果记录表时，先按“识别对象—描述执行—判定结果—留存证据—建立关联”五类组织字段。以下字段表可作为最小集，团队可按业务复杂度增补，但不宜删减必填项。
| 类别 | 字段名 | 填写内容 | 是否必填 | 填写人 |
|---|---|---|---|---|
| 用例识别 | 用例标识 | 用例编号或唯一ID，与用例库保持一致 | 必填 | 测试执行人 |
| 用例识别 | 用例版本 | 本次执行所依据的用例版本号或修订标识 | 必填 | 测试执行人 |
| 被测对象 | 被测对象与构建版本 | 产品/模块名称、构建号或发布版本号 | 必填 | 测试执行人 |
| 被测对象 | 测试环境 | 环境名称、操作系统/浏览器/设备等关键配置 | 必填 | 测试执行人 |
| 执行信息 | 执行人 | 实际执行该用例的人员 | 必填 | 测试执行人 |
| 执行信息 | 执行时间 | 执行开始与完成时间，精确到日期即可满足多数场景 | 必填 | 测试执行人 |
| 执行信息 | 执行轮次 | 首轮、第N轮复测等轮次标记 | 必填 | 测试执行人 |
| 结果判定 | 执行结果状态 | 通过、失败、阻塞、未执行等，需团队统一定义 | 必填 | 测试执行人 |
| 结果判定 | 预期结果 | 引用用例中的预期描述，必要时摘录关键判定点 | 必填 | 测试执行人 |
| 结果判定 | 实际结果与差异说明 | 实际观察到的现象；失败时说明与预期的具体差异 | 失败/阻塞时必填 | 测试执行人 |
| 证据留存 | 证据附件 | 截图、日志、录屏或请求响应记录 | 失败时必填，通过时按需 | 测试执行人 |
| 关联追溯 | 关联缺陷或问题单 | 缺陷编号及简要标题，失败用例应建立关联 | 失败时必填 | 测试执行人，开发人员确认 |
| 补充说明 | 备注与复测标记 | 特殊说明、阻塞原因、是否需复测及复测结论 | 按需 | 测试执行人 |
字段口径要在团队内统一。例如“通过”指实际结果与预期完全一致且证据可查；“阻塞”指因环境、依赖或数据问题无法完成执行，需在备注中写明阻塞原因。状态定义一旦确定，就应写入测试规范，避免不同执行人各自解释。
从执行到归档：记录填写与流转步骤
字段清单解决“记什么”，流程解决“什么时候记、按什么顺序记”。以下五步覆盖从执行前准备到归档的完整链路，每步标注输入、动作、输出与完成标志。
第一步：执行前准备
输入为测试计划、用例库和待测构建。执行人确认本次要执行的用例版本与构建号对应，核对测试环境可用、测试数据就绪。输出是一份可执行的用例清单及环境确认结果。完成标志是执行人能在记录中准确填写用例版本、构建版本和环境信息，无需事后回忆。
第二步：执行中记录
输入为单条用例及其预期结果。执行人按步骤操作，实时填写执行结果状态和实际结果；失败时立即截图或保存日志，作为证据附件上传。输出是一条带有状态、实际结果和证据的完整记录。完成标志是记录中的实际结果描述能让未参与执行的人复现问题现象。
第三步：执行后核对
输入为当日或当轮的执行记录。执行人逐条核对失败用例的差异说明是否具体，确认是否需要提交缺陷；需要时创建缺陷单并在记录中回填缺陷编号。输出是差异说明清晰、缺陷关联完整的记录集合。完成标志是每条失败记录都能通过缺陷编号追溯到对应问题单。
第四步：复测与状态更新
输入为缺陷修复后的新构建和原失败记录。执行人开展复测，新增一条执行轮次记录或在原记录上更新状态，保留原失败记录不做覆盖。输出是带有轮次标记和结果变更留痕的复测记录。完成标志是能看出同一用例从失败到通过的完整轮次变化，且每轮都有执行人和时间。
第五步：归档与可追溯
输入为当轮全部执行记录。测试负责人确认记录完整后归档，确保记录与用例、构建版本形成对应关系。输出是可检索、可统计的测试结果数据集。完成标志是给定任一用例或构建版本，能查出对应的全部执行记录及结果。
角色分工与各角色交付物
记录字段无人负责，规范就会落空。以下对照表明确谁填、谁审、谁用，团队可据此分配职责。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 测试执行人 | 执行用例，填写结果状态、实际结果，上传证据，提交或关联缺陷 | 单条测试结果记录及证据附件 |
| 测试负责人 | 制定状态定义与判定口径，抽查记录质量，确认归档 | 判定口径说明、抽查记录、归档确认 |
| 开发人员 | 确认缺陷关联信息，补充修复说明，配合复测 | 缺陷单中的确认与修复记录 |
| 项目或质量角色 | 基于记录做通过率、缺陷分布、轮次趋势统计与追溯 | 统计视图、质量分析结论 |
分工的关键在于判定口径由测试负责人统一发布，执行人只按口径填写，减少同一状态在不同人手里含义不同的情况。开发人员确认缺陷关联，保证记录与问题单之间的追溯链不断裂。
填写示例：一条登录功能测试结果记录
以下为演示情景，用于说明字段颗粒度，非真实项目案例。
背景：某系统登录模块，用例验证“正确账号密码可登录并跳转首页”，在测试环境执行首轮测试。
| 字段 | 填写内容 |
|---|---|
| 用例标识 | TC-LOGIN-012 |
| 用例版本 | v1.3 |
| 被测对象与构建版本 | 用户中心模块，构建号 build-20240612-03 |
| 测试环境 | 测试环境 test-02，Chrome 125，Windows 11 |
| 执行人 | 测试工程师A |
| 执行时间 | 2024-06-12 14:20 至 14:28 |
| 执行轮次 | 首轮 |
| 执行结果状态 | 失败 |
| 预期结果 | 输入正确账号密码后登录成功，跳转至首页并显示用户名 |
| 实际结果与差异说明 | 登录请求返回成功，但页面停留在登录页未跳转；控制台出现路由跳转异常日志 |
| 证据附件 | 页面截图1张、控制台日志片段1份 |
| 关联缺陷 | BUG-2048 登录成功后未跳转首页 |
| 备注与复测标记 | 需复测；复测时关注路由配置变更 |
这条记录的颗粒度体现在：实际结果写明了观察到的现象和日志线索，差异说明直接指向预期与实际的偏离点，证据附件能支撑开发定位，缺陷关联使记录可追溯。复测时新增一条轮次为“复测1”的记录，状态更新为通过，原失败记录保留。
完成检查：记录是否合格的核对项
记录填写完成后，可用以下清单自检或评审。任一项阻断项不通过，记录不应归档。
| 检查项 | 通过标准 | 阻断项 |
|---|---|---|
| 必填字段齐全 | 用例标识、版本、构建版本、环境、执行人、时间、轮次、状态均有值 | 是 |
| 结果状态与证据一致 | 失败记录有实际结果描述和至少一项证据；通过记录无矛盾描述 | 是 |
| 缺陷关联可追溯 | 失败用例均关联缺陷编号，缺陷单可打开且标题对应 | 是 |
| 复测与轮次信息更新 | 复测记录有独立轮次标记，原记录未被覆盖 | 是 |
| 记录与用例、构建对应 | 用例版本与构建号能在用例库和构建记录中找到对应 | 是 |
| 差异说明可复现 | 实际结果描述包含操作路径和现象，他人可据此复现 | 否，建议改进 |
抽查时优先看失败记录和复测记录，这两类最容易出现证据缺失或轮次覆盖。通过率统计前，先确认状态定义与记录一致，避免把“阻塞”计入失败导致数据失真。
用工具承载记录：字段、状态与追溯的落地方式
记录量增大后，靠表格维护容易出现字段缺失、轮次覆盖和关联断裂。把字段、状态流转和追溯关系固定到测试管理工具中，能减少人工核对成本。落地时关注四个要点。
- 字段结构化配置：将用例标识、构建版本、环境、执行轮次等设为结构化字段，而非自由文本，便于筛选和统计。ONES 测试管理支持自定义用例属性，可适配不同业务场景的字段需求，具体可配置的字段类型以实际版本为准。
- 状态与轮次流转：执行结果状态应有明确可选值，复测通过新增轮次记录而非覆盖原记录，保留结果变更留痕。
- 关联追溯：记录需与用例、构建版本、缺陷形成关联。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联；未通过的用例可快速创建缺陷任务，执行人可将用例分配执行人，使记录与问题单的追溯链在工具内闭合。
- 统计视图依赖：通过率、缺陷分布等统计依赖字段口径统一。ONES 测试管理支持多维度概览测试计划进度，并提供质量统计报表，统计维度以实际版本为准。
工具承载的价值在于把“谁填、填什么、关联到哪”变成系统约束，而不是依赖个人记忆。团队可先按本文字段表在工具中配置字段和状态，再通过权限设置区分执行人与负责人的操作范围。ONES 测试管理支持为不同用户组配置权限，也可为用例库、测试计划单独配置权限，便于把填写与审核职责落到系统层面。字段配置完成后，用一条失败用例走通“执行—提缺陷—复测—统计”的完整链路，确认记录可追溯后再推广到全团队。
常见问题
执行结果状态应该定义哪几个值，团队口径怎么统一？
常见的最小状态集包括通过、失败、阻塞、未执行。定义时要写清每个状态的判定条件，例如“通过”指实际结果与预期完全一致且证据可查，“阻塞”指因环境、依赖或数据问题无法完成执行。状态定义由测试负责人统一发布并写入测试规范，执行人只按口径选择，避免同一现象在不同人手里被记成不同状态。状态值一旦确定，统计口径也随之固定，后续调整需要同步更新历史记录的说明。
复测时是修改原记录还是新增一条记录？
建议新增一条执行轮次记录，原失败记录保留不覆盖。新增记录中标注轮次（如复测1）、执行人、执行时间和新状态，并在备注中引用原记录或缺陷编号。这样同一用例从失败到通过的变化过程完整可见，统计时也能区分首轮结果和复测结果。如果直接在原记录上改状态，轮次变化和结果变更留痕会丢失，后续追溯失败原因时缺少依据。
通过状态的用例是否也需要上传证据？
按需处理。失败和阻塞记录必须附证据，通过记录在多数场景下可以不附。但涉及关键路径、合规要求或曾经失败后复测通过的用例，建议保留截图或日志，便于证明结果可信。团队可以在测试规范中列出必须附证据的用例范围，例如核心交易流程、安全相关功能，其余通过记录以状态和实际结果描述为准。
记录字段配置到工具后，如何确认追溯链真的走得通？
字段配置完成后，用一条失败用例走通完整链路：执行并记录失败、创建或关联缺陷、修复后新增复测轮次、在统计视图中查到这条记录。检查每个环节能否从记录跳到对应用例、构建版本和缺陷单，反向也能从缺陷单找到执行记录。ONES 测试管理支持测试用例与需求、任务关联，未通过的用例可快速创建缺陷任务，并支持为不同用户组配置权限，便于把填写与审核职责落到系统层面。链路验证通过后再推广到全团队，能减少配置返工。
记录与构建版本的对应关系断了，会带来什么问题？
构建版本是判断结果属于哪次交付的关键依据。对应关系断裂后，统计通过率时无法区分结果来自哪个构建，复测时也难以确认修复是否已包含在当前版本中。执行前准备阶段就要确认用例版本与构建号对应，记录中填写构建号或发布版本号，归档时由测试负责人核对记录与构建记录能否互相查到。工具中可将构建版本设为结构化字段，减少自由文本带来的不一致。
