【Hermes系列6】回归报告没人看？我用 Hermes 实现"自动推送 + 失败@责任人"先说个扎心的事实你辛辛苦苦

先说个扎心的事实

你辛辛苦苦写的测试报告，有多少人真的会看？

上周五下午 3 点，项目复盘会。

研发负责人："上次回归测试怎么样？有风险吗？"

我打开电脑，准备展示测试报告。

研发负责人："等等，我怎么没看到报告？"

我："发了啊，周四早上发的邮件，还有飞书..."

研发负责人："邮件太多了，没注意。飞书哪个群？我没看到。"

业务负责人："所以测了没有？结果怎么样？"

空气突然安静。

我说："我再发一次。"

这不是我第一次遇到这种事。

我问团队 10 个人："上次回归测试的报告在哪？"

3 个人说："不知道啊，你没发群里吗？"
4 个人说："发了吧，我没注意..."
2 个人说："在邮件里，但我没打开"
1 个人说："在飞书，但我忘了"

真正打开报告的人：0

你辛辛苦苦写的报告，就像石沉大海。

而这样的场景，每个月都在上演。

为什么报告触达比执行更重要？

测试的价值链条

TEXT复制

执行测试 → 生成报告 → 触达团队 → 发现问题 → 修复问题 → 质量提升
   ↓          ↓          ↓
  自动化    格式化      飞书推送

如果报告没触达：

TEXT复制

执行测试 → 生成报告 → 本地躺平 → 无人知晓 → 问题遗留 → 线上故障
                      ↑
                   你在这

真实案例

上个月，价格模块重构，回归测试发现了 5 个 bug。

第一次（报告发邮件 + 群里喊了一声）：

邮件发送：周一上午 9 点
群里消息："@所有人回归报告已发，有 5 个 bug 麻烦处理一下"
研发 A："这 3 个不是我改的，应该是后端的问题"
研发 B："我看了一下，这 2 个是前端缓存问题，不是我负责的范围"
测试："那这些 bug 谁来修？"
群里沉默了...
周三下午，研发负责人问："那几个 bug 修得怎么样了？"
研发 A："哦，我以为是小问题，没优先处理"
研发 B："我以为不紧急，先忙别的需求了"
问题修复：周五下班前
风险暴露时间：5 天

第二次（报告推飞书 +@责任人 + 明确 SLA）：

飞书推送：周一上午 9 点
每条失败用例自动@对应模块负责人
文案："【P2】商品详情页价格显示异常 - @张三 - 建议今日 18:00 前修复"
文案："【P3】库存数字精度问题 - @李四 - 建议本周三前修复"
张三："收到，这个我中午看一下"
李四："这个需要排期，周三前能好"
问题修复：周三全部完成
风险暴露时间：2 天

第三次（优化后 + 失败用例自动创建工单）：

飞书推送：周一上午 9 点
同时自动在 Jira 创建 5 个 bug 工单，指派给对应负责人
工单关联到迭代，纳入本周 sprint 任务
张三收到 Jira 通知 + 飞书@，当天上午修复
李四看到工单在 sprint 里，优先安排
问题修复：周二全部完成
风险暴露时间：1 天

触达方式决定响应速度，责任清晰决定修复效率。

飞书 webhook 完整配置流程

步骤 1：创建自定义机器人

打开飞书，进入要推送的群聊
点击右上角「设置」图标
找到「群机器人」→「添加机器人」
选择「自定义机器人」

步骤 2：配置机器人信息

填写：

名称： Hermes 测试报告
描述：（可选）自动推送测试报告 头像：上传一个醒目的图标（建议用 Hermes logo）

步骤 3：安全设置（重要！）

有三种安全方式：

方式	优点	缺点	推荐度
不限	配置简单	任何人拿到 URL 都能发消息	⭐⭐
IP 白名单	安全性高	需要固定 IP	⭐⭐⭐
签名验证	安全且灵活	需要计算签名	⭐⭐⭐⭐⭐

推荐选择「签名验证」，复制「签名密钥」（secret），后面要用。

步骤 4：复制 Webhook URL

格式类似：

https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

⚠️ 重要：这个 URL 相当于密码，不要发到公开仓库！

配置 Hermes

编辑配置文件

BASH复制

vim ~/.hermes/config.yaml

添加飞书配置：

YAML复制

飞书推送配置

FEISHU_HOME_CHANNEL: XXX# 你的飞书 channel ID
FEISHU_WEBHOOK_URL:https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
FEISHU_WEBHOOK_SECRET: xxxxxxxxxxxxxxx  # 签名密钥


模型配置

model:
  provider: XXXX
  default: XXXX

⚠️ 安全提示：Webhook URL 和 Secret 相当于密码，不要提交到公开仓库！

获取 Channel ID

如果你不知道 channel ID，可以：

1. 方式 1：在飞书群里发消息，然后查看消息 URL
2. 方式 2：使用 Hermes 命令查询
3. 方式 3：直接填 local（推送到本地文件）

摘要契约设计

什么是最小可用摘要？

不需要大而全，先锁最小结构：

JSON复制

{
  "test_time": "2026-04-11T09:30:00",
  "suite": "login_regression",
  "total": 50,
  "passed": 48,
  "failed": 2,
  "failed_cases": [
    {
      "name": "test_login_with_invalid_password",
      "hint": "预期 401，实际 500"
    },
    {
      "name": "test_session_timeout",
      "hint": "超时时间不符合预期"
    }
  ]
}

字段说明

字段	类型	必填	说明
`test_time`	string	✅	ISO8601 格式时间
`suite`	string	✅	测试套件名称
`total`	number	✅	总用例数
`passed`	number	✅	通过数
`failed`	number	✅	失败数
`failed_cases`	array	❌	失败用例详情（最多 5 条）

扩展字段（可选）

JSON复制

{
  "test_time": "2026-04-11T09:30:00",
  "suite": "login_regression",
  "total": 50,
  "passed": 48,
  "failed": 2,
  "failed_cases": [...],
  // 扩展字段
  "duration_seconds": 120,
  "environment": "test",
  "branch": "feature/login-fix",
  "commit_id": "abc123",
  "coverage": "85.3%"
}

emit_summary.py 完整代码

篇幅有限，未贴；

hermes cron 配置详解

方式 1：手动执行（推荐）

最简单的方式：直接在终端执行脚本

实际执行命令（2026-04-13 08:22）：

BASH
复制

cd /home/zhou/hermes-demo
python3 emit_summary.py

输出：

📊 Hermes 测试数据工厂报告
🕐 生成时间：2026-04-13 08:22

━━━ 🟢 铺数结果 ━━━

📦 批次 ID: 20260411_163612


📊 总数：10
✅ 成功：8
❌ 失败：2（意外 0 + 预期 2）
📈 总体成功率：80.0%（8/10）
📈 有效成功率：100.0%（8/8，排除预期失败）




⚠️  预期失败（业务规则验证）：


E2E_AUTO_异常_负价格

> 价格必须大于等于 0


E2E_AUTO_异常_负库存

> 库存必须大于等于 0




━━━ 🧹 清理结果 ━━━

📊 找到：8
✅ 成功：8
❌ 失败：0
📈 成功率：100.0%

━━━ 💡 建议 ━━━

✅ 全流程正常，可以继续执行测试

*报告由 Hermes 测试数据工厂自动生成*

📁 报告已保存：/home/zhou/hermes-reports/feishu_report.txt

💡 技术细节

报告格式：飞书兼容的 Markdown（支持粗体、代码块、列表） > - 数据来源：自动读取 seed_result.json 和 cleanup_result.json > - 建议逻辑：根据铺数/清理/测试结果动态生成 > - 保存位置：~/hermes-reports/feishu_report.txt > - 使用方式：可以手动执行，也可以配置定时任务

方式 2：定时任务（可选）

如果需要自动推送，可以配置定时任务：

BASH复制

1. 复制脚本到 Hermes 脚本目录

mkdir -p ~/.hermes/scripts
cp /home/zhou/hermes-demo/emit_summary.py ~/.hermes/scripts/


2. 安装 croniter（解析 cron 表达式）

pip3 install croniter


3. 创建定时任务（工作日每天 9:00 执行）

hermes cron create "0 9 * * 1-5" "生成测试报告" \
  --name "regression-feishu-digest" \
  --script "emit_summary.py" \
  --deliver "feishu"

说明：

脚本位置：必须放在 ~/.hermes/scripts/ 目录下 > - cron 表达式：0 9 * * 1-5 = 周一至周五每天 9:00 > - 交付目标：feishu = 推送到飞书群（配置在 ~/.hermes/config.yaml） > - 注意：需要 Hermes 网关运行中才能自动推送

Cron 表达式参考

常用示例：

cron 表达式	含义
`0 9 * * 1-5`	工作日每天 9:00
`0 9 * * *`	每天 9:00
`0 9,18 * * *`	每天 9:00 和 18:00
`0 /2 * *`	每 2 小时
`0 9 * * 1`	每周一 9:00

执行报告生成

实际执行命令（2026-04-13 08:22）：

cd /home/zhou/hermes-demo
python3 emit_summary.py

实际输出：

📊 Hermes 测试数据工厂报告
🕐 生成时间：2026-04-13 08:22

━━━ 🟢 铺数结果 ━━━

📦 批次 ID: 20260411_163612


📊 总数：10
✅ 成功：8
❌ 失败：2（意外 0 + 预期 2）
📈 总体成功率：80.0%（8/10）
📈 有效成功率：100.0%（8/8，排除预期失败）




⚠️  预期失败（业务规则验证）：

E2E_AUTO_异常_负价格
> 价格必须大于等于 0

E2E_AUTO_异常_负库存
> 库存必须大于等于 0

━━━ 🧹 清理结果 ━━━

📊 找到：8
✅ 成功：8
❌ 失败：0
📈 成功率：100.0%

━━━ 💡 建议 ━━━

✅ 全流程正常，可以继续执行测试

*报告由 Hermes 测试数据工厂自动生成*

📁 报告已保存：/home/zhou/hermes-reports/feishu_report.txt

技术细节：

报告格式：飞书兼容的 Markdown（支持粗体、代码块、列表） > - 数据来源：自动读取 seed_result.json 和 cleanup_result.json > - 建议逻辑：根据铺数/清理/测试结果动态生成 > - 保存位置：~/hermes-reports/feishu_report.txt > - 使用方式：手动执行或集成到 CI/CD 流程

飞书收到的消息效果

进阶玩法

玩法 1：失败自动@责任人

需求：测试失败时，自动@对应的研发负责人。

实现：

def get_responsible_person(case_name):
    """根据用例名获取责任人"""
    # 维护一个映射表
    mapping = {
        "login": "张三",
        "order": "李四",
        "payment": "王五",
        "product": "赵六",
    }

    for module, person in mapping.items():
        if module in case_name.lower():
            return person
    return "测试负责人"



def generate_failure_notification(failed_cases):
    """生成失败通知"""
    lines = ["🔴 测试失败通知\n"]

    mentioned = set()

    for case in failed_cases:
        person = get_responsible_person(case['name'])
        if person not in mentioned:
            lines.append(f"📢 @{person}")
            mentioned.add(person)

        lines.append(f"- {case['name']}")
        if 'hint' in case:
            lines.append(f"  > {case['hint']}")

    return "\n".join(lines)

玩法 2：阻断级失败自动通知 Leader

需求：P0 级失败用例，除了@责任人，还要通知研发 Leader。

实现：

def is_blocking_case(case_name):
    """判断是否是阻断级用例"""
    blocking_keywords = ["login", "payment", "order_create", "checkout"]
    return any(kw in case_name.lower() for kw in blocking_keywords)



def notif_leaer_if_blocking(failed_cases):
    """阻断级失败通知 Leader"""
    blocking = [c for c in failed_cases if is_blocking_case(c['name'])]

    if blocking:
        # 发送飞书消息给 Leader
        leader_message = f"""
🚨 阻断级失败警告





发现 {len(blocking)} 个阻断级失败用例：
{chr(10).join([f'- {c["name"]}' for c in blocking])}





请立即处理！
"""
        send_feishu_message(LEADER_CHANNEL_ID, leader_message)

玩法 3：周报/日报差异化文案

日报（简洁）：

TEXT
复制

📊 日报 











【本周概况】

执行回归：5 次
总用例数：250
累计通过：245 (98%)
发现 bug：5 个（已修复 4 个）

【趋势分析】

通过率：95% → 98% ↑
执行时长：15min → 12min ↓

【待办事项】

剩余 1 个 bug 待修复（P2）
下周新增 10 个用例

备选方案对比

方案 1：飞书 webhook（推荐）

优点：

实时触达
支持@责任人
消息格式丰富（Markdown）
免费

缺点：

需要配置 webhook
依赖飞书服务

适用场景：日常日报、失败通知

方案 2：系统 cron + curl

优点：

不依赖 LLM
链路更硬
完全可控

缺点：

消息文案要自己维护
无法智能总结

适用场景：对稳定性要求极高的场景

2. 检查 webhook URL 是否正确

cat ~/.hermes/config.yaml 


指标	数值
报告发送方式	邮件
平均打开时间	4 小时
失败响应时间	1 天
报告打开率	30%
扯皮次数	5 次/周


实施后（飞书推送）


指标	数值报告发送方式	飞书
平均打开时间	5 分钟
失败响应时间	30 分钟
报告打开率	100%
扯皮次数	1 次/周


效率提升
打开时间：4 小时 → 5 分钟，提升 48 倍
响应速度：1 天 → 30 分钟，提升 48 倍
扯皮次数：5 次 → 1 次，减少 80% 


你的收益计算器

如果你的团队：

每周 5 次回归测试
每次扯皮浪费 30 分钟（解释、复现、确认）
时薪 100 元
实施前：5 × 0.5 × 100 × 4 周 = 1,000 元/月（仅扯皮成本）  
实施后：1 × 0.5 × 100 × 4 周 = 200 元/月
每月节省：800 元（仅扯皮）



更重要的是：

线上故障减少（问题早发现）
团队信任提升（报告准时、结论清晰）
个人品牌建立（靠谱、专业、高效）
这些，都是无价的。 




给你的行动清单

30 分钟：
1. 创建飞书机器人（5 分钟）
2. 配置 webhook（2 分钟）
3. 复制 emit_summary.py（5 分钟）
4. 手动执行一次（1 分钟）
5. 复制报告内容发送到飞书群（1 分钟）
6. 截图发朋友圈，收获一波点赞（16 分钟）← 这步很重要！

1 小时：
1. 调整文案格式，适配自己团队（15 分钟）
2. 配置@责任人映射（15 分钟）
3. 集成到 CI/CD 流程（30 分钟）

1 天：
1. 覆盖所有测试套件
2. 配置阻断级通知
3. 区分日报/周报文案

1 周后：

报告打开时间：4 小时 → 5 分钟
失败响应时间：1 天 → 30 分钟
业务扯皮次数：5 次/周 → 1 次

这就是自动化的力量。