3. 回归平台需求分析与架构设计

回归平台不是先写脚本再想需求，而是从项目验证计划（Verification Plan）反向推导出来的。验证计划里定义了哪些功能点需要覆盖、每个功能点对应哪些测试用例、覆盖率目标是多少、签核标准是什么。回归平台要做的事情，就是把这些静态的验证意图，转化为可自动触发、可分配资源、可收集结果、可生成报告的动态执行系统。因此，需求分析的第一步不是问“平台要支持什么功能”，而是问“验证计划要求平台在什么条件下、以什么粒度、产出什么证据”。

一、从验证计划提取回归需求

假设某 SoC 项目验证计划中包含以下典型条目：DMA 控制器需覆盖 128 个功能点，其中 96 个由定向测试覆盖，32 个由随机约束测试覆盖；覆盖率目标为代码覆盖率 100%、功能覆盖率 95%；签核要求连续 5 次回归全部通过且覆盖率不下降。这些条目直接转化为回归平台的四类需求：

• 触发条件：代码提交、每日定时、覆盖率未达标、签核前强制触发。
• 资源需求：随机测试需要更多仿真 license 和 CPU 核数，定向测试可批量并行。
• 结果收集：每个用例的通过/失败状态、覆盖率数据库、仿真日志、波形文件。
• 报告机制：按功能点、按测试类型、按覆盖率维度汇总，并标记回归趋势。

这里的关键是：需求不是拍脑袋定的，而是从验证计划的字段中“翻译”出来的。例如验证计划中“功能覆盖率 95%”对应平台必须能合并多个 seed 的覆盖率数据库；“连续 5 次通过”对应平台必须保留历史回归记录并支持趋势判断。

二、回归触发条件的设计

触发条件是回归平台的入口逻辑，设计时要区分三类触发源。第一类是事件驱动触发，例如 Git 提交后通过 webhook 触发增量回归，只运行与改动文件相关的测试子集。第二类是时间驱动触发，例如每晚 22:00 触发全量回归，适合随机测试和长用例。第三类是状态驱动触发，例如覆盖率未达标或上次回归失败时自动重跑失败用例。

实际实现中，触发条件通常写成一个配置片段。以下是一个示例配置，用于说明触发规则如何与测试集绑定：

trigger:
  - name: nightly_full
    type: schedule
    cron: "0 22 * * *"
    testset: full_regression
    resource: farm_night
  - name: commit_smoke
    type: webhook
    branch: main
    testset: smoke_subset
    resource: farm_fast
  - name: coverage_retry
    type: coverage_gate
    threshold: 95%
    testset: failed_and_uncovered
    resource: farm_fast

这段配置表达了三个触发源各自绑定的测试集和资源池。注意，触发条件不是孤立的，它必须和资源需求、结果收集形成闭环：夜间全量回归占用大资源池，提交冒烟只占用快速资源池，覆盖率重跑只跑失败和未覆盖用例。

三、资源需求与调度模型

回归平台的资源需求通常包括：仿真 license 数量、CPU 核数、内存、磁盘空间、波形存储、以及不同测试类型对运行时长的要求。资源需求分析的核心是回答“多少用例、多大并发、多长时间”。例如，全量回归有 2000 个用例，平均每个用例仿真 8 分钟，若并发 50 个，则理论墙钟时间约为 2000×8/50=320 分钟，约 5.3 小时。若并发提升到 100，则约 2.7 小时，但需要 100 个 license 和足够的 CPU 核数。

因此，资源需求不是简单“越多越好”，而是要在 license 成本、墙钟时间和失败重跑开销之间取平衡。平台架构上通常采用“资源池 + 队列 + 调度器”的结构：资源池按 license 类型和机器规格划分，队列按优先级排序，调度器负责把用例分配到合适的资源池。

四、结果收集与报告机制

结果收集要解决三个问题：收什么、怎么收、怎么判断。收什么包括：用例状态（pass/fail/error/timeout）、仿真日志、覆盖率数据库、波形文件、种子号、运行时长。怎么收通常通过统一的日志格式和退出码约定，例如仿真脚本返回 0 表示通过，非 0 表示失败，覆盖率数据库统一写入指定目录。怎么判断则依赖回归平台的结果解析器，把原始日志转换为结构化记录。

报告机制要面向不同角色：验证工程师关心失败用例和日志，项目负责人关心通过率和覆盖率趋势，签核评审关心连续通过次数和覆盖率是否达标。因此，报告通常分为三层：用例级明细、测试集级汇总、项目级趋势。以下是一个简化的结果记录示例：

testcase: dma_random_test
seed: 38291
status: fail
duration: 512s
log: /regress/logs/dma_random_test_38291.log
coverage_db: /regress/cov/dma_random_test_38291.vdb
fail_reason: scoreboard mismatch at addr 0x1F00

这条记录既包含执行结果，也包含定位失败所需的关键信息。回归平台在收集到这类记录后，才能生成“失败用例列表”“覆盖率合并报告”“连续通过趋势图”等报告。

五、架构设计：从需求到模块

综合以上需求，回归平台的架构可以划分为五个核心模块：触发管理、测试集管理、资源调度、执行引擎、结果与报告。触发管理负责接收事件、时间和状态信号；测试集管理负责维护用例列表和标签；资源调度负责分配 license 和机器；执行引擎负责启动仿真、监控超时、收集日志；结果与报告负责解析、存储和展示。这五个模块之间的数据流和依赖关系，可以用下面的 SVG 图清晰表达。

这张图表达的是回归平台从触发到报告的完整数据流，以及结果反馈到触发的闭环。触发管理接收外部信号后，从测试集管理中取出用例，连同资源需求一起交给资源调度；资源调度分配 license 和机器后，执行引擎启动仿真并收集结果；结果与报告模块解析数据后生成报告，同时把覆盖率未达标或失败信息反馈给触发管理，形成重跑闭环。

六、需求到架构的映射检查

架构设计完成后，需要做一次需求映射检查，确保每个需求都有模块承接。例如，“连续 5 次通过”需要结果与报告模块保留历史记录；“覆盖率 95%”需要执行引擎收集覆盖率数据库并由报告模块合并；“提交触发增量回归”需要触发管理支持 webhook 并绑定测试集。如果某个需求找不到对应模块，说明架构有缺口；如果某个模块没有需求支撑，说明设计过度。

最后，回归平台的需求分析和架构设计不是一次性的，而是随着项目阶段演进的。早期可能只需要每日全量回归和简单报告，后期则需要增量触发、覆盖率门禁、失败自动重跑和趋势分析。因此，架构上要预留扩展点：触发管理支持插件式触发源，资源调度支持多资源池，结果与报告支持自定义报告模板。这样平台才能跟随验证计划的变化持续演进，而不是每次需求变更都推倒重来。