回归范围由本次变更的影响面决定，而非把全部用例重跑一遍。做法是先收集变更清单，再沿调用链、依赖、数据与业务场景推导受影响功能，映射到既有用例后按风险分为必测、抽测、不测三档，经评审留痕，并在执行中依据缺陷分布调整。本文给出可直接照做的步骤与表格。
要点总览（TL;DR）
- 回归范围由变更影响面决定：先收齐需求、代码、配置、依赖、数据与接口五类变更，形成可核对的变更输入清单。
- 逐项沿调用链、依赖、数据、业务场景四条线索推导受影响功能点，并记录每个功能点的来源变更，便于评审追溯。
- 把受影响功能点映射到既有用例，按变更直接程度、业务关键度、使用频率、历史缺陷密度分为必测、抽测、不测三档，不测项须写明理由和风险接受人。
- 范围由测试牵头推导，开发、产品与业务方参与评审确认；执行中依据缺陷分布调整并留痕，最后用完成检查清单逐项核对。
先明确变更清单：回归范围的输入从哪里来
回归范围不准，常见原因在输入阶段：测试凭印象回忆“这次改了什么”，漏掉配置调整、依赖升级和接口字段变化。范围确定的第一步，是把本次发布涉及的所有变更项收齐并结构化，形成一份可核对的变更输入清单。清单完整，后续推导才有依据。
变更清单通常包含五类内容，每类有明确的提供者和需要标注的影响线索：
| 变更类型 | 典型内容 | 提供者 | 需标注的影响线索 |
|---|---|---|---|
| 需求变更 | 新增或调整的业务规则、交互流程、权限逻辑 | 产品 | 改动模块、关联需求号、涉及角色 |
| 代码提交 | 功能开发、缺陷修复、重构 | 开发 | 改动模块、调用方、是否公共组件 |
| 配置与参数 | 开关、阈值、路由规则、环境配置 | 开发、运维 | 生效范围、影响的环境与模块 |
| 依赖组件升级 | 中间件、公共库、第三方服务版本变化 | 开发、运维 | 被哪些模块引用、是否公共组件 |
| 数据与接口变更 | 表结构、字段、缓存键、消息格式、接口出入参 | 开发 | 上下游调用方、数据消费方 |
清单字段建议固定为：变更项、类型、涉及模块、调用方、提交人、关联需求/缺陷号、是否公共组件。其中“调用方”和“是否公共组件”两列是后续推导影响面的关键，收集时就要填，不能留空。公共组件的改动往往波及多个业务线，遗漏这一列会直接导致范围偏小。
收集方式上，可以由测试负责人在发布前发起一次清单汇总，开发按提交记录填写代码与配置项，产品补充需求变更，运维提供依赖与环境变化，测试负责合并去重并核对关联号。清单在范围评审前冻结一版，后续新增变更走补充登记。
当变更项、需求和缺陷已经记录在工作项系统中时，清单可以直接从工作项导出整理，减少手工转录的遗漏。ONES 支持测试用例与需求、任务关联，测试计划与迭代关联，变更项与对应用例可以在同一套工作项体系内建立联系，便于把清单和后续分档结果串起来。
从变更推导影响面：四条线索逐层展开
拿到变更清单后，逐项推导“这个改动会让哪些已有功能的行为发生变化”。推导沿四条线索展开，每条线索的产出都是受影响功能点，最终汇总成一张“变更项→影响线索→受影响功能点”的清单。
调用链线索
从改动的方法、服务或接口出发，向上找调用方，向下找被调服务。上游调用方决定哪些入口会受影响，下游被调服务决定哪些返回结果可能变化。例如修改订单查询接口的返回字段，所有调用该接口的页面、导出功能和对接方都在影响范围内。产出应写到功能点粒度，如“订单列表页”“订单导出”“开放平台订单查询”。
依赖线索
检查改动是否涉及共享组件、公共库、中间件或配置中心。公共组件的变更要列出所有引用方，配置中心的变更要确认生效范围和灰度策略。这条线索容易产生大范围影响，推导时以引用清单为准，不凭记忆判断“应该没人用”。
数据线索
表结构、字段含义、缓存键、消息格式的变化，会影响所有读写这些数据的路径。需要确认：哪些功能写入该字段、哪些功能读取该字段、缓存失效后回源逻辑是否正常、消息消费方能否兼容新格式。数据类变更往往不改变界面，却会在统计、报表、对账等下游功能上暴露问题。
业务场景线索
同一功能在不同角色、终端、流程分支下的使用路径不同。改动一个审批节点，需要检查发起人、审批人、抄送人各自的视图，以及移动端与网页端、正常流程与驳回重提分支。这条线索把技术影响翻译成用户可感知的功能点，是映射用例前的必要一步。
四条线索推导完成后，合并去重，形成受影响功能点清单。每个功能点标注来源变更项和推导线索，便于评审时追溯“为什么它在范围内”。
把受影响功能映射到既有用例并分档
受影响功能点本身不是回归范围，还要落到可执行的用例上。前提是用例库与功能点之间有稳定的对应关系：用例按功能模块组织，每条用例标注所属功能点，需求变更时同步更新用例。若对应关系缺失，先补齐关键模块的映射，再谈分档。
映射完成后，按四个维度对候选用例分层：
- 变更直接程度：直接改动路径的用例优先级最高，间接依赖的次之。
- 业务关键度：涉及资金、权限、核心交易流程的功能，容错空间小。
- 使用频率：高频入口的问题暴露面大，用户感知明显。
- 历史缺陷密度：过去反复出问题的模块，回归价值更高。
据此划分三档，判定规则与记录方式如下：
| 档位 | 判定规则 | 记录方式 |
|---|---|---|
| 必测 | 变更直接路径，或业务关键度高、历史缺陷密集的功能 | 列入本轮回归计划，逐条执行并记录结果 |
| 抽测 | 间接影响、使用频率中等、有自动化覆盖或近期稳定 | 按抽样规则选取部分用例，注明抽样依据 |
| 不测 | 影响可忽略、功能已下线或风险经评估可接受 | 显式列出，写明不测理由和风险接受人 |
“不测”必须显式记录，不能靠沉默省略。每条不测项写明理由和风险接受人，接受人对该风险知情并确认。分档表字段建议为：功能点、对应用例、档位、判定理由、风险接受人。这张表就是本轮回归范围的正式定义，也是后续评审和调整的基准。
用例库的结构化程度直接影响映射效率。ONES 支持通过不同方式导入用例至用例库并以清晰结构组织管理，同时提供自定义属性，可以为用例补充功能点、关键度等标记，让分档筛选有据可依；用例与需求、研发任务关联后，变更项能顺着关联关系找到候选用例。
角色分工与交付物：谁定范围、谁确认
回归范围涉及技术影响判断和业务风险取舍，由测试单方拍板容易两头失真：技术上漏掉调用方，业务上误判关键度。合理做法是测试牵头推导，多方参与确认。
| 角色 | 在范围确定中的职责 | 交付物 |
|---|---|---|
| 测试负责人 | 汇总变更清单，组织影响面推导，编制分档表，发起评审 | 变更输入清单、受影响功能点清单、回归范围分档表 |
| 开发 | 提供代码、配置、依赖与数据变更，说明调用方和公共组件引用 | 变更项登记及影响线索说明 |
| 产品 | 提供需求变更，确认业务关键度与使用频率判断 | 需求变更说明、关键度确认意见 |
| 业务方 | 对不测项和抽测抽样做风险确认 | 风险接受确认 |
范围评审安排在变更清单冻结之后、回归执行开始之前，参与人包括测试负责人、相关开发、产品和业务方代表。评审输出是确认后的分档表和评审记录，记录中写明参与人、确认结论和遗留分歧。
执行过程中若发现新变更或原判断有误，由提出人发起范围变更，说明新增或调整的功能点、档位变化及理由，经测试负责人和相关角色确认后更新分档表，并通知执行人员。范围变更同样留痕，避免出现“计划外执行了用例但没人知道为什么”。
评审记录和分档表需要有稳定的存放位置，并与本轮迭代关联。ONES 支持为不同用户组配置权限，也可为用例库、测试计划单独配置权限，范围确认结果可以按角色控制可见与可编辑范围，评审结论随测试计划一并留存。
一个完整示例：支付模块优惠券逻辑变更的回归范围
以下为演示情景，用于说明推导过程，不代表任何真实项目数据。
变更描述：支付模块调整优惠券叠加规则，允许两张满减券在同一订单叠加使用，涉及结算页金额计算、订单创建接口和优惠券核销逻辑。
变更清单填写：需求变更一项，关联需求号；代码提交涉及结算服务与优惠券服务；接口变更涉及订单创建接口的优惠金额字段；数据变更涉及订单表新增优惠明细字段。提交人为对应开发，产品提供需求说明。
四条线索推导：
- 调用链：结算页、订单确认页、订单创建接口、支付回调中的金额校验。
- 依赖：优惠券服务被营销活动页、会员中心引用，需检查这些入口的券展示与可用性判断。
- 数据：订单表新增字段影响订单详情、订单导出、对账报表。
- 业务场景：新用户与老用户、单券与叠加券、全额退款与部分退款分支。
分档结果：结算页金额计算、订单创建、优惠券核销、退款金额计算列为必测；营销活动页券展示、订单导出列为抽测；会员中心券列表因仅读取券状态、不涉及叠加逻辑，列为不测，由产品确认风险接受。
评审调整：评审中开发补充说明支付回调也读取优惠金额字段，遂将支付回调金额校验从抽测上调为必测；业务方要求对账报表纳入抽测，理由是财务对账依赖该字段。
执行中的动态调整与完成检查
分档表是执行起点，执行中的信息会改变判断。以下情况触发范围调整：必测项集中出现缺陷，说明影响面被低估，应扩大同模块抽测范围；抽测项连续通过且变更影响已确认有限，可在记录理由后收窄；发现清单外的新变更，补充登记并重新推导影响面。
每次调整记录调整项、原档位、新档位、触发原因、确认人和通知范围，更新后的分档表同步给执行人员。调整记录与评审记录放在一起，形成完整的范围决策轨迹。
范围工作是否完成，用以下清单逐项核对：
- 变更清单覆盖需求、代码、配置、依赖、数据与接口五类，字段填写完整，公共组件已标注。
- 每个变更项都有四条线索的推导记录，受影响功能点可追溯到来源变更。
- 分档表中每条用例都有档位和判定理由，必测、抽测、不测三档齐全。
- 所有不测项均写明理由并有风险接受人确认。
- 范围评审已召开，参与人和结论有记录。
- 执行期的每次范围调整都有记录并已通知相关人员。
回归执行结束后，测试报告需要反映本轮范围与结果。ONES 支持自动生成测试报告并自定义报告模板，可将分档结果、执行情况和缺陷分布汇总呈现，供发布决策参考。
常见问题
变更清单在评审前冻结后，又出现紧急修复提交，回归范围怎么处理？
把这类提交当作范围变更处理，不直接塞进已确认的分档表。由提交人补充登记变更项，写明改动模块、调用方和是否公共组件，测试据此补做影响面推导，判断是新增必测项还是并入已有抽测。调整后的档位变化、触发原因和确认人一并记录，更新分档表并通知执行人员。若紧急修复在回归执行后期才出现，需要评估剩余执行时间是否够覆盖新增必测项，不够时由业务方对未覆盖部分做风险确认。
团队用例库和功能点没有建立对应关系，还能做分档吗？
可以先做，但要接受精度损失。临时做法是按功能模块粗粒度归并用例，把受影响功能点对应到模块级用例集，在分档表里注明“模块级映射，待细化”。同时把补齐关键模块的用例与功能点映射列为后续任务，优先补资金、权限、核心交易流程这类高关键度模块。映射关系补齐后，分档可以从模块级细化到用例级，抽测抽样也会更有依据。
抽测的抽样比例有统一标准吗？
没有通用比例，抽样依据比比例本身更重要。可参考的因素包括：该功能点与变更的间接程度、历史缺陷密度、是否有自动化覆盖、本轮剩余执行时间。常见做法是间接影响且近期稳定的功能抽少量核心路径，间接影响但历史问题多的功能提高抽样量。无论比例多少，都要在分档表中写明抽样依据，让评审者能判断这个抽样是否合理。
不测项的风险接受人应该由谁担任？
由对该功能业务后果承担责任的角色担任，通常是产品负责人或业务方代表，测试负责人可以提出建议但不替对方接受风险。确认方式建议留下明确记录：不测的功能点、理由、可能的影响、接受人姓名与确认时间。若接受人对技术影响判断存疑，可要求开发补充说明后再确认。风险接受人缺位时，该功能点宜先归入抽测，避免出现无人认领的不测项。
回归范围确定后，如何与测试计划和测试报告衔接？
分档表确认后直接作为测试计划的输入：必测项逐条排入执行计划，抽测项注明抽样规则，不测项作为范围说明附在计划中。执行结束后，测试报告应反映本轮实际范围、各档执行结果和缺陷分布，让发布决策者看到哪些功能验证过、哪些按风险接受未覆盖。范围调整记录也应随报告留存，形成从变更清单到范围决策再到执行结果的完整链路。ONES 支持自动生成测试报告并自定义报告模板，可将分档结果、执行情况和缺陷分布汇总呈现。
