今天跟大家分享一下我對前端專案自動化測試的實現。希望對你們有幫助，有說的不好的地方，還請多多指教！

1.允許測試腳本里呼叫api

我們經常在測試時要做一些準備活動，比如註冊一個新使用者。這一步驟可能每次花費幾分鐘時間，那麼這時候建議直接呼叫註冊使用者的api來生成新使用者。每個場景節約幾分鐘，加起來就多了。

2.允許測試腳本里訪問資料庫

雖然我們做測試可以說重點在介面上，但是業務邏輯上如果出錯了最好也要能找出來。也就是說，我的檢查點不止檢查頁面元素，更先去檢查對應資料在資料庫裡是否正確。好處是資料庫裡不正確的時候，指令碼就不用傻乎乎等個幾十秒才報出來頁面上的錯誤。

3.為測試準備獨立乾淨的測試環境

測試如果針對網站，很多時候要考慮在windows系統上跑指令碼。一般建議和工作用的電腦分開。如果有條件，還可以自動化搭建這樣的測試環境，我們以前是通過雲自動搭建符合要求的虛擬機器來做。

4.考慮測試邏輯的重要性

通常採用頁面物件建模，詳見selenium官網。如果是商業工具則一般已經自帶物件庫，如QTP等都自帶了。簡單來說就是同樣的測試邏輯封裝在一起，用的時候直接調，改的時候只改一個地方。

5.在開發階段考慮可測性

有的app就是不可測，這也動態那也動態，控制元件各種不標準，自定義。這種是沒法做自動化的。比如用selenium去測gmail的網頁版，一切都是動態的，那簡直瘋了也做不成功。相反比如說去看京東的網頁，各種標準，再沒有比它更適合用selenium測試的了。可測性每提升一丁點兒，自動化測試效率提升一大截。質的改變。

6.採用統一的設計和分層次的設計

有一個經典問題，在我去一些公司面試時被反覆問到，有一個測試場景會用到網站、桌面app、手機app，如何做自動化？

具體點我舉個例子，你在手機端拍了一張照片，上傳到了網盤上，放下手機在桌面端開啟這個照片並做了一些修改和美化，然後在網頁端把他展示出去。這個場景如何自動化測試？

如果採用統一的自動化測試設計應當可以解決。不管是桌面的網頁的還是手機的，對測試指令碼來說都是執行測試的庫去負責的，也就是說我寫測試只是寫業務邏輯，如何執行是那些庫的事情。第一層是測試邏輯層，第二層是測試實現層。

這樣分開的好處是：1.實現層的工具可能會換，2.可以測試複雜的場景，3，維護人員可以分開，降低測試邏輯層維護人員的技術要求，4，便於大團隊的協作。

7.允許半自動化測試

我曾經這麼做：指令碼負責截圖，我事後肉眼人工檢查截下來的圖，來判斷是否有介面錯亂之類的問題。好處是實現方便，不用搞什麼鬼的影象比對。影象比對完了之後你還是要瞄一眼截圖，不然你不放心影象比對的結果，事實上我自己光瞄幾眼就看完了所有圖片，每種介面截個一兩張就夠了。