端到端测试一条通知

在凌晨三点依赖它之前，先通过真实媒介从规则到手机完整发一条测试消息。

这页办完你会确认：真实告警发生时，消息确实会落到那个群 / 那个邮箱，而不是停在「界面上配好了」这一步。

三个层次的测试

层次	在哪按	验证了什么	没验证什么
媒介测试	通知媒介编辑页底部的测试	地址通不通、密钥对不对、网络能不能出去	你的消息模板、通知规则的筛选条件
通知规则测试	通知规则表单里每条通知配置右上角的通知测试	媒介 + 模板 + 接收人这一整组配置	告警规则有没有挂上这条通知规则
真实告警	告警规则的测试触发	整条链路，包括规则绑定	——

三个都过了才算数。只做前两个是「配置对」，不等于「真实告警会到」。

告警通知 → 通知媒介，点开一个媒介，底部有测试。

它按当前表单里的内容真实发一条消息，不需要先保存，所以适合边填边试。弹窗里从上往下：

预期结果：提示「发送成功」，并且你真的在群里/邮箱里看到那条消息。只看提示不算——媒介返回 200 但消息被平台丢掉的情况并不少见。

两个限制：

Script 类媒介不能内联测试，必须先保存。未保存的脚本会被写盘执行，等于从请求体直接执行任意代码，后端因此拒绝。
这里发出去的正文不是你的模板，是界面按媒介请求体里的 {{$tpl.xxx}} 现拼的一段起步内容。所以这一步只能证明「通道是通的」，证明不了「模板写对了」。

告警通知 → 通知规则，编辑一条规则，在某条通知配置右上角点 通知测试。这一步用的就是这条配置真正会用的媒介、模板和接收人。

两种模式的差别很重要：

使用模拟事件：不校验筛选条件，只验证通道。级别取你勾选的最低那一级。模拟事件长这样——规则名「通知测试模拟事件」，触发值 81.5，标签 ident=mock-host-01、source=notify-rule-test。
选择历史事件：会先跑一遍筛选条件，事件不匹配就直接报错（event severity not match severity filter 之类）。想验证筛选条件写得对不对，用这个。

预期结果：弹窗里回显目标返回的响应（HTTP 媒介是 status_code:200, response:...），同时消息真的到了。

前两步不经过告警规则，所以最容易漏掉的一件事是：这条通知规则根本没挂到告警规则上。

去 告警通知 → 规则管理，确认目标告警规则的 通知规则 字段里有它，然后用规则自己的测试触发真的产生一条事件。

预期结果：告警通知 → 告警事件 里出现一条新事件，同时你收到消息。

事件出现了但消息没到，就去看通知记录：告警事件 → 点开事件详情 → 通知记录 → 查看详情。

抽屉里有两张表：告警规则通知 和 订阅规则通知，列是通知规则 ID、通知渠道、通知对象、通知目标、通知状态。状态里的文字就是失败原因，例如：

记录里的文字	含义
`status_code:200, response:...`	发出去了，对方回了 200
`message_template not found`	这条通知配置没选消息模板，整条被丢弃
`notify_channel not found`	媒介被删了或被停用
`all retries failed, last error: ...`	连不上目标地址
`status_code:400, response:...`	目标接受了请求但拒绝了内容，多半是 token、签名或消息格式

通知目标默认打码（末 8 位变星号），只有邮件、短信、语音、脚本和屏蔽记录例外。