将定时测试任务玩到极致

背景

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

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

最初的定时任务

最初的定时任务设计很是简单，能够将用例集加入定时任务并设置时间间隔去运行测试。

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

发现的弊端

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

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

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

给定时任务加点料

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

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

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

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

这样作不只能够避免定时任务持续报警的尴尬，还能够代替人工去验证缺陷的修复。（离把本身弄失业又进了一步）

比较使人惊喜的效果

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

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

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

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

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