回归测试用例维护：优先级、冗余与更新

说实话，很多团队刚开始搞回归测试时，都觉得“用例库嘛，越多越好”。结果呢？跑一次回归要三天三夜，报出来的失败一半是过时的、重复的、或者压根不该跑的。我见过一个项目，回归用例从200条膨胀到2000条，覆盖率反而下降了——因为没人清理。

这一章咱们就聊聊，怎么让回归用例库保持“小而精”。核心就是三个动作：定优先级、查冗余、勤更新。

一、用例优先级划分

回归用例那么多，不可能全跑一遍。你需要给每一条用例贴个标签：P0、P1、P2。我在团队里推行过一套规则，效果还不错。

优先级的确定不是拍脑袋。我建议用“业务影响×使用频率”矩阵来打分。举个例子：

• 用户登录：影响面极大，频率极高 → P0
• 用户修改头像：影响小，频率低 → P2
• 忘记密码流程：影响中等，频率中等 → P1

二、识别并消除冗余用例

你想想看，需求迭代了十轮，用例库里的case可能还写着N年前的逻辑。冗余表现在几个方面：

• 重复覆盖：两个不同用例测的是同一个功能点
• 等价合并：用一条等价类用例能覆盖五条边界用例
• 已废弃功能：旧模块下线了，用例还在
• 细碎场景：一个接口参数不同组合，你写了20个case，其实5个就够了

我曾经在一个老项目里发现了47条完全相同的登录用例——只是UI自动化的xpath写法不同。这种冗余不仅浪费时间，还会让新人摸不着头脑。怎么清理？

1. 先跑一次全量回归，记录每条用例的执行时间
2. 用“功能标签”聚类，找出同一模块内功能重合的用例
3. 对比用例步骤和断言，保留最精炼的一条
4. 删除重复项，并更新关联的测试套件

三、用例的持续更新

需求变了，用例不变？那回归测试就失去了意义。用例维护不是一个“一次性”动作，而是一个持续的过程。我把它分成三种更新场景：

说白了，用例更新要跟开发流程绑定。我习惯在CI/CD的每个阶段加一个“用例健康检查”节点：

• MR合并前：跑增量用例，检查新老用例的覆盖率变化
• 每日构建：跑P0+P1，报告超时或失败的用例
• 每个发布版：审计用例库里的“最后执行日期”超过30天的用例，打上待审核标签

四、维护工作的自动化实践

手动维护？不现实。团队上百条用例，靠人肉记得住才怪。我推荐几个自动化手段：

# scan_stale_cases.py
from datetime import datetime, timedelta
import json

stale_threshold = datetime.now() - timedelta(days=30)
stale_cases = []
with open('regression_suite.json', 'r') as f:
    suite = json.load(f)
for case in suite['cases']:
    last_run = datetime.fromisoformat(case['last_executed'])
    if last_run < stale_threshold:
        stale_cases.append(case['id'])
print(f"发现 {len(stale_cases)} 条过期用例，建议review")
# 输出：发现 3 条过期用例，建议review

这个脚本简单吧？但很管用。我让它每周一早上自动跑一次，把结果发到群里。负责人一看，哦，我这周得看看这3条要不要删。久而久之，用例库就干净了。

另外，我建议在测试管理平台上做标签化。比如给每条用例打上“模块-优先级-版本号”的标签，方便批量筛选。举个例子：

# 在TestRail或Xray中定义元数据
case_001:
  tags: ["pay", "P0", "v3.2"]
  precondition: "用户已登录，金额大于0"
  steps: "1. 点击支付\n2. 选择微信支付\n3. 支付成功弹窗"
  expected: "余额扣减，订单状态为已支付"

版本号标签特别好使——当某个功能被重构时，我直接查所有带旧版本号的用例，批量review。嗯，这里要注意：更新用例后记得同步修改标签版本号，不然下回就查不到了。

五、我的避坑经验

讲几个我踩过的坑，希望对你有用。

• 坑一：只管加不管删。结果回归时间膨胀到8小时，CI pipeline崩溃。后来我设了一个规则：每新增一条P0用例，必须删掉一条P2用例（或者确认它仍然必要）。
• 坑二：优先级只定一次。项目跑了一年，优先级没有任何变动。怎么可能？新功能上线后，旧功能的使用频率会下降。我建议每个季度做一次全量重评。
• 坑三：冗余清理只看代码不看业务。我有个同事把所有登录相关的用例合并成了一条“一键登录”，结果呢，忘了考虑多语言、多账户类型的组合。合并后还是得拆。所以合并时一定要问自己：这条用例是否覆盖了所有业务分支？