判断测试左移是否让缺陷发现真正提前，要看缺陷被发现时所处的阶段是否整体前移，缺陷总数或测试用例数的变化不能作为依据。做法是固定同一产品或同一类需求，按需求评审、设计、编码自测、提测、系统测试、上线后等阶段统计缺陷分布，对比推行前后的同口径数据。只有阶段分布持续前移，并且上线后逃逸缺陷同步下降，才能说明缺陷发现真正提前。
要点总览（TL;DR）
- 判断缺陷发现是否提前，看缺陷被发现时所处阶段是否整体前移，缺陷总数和测试用例数的变化不能作为依据。
- 固定同一产品或同一类需求，按需求评审、设计、编码自测、提测、系统测试、上线后统计缺陷分布，对比推行前后同口径数据。
- 核心指标是缺陷阶段分布、缺陷发现前置率和缺陷逃逸率；前置率上升且逃逸率同步下降，才支持真正提前的结论。
- 阶段定义、分母规则、缺陷等级过滤和缺失值处理要在评估前统一，否则前后数据不可比。
- 前置率上升而逃逸率不降、阶段字段被重新归类、测试投入或需求规模变化，都不能直接当作提前的证据。
评估目标：先定义“提前”指什么
“提前”在评估中有一个可操作的含义：同一类缺陷，被发现时所处的研发阶段比推行前更靠前。一个支付校验规则遗漏，如果在需求评审时被提出，属于提前发现；如果到系统测试才暴露，则没有提前。缺陷总数增加可能来自需求规模扩大、测试覆盖加严或缺陷记录习惯变化，与发现位置无关，不能作为提前的证据。
评估对象应固定为同一产品或同一类需求。跨产品比较会混入业务复杂度、团队经验和发布节奏的差异，难以归因到测试左移。对比基线通常取推行前若干个完整迭代或发布周期，观察期取推行稳定后的若干周期，两端的需求类型、缺陷等级范围保持一致。
评估范围需要事先写明不纳入的内容：自动化脚本编写质量、安全攻击手法与源码分析、单份需求文档的评审质量，这些属于测试左移的具体执行手段，本评估只回答“缺陷发现位置是否前移”。评估目标说明建议包含三部分：观察对象（哪个产品、哪类需求）、对比基线（哪几个迭代或版本）、不纳入项。写清楚这三项，后续取数和结论才有共同前提。
指标与范围：用哪几个维度看缺陷发现位置
单一指标容易给出片面结论，建议用一组指标从不同角度描述缺陷发现位置。每个指标回答一个具体问题，组合起来才能支撑判断。
| 指标 | 定义 | 回答的问题 | 观察范围 |
|---|---|---|---|
| 缺陷阶段分布 | 各阶段发现的缺陷数与占全部缺陷的比例 | 缺陷主要在哪一阶段被拦住，分布是否整体前移 | 按迭代或版本分组，按缺陷等级分层 |
| 缺陷发现前置率 | 提测前发现的缺陷数 ÷ 同期全部有效缺陷数 | 有多大比例的缺陷在进入系统测试前被发现 | 同一产品、同一类需求，推行前后同口径 |
| 缺陷逃逸率 | 上线后发现的缺陷数 ÷ 同期全部有效缺陷数 | 有多少缺陷漏到生产环境 | 上线后固定观察窗口，如发布后30天 |
| 缺陷存活时长 | 缺陷从引入到被发现的间隔 | 缺陷在系统里潜伏了多久 | 能追溯到引入阶段的缺陷样本 |
缺陷阶段分布是主指标，直接反映发现位置；前置率把“提测前”压缩成一个比例，便于跨周期比较；逃逸率用于校验前移是否真实有效，防止缺陷只是被提前记录、关键问题仍漏到线上；缺陷存活时长补充时间维度，适合对引入阶段有较可靠记录的团队。观察范围要固定时间窗、需求样本和缺陷等级过滤规则，例如只统计严重及以上缺陷，或统计全部有效缺陷但单独列出严重缺陷。范围一旦确定，推行前后不得随意调整。
数据口径：阶段划分与分母怎么定
前后可比的前提是阶段定义和分母规则一致。阶段划分建议与研发流程节点对齐，并明确每个阶段的进入和退出条件，例如“提测”指开发完成自测并提交测试的时点，“系统测试”指测试团队执行系统级用例的区间。缺陷的阶段字段应取自缺陷单上的固定字段，由发现人在提交时选择，避免事后按结果回填。
分母选择直接影响比例的含义，常见有三种：全部缺陷、有效缺陷、按需求计。评估缺陷发现位置时，建议以有效缺陷为分母，即剔除重复提交、无法复现、需求变更导致作废的记录。按需求计的分母适合回答“每个需求平均在早期发现多少缺陷”，可与按缺陷计的口径并列展示，但不宜混用在同一张对比表里。
缺陷等级过滤规则要写进口径说明。若只统计严重及以上缺陷，样本量会明显减少，需要相应拉长观察周期。缺失值和异常数据的处理也要事先约定：阶段字段为空的缺陷单独列出，不计入任何阶段占比；阶段被回填修改的记录保留修改痕迹，评估时以发现时点填写的值为准；同一问题多次提交的重复缺陷合并为一条，保留最早发现阶段。推行前后还要检查样本量与需求类型的可比性，若观察期需求以小型迭代为主、基线期以大型版本为主，需要按需求类型分层后再比较。
这些阶段字段、需求关联和统计报表需要有承载的地方。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，缺陷可关联至迭代，并提供项目缺陷分布统计与质量统计报表，便于按迭代归集缺陷阶段数据；报表的具体维度和字段口径以实际配置为准。
计算与评估步骤：从取数到判断的流程
计算按固定顺序进行，先描述分布，再算比例，最后做判断。
- 按阶段统计缺陷数。对每个观察周期，统计需求评审、设计、编码自测、提测、系统测试、上线后各阶段的缺陷数，计算阶段占比：某阶段缺陷数 ÷ 该周期全部有效缺陷数 × 100%。
- 计算缺陷发现前置率。前置率 = 提测前发现的缺陷数 ÷ 同期全部有效缺陷数 × 100%。提测前包括需求评审、设计、编码自测三个阶段，分子分母均使用有效缺陷。
- 计算缺陷逃逸率。逃逸率 = 上线后发现的缺陷数 ÷ 同期全部有效缺陷数 × 100%。上线后观察窗口需固定，例如发布后30天内提交的缺陷。
- 按迭代或需求分组对比。把推行前基线和推行后观察期的上述指标并列，按需求类型分层展示，避免规模差异掩盖真实变化。
- 按顺序判断。先看阶段分布是否整体前移，即提测前各阶段占比上升、系统测试和上线后占比下降；再看逃逸率是否同步下降。两者同时成立，才支持“缺陷发现真正提前”的结论。
分母为零或样本过少时，比例没有意义。某周期提测前缺陷数为零，前置率为零并不代表退步，应标注样本不足并延长观察周期或合并相邻迭代。有效缺陷总数低于约定阈值（例如30条）的周期，建议只展示绝对数，不计算比例，也不纳入趋势判断。
例子：一次推行前后的对比演算
以下为演示情景，数字仅用于说明计算过程。某产品推行测试左移前后各取3个迭代，有效缺陷总数分别为200条和220条，各阶段缺陷数如下。
| 阶段 | 推行前缺陷数 | 推行前占比 | 推行后缺陷数 | 推行后占比 |
|---|---|---|---|---|
| 需求评审 | 10 | 5% | 26 | 11.8% |
| 设计 | 8 | 4% | 18 | 8.2% |
| 编码自测 | 22 | 11% | 40 | 18.2% |
| 提测 | 30 | 15% | 36 | 16.4% |
| 系统测试 | 90 | 45% | 72 | 32.7% |
| 上线后 | 40 | 20% | 28 | 12.7% |
按公式计算：推行前前置率 = (10+8+22) ÷ 200 = 20%，逃逸率 = 40 ÷ 200 = 20%；推行后前置率 = (26+18+40) ÷ 220 ≈ 38.2%，逃逸率 = 28 ÷ 220 ≈ 12.7%。阶段分布上，提测前三个阶段占比从20%升至约38.2%，系统测试占比从45%降至32.7%，上线后占比从20%降至12.7%，分布整体前移，逃逸率同步下降，这组数据支持缺陷发现提前的结论。
对照另一种结果：若推行后提测前缺陷数从40条增至80条，但系统测试和上线后缺陷数基本不变，前置率上升而逃逸率没有下降，说明缺陷更多被提前记录，关键问题仍漏到后期，不能判定为真正提前。还有一种情况是阶段字段被重新归类，例如把部分系统测试缺陷改记为提测阶段，占比同样会前移，但逃逸率不变，需要核对缺陷单的修改记录才能识别。
解读与限制：哪些结果不能当作提前的证据
缺陷总数变化不能说明发现位置。总数上升可能来自需求规模扩大或记录更细，总数下降可能来自漏报，两者都与阶段前移无关。阶段占比前移也需要排除字段重新归类的影响，评估前抽查一批缺陷单，核对阶段字段的填写时点和修改记录，是成本较低的校验方式。
测试投入增加、需求规模变化、团队人员调整都会影响指标。测试人力增加本身就会让更多缺陷被发现，若观察期同时扩大了测试投入，结论应表述为“在测试投入增加的条件下，缺陷发现位置前移”，不宜单独归因于测试左移。需求规模变化可通过按需求计的分母做辅助校验，观察单需求缺陷阶段分布是否同样前移。
单指标不能代表整体成效。前置率上升而逃逸率不降，说明早期发现的多是低影响问题；逃逸率下降而阶段分布未变，可能来自上线后监控和灰度发布的作用。结论需要多指标、多周期共同支持，至少覆盖推行前后各3个完整迭代，并观察趋势是否稳定。指标反映的是相关关系，测试左移与缺陷前移之间是否存在因果，还需要结合具体改进动作的执行记录来判断。
常见问题
推行时间不长，观察期只有一两个迭代，能下结论吗？
样本量偏少时，比例波动会很大，单个迭代的前置率上升或下降都可能来自偶然。建议至少覆盖推行前后各3个完整迭代，再观察趋势是否稳定。若有效缺陷总数低于约定阈值（例如30条），只展示绝对数，不计算比例，也不纳入趋势判断，可以合并相邻迭代或延长观察周期后再评估。
缺陷阶段字段填写不规范，历史数据还能用吗？
可以先用，但要先做一次数据清理。阶段字段为空的缺陷单独列出，不计入任何阶段占比；阶段被回填修改的记录保留修改痕迹，评估时以发现时点填写的值为准；同一问题多次提交的重复缺陷合并为一条，保留最早发现阶段。清理后抽查一批缺陷单，核对填写时点和修改记录，确认阶段字段没有系统性偏移，再进入计算。
前置率上升但逃逸率没降，说明测试左移失败了吗？
不能直接判定失败。前置率上升而逃逸率不降，常见原因是早期发现的多是低影响问题，关键缺陷仍漏到后期；也可能是缺陷被更早记录，但评审和自测环节没有真正拦住问题。这时应结合缺陷等级分层看数据，单独统计严重及以上缺陷的阶段分布和逃逸情况，再判断早期发现是否覆盖了关键问题。
团队同时增加了测试人力，结论怎么表述才准确？
测试投入增加本身就会让更多缺陷被发现，与测试左移的效果混在一起。结论应写成“在测试投入增加的条件下，缺陷发现位置前移”，不宜单独归因于测试左移。可以补充按需求计的分母做辅助校验，观察单需求缺陷阶段分布是否同样前移，并结合改进动作的执行记录说明哪些变化来自左移实践。
评估缺陷阶段分布，数据在研发管理工具里怎么归集？
关键是缺陷单上有稳定的阶段字段，并且缺陷能关联到迭代或需求，才能按周期分组统计。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，缺陷可关联至迭代，并提供项目缺陷分布统计与质量统计报表，可用于按迭代归集缺陷阶段数据；报表的具体维度和字段口径以实际配置为准。
