测试执行是把已评审的测试用例按计划落到真实运行环境中的过程，核心是五步：确认准入条件、分配执行任务、逐条执行并记录、登记失败项、汇总轮次结果。本文按这五步展开操作动作、角色交付物和收尾检查，适用于手工执行一轮功能测试的场景；缺陷修复闭环和测试报告编写不在本篇展开。
要点总览（TL;DR）
- 测试执行按五步推进：确认准入条件、拆分并分配任务、逐条执行并记录、登记失败项、汇总轮次结果并判断收尾。
- 准入核对覆盖被测版本、测试环境、已评审用例、测试数据与账号、执行安排五项；条件不满足时记录阻塞原因并同步负责人决定顺延或调整范围。
- 每条用例留下结论、实际结果和证据，失败项先判定为产品缺陷、用例问题或环境问题，再决定是否登记缺陷单。
- 执行期间按日或按轮跟踪已执行数、通过数、失败数、阻塞数和通过率，阻塞项当天协调处理，延期项写明原因和计划轮次。
- 收尾以计划内用例全部有结论、失败项均有判定、记录可追溯到版本与执行人为标准，再决定进入回归或收尾。
测试执行前要确认哪些准入条件
开始执行前，先确认五项条件齐备。条件不满足时强行开跑，后续记录会混入大量环境噪声，失败项也难以判定归属。
| 核对项 | 确认内容 | 确认方式 |
|---|---|---|
| 被测版本 | 版本号与构建号已固定，构建产物可追溯 | 与开发或发布负责人核对构建记录 |
| 测试环境 | 环境可访问，配置与目标环境一致，依赖服务正常 | 执行冒烟用例或环境自检清单 |
| 测试用例 | 用例已评审，优先级、所属模块、预期结果明确 | 检查用例库状态与评审记录 |
| 测试数据与账号 | 各角色账号可用，基础数据与边界数据已准备 | 逐条登录验证，抽样检查数据 |
| 执行安排 | 执行人、执行轮次、时间窗口已确定 | 对照测试计划确认 |
准入不满足时，处理方式分两类。版本或环境未就绪，记录阻塞原因，在计划中标注阻塞状态并同步测试负责人，由负责人决定顺延执行或调整本轮范围；用例或数据缺失，先补齐再开跑，补齐成本高的用例可标记为下轮执行，并在轮次小结中说明。判断标准很简单：任何一条计划内用例因前置条件缺失而无法得到可信结果，就属于准入未通过。
测试执行的操作步骤：从领任务到记录结果
整轮执行按“拆任务—执行单条—记录结果—推进轮次”的顺序推进，每一步都有明确输入和输出。
拆分任务并指派执行人
测试负责人按模块和优先级拆分本轮用例，把高优先级、影响主流程的用例排在前面，指派到具体执行人。输入是本轮用例清单和人员可用时间，输出是带执行人和执行顺序的任务列表。拆分粒度以一个人一天能完成并记录为参考，模块之间尽量不交叉，减少同一执行人频繁切换上下文。
执行单条用例
单条用例的执行动作固定为四步：准备该用例所需数据和账号；按步骤操作被测功能；将实际结果与预期结果比对；记录结论。比对时以用例写明的预期为准，预期本身模糊的，先与用例作者确认再判定，避免把用例问题记成产品缺陷。
记录实际结果、证据与耗时
每条用例至少留下三项信息：执行结论（通过、失败、阻塞、未执行）、实际结果描述、证据。失败和阻塞项附截图或日志，日志截取与失败时间点对应的片段。执行耗时按用例记录，用于后续估算同类模块的测试工作量。记录在执行的当下完成，事后补记容易丢失细节。
失败项初步判定
失败项先做归属判断，再决定后续动作：
- 产品缺陷：按用例步骤可稳定复现，实际结果与预期不符，登记缺陷单。
- 用例问题：步骤描述有歧义、预期已过时或数据不适用，标记用例待修订，不计入产品失败。
- 环境问题：依赖服务异常、数据被污染或配置错误，标记阻塞，修复环境后重跑该用例。
状态标记与轮次推进
每条用例执行后立即更新状态，整轮用例全部有结论（通过、失败、阻塞或明确延期）后，本轮执行结束，进入小结。未执行且无说明的用例不能带入下一轮，否则进度统计会失真。
在工具中承载这套流程时，ONES 测试管理支持用例分配执行人，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，执行记录和缺陷登记可以在同一处衔接。
执行中发现问题怎么登记和流转
失败项判定为产品缺陷后，登记为缺陷单。缺陷单的质量决定开发能否一次定位问题，字段按下表填写。
| 字段 | 填写要求 |
|---|---|
| 标题 | 一句话说明现象和位置，如“登录页验证码错误时提示文案不显示” |
| 复现步骤 | 按操作顺序编号，包含前置条件和输入数据 |
| 预期结果 | 引用用例中的预期，写明依据 |
| 实际结果 | 描述观察到的现象，附截图或日志 |
| 环境与版本 | 环境名称、被测版本号与构建号、浏览器或设备信息 |
| 严重程度 | 按对主流程的影响分级，如阻断、严重、一般、轻微 |
| 关联用例 | 填写来源用例编号，便于回溯和回归时定位 |
缺陷与用例的关联建议双向保留：缺陷单记录来源用例编号，用例的执行记录指向缺陷单号。回归时按用例找到关联缺陷，验证修复是否覆盖原场景。
环境问题和用例缺陷不登记为产品缺陷。环境问题在轮次记录中标注阻塞原因和处理人；用例缺陷走用例修订流程，修订后在下轮执行。提交后的缺陷单由测试负责人或指定的缺陷管理角色确认信息完整性，再分派给对应模块的开发人员；信息不全的退回补充，避免开发反复询问复现条件。
角色分工与各环节交付物
测试执行涉及四类角色，职责边界按环节划分，交付物可逐项核对。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 测试负责人 | 制定本轮执行计划，拆分并分配任务，跟踪进度，组织轮次小结，判断是否进入回归或收尾 | 执行计划、任务分配表、轮次执行小结 |
| 执行测试人员 | 按用例执行，记录实际结果与证据，判定失败项归属，登记缺陷单 | 用例执行记录、证据附件、缺陷单 |
| 开发人员 | 确认缺陷是否成立，补充定位所需信息，说明修复范围 | 缺陷确认意见、补充信息 |
| 环境与数据支持角色 | 维护测试环境可用，准备和刷新测试数据与账号，处理环境阻塞 | 环境就绪确认、数据准备记录、阻塞处理记录 |
小团队中测试负责人常同时承担执行工作，此时建议把计划与分配动作和具体执行记录分开留存，便于事后区分“计划安排”和“实际执行”的差异。ONES 测试管理支持为不同用户组配置权限，也可为用例库、测试计划单独配置权限，角色边界可以在工具权限上对应落地。
一轮测试执行的示例：登录模块怎么跑完
以下为演示情景，用于说明执行流程，数据为示例值。
背景与范围。某版本登录模块本轮共 24 条用例，覆盖账号密码登录、验证码、找回密码、异常提示四类场景，其中高优先级 10 条、中优先级 9 条、低优先级 5 条。被测版本为 2.4.0，构建号 20240612-3。
分配与顺序。测试负责人将用例按场景分给两名执行人：执行人 A 负责账号密码登录与验证码共 14 条，执行人 B 负责找回密码与异常提示共 10 条。执行顺序为先高优先级主流程，再中优先级分支，最后低优先级边界场景。首日先跑 3 条冒烟用例确认环境和账号可用。
典型失败项记录。执行人 A 执行“验证码错误时提示文案”用例时，输入错误验证码后页面无任何提示。记录内容为：结论失败；实际结果为点击登录后页面停留在原页，无提示文案；附页面截图和控制台日志；耗时 4 分钟。初步判定为产品缺陷，登记缺陷单，标题为“登录页验证码错误时无提示文案”，复现步骤三步，预期引用用例原文，环境为测试环境 2.4.0 构建 20240612-3，严重程度定为严重，关联用例编号 TC-LOGIN-017。
轮次小结。24 条用例全部有结论：通过 19 条、失败 3 条、阻塞 1 条、延期 1 条。3 条失败中 2 条登记为缺陷、1 条判定为用例预期过时；阻塞项为短信服务不可用，已由环境支持角色处理；延期项为低优先级兼容性用例，说明顺延至下轮。小结中列出通过率、缺陷清单和遗留项，测试负责人据此决定修复后进入回归。
执行进度与结果如何跟踪
执行期间跟踪五个指标，按日或按轮同步，出现异常时及时调整范围或人力。
| 指标 | 含义 | 异常信号 |
|---|---|---|
| 已执行数 | 本轮已有结论的用例数 | 进度明显落后于计划 |
| 通过数 | 结论为通过的用例数 | 通过率持续偏低 |
| 失败数 | 判定为产品缺陷的用例数 | 集中在同一模块，提示该模块质量风险 |
| 阻塞数 | 因环境或数据无法执行的用例数 | 阻塞持续超过半天 |
| 通过率 | 通过数占已执行数的比例 | 与历史同模块水平差距明显 |
同步节奏建议每日一次短会或一条进度消息，内容为当日执行数、新增缺陷、阻塞项和处理人。轮次结束时出一份执行小结，汇总上述指标和遗留项。阻塞项由测试负责人当天协调环境支持角色处理，超过约定时间未解决的，调整本轮范围并在小结中说明；延期项需写明原因和计划执行轮次，不能只标“未执行”。
ONES 测试管理提供测试情况概览，可查看测试计划的进度和通过率，多维度概览全部测试计划，进度展示的具体指标口径以实际产品界面为准。
判定本轮执行可以结束的条件是：计划内用例全部有明确结论，失败项均已完成登记或判定，阻塞项已有处理结论或转入下轮说明。满足这三条即可结束本轮，进入缺陷修复后的回归安排。
完成检查：本轮测试执行是否做到位
收尾时逐项核对下表，全部满足才判定本轮执行完成。
| 检查项 | 通过标准 |
|---|---|
| 计划内用例执行完成情况 | 计划内用例全部有结论，延期项写明原因和下轮安排 |
| 失败项结论 | 每条失败项已判定为缺陷、用例问题或环境问题，无悬空项 |
| 记录完整性 | 每条用例有实际结果，失败和阻塞项有截图或日志，缺陷单关联来源用例 |
| 可追溯性 | 执行记录能对应到具体版本、构建号和执行人 |
| 遗留与阻塞说明 | 阻塞项有处理记录，遗留项有责任人和计划轮次 |
| 轮次小结 | 小结包含执行数、通过率、缺陷清单和遗留项 |
进入回归的判断条件是：本轮登记的缺陷已完成修复并有明确修复说明，回归范围覆盖原失败用例及其关联场景。进入收尾的判断条件是：回归通过率达到本轮约定标准，遗留项均为低优先级且有明确处理计划。两项条件都不满足时，继续执行或补充一轮，并在小结中说明原因。
常见问题
测试执行到一半发现环境不稳定，已经跑过的用例要重跑吗？
按影响范围判断。环境问题只影响部分用例时，先标记这些用例为阻塞，修复环境后重跑；已通过且执行时环境正常的用例，记录中保留原结论，不必全部重跑。若环境异常发生在执行前就已存在，或导致数据被污染、结果不可信，则受影响的用例需要重跑，并在轮次小结中说明重跑范围和原因。判断依据是执行当时的环境状态是否有记录可查，因此环境自检结果和阻塞处理记录要一并留存。
用例执行失败，但开发认为不是缺陷，这种情况怎么处理？
把分歧落到可核对的信息上。执行人补充复现步骤、实际结果截图或日志、环境与构建号，开发说明其判断依据，例如设计如此、需求已变更或数据不适用。双方对照用例预期和需求文档确认：属于需求变更的，走用例修订，下轮按新预期执行；确认是缺陷的，保留缺陷单继续流转；暂时无法达成一致的，由测试负责人记录争议点并在轮次小结中列为待确认项，避免悬空。
一轮测试执行中，低优先级用例时间不够，可以跳过吗？
可以顺延，但要留下说明。把未执行的用例标记为延期，写明原因和计划执行轮次，并在轮次小结中列出，不能只标“未执行”就结束本轮。顺延的前提是高优先级主流程用例已全部有结论、失败项已登记。如果低优先级用例涉及本次变更的核心场景，建议调整人力优先执行，或与测试负责人确认风险后再顺延。
执行记录只写通过或失败，不附截图可以吗？
通过项可以只记录结论和实际结果简述；失败项和阻塞项建议附证据。截图或日志的作用是让开发一次定位问题、让回归时能对照原场景，缺少证据的缺陷单常被退回补充，反而拉长处理时间。证据截取与失败时间点对应的片段，日志保留关键报错行即可，不必整份上传。
多人同时执行同一模块，进度怎么汇总才不重复？
以用例为最小统计单位，每条用例只对应一个执行人和一个当前状态，汇总时按用例状态计数，不按人头累加。任务拆分时避免同一用例分给两人，模块交界处的用例明确归属。每日同步时由测试负责人汇总各执行人的状态更新，发现同一用例出现两条记录时及时合并，保留最新结论并注明变更原因。
