今日收到一位测试经理的问题如下：

晓南老师，最近做测试遇到了2个困惑点。

• 困惑一，当前测试都是底座替换类，如数据库、中间件的替换，开发分析影响范围就是全量，但是其实全量是浪费的，如何精准是一个问题。

• 第二个困惑，在这种底座替换测试中，是没有业务类需求的，我们对于业务功能的测试如果积累的资产少自动化也少，对比测试也无法覆盖全部场景，有没有什么好办法～

我觉得这俩问题很好，覆盖了回归测试中的一些典型痛点。为了更好的回答问题，我写了这篇文章，刘冉老师对此文的内容产出亦有贡献。

理想方案：结合代码影响范围和业务优先级的全量测试

都是底座替换类，确实影响范围是全量的，但是全量并不代表全都重要，可以结合底座和业务的耦合程度，根据集成点来分析功能回归的优先级，针对不同优先级来进行不同程度的分层回归。

理想情况是结合代码影响范围和业务优先级来综合评估。

代码影响范围：由开发出具代码变更多功能模块的影响分析矩阵（Impact Analysis Matrix），如果说所有代码全都影响，优先级一样，这就是无效的分析，需要给出有效的分析结果。可以通过 code diff 或 code dependency 的工具来自动生成影响范围结果。

业务优先级：由业务/产品和测试一起出具业务场景的优先级列表，针对不同优先级来分层测试。

如果很清楚集成点，可以根据集成点的优先级来定回归策略。

如果很难分析清楚集成点，就可以参考日常回归优先级策略，比如核心主流程的 happy path, sad path, exception path 全回归，其他选择性回归。

另外注意日常积累测试用例，如果不是自动化的，至少也需要有基于业务优先级的用例积累。

退一步讲，就算没有底层的变化，我们也应该有一些常规的冒烟测试、健壮性测试、业务关键路径测试，这与底层变不变是解耦的。可以在日常多积累这些测试点，重复执行多了也比较容易自动化。

现实方案：由测试和研发共同出具可行的回归范围

有经验的同学应该发现理想方案的问题了。

首先，研发很难给出全量的代码变更影响范围。这个范围会受到各种因素的影响，如技术架构实现、技术栈选型、代码分析工具等等，有的技术栈支持给出部分影响范围，有的则不支持。

结论是哪怕在各种因素都积极的情况下，研发也只能给出部分的代码变更影响范围。测试同学要充分理解这一现实约束。

好了，我们可以接受研发给出部分代码变更影响范围，而不是全量影响范围。那么业务优先级就能在短期内由业务/产品和测试快速确定下来吗？

但凡有跨角色协作经验的同学都知道大概率定不了，因为业务优先级的确定周期会无限延长，尤其在没有业务积累的场景下，这几乎是不可能完成的任务。

所以业务优先级这一部分也会打折，比较现实可行的方法是，由资深的测试同学出具基于业务优先级的回归用例集合，应包含核心业务场景的全量回归和其他典型的回归测试集合。

关于采用什么测试方法和工具，契约测试、接口测试、UI自动化，这些都是在确定方案之后的实现途径，在此不做过多展开了。

关于缺乏业务用例的积累，除了一点一滴积累以外，没有什么捷径。如果之前毫无积累可供参考，就从现在马上开始积累。

额外想说的

偿还技术债：这类问题产生的背后原因往往是架构设计问题，如系统前后端不分离的大单体架构；同时由于架构缺陷，很难低成本自动化，以至于持续缺乏自动化测试。这时由于痛点明显，是投资技术债管理的合适时机。

可尝试引入AI：AI在IT领域的一个应用场景是遗留代码重构，成本和企业内部条件允许的话，可以尝试引用AI做重构后的影响范围分析，因为以往由于人力受限产生的约束，对于AI来说可能并不存在。只是我们对效果不要报以过高期望就好。

多方合作共赢：这个例子充分体现了团队全员对质量负责的理念，一旦多方开始责任共担，那么彼此的风险都会降低。

“其实团队全员对质量负责的理论基础是博弈论。” ——刘冉