回归测试策略设计：测试用例选择、优先级排序与覆盖率规划

讲回归测试策略设计，说白了就是三个问题：测哪些？先测谁？测多细？

我在项目中遇到过不止一次，开发说「我就改了一行配置」，结果上线后把整个订单流程打崩了。从那以后，我养成了一个习惯——任何改动，哪怕只是改个按钮颜色，都要重新捋一遍回归策略。

今天就聊聊我这些年沉淀下来的一套实操方法。

测试用例选择：挑出真正该回归的

回归测试最忌讳的就是「全量回归」。你想想看，一个系统迭代了三年，用例库早就上万条了。每次改动都跑一遍？没那个时间，也没那个必要。

我的做法是：把用例库分成三个池子。

池子	定义	选择策略
必测池	与本次改动直接相关的用例	通过代码变更分析（diff）+ 调用链追踪
联测池	与改动模块存在接口或数据依赖的用例	基于依赖图谱（依赖矩阵）选取
抽测池	历史高频出错的用例	按严重等级 + 最近三个月故障统计

具体选哪些用例？我个人习惯用三个维度来过滤：

• 业务影响度——改动代码覆盖了哪些业务场景
• 技术风险度——改动的代码本身有多复杂、有多少人维护过
• 历史缺陷率——这块代码在过去半年里出过几次问题

优先级排序：把时间花在刀刃上

用例选出来之后，怎么排执行顺序？我曾经吃过亏：按用例编号顺序跑，结果先把不痛不痒的界面检查跑完了，真正有问题的核心逻辑卡在最后才暴露。

现在我用的是「风险加权优先」策略，说白了就一句话——哪个用例不通过造成的影响最大、风险最高，就先跑哪个。

优先级	定义	适用场景	预估耗时占比
P0（致命级）	核心业务流、主链路、数据安全	任何改动都必须跑	10% ~ 15%
P1（严重级）	次核心功能、接口契约、权限控制	改动影响了关联模块	20% ~ 30%
P2（一般级）	边缘逻辑、UI 布局、辅助功能	仅当改动直接命中时才跑	剩余时间弹性分配

排序的算法其实不复杂，我一般这样计算：

用例优先级分 = 业务严重等级（1~10）
              + 历史缺陷权重（0.5~2.0）
              + 改动的调用链深度（0~5）

最终排序：按总得分从高到低执行

覆盖率规划：不是越高越好，是越准越好

覆盖率这个东西，很多团队会设硬指标——「语句覆盖必须到 85%」「分支覆盖必须到 70%」。说实话，我觉得这种一刀切的做法有点片面。

我个人的经验是用「四色覆盖模型」来规划：

覆盖类型	衡量什么	建议目标值
代码覆盖	哪些代码行被执行了	改动部分 100%，整体 60%+
功能覆盖	每个功能点是否至少被一个用例覆盖	100%（基于功能清单）
场景覆盖	核心业务场景的全链路覆盖	核心链路 ≥ 3 条用例/场景
数据覆盖	不同数据状态下代码的执行路径	边界值 + 异常值 + 空值

嗯，这里要注意：覆盖率是结果，不是目标。你告诉我「覆盖率 90%」，我并不会觉得安全；但如果你告诉我「核心业务链路上每个分支都被测过了」，那我心里就有底了。

风险评估：给策略加个兜底

最后聊一个很多教程会忽略的东西——风险评估矩阵。

每次规划回归测试前，我都会拉上开发、产品和测试三方一起过一遍这个矩阵：

• 这个改动如果出问题，影响面有多大？会影响多少用户？
• 影响持续多长时间？有没有自动恢复能力？
• 我们现有的回归用例，能不能覆盖到这个风险点？

根据这个矩阵，我会动态调整测试用例的选择和优先级。如果某个风险的「影响程度 × 发生概率」得分很高，即使它的代码覆盖率已经达标，我也会额外加两条探索式测试场景——因为自动化脚本有时候抓不住业务上的诡异组合。