背景

最近在新公司落地接口自动化测试，但因某些原因暂时无法将接口自动化测试接入项目 CI 流程（腾讯云的 tencenthub 下架了，差评！）。

经过内部讨论，最终选择以定时任务的方式对项目接口进行持续测试。

最初的定时任务

最初的定时任务设计非常简单，可以将用例集加入定时任务并设置时间间隔去运行测试。

一旦出现失败的测试用例后，会给配置好的 邮箱 / 企业微信 / 钉钉 进行报警消息推送。

发现的弊端

经过实践后，发现最初的定时任务在设计上存在着一些弊端：

1. 一旦出现报错的测试用例，定时任务会在每个测试触发时间点持续地进行报警。

2. 当定时测试任务撞上系统重启等 "特殊情况" 时，会出现 "误报"，导致垃圾推送消息过多。

给定时任务加点料

"误报" 的问题好解决，只需要加上测试任务重试次数以及重试间隔就可以较为完美地解决问题。

剩下的问题就是如何设计定时任务报警机制，

经过思考后，我有了这样的想法：

当定时任务出现报警后，该定时任务便会 进入等待用例修复 状态。在这个状态下，即使定时任务测试失败也不会再次进行任何报警。一旦在以后某个时刻定时任务测试通过，则会 解除等待用例修复 状态并推送一条 测试报警恢复 的消息提醒。

这样做不仅可以避免定时任务持续报警的尴尬，还可以代替人工去验证缺陷的修复。（离把自己弄失业又进了一步）

比较令人惊喜的效果

就在我刚将新的定时任务提醒机制加上的当天，他就成功地发挥了效果。

还记得那一天望着开发们沧桑的背影，我准点下了班。

隔天早上我发现昨晚 10 点左右定时任务报了一次警，但紧接着到 10 点半左右定时任务报了一次 测试恢复 的提醒。

一开始我以为我的定时任务出现了异常，但一问开发，是某位开发看到推送的测试报告后将缺陷 "偷偷" 修复了...

ps: 公司已经不需要我了 :(