回归用例集分层维护要解决的是用例越积越多、每次回归却难以判断该跑哪些的问题。做法是把每条用例放到变更影响、业务关键度、历史缺陷分布三个可核对的坐标上，合成L1核心必跑、L2重点抽跑、L3常规抽跑、L4低频观察四个层级，并把结果写进用例属性字段，随需求变更、缺陷关闭和版本复盘持续刷新。
要点总览（TL;DR）
- 回归用例集分层维护把每条用例放到变更影响、业务关键度、历史缺陷分布三个坐标上，合成L1核心必跑、L2重点抽跑、L3常规抽跑、L4低频观察四个层级。
- 三个因子各自取高、中、低，按固定判定表合成层级；边界规则提前写入分层规则文档，避免不同人定级标准不一。
- 分层结果写入用例属性字段，随需求变更、缺陷关闭、版本发布和季度复盘增量刷新，季度做一次全量校准。
- 测试负责人定规则与比例目标，用例Owner维护属性与覆盖关系，模块测试同学提供变更与缺陷数据，评审角色处理升降层争议。
- 完成检查看五项：属性完整率、层级分布、刷新记录、升降层可追溯、分层结果被回归执行实际使用。
三层划分依据怎么落到用例属性上
三个依据要真正可用，前提是每条用例都能被单独查询和批量修改。建议先在用例库中补齐一组固定属性，再按统一口径打分。属性字段至少包括：所属模块、覆盖需求或接口、变更影响等级、业务关键度等级、近12个月缺陷数、缺陷密度等级、综合层级、分层依据说明、最近刷新时间、刷新触发来源。
变更影响：从变更记录反查用例覆盖关系
变更影响衡量的是用例覆盖对象在近期是否被改动。可观测信号有三类：需求变更单涉及的功能点、模块代码或配置的提交记录、接口契约的变更记录。取值方式建议按观察窗口统计，例如近3个版本或近90天内被触及的次数，记为高（直接改动核心逻辑或接口）、中（改动关联模块或依赖配置）、低（窗口内无变更）。
落地时先建立覆盖关系：每条用例标注它验证的需求编号、模块路径和接口名。需求或接口发生变更时，通过覆盖关系反查受影响的用例，把变更影响等级调高；窗口内未被触及的用例按规则降档。覆盖关系缺失的用例先补标，再参与打分，否则变更影响因子会失真。
业务关键度：按用户路径、收入与合规影响分级
业务关键度判断的是用例失效时对用户和业务的实际损害，避免凭印象定级。建议分三档：高，对应主流程必经路径、直接产生收入或涉及资金与合规校验的场景，例如下单、支付、退款、发票开具；中，对应次要路径、影响部分用户或可降级处理的场景；低，对应边缘配置、展示性内容或内部辅助功能。
定级时要求写出依据，例如“支付回调失败将导致订单状态不一致，影响收入确认”，而不是只填一个“高”。同一业务域内由模块测试同学提出、测试负责人校准，减少不同人标准不一。
历史缺陷分布：按模块与场景统计缺陷密度
历史缺陷分布反映哪里曾经出问题。统计口径建议统一为：观察窗口取近6至12个月，按模块和业务场景两个维度统计缺陷数，再除以该范围的用例数或用例执行次数，得到缺陷密度。密度明显高于同类模块的，标记为高；处于平均水平的标记为中；长期无缺陷的标记为低。
统计时区分缺陷严重级别，避免把大量界面文案类缺陷与阻断性缺陷混在一起。对已关闭但根因未消除的缺陷，保留在统计中并在备注中说明，防止模块因短期修复而被误降档。
三因子合成层级
三个因子分别取高、中、低后，按下表合成层级。阈值可按团队用例规模校准，但规则要固定并写入分层规则文档。
| 变更影响 | 业务关键度 | 历史缺陷密度 | 合成层级 | 回归策略 |
|---|---|---|---|---|
| 高 | 高 | 任意 | L1 | 每次回归必跑 |
| 高 | 中 | 高 | L1 | 每次回归必跑 |
| 中 | 高 | 高 | L1 | 每次回归必跑 |
| 高 | 中 | 中或低 | L2 | 重点版本必跑，常规版本抽跑 |
| 中 | 高 | 中或低 | L2 | 重点版本必跑，常规版本抽跑 |
| 低 | 高 | 高 | L2 | 重点版本必跑，常规版本抽跑 |
| 中 | 中 | 任意 | L3 | 按比例抽跑 |
| 低 | 中 | 中 | L3 | 按比例抽跑 |
| 低 | 低 | 任意 | L4 | 低频观察，季度或大版本抽检 |
| 低 | 中 | 低 | L4 | 低频观察，季度或大版本抽检 |
边界规则需要提前约定：任一因子为高且另一因子不低于中时进入L1；两个因子为中或单个因子为高时进入L2；其余按中低组合区分L3与L4。合成结果写入“综合层级”字段，同时在“分层依据说明”中记录三个因子的取值，保证后续可复核、可解释。
分层维护的操作步骤与刷新节奏
分层是一次建规则、长期维护的机制。首次建层解决“有没有”，日常刷新解决“准不准”。两者都要有明确的输入、动作、输出和完成标志。
首次建层
- 盘点用例：按模块导出全量用例清单，标记无覆盖关系、长期未执行、重复描述的用例，先做合并或废弃处理。
- 补属性：为保留用例补齐模块、覆盖需求或接口、业务关键度初值等字段。
- 打分：模块测试同学按统一口径填写变更影响与缺陷密度，用例Owner核对覆盖关系。
- 定层：按判定表合成L1至L4，测试负责人抽查各层级样本，校准明显偏差。
- 评审发布：评审分层规则、层级比例和争议用例，发布分层规则文档与用例属性表。
完成标志是：全量在用用例均具备综合层级字段，争议用例有结论记录，分层规则文档完成评审。
日常刷新触发条件
| 触发条件 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 需求变更或接口变更 | 变更单、覆盖关系 | 反查受影响用例，调整变更影响等级并重算层级 | 更新后的用例属性 | 受影响用例全部完成重算 |
| 缺陷关闭 | 缺陷记录、模块归属 | 更新缺陷密度统计，必要时上调相关用例层级 | 缺陷分布统计与层级变更记录 | 统计窗口内数据已刷新 |
| 版本发布 | 本版本变更清单、回归结果 | 复盘漏测与误判，调整因子取值 | 版本复盘记录 | 复盘结论落实到属性字段 |
| 季度复盘 | 季度缺陷数据、执行记录 | 整体校准层级比例，处理积压的升降层申请 | 季度分层报告 | 报告评审通过 |
刷新节奏不必所有用例同步进行，按触发条件做增量更新即可，季度复盘做一次全量校准。
升降层规则与审批
层级要能升也能降。建议规定：升层需提供变更记录、缺陷记录或业务影响说明，由测试负责人审批；降层需连续两个观察窗口无相关缺陷且无变更触及，由用例Owner提出、测试负责人审批。每次升降层在属性中保留变更时间和原因，避免层级只升不降导致L1不断膨胀。
用例新增时按同一判定表首次定层；用例合并时取合并前各用例的最高层级并重新打分；用例废弃时移出在用集合，保留历史记录以便追溯。分层结果需要被回归执行直接取用，属性字段就要支持按层级筛选。ONES用例库支持自定义用例属性，且所有用例属性都支持筛选，可以把综合层级、变更影响等字段配置为可筛选属性，回归时按层级快速圈定执行范围；用例与需求、任务的关联也有助于在需求变更时反查覆盖用例。
角色分工与各环节交付物
分层维护涉及规则制定、数据提供、结果使用三类工作，角色不清会出现“有人打分、没人复核”的情况。下表给出建议分工，团队规模较小时可一人兼多角，但职责要分开记录。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 测试负责人 | 定义三因子口径与判定表，设定L1至L4比例目标，审批升降层 | 分层规则文档、层级比例目标、审批记录 |
| 用例Owner | 维护用例属性与覆盖关系，提出升降层申请，处理用例合并与废弃 | 用例属性表、覆盖关系清单、变更申请 |
| 模块测试同学 | 提供变更影响判断与缺陷分布数据，参与首次打分 | 模块变更清单、缺陷密度统计、打分记录 |
| 评审角色 | 处理升降层争议，抽查层级合理性 | 评审结论、争议处理记录 |
| 回归执行人 | 按层级选取用例执行，反馈漏测与误判 | 回归执行记录、分层有效性反馈 |
交付物要集中存放并可追溯：分层规则文档记录口径与判定表，用例属性表随用例库同步更新，刷新记录按触发条件逐条登记。三者构成分层体系的可审计基础。
示例：一个订单模块的用例分层
以下为演示情景，数据用于说明方法，实际使用时替换为团队真实统计。
假设订单模块共有120条回归用例，观察窗口为近6个月。变更影响方面，下单流程与支付回调接口在本季度有改动，相关用例记为高；订单查询与列表展示无改动，记为低；优惠券叠加规则有配置调整，记为中。业务关键度方面，下单、支付、退款路径记为高，订单查询与导出记为中，内部备注与展示样式记为低。历史缺陷分布方面，支付回调与退款状态同步近6个月缺陷密度最高，记为高；下单校验为中；展示类为低。
| 用例组 | 数量 | 变更影响 | 业务关键度 | 缺陷密度 | 层级 | 回归策略 |
|---|---|---|---|---|---|---|
| 下单主流程 | 18 | 高 | 高 | 中 | L1 | 每次必跑 |
| 支付回调与状态同步 | 15 | 高 | 高 | 高 | L1 | 每次必跑 |
| 退款申请与审核 | 14 | 中 | 高 | 高 | L1 | 每次必跑 |
| 优惠券叠加规则 | 16 | 中 | 中 | 中 | L3 | 按比例抽跑 |
| 订单查询与导出 | 22 | 低 | 中 | 低 | L4 | 季度抽检 |
| 订单列表展示 | 20 | 低 | 低 | 低 | L4 | 季度抽检 |
| 内部备注与样式 | 15 | 低 | 低 | 低 | L4 | 季度抽检 |
合成后L1共47条，约占39%；L3共16条，约占13%；L4共57条，约占48%。常规版本回归执行L1全量加L3抽跑30%，约52条；重点版本追加L2与L4抽检。这个比例说明该模块当前变更集中在交易链路，展示类用例可以低频维护。若后续订单查询出现线上缺陷，缺陷密度上调后相关用例会升入L2或L1，回归范围随之扩大。
分层维护的完成检查
分层体系是否建立并可持续运行，可用以下清单逐项核对。建议每季度复盘时完整走一遍，日常刷新时抽查其中相关项。
- 用例属性完整率：在用用例的综合层级、变更影响、业务关键度、缺陷密度字段填写率达到100%，覆盖关系缺失用例已单独列出并处理。
- 层级分布合理性：L1占比处于团队设定区间，通常不宜超过总量的40%；若L1持续膨胀，检查升层审批是否失效或业务关键度定级过宽。
- 刷新记录：需求变更、缺陷关闭、版本发布、季度复盘四类触发条件均有对应刷新记录，记录中包含时间、触发来源、变更用例数和操作人。
- 升降层可追溯：每次层级变更都有原因说明和审批记录，降层用例满足观察窗口要求。
- 结果被实际使用：回归执行记录中能按层级统计执行覆盖率，L1执行率应为100%，抽跑比例与计划一致。
- 有效性反馈：版本复盘中对漏测用例做归因，确认是否因分层偏低导致漏跑，并将结论回写到属性字段。
清单全部满足，说明分层已经从一次性标注转为可维护的机制；若多项不满足，优先修复属性完整率和刷新记录，再校准层级比例。
常见问题
团队用例规模较小，三因子打分会不会太重？
可以简化，但三个因子都要保留。规模小时，变更影响直接按“近一个版本是否被改动”取高或低，业务关键度只分高、低两档，缺陷密度按模块整体统计而不细分场景。判定表相应缩减为几条主要组合，规则仍然固定并记录在分层规则文档中。等用例数量增长、变更频率提高后，再补充观察窗口和中间档位。
L1占比持续上升，怎么判断是业务变复杂还是分层失效？
先看升层记录：如果大量升层缺少变更记录或缺陷记录支撑，说明审批环节失效；如果升层都有据可查，再看业务关键度定级是否过宽，把“影响部分用户”的场景误定为高。处理方式是收紧升层审批、复核高关键度用例的依据说明，并对连续两个观察窗口无缺陷且无变更触及的用例启动降层。L1占比通常不宜超过总量的40%，超出时优先排查这两类原因。
需求变更频繁时，每次都要全量重算层级吗？
不需要。按触发条件做增量更新：需求或接口变更时，通过用例与需求的覆盖关系反查受影响用例，只重算这部分；缺陷关闭时更新对应模块的缺陷密度并调整相关用例；版本发布后复盘漏测与误判；季度复盘再做一次全量校准。增量更新的前提是覆盖关系完整，覆盖关系缺失的用例要先补标，否则反查会漏掉受影响范围。
分层结果怎么保证回归执行时真的被用上？
关键是分层字段要能被筛选和统计。把综合层级配置为用例属性，回归执行时按层级圈定范围，执行记录中保留层级信息，事后就能统计L1执行率和各层级抽跑比例是否符合计划。若分层结果只存在于文档或表格中，执行时仍靠人工挑选用例，分层就退化成一次性标注。ONES用例库支持自定义用例属性，且所有用例属性都支持筛选，可以把综合层级配置为可筛选属性，回归时按层级快速取用。
漏测发生后，应该改分层规则还是只调用例层级？
先做归因再决定。如果漏测用例的分层本身偏低，且其变更影响或缺陷密度数据在漏测前已具备上调条件，属于个案误判，调整该用例层级并记录原因即可；如果同类漏测反复出现，说明判定表或因子口径有系统性偏差，例如业务关键度定级过宽或缺陷统计窗口太短，这时修改分层规则文档并重新校准相关用例。两种情况都要把结论回写到属性字段，作为下次复盘的输入。
