测试质量评估的依据可以分成三层：先明确评估目标与范围，确定评的是哪个版本、哪轮测试、哪类质量属性；再固定指标口径，写清每项指标的分子、分母、时间窗和单位；最后准备可核验的证据，包括用例执行记录、缺陷单及状态流转、需求与变更记录、环境与构建信息。三层齐备后按统一口径计算，并结合样本量与数据完整性解释结果。本文范围限于当前测试或版本的结论，组织级质量趋势和发布审批门禁不展开。
要点总览（TL;DR）
- 测试质量评估的依据分三层：评估目标与范围、指标口径、可核验证据；先定对象再选指标，最后落到取数位置。
- 常用指标分过程类（执行率、通过率、缺陷发现趋势）、结果类（缺陷密度、遗留缺陷等级分布、缺陷逃逸率）和覆盖类（需求覆盖率、风险项覆盖），指标要与判断问题一一对应。
- 每项指标要写清分子、分母、单位、时间窗和缺失值处理；分母为零标注“不适用”，样本过小同时给出绝对数量。
- 证据来自用例执行记录、缺陷单及状态流转、需求与变更记录、构建版本和环境配置，缺失时用降级表达说明证据边界。
- 指标反映当前测试与版本状态，结论要附对象、时间窗、口径和未覆盖范围，单个指标不直接等于产品质量。
评估目标：这次测试质量评估要回答什么
测试质量评估的第一步是确定评估对象和判断问题。对象可以是一个版本、一个迭代、一轮系统测试，也可以是某类质量属性，例如功能正确性、回归稳定性或高风险模块的验证充分性。对象不同，取数范围和指标选择都会变化。
评估目标说明需要写成一份简短记录，至少包含四项内容：评估对象、统计时间窗、要回答的判断问题、范围边界。判断问题应当具体到可以回答“是或否、达到或未达到、风险收敛或仍需观察”。例如“本轮回归测试是否达到完成标准”比“测试质量好不好”更容易落到证据上。
范围边界同样要写明。本文讨论的是当前测试或版本的质量结论，组织级质量趋势、跨季度度量对比、发布审批与质量门禁规则属于另外的管理动作，不在本次评估目标内。把边界写清楚，可以避免评估过程中不断加入新指标，导致口径反复变化。
一份可用的评估目标说明可以按以下结构填写：
- 评估对象：版本号或迭代名称、测试轮次、涉及模块；
- 时间窗：取数起止日期，按缺陷创建时间、关闭时间还是测试执行时间统计；
- 判断问题：本轮测试完成标准是否达到、遗留风险是否收敛；
- 范围边界：不纳入组织级趋势、不替代发布审批结论；
- 结论使用人：测试负责人、研发负责人或项目组，明确结论交付给谁。
指标与范围：测试质量评估用哪些指标
指标选择应围绕评估目标，而不是把所有能统计的数字都放进报告。测试质量评估常用的指标可以分为过程类、结果类和覆盖类三组。过程类反映测试活动执行得是否充分，结果类反映缺陷与遗留风险的状态，覆盖类说明测试范围是否触及关键需求与风险项。
| 指标 | 回答的问题 | 适用评估对象 |
|---|---|---|
| 用例执行率 | 计划内的用例有多少已经执行 | 单轮测试、版本测试 |
| 用例通过率 | 已执行用例中通过的比例如何 | 单轮测试、回归测试 |
| 缺陷发现趋势 | 测试推进过程中新增缺陷是否收敛 | 迭代、测试轮次 |
| 缺陷密度 | 单位规模或单位功能点上的缺陷数量 | 版本、模块 |
| 遗留缺陷等级分布 | 未关闭缺陷集中在哪些严重等级 | 版本发布前、测试收尾 |
| 缺陷逃逸率 | 上线后发现的缺陷占测试期与上线后缺陷总和的比例 | 版本、发布周期 |
| 需求覆盖率 | 需求中有多少已被测试用例覆盖 | 迭代、版本 |
| 风险项覆盖情况 | 已识别的风险项是否都有对应验证 | 高风险模块、专项测试 |
指标与评估目标要一一对应。判断“本轮测试是否完成”，重点看用例执行率、通过率和遗留缺陷等级分布；判断“风险是否收敛”，重点看缺陷发现趋势、高风险模块的缺陷关闭情况和风险项覆盖；判断“测试范围是否充分”，重点看需求覆盖率和风险项覆盖。缺陷逃逸率需要上线后数据才能计算，适合在版本发布后回顾，不适合在测试收尾当天作为完成判断依据。
指标数量控制在能支撑判断问题的范围内。每增加一个指标，就增加一份取数和核对成本，也增加口径解释的分歧。评估目标说明中列出的判断问题，应当能在指标清单中找到对应项；找不到对应指标的判断问题，要么补充指标，要么从本次评估目标中移除。
数据口径：每个指标的分子、分母与时间窗
指标只有写成可复算的口径定义，才能在不同人之间得到一致结果。口径定义至少包含公式、分子、分母、单位、统计时间窗和缺失值处理方式。下表给出常用指标的参考口径，实际使用时需结合团队缺陷状态字典调整。
| 指标 | 公式 | 单位 | 时间窗 | 缺失值处理 |
|---|---|---|---|---|
| 用例执行率 | 已执行用例数 ÷ 计划执行用例数 × 100% | 百分比 | 本轮测试开始至取数日 | 计划用例数为零时标注“不适用”，不记为零 |
| 用例通过率 | 通过用例数 ÷ 已执行用例数 × 100% | 百分比 | 同上 | 已执行数为零时标注“无样本” |
| 缺陷密度 | 有效缺陷数 ÷ 统计基数 | 个/千行代码或个/需求项 | 按缺陷创建时间 | 统计基数缺失时只报缺陷数，不报密度 |
| 遗留缺陷等级分布 | 各严重等级未关闭缺陷数 ÷ 未关闭缺陷总数 × 100% | 百分比或个数 | 取数时点快照 | 状态字典变更时注明版本 |
| 缺陷逃逸率 | 上线后发现的缺陷数 ÷（测试期发现缺陷数 + 上线后发现缺陷数）× 100% | 百分比 | 版本发布后固定观察期 | 观察期未结束时标注“未完整” |
| 需求覆盖率 | 已有用例覆盖的需求数 ÷ 本期需求总数 × 100% | 百分比 | 迭代或版本范围 | 需求拆分口径变化时分别统计 |
缺陷状态取值需要事先约定。常见做法是把“新建、处理中、待验证、重新打开”计入有效缺陷，把“已关闭、已拒绝、重复、无法复现”按团队规则区分处理。拒绝和重复是否计入分母，会直接影响缺陷密度和逃逸率，因此口径定义中要写明，并在报告中保持稳定。状态字典发生调整时，应记录调整日期，跨调整日期的数据不直接合并比较。
分母为零和样本过小是常见问题。计划用例数为零时，执行率没有意义，应标注“不适用”并说明原因；已执行用例只有个位数时，通过率波动很大，结论应写成“样本较小，仅供参考”，同时给出绝对数量。缺陷密度在统计基数缺失时，只报告缺陷个数和分布，不强行计算密度。
跨版本、跨环境的数据不可比时要标注。例如两个版本的需求拆分粒度不同，需求覆盖率不能直接比较；测试环境与生产环境的缺陷发现条件不同，逃逸率的分母范围要单独说明。不可比的数据可以并列展示，但不能合并成一个总数后下结论。
证据来源：哪些记录能支撑评估结论
指标计算完成后，每个数字都要能追溯到具体记录。证据清单的作用是把指标与取数位置、责任人对应起来，保证结论可核验。测试质量评估常用的证据包括以下几类。
| 证据类型 | 取数位置 | 支撑的指标 | 责任人 |
|---|---|---|---|
| 测试用例库与执行记录 | 测试管理工具中的用例、测试计划与执行结果 | 执行率、通过率、需求覆盖率 | 测试负责人 |
| 缺陷单及状态流转历史 | 缺陷管理中的缺陷记录、状态变更日志 | 缺陷密度、遗留缺陷分布、逃逸率 | 测试负责人与研发负责人 |
| 需求与变更记录 | 需求管理中的需求条目、变更单 | 需求覆盖率、范围变化说明 | 产品负责人 |
| 构建版本记录 | 构建或发布记录中的版本号、构建时间 | 评估对象界定、缺陷归属版本 | 研发或构建管理员 |
| 测试环境与配置信息 | 环境说明、配置清单 | 数据可比性说明 | 测试环境负责人 |
证据与指标要能对上。例如用例执行率的分母来自测试计划中的计划用例清单，分子来自执行记录中的执行状态；遗留缺陷分布来自取数时点的缺陷状态快照，需要保留快照时间。缺陷单的状态流转历史尤其重要，它能说明缺陷是否经过验证关闭，也能解释为什么某些缺陷在统计时点仍未关闭。
证据缺失时采用降级表达。缺少执行记录时，不报告执行率，改为说明“执行记录不完整，仅报告已登记结果”；缺少构建版本对应关系时，缺陷密度只按模块报告，不按版本报告；环境配置信息缺失时，在结论中注明“环境差异未核实，数据可比性受限”。降级表达的目的是让读者知道结论的证据边界，而不是用估算数字填补空白。
当用例、缺陷和需求记录分散在不同工具中时，取数成本和口径一致性都会上升。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，这些记录可以在同一流程中留存，便于按版本和迭代回溯执行记录与缺陷状态。具体字段和报表口径仍以团队实际配置为准。
计算与评估步骤：从取数到结论的流程
评估流程可以按五步执行，每一步都有明确的输入、动作和产出，便于复核和交接。
- 确定评估对象与时间窗。输入是版本计划或迭代说明，动作是锁定版本号、测试轮次和取数起止日期，产出是评估目标说明。完成标志是对象、时间窗和判断问题都已书面确认。
- 按口径取数并核对完整性。输入是口径定义表和证据清单，动作是从用例库、缺陷单、需求记录中导出数据，核对记录数、状态取值和版本归属，产出是取数底表。完成标志是每个指标都能在底表中找到分子和分母来源。
- 计算各指标并标注分母与样本量。输入是取数底表，动作是按公式计算，记录分母、样本量和缺失值处理方式，产出是指标计算表。完成标志是任意一个数字都能被第三人按同样口径复算。
- 按预设标准判断并形成结论。输入是指标计算表和评估目标说明，动作是逐项回答判断问题，区分“达到”“未达到”“证据不足”，产出是评估结论。完成标志是每条结论都对应具体指标和证据。
- 结论与证据对应留痕。输入是评估结论和取数底表，动作是建立结论与证据的对应关系，记录口径版本和取数时间，产出是评估记录。完成标志是结论中的每个数字都能追溯到证据清单中的记录。
流程执行中，口径变更要有记录。如果在评估中途调整了缺陷状态取值或时间窗，应保留调整前后的口径版本，并在结论中说明影响范围。评估记录建议与测试报告一并归档，便于后续版本对比时确认口径是否一致。ONES 测试管理支持自动生成测试报告并提供项目缺陷分布统计，报告模板可按业务场景组装，适合把上述指标和证据说明固定在报告结构中；报表内容与指标口径以实际配置的模板和数据源为准。
示例：一个版本的测试质量评估怎么算
以下为演示情景，数字仅用于说明计算过程，不代表任何真实项目或通用达标线。
设定：某版本 V2.3 进行一轮系统测试，时间窗为 3 月 1 日至 3 月 20 日。计划执行用例 400 条，已执行 360 条，其中通过 324 条。测试期发现有效缺陷 48 个，统计基数为 12 个需求项。取数时点未关闭缺陷 9 个，其中严重 1 个、一般 5 个、轻微 3 个。版本上线后 30 天观察期内发现缺陷 6 个。需求总数 15 个，已有用例覆盖 12 个。
计算过程：
- 用例执行率 = 360 ÷ 400 × 100% = 90%；
- 用例通过率 = 324 ÷ 360 × 100% = 90%；
- 缺陷密度 = 48 ÷ 12 = 4 个/需求项；
- 遗留缺陷等级分布：严重 1 ÷ 9 ≈ 11.1%，一般 5 ÷ 9 ≈ 55.6%，轻微 3 ÷ 9 ≈ 33.3%；
- 缺陷逃逸率 = 6 ÷（48 + 6）× 100% ≈ 11.1%；
- 需求覆盖率 = 12 ÷ 15 × 100% = 80%。
结论表述可以写成：本轮系统测试执行率 90%，通过率 90%，未执行用例 40 条，主要集中在低优先级模块；遗留缺陷 9 个，其中严重 1 个，需在发布前确认修复或给出规避方案；缺陷密度为 4 个/需求项，统计基数为 12 个需求项；上线后 30 天缺陷逃逸率约 11.1%，观察期已完整；需求覆盖率 80%，未覆盖的 3 个需求为界面文案调整，已确认不影响核心流程。上述结论基于 3 月 20 日取数快照，缺陷状态按团队当前字典统计。
如果某个模块的计划用例数为零，执行率标注“不适用”，不参与整体执行率的分母合并；如果上线观察期未结束，逃逸率标注“未完整”，只报告已发现缺陷数，不给出百分比结论。示例中的判断标准来自评估目标说明中预设的完成条件，不同团队可以根据版本风险设定自己的条件，本文不提供通用达标线。
解读与限制：指标能说明什么、不能说明什么
指标反映的是当前测试与版本的状态，不直接等于产品质量。执行率和通过率高，说明本轮计划内的用例执行充分、已执行部分结果稳定，但不能证明未覆盖的需求和场景没有缺陷；缺陷密度低，可能是质量好，也可能是测试深度不足或统计基数偏大。解读时要回到评估目标和证据范围，说明指标支持哪条结论、不支持哪条结论。
样本量和分母影响结论稳定性。用例通过率在已执行 360 条时有一定参考价值，在已执行 8 条时波动很大，应同时给出绝对数量和“样本较小”的说明。缺陷密度依赖统计基数的口径，按需求项统计和按代码规模统计的结果不能直接比较。遗留缺陷分布是取数时点的快照，取数后缺陷状态继续变化，报告应注明快照时间。
数据不完整或口径变更时，可比性受限。跨版本对比前要确认需求拆分粒度、缺陷状态字典和统计时间窗是否一致；不一致时并列展示并标注差异，不合并计算。测试环境与生产环境的差异也会影响逃逸率，观察期长度不同时，逃逸率不能直接比较。
结论表达应附条件和证据范围。推荐写法是“在什么对象、什么时间窗、什么口径下，哪个指标是多少，支持什么判断，还有什么未覆盖”。避免把单个指标写成整体质量结论，也避免用指标直接推断团队绩效。评估记录与测试报告一起归档，保留取数底表和口径版本，后续复盘时才能确认结论是在什么条件下得出的。
常见问题
评估中途发现缺陷状态字典需要调整，之前算好的指标怎么处理？
先保留调整前后的口径版本，记录调整日期和影响范围，再决定是否重算。如果调整只影响少数缺陷，可以按新口径重算并在结论中说明差异；如果影响面较大，建议把调整前后的数据分段展示，不合并成一个总数。跨调整日期的缺陷密度、逃逸率不宜直接比较，报告中注明“口径变更，数据分段统计”即可。
测试期数据完整，但上线后观察期还没结束，缺陷逃逸率能不能先给一个数？
可以报告已发现的缺陷数量，百分比结论建议标注“未完整”。逃逸率的分母包含上线后发现缺陷数，观察期未结束时这个分母还会增长，提前给出的百分比会随观察期推进而变化。更稳妥的写法是“观察期截至某日，已发现上线后缺陷 N 个，逃逸率待观察期结束后计算”，并写清观察期长度和起算时间。
用例执行记录分散在多个工具里，取数时怎么保证口径一致？
先固定一份取数底表模板，列出用例编号、所属计划、执行状态、执行时间和版本号，再从各来源按同一字段映射导入。核对时重点看三处：计划用例总数是否与测试计划一致、执行状态取值是否统一、版本归属是否按构建记录对齐。记录分散会抬高核对成本，ONES 测试管理把用例、测试计划与迭代关联，未通过用例可直接创建缺陷任务，执行记录和缺陷状态在同一流程中留存，便于按版本回溯；具体字段以团队实际配置为准。
遗留缺陷等级分布按个数报还是按百分比报？
两者都报更便于判断。个数说明绝对量，百分比说明结构占比，尤其在未关闭缺陷总数较少时，百分比容易被放大。例如未关闭缺陷只有 3 个，其中一个严重缺陷就占 33.3%，单看比例容易误判风险规模。建议写成“未关闭缺陷 9 个，其中严重 1 个（占 11.1%）”，并注明取数快照时间。
评估结论需要交付给研发负责人，报告里要保留哪些留痕？
至少保留四类留痕：评估目标说明（对象、时间窗、判断问题）、口径定义表（公式、分母、缺失值处理）、取数底表与快照时间、结论与证据的对应关系。口径中途变更的，附上变更记录。ONES 测试管理支持自动生成测试报告并提供项目缺陷分布统计，报告模板可按业务场景组装，适合把指标和证据说明固定在报告结构中；报表内容与口径以实际配置的模板和数据源为准。
