回归测试是什么
回归测试验证修改没有破坏既有功能：目的不是发现新需求相关的缺陷，而是确认这次变更没有引出副作用。它的范围弹性很大——从只跑受影响模块，到发布前的全量套件，通常按变更影响分析与风险清单选择子集。软件的任何改动都可能产生回归：代码提交、依赖升级、配置调整、环境迁移都算。选择回归子集的过程本身就是一次风险推演：谁会被这次改动波及、历史缺陷分布在哪些模块、哪些链路的失败代价最高，回答完这三个问题，范围自然浮现。工程上衡量回归体系好坏的核心指标是两件事：漏网副作用有多少、每次验证花多长时间。
基本信息
| 目的 | 确认变更没有引入副作用 |
|---|---|
| 触发时机 | 合并前、发布前、热修复后、依赖或环境变更后 |
| 范围策略 | 变更影响分析、缺陷聚类历史、核心链路清单 |
| 常见形式 | 自动化套件、手工回归清单、分层组合 |
| 关键指标 | 漏检率与执行时长，两者需要同时优化 |
典型使用场景
- 线上缺陷修复合入后：确认修复本身有效且未伤及相邻功能
- 依赖库或框架升级：验证升级引入的行为差异
- 发布前全量验证：按发布窗口选择可承担的范围与时长
- 大型重构之后：以回归集作为行为不变性的证据
- 配置与基础设施变更：连接参数、证书、域名替换后的整体验证
- 第三方组件升级公告发布后：按受影响矩阵决定回归范围
- 大促或重要活动前：对核心交易链路做专项回归
分层回归示意
分层回归示意
# 提交级：只跑受影响范围，秒到分钟级反馈
pytest tests/orders tests/payments -q
# 合并级：影响范围外扩一圈，加冒烟集合
pytest tests/ -m 'not slow' -q
# 发布级：核心链路全量回归，可接受小时级时长
pytest tests/ -m slow -q回归集分层设计
| 层级 | 范围 | 触发频率 | 时长预算 |
|---|---|---|---|
| 提交级 | 受影响模块的单元与集成用例 | 每次提交 | 分钟级 |
| 合并级 | 相关模块加冒烟集合 | 每次合并或每日 | 十分钟级 |
| 发布级 | 全量套件加核心业务链路 | 每次发布 | 小时级 |
回归集需要定期修剪：长期不再失败的用例要么已内建为更快的检查，要么需要更新覆盖点；只增不减的套件会拖垮执行时长。
回归选择的实用起点：git diff 命中的模块加上这些模块的直接调用方，再叠加最近三十天缺陷最集中的模块；范围宁可外扩一圈，也别把风险留给发布之后。
手工回归清单并非落后：对低频、高价值、难以自动化的操作（如财务对账流程），结构化清单加双人复核往往是最经济的方案；关键是清单要带版本记录与执行签字。
快照（snapshot）对比是回归的一种实现：对输出结构做基线留存，变化时人工确认是预期修改还是意外回归。
养成回归复盘习惯：每次线上事故后回看当时为什么没有覆盖到这条路径，把答案写进回归选择规则里，回归体系才会随事故进化而不是原地踏步。