作為一個在軟體和網際網路行業浸潤了20年的老兵，我接觸了很多公司，也面試了很多人，發現國內現在能實現APP的UI自動化測試的公司很少，我的一個之前在淘寶測試團隊工作的同事也講，在淘寶也是部分實現了自動化測試，因為很多業務變化很快，實現自動化測試意義不大。我面試過的很多測試人員，有些是工作了快10年的也是這種觀點。我們公司是一個創業型的汽車後市場O2O企業，因為老闆的平臺化戰略，我們的APP非常龐大，安卓我們有5個APP，IOS我們有4個APP，功能覆蓋洗車，保養，維修，拼車，租車，代駕，交友朋友圈等等，功能複雜度堪比淘寶，也不是我這裡吹牛，大家下載看看就知道了，在應用寶搜尋”逸休聯盟”就可以看到了。

因為我們基於精兵戰略，我們的開發和測試人數一直都很少，安卓和IOS開發巔峰時候也就是各自5個人，現在縮減到各自3人，測試人員從之前的2人變成了1人。因為是個創業公司，我們的業務現在還是非常不穩定，功能經常是變來變去，這也是很多創業公司遇到的，但我們還有2個困難，功能龐大，人員少，根據我的瞭解很多創業公司的功能比我們少很多，但人員多很多，提升開發效率和測試效率就變成了我們需要解決的問題。今天這裡，我主要談談我們怎麼樣基於現在流行的Appium解決自動化測試的問題。

上面是我們APP的架構圖，安卓和IOS都是相同的，獨立元件層是一個重用性非常高的模組，只依賴安卓和IOS自身類庫，和知名的類庫，如百度地圖等，這個模組可以脫離我們APP使用。在這個層上面，網路層是和後臺進行互動的，一切資料請求包括圖片都通過這個層面，我們學習了幾個開原始碼基礎上面獨自開發的，這樣做的考慮有很多，這裡不在多講了，如果有興趣，請關注我後面的文章。資料模型層用於和後臺的資料互動，也同時用於APP介面的VIEW的互動。專案元件層是專案當中可以重用的元件，因為依賴資料模型，不能獨立出來。最上面一層就是我們的外掛層，就是具體的業務功能實現。

其實自動化測試需要解決下面幾個棘手的問題：

1.    怎麼樣找到能夠完成這個工作的人

2.    怎麼應對頻繁的業務變化和UI變化

3.    怎麼樣設定斷言，怎麼樣建立標準庫

我面試非常多的測試人員，發現真正懂自動化測試的人太難找，如果應要找就得去BAT挖人了，這當然是不現實的。很多測試人員是不會程式設計的，即使會程式設計，也是太低階的水平。我們的辦法是測試人員和開發人員合作完成，開發人員程式設計能力很強，但他們不知道怎麼去做測試，他們互相合作形成優勢互補解決了人員問題。這個合作關係當中，測試人員就是產品經理，開發人員通過理解他們的測試用例，來形成需求文件設計。我們的目標是基於我們的APP，開發一個測試框架，這個測試框架具有很高的重用性，可以大大降低測試人員的程式設計門檻，他們只要簡單的呼叫幾行API就完成了測試，測試人員關注的是測試的流程和角度，不需要關心具體底層的實現。下面是我們的工程截圖：

我們的測試工程包含了兩個包，一個是開發人員維護的，一個測試人員維護的，開發人員去學習Appium框架和API，基於Appium設計和開發出我們自己的框架，同時可以測試IOS和安卓，測試人員不需要去關心這兩個平臺的區別，因為IOS和安卓的功能都是相同的，所以他們是可以只寫一套測試程式碼的，下面是測試人員的程式碼：

雖然這是首頁的更換城市，我們還有很多其它需要更換城市的地方，其實就是需要換個ID就行了，測試人員是知道怎麼通過工具獲得ID的，而且這些ID也是相對比較穩定的。

這是一個相對複雜的測試用例，對於測試人員只要知道理解我們的API就行了。

怎麼樣應對業務和UI的快速變化沒有一個統一的解決辦法，這是需要針對不同情況找不同的辦法，但前提是我們需要對產品，開發和測試有個全域性的考慮，從而發現解決的辦法。因為我們的軟體是基於元件化開發的，實現快速應變有著先天的優勢。我們元件化提升我們的開發效率，同時在測試方面我們也應用了針對元件的元件化測試。下面我來舉例說明一下，當然這只是我們解決的問題當中的2種類型：

搜尋排序是一個非常常見的場景，所有電商APP都有這個場景，我們的也不例外，下面是一些我們的場景圖：

上面兩個圖，一個是進行商家查詢，一個是進行服務查詢，這兩個場景看似不同，但對我們測試框架來講實現是一樣的，沒有區別，我們的介面都是元件化的。比如左邊的截圖包含了題頭元件+地址選擇元件+賽選元件+列表元件，右邊截圖也包含了相同的元件，我們的題頭元件定義了很多不同展示形式，其實都是一種元件，因為我們的測試框架也是針對元件做的，自然就保證了測試用例的靈活性。上面的賽選排序測試用例就簡化成了下面這樣，就幾行程式碼，我們的賽選條件可以只多級的，這個示例只是兩級，如果我們要設定地區條件排序條件，則filter(“行政區，登州市”)，sort(“好評優先”)，寫測試用例變得非常簡單和直接，如下圖所示：

其實這個賽選函式可以使用到很多地方，如車型選擇，城市選擇等等，我們的框架每個函式都是解決的一類問題，而不是一個問題，具有非常好的靈活性。

下面我講講怎麼建立介面變化的問題，拿商家查詢來講，列表當中的每個CELL，產品那邊是經常變化的，賽選條件也是經常變化的，賽選條件變化，我們就是把傳入的引數變化一下就行了，對於CELL的變化有稍微複雜些。做過測試的人都知道，測試這個商家列表，我們可以從很多角度進行測試，角度有：排序和賽選條件是否正常工作，正常查詢是否能進行，點選CELL是否能成功進入詳情等等。

因為CELL是經常變化的，但CELL的變化會影響我們排序和賽選的測試用例嗎？如果你使用截圖對比方式，當然是影響的，因為你的CELL變化了，說明標準圖例也必須變化，否則用例就是失效的。但如果我們使用邏輯進行判斷呢？情況就完全不同了，我們的CELL可以任意變化，但商家名稱這個欄位是永遠不變的，沒有商家名稱，這個列表也就沒有意義了，所以可以講這個欄位是100%肯定不會變化的，那麼通過擷取列表當中商家名稱的序列，我們就可以判斷排序和賽選條件是否有問題。比如，一組賽選和排序條件設定後，我們希望的商家排序是：

汽車快修保養，盛大汽車裝潢，大拇指汽車美容…

但實際上是：

汽車快修保養，大拇指汽車美容，盛大汽車裝潢

通過對比兩個LIST，我們就可以知道，排序和賽選邏輯是否發生了變化，程式是否出現了BUG，所以我們能做邏輯判斷的地方，就不會使用圖片對比判斷。使用邏輯判斷的另外一個好處就是，我們不需要考慮機器的適配性，安卓機器市面上太多了，每種機器的截圖都是可能不同的，勞動量顯然是我們這樣做的幾十倍。通過這個例子，我就是想說明一個道理，業務變化快是事實，但不能說自動化測試成本就會非常高，關鍵是產品+開發+測試的全域性的思維和解決問題的方式。

斷言的設定和標準庫的建立也是一個比較棘手的問題。我們有一個自動化測試標準庫，這個庫有的是生產資料，有的是後臺建立的資料，由後臺團隊進行維護和升級，這個資料庫表結構和生產環境保持同步，就是生產環境的一個特製版本，可以支援生產流程當中的全部業務邏輯。為了保證自動化測試的可重複性，我們使用的DOCKER技術進行映像回滾，APP測試框架可以通過SOCKET連線遠端觸發資料庫回滾和伺服器程式碼回滾。有了標準資料庫，下面就是怎麼建立對比標的資料。

前些時間我面試了一個做測試的老兵，8年做測試的經驗，曾經在阿里和百度都呆過，最後於2014年離開百度到了最近的一家公司。當時我問她的問題是，怎麼繼續斷言的邏輯比對。她給我的答案是，他們測試團隊也有開發，他們會程式設計從資料庫讀取資料，然後和APP的讀取資料進行比對。這雖然是個解決辦法，但測試人員需要有良好的開發技能，而且因為業務邏輯變化，他們測試團隊讀取資料庫的方式也需要不斷修改。我看過很多人的測試用例程式碼，包括一些國外的示範例子，很多人喜歡把測試斷言判定條件直接寫在程式碼上面，比如ASSERT(result==’example’)，這種Hardcode的方式重用性和維護性極差，我們的測試程式碼是絕對不允許這樣做的。我們提出了一個標的資料集的概念，標的資料集就是你需要對比的標準值，這個標準值可以是一段文字，數字，一個字串LIST（例如商家查詢的對比標的），也可以是圖片，可以是任何形式的資料，下面的資料就是怎麼來建立這些標的資料集。之前我在網上看到一些例子，都是人工去處理的，人工去設定到EXCEL表格當中，人工截圖然後放到指定的資料夾裡面，每次業務邏輯變化，這個標的資料集的建立本身就是一個費力的事情。我們的解決辦法是標的資料集建立的自動化，我們的框架裡面有兩個測試環境變數，一個是資料標定流程，一個是測試流程，測試流程不用講了，標定流程其實就是自動化生成標準資料流程。當測試手工完成業務測試後，我們就認為現在的資料可以作為標的資料集了，會啟動標的資料集流程，這個流程，系統會擷取介面資料，或者自動截圖，把這些資料儲存在我們規定的目錄之下。例如，前面的商家搜尋案例，系統會把商家名字排序擷取處理，儲存到一個字串LIST的資料集當中，同時也會截圖手機圖片，作為影象對比的標準圖片，並且儲存到對應的檔案目錄中。每個測試用例都需要加入一個數據標定流程，資料標定也提供了API，測試人員只要直接簡單呼叫就行，他不需要關心資料是怎麼擷取的，怎麼儲存，或者儲存到了什麼地方，他都不需要關心，他只需要指定需要針對什麼生成什麼資料集。例如，商家搜尋案例，測試需要指定，按照商家名稱的ID，生成一個字串LIST的資料集，其它的他都不需要去關心。

通過上面的一些措施，我們現在就一個測試人員來維護9個APP，如果有不能完成的測試用例流程，則讓開發人員協助幫助他完成。當然基於人員儲備考慮，我們後面會增加一個測試人員，保持2個測試人員水平。