一轮埋点验收跑完，报告上是这样一行数字：

结果 数量
Pass 12
Not Run 8

如果照着”自动化通过率”的老习惯，有人会立刻算出 60%，然后问：”才过一半多，这轮是不是没过？”

但真正做过埋点验收的人不会这么看。埋点的”通过”不是一个百分比，而是一组带边界的结论。 那 8 条 Not Run 不是 8 条失败，它们和 Fail 是两回事。

这篇文章我想讲清楚：埋点验收里的 Pass、Fail、Blocked、Not Run 到底各自意味着什么，为什么”没跑到”必须和”跑挂了”分开，以及什么情况下 12 Pass + 8 Not Run 依然能给出一个有信心的验收结论。

一、先把四个结论的含义对齐

埋点验收的结论不应该只有”过”和”不过”两档。我在平台里把它拆成了四个：

  • Pass（通过）：这次执行真的触发了目标事件，并且拿到了能证明”事件被正确接收”的证据。
  • Fail（失败）：事件触发了、证据也拿到了，但实际内容与规范不一致——比如事件名不对、参数缺失、参数值错误、触发时机不对。
  • Blocked（阻塞）：这一条没法继续，因为前置条件或外部依赖不满足。比如需要登录才能触发的事件，登录环节本身挂了。
  • Not Run（未执行）：这一条这次根本没有跑到——不是它失败了，是它连”被测”的机会都没有。

后面三个（Fail、Blocked、Not Run）有一个共同要求：必须写明原因。你不能只丢一个状态就走，因为这三个状态的可信度，完全取决于原因是否站得住。

一个很自然的推论是：Not Run 不是 Fail。 把 Not Run 记成 Fail，等于把”没考”记成”考了不及格”，这是两个完全不同的结论。

二、为什么不能拿”Pass 数 / 总数”算通过率

用 12 / 20 = 60% 来评价这轮埋点验收，错在两个地方。

第一，分母选错了。

总数 20 里，有 8 条是 Not Run。这 8 条没有产生任何”被观测”的结果，把它们放进分母，等于默认”没跑 = 没过”，这是不对的。

更合理的做法，是先看真正被观测到的样本：12 条 Pass、0 条 Fail、0 条 Blocked。也就是说，在所有这次实际跑到的事件里，100% 都通过了。这个结论和”60% 通过”是完全不同的分量。

第二，真正要盯的是 Fail 和 Blocked，而不是 Not Run。

一轮验收里最需要警惕的是 Fail（跑到了但不一致）和 Blocked（被前置条件卡住）。只要这两项是 0，说明”凡是跑到的，都没发现问题”。

Not Run 需要被单独管理，但它不直接代表产品缺陷。它代表的是这轮验收的覆盖是不完整的——这 8 个事件这次没有被验证，仅此而已。

三、”没跑到”和”跑挂了”，是两种完全不同的风险

Not Run 和 Fail 的分界线，是埋点验收里最容易混淆、也最关键的一根线。

  • Fail 指向产品问题：事件名拼错、参数没传、值不对、时机不对，这些是缺陷线索，需要开发修复。
  • Not Run 指向执行覆盖问题：可能是这一轮的操作路径没走到那个事件，可能是前置条件没满足，可能是设备/环境原因导致脚本没执行到那一步。它需要的是”补跑”，而不是”修缺陷”。

如果把 Not Run 当成 Fail 报给开发，会发生一件很糟糕的事：开发拿到一个”失败”，却不知道要修什么，因为根本没有东西可修。 最后要么被当成无效缺陷打回来，要么为了”让用例变绿”去做一些本不该做的改动。

反过来，如果把 Fail 悄悄记成 Not Run，就更危险了——一个真实的埋点缺陷被”没跑到”这个说法盖住了，报告看起来干净，实际上缺陷已经漏了出去。

所以这两根线必须划清楚：Fail 要有不一致的证据，Not Run 要有没跑到的原因。 两者都不能靠”大概”来定。

四、Pass 也不是”看见了日志就算”

反过来，Pass 的判定也不能太松。

埋点验收里最容易犯的错，是把”采集到了日志”当成”事件被正确接收”。实际上，一条日志的出现，只能说明采集窗口里有这么一段记录，它不能证明目标事件真的到达了验收层。

一个严谨的 Pass，至少要满足两点：

  1. 证据来自接收层：能证明事件被接收的，是 SDK、Console（调试控制台）或 Network（网络）这类”已匹配事件”的接收证据，而不是随手截的一段采集日志。
  2. 证据与事件匹配：这条证据要能对得上这个验收用例对应的事件，而不是”同一批日志里恰好出现过类似字段”。

换句话说，Pass 是需要证据支撑的。没有接收层证据，就不能判 Pass；证据对不上事件，也不能判 Pass。

这也是为什么在埋点验收里，”全绿”并不廉价——每个 Pass 背后都挂着一条可追溯的接收证据。

五、12 Pass + 8 Not Run，最终应该怎么判

回到开头那行数字。如果 Fail 和 Blocked 都是 0，那么这轮验收的结论可以这样表述：

在本次实际执行的 12 个事件中，全部匹配到了接收层证据，未发现事件名、参数、时机上的不一致。另有 8 个事件本次未执行，尚未被验证。

这是一个有条件通过的结论，而不是”没过”，也不是”全过”。

它同时给出三样东西：

  • 已经证明的：12 个事件的接收链路是通的，内容与规范一致。
  • 还没有证明的：8 个事件这次没有覆盖到。
  • 接下来要做的：为那 8 个 Not Run 单独安排一次补跑，把覆盖补上。

只有当那 8 个 Not Run 也都各自有了明确的结论（Pass，或者带着原因的 Fail / Blocked），这一轮验收才算真正闭环。

如果反过来，那 8 条里有任何一条是 Fail 或 Blocked，结论就立刻不同了——那就意味着已经发现了不一致或被卡住的问题，必须先处理，而不是谈”通过”。

六、一个可复用的判定清单

做埋点验收时，我会用下面这个顺序来收口，避免被百分比带偏：

  1. 先看 Fail 和 Blocked：只要不是 0，先处理问题，别急着谈通过。
  2. 再看 Pass 的证据质量：每个 Pass 是否都有 SDK/Console/Network 的接收证据，而不是只有日志。
  3. 单独盘点 Not Run：每条 Not Run 有没有写明原因——是没走到、前置不满足，还是环境问题。
  4. 区分两类结论：Fail/Blocked 指向缺陷和阻塞，Not Run 指向覆盖缺口，二者不能互换。
  5. 给出带边界的结论：写清”已证明什么、还没证明什么、下一步补什么”。

这五步走完，结论就不再是一句苍白的”通过”或”不通过”，而是一份能支撑决策的验收判断。

结语

埋点验收的价值，从来不只是给出一串 Pass/Fail 的计数，而是让每一个”通过”都有证据、每一个”没跑到”都有交代。

12 条 Pass、8 条 Not Run，说明这轮验收证明了它该证明的那部分，也诚实地标出了它还没覆盖的那部分。这比一个虚高的”100% 通过”更可信，也比一个被误伤的”60% 没过”更公平。

因为真正专业的验收结论，不是把数字做得好看，而是把边界说得清楚。