CI/CD 概念与回归测试概述
我们做自动化测试的同学都知道，CI/CD 流水线现在已经成了研发团队的标配。说白了，就是让代码从提交到上线这条路上跑得更顺、更稳。我个人习惯把 CI/CD 理解成“代码的传送带”——你只管写好代码，剩下的编译、检查、测试、部署，交给流水线去处理。
CI/CD 流水线基本概念
持续集成（CI），核心是“频繁合并、自动验证”。每次代码提交，流水线自动拉代码、编译、跑单元测试，尽早发现集成问题。持续交付（CD）呢，是让通过验证的代码随时可以部署到生产环境，但不一定自动部署。持续部署则是更激进一点——自动部署到生产。
我遇到过不少团队，CI 跑得很顺，但 CD 阶段卡在手工审批上。你想想看，如果每次发版都要人工点一下，那“持续交付”就名存实亡了。我的建议是：先把 CI 跑稳，再逐步推进 CD 自动化。
核心流程：
- 代码提交（git push）触发 Webhook
- 流水线自动拉取最新代码
- 执行编译/构建
- 运行单元测试、代码检查
- 打包制品（如 Docker 镜像）
- 部署到测试环境/预发环境
- 运行集成测试、回归测试
- 人工审批（可选）后发布生产
回归测试定义与价值
回归测试，说白了就是：改了代码之后，把以前能跑过的测试再跑一遍，确保新改动没有破坏旧功能。为什么这件事重要？我以前在某个项目里，开发同学改了一行配置，结果导致支付模块全部超时。那行代码本身没问题，但它影响了调用链上另一个服务。如果回归测试没覆盖到，线上就会出大问题。
回归测试的价值，我总结有三点：
| 价值维度 | 说明 |
|---|---|
| 降低风险 | 及时发现修改带来的副作用 |
| 提升信心 | 发布前知道所有已有功能正常 |
| 减少人工 | 自动化回归替代重复手工测试 |
但是回归测试有个痛点：用例太多，跑起来慢。全量回归跑一次可能要几个小时，甚至十几个小时。所以不能每次提交都跑全量，得有策略地选择触发。
自动化触发回归用例的场景
为什么要自动化触发？原因很简单：人做不到及时响应。你不可能每次代码合并都手动跑回归，那太慢了。以下是几个常见的自动化触发场景：
- 代码合入目标分支（比如合并到 master/release）——这是最常见的触发点。我记得在早期项目里，团队把回归测试放在 merge request 通过后自动执行，有问题立刻回滚。
- 特定文件变更——比如只修改了数据库脚本或 API 定义文件，就触发相关回归用例，而不是跑整个套件。
- 定时触发——有些回归用例跑得慢，不适合每次代码提交都跑。可以每天凌晨跑一次全量回归，白天只跑增量。
- 手动触发带参数——测试人员可以按版本号、环境标签手动启动回归流水线，这在发版前很有用。
- 依赖变更触发——比如第三方库升级、配置文件改动，自动触发受影响模块的回归。
避坑指南：我曾经犯过一个错：把所有回归用例都挂到每次 commits 上。结果团队人一多，流水线排队严重，开发等结果等一上午。后来我改成“合并时触发全量，提交时仅触发受影响模块”，效率立刻提升。
触发策略的选择，可以用一张图来梳理：
容易踩的坑：把回归测试和冒烟测试混为一谈。冒烟测试是验证核心功能是否可用，通常跑得很快；回归测试是全量覆盖，耗时很长。在CI流水线上，冒烟测试应该放在每次提交跑，回归测试则按触发策略跑。我见过有团队把几百个回归用例挂在每次提交上，结果流水线经常超时失败，最后大家都不敢提交代码了。
总结一下：CI/CD 流水线是回归自动化的基础，回归测试的价值在于保护已有功能，而自动化触发则是让这两者高效协同的关键。你想想看，如果每次代码变更都能自动选出最需要跑的回归用例，并且跑完结果直接通知到人，那测试效率至少翻倍。后面的章节，我会具体讲如何设计触发规则、如何实现分支过滤、如何与测试用例管理平台对接。这些都是我在多个项目中踩过坑、改过版之后沉淀下来的经验。