1.1 移動自動化測試現狀

因為軟件行業越來越發達，用戶的接受度也在不斷提高，所以對軟件質量的要求也隨之提高，當然這個也要分行業，但這個還是包含了大部分。因為成本、質量的變化現在對自動化測試的重視度越來越高，在幾年前自動化測試還沒有像現在這么普及，但是現在隨便去一家公司面試都會問到自動化測試，當然這個和他們公司是否運用到另說。

但是不言而喻的是大家都意識到了軟件測試這個行業都走向了自動化這條路。或許你認為實施自動化可能不是必須的，可能在你的觀念中測試思想是最重要的，所謂的自動化工具或者框架都是用來輔助的，但是作者想告訴你的是：計算機行業的發展、軟件測試行業的發展其實就像工業革命一樣，為的是通過此途徑解決人類手工勞動的復雜性，當然可能并不一定是這幾年出現，但是如果我們不學習肯定會被時代淘汰。

對于現在的我們來說自動化測試是我們必須掌握的技能，同時它也是這個行業的一種發展趨勢，當然你想要提高到更高的一個檔次可以往測試開發走，我堅信你能夠走得更遠。

1.2 本課程目標

因為作者也是從一個初學者過來的，而且在初學的過程中走了許多的彎路，所以作者希望通過本書帶領讀者從一個初級用戶到高級用戶，從不會到自己能夠獨擋一面。

我們共同的目的是先掌握android的基礎知識、appium相關環境知識、python的基礎知識、常見api的使用以及封裝、日志的收集、報告的生成、再是我們常用的數據驅動、頁面驅動，還有后面的unittest框架的介紹以及使用。

1.3 自動化測試流程

無論在做什么事情之前都需要掌握其流程，自動化也是一樣，我們首先要掌握的就是流程，如果你連最起碼的流程都無法掌握，那么你也沒辦法做好自動化。作者將通過自己的項目經驗來寫，當然這個不一定就是標準的答案，所以如果有覺得不符合的也不要吐槽，可以提出來一起討論。

我們通過下面的圖片來了解

可能有的人會有疑問說：這個怎么看就是一個v模型呢？這個作者只是為了讓大家更容易理解這樣編寫的。可能還有人會說我們做自動化為什么不是直接拿著需求就開始寫代碼，浪費那么多時間去做其他的有什么好處呢？我們來一 一講解。

現在我也找了很多測試的朋友，做了一個分享技術的交流群，共享了很多我們收集的技術文檔和視頻教程。
如果你不想再體驗自學時找不到資源，沒人解答問題，堅持幾天便放棄的感受
可以加入我們一起交流。而且還有很多在自動化，性能，安全，測試開發等等方面有一定建樹的技術大牛
分享他們的經驗，還會分享很多直播講座和技術沙龍
可以免費學習！劃重點！開源的！！！
qq群號：310357728【暗號：csdn999】

1、需求了解：當給你一個需求或者一個系統讓你去做自動化的時候你什么都不知道你就去做自動化能行嗎？你不去分析需求或者系統的哪些模塊兒適合做自動化你怎么去做？如果盲目的去做，當你做到后面的時候可能你框架還沒弄好需求或者系統又變了，那你是否做了無用功？所以我們第一步一定是確定需求或者系統哪些模塊適合做自動化，而且一定要明白這個需求或者系統做自動化給我們帶來的好處是什么，而不是說做自動化就是為了表示我們會做。

2、需求分析：和需求了解有類似之處，我們在這個期間主要做的就是分析需求或者系統哪些模塊適合做自動化，做自動化給我們的好處是什么，為后期方案提供參考，提供可用信息。

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

4、環境準備：這個最好理解，方案選擇好之后就該準備環境了。這個環境不會像大家想的那樣配置一個jdk、appium、ide就行了，你需要考慮的是appium的版本、持續集成、代碼管理等等問題，這個詳細內容在后面框架部分作者會講到。

5、系統設計：剛開始接觸自動化的小伙伴可能對這個比較陌生，不知道什么叫做系統設計，不用擔心。在做自動化的時候大家是否考慮過一個問題：在自動化過程中我們公用的東西是怎么提取出來的，為什么要按照不同的包結構來進行框架搭建，為什么不能夠是所有的都在一個包下或者一個類下面？我們簡單的看一下下面這個圖片:

從圖片中我們能夠看出在這個工程中我們有專門存放app的地方，有單獨的配置文件、case、以及讀取配置文件的地方，共同的特點就是他們都沒有在一起，這還只是一個簡單的例子，在以后我們的工作中這個是最常見的，在開發之前我們就需要把這些規劃好，因為一個項目往往是一個團隊來做，那么大家肯定是先劃分模塊，分工，在后期還會涉及到一些模塊間的調用。目的就是讓我們一目了然的就知道這個包是做什么的，把公用的都提取了，各司其能。

6、編碼：編碼故名思意就是編寫代碼，只是這里我們的編寫代碼是根據事先寫好的用例來進行編寫代碼。

筆者在這里說一個題外話，這個也是很多初學者會面臨的一個問題，這也是為什么很多人看了一些自動化的資料但是一直無法做自動化的原因。在很多的公司自動化會分兩個組，一個是開發測試框架，一個是寫測試用例，這里的測試用例是自動化的case，不要理解錯。

7、執行：執行是整個自動化展示成果的重要一部，最后的結果我們看到的是執行了多少case，通過多少，通過率是多少，失敗的為什么失敗。這也是領導或者其他相關人員想看到的數據。

那么為了這一步我們的自動化要做多少準備呢？作者會在本書中一 一給大家講解。

1.4 自動化測試用例的編寫

自動化測試用例和我們常用的功能測試用例雖說區別不是很大，但還是有一定的區別，下面我們用登陸功能來舉例：

功能冒煙用例：

（備注：因為格式原因所以表格里面沒辦法調整，用例中步驟1=>1，以此類推）

上面圖片就是一個簡單登陸冒煙測試，自動化的用例不同之處在于更仔細。來我們直接通過下面的用例來給大家講解：

自動化登陸用例：

通過上面的用例我們不難看出自動化和功能測試用例最大的區別在于自動化要求更詳細，信息更加準確，當然這個并不是完全標準的，這個只是作者在工作中和接觸的人中大家基本都用的類似用例。很多公司設計用例的和將用例轉換為自動化腳本的并不一定是同一個人，所以我們需要保證的是別人看見你的自動化測試用例能夠準確的編寫出測試腳本，這也是我們的目的。

END今天的分享就到此結束了，點贊關注不迷路！