煉技術(9): 簡約而不簡單,永不停歇的測試 — always_run

最強戰力,永不停歇的測試:always_run

許多工程師寫完程式後,都不願意對自己的程式做仔細測試。

很多測試說會做自動化測試,可能工作好幾年都沒真做過多少自動化測試。

我們的解決方案是,在系統的測試環境里,常駐跑一個always_run程式來做品質保證以及有效發現問題。

always_run 程式的簡約設計如下:

  • 設計一個插件模式,約定了各模組提供的測試程式的入口和出口。
  • 這個程式里包含對各模組的場景使用流程程式碼。在項目中嚴格要求各模組必須提供對應的測試程式。
  • always_run 在系統里會24*7運行,通過設計不同分組的定時器,定時跑不同分組的測試程式,盡量做到足夠的覆蓋率。
  • 測試環境的機器覆蓋了實際系統所需的所有角色。
  • 為always_run提供一個機器人,在測試api里提供機器人上報介面,在測試失敗的分支里,調用機器人把錯誤簡要資訊和日誌路徑資訊發送到測試報警IM里。進一步可以自動AT相關的模組負責人。
  • 項目組需要把報警的優先順序調高,出現的錯誤報警如果不解決,會一直上報,只到被修復重新上線。
  • 為了保證always_run持續起作用,需要持續為always_run添加測試用常式序,持續活躍的測試加入,保證了always_run的不過時和真正為項目品質作出貢獻。
  • always_run 在測試體系里,屬於模組級別的集成測試,不算單元測試。但是它能快速的發現大部分問題,特別是程式里跟時序有關的BUG。
  • 工程師可能只能為模組跑有限次數的測試,或者不夠複雜的測試。測試如果不能寫介面測試,手工操作也只能做有限次數的測試。
  • 為 always_run 寫的場景測試,實際上是系統的最小使用原型,儘快地跑起來always_run 就是儘快地驗證系統的最小子集,此後有新的組件進來,就可以持續地為場景增加常駐執行的程式碼。
  • always_run 和通常說的自動化測試並不完全相同,always _run 本身是被當作一個完整的獨立Program被寫出來了,不需要依賴什麼自動化測試框架,只需對新加入的測試做入口和出口的約定即可。
  • 不要996, 而要 always_run !

–end–