將定時測試任務玩到極致

背景

最近在新公司落地介面自動化測試，但因某些原因暫時無法將介面自動化測試接入專案 CI 流程（騰訊雲的 tencenthub 下架了，差評！）。

經過內部討論，最終選擇以定時任務的方式對專案介面進行持續測試。

最初的定時任務

最初的定時任務設計非常簡單，可以將用例集加入定時任務並設定時間間隔去執行測試。

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

發現的弊端

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

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

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

給定時任務加點料

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

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

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

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

這樣做不僅可以避免定時任務持續報警的尷尬，還可以代替人工去驗證缺陷的修復。（離把自己弄失業又進了一步）

比較令人驚喜的效果

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

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

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

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

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