📚 课程目录第2章回归测试基础

回归测试基础：原则、触发条件与测试类型辨析

回归测试这件事，说白了就是「改了老代码，别把老功能搞坏了」。我做了这么多年UI定制，见过太多因为回归不充分导致线上翻车的案例。有一次，团队只改了按钮的圆角参数，结果把整个表单的提交逻辑带崩了——因为那个按钮绑定的点击事件被不小心覆盖了。嗯，从那以后我对回归测试再也不敢马虎。

回归测试不是盲目地全量跑一遍用例，它有自己的章法。我习惯把回归测试的原则归纳为四个，你可以在实际项目中对照看看。

完整性原则：回归测试必须覆盖所有受影响的功能区域，不只是改了什么测什么。我在项目中遇到过，开发只改了一个配置文件，结果影响到了三个页面的布局渲染。如果只测改的那个模块，其他两个页面就漏了。
自动化优先原则：能自动化的千万别手动。UI回归测试重复执行频率极高，手动跑一遍几百个用例，两天就过去了。我建议核心回归用例的自动化覆盖率至少达到80%以上。
风险驱动原则：资源有限的时候，优先测风险最高的模块。比如UI定制中，主题引擎、布局系统、事件绑定这几个核心模块，优先级永远排在最前面。
可追溯原则：每条回归用例都必须能追溯到具体的需求变更或缺陷修复。我曾经因为用例和需求失联，导致一个已知缺陷在下一个版本中再次出现——也就是所谓的「回归复发」，非常尴尬。

核心要点：回归测试不是「全量重测」的代名词，而是「基于变更影响面的精准验证」。完整性是底线，自动化是效率，风险驱动是策略，可追溯是质量保障。

什么时候该触发回归测试？很多团队一开始是「每次构建都全量回归」，后来发现跑一次要几个小时，根本跑不过来。我个人习惯按下面这几个条件来判断：

代码提交或合并：只要有代码变更进入主分支，就应该触发至少一轮增量回归。尤其是UI定制项目里，CSS和布局文件的微小改动都可能引发连锁反应。
缺陷修复后：修复了一个Bug，不光要验证Bug本身被修好了，还要验证修复过程有没有引入新的问题。我曾经遇到过，修复一个登录框的样式问题，结果把密码输入框的占位符颜色改没了。
环境或配置变更：UI定制依赖大量的配置文件（主题色、字体、间距、动画参数等）。配置文件的变更往往不被重视，但影响面可能非常大。
版本发布前：每次发版前必须执行一次完整的回归测试，这是最后的防线。我之前在一个项目中跳过了这一步，结果发布后用户反馈首页加载白屏——因为一个JSON配置的逗号写错了。
依赖库或框架升级：UI定制通常依赖第三方UI库或自定义组件库。依赖库的版本升级，哪怕是小版本，也可能导致样式或行为不一致。

避坑指南：我曾经把一个「全量回归」的触发条件设得太宽松，结果CI每天跑6小时，开发人员排队等构建。后来改成「增量回归 + 每日全量」的策略，排队问题才解决。触发条件一定要结合团队实际节奏来定，不要一刀切。

这三个概念经常被放在一起比较，但它们的定位完全不同。我用一个表格来对比，这样更直观。

你看，冒烟测试是「能不能用」的快速检查，回归测试是「改了没改坏」的全面验证，验收测试是「做得对不对」的最终把关。三者在测试体系中各司其职，缺一不可。我习惯把冒烟测试比作安检门，回归测试比作全身体检，验收测试比作出院复查——层级和目的都不一样。

个人建议：在UI定制项目中，我建议把冒烟测试作为CI流水线的第一道关卡。冒烟不过，直接打回，不浪费回归测试的资源。验收测试则建议在准生产环境中执行，让业务人员参与确认。

看这张图就清楚了。冒烟测试、回归测试、验收测试是三条并行的防线，各管一摊。回归测试作为中间层，向下承接冒烟测试的快速验证结果，向上为验收测试提供质量依据。而触发条件和核心原则，就是回归测试这座桥梁的两根支柱——没有它们，回归测试要么跑偏，要么跑不动。