只靠上线后人工点一遍，是多数机器人项目的测试现状。消息系统改一处文案可能影响发送、审核、回执三条链路，没有分层测试兜底，每次发布都是赌博。本文讲四层测试体系的搭建。

背景痛点

机器人系统的测试难点在于依赖：发送依赖接口平台，回执依赖回调推送，多依赖集成让"全量手工回归"越来越不可行。解法是分层——把不同类型的验证放到不同层，让每一层都跑得又快又稳。

原理

所谓测试金字塔，是指按成本与数量分层的测试策略：

单元测试（规则函数、格式转换，量大跑得快） → 集成测试（模块协作，mock 外部接口） → 契约测试（真实接口形态断言，低频定时） → 演练验证（故障注入与端到端验证，季度级）。

四层的分工：单测管逻辑正确（打标规则、模板渲染、错误分流）；集成测试管模块组装（mock 接口平台，验证队列到发送的协作）；契约测试管外部依赖没变（真实调用断言响应形态）；演练管真实故障下的表现。每一层只能依赖下一层，别让单测去调真实接口——调了就又慢又脆。

核心实现

分层在 CI 流水线里的编排（仅演示，上线前对照官方文档校验）：

stages = [
    ("unit",   run_unit_tests),        # 每次提交：秒级，不过即止
    (" integ", run_integration_tests), # 合并前：分钟级，mock 外部接口
    ("contract", nightly_contract),    # 每夜：真实接口形态断言
    ("drill",  quarterly_drill),       # 季度：故障演练与回归
]
# 仅演示，上线前对照官方文档校验
for name, fn in stages:
    if not fn():
        fail_pipeline(name)            # 任一层失败即阻断合并或发布

快层在前慢层在后，问题在最低成本层暴露。

踩坑

一、mock 的接口形态要和契约测试对齐：集成测试 mock 的响应结构，直接从契约测试的基准记录里生成——两套口径不一致，集成测得越对上线摔得越狠。

二、单测覆盖率看逻辑层不看壳：模板渲染、规则引擎、错误分流的覆盖率往高追；胶水代码和配置加载不必强求，覆盖率指标化会催生无意义的测试。

三、回调链路要造"脏数据"用例：重复推送、乱序到达、未知事件类型，这些脏数据在联调时出现概率极高——集成测试里专门建一组异常用例集。

四、测试数据与生产隔离：测试实例、测试账号单独申请，测试流量永不混入生产统计，这条在接口平台的开通流程里就能分开。

总结

测试体系的验收标准：一个改动从提交到可发布，全自动验证不超过十五分钟。本文基于 Eyun 平台的企微接口实践整理，接口形态的契约基准与开通环境以 Eyun 官方文档为准，四层不必一次建齐，先补单测和集成，契约与演练跟着基础设施一起长。