回归测试计划要回答的是：这次变更之后，原有功能是否仍然可用。计划是否可用，取决于三个条件能否说清——范围从哪里来、分几轮执行、每个环节由谁负责并交付什么。本文按“输入—动作—输出”的顺序，给出可直接套用的范围表、轮次安排、角色分工和完成检查清单，适合测试负责人或测试人员在版本变更前起草计划时使用。
要点总览（TL;DR）
- 回归测试计划以变更影响分析为起点：先收集变更清单、影响范围分析、用例库和历史缺陷记录，再圈定范围、分层选用例。
- 范围按风险分三层：核心链路每轮必测，高频功能按变更关联度选取，边缘功能在全量回归轮覆盖或依据历史缺陷决定，取舍理由要留痕。
- 执行按冒烟回归、核心回归、全量回归递进，每轮写明触发条件、准入条件和准出标准，未通过项与单缺陷复测分开记录。
- 范围确认、用例评审、执行记录、结果评审四个环节都要落实到人和交付物，计划变更由测试负责人更新并保留版本记录。
- 定稿前用完成检查清单核对：变更影响面是否全覆盖、用例分层是否与风险一致、通过标准是否可由记录直接判定。
回归测试计划先定哪几件事
回归测试计划的目标很具体：验证本次变更没有破坏既有能力。它不承担新功能验收，也不替代单个缺陷修复后的复测。把目标定准，计划才不会写成一份笼统的“测试安排”。
起草前先收集四项输入。缺少任何一项，范围就只能靠猜：
- 变更清单：本次版本包含的需求、缺陷修复、配置调整和依赖升级，标明每项变更涉及的模块与提交时间。
- 影响范围分析：由开发或需求负责人对每项变更说明可能波及的模块、接口、数据结构和上下游依赖。
- 既有用例库：按模块组织的存量用例，最好带有优先级、最近执行结果和覆盖的需求编号。
- 历史缺陷与风险记录：过去同类变更出过问题的模块、高频缺陷区域，作为加权的依据。
有了输入，计划编制围绕五个动作展开：圈定范围、分层选用例、定触发时点与轮次、定角色与交付物、定通过标准。五个动作的产出汇总成四份可执行材料：回归范围表、用例选择清单、执行排期（含准入准出条件）、角色与交付物对照表。这四份材料就是回归测试计划的正文，其余文字都是对它们的说明。
| 动作 | 输入 | 输出 | 完成标志 |
|---|---|---|---|
| 圈定范围 | 变更清单、影响范围分析 | 回归范围表 | 每项变更都能对应到受影响模块，无遗漏项 |
| 分层选用例 | 用例库、历史缺陷记录 | 用例选择清单 | 每个范围内模块都有对应用例，取舍有记录 |
| 定触发与轮次 | 版本排期、变更类型 | 执行排期与准入准出条件 | 每轮有启动条件、结束标准和责任人 |
| 定角色与交付物 | 团队分工 | 角色职责与交付物对照表 | 每个环节有明确负责人和产出物 |
| 定通过标准 | 质量要求、历史基线 | 判定规则与证据要求 | 通过与否可由记录直接判定 |
回归范围怎么圈：从变更影响到用例分层
范围确定分两步走：先从变更推导影响面，再按风险给用例分层。跳过第一步直接全量回归，成本高且执行容易走形式；只测变更点本身，又会漏掉依赖模块。
从变更清单推导影响面
逐条处理变更清单，对每项变更追问三个问题：直接改动了哪个模块或接口；该模块被哪些上游功能调用；是否涉及数据结构、公共组件、配置项或第三方依赖的调整。答案填入回归范围表，形成“变更项—受影响对象—影响类型”的对应关系。公共组件和配置项的变更往往波及面最广，需要单独列出。
按风险分层选用例
影响面确定后，把范围内的用例分为三层，不同层对应不同的执行轮次：
- 核心链路：主业务流程和关键交易路径，一旦失败直接影响用户可用性。这一层用例必须每轮执行。
- 高频使用功能：日常使用频率高、用户感知明显的功能，按变更关联度选取，在核心回归轮执行。
- 边缘功能：低频入口、历史遗留模块、管理后台的次要配置。可在全量回归轮覆盖，或依据历史缺陷记录决定是否纳入。
取舍要留痕。每条未纳入的用例注明理由，例如“本次变更未触及该模块”“近三个版本无缺陷且无调用关系”。范围变更时，先更新范围表，再同步调整用例清单和轮次安排，并在计划中记录变更时间和确认人。这样后续复盘时能判断是范围判断失误还是执行遗漏。
触发时点、执行轮次与准入准出条件
回归在什么条件下启动、分几轮、每轮何时算通过，需要在计划里写死，避免临时口头约定。
常见触发点
版本提测是最常规的触发点；缺陷修复合入主干后，需要针对修复影响面做定向回归；配置项、依赖库或部署环境变更，即使代码未动，也应触发一轮核心回归。触发条件写进计划时，同时注明触发后的响应时限，例如提测后一个工作日内启动冒烟回归。
分轮策略
| 轮次 | 适用条件 | 覆盖范围 | 准入条件 | 准出标准 |
|---|---|---|---|---|
| 冒烟回归 | 每次提测或修复合入 | 核心链路的最小用例集 | 构建可部署、主流程可走通 | 冒烟用例全部通过，无阻塞级缺陷 |
| 核心回归 | 冒烟通过后 | 核心链路 + 与变更关联的高频功能 | 冒烟准出、变更清单确认完毕 | 核心与高频用例通过率达到计划设定值，遗留缺陷已评估 |
| 全量回归 | 发布前或大范围变更 | 范围内全部三层用例 | 核心回归准出、发布窗口确定 | 全部计划用例执行完毕，未通过项有结论 |
未通过时的处置也要写清：阻塞级缺陷直接退回开发，本轮终止；一般缺陷记录后继续执行其余用例，修复后安排复测。复测只覆盖失败用例及其直接影响面，与完整轮次区分开，避免把复测混入下一轮统计。
角色分工与各环节交付物
计划落到人，才具备执行条件。回归测试涉及的角色和交付物可以按环节对照：
| 环节 | 负责人 | 配合角色 | 交付物 |
|---|---|---|---|
| 范围确认 | 测试负责人 | 开发、产品/业务方 | 回归范围表，含影响面说明与确认记录 |
| 用例选择与评审 | 模块测试人员 | 测试负责人 | 用例选择清单，含分层结果与取舍理由 |
| 执行与记录 | 模块测试人员 | 开发（缺陷定位） | 执行记录、缺陷单、失败用例清单 |
| 结果评审 | 测试负责人 | 产品/业务方、开发 | 回归结论、遗留问题清单、发布建议 |
开发负责提供准确的影响范围分析并在缺陷修复后说明修复影响面；产品/业务方确认核心链路范围和通过标准的业务口径。交接节点设在范围确认后和结果评审前：范围表确认后冻结本轮范围，新增变更走变更确认流程；执行记录齐备后进入评审，评审结论作为发布决策的输入。计划本身发生调整时，由测试负责人更新并通知相关角色，保留调整前后的版本记录。
当回归范围、用例执行和缺陷流转需要在同一处承载时，可以用 ONES 测试管理来组织：用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；测试计划可多维度概览并分配用例执行人；未通过的用例可快速创建缺陷任务，在测试与研发团队间流转；测试报告可自动生成并支持自定义模板。范围表和轮次安排仍由测试负责人制定，工具承担的是执行记录与结果汇总这一层。
一份可填写的回归测试计划示例
以下为演示情景，用于说明填写方式，不代表真实项目数据。
背景：某业务系统发布 v3.2 版本，包含三项变更——订单结算页改版、支付接口增加一种渠道、用户中心修复一个头像上传缺陷。测试负责人据此起草回归计划。
范围表填写示例
| 变更项 | 受影响对象 | 影响类型 | 风险层级 |
|---|---|---|---|
| 订单结算页改版 | 结算页、优惠券计算、订单创建接口 | 直接改动 + 上游依赖 | 核心链路 |
| 支付接口新增渠道 | 支付网关、退款流程、对账任务 | 接口扩展 + 下游依赖 | 核心链路 |
| 头像上传缺陷修复 | 用户中心、文件存储服务 | 局部修复 | 高频功能 |
轮次与判定填写示例
冒烟回归安排在提测当日，覆盖登录、下单、支付主流程共 15 条用例，全部通过方可进入下一轮。核心回归在次日执行，覆盖结算、支付、退款及用户中心相关用例共 60 条，通过率要求不低于 98%，且无阻塞级缺陷。全量回归在发布前两个工作日执行，覆盖范围内全部 180 条用例。头像上传缺陷修复后安排一次定向复测，只执行该模块的 6 条用例，结果单独记录。
结果记录示例
执行完成后，记录每轮实际执行数、通过数、失败用例编号及对应缺陷单号，未通过项注明处置结论（已修复待复测、延期、接受风险）。结论栏写明“核心回归通过率 98.3%，遗留 1 个一般缺陷已评估不影响发布”，作为发布评审的输入。
计划落地后的完成检查
计划定稿前，用下面这份清单逐项核对，每项都能给出明确答案才算可执行：
- 变更清单中的每一项是否都能在范围表中找到对应的影响对象？未纳入的项是否有书面理由？
- 范围内每个模块是否都有对应用例，且用例分层与风险层级一致？
- 每轮的触发条件、准入条件、准出标准是否写明，且可由执行记录直接判定？
- 范围确认、用例评审、执行记录、结果评审四个环节是否都有明确负责人和交付物？
- 通过标准是否包含通过率口径、缺陷等级要求和证据形式（执行记录、缺陷单、报告）？
- 范围或轮次发生变更时，是否约定了更新方式和确认人？
- 未通过项的处置路径和复测边界是否与完整轮次区分清楚？
清单全部通过，回归测试计划就具备了执行和复盘的基础；后续每轮执行的实际数据，又可以反过来修正下一版计划的范围判断和轮次设置。
常见问题
回归测试计划与整体测试计划是什么关系，需要单独写吗？
整体测试计划覆盖一个版本或一个项目的测试策略、资源、进度和风险，回归测试计划是其中针对“变更后既有能力是否仍可用”这一部分的具体安排。当版本变更较多、涉及公共组件或依赖升级时，单独写一份回归测试计划更容易执行和复盘；变更范围小、影响面清晰时，也可以作为整体测试计划中的一个章节，但范围表、轮次和准入准出条件仍需写清。
变更频繁、每次都要回归，如何避免计划越写越重？
把稳定部分固化成模板，只更新变化部分。范围表可以按模块预置常用影响关系，用例分层规则和历史缺陷加权方式一次确定、长期沿用；每次只需重新填写变更清单、受影响对象和本轮取舍理由。轮次安排也可以按变更类型预设：局部修复走冒烟加定向回归，公共组件或接口调整走核心回归，发布前走全量回归。模板化的前提是上一轮执行数据被记录下来，用来修正分层和取舍规则。
回归执行中发现范围漏了模块，应该怎么处理？
先评估遗漏模块与本次变更的关联程度和风险层级，再决定处理方式：属于核心链路的，暂停当前轮次统计，补充用例后重新执行并更新范围表；属于边缘功能的，可记录为范围变更，纳入全量回归轮或下一轮执行。无论哪种情况，都要在计划中记录变更时间、补充理由和确认人，并在结果评审时说明对通过率统计口径的影响，避免复盘时把范围判断失误误认为执行遗漏。
通过率设成多少合适，是否每轮都要用同一个标准？
通过率标准应与轮次和风险层级匹配。冒烟回归通常要求全部通过，因为它的作用是判断构建是否具备继续测试的条件；核心回归可以设定一个较高的通过率下限，并对阻塞级缺陷单独设零容忍要求；全量回归更关注计划用例是否执行完毕、未通过项是否都有结论。具体数值应参考历史基线和本次变更风险，在计划中写明口径（按用例数还是按模块计），执行后按同一口径统计。
回归范围、用例执行和缺陷流转分散在不同表格里，怎么保证记录可追溯？
关键是让范围、用例和缺陷共用同一套标识：范围表中的每个受影响对象对应到用例库中的模块或用例编号，执行记录引用这些编号，失败用例产生的缺陷单再回填到执行记录中。使用测试管理工具承载时，可以把用例与需求、任务关联，测试计划与迭代关联，未通过的用例直接创建缺陷任务并在测试与研发团队间流转，测试报告自动汇总执行结果。ONES 测试管理提供上述关联、执行分配与报告能力，具体版本和套餐差异建议向官方确认。范围表和轮次安排仍由测试负责人制定，工具负责执行记录与结果汇总。
