前言：
作者簡介：渴望力量的哈士奇 ，大家可以叫我 哈士奇 ，一位致力於 TFS 賦能的博主
CSDN博客專家認證、新星計劃第三季全棧賽道 top_1 、華為雲享專家、阿裡雲專家博主
如果文章知識點有錯誤的地方，請指正！和大家一起學習，一起進步
人生格言：優於別人,並不高貴,真正的高貴應該是優於過去的自己。
如果感覺博主的文章還不錯的話，還請關注、點贊、收藏三連支持一下博主哦專欄系列（點擊解鎖） 學習路線指引 知識定位 Python全棧白皮書 零基礎入門篇 以淺顯易懂的方式輕松入門，讓你徹底愛上Python的魅力。 語法進階篇 主要圍繞多線程編程、正則表達式學習、含貼近實戰的項目練習 。 自動化辦公篇 實現日常辦公軟件的自動化操作，節省時間、提高辦公效率。 自動化測試實戰篇 從實戰的角度出發，先人一步，快速轉型測試開發工程師。 數據庫開發實戰篇更新中 爬蟲入門與實戰更新中數據分析篇更新中前端入門+flask 全棧篇更新中django+vue全棧篇更新中拓展-人工智能入門更新中網絡安全之路 踩坑篇 記錄學習及演練過程中遇到的坑，便於後來居上者 網安知識掃盲篇 三天打魚，不深入了解原理，只會讓你成為腳本小子。 vulhub靶場漏洞復現 讓漏洞復現變得簡單，讓安全研究者更加專注於漏洞原理本身。 shell編程篇 不涉及linux基礎，最終案例會偏向於安全加固方向。 [待完結] WEB漏洞攻防篇2021年9月3日停止更新，轉戰先知社區等安全社區及小密圈 滲透工具使用集錦2021年9月3日停止更新，轉戰先知社區等安全社區及小密圈點點點工程師 測試神器 - Charles 軟件測試數據包抓包分析神器 測試神器 - Fiddler 一文學會 fiddle ，學不會倒立吃翔，稀得！ 測試神器 - Jmeter 不僅是性能測試神器，更可用於搭建輕量級接口自動化測試框架。 RobotFrameWorkPython實現的自動化測試利器，該篇章僅介紹UI自動化部分。 Java實現UI自動化文檔寫於2016年，Java實現的UI自動化，仍有借鑒意義。 MonkeyRunner該工具目前的應用場景已不多，文檔已刪，為了排版好看才留著。
緊接著上一章節，在今天的這一章節我們來具體聊一聊 APP 自動化測試工具的演進史。所以在該章節具體跟大家介紹的其實就是常用的、或者是以前見過的 APP 自動化測試工具都有哪些？以及我們為什麼要使用 APPIUM ，它的優勢又在哪裡。
大概在 2010年 前後，APP自動化測試還只是一個萌芽狀態。最早的自動化測試工具其實就是安卓本身自帶的測試框架 Instrumentation ，這樣的一個測試框架其實是現在也是未來很多測試框架的基礎。
Instrumentation 這個框架其實非常的簡陋，底層的支持也不是太好，使用起來不是太方便，同時最大的缺點是不支持跨應用。而且封裝也非常的簡單，基本上就是直接去調用 安卓的源碼包 ；（這種方式讓大家寫起自動化來非常的難，而且那個時候 selenium 已經普及開來了，大家非常適用這種簡單的高封裝性的寫法），所以 Instrumentation 並沒有流行開來，只是在小范圍內，沒有辦法的情況下才會選擇使用。
由於 Instrumentation 封裝的不夠好，後來就出現了基於 Instrumentation 框架開發的 Robotium ，“Robotium” 對於一些常用的操作進行了一些封裝，封裝成了我們習慣性使用的自動化指令。
在後來的使用過程中發現，這個 Robotium 高度封裝了關於安卓底層的一部分，而且在當時也有一些像 flash 的類似組件、和IOS系統的設備都沒有辦法支持。
所以雖然它火了一段時間，但是仍然逐步的被 APP 自動化領域拋棄掉了。
接下來，谷歌方面就開源了各種各樣的開源組件。第一個給出的就是 UIAutomator ，“UIAutomator” 是現在我們做自動化的一個核心的基礎。它提供的這樣一套開源框架呢包含了 API 的 JAVA 庫，用來創建功能性的UI測試。並且有了一套自己的 APP 測試引擎，能夠結合著 Junit 、TestNG來進行一些測試案例的寫法。
但是谷歌維護起來這樣一套 UIAutomator 是非常困難的，所以它的社區資源完全已谷歌自己的為主，並不太完善。而且大家使用的程度也不是特別的高，同時受限於當時的安卓版本限制，只對 Java 支持的特別好，對其他語言的支持非常差，所以 UIAutomator 沒有火起來。但是它奠定了 自動化測試的核心的一個底層，包括現在使用的 "APPIUM" 的底層其實就是借鑒了 "UIAutomator" 的大部分內容 。
隨著 UIAutomator 的不太成功，谷歌又推出了一個精簡、快速的自動化測試框架 Espressp 。這樣一個框架也是開源出來的，非常的小、也非常的輕量級。編寫代碼起來非常的簡單，開始它僅僅是基於 Instrumentation 的高度封裝，沒有突破 Instrumentation 裡面的問題，比如說跨應用等問題都沒有解決。
隨著谷歌的這兩款工具的使用的減少，行業裡開始有一些人開始自己動手做工具。谷歌都沒有做好的事情，可能很多人都覺得自己做起來可能也很困難，但實際上呢有一批這樣的人算是測試開發領域的領路人，他們做了一套屬於自己的一套自動化測試工具。該工具的底層非常高度的借鑒了安卓的UIAutomator ；對於 IOS 的支持，其實是使用了 IOS 自己內部的框架 UIAutomation ；使用了這兩套框架的組合，實現了雙平台支持的 APPIUM 這樣一款工具。這款工具的出現，真的是讓大家覺得終於能有一個方式能用一套代碼同時支持我們的IOS和安卓。
同時該工具的寫法上拋棄了原有的 UIAutomator 、UIAutomation 的寫作習慣，開始綁定了 selenium2.0 之後出現的 webdriver 的語法，將這樣的語法利用在了我們的安卓移動端上的測試，開發人員就可以使用 webdriver 來兼容任何一個語言。（比如 Java、Python、Ruby…）這些都可以編寫自動化腳本，這就是 APPIUM 的優勢。
那麼 APPIUM 有沒有缺點呢? 其實也是有的，比如說它的封裝性非常的強，但是當我們想要對底層進行一些二次開發的時候，它的二次開發沒有那麼的友好。所以雖然 APPIUM 是開源的，但是很多人基於它做了二次開發但是並不太成功，所以大家在使用上依然沒有跳出 APPIUM 給大家設定好的規則。但是這並不能代表這個工具就有很大的缺點，只能說 APPIUM 本身的支持就非常的全面。
直到現在，雖然 APPIUM 誕生了很多年了，大家仍然依賴、習慣於是用它。
當然了，並不說 APPIUM 的出現就導致不在有其他的工具誕生了。在這之後出現了一款叫做Calabash 的工具，它也是一個跨平台的 APP 測試框架。它所測試的東西並不像 APPIUM 這樣面面俱到，主要是用來測試屏幕截圖、手勢等一些曉得功能。
最主要的是該款工具綁定了另外一種設計模式，支持的是一種叫做 Cucumber 的 行為驅動模式 。“行為驅動模式” 其實就是另外一種模式的關鍵字驅動，只不過呢我們將它的行為取代了關鍵字而已。本質來說，在自動化測試領域體系裡面，它的提升並不是太高。
同時 Calabash 也有很多自己的缺點，比如說它運行起來非常的慢，就像早期的 APP自動化測試工具一樣 ，默認都要先安裝 APP 。哪怕是已經安裝好了，也會重新安裝一遍；在語言上，除了 ruby 之外，對其他的語言支持也不是很友好。這就是 Calsbash 目前最大的問題 。
目前，在行業裡。提到APP自動化測試，大家默認的一個方式就是使用 APPIUM 。所以後續的章節，也是完全基於 APPIUM 來為大家進行的講解。
見下圖：
實際上大家在後面使用 APPIUM 的時候就會發現調用的速度會很慢，造成這個原因的其實就是上圖中的示意。
我們編寫的腳本通過 HTTP 底層的 TCP 鏈接到 APPIUM 的 Server ，再通過 Server 來確認鏈接的設備是安卓還是IOS等等等等，同時在回去加載對應的 adb 等非常多的設備管理工具，綜合的完成了一套這樣的框架來實現腳本的預期結果。
OK，對於 APP 自動化測試、對於 APPIUM 的一些簡單的介紹就見到這裡，從下一章節開始，一起來真的使用 APPIUM 這款工具，看看它是不是真的那麼的好用。
拜了個拜…
