zh explanation coverage results

源文档 / Source · English

检查、覆盖率与回归结果

一次回归可以同时产生测试判定、功能覆盖率、原生覆盖率和运行 manifest。 它们回答的问题不同，判断验证结果时需要分别阅读。

命中场景不等于结果正确

断言和 Scoreboard 比较预期与实际结果；功能覆盖率记录定义的场景是否被观察到； 原生覆盖率记录仿真器统计的代码或信号活动。覆盖率高不能证明检查完整，测试通过也不能 证明已经覆盖所有需要验证的场景。

例如，Monitor 收到一次响应并先计入覆盖率，随后 Scoreboard 发现结果错误。 “观察到该响应”和“响应不正确”可以同时成立。因此覆盖采样点应有明确含义： 输入接受、DUT 输出，或检查成功。采样位置不同，计数代表的事实也不同。

一条观测的交付与采样

Scoreboard 和覆盖率常常需要同一条 DUT 观测。直接让两个消费者分别调用同一个 Monitor 的 recv()，可能把观测分给不同消费者，使检查和采样都只看到部分结果。

项目可以在交付检查器之前，对同一个不可变 Transfer 做一次覆盖采样。 这种方式明确了数据来源，也保留单一消费路径。检查停止后未交付的观测不会计数； 若项目需要故障后仍持续观察，需要另外定义观察与采样的生命周期。 完整配方见组合验证环境。

跨用例汇总需要一致的含义

Runner 在测试清理后收集各测试创建的覆盖组，共享组在进程退出时收集一次。 各进程的计数可以累加，前提是覆盖定义、实例身份和采样规则兼容；零命中的 bin 也必须 保留，否则未测到的场景会从分母中消失。

覆盖模型的单元测试可能人为填满 bin 来检查分桶规则。这些样本描述模型自身的行为， 不能据此推断 DUT 已经过相应场景。因此 runner 提供排除标记和 capture=False， 使模型自测与 DUT 的覆盖统计保持各自含义。用法见运行测试与汇总覆盖率。

原生计数按 DUT 构建身份合并，不同构建不会混在一起。功能覆盖率与原生覆盖率各自保留， 不会被换算成一个能替代测试判定的总分。

报告完整与测试通过

manifest.json 中的 state="committed" 表示本轮产物已经完整写入并校验， 不表示所有测试通过。一次包含断言失败但完整执行的回归，仍能生成可用的诊断覆盖率； 测试失败仍返回非零退出码。

有些用例已经执行，但关键期望的依据、观察能力或需要验证的组合尚未齐备。这时可明确 声明 UNCERTAIN（证据不足），让它不计入 PASS。它不是“预期失败”，也不跳过检查； 断言失败或 fixture 错误仍按真实错误报告。UNCERTAIN 本身不改变退出码，覆盖率也正常 提交。因此 state="committed"、退出码 0 和“验证全部通过”是三种不同结论。

进程崩溃、收集不完整或输入损坏会使汇总不完整。保留可用的中间输入有助于定位问题， 但不能把这份部分结果当作完整回归。已提交产物的清理失败则是另一种情况： 最终结果仍保留，manifest 记录 cleanup_error，命令仍会报告失败。

各文件、状态和退出行为的定义见Runner 参考； 实际排查步骤见运行测试与汇总覆盖率。