回归测试用例选择可以按四步推进：先识别本次变更的影响范围，再按风险分级确定覆盖强度，然后用用例库的关联字段筛出候选集并人工复核，执行后把漏测和冗余回写到用例库。它解决的是“这次版本该跑哪些既有用例”，适用于需求变更、缺陷修复、配置与依赖升级等场景；整体测试策略制定和单个缺陷的复测跟踪不在本文范围内。
要点总览（TL;DR）
- 回归选例从变更影响范围出发：把需求变更、代码提交、缺陷修复、配置升级合并成清单，标注模块、接口、数据对象和风险等级。
- 风险分级决定覆盖强度：高风险模块全量执行，中风险覆盖主流程与边界，低风险抽检，核心链路与冒烟用例每次固定保留。
- 用例库按模块、接口、数据表、关联缺陷等字段初筛，再人工补充跨模块组合、历史高发缺陷和本次新增边界三类场景。
- 执行后把漏测用例回补、冗余用例降级或剔除，并更新关联字段，让下个版本能直接按字段筛选。
- 完成标准是六项检查全部满足：范围已标注、分级已覆盖、核心链路已保留、复核记录完整、结果已回写、字段已更新。
先定影响范围：回归用例从哪里筛出来
回归选例的第一步是把“这次改了什么”转成一份可检索的影响范围清单。清单里要落到模块、接口、数据对象和风险等级四个维度，后续筛选才有依据。范围识别不完整，后面筛得再快也会漏掉调用方和被调用方。
变更清单从哪里获取
变更信息通常分散在几个地方，需要合并成一张表再分析：
- 需求变更：产品需求文档的修订记录、变更评审结论，标明改了哪个功能点、影响哪些角色。
- 代码提交：按提交记录归并到模块或服务，重点关注公共组件、工具类、配置文件的改动。
- 缺陷修复：修复单关联的模块和触发条件，修复本身可能引入新的边界问题。
- 配置与依赖升级：中间件版本、第三方接口、数据库字段、开关配置的调整，这类变更容易被忽略，却常影响多个模块。
沿影响链路展开
拿到变更点后，逐个向下和向上追一层：直接改动的模块本身要覆盖；上游调用方要确认入参和返回结构是否受影响；下游被调用方要确认依赖的接口契约是否变化；共享数据与公共组件要单独列出，例如用户中心、权限、消息队列、公共字典表。公共组件的改动往往牵动多个业务模块，应作为独立条目记录，而不是并入某一个模块。
把范围落到用例库字段上
影响范围清单的每一行，最终要能对应到用例库中的检索条件。常见做法是给每个变更点标注：所属模块、涉及的接口名、涉及的数据表或字段、关联的需求编号。这样在用例库中按模块、接口、数据表筛选时，能直接命中候选用例。清单建议用表格维护，字段包括变更编号、变更类型、直接改动模块、上游调用方、下游依赖、共享组件、数据对象、初步风险等级、备注。
完成标志是：每个变更点都有明确的模块和接口归属，公共组件改动已单独列出，清单可以直接作为下一步风险分级的输入。
按风险分级确定回归范围与用例数量
影响范围决定“筛哪里”，风险分级决定“筛多深”。同一份范围清单，高风险部分全量覆盖，中风险选取主流程与边界用例，低风险抽检即可。分级不是为了减少工作量而随意压缩，而是把有限的执行时间放在最可能出问题的地方。
四个分级维度
| 维度 | 判断依据 | 高风险信号示例 |
|---|---|---|
| 变更规模 | 改动代码量、涉及文件数、是否改动公共组件 | 公共组件重构、数据库结构变更 |
| 业务关键度 | 该功能是否属于核心交易、登录、支付等主链路 | 下单、结算、权限校验 |
| 历史缺陷密度 | 该模块近几个版本的缺陷数量与严重级别 | 连续多个版本出现线上问题 |
| 使用频率 | 功能被用户调用的频次与覆盖人群 | 高频入口、默认路径 |
四个维度不必精确打分，可以用“满足两项及以上高风险信号即定为高”这类简单规则，保证团队内判断口径一致。
三档覆盖策略
- 高风险：该模块用例全量执行，包括正常流程、异常流程、边界值和历史缺陷对应用例。
- 中风险：执行主流程用例加边界用例，异常分支选取与本次变更直接相关的部分。
- 低风险：抽检少量代表性用例，确认基本可用即可，抽检比例可按团队经验设定并在复盘中调整。
固定保留的用例
无论风险分级结果如何，核心链路用例和冒烟用例应固定保留在每次回归集中。核心链路指用户完成主要业务目标必须经过的路径，冒烟用例指能在较短时间内判断系统是否可测的基础检查。这两类用例构成回归集的底线，避免因分级判断偏差导致主流程未被验证。
完成标志是：影响范围清单中每一行都标注了风险等级，并对应到具体的覆盖策略和预计用例数量，总量与本次可投入的执行资源相匹配。
用关联字段筛选，再人工复核补充
有了范围清单和分级规则，就可以在用例库中做初筛。初筛解决效率问题，人工复核解决准确性问题，两步都不能省。
用例库需要具备的关联字段
筛选的前提是用例本身带有可检索的关联信息。建议用例库至少维护以下字段：需求编号、所属模块、涉及接口、涉及数据表或字段、关联缺陷编号、优先级、最近执行结果。字段在编写用例时同步填写，而不是事后补录，否则筛选结果会失真。
初筛的操作顺序
- 按模块筛选：用影响范围清单中的直接改动模块，筛出该模块下全部用例。
- 按接口和数据表补充：对跨模块调用和数据共享的变更点，用接口名、数据表字段作为条件再筛一轮，把其他模块中受影响的用例纳入。
- 按关联缺陷补充：对历史缺陷密度高的模块，筛出关联缺陷的用例，确保曾经的坑被覆盖。
- 按优先级收口：在候选集中按优先级排序，结合风险分级确定最终执行范围。
人工复核补三类场景
字段筛选只能命中已标注关联的用例，以下三类需要人工判断补充：
- 跨模块组合场景：单个模块用例都通过，但组合路径可能出问题，例如订单模块与库存模块的联动。
- 历史高发缺陷场景：曾经反复出问题的业务路径，即使本次变更看似无关，也建议保留。
- 新变更引入的边界：本次改动新增的入参范围、空值处理、并发情况，原有用例可能未覆盖，需要补充或标记为待补用例。
复核记录要写清楚：补充了哪些用例、补充理由、由谁确认。这份记录既是本次回归集的说明，也是后续维护用例库的输入。
在工具层面，ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联；用例库中所有用例属性都支持筛选，并支持自定义用例属性，可以把模块、接口、数据表等关联信息设为字段，按影响范围做初筛。用例模块支持树状结构和拖拽排序，便于按业务域组织用例。筛选结果仍需按上述三类场景人工复核，字段维护得越完整，初筛命中率越高。
角色分工与各环节交付物
回归选例涉及开发、测试、产品三方，职责不清时最容易出现“影响范围没人说全、用例没人复核”的情况。下表给出一种常见分工，团队可按规模调整，但每个环节都应有明确的责任人和产出。
| 环节 | 责任人 | 主要动作 | 交付物 |
|---|---|---|---|
| 变更点与影响链路说明 | 开发 | 汇总需求变更、代码提交、配置升级信息，标注直接改动模块、上下游依赖、共享组件 | 变更影响说明，含模块、接口、数据对象 |
| 风险分级与用例筛选 | 测试负责人 | 组织分级评审，按规则确定各模块覆盖强度，在用例库中初筛 | 风险分级表、回归候选集 |
| 核心链路确认 | 产品/业务 | 确认本次版本的核心业务路径和不可省略的验证点 | 核心链路清单 |
| 人工复核 | 测试工程师 | 补充跨模块组合、历史高发缺陷、新边界场景，记录理由 | 复核记录、最终回归集 |
| 用例库维护 | 用例库维护人 | 执行后回写结果，补充漏测用例，调整冗余用例 | 更新后的用例库与维护记录 |
开发提供影响说明的时点应早于测试开始筛选，通常在提测前完成；测试负责人的分级评审可以在提测当天进行；用例库维护则贯穿版本周期，在执行结束后集中更新一次。角色可以由同一人兼任，但交付物不能省略，否则后续版本无法追溯本次选例的依据。
一个版本迭代的回归选例示例
以下为演示情景，用于说明流程如何落地，不代表真实项目数据。
示例背景
某版本对订单查询接口做了字段调整：返回结果中新增“预计送达时间”字段，同时修改了公共的日期格式化组件。需求方希望用户在下单后能看到预计送达时间。
影响范围识别结果
- 直接改动模块：订单查询服务。
- 上游调用方：订单列表页、订单详情页、客服工作台。
- 下游依赖：物流服务提供的时效数据接口。
- 共享组件：日期格式化组件，被订单、售后、报表等多个模块引用。
- 数据对象：订单主表、物流时效表。
风险分级与用例选取
订单查询属于核心交易链路，日期格式化组件为公共组件，两项高风险信号同时满足，定为高风险，订单查询模块用例全量执行。客服工作台和报表模块因引用公共组件，定为中风险，执行主流程和日期显示相关的边界用例。物流时效接口为新增依赖，补充接口异常和超时场景的用例。核心链路用例和冒烟用例固定保留。
执行后的漏测与调整
执行中发现，客服工作台在时区切换场景下日期显示异常，而原有用例只覆盖了默认时区。该场景被补充为新用例，并关联到日期格式化组件。同时发现报表模块有部分用例长期未发现缺陷、与本次变更关联度低，将其优先级下调，减少后续回归的执行量。复核记录中写明了补充理由和降级依据，用例库同步更新。
执行后的用例集维护与完成检查
回归集需要随版本持续调整。一次选例的结果如果只停留在执行记录里，下个版本又要从头判断，效率不会提升。维护的重点是把执行中暴露的信息沉淀回用例库。
漏测与冗余的处理
- 漏测用例回补：线上或测试后期发现、但本次回归集未覆盖的问题，补充为用例并关联对应模块、接口和缺陷，标注发现版本。
- 冗余用例降级或剔除：长期执行且未发现缺陷、与当前业务关联减弱的用例，可下调优先级或移出常规回归集，保留在库中备查。剔除前确认其覆盖的场景已被其他用例替代。
- 失效用例更新：因需求变更导致步骤或预期结果不再适用的用例，及时修订或标记废弃，避免误导后续筛选。
用例库字段的持续维护
筛选效率取决于字段质量。每次版本结束后，检查新增用例是否填写了需求编号、模块、接口、数据表、关联缺陷等字段；公共组件的引用关系是否随代码调整同步更新；自定义属性是否仍能覆盖当前业务分类。字段维护可以和用例评审合并进行，减少额外工作量。
完成检查清单
- 影响范围清单中的每个变更点都已标注模块、接口、数据对象和风险等级。
- 高风险模块已全量覆盖，中风险模块已覆盖主流程与边界，低风险模块已完成抽检。
- 核心链路用例和冒烟用例已保留在本次回归集中。
- 人工复核记录完整，补充用例均写明理由和确认人。
- 执行结果已回写用例库，漏测用例已补充，冗余用例已调整。
- 用例库关联字段已更新，下个版本可直接按字段筛选。
六项全部满足，可以认为本次回归选例工作完成。若某项缺失，应在版本复盘时明确补齐责任人和时间点，避免问题累积到下一个版本。
常见问题
变更很小，比如只改了一个接口字段，还需要走完整的影响分析吗？
建议保留影响分析的步骤，但可以按变更规模缩减投入。字段调整这类改动，重点确认三件事：上游调用方是否依赖原字段结构、下游数据来源是否同步变化、是否引用了公共组件。如果改动只涉及单个模块且无公共组件引用，影响范围清单可以只写一行，风险等级定为低，抽检代表性用例即可。跳过影响分析的风险在于调用方和数据共享往往不在改动文件里，容易在执行后期才暴露。
用例库字段不全，历史用例没有关联需求编号和接口，怎么开始筛选？
可以先用模块字段做第一轮初筛，把影响范围内的模块用例全部拉出来，再靠人工判断取舍。同时启动字段补录：优先给核心链路和高缺陷密度模块的用例补上需求编号、接口、数据表字段，按模块分批推进，不必一次补全。补录工作可以和用例评审合并，在评审时顺手补齐。字段完整度提升后，后续版本的初筛命中率会逐步提高。
回归集应该每个版本重新选，还是维护一个固定的回归用例集？
两种做法可以结合。核心链路用例和冒烟用例构成固定基线，每次回归都执行，不随版本调整；其余用例按本次变更的影响范围和风险分级动态选取。固定基线保证主流程始终被验证，动态部分控制执行量。如果团队版本节奏快、变更集中，动态选取的比例可以高一些；如果系统稳定、变更零散，固定基线的占比可以更大。
人工复核由谁做比较合适，复核记录要写到什么程度？
复核通常由熟悉该业务模块的测试工程师执行，测试负责人确认最终回归集。复核记录至少写清三项：补充或调整了哪些用例、理由是什么、由谁确认。理由要具体到场景，例如“客服工作台时区切换场景原用例未覆盖”，而不是笼统写“补充边界用例”。这份记录在版本复盘和用例库维护时都要用到，写得含糊后续无法追溯。
用 ONES 做回归选例，哪些环节能直接支撑，哪些仍需人工判断？
ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联；用例库中所有用例属性都支持筛选，并支持自定义用例属性，可以把模块、接口、数据表等关联信息设为字段，按影响范围做初筛；用例模块支持树状结构和拖拽排序，便于按业务域组织。风险分级判断、跨模块组合场景的补充、历史高发缺陷的取舍仍需人工完成。字段维护得越完整，初筛结果越接近最终回归集。
