1.自動化測試分類

分層測試

測試金字塔分層一般為三層：底層單元測試、中間層為介面測試、頂層為UI層。

移動APP的UI自動化測試長久以來一直是一個難點，難點在於UI的”變”, 變化導致自動化用例的大量維護。 從分層測試的角度，自動化測試應該逐層進行。

最大量實現自動化測試的應該是單元測試, 最容易實現也最容易在早期發現問題;

其次是介面級測試, 以驗證邏輯為目的進行自動化, 由於介面的相對穩定, 自動化測試成本相對也可以接受;

自動化成本最大的便是UI級自動化測試, 然而UI介面是直接反饋給使用者的效果展示,適度的尤其是BVT（版本驗證測試）級的自動化測試也是非常必要的。

常見三方自動化測試平臺

（目前有了一些第三方自動化測試平臺，是否還需要自己做自動化測試？）

目前存在的自動化測試平臺大多是基於相容性測試的平臺，主要測試app的安裝、啟動、退出、解除安裝等通用功能。無法滿足app特定功能測試需求（如測試登入、註冊）因此還需要測試人員自己手動根據自己產品特性來寫測試指令碼執行自動化測試。

常見第三方測試平臺

2.測試流程

需求分析：

當給你一個需求或者一個系統讓你去做自動化的時候你什麼都不知道你就去做自動化能行嗎？你不去分析系統的哪些模組兒適合做自動化哪些不適合 ？

如果盲目的去做，當你做到後面的時候可能你框架還沒弄好需求或者系統又變了，那你是否做了無用功？所以我們第一步一定是確定需求或者系統哪些模組適合做自動化，而且一定要明白這個需求或者系統做自動化給我們帶來的好處是什麼，而不是說為了自動化而做自動化。

方案選擇：

有的人可能對選擇方案會比較陌生，不知道這個到底是幹什麼的？那麼問你一個很簡單的問題，現在自動化測試框架常見的有robotium、appium、monkeyrunnner、UIAutomator等等，這麼多的框架你到底選擇哪一個呢？其實這就是一個方案的選擇，那麼有時候你也會根據你專案的需求去選擇一個更加適合的框架，讓我們這個需求實現利益最大化。

環境準備：

這個最好理解，方案選擇好之後就該準備環境了。這個環境不會像大家想的那樣配置一個jdk、appium、ide就行了，你需要考慮的是appium的版本、持續整合、程式碼管理等等問題。

系統設計：

系統設計主要是對整個測試框架系統進行合理的設計，比如各個公共模組的封裝，不同模組的檔案管理，配置資料和程式碼的分離、日誌管理等等。就像工程建設實現都是經過嚴格的方案設計，然後根據設計方案進行施工。

編碼：

編碼故名思意就是編寫程式碼，這裡我們的編寫程式碼是根據事設計好的用例來進行編寫程式碼。