测试执行把已评审的用例按计划落到具体环境、版本和责任人，逐条运行并记录实际结果与证据，再把失败项转成可跟踪的问题，最后用通过率、阻塞率和遗留风险判断本轮能否收口。本文聚焦“分配—运行—记录—复核—收口”这条执行主线，缺陷修复验证与测试报告编制不在展开范围。若团队使用ONES，测试用例、执行记录与缺陷任务可在同一工作项体系中流转，便于把执行状态和问题处理放在一处查看。
要点总览（TL;DR）
- 测试执行按“分配—运行—记录—复核—收口”五个动作推进，开始前先确认用例已评审、环境可用、版本与构建号确定三项准入条件。
- 执行记录至少覆盖用例标识、版本/构建号、环境、执行人、执行时间、实际结果、状态、失败证据与关联问题单编号，状态取值保持通过/失败/阻塞/未执行四选一。
- 测试负责人、用例执行人、环境/数据负责人、开发与产品角色、结果审核人各有交付物和交接时点，角色可合并但交付物不能省。
- 收口判断结合通过率、阻塞率和遗留风险三类数据，失败项全部有归属和编号、阻塞项有解除条件，才具备收口条件。
- ONES测试管理支持测试计划与迭代关联、用例分配执行人、未通过用例一键创建缺陷任务，并提供测试情况概览查看进度和通过率。
测试执行的核心动作与先后顺序
测试执行的主线可以拆成五个动作：分配、运行、记录、复核、收口。每个动作都有明确的输入、输出和完成标志，缺一项就容易出现“跑完了但说不清结果”的情况。执行开始前先确认三项准入条件：用例已经过评审且版本固定；测试环境可用，依赖服务与测试数据就绪；被测版本与构建号已确定并记录。三项未满足时，执行记录中的失败无法区分是产品缺陷还是环境问题，后续统计会失真。
| 动作 | 输入 | 做法 | 输出 | 完成标志 |
|---|---|---|---|---|
| 分配 | 已评审用例集、版本/构建号、环境清单、人员可用时间 | 按用例集、模块或优先级切分任务，指定每条用例的执行人和计划完成时间；同步标注环境负责人 | 执行任务清单，含用例范围、责任人、截止时间 | 每条用例都有唯一执行人，无未分配项 |
| 运行 | 执行任务清单、可用环境、测试数据 | 按优先级从高到低运行；执行人按步骤操作，遇到环境异常先记录再判断是否阻塞 | 逐条运行的实际结果 | 计划内用例均已运行或标记为阻塞/未执行并说明原因 |
| 记录 | 运行结果、截图或日志等证据 | 填写实际结果、状态、证据和失败现象；失败项同步创建问题单并回填编号 | 完整的执行记录 | 每条记录字段齐全，失败项均有关联问题单 |
| 复核 | 执行记录、问题单列表 | 审核人抽查记录质量，核对状态与实际证据是否一致，纠正误标 | 复核意见与修正后的记录 | 抽查范围内记录无缺项、无误标 |
| 收口 | 执行记录汇总、问题单状态、阻塞项清单 | 统计通过率、阻塞率，汇总遗留风险，给出本轮是否可收口的结论 | 收口结论与遗留风险说明 | 结论有数据支撑，遗留风险有责任人和处理计划 |
失败项的处理边界需要提前说清：执行人确认失败后，把现象、复现步骤和环境信息转成问题单，执行记录中回填问题单编号，本轮执行的职责到此为止。修复后的回归验证属于缺陷闭环环节，另行安排，避免执行周期被无限拉长。收口时看三类数据：通过率反映功能基本可用程度；阻塞率反映环境或依赖对执行完整性的影响；遗留风险说明未执行项和已知失败项的处置安排。三者结合才能判断本轮是否具备发布条件。
在工具承载上，ONES测试管理支持测试计划与迭代关联，并可将用例分配执行人，多维度查看测试计划进度；未通过的用例可一键创建缺陷任务，在测试与研发团队间流转。这套流程适合希望把执行任务分配、结果记录和问题转出放在同一工作项体系中的团队，具体字段与状态配置以团队实际环境为准。
执行记录需要哪些字段
执行记录的最小字段集要同时满足三个用途：统计通过率、追溯单条结果、交接给下一环节。字段太少无法统计，字段太多执行人填写负担重、容易敷衍。下表给出一份可直接复用的字段设计，必填项保证可统计可追溯，选填项按团队需要补充。
| 字段 | 必填 | 取值口径 | 用途 |
|---|---|---|---|
| 用例标识 | 是 | 用例编号，与用例库一致，不重复 | 关联用例与需求，支持追溯 |
| 版本/构建号 | 是 | 被测版本号加构建号，精确到本次构建 | 区分不同构建下的结果差异 |
| 环境 | 是 | 环境名称加关键配置说明，如测试环境A、数据库版本 | 判断失败是否与环境相关 |
| 执行人 | 是 | 实际运行该条用例的人，非任务分配人 | 结果责任归属与问题追问 |
| 执行时间 | 是 | 精确到日期，跨天执行记录完成时间 | 判断结果时效性 |
| 实际结果 | 是 | 简述系统实际表现，与预期结果对应 | 失败分析与复核依据 |
| 状态 | 是 | 通过/失败/阻塞/未执行，四选一，不混用 | 统计通过率与阻塞率 |
| 证据附件 | 失败时必填 | 截图、日志或录屏，能支撑失败判断 | 减少口头描述歧义 |
| 失败现象描述 | 失败时必填 | 复现步骤加实际与预期差异 | 转问题单的直接输入 |
| 关联问题单编号 | 失败时必填 | 问题单唯一编号，一条失败对应至少一个编号 | 连接执行与缺陷跟踪 |
| 备注 | 否 | 阻塞原因、依赖说明等补充信息 | 辅助复核与交接 |
取值规范上有几个容易出错的点。状态取值要互斥，“失败但已提问题单”仍记为失败，不能因为提了单就改成通过；阻塞与失败要分开，环境不可用、依赖服务未就绪导致的无法运行记为阻塞，产品行为不符合预期记为失败；未执行要写清原因，是时间不足、优先级调整还是前置条件未满足。执行人字段填实际运行人而非任务分配人，多人协作时才能定位到具体操作者。证据附件在失败时必填，通过项可按团队要求选填，但涉及核心功能的通过项建议保留证据，便于后续复核。
角色分工与各自交付物
测试执行涉及五类角色，分工不清时最常见的问题是失败项无人认领、环境问题拖住整批用例、记录质量无人把关。下表按角色列出动作、交付物和交接时点，团队可按规模合并角色，但交付物不能省。
| 角色 | 主要动作 | 交付物 | 交接时点 |
|---|---|---|---|
| 测试负责人 | 制定执行排期，按模块和优先级分配任务，跟踪进度，组织收口判断 | 执行任务清单、进度跟踪表、收口结论 | 执行开始前交付任务清单；收口时交付结论 |
| 用例执行人 | 按步骤运行用例，填写执行记录，失败项提交问题单并回填编号 | 逐条执行记录、问题单 | 每条用例运行完成后即时更新；当日执行结束前完成记录 |
| 环境/数据负责人 | 准备并维护测试环境，准备测试数据，处理环境异常 | 环境可用性说明、数据准备清单、环境问题处理记录 | 执行开始前确认环境就绪；执行期间响应环境问题 |
| 开发与产品角色 | 确认失败项是否成立，参与优先级判断，明确修复安排 | 失败项确认意见、优先级结论 | 问题单提交后按约定时限确认 |
| 结果审核人 | 抽查执行记录质量，核对状态与证据一致性，纠正误标 | 复核意见、修正记录 | 执行中期抽查一次，收口前完成终审 |
交接时点决定了协作节奏。任务清单在执行开始前交付，执行人才能按优先级安排时间；环境就绪确认要在第一批用例运行前完成，否则阻塞项会集中出现；问题单提交后开发与产品的确认时限建议在团队内约定，避免失败项长期悬空；复核安排在执行中期和收口前两个节点，中期抽查能及时纠正填写习惯，终审保证收口数据可信。ONES测试管理支持为不同用户组配置权限，也可为用例库和测试计划单独配置权限，适合按上述角色划分查看与操作范围。
一次完整执行周期的示例
以下为演示情景，用于说明流程与字段如何落地，数据为虚构。某版本计划执行一组登录与权限相关用例，共40条，由两名执行人分担，测试环境为测试环境A，构建号为v2.3.0-118。
分配阶段，测试负责人按模块切分：执行人甲负责登录与账号安全共22条，执行人乙负责权限校验共18条，计划两个工作日内完成，环境负责人确认测试环境A可用、测试账号数据已准备。运行阶段，执行人甲按优先级先跑高优先级用例，其中一条“连续输错密码锁定”用例实际结果为账户未锁定，状态记为失败，附截图与操作日志，提交问题单并回填编号BUG-1042；另一条“短信验证码有效期”用例因短信服务未接入测试环境无法运行，状态记为阻塞，备注写明解除条件为短信服务测试通道开通。执行人乙在权限校验中发现一条越权访问用例失败，回填编号BUG-1043。
收口阶段，40条用例中通过34条、失败3条、阻塞2条、未执行1条，通过率85%，阻塞率5%。失败项均已关联问题单并由开发确认，阻塞项有明确解除条件和责任人，未执行项为低优先级用例，经测试负责人确认转入下轮。收口结论为本轮核心功能可用，遗留风险为2条阻塞项涉及的验证码与短信相关功能未覆盖，需在短信通道开通后补测。这个示例中常见的填写错误有两处：一是执行人曾把阻塞项误记为失败，导致失败率虚高，复核时按“环境原因无法运行记为阻塞”的规则纠正；二是失败项提交问题单后有人把状态改成通过，复核时恢复为失败并保留问题单编号，保证统计口径一致。
执行质量的完成检查
收口前逐项核对下表，全部通过项满足、无阻断项时，本轮测试执行可判定为达到收口标准。检查结果建议形成书面记录，与收口结论一并留存。
| 检查项 | 通过标准 | 阻断条件 |
|---|---|---|
| 用例覆盖与执行率 | 计划内用例执行率达标，未执行项均有原因说明和处置安排 | 高优先级用例存在未执行且无说明 |
| 失败项归属 | 每条失败项均有关联问题单编号和确认人 | 存在失败项无问题单或无归属 |
| 阻塞项处理 | 每条阻塞项写明解除条件、责任人和预计解除时间 | 阻塞项无责任人或无解除条件 |
| 记录完整性 | 必填字段无缺失，状态取值符合规范，失败项证据齐全 | 抽查发现关键字段缺失或状态误标未纠正 |
| 状态准确性 | 复核抽查中状态与实际证据一致 | 存在为赶进度虚标通过的情况 |
| 遗留风险结论 | 未覆盖功能和已知失败项形成书面风险说明，含影响范围与处理计划 | 遗留风险无书面结论 |
检查通过后，测试负责人汇总通过率、阻塞率和遗留风险，形成收口结论并同步给开发与产品角色。ONES测试管理提供测试情况概览，可查看测试计划的进度和通过率，作为收口判断的数据来源之一；统计口径与收口标准仍需团队在流程中自行约定。执行记录和问题单编号保留在同一体系中，下一轮回归或后续版本追溯时可直接查阅，减少交接时的信息丢失。
常见问题
用例执行到一半环境不可用，已跑完的结果要作废重跑吗？
不必整批作废。先判断环境异常影响的范围：如果已完成的用例在运行时环境正常、证据完整，结果可以保留；受环境影响的用例把状态记为阻塞，备注写明环境问题和解除条件，环境恢复后只补跑这部分。需要警惕的是环境异常期间产生的失败结果，这类失败无法区分是产品缺陷还是环境问题，建议在环境恢复后复跑确认，再决定是否保留失败状态。
执行人把失败项提交问题单后，执行记录里的状态应该改成什么？
状态仍记为失败，只回填问题单编号，不改状态。失败反映的是本次运行的实际结果，问题单反映的是后续处理进展，两者是不同维度。如果因为提了单就改成通过，通过率会虚高，收口判断失去依据。修复完成并回归验证通过后，属于下一轮执行的结果，在本轮记录中保留失败状态和问题单编号即可。
团队规模小，五类角色能不能合并？
可以合并，但要保证交付物不缺失。常见做法是测试负责人兼任结果审核人，用例执行人兼任环境准备，开发角色承担失败项确认。合并后需要特别注意两点：一是复核环节不能由执行人自己完成，否则记录质量问题难以发现；二是环境问题要有明确对接人，避免执行人一边跑用例一边排查环境，拖慢整体进度。
通过率达到多少才算可以收口？
没有统一阈值，通过率需要结合用例优先级和失败项性质判断。更稳妥的做法是先约定规则：高优先级用例全部执行且失败项均已确认，遗留失败项不影响核心功能，阻塞项有明确解除计划。满足这些条件时，通过率即使未达某个百分比也可以收口；反之，通过率数字好看但存在高优先级用例未执行，也不应直接收口。
执行记录和问题单分散在不同工具里，怎么保证可追溯？
关键是执行记录中保留问题单唯一编号，并在问题单中回填对应的用例标识，形成双向引用。工具层面，ONES测试管理支持对未通过的用例一键创建缺陷任务，缺陷任务在测试与研发团队间流转，执行记录与问题单在同一工作项体系中，追溯时可直接跳转查看。如果团队使用多套工具，至少在收口汇总时核对编号对应关系，避免出现有失败记录但找不到问题单的情况。
