Appium python自動化測試系列之移動自動化測試前提（一）

來自專欄猿論

1.1 移動自動化測試現狀

因為軟體行業越來越發達，用戶的接受度也在不斷提高，所以對軟體質量的要求也隨之提高，當然這個也要分行業，但這個還是包含了大部分。因為成本、質量的變化現在對自動化測試的重視度越來越高，在幾年前自動化測試還沒有像現在這麼普及，但是現在隨便去一家公司面試都會問到自動化測試，當然這個和他們公司是否運用到另說。但是不言而喻的是大家都意識到了軟體測試這個行業都走向了自動化這條路。或許你認為實施自動化可能不是必須的，可能在你的觀念中測試思想是最重要的，所謂的自動化工具或者框架都是用來輔助的，但是作者想告訴你的是：計算機行業的發展、軟體測試行業的發展其實就像工業革命一樣，為的是通過此途徑解決人類手工勞動的複雜性，當然可能並不一定是這幾年出現，但是如果我們不學習肯定會被時代淘汰。對於現在的我們來說自動化測試是我們必須掌握的技能，同時它也是這個行業的一種發展趨勢，當然你想要提高到更高的一個檔次可以往測試開發走，我堅信你能夠走得更遠。

1.2 本課程目標

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

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

1.3 自動化測試流程

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

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

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

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

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

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

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

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

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

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

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

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

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

1.4 自動化測試用例的編寫

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

功能冒煙用例：

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

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

自動化登陸用例：

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

作者： Mushishi_Xu

鏈接：https://www.imooc.com/article/23829

來源：慕課網

推薦閱讀：

Python玩轉人工智慧最火框架TensorFlow應用實踐

面對人工智慧，我們應有的態度

學習微服務首先要了解為什麼使用微服務

如何使用mock.js取代json-server模擬Ajax請求

Python中寫CLI行命令程序