📚 课程目录第4章回归测试平台总体架构设计

4. 回归测试平台总体架构设计

回归测试平台不是把 Jenkins、TestNG、Allure 拼在一起就能成立的系统。它要同时承载三类职责：测试资产的长期管理（用例、数据、环境、基线）、测试执行的高并发调度（引擎、执行机、结果采集）、质量结论的持续输出（报告、趋势、门禁）。医疗软件还叠加了 IEC 62304 的软件安全分级、IEC 62366 的可用性验证、以及数据可追溯要求，因此架构设计的第一原则是：任何一次回归结论都必须可追溯到“哪条用例、哪个版本、哪套环境、哪份数据、哪次执行”。围绕这一原则，本节给出分层架构、微服务与单体的权衡、执行引擎、用例管理、报告服务以及与 CI/CD 的集成点。

一、分层架构：把“变化频率”作为分层依据

推荐按变化频率从低到高分为五层，而不是按技术栈分层：

接入层：CI/CD 触发接口、Web 控制台、命令行 CLI、Webhook 回调。它只做协议转换与鉴权，不含业务逻辑。
编排层：把“一次回归请求”翻译成“一批可调度的执行任务”。负责用例筛选、环境匹配、并发配额、失败重试策略、优先级排序。
执行层：执行引擎与执行机（Runner）池。负责拉起被测系统、注入测试数据、运行用例、采集日志与截图、上报结果。
资产层：用例库、测试数据集、环境配置、基线快照、设备/仪器接口定义。这是平台最需要版本化的部分。
数据与报告层：结果存储、趋势聚合、报告生成、门禁判定、审计留痕。

分层的关键约束是依赖单向向下：编排层可以调用执行层，执行层不能反向调用编排层；报告层只读结果数据，不参与调度决策。这样当执行引擎从 Selenium 换成 Playwright、或从物理执行机换成容器时，编排层与报告层几乎不需要改动。

二、微服务与单体的权衡：按“团队边界”而非“技术时髦”切分

回归测试平台常见的错误是过早微服务化：把用例管理、执行调度、报告生成拆成三个独立服务，结果一次回归请求要跨三次网络调用、两次数据一致性补偿，排障成本远高于收益。更务实的判断标准是变更频率与团队边界是否真的不同。

维度	单体更合适	微服务更合适
用例管理	用例量 < 2 万条，团队 1～2 个	多产品线各自维护用例，需独立发布
执行引擎	执行机类型单一（纯 Web）	需同时支持 Web、接口、设备、影像等多类 Runner
报告服务	报告格式固定，仅内部使用	需对接监管审计、外部客户、多租户
数据一致性	强一致，事务简单	可接受最终一致，有独立数据域

推荐路径是“模块化单体起步，执行层先拆”。用例管理、报告服务先做成同一进程内的清晰模块，通过接口隔离；执行引擎因为要对接异构 Runner、需要独立扩缩容、且故障不应拖垮控制面，可以最先拆为独立服务。这样既保留了单体的事务简单性，又让最需要弹性的部分获得弹性。

三、测试执行引擎：分片、隔离与可复现

执行引擎的核心不是“能跑用例”，而是在并发下仍能保证结果可复现。关键设计有三点：

分片策略：按用例标签（模块、风险等级、是否可并行）分片，而不是简单按数量均分。例如 1200 条用例中标记 parallel-safe 的 900 条按 8 个 Runner 均分，剩余 300 条串行执行，避免共享设备冲突。
环境隔离：每个 Runner 绑定一套独立环境快照（数据库 schema、配置、脱敏数据集），执行前重置，执行后回收。示例参数：单次回归环境准备耗时约 40 秒，若复用环境可降至 8 秒，但需承担脏数据风险。
失败隔离与重试：区分“用例失败”与“基础设施失败”。断言失败不重试；连接超时、Runner 掉线等基础设施失败最多重试 2 次，并在报告中标记 flaky。

# 执行任务描述示例（YAML）
task_id: REG-2024-0517-003
suite: 输液泵控制模块回归
shard:
  parallel_safe: 900
  serial: 300
runners:
  pool: web-chrome-8
  env_snapshot: env_pump_v2.3.1
retry:
  infra_max: 2
  assert_retry: false
report:
  format: [junit_xml, json]
  gate: pass_rate >= 0.98 and critical_fail == 0

四、用例管理与报告服务：资产化与结论化

用例管理要解决的是“同一条用例在不同版本、不同环境下的可比性”。每条用例至少携带：唯一 ID、所属需求/风险项、适用软件版本范围、前置数据依赖、预期结果、基线通过记录。医疗软件中，涉及安全相关（Class B/C）的用例必须与风险控制措施建立双向链接，回归时优先执行。

报告服务则要把原始结果转化为可判定的结论。建议报告至少包含四块：执行概览（总数/通过/失败/跳过/阻塞）、失败聚类（按模块与失败原因分组）、趋势对比（与上一基线通过率差异）、门禁判定（是否允许进入下一阶段）。门禁规则应显式配置，例如：

门禁示例：当 critical_fail == 0 且 pass_rate ≥ 98% 且 新增失败用例数 == 0 时判定为“通过”；任一不满足则“阻断”，并在 CI 流水线中阻止制品晋级。

五、与 CI/CD 的集成点

集成点应控制在四个，避免平台与流水线深度耦合：

触发点：CI 在构建成功后通过 REST 或 CLI 发起回归请求，携带制品版本、变更集、目标环境。
任务下发点：平台返回执行 ID，CI 可据此轮询或等待回调，不阻塞流水线其他阶段。
结果回传点：平台以 JUnit XML 或 JSON 回传结果，CI 直接解析为测试报告。
门禁判定点：平台输出通过/阻断结论，CI 据此决定是否继续部署。

实践建议：集成点全部通过版本化接口契约定义（如 OpenAPI），平台升级不破坏流水线；同时保留“人工触发”入口，用于监管审计或紧急回归场景。

综上，回归测试平台的架构设计应围绕“可追溯、可复现、可判定”三个目标展开：分层保证变化隔离，微服务与单体的取舍服从团队与变更边界，执行引擎保证并发下的可复现，用例与报告服务把资产和结论沉淀下来，四个 CI/CD 集成点则让平台真正嵌入研发流程而非成为孤岛。