將定時測試任務玩到極致

背景

最近在新公司落地接口自動化測試，但因某些緣由暫時沒法將接口自動化測試接入項目 CI 流程（騰訊雲的 tencenthub 下架了，差評！）。

通過內部討論，最終選擇以定時任務的方式對項目接口進行持續測試。

最初的定時任務

最初的定時任務設計很是簡單，能夠將用例集加入定時任務並設置時間間隔去運行測試。

一旦出現失敗的測試用例後，會給配置好的 郵箱 / 企業微信 / 釘釘 進行報警消息推送。

發現的弊端

通過實踐後，發現最初的定時任務在設計上存在着一些弊端：

1. 一旦出現報錯的測試用例，定時任務會在每一個測試觸發時間點持續地進行報警。

2. 當定時測試任務撞上系統重啓等 "特殊狀況" 時，會出現 "誤報"，致使垃圾推送消息過多。

給定時任務加點料

"誤報" 的問題好解決，只須要加上測試任務重試次數以及重試間隔就能夠較爲完美地解決問題。

剩下的問題就是如何設計定時任務報警機制，

通過思考後，我有了這樣的想法：

當定時任務出現報警後，該定時任務便會 進入等待用例修復 狀態。在這個狀態下，即便定時任務測試失敗也不會再次進行任何報警。一旦在之後某個時刻定時任務測試經過，則會 解除等待用例修復 狀態並推送一條 測試報警恢復 的消息提醒。

這樣作不只能夠避免定時任務持續報警的尷尬，還能夠代替人工去驗證缺陷的修復。（離把本身弄失業又進了一步）

比較使人驚喜的效果

就在我剛將新的定時任務提醒機制加上的當天，他就成功地發揮了效果。

還記得那一天望着開發們滄桑的背影，我準點下了班。

隔天早上我發現昨晚 10 點左右定時任務報了一次警，但緊接着到 10 點半左右定時任務報了一次 測試恢復 的提醒。

一開始我覺得個人定時任務出現了異常，但一問開發，是某位開發看到推送的測試報告後將缺陷 "偷偷" 修復了...

ps: 公司已經不須要我了 :(