判断测试目标达成度，需要把测试结果、缺陷和覆盖率三类信息放在同一需求范围、同一版本和同一时间窗内对照：测试结果说明计划内的测试是否执行并达到预期通过水平，缺陷信息说明问题发现与修复是否收敛，覆盖率说明测试是否触达目标需求、代码或风险场景。三类指标回答不同问题，需要先设定目标值、分母口径和退出条件，再综合判断。
要点总览（TL;DR）
- 测试目标达成度需要把测试结果、缺陷和覆盖率三类指标放在同一需求范围、同一版本、同一时间窗内对照，单独看通过率或覆盖率都不足以下结论。
- 测试结果类核心指标包括计划执行率、用例通过率和阻塞用例占比，其中通过率的分母要写明是计划用例、已执行用例还是全部用例。
- 缺陷类核心指标包括缺陷密度、严重缺陷占比、修复率、回归通过率和遗留缺陷数，需提前约定缺陷状态取值与去重规则。
- 覆盖率类指标要区分需求覆盖率、用例覆盖需求比例和代码覆盖率（行/分支），代码覆盖率需注明统计工具与范围。
- 综合判断采用目标值对照加趋势收敛：逐项对照退出条件，对未达标项用另一类指标交叉验证，并写明遗留风险。
评估目标：先明确这次要判断什么
“测试目标达成度”是一个综合判断，需要先拆成几个可以分别回答的问题：计划内的测试做完了吗？做完的部分结果是否达到预期？发现的问题是否收敛到可接受状态？测试是否覆盖了本次要验证的需求和风险？把这些问题写清楚，后面的指标选择才有依据。
测试目标通常有四类。范围完成目标关注计划用例是否执行完毕；质量门槛目标关注通过率、严重缺陷遗留数是否达到约定水平；风险覆盖目标关注高风险需求、关键场景是否被用例和代码执行覆盖；发布准入目标则是上述条件的组合，作为版本能否进入下一阶段的判定依据。一次评估可以只针对其中一类，也可以组合使用，但需要在评估前写明。
评估对象和时间窗要同时锁定。对象可以是某个版本、某次迭代或某个需求集合；时间窗要写明起止日期，并说明统计的是该窗口内创建的数据还是该窗口内更新为某状态的数据。判定方式有两种：目标值对照适合有明确退出条件的发布准入，逐项检查是否达到约定值；趋势收敛适合迭代周期内的过程观察，看缺陷发现量、修复量和遗留量是否随时间收敛。两种方式可以并用，但结论要分别表述。
一份可用的评估目标说明至少包含：评估对象（版本或需求范围）、时间窗、目标类型、判定方式、各项退出条件的目标值及其来源。目标值应由项目或版本负责人在评估前确认，避免事后按结果调整标准。
指标与范围：测试结果、缺陷、覆盖率各看哪些指标
三类指标各自回答不同问题，建议每类选取少量核心指标，并固定公式和分母。下表给出常用指标的定义口径，单位除特别说明外均为百分比。
| 类别 | 指标 | 公式 | 分母口径 | 回答的问题 |
|---|---|---|---|---|
| 测试结果 | 计划执行率 | 已执行用例数 ÷ 计划用例数 × 100% | 本次范围内计划执行的用例总数 | 计划内的测试是否做完 |
| 测试结果 | 用例通过率 | 通过用例数 ÷ 已执行用例数 × 100% | 已执行用例数（需注明是否含阻塞用例） | 执行过的测试结果是否达到预期 |
| 测试结果 | 阻塞用例占比 | 阻塞用例数 ÷ 计划用例数 × 100% | 计划用例数 | 有多少测试因环境或前置问题无法得出结果 |
| 缺陷 | 缺陷密度 | 缺陷数 ÷ 统计基数 | 基数可为需求数、用例数或千行代码，需固定一种 | 问题发现的相对强度 |
| 缺陷 | 严重缺陷占比 | 严重及以上缺陷数 ÷ 缺陷总数 × 100% | 窗口内去重后的缺陷总数 | 问题结构的严重程度 |
| 缺陷 | 修复率 | 已修复缺陷数 ÷ 缺陷总数 × 100% | 窗口内确认的缺陷总数 | 问题处理进度 |
| 缺陷 | 回归通过率 | 回归通过缺陷数 ÷ 已修复待回归缺陷数 × 100% | 进入回归环节的缺陷数 | 修复是否有效且未引入新问题 |
| 缺陷 | 遗留缺陷数 | 截至评估时点仍未关闭的缺陷数（可按严重度分列） | 不适用，为绝对数量，单位：个 | 发布时仍带出的风险 |
| 覆盖率 | 需求覆盖率 | 有用例关联的需求数 ÷ 范围内需求总数 × 100% | 本次版本或迭代内的需求总数 | 需求是否都有测试设计 |
| 覆盖率 | 用例覆盖需求比例 | 被至少一条用例覆盖的需求数 ÷ 范围内需求总数 × 100% | 同上，需与需求覆盖率区分统计来源 | 需求是否真正落到可执行用例 |
| 覆盖率 | 代码覆盖率（行/分支） | 被执行的代码行（分支）数 ÷ 可执行代码行（分支）总数 × 100% | 需注明统计工具、代码范围和排除项 | 测试执行触达代码的程度 |
指标与目标类型的对应关系可以这样安排：范围完成目标主要看计划执行率和阻塞用例占比；质量门槛目标主要看用例通过率、严重缺陷占比、修复率和遗留缺陷数；风险覆盖目标主要看需求覆盖率、用例覆盖需求比例和代码覆盖率；发布准入目标则组合使用，并为每项设定退出条件。缺陷密度和回归通过率适合作为过程观察指标，帮助解释通过率和遗留缺陷的变化原因。
需要提醒的是，用例通过率的分母有三种常见选择：计划用例数、已执行用例数、全部用例数。三者算出的数值差异可能很大，评估报告中必须写明采用哪一种，并在同一版本内保持一致，否则不同轮次的数据不可比。
数据口径与证据：让指标可复算、可核对
指标能否被复核，取决于数据来源是否固定、统计规则是否写明。测试结果数据来自测试管理中的测试计划和用例执行记录；缺陷数据来自缺陷记录中的状态、严重度和创建、关闭时间；覆盖率数据来自需求与用例的关联关系，以及代码覆盖率工具生成的报告。三类数据要按同一需求范围、同一版本、同一时间窗归集，跨版本或跨迭代的数据不混算。
统计规则需要提前约定几件事。去重规则：同一问题被多次提交时，以哪条记录为准，关联重复缺陷如何处理。状态取值规则：缺陷在“已修复未回归”时计入修复率还是遗留数，需要明确；用例状态为“阻塞”时是否计入已执行，也要写明。时间归属规则：按创建时间还是关闭时间落入窗口，会影响修复率和遗留数的结果。这些规则写在口径说明中，评估人和复核人使用同一份。
几种边界情况要单独处理。分母为零时，例如某版本没有严重缺陷，严重缺陷占比不写成0%，而应标注“无数据”并说明原因，避免被误读为表现优秀。用例未执行时，通过率只按已执行用例计算，同时用计划执行率说明执行缺口，两个指标一起看。缺陷状态未关闭时，遗留缺陷数按实际状态统计，并注明其中有多少处于待回归、多少处于未修复，便于判断风险性质。
证据留存建议包括：评估时点的测试报告快照、缺陷列表导出、覆盖率报告原文、口径说明文档和评审记录。报告快照的作用是固定数据，避免后续状态变化导致同一时点的指标无法复现。评审记录写明目标值来源和未达标项的处理结论，作为后续版本对比的依据。
计算与评估步骤：从取数到得出结论
评估可以按五步推进，每一步都有明确的产出，便于交接和复核。
- 确定范围与时间窗。锁定版本号、需求清单和起止日期，确认统计规则，形成评估目标说明。完成标志是范围清单和时间窗经项目负责人确认。
- 按公式计算三类指标。从测试管理导出用例执行记录，从缺陷记录导出缺陷清单，从覆盖率报告取数，按约定分母逐项计算，填入指标表。完成标志是每个指标都有数值、分母和单位。
- 与目标值或退出条件逐项对照。对每项指标标注达标、未达标或无数据，未达标项写明差距。完成标志是形成对照表。
- 对未达标项做原因归集与交叉验证。例如通过率偏低时，查看是否集中在某类需求或某严重度缺陷；覆盖率偏低时，查看是需求未关联用例还是用例未执行。用另一类指标验证判断，避免单一指标下结论。
- 形成达成度结论与遗留风险说明。结论按目标类型分别表述，列出未达标项、遗留缺陷及其严重度、对发布的影响和建议的后续动作。
判定规则建议写成可执行的条目：所有退出条件均达标且无未解释的数据缺口，判定为达成；核心条件达标但存在少量遗留缺陷，判定为有条件达成，并写明遗留缺陷的处理计划；任一核心条件未达标，判定为未达成。趋势收敛判断则看连续几个统计周期内缺陷发现量下降、修复率上升、遗留数收窄，作为过程健康的辅助证据。
在测试执行和缺陷流转环节，ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，测试计划进度和通过率可在计划视图中查看。这些记录可以作为上述指标取数的来源；覆盖率类指标和具体报表口径仍需按团队约定在评估前确认。
例子：一个版本的达成度计算
以下为演示情景，数据为假设值，用于说明计算过程，不代表任何真实项目。某版本评估范围包含40个需求，计划用例200条，时间窗为版本测试开始至发布评审前一日，目标类型为发布准入。
测试结果计算：已执行用例170条，计划执行率 = 170 ÷ 200 × 100% = 85%。已执行用例中通过150条，用例通过率 = 150 ÷ 170 × 100% ≈ 88.2%。阻塞用例8条，阻塞用例占比 = 8 ÷ 200 × 100% = 4%。
缺陷计算：窗口内去重后缺陷60个，按需求数计算缺陷密度 = 60 ÷ 40 = 1.5个/需求。严重及以上缺陷9个，严重缺陷占比 = 9 ÷ 60 × 100% = 15%。已修复48个，修复率 = 48 ÷ 60 × 100% = 80%。进入回归的缺陷40个，回归通过36个，回归通过率 = 36 ÷ 40 × 100% = 90%。遗留缺陷12个，其中严重缺陷2个。
覆盖率计算：40个需求中38个关联了用例，需求覆盖率 = 38 ÷ 40 × 100% = 95%；其中35个需求有至少一条已执行用例，用例覆盖需求比例 = 35 ÷ 40 × 100% = 87.5%。代码覆盖率报告显示行覆盖率72%、分支覆盖率58%，统计范围为本次变更模块。
综合判断：假设退出条件为计划执行率不低于95%、用例通过率不低于90%、严重缺陷遗留为0、需求覆盖率不低于95%。对照后，计划执行率85%未达标，用例通过率88.2%未达标，严重缺陷遗留2个未达标，需求覆盖率95%达标。交叉验证发现，未执行的30条用例中有18条集中在两个需求上，这两个需求的用例覆盖需求比例偏低，与需求覆盖率95%的表面达标形成反差，说明需求覆盖率的分母口径掩盖了执行缺口。结论为未达成，遗留风险主要是2个严重缺陷和两个需求验证不充分。
这个例子暴露的口径问题有两个：需求覆盖率按“关联用例”统计，未区分用例是否执行，容易高估覆盖；用例通过率未说明阻塞用例的处理方式，若将阻塞用例计入已执行，通过率会进一步下降。评估报告中应补充这两项说明。
解读与限制：指标能说明什么、不能说明什么
覆盖率反映测试触达的范围，不直接反映缺陷发现能力。代码覆盖率高的版本仍可能遗漏关键场景，尤其是用例设计未覆盖的边界条件；需求覆盖率高也可能只是关联了用例而用例本身质量不足。覆盖率适合回答“有没有测到”，判断“测得够不够好”需要结合缺陷发现情况和用例评审记录。
通过率受用例设计和执行范围影响很大。用例设计偏简单时通过率自然偏高；只执行容易通过的用例、把困难用例留到最后，也会让阶段性通过率失真。因此通过率要与计划执行率、阻塞用例占比一起看，并说明分母口径。
缺陷指标受发现能力和统计口径双重影响。测试投入增加时缺陷发现量上升，不能直接解读为质量下降；缺陷密度依赖统计基数，按需求数和按代码量算出的结果不可直接比较。修复率和回归通过率还受缺陷状态流转规则影响，状态定义不一致时跨团队数据不可比。
这些指标用于判断测试目标是否达成，提供的是对照依据，不构成质量保证，也不适合直接作为人员绩效结论。建议的做法是固定一组核心指标，连续多个版本按同一口径统计，观察趋势变化；单次评估中至少组合测试结果、缺陷和覆盖率各一项指标，并对未达标项写明原因和后续动作。目标值应结合项目历史数据和风险承受度设定，避免套用统一达标线。
常见问题
计划执行率没达标，但用例通过率很高，能判定测试目标达成吗？
通常不能直接判定达成。通过率高只说明已执行部分的结果较好，未执行部分的质量仍未知。此时应把计划执行率与通过率一起看：先确认未执行用例的原因（环境阻塞、时间不足、需求变更），再看这些用例是否集中在高风险需求上。如果未执行部分涉及核心场景，即使通过率达标，也应判定为有条件达成或未达成，并写明补测计划。
需求覆盖率达到100%，是否说明测试覆盖已经充分？
需求覆盖率只回答“需求是否关联了用例”，不回答用例是否执行、设计是否充分。评估时可以补充用例覆盖需求比例（需求是否落到可执行用例）和计划执行率，三者一起看。若需求覆盖率高但执行率低，说明覆盖停留在设计层面；若两者都高但缺陷仍集中在某类需求，则需要回到用例设计质量上检查。
缺陷发现量在版本后期上升，是否意味着质量变差？
不一定。缺陷发现量受测试投入、测试范围和用例设计影响，投入增加时发现量上升属于正常现象。判断质量趋势应结合严重缺陷占比、修复率、回归通过率和遗留缺陷数：如果发现量上升但严重缺陷占比下降、修复率上升、遗留数收窄，说明问题在收敛；如果遗留缺陷持续增加且严重缺陷占比不降，则需要关注发布风险。
分母为零或数据缺失时，指标应该怎么写？
分母为零时不应写成0%，而应标注“无数据”并说明原因，例如该版本没有严重缺陷，严重缺陷占比记为无数据。用例未执行时，通过率只按已执行用例计算，同时用计划执行率说明执行缺口。数据缺失的指标在对照表中标注为“无数据”，并在结论中说明缺口对判断的影响，避免用缺失数据支撑达成结论。
评估过程中如何保证不同轮次的数据可比？
关键是固定口径并留存证据。评估前写明需求范围、版本、时间窗、各指标的分母口径、缺陷状态取值规则和去重规则，形成口径说明文档；评估时保存测试报告快照、缺陷列表导出和覆盖率报告原文。后续轮次沿用同一份口径说明，若确需调整，应在报告中注明调整内容和影响，避免直接与历史数据比较。
