第4章 基于风险分析的用例选取
做回归测试最怕什么？我刚开始带项目时，总觉得把全量用例跑一遍最保险。结果呢？一个版本迭代两周，回归就要跑三天，开发等得急，测试测到吐。后来我明白一个道理——你不可能测尽所有，但可以用风险分析把力气用在刀刃上。
这一章，我们就聊聊怎么用风险矩阵、影响域分析、优先级排序，来圈定那些非测不可的高危区域。说白了，就是花最少的时间，拦住最要命的 Bug。
避坑提醒： 风险分析不是为了减少工作，而是让有限的测试资源去覆盖最可能出问题的地方。千万不要偷懒直接跳过中低风险——我见过因为一个“低概率”事件导致线上 P0 事故的团队。
4.1 风险矩阵：给每个变更打个分
风险矩阵不是什么高深玩意。就是两张表——负面影响和发生概率，各给 1~5 分，乘积就是风险值。我习惯先让开发、测试、产品坐在一起，对着变更项逐一打分。
| 影响程度 | 分值 | 典型场景 |
|---|---|---|
| 极低 | 1 | 文字展示类变更，不影响核心逻辑 |
| 低 | 2 | 非主流程的 UI 调整 |
| 中 | 3 | 次要业务流程修改，有重试兜底 |
| 高 | 4 | 主流程、支付、登录等核心模块 |
| 极高 | 5 | 数据一致性问题、安全漏洞、合规风险 |
概率打分类似：1=几乎不会发生，5=必然发生（比如配置写错、依赖包升级）。
实际案例： 我记得一个项目，数据库连接池参数被改了。影响程度只有 3（非核心接口），但概率打了 5（因为开发随手改的，没 review）。风险值 15 ，直接定为 P1。果然上线后连接池爆满，幸好我们提前加了容量和重试用例，才没出大事。
4.2 影响域分析：别只看代码
上一步打了分，但只算了一小半。真正要命的是影响域——你改了一行代码，可能波及五个服务。
我每次拿到变更清单，会先画一张依赖关系图（手动或用工具）。重点关注：
- 直接调用者：改的接口被谁调了？
- 间接影响：是否影响缓存、消息队列？
- 数据流向：改字段会不会导致下游解析失败？
- 配置依赖：改环境变量后，其他模块是否同步？
你想想看，有一次我只是改了一个验证码的过期时间配置……结果所有需要验证码的流程都跟着变了。当时要是没做影响域分析，就直接放过去了。
曾经踩过的坑： 我在团队里吃过一次亏——改了一个公共工具类（影响域分析时说“只影响 A 模块”），上线后却发现 B 模块的日志格式全乱了。因为那个工具类被 B 模块的日志切面静态引用了。从那以后，我要求每次变更必须列出静态依赖扫描结果，不能只凭记忆。
4.3 优先级排序：P1 一定要测，P3 可以商量
结合风险值和影响域，我把用例分成三级：
| 优先级 | 门槛 | 回归策略 |
|---|---|---|
| P1 | 风险值≥12 或 影响域涉及核心模块 | 全部回归用例 + 额外新增探索性测试 |
| P2 | 风险值 6~11，且影响域可控 | 抽关键路径 + 冒烟测试 |
| P3 | 风险值≤5，影响域孤立 | 仅执行变更点对应的最小冒烟用例 |
我的习惯： 排序后我会让开发自测 P1 用例，测试人员验证 P2，而 P3 往往只做代码审查就能放行。这样版本周期能压到 2 天以内。
4.4 高风险区域的回归覆盖策略
高风险（P1）区域，我们要做到三个“全”：
- 全链路覆盖：从入口到出口，调用链上每个节点都测。
- 全数据变体：正常值、边界值、异常值、空值都跑一遍。
- 全并发场景：多线程同时操作热点数据，检查死锁或数据不一致。
举个实际例子——支付模块改了一个优惠券叠加逻辑。风险值 16（高影响+高概率），影响域涉及订单、库存、优惠券三个服务。我们当时做了：
- 正向：单张券、多张券、满减券、折扣券叠加
- 逆向：券过期、库存不足、支付超时、退款后券回退
- 并发：同时下单抢券、同时取消订单
- 数据一致性：订单金额和券核销记录对账
你猜怎么着？上线前真的发现了一个并发下券被重复使用的 Bug。要是只跑几个正向用例，漏了。
一句话总结： 风险分析不是终点，而是用例设计的起点。把高风险区域喂给自动化回归集，让机器替你盯着；中风险用人工抽测兜底；低风险直接信任代码审查。