自動化測試的統籌規劃

談到自動化測試，大家都會想到單元測試、功能測試等詞彙，筆者所在團隊也有這樣的實踐，取得了一定的效果，但卻沒有讓自動化測試發揮最大的價值，一直在思考這背後的原因，有沒有辦法做的更好，是以形成本文，供讀者參考~

背景回顧以前自動化測試編寫的經歷，主要是以開發者自驅動的方式進行，測試的編寫隨心而動，沒有規劃，也沒有章法，這樣就面臨如下的一些問題：

測試用例設計不到位，覆蓋不全，或者不夠高效

因為工期原因壓縮自動化測試時間，自動化測試名存實亡

自動化基礎設施不完善，某些測試編寫成本比較高

缺少完善的測試資料支援，導致測試效果大打折扣

這麼多的問題，其實總結起來本質就是乙個原因，缺少自動化測試的統籌規劃，沒有將自動化測試納入到研發體系中。

自動化測試的統籌規劃

為了解決這些問題，讓自動化測試真正的發揮其最大價值，解放生產力，提高研發效率，讓我們從重複的手動測試中解放出來，我們首先要做的就是對自動化測試進行統籌規劃，將自動化測試的意義提公升乙個等級，讓每個人都認識到他的價值與意義，包括產品，研發，測試以及高層管理人員。

自動化測試的統籌規劃應該是自上而下的，由多個層次構成一整套體系，這個體系應對包含框架，資料、用例和**四個部分，每個部分有其自己的職責，四者相互協同形成完整的測試體系和閉環。

下面簡單介紹一下這套體系。

測試體系之測試框架

選擇合適的測試框架，tdd 還是 bdd

環境初始化機制，比如e2e測試如何搭建快速搭各種環境，以及對應資料的初始化

輔助測試工具的開發

做好測試框架的搭建，需要有相關的測試開發人員（未必要有這個職位，但需要這個角色）進行，乙個好用完善的測試框架，直接關係到最終測試體驗和效果

測試體系之測試資料

自動化測試離不開資料的支援，為了測試順利進行，我們需要準備一套甚至多套測試資料，以便在不同的場景下使用。同時，這些資料不能是雜亂無章的，它應該是有序的，且能夠覆蓋盡可能多的使用場景，並且需要隨著業務的發展不斷迭代維護。

假如使用者有多個狀態，每個狀態對應了不同的使用者行為，這些使用者的測試資料應該同時包含不同狀態的使用者，以便測試使用者在不同狀態的行為是否符合預期，當然這只是乙個很簡單的例子，實際場景會複雜很多。

測試體系之測試用例

有了測試框架和測試資料的支撐，就需要我們開始設計測試用例了，測試用例的設計最好是獨立於開發環節之外，這樣才能更專注的進行測試用例的設計，對於有手動測試的團隊，測試用例在自動化測試和手動測試也需要統籌考慮，以便設計最高效的測試用例，平衡測試效果與成本。

同理，如果存在多個層次的測試，比如單元測試、功能測試、e2e測試，他們的測試也要統籌考慮，在最合適的地方做最合適的事情。

測試體系之測試**

有了前面的規劃和準備，測試**的編寫應該是水到渠成的事了，有開發者編寫對應的測試**即可。當然，在這個階段如果遇到測試**編寫的困難，比如某個基礎資料很難在測試中復現，可能需要回到測試框架中，反過來提公升測試框架的能力，形成乙個完整的閉環。