什么是全量回归（Full Regression）
全量回归，是软件测试里的回归测试的一种类型，简单一句话：对整个产品/项目所有功能，全部重新跑一遍测试用例，验证本次改动有没有破坏原有任何功能。
对比区分
1. 全量回归（Full Regression）
- 范围：全部模块、全部功能、全部用例，不做裁剪
- 触发场景：
- 版本大升级、底层架构改动
- 核心模块大量代码变更
- 隔了很久才发版、多批次需求合并上线
- 线上出现严重bug，大面积修复后
- 优点：覆盖最完整，漏测风险最低
- 缺点：耗时长、人力成本高，执行慢
2. 增量回归 / 部分回归（Partial Regression）
- 范围：只测改动点 + 受影响关联模块
- 触发：小需求、简单bug修复
- 优点：快、成本低
- 缺点：依赖对影响范围的判断，判断错就容易漏测
3. 冒烟回归
只跑核心主流程，快速验证版本能不能用，属于极简回归。
举个例子
一个电商系统：商品、购物车、下单、支付、退款、会员、优惠券。
- 只改优惠券规则：做增量回归，测优惠券+下单关联逻辑即可
- 重构整个订单底层数据库：做全量回归，商品、购物车、下单、支付、退款、会员所有功能全部复测一遍，防止改底层把老功能搞崩
补充要点
- 全量回归≠每次上线都做，一般只在高风险变更才启用；日常迭代大多用增量回归。
- 自动化测试里也经常提到全量回归：一次性执行自动化用例集里全部脚本，而不是只跑部分脚本。
- 核心目的：防止新代码引入缺陷，把原本正常的老功能搞坏（回归bug）。
如果你需要，我可以整理一份：全量回归 vs 增量回归 vs 冒烟测试的对比表格，方便写测试方案。
全量回归 vs 增量回归 vs 冒烟测试 对比表
| 对比项 | 全量回归（Full Regression） | 增量回归（Partial Regression） | 冒烟测试（Smoke Test） |
|---|---|---|---|
| 核心定义 | 对产品全部功能、全部测试用例完整执行，验证改动不会破坏任何原有功能 | 仅测试本次变更点 + 预估受影响关联模块，不覆盖全量功能 | 快速验证版本核心主流程是否可用，判断版本是否具备后续测试资格 |
| 覆盖范围 | 最大，全模块、全用例 | 中等，变更点+关联范围 | 最小，核心主干流程 |
| 适用场景 | 1.底层架构/核心模块重构 2.大量需求合并上线 3.长时间未迭代，版本跨度大 4.线上重大故障修复后 | 1.小需求开发、简单bug修复 2.改动范围小，影响面清晰 3.日常迭代版本 | 1.版本包刚交付，准入校验 2.每日构建/自动化打包快速校验 |
| 测试目标 | 最大程度规避回归缺陷，保障整体产品稳定 | 在可控成本下，拦截变更带来的关联bug | 快速阻断不可用版本，避免浪费测试人力 |
| 优点 | 覆盖全面，漏测风险最低 | 执行快、人力成本低 | 耗时极短，快速判断版本可用性 |
| 缺点 | 耗时长、资源消耗大，不适合频繁执行 | 依赖影响范围分析，分析失误会漏测 | 覆盖极少，只能阻断致命阻塞问题 |
| 执行时机 | 版本正式上线前，高风险变更后 | 日常迭代，大部分需求提测后 | 版本编译完成，提测第一关 |
| 自动化场景 | 执行全套自动化用例集 | 只跑变更相关自动化脚本 | 自动化核心链路脚本，快速跑通主干 |
| 典型举例 | 电商系统订单底层数据库重构，复测商品、购物车、下单、支付、退款、会员全部功能 | 仅修改优惠券折扣逻辑，只测优惠券+下单关联流程 | 验证电商能否正常打开、浏览商品、下单支付主干流程 |
一句话总结
- 冒烟测试：版本能不能测（准入检查）
- 增量回归：改哪里+影响哪里就测哪里（日常主力）
- 全量回归：全部功能重测一遍（高风险大变更兜底）
需要我再补充一份在测试方案文档里可直接粘贴的简短文字说明吗？