回归管理、种子调度与失败分诊
更新时间：2026-10-01。随机验证的价值靠大量种子回归兑现，而回归工程的核心难题是：跑挂了一大批，怎么快速判断是真 bug 还是平台/flaky 问题。
本文要回答的问题
- 回归怎么分层、种子怎么分配才高效？
- 上百个失败里怎么去重并锁定第一个真失败？
- 时好时坏的 flaky 用例怎么治理？
一、回归分层
- 冒烟 smoke：少量快速用例，每次提交跑，保证基本可用。
- 功能回归：覆盖主要特性，日常运行。
- 压力/长回归：大种子数、边界与异常场景，夜间/周末跑。
- 定向 + 随机结合；用 plusarg/seed 矩阵驱动（见 字符串与文件 IO/plusarg）。
二、资源与结果
作业分发到 LSF/网格并行（见 LSF 调度），收集 pass/fail、日志、覆盖率到统一报告；按覆盖率空洞动态补种子，而不是无脑加量。
三、分诊流程
- 用 seed 复现失败（随机性必须能复现才有意义，见 CRV 复现）。
- 判断错误来源：DUT 逻辑、testbench/checker、时钟复位/环境配置。
- 去重：同一根因的多个失败合并，追“第一个”失败点。
四、flaky 治理与门禁
flaky（同代码同 seed 结果不稳）多源于竞争、未初始化、线程残留、文件依赖，应单独隔离修复而不是重跑掩盖。发布门禁绑定关键回归通过率和覆盖率；基线（passing baseline）清晰，新失败立即可见。
五、常见坑
- 失败不先复现就提单，无法定位。
- 多个失败不做根因去重，工单爆炸。
- 靠重跑掩盖 flaky，真 bug 混入。
- 种子/结果不可追溯，覆盖率无法合并。
- 所有用例一个层级跑，反馈慢、资源浪费。
小结
回归分层 + 种子矩阵产生数据，分诊靠“可复现→分类→去重”，flaky 必须根治，发布门禁与覆盖率挂钩。下一篇 UVM phase、objection 与仿真结束控制。
总结
大规模随机回归的工程闭环：用例分层——冒烟（每次提交快速验证）、功能（日常覆盖主特性）、压力/长回归（大种子+边界异常，夜间跑），作业分发 LSF/网格并行、结果和覆盖率汇入统一报告，并按覆盖率空洞动态补种子而非无脑加量；失败分诊走“固定 seed 最小化复现 → 分类（DUT/TB/环境）→ 同根因去重、追第一个失败点 → 提单保留波形”，因为随机性必须能复现才有意义；flaky 用例（同代码同 seed 结果不稳）多源于竞争、未初始化、残留和文件依赖，必须隔离根治、不能靠重跑掩盖；发布门禁绑定关键回归通过率与覆盖率基线，让新失败立即可见。