4. 回归测试用例库设计与维护

多制式无线终端（例如同时支持 LTE、NR、WCDMA、GSM 的终端）的回归测试，最大的挑战不是“测什么”，而是“在有限时间内先测什么、哪些用例可以长期复用、用例本身如何随版本演进”。本节围绕三个问题展开：如何基于风险与变更影响确定用例优先级，如何建立可复用的多制式回归用例集，以及如何对用例做版本管理。

一、为什么优先级不能只按“功能重要性”排

很多团队排优先级时习惯按功能模块的重要性打分，例如“通话最重要，所以通话用例全部 P0”。但在回归测试中，真正决定优先级的因素有两个维度：失效风险（该功能出问题的可能性）和失效影响（出问题后的后果严重度）。风险 = 可能性 × 影响，二者缺一不可。

以一次典型的终端软件版本为例：本版本主要修改了 NR 侧的 RRC 重配流程和双连接（EN-DC）下的承载管理，同时更新了基带固件。此时：

• NR RRC 重配、EN-DC 辅节点添加/修改/释放相关用例，失效可能性高（直接改动），影响大（连接中断、掉话），应列为最高优先级。
• LTE 侧未改动，但 EN-DC 依赖 LTE 锚点，LTE 锚点侧的测量、切换用例属于“被间接影响”，可能性中等，影响大，列为次高优先级。
• GSM/WCDMA 未改动且与本次改动无耦合，可能性低，列为低优先级，可在冒烟通过后抽样执行。

这里的关键是“变更影响分析”：不能只看代码 diff 落在哪个模块，还要看模块之间的依赖链。基带固件更新往往影响所有制式的物理层行为，因此即使上层协议栈没改，也应把各制式的物理层关键用例（如小区搜索、随机接入、功率控制）纳入高优先级抽样。

二、用“风险矩阵 + 变更影响”确定优先级

实践中可以把两个维度合成一个可操作的评分。下面给出一个可直接使用的评分表（示例参数，非实测数据）：

总分 = 可能性 + 影响 + 缺陷密度，范围 3～9。总分 8～9 为 P0，6～7 为 P1，4～5 为 P2，3 为 P3。P0 用例必须在每次回归中全量执行；P1 在冒烟通过后执行；P2 按抽样比例执行；P3 在版本稳定后或专项回归中执行。这样优先级不是拍脑袋，而是可追溯、可复算的。

三、建立可复用的多制式回归用例集

可复用不等于“把所有用例堆在一起”。多制式终端的回归用例集应按“公共能力 + 制式专属 + 互操作”三层组织：

• 公共能力层：与制式无关的通用能力，如开机驻网、SIM 管理、APN 配置、数据连接建立、功耗与热管理、异常恢复（飞行模式切换、重启后重驻网）。这一层用例在所有制式间复用，是冒烟集的核心。
• 制式专属层：LTE 的切换、重定向、载波聚合；NR 的 RRC 状态迁移、波束管理、SA/NSA 切换；WCDMA 的软切换、压缩模式；GSM 的频点扫描、GPRS 附着。这一层按制式独立维护，但用例模板、前置条件、判定标准保持统一。
• 互操作层：跨制式移动性，如 NR→LTE 重定向、LTE→NR 切换、EN-DC 下辅节点释放后锚点保持、CSFB 回落与返回。这一层是多制式终端回归中最容易出问题、也最难复用的部分，需要单独设计用例并标注制式组合。

为了让用例真正可复用，每条用例应至少包含：唯一 ID、适用制式/频段、前置条件（网络配置、终端状态、SIM 类型）、操作步骤、预期结果、判定依据（关键信令、关键日志、关键指标阈值）、优先级评分、关联缺陷、版本适用范围。其中“判定依据”是可复用性的关键——如果只写“连接正常”，不同人执行会得出不同结论；如果写成“RRC Reconfiguration Complete 在 200 ms 内收到，且后续 30 s 内无 RLF”，则可重复、可自动化。

四、用例版本管理

用例库不是一次建好就固定不变的。终端软件版本、网络配置、测试仪表能力都在变，用例本身也需要版本管理。推荐的做法是：

1. 用例库纳入版本控制（如 Git），每条用例一个文件或一个结构化条目，变更可 diff、可回溯。
2. 用例版本与终端软件版本解耦但建立映射：某条用例在 v1.2 适用、在 v1.3 因接口变更需要修改，则在用例元数据中记录“适用版本区间”和“变更原因”。
3. 每次回归执行时记录“用例版本 + 终端版本 + 网络配置版本”，三者绑定，避免出现“用例改了但结果无法复现”的情况。
4. 对失效用例（长期不通过或已不适用）不直接删除，而是标记为 deprecated 并保留历史，便于追溯历史版本的测试覆盖。

下面这张图给出从“变更输入”到“用例集更新与执行”的整体关系，重点表达风险评分、三层用例集与版本管理之间的数据流。

五、一个可落地的用例条目示例

下面给出一条互操作层用例的结构化示例，字段可直接用于用例管理工具。参数为教学示例，非实测结果。

用例ID: IOC-EN-DC-007
标题: EN-DC 下辅节点释放后 LTE 锚点保持
适用制式: LTE + NR (EN-DC)
频段: LTE B3 + NR n78
前置条件:
  - 终端已注册 LTE，并成功添加 NR 辅节点
  - 网络侧配置允许 SN Release
操作步骤:
  1. 建立 EN-DC 双连接，确认 SN 添加成功
  2. 网络侧发起 SN Release
  3. 观察 LTE 锚点连接状态与数据业务
预期结果:
  - SN Release 完成后，LTE RRC 连接保持
  - 数据业务中断时间 < 500 ms
  - 30 s 内无 RLF、无掉网
判定依据:
  - 信令: RRC Connection Reconfiguration (release) 正常交互
  - 日志: 无 RLF indication
  - 指标: 吞吐恢复至释放前 90% 以上
优先级评分: 可能性3 + 影响3 + 缺陷密度2 = 8 → P0
适用版本: v1.2 ~ v1.4
关联缺陷: BUG-2317, BUG-2450

这条用例的价值在于：它把“制式组合、前置条件、判定阈值、版本区间、关联缺陷”全部显式化。当终端版本从 v1.4 升到 v1.5 时，如果 NR 侧 SN Release 流程有改动，只需更新“适用版本”和“变更原因”，用例本身可继续复用；如果判定阈值因仪表升级需要调整，则通过版本控制记录 diff，历史执行结果仍可对照。

总结来说，多制式回归用例库的设计与维护，核心是三条线：用“风险评分 + 变更影响”决定先测什么，用“公共能力 + 制式专属 + 互操作”三层结构决定怎么复用，用“用例版本 + 终端版本 + 网络配置”三者绑定决定怎么追溯。三条线打通后，回归测试才能既快又稳，并且随着版本迭代持续积累而不是反复重建。