回归范围确定规则可以落成一张可填写的判定表：先按变更影响面列出候选功能与接口，再按风险等级、使用频率、历史缺陷密度和依赖关系打分，最后用阈值把候选分成必测、抽测和不测三档。本文用一个假设的订单模块改版情景，完整演示这张表从填写到定稿的过程，并说明换一个模块时如何复用。
要点总览（TL;DR）
- 回归范围确定规则可以落成一张判定表：候选功能或接口、受影响原因、风险等级、使用频率、历史缺陷密度、依赖关系、综合得分、判定档位、抽样说明。
- 示例情景为订单模块改版，涉及计价逻辑与优惠券接口，按四项评分相加，8分及以上必测、5至7分抽测、4分及以下不测。
- 阈值依据候选得分分布确定，并非固定值；发布窗口紧可上调必测线，质量要求高可下调。
- 换模块复用时按五步走：列变更点、沿调用链扩候选、统一口径打分、按分布定阈值、为抽测和不测写明依据。
- 该方法适用于变更后既有能力验证，影响面无法评估或系统强耦合时，判定表宜作记录而非裁剪依据。
示例目标：这次回归要圈定多大范围
先交代情景。假设某电商系统的订单模块进行一次改版，变更点有两处：一是计价逻辑调整，涉及订单金额、运费和税费的计算顺序；二是优惠券接口升级，优惠券的校验与抵扣改由新接口返回结果。这次改版没有改动用户登录、商品详情、库存扣减等模块，但订单模块与这些模块存在调用关系。示例要回答的问题是：在本次改版后，哪些功能必须回归、哪些抽测、哪些可以不测，并给出可估算的测试量。
判定表需要产出的字段包括：候选功能或接口名称、受影响原因、风险等级、使用频率、历史缺陷密度、依赖关系、综合得分、判定档位、抽样说明。结论形式是一张分档清单：必测项逐条列出，抽测项注明抽样比例或抽样对象，不测项注明理由。这样产出的结果既能直接排入测试执行，也能在评审时逐行解释为什么测、为什么少测或不测。
需要说明的是，以下情景、分值和结论均为演示用示例，不代表任何真实项目的数据或实测结果。
完整示例：订单改版的回归范围判定表
下表是本次示例的填写结果。评分口径为：风险等级高记3分、中记2分、低记1分；使用频率高记3分、中记2分、低记1分；历史缺陷密度高记3分、中记2分、低记1分；依赖关系强记2分、弱记1分、无记0分。四项相加得到综合得分，满分11分。阈值设定为：得分8分及以上为必测，5至7分为抽测，4分及以下为不测。
| 候选功能/接口 | 受影响原因 | 风险等级 | 使用频率 | 历史缺陷密度 | 依赖关系 | 综合得分 | 判定档位 |
|---|---|---|---|---|---|---|---|
| 订单金额计算 | 计价逻辑直接变更 | 高（3） | 高（3） | 高（3） | 强（2） | 11 | 必测 |
| 运费与税费计算 | 计价逻辑直接变更 | 高（3） | 中（2） | 中（2） | 强（2） | 9 | 必测 |
| 优惠券校验与抵扣 | 接口升级，直接变更 | 高（3） | 高（3） | 中（2） | 强（2） | 10 | 必测 |
| 下单主流程 | 调用计价与优惠券接口 | 高（3） | 高（3） | 低（1） | 强（2） | 9 | 必测 |
| 订单取消与退款金额 | 依赖订单金额结果 | 高（3） | 中（2） | 中（2） | 强（2） | 9 | 必测 |
| 订单列表与详情展示 | 展示金额与优惠信息 | 中（2） | 高（3） | 低（1） | 弱（1） | 7 | 抽测 |
| 优惠券领取与发放 | 与升级接口共用券数据 | 中（2） | 中（2） | 低（1） | 弱（1） | 6 | 抽测 |
| 订单导出 | 读取订单金额字段 | 低（1） | 低（1） | 低（1） | 弱（1） | 4 | 不测 |
| 库存扣减 | 与订单模块存在调用关系，本次未改 | 中（2） | 高（3） | 低（1） | 弱（1） | 7 | 抽测 |
| 用户登录 | 无直接变更与调用变化 | 低（1） | 高（3） | 低（1） | 无（0） | 5 | 抽测 |
按上表汇总，必测项5条，覆盖计价、优惠券、下单主流程和退款金额；抽测项4条，包括订单展示、券领取、库存扣减和登录；不测项1条，为订单导出。测试量估算按每条必测项配置完整用例集、每条抽测项按三成用例抽样计算：若必测项平均每条12条用例、抽测项平均每条10条用例，则本次回归约执行60条必测用例加12条抽测用例，合计约72条，相比全量回归的两百余条明显收敛。
逐项解释：每一列为什么这样填
受影响原因从变更点向调用链推导。计价逻辑变更，直接落在订单金额、运费与税费的计算上；优惠券接口升级，直接落在券校验与抵扣上。再沿调用关系向外扩一层：下单主流程调用了计价和优惠券接口，订单取消与退款要读取订单金额结果，因此进入候选。订单列表与详情只是展示金额和优惠信息，属于弱依赖，列为候选但评分不高。库存扣减和登录与订单模块有调用关系但本次未改，列出来是为了判断是否需要抽测，而不是默认纳入。
四个评分维度的取值口径需要事先约定。风险等级看变更是否触及资金、权限或不可逆操作，本例中金额与优惠券都涉及资金，记高；使用频率看线上调用占比或用户操作占比，下单、金额展示属于高频，导出属于低频；历史缺陷密度看近几个版本该功能或邻近代码的缺陷数量，金额计算和优惠券历史问题较多，记高或中；依赖关系看该功能被多少其他功能调用、改动后是否会传导，强依赖记2分，弱依赖记1分，无依赖记0分。四个维度的分值应写进表格说明，避免不同人打分口径不一。
阈值定在8分和5分，依据是本次候选的得分分布。得分集中在9至11分的项，四项中至少三项偏高，属于变更直接命中且影响面大的功能，漏测代价高，划为必测。5至7分的项通常只有一到两项偏高，属于间接受影响或影响可控的功能，全测收益有限，划为抽测。4分及以下的项各项均低，且与变更点关系远，划为不测并记录理由，便于评审时复核。阈值不是固定值，候选数量多、发布窗口紧时可以上调必测线，质量要求高的版本可以下调。
抽测档的抽样方式按风险点选取，不做随机抽样。订单展示抽测金额与优惠信息的展示一致性；券领取抽测与升级接口共用数据的场景；库存扣减抽测下单成功后的扣减结果；登录抽测下单前的会话校验。每条抽测项写明抽什么、为什么抽，执行时按说明取用例，避免抽测变成随意点几条。
可迁移规律：换一个模块怎么复用
换一个模块时，按以下步骤复用这套判定表。第一步，列出本次变更点，区分直接变更和间接受影响。第二步，从变更点出发沿调用链、数据流和共用组件向外扩，形成候选清单，每个候选写明受影响原因。第三步，按四个维度逐项打分，打分前先确认口径，涉及资金、权限、不可逆操作的优先记高风险。第四步，按得分分布确定阈值，把候选分成三档。第五步，为抽测项写明抽样对象，为不测项写明理由，形成可评审的清单。
评分维度和阈值可以按项目特点调整。面向内部用户的系统，使用频率的区分度可能不高，可以换成影响用户数或业务单据量；强耦合系统里依赖关系的权重可以调高，把传导风险提前暴露；处于快速迭代期的模块，历史缺陷密度的统计窗口可以缩短到近两个版本。调整时保持两点：维度口径写清楚，阈值与得分分布对应，避免拍脑袋划线。
判定表在评审和交接中有两个用法。评审时逐行过必测项和不测项，重点确认不测理由是否成立，以及抽测项的抽样对象是否覆盖了主要风险点。交接时把判定表连同候选清单一起移交，接手人能看到每个结论的依据，不必重新推导一遍范围。
当候选清单、用例和缺陷分散在不同表格里时，判定表的维护成本会上升。ONES 支持将需求、测试用例与缺陷关联到同一工作项下，回归范围确定后，可以把必测项对应的用例挂到本次变更需求上，执行结果和发现的缺陷沿同一链路回填。这样判定表中的每一行都能对应到具体的用例集合和执行状态，评审时不必在多份表格间核对。是否采用工具承载取决于团队现有的管理方式，判定表本身用普通表格也能完成。
适用边界：哪些情况不适用这套判定
这套判定表适用于变更后对既有能力做验证的场景，即已有功能因代码、接口或配置变化而需要确认未受影响。它解决的是“测哪些”的范围问题，测试策略与测试计划的制定、测试环境与排期安排属于另外的工作，不在本文范围内。单个缺陷修复后的复测也不适用，复测范围通常由缺陷影响面和修复点决定，用判定表反而增加负担。
当变更影响面无法评估时，例如底层框架升级、公共组件替换、数据库结构大改，调用链难以逐条梳理，判定表的候选清单可能不完整。这种情况下应先做影响面分析或架构梳理，再回到判定表；在影响面清楚之前，不宜用打分结果直接裁剪范围。系统强耦合、模块间调用关系混乱时，依赖关系维度会普遍偏高，得分区分度下降，此时可以改为按核心链路逐条确认，判定表作为记录而非裁剪依据。
最后重申，本文的订单模块情景、分值和测试量均为演示用示例，用于说明判定表的填写方式，不代表真实项目数据，也不构成对任何具体系统回归范围的结论。实际使用时，请以本项目的变更内容、历史缺陷记录和评审结论为准。
常见问题
判定表的四个评分维度可以替换或增减吗？
可以，前提是替换后仍能区分候选之间的差异，并把口径写进表格说明。面向内部用户的系统，使用频率的区分度可能不高，可以换成影响用户数或业务单据量；强耦合系统可以把依赖关系的权重调高，让传导风险更早暴露。增减维度时注意保持总分口径一致，阈值随分值范围重新对应，避免沿用旧阈值直接划线。
候选清单怎么保证不漏掉间接受影响的功能？
从变更点出发，沿三条线向外扩：调用链、数据流和共用组件。计价逻辑变更后，凡是读取订单金额结果的功能都应进入候选，例如退款金额、订单导出；优惠券接口升级后，凡是共用券数据的功能也应列出，例如券领取与发放。扩完后请熟悉该模块的开发或测试复核一遍，把“本次未改但有调用关系”的项单独标注，再进入打分环节。
抽测项执行时抽多少、抽哪些，怎么定？
抽测比例按发布窗口和风险承受度确定，示例中按三成用例抽样仅用于演示。抽样对象按风险点选取，不做随机抽样：每条抽测项写明抽什么场景、为什么抽，例如订单展示抽金额与优惠信息的一致性，库存扣减抽下单成功后的扣减结果。执行时按说明取用例，抽测结果若发现问题，应把该项升为必测并扩大范围。
不测项写了理由，评审时还需要确认什么？
评审重点看不测理由是否成立，以及是否存在被低估的传导路径。确认三件事：该功能与变更点之间确实没有数据或调用关系；历史缺陷记录中没有与本次变更区域重叠的问题；一旦线上出问题，影响是否可接受、能否快速回退。三项都通过再维持不测结论，否则调整为抽测。不测项的理由要随判定表一起归档，便于后续追溯。
团队没有测试管理工具，判定表怎么落地？
用普通表格软件即可完成判定表的填写、打分和分档，关键是口径统一和结论可追溯。候选清单、用例和缺陷分散在多份表格时，维护成本会上升，可以在判定表中增加用例编号列，把每个必测项对应的用例集合列出来。ONES 支持将需求、测试用例与缺陷关联到同一工作项下，回归范围确定后可将必测项用例挂到本次变更需求上，执行结果沿同一链路回填；是否采用工具承载取决于团队现有管理方式。
