回归用例集分层维护要解决的是“每次回归该跑哪些用例、长期按什么优先级维护”的问题。做法是把变更影响、业务关键度和历史缺陷分布三个依据分开使用：变更影响圈定本轮必跑范围，业务关键度决定用例的长期层级，历史缺陷分布校正层级并提示补充用例。三层规则落到用例字段和固定评审节奏上，用例集才能随版本持续可执行。
要点总览（TL;DR）
- 三个依据分工明确：变更影响圈定本轮必跑范围，业务关键度决定用例的长期层级，历史缺陷分布用于升降级校正和补充用例。
- 层级建议分为核心层、常规层、观察层，各层对应不同的执行频率与维护责任；业务关键度决定层级下限，历史缺陷分布只能在相邻层级间调整一次。
- 分层维护要落到用例字段上，包括变更关联模块、业务关键度、历史缺陷密度、当前层级和最近执行结果，并约定升降级与退役的触发条件。
- 层级评审建议每季度一次，大版本前增加临时评审；完成检查覆盖字段完整性、层级分布、变更覆盖率和历史缺陷回填，并明确阻断项。
三层依据如何合成一套分层规则
三个依据回答的是不同问题，不能简单相加成一个分数。变更影响回答“本轮跑什么”，它随版本变化，决定的是执行范围；业务关键度回答“长期优先维护什么”，相对稳定，决定用例的层级基线；历史缺陷分布回答“哪些地方风险被低估或高估”，用于对基线做升降级校正。合成顺序建议是：先按业务关键度定层级，再用历史缺陷分布校正层级，最后用变更影响圈定本轮执行范围。
层级建议划分为三层，各层承担不同的维护强度：
- 核心层：业务关键度高、失效后果严重的用例。每个版本全量执行，由模块负责人直接维护，用例变更需评审。
- 常规层：业务关键度中等或关键度一般但缺陷历史较多的用例。按版本或按迭代轮换执行，由模块负责人维护，测试负责人抽查。
- 观察层：业务关键度低、长期无缺陷的用例。按季度或大版本执行，由用例编写人维护，评审时决定保留、合并或退役。
三个依据冲突时按主次处理：业务关键度决定层级下限，核心业务用例不因近期无缺陷而降出核心层；历史缺陷分布只能在相邻层级间做一次升降，不能把观察层用例直接提为核心层；变更影响只扩大本轮执行范围，不改变用例的长期层级。下表给出可直接套用的判定规则。
| 业务关键度 | 历史缺陷分布 | 层级基线 | 合成后层级 | 执行频率 |
|---|---|---|---|---|
| 高 | 高频或严重缺陷 | 核心层 | 核心层 | 每版本全量 |
| 高 | 低频、无严重缺陷 | 核心层 | 核心层 | 每版本全量 |
| 中 | 高频或严重缺陷 | 常规层 | 核心层（上调一级） | 每版本全量 |
| 中 | 低频、无严重缺陷 | 常规层 | 常规层 | 按版本轮换 |
| 低 | 高频或严重缺陷 | 观察层 | 常规层（上调一级） | 按版本轮换 |
| 低 | 长期无缺陷 | 观察层 | 观察层 | 按季度或大版本 |
变更影响不进入上表的层级结果，而是叠加在执行范围上：本轮变更涉及的模块，其核心层和常规层用例全部纳入执行，观察层用例按变更关联度选择性纳入。这样层级保持稳定，执行范围随版本浮动。
分层维护的操作步骤与字段设计
分层规则要能运转，前提是每个判断依据都能在用例上找到对应字段。建议先在用例库建立以下基线字段，再按步骤执行维护动作。
| 字段 | 取值示例 | 维护人 | 用途 |
|---|---|---|---|
| 变更关联模块 | 订单结算、优惠券核销 | 模块负责人 | 圈定本轮回归范围 |
| 业务关键度 | 高 / 中 / 低 | 测试负责人与业务方确认 | 确定层级基线 |
| 历史缺陷密度 | 近12个月缺陷数、是否含严重缺陷 | 模块负责人回填 | 层级校正 |
| 当前层级 | 核心层 / 常规层 / 观察层 | 层级评审会确认 | 执行频率依据 |
| 最近执行结果 | 通过 / 失败 / 未执行及版本号 | 执行人自动或手动更新 | 发现长期未执行用例 |
字段建立后，按以下步骤完成一轮分层维护：
- 圈定本轮回归范围。输入是本版本变更清单和需求关联关系，动作是把变更涉及的模块与用例的“变更关联模块”字段比对，输出是本轮必跑用例清单，完成标志是清单经开发负责人确认无遗漏模块。
- 分配层级与执行频率。输入是业务关键度字段，动作是按判定表确定层级基线，输出是每个用例的当前层级，完成标志是核心层用例全部有明确责任人。
- 按历史缺陷分布校正。输入是近12个月缺陷记录，动作是统计各模块缺陷密度和严重缺陷情况，对判定表中需要上调或下调的用例调整层级，输出是校正后的层级清单，完成标志是每次调整都有缺陷数据作为依据记录在案。
- 补充缺失用例。对缺陷密度高但用例覆盖薄的模块，补充针对缺陷场景的回归用例，输出是新增用例及其层级归属，完成标志是新增用例通过评审并入层。
- 执行升降级与退役评审。触发条件事先约定：连续三个版本执行通过且无缺陷、变更影响低的常规层用例可降为观察层；核心模块出现高频或严重缺陷时，相关用例上调一级；观察层用例连续两个评审周期未执行且无关联缺陷，进入退役候选。
这些字段和层级状态需要有承载的地方。ONES 测试管理支持自定义用例属性，可以把业务关键度、历史缺陷密度、当前层级作为用例字段维护；用例库支持树状结构组织模块，所有用例属性支持筛选，便于按层级和模块快速拉出本轮回归清单；用例可与需求、任务关联，测试计划与迭代关联，使变更影响评估有需求侧输入。项目缺陷分布统计可作为历史缺陷回填的参考数据。具体字段配置和统计口径以实际产品配置为准。
角色分工与各环节交付物
分层维护涉及四类角色，各自对不同的字段和决策负责，避免出现“字段有人建、没人维护”的情况。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 测试负责人 | 制定分层规则与评审节奏，确认业务关键度口径，对回归范围最终负责 | 分层规则说明、层级评审记录、本轮回归范围确认单 |
| 模块负责人 | 维护所辖模块用例的变更关联模块、历史缺陷密度字段，提出升降级建议 | 模块用例清单、缺陷回填记录、升降级申请 |
| 开发负责人 | 提供变更影响评估输入，确认变更涉及模块和影响面 | 变更影响说明、回归范围确认意见 |
| 质量评审角色 | 参与层级评审，核对调整依据，抽查字段完整性 | 评审结论、检查问题清单 |
变更影响评估的输入来源包括版本变更清单、需求与任务的关联关系、开发负责人的影响面说明，责任人是开发负责人，模块负责人负责把影响面映射到用例字段。层级评审会建议每季度一次，大版本发布前增加一次临时评审，参与角色为测试负责人、模块负责人和质量评审角色，输出是层级调整记录和退役用例清单。日常维护中，用例维护由模块负责人负责，缺陷回填在缺陷关闭时完成，层级调整只在评审会上生效，避免个人随意改动。
示例：一个模块的回归用例分层维护过程
以一个电商系统的“订单结算”模块为例说明。该版本变更内容是新增分期支付方式并调整优惠券叠加规则，变更影响集中在结算页和优惠计算逻辑。业务关键度判断为高：结算失败直接影响成交。历史缺陷方面，近12个月该模块缺陷数在全部模块中排前两位，其中两起为金额计算错误，属于严重缺陷。
按规则处理：结算主流程、优惠计算、支付方式选择等用例业务关键度为高，层级定为核心层，每版本全量执行；优惠券叠加边界用例业务关键度为中，但历史缺陷密度高，按判定表上调为核心层；发票信息展示等用例业务关键度为低且长期无缺陷，留在观察层，本轮因变更不涉及发票，不纳入执行范围。本轮回归范围为核心层全部用例加观察层中与支付方式相关的两条用例。
版本发布后，优惠券叠加相关用例发现一处缺陷，模块负责人回填缺陷记录并建议保持核心层；发票模块连续三个版本无缺陷，评审会上将其两条常规层用例降为观察层。同时，针对本次金额计算缺陷补充了一条“分期手续费与优惠叠加”的回归用例，业务关键度定为高，直接进入核心层。这个示例体现的取舍是：变更影响决定本轮跑什么，业务关键度决定层级下限，历史缺陷分布既用于上调也用于补充用例，三者各司其职。
完成检查：分层维护是否到位
分层维护是否真正运转，可以用以下清单逐项核对。检查建议每季度随层级评审同步执行，由测试负责人组织，质量评审角色抽查。
| 检查项 | 通过标准 | 证据要求 |
|---|---|---|
| 字段完整性 | 核心层和常规层用例的业务关键度、当前层级、变更关联模块字段填写率100% | 字段填写统计截图或导出清单 |
| 层级分布合理性 | 核心层用例占比与业务关键模块占比大致匹配，无某模块全部用例集中在核心层的情况 | 层级分布统计表 |
| 变更覆盖率 | 本版本变更涉及模块的核心层用例执行率100%，常规层执行率不低于约定比例 | 测试计划执行记录 |
| 历史缺陷回填 | 近一个季度关闭的缺陷均已回填到对应用例或模块 | 缺陷回填记录与缺陷列表比对 |
| 层级调整记录 | 每次升降级均有评审记录和数据依据 | 层级评审会议记录 |
以下情况视为阻断项，需要在下一次评审前整改：核心层用例连续两个版本未执行；历史缺陷连续一个季度未回填；层级超过两个评审周期未做任何调整且无调整说明；观察层用例占比过高导致回归范围实际只覆盖核心层。检查发现的问题应指定责任人和整改期限，整改结果在下次评审会上复核。
常见问题
业务关键度高的用例，是否可能因为长期没有缺陷而降到常规层？
不建议。业务关键度决定的是层级下限，核心业务用例即使近期没有缺陷，也应留在核心层每版本执行。历史缺陷分布的作用是在基线之上做风险校正，它可以推动中低关键度用例上调，也可以作为观察层用例退役的依据，但不应把高关键度用例降出核心层。如果确实要调整，需要业务方参与确认失效后果已经变化，并在评审记录中写明依据。
历史缺陷数据应该统计多长的时间窗口？新模块没有历史数据怎么办？
常见做法是取近12个月，既能覆盖多数版本的缺陷规律，又不至于把早已重构的旧问题带入判断。窗口长度应在分层规则中事先约定，各模块统一口径。新模块或新业务线没有历史缺陷数据时，先按业务关键度确定层级基线，历史缺陷密度字段标记为“暂无数据”，在积累一到两个版本的缺陷记录后再参与校正。这段时间内可以适当提高执行频率作为过渡。
变更影响评估由谁提供输入，测试团队如何确认没有遗漏模块？
变更影响评估的输入通常来自版本变更清单、需求与任务的关联关系，以及开发负责人对影响面的说明，责任人是开发负责人。测试侧由模块负责人把影响面映射到用例的变更关联模块字段，形成本轮必跑清单后交开发负责人确认。确认环节重点核对两类遗漏：变更涉及的公共组件是否影响其他模块，以及配置或数据变更是否波及未改动的功能。确认意见应留档，作为回归范围的责任依据。
观察层用例长期不执行，如何判断该保留还是退役？
退役判断建议同时看三个条件：连续两个评审周期未执行、期间没有关联缺陷、业务关键度没有上升。三个条件都满足时进入退役候选，由层级评审会确认后移出回归集，用例本身可以归档保留，便于后续追溯。如果只是执行频率低但业务上仍可能触发，可以保留在观察层并注明触发条件，例如仅在相关模块变更时执行。退役不是删除，归档记录要能查到原有用例内容。
分层维护的字段和评审记录放在哪里维护比较合适？
字段应尽量放在用例库本身，避免另建表格造成两份数据。ONES 测试管理支持自定义用例属性，可以把业务关键度、历史缺陷密度、当前层级作为用例字段维护；用例库支持树状结构组织模块，用例属性支持筛选，便于按层级和模块拉出回归清单；用例可与需求、任务关联，测试计划与迭代关联，为变更影响评估提供需求侧输入。评审记录可以放在对应的迭代或项目文档中，与层级调整记录保持一致。具体字段配置以实际产品配置为准。
