談到自動化測試，大家都會想到單元測試、功能測試等詞匯，筆者所在團隊也有這樣的實踐，取得了一定的效果，但卻沒有讓自動化測試發揮最大的價值，一直在思考這背后的原因，有沒有辦法做的更好，是以形成本文，供讀者參考~
背景
回顧以前自動化測試編寫的經歷，主要是以開發者自驅動的方式進行，測試的編寫隨心而動，沒有規划，也沒有章法，這樣就面臨如下的一些問題：
- 測試用例設計不到位，覆蓋不全，或者不夠高效
- 因為工期原因壓縮自動化測試時間，自動化測試名存實亡
- 自動化基礎設施不完善，某些測試編寫成本比較高
- 缺少完善的測試數據支持，導致測試效果大打折扣
這么多的問題，其實總結起來本質就是一個原因，缺少自動化測試的統籌規划，沒有將自動化測試納入到研發體系中。
自動化測試的統籌規划
為了解決這些問題，讓自動化測試真正的發揮其最大價值，解放生產力，提高研發效率，讓我們從重復的手動測試中解放出來，我們首先要做的就是對自動化測試進行統籌規划，將自動化測試的意義提升一個等級，讓每個人都認識到他的價值與意義，包括產品，研發，測試以及高層管理人員。
自動化測試的統籌規划應該是自上而下的，由多個層次構成一整套體系，這個體系應對包含框架，數據、用例和代碼四個部分，每個部分有其自己的職責，四者相互協同形成完整的測試體系和閉環。
下面簡單介紹一下這套體系。
測試體系之測試框架
這里的測試框架是泛指，也可以叫測試基礎設施，它存在的目的是為了服務測試相關人員，讓他們更加高效便捷的編寫測試，執行測試，從而提高效率。可能涉及如下一些工作：
- 選擇合適的測試框架，TDD 還是 BDD
- 環境初始化機制，比如E2E測試如何搭建快速搭各種環境，以及對應數據的初始化
- 輔助測試工具的開發
做好測試框架的搭建，需要有相關的測試開發人員（未必要有這個職位，但需要這個角色）進行，一個好用完善的測試框架，直接關系到最終測試體驗和效果
測試體系之測試數據
自動化測試離不開數據的支持，為了測試順利進行，我們需要准備一套甚至多套測試數據，以便在不同的場景下使用。同時，這些數據不能是雜亂無章的，它應該是有序的，且能夠覆蓋盡可能多的使用場景，並且需要隨着業務的發展不斷迭代維護。
假如用戶有多個狀態，每個狀態對應了不同的用戶行為，這些用戶的測試數據應該同時包含不同狀態的用戶，以便測試用戶在不同狀態的行為是否符合預期，當然這只是一個很簡單的例子，實際場景會復雜很多。
測試體系之測試用例
有了測試框架和測試數據的支撐，就需要我們開始設計測試用例了，測試用例的設計最好是獨立於開發環節之外，這樣才能更專注的進行測試用例的設計，對於有手動測試的團隊，測試用例在自動化測試和手動測試也需要統籌考慮，以便設計最高效的測試用例，平衡測試效果與成本。
同理，如果存在多個層次的測試，比如單元測試、功能測試、E2E測試，他們的測試也要統籌考慮，在最合適的地方做最合適的事情。
測試體系之測試代碼
有了前面的規划和准備，測試代碼的編寫應該是水到渠成的事了，有開發者編寫對應的測試代碼即可。當然，在這個階段如果遇到測試代碼編寫的困難，比如某個基礎數據很難在測試中復現，可能需要回到 測試框架 中，反過來提升測試框架的能力，形成一個完整的閉環。