回归测试策略
回归测试，说白了就是跑一遍历史用例，确保新改动没弄坏旧功能。
我见过最多的线上事故，都源于漏跑了回归测试。有一次证书续签接口改了响应字段格式，负责人觉得「就改个字段名，不影响」，结果下游三个服务解析失败，线上告警响了一整夜。
嗯，从那以后我立了个规矩——改任何代码，都必须过回归测试。
为什么必须把回归测试做深做细？
你想想看，CI/CD 流水线跑得再快，如果回归测试覆盖不全，那也只是在快速犯错。回归测试的核心价值就一句话：守住旧功能的底线。
我个人习惯：在每次提交PR之前，先问自己三个问题——这改动会影响哪些证书类型？会影响哪些接口的返回结构？会不会导致缓存数据不一致？问清楚了，再圈定回归范围。
回归测试不是越多越好，也不是越少越好，而是精准。范围选大了，流水线跑半小时，开发等得心焦；范围选小了，漏了关键用例，上线就爆雷。
回归测试选择范围的思考框架
我通常把选择策略分成三类，你可以根据项目节奏灵活切换：
| 策略 | 描述 | 适用场景 | 风险等级 |
|---|---|---|---|
| 全量回归 | 所有证书接口用例全跑 | 大版本发布、证书类型新增 | 低（时间长） |
| 影响分析回归 | 只跑变更波及的接口和上下游关联用例 | 日常迭代、bug修复 | 中（需分析工具） |
| 风险驱动回归 | 按历史缺陷+变更频率排序，优先跑高风险用例 | 快速上线、hotfix | 高（速度快） |
我建议你从「影响分析回归」起步，逐步积累变更与用例的映射关系。等映射关系稳定了，再引入自动化分析工具，省下大量人工排查时间。
我曾经踩过的一个坑：全量回归虽然安全，但会把流水线时长拖到45分钟以上。开发一天提8次代码，每次等45分钟，最后大家偷偷跳过回归测试。所以——全量回归是保险，不是常态。
用例优先级的划分逻辑
回归用例不能不加区分。我用四层优先级来管理：
-
P0（阻塞级）——如果通不过，版本不能上线。
例如：证书申请、证书续签、证书吊销这三个核心接口，任何格式错误、状态码异常、数据持久化失败，都属于 P0。 -
P1（重要级）——影响大部分用户，但可临时降级。
例如：证书下载、证书验证、证书到期提醒。这些接口出问题，用户感知明显，但不会直接导致平台瘫痪。 -
P2（边界级）——只在特殊条件下出问题。
例如：证书最大有效期测试、超大证书链解析、并发续签压力。这些用例跑起来慢，我通常按比例抽检。 -
P3（低优级）——属于兼容性验证。
例如：老版本证书格式解析、历史签发记录查询。这类用例变化极少，可以在每周夜间回归中覆盖。
这里有一个经验数字：我团队里回归测试的P0+P1用例占总用例的35%左右，但它们覆盖了95%以上的用户请求场景。所以优先级划分的核心思路——用最少的用例，锁定最大的风险。
自动化回归的价值权衡
为什么要搞自动化回归？我直接给你说数字：
- 快的优势：手工回归证书续签接口，一个场景平均5分钟，20个场景就是100分钟。自动化？2分钟跑完。
- 覆盖率的保证：人总会累的。手工跑回归到第15个用例时，注意力就下降了。机器不会。
- 可信的回归结论：断言写的明确，通过就是通过，失败就是失败。不存在「好像返回了200，应该没问题吧」这种模糊判断。
但我也得泼点冷水——自动化回归不是银弹。你在项目初期就急着写自动化代码，大概率会陷入「频繁改脚本」的泥潭。我见过一个团队，三个月里用例改了7版，自动化代码比业务代码还多，最后放弃了。
我建议的节奏：先手工跑出稳定的回归用例集，把接口响应结构固化下来。等接口格式稳定了，再自动化。别上来就自动化，否则自动化代码会成为你的包袱。
说白了，自动化回归的核心价值不是替代人工，而是替代人工的低效重复。你把精力花在分析用例优先级、优化回归范围上，机器负责傻瓜式执行——这才是正解。
这张图是我日常做回归测试决策时的心智模型。从左到右，每一步都是在做减法——先分析影响，再选范围，再排优先级，最后自动化执行，落到质量门禁上。你会发现，真正花时间的不是执行，而是前期的分析和策略选择。