回归测试用例选择三把斧

说实话，回归测试最让人头疼的问题就一个：测什么？

项目时间紧，全量回归不现实。随便抽几个用例跑跑，又怕漏掉关键bug。干我们这行的，谁还没经历过这种纠结？

我个人的习惯是，先把回归用例的来源理清楚。一般来说，就三条路：代码变了、需求改了、以前出过事。咱们一条条聊。

基于代码变更的选择

这是最直接的方法。代码改了，影响的模块自然要测。

具体怎么操作？我建议关注两点：

• 变更分析：用git diff或者代码审查工具，搞清楚改的是哪几行、哪个函数、哪个类。
• 影响范围评估：改了一个底层工具函数，所有调用它的地方都可能受影响。

举个例子。之前有个项目，开发只改了一个数据校验的公共方法。结果呢？所有引用这个方法的模块全出了问题。我们在回归时只测了改了代码的模块，其他模块都没碰。上线后，订单模块直接挂了——因为那个校验方法也被它用了。

基于需求变更的选择

需求变了，测试范围也得跟着变。这个道理大家都懂。但怎么变？变多大？

我一般把需求变更分成几类：

你想想看，如果只是改了个按钮颜色，把全量回归跑一遍，那不是浪费时间吗？但如果是改了支付流程的核心逻辑，那就得慎重了。

我个人习惯是，需求变更文档出来后，先拉着开发和产品一起过一遍。搞清楚「为什么要改」和「改了哪些地方」。很多时候，产品经理自己都说不清楚影响范围——这时候就需要我们来补位了。

基于历史缺陷的选择

这个思路其实很简单：以前出过bug的地方，容易再次出bug。

为什么要这么做？因为历史bug往往意味着代码复杂、逻辑边界多、或者开发对这块不熟悉。这些地方就是高风险区域。

我自己的做法是，维护一个「历史缺陷热力图」。每次发版前，先把这张图拉出来看看。哪些模块bug多，哪些模块总是修了又出问题——这些就是重点回归对象。

举个例子。我之前负责一个电商后台的测试。商品管理模块，每次版本都出问题。不是价格计算错了，就是库存同步延迟。后来我把这个模块的历史bug整理出来，发现大部分问题都集中在「价格策略」和「库存扣减」这两个子功能上。之后的回归，我就盯着这两个地方猛测。效果很明显，类似的线上问题基本没再出过。

三种方法的组合策略

说了三种方法，你可能想问：到底用哪种？

我的答案是：全都要。

当然不是简单的叠加。我一般这么组合：

1. 第一步：按代码变更选核心用例——先圈出最直接的影响范围。
2. 第二步：用需求变更补充遗漏——看看代码没动但逻辑变了的地方。
3. 第三步：用历史缺陷兜底——把那些老出问题的模块加进来。

我记得有次迭代，开发改了一个很小的配置项，代码变更分析觉得影响不大。但需求文档里写着这个配置项会影响所有导出功能。历史数据也显示，这个模块以前因为配置问题出过两次线上事故。你看，三种方法一交叉，问题就出来了——压根不是小改动。