判断测试目标是否达成，需要先把目标转成可核验的判定条件，再用测试结果、缺陷和覆盖率三类证据相互印证。本文给出目标拆解、指标公式、数据口径、计算步骤和示例，并说明分母为零、数据不可比时如何处理，以及指标结论的适用边界。
要点总览（TL;DR）
- 判断测试目标是否达成，先把目标拆成质量对象、范围、版本基线与时间窗、判定条件四要素，并设计达成、部分达成、未达成三档结论。
- 测试结果、缺陷、覆盖率三类证据各看一个侧面：执行率与通过率反映已测部分的进度和稳定度，严重缺陷关闭率与遗留缺陷分级反映问题收敛情况，需求覆盖率与代码覆盖率反映测试触达范围。
- 每个指标都要写清分子、分母、单位与统计时点，分母为零标注“不适用”，数据缺失或口径变更要显式说明，结论才能被复算和复核。
- 评估按证据齐备、逐项计算、与预设条件比对、例外说明、形成结论的顺序执行，未达标项是否落在必选范围内决定最终判定。
- 指标反映统计时点的状态，不构成质量保证；阈值应结合业务风险设定，覆盖率与通过率都需要结合用例设计和失败分布解读。
评估目标：把测试目标拆成可判定的条件
“本轮测试要保证版本质量”“核心功能要稳定可用”这类表述无法直接判断是否达成，因为缺少对象、范围和判定标准。可判定的测试目标至少包含四个要素：测什么（质量对象）、测到哪里（范围）、以什么版本和什么时间段的数据为准（版本基线与时间窗）、达到什么状态算完成（判定条件）。
质量对象决定后续选哪类指标。功能测试关注需求是否被用例覆盖、用例是否通过；性能测试关注响应时间、吞吐量、资源占用在指定负载下是否落在预设区间；兼容性测试关注目标设备、浏览器、操作系统组合上的通过情况；安全测试关注既定检查项和高风险问题的关闭状态。一个版本可能同时包含多个质量对象，此时应为每个对象分别设定判定条件，再汇总为整体结论。
范围界定要写清楚哪些需求、模块、接口或场景纳入本轮测试，哪些明确排除。范围之外的缺陷和覆盖率不计入本轮判定，避免用全量数据掩盖局部缺口，也避免把未纳入的内容算作遗漏。版本基线与时间窗同样要固定：以哪个构建号、哪个分支的代码为准，数据统计截止到哪一天，缺陷状态以截止时点的快照为准还是以关闭时间为准。
判定条件建议设计为三档，而不是简单的“达成/未达成”。达成指所有必选条件均满足；部分达成指核心条件满足但存在已记录的例外或次要条件缺口；未达成指任一必选条件未满足。三档设计让结论能承载“可以发布但需带风险上线”这类真实情形，也迫使团队提前约定哪些条件属于必选、哪些属于参考。
| 目标表述（改写前） | 质量对象 | 范围 | 版本基线与时间窗 | 判定条件（示例） |
|---|---|---|---|---|
| 核心功能要稳定可用 | 功能 | 订单、支付、退款三个模块的P0/P1需求 | 构建号v3.2.0，统计至发布前一日24:00 | P0用例通过率100%，P1用例通过率≥95%，无未关闭的致命/严重缺陷 |
| 接口性能要达标 | 性能 | 下单与查询两个核心接口 | 同一构建号，压测执行当日 | 在约定并发下P95响应时间≤预设值，错误率≤预设值 |
| 主流机型要兼容 | 兼容性 | 约定的机型与系统版本清单 | 同一构建号，兼容性测试轮次内 | 清单内每个组合的核心路径用例全部通过 |
这张对照表应在测试计划阶段完成并经过评审，评估阶段只做比对，不再临时调整条件。条件一旦变更，要在报告中记录变更原因和影响范围。
指标与范围：测试结果、缺陷、覆盖率各看什么
三类证据回答不同问题：测试结果说明“计划要测的测了没有、结果如何”，缺陷说明“已发现的问题严重程度和收敛情况”，覆盖率说明“测试触及的范围是否足够”。任何一类单独使用都可能得出片面结论，判定时需要组合。
测试结果类指标
这类指标的分母要区分“计划用例数”和“已执行用例数”，混用会导致通过率虚高或虚低。
- 计划用例执行率＝已执行用例数÷计划用例数×100%，单位是百分比，反映测试进度，不反映质量。
- 用例通过率＝通过用例数÷已执行用例数×100%，分母是已执行数，反映已测部分的稳定程度。
- 阻塞率＝阻塞用例数÷计划用例数×100%，反映环境、依赖或前置条件造成的测试中断程度。阻塞用例既不算通过也不算失败，需单独列出。
执行率低时，通过率再高也不能作为达成依据，因为大量用例尚未验证。反过来，执行率高但阻塞率也高，说明有效验证的比例不足。
缺陷类指标
- 缺陷发现密度＝统计期内新增有效缺陷数÷统计口径下的工作量或需求数。分母必须事先约定，用需求数、用例数还是人天，不同口径的结果不可直接比较。
- 严重缺陷关闭率＝已关闭的致命与严重缺陷数÷致命与严重缺陷总数×100%。分母是该版本累计发现的严重缺陷，不是某一时点的存量。
- 遗留缺陷分级：按严重级别列出截止时点仍未关闭的缺陷数量，并标注每个遗留缺陷的影响范围和规避方案。
缺陷指标依赖严重级别定义的一致性。同一问题在不同团队被定为“严重”或“一般”，关闭率就失去可比性。缺陷发现密度还受测试深度影响，密度低可能是质量好，也可能是测试不够深入，需要结合覆盖率和用例设计情况解读。
覆盖率类指标
- 需求覆盖率＝已关联测试用例的需求数÷纳入范围的需求数×100%，反映需求是否都有对应用例。
- 用例覆盖率＝已设计用例的需求点÷需求点总数×100%，粒度比需求覆盖率细，适合需求点可枚举的场景。
- 代码覆盖率＝已执行代码行（或分支）÷可执行代码行（或分支）×100%，通常由工具统计，反映自动化或手工执行触达的代码比例。
覆盖率只说明“测到了”，不说明“测得对”。需求覆盖率达到100%仍可能存在用例设计遗漏边界条件的情况；代码覆盖率高也可能缺少有效断言。因此覆盖率适合作为必要条件之一，不能作为达成结论的唯一支撑。
| 指标名 | 公式 | 分子 | 分母 | 单位 | 时间窗 | 数据来源 |
|---|---|---|---|---|---|---|
| 计划用例执行率 | 已执行÷计划 | 已执行用例数 | 计划用例数 | % | 本轮测试起至截止时点 | 测试管理工具用例执行记录 |
| 用例通过率 | 通过÷已执行 | 通过用例数 | 已执行用例数 | % | 同上 | 用例执行结果 |
| 阻塞率 | 阻塞÷计划 | 阻塞用例数 | 计划用例数 | % | 同上 | 用例执行结果中的阻塞标记 |
| 缺陷发现密度 | 缺陷数÷工作量口径 | 新增有效缺陷数 | 约定口径（需求数/用例数/人天） | 个/单位 | 本轮测试周期 | 缺陷管理系统 |
| 严重缺陷关闭率 | 已关闭严重÷严重总数 | 已关闭致命与严重缺陷数 | 累计致命与严重缺陷数 | % | 截至截止时点 | 缺陷管理系统状态快照 |
| 需求覆盖率 | 已覆盖需求÷纳入需求 | 已关联用例的需求数 | 纳入范围需求数 | % | 测试计划确定时 | 需求与用例关联关系 |
| 代码覆盖率 | 已执行代码÷可执行代码 | 已执行行或分支 | 可执行行或分支 | % | 执行完成后统计 | 覆盖率工具报告 |
数据口径与证据：怎样保证结果可复算
同一组数字，取数时点不同、缺陷状态归类不同，结论可能相反。可复算的前提是口径写在报告里，任何人按同样规则能算出同样结果。
数据来源与统计时点要一致。用例执行数据、缺陷数据、覆盖率报告应来自同一版本基线，统计截止时点统一。如果缺陷数据取自截止日当天上午、用例数据取自当天晚上，中间新增的缺陷和执行的用例会造成口径错位。建议在报告中写明每个数据集的导出时间和来源系统。
缺陷归类规则需要提前约定：哪些状态算“已关闭”（已修复并验证通过，还是仅标记为已修复）；严重级别采用哪套定义；重复缺陷、无效缺陷、非本版本引入的缺陷是否计入分母。通常重复和无效缺陷不计入有效缺陷数，但要在报告中披露剔除数量，避免通过大量标记无效来美化关闭率。
分母为零和数据缺失要显式处理。某模块没有严重缺陷时，关闭率的分母为零，此时应标注“不适用”，而不是记为100%。某类数据无法获取时，标注缺失并说明对结论的影响，不能以零值代入计算。口径在评估中途发生变更时，新旧口径的数据不可直接合并，应分段呈现或按新口径重算历史数据。
证据留存方面，测试报告、缺陷清单导出、覆盖率报告应作为附件与结论一起归档，缺陷清单至少包含编号、严重级别、状态、发现时间、关闭时间。这样结论被质疑时可以回溯到原始记录，而不是只保留一个汇总百分比。
当用例执行、缺陷流转和测试报告在同一套测试管理工具中完成时，取数口径更容易保持一致。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，同时提供测试计划进度与通过率概览、缺陷分布统计和可自定义组装的测试报告模板。评估前可在其中固定统计时点、导出缺陷清单与报告，作为口径说明的附件。
计算与评估步骤：从证据到达成结论
评估按固定顺序执行，每一步留下记录，避免先看结果再找理由。
- 确认证据齐备与口径一致。核对三类数据是否都来自同一版本基线、统计截止时点是否统一、缺陷状态与严重级别定义是否与计划一致。缺哪类数据、哪类数据口径有变更，先记录再进入计算。
- 逐项计算指标并记录分母。每个指标写出分子、分母和计算结果，分母为零的标注“不适用”。计算过程保留在评估记录中，便于复核。
- 与预设判定条件比对。逐条对照测试计划中的必选条件和参考条件，标记满足、不满足、无法判断三种状态。无法判断通常意味着数据缺失或口径不一致，需要回到第一步补充。
- 对例外与偏差做说明。列出未满足的条件、遗留缺陷、阻塞用例和口径变更，说明原因、影响范围和应对措施。例外说明是“部分达成”结论的组成部分，不能省略。
- 形成结论。所有必选条件满足且无重大例外，判为达成；核心条件满足但存在已记录例外或次要条件缺口，判为部分达成；任一必选条件未满足且无有效替代证据，判为未达成。结论后附证据清单和限制说明。
结论模板可以写成：本轮测试对象为某版本某范围，统计截止某时点；执行率、通过率、严重缺陷关闭率、需求覆盖率分别为多少；必选条件中哪几项满足、哪几项不满足；遗留缺陷若干，其中严重级别若干，影响范围如何；综合判定为达成、部分达成或未达成，并列出后续动作。
示例：一次版本测试目标的达成判断
以下为演示用假设数据，不对应真实项目。
假设目标：v3.2.0版本订单与支付模块的功能测试，纳入需求20个，计划用例400条，判定条件为——计划用例执行率≥95%，用例通过率≥95%，致命与严重缺陷关闭率100%，需求覆盖率100%，且无未关闭的致命缺陷。
测试结果数据：已执行用例380条，其中通过355条，失败18条，阻塞7条。计算得执行率＝380÷400＝95%，通过率＝355÷380≈93.4%，阻塞率＝7÷400＝1.75%。执行率刚好达到条件，通过率低于95%。
缺陷数据：本轮累计发现有效缺陷60个，其中致命2个、严重10个。致命缺陷已全部关闭，严重缺陷关闭9个，1个仍处于待验证状态。严重缺陷关闭率＝9÷12＝75%，未达到100%。需求覆盖率：20个需求全部关联了用例，覆盖率100%。
比对结果：执行率满足，需求覆盖率满足，通过率不满足，严重缺陷关闭率不满足。例外说明：未通过的18条用例中，12条集中在两个非核心的报表导出场景，已确认不影响主流程；剩余1个严重缺陷为支付回调偶发延迟，已有临时规避方案，计划下个版本修复。阻塞的7条用例因第三方沙箱环境不可用，已记录并在环境恢复后补测。
结论：判为部分达成。核心下单与支付主流程用例全部通过，致命缺陷清零；未达标项集中在非核心场景和1个已记录严重缺陷。遗留风险为支付回调偶发延迟和7条未执行用例，需在发布说明中披露，并在下个版本跟踪关闭。这个例子说明，通过率和关闭率未达100%并不自动等于未达成，关键看未达标项是否落在必选范围内、是否有可接受的例外说明。
解读与限制：指标能说明什么、不能保证什么
指标反映的是统计时点的状态，不构成质量保证。通过率高说明已执行用例在当次执行中结果符合预期，不能证明未覆盖的场景没有问题；严重缺陷关闭率高说明已知严重问题处理得好，不能证明没有尚未发现的严重问题。把指标当作因果结论，容易在发布后出现预期外的质量问题。
阈值应结合业务风险和版本性质设定。面向大量用户的核心交易系统与内部工具的容忍度不同，紧急修复版本与常规版本的判定条件也可以不同。套用统一的“通过率95%”这类通用达标线，可能对高风险模块过于宽松，对低风险模块过于严格。阈值应在测试计划阶段依据影响范围和故障后果确定，并写明依据。
覆盖率存在几类常见误读：需求覆盖率高不等于用例设计充分，可能只是每条需求挂了一个简单用例；代码覆盖率高不等于验证有效，缺少断言的执行同样计入覆盖；覆盖率统计范围可以被人为缩小，报告应说明分母包含哪些代码或需求。解读覆盖率时，应同时看用例设计评审记录和失败用例的分布。
结论沟通中要同时呈现限制与假设：数据截止时点、口径变更、被剔除的无效缺陷数量、未执行或阻塞的用例、无法获取的数据。只呈现达标指标、隐去例外，会让结论失去可复核性。评估记录的价值在于让后续版本能对比同一口径下的变化，因此口径说明和证据附件应与结论一同归档。
常见问题
测试目标里写了“核心功能稳定可用”，评估时怎么落地成可判断的条件？
把这类表述拆成四要素：质量对象（功能）、范围（哪些模块和需求级别）、版本基线与时间窗（哪个构建号、统计截止到哪天）、判定条件（例如P0用例通过率100%、无未关闭的致命与严重缺陷）。拆完后在测试计划阶段评审确认，评估时只做比对，不再临时调整条件；确需变更的，在报告中记录变更原因和影响范围。
用例通过率很高，但执行率只有六成，能判为达成吗？
通常不能。通过率的分母是已执行用例数，执行率低意味着大量计划用例尚未验证，已测部分的结果无法代表整体。此时应把执行率作为必选条件之一单独比对，并列出未执行和阻塞用例的原因。如果未执行部分集中在低风险场景且有明确补测计划，可以作为“部分达成”的例外说明，但不能直接用高通过率得出达成结论。
某个模块没有发现严重缺陷，严重缺陷关闭率怎么算？
分母为零时，该指标标注“不适用”，不记为100%，也不记为0%。同时在报告中说明该模块的缺陷分布和测试深度，避免读者把“没有严重缺陷”误读为“质量一定好”。如果某类数据整体无法获取，同样标注缺失并说明对结论的影响，不以零值代入计算。
评估中途缺陷严重级别定义改了，历史数据还能直接合并吗？
新旧口径的数据不可直接合并。可以按新口径重算历史数据，或者分段呈现并注明各段使用的口径。报告中要写清变更时间、变更内容和影响范围，让复核者能判断关闭率等指标在变更前后的可比性。
用ONES做测试目标达成评估，取数环节能省哪些事？
当用例执行、缺陷流转和测试报告在同一套工具中完成时，统计时点和口径更容易保持一致。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，同时提供测试计划进度与通过率概览、缺陷分布统计和可自定义组装的测试报告模板。评估前可在其中固定统计时点、导出缺陷清单与报告，作为口径说明的附件。各报表中指标的具体计算公式，以产品内报表说明为准。
