移動端自動化測試策略

隨著移動互聯(lián)網(wǎng)的深入發(fā)展，移動端APP的需求不斷增加，越來越多的數(shù)字化企業(yè)開始注重其APP的建設(shè)。在市場競爭日益加劇的今天，互聯(lián)網(wǎng)為快不破的方法論也影響著當(dāng)下企業(yè)的決策。企業(yè)紛紛實行移動端產(chǎn)品的快速迭代模式：如阿里提出的2-1-1模式，美團(tuán)的單周發(fā)版節(jié)奏等，這也給研發(fā)團(tuán)隊帶來了移動端高效測試的壓力，各大公司紛紛開始了移動端自動化測試的探索與實踐之路。

相較于API自動化測試以及Web自動化測試而言，移動端自動化測試的實施成本相對較高，原因一方面是因為移動端由于Android與iOS兩大陣營都有自己獨立的生態(tài)體系，而且相比于Google的Android系統(tǒng), 蘋果的iOS 系統(tǒng)生態(tài)更加封閉一些：如只能依靠蘋果提供的工具鏈等。同時由于開源工具和框架還不夠穩(wěn)定和豐富，移動端自動化測試面臨了很多新的挑戰(zhàn)：不同的機型，系統(tǒng)版本，分辨率，網(wǎng)絡(luò)抖動等等，都會影響到自動化測試執(zhí)行的結(jié)果。要想在移動端做好自動化測試，團(tuán)隊需要制定與其項目相匹配的測試策略與方法。

01 - 移動端自動化測試策略設(shè)計

在設(shè)計移動端自動化測試策略的時候，我們可以思考以下幾個問題，看我們能否給出合理的理由：

1. 為什么要做移動端自動化測試，自動化測試的價值在哪里？

2. 你的項目中質(zhì)量內(nèi)建成熟度如何？

3. 如果單元測試足夠覆蓋的情況下，是否還有必要做端到端自動化測試？

4. 是否已經(jīng)有移動端專項測試體系了，如性能，安全，兼容性，穩(wěn)定性等？

5. 你的團(tuán)隊是否已經(jīng)有完善的基礎(chǔ)設(shè)施了，如Mobile CI/CD ?

   如果連打包，構(gòu)建，分發(fā)都不是自動且持續(xù)的，先解決這個問題，再來考慮自動化測試吧。要想富，先修路。

分層測試策略

如下圖Bagmar Anand所畫的測試金字塔所示：

在不同的層，我們所關(guān)注的重點會有所不同。

因此需要使用分層測試策略，制定不同的測試目標(biāo)：

1. 實現(xiàn)核心穩(wěn)定的用例自動化，用于每次的迭代回歸測試
2. 對于新功能或者頻繁變動的功能，采用手工探索性測試
3. APP 的可用性與UX測試，可以引入產(chǎn)品和設(shè)計人員參與測試
4. 對于一些UI樣式和兼容性等需求，使用自動遍歷測試
5. APP的穩(wěn)定性，可以采用隨機測試，并且采集測試過程中的設(shè)備性能數(shù)據(jù)
6. APP性能和安全測試，需要采用安全和性能專項測試策略

用例穩(wěn)定性設(shè)計

自動化測試用例的穩(wěn)定性和可維護(hù)性非常重要，關(guān)系到自動化的成效，需要關(guān)注以下幾點：

1. 使用穩(wěn)定的測試框架和工具

很多人喜歡造輪子，沒有對開源框架的優(yōu)缺點進(jìn)行評估和分析，就開始自己實現(xiàn)一個簡易版的框架和工具，在這里是不太推薦的，

一個穩(wěn)定的測試框架是自動化測試的基礎(chǔ)，在規(guī)?；淖詣踊瘻y試工程中，穩(wěn)定比靈活更加重要。我們可以在開源框架不符合需求的情況下，先進(jìn)行二次開發(fā)，也不要貿(mào)然就從零開始自己寫一個。

2. 失敗重試機制，智能等待策略，智能判斷等

自動化測試執(zhí)行過程中，可能會遇到各種各樣的突發(fā)異常，如網(wǎng)絡(luò)波動，內(nèi)存溢出導(dǎo)致APP進(jìn)程被系統(tǒng)強制殺死等，因此必須要考慮容錯處理，避免因環(huán)境的問題導(dǎo)致用例執(zhí)行失敗。

3. 好的測試用例設(shè)計方法

好的用例設(shè)計方法，可以使我們的用例具備更好的可維護(hù)性以及可讀性。我們可以采用以下幾種業(yè)內(nèi)常用的設(shè)計方法：

1. Page Object Model
2. BDD
3. Data Driven / Keywords Driven

02 - 移動端自動化測試框架

好的測試框架需要具備以下九個特點：

1. 穩(wěn)定性（框架必須有很多真實的使用案例，并且有穩(wěn)定的版本，以及社區(qū)持續(xù)維護(hù)）
2. 可擴展性 （用戶可以很方便進(jìn)行二次開發(fā)）
3. 清晰的架構(gòu) （框架的設(shè)計必須清晰，模塊化）
4. 易于使用 （讓測試開發(fā)人員可以用更多的精力投入用例編寫上，而不是去耗費時間熟悉框架）
5. 跨平臺支持（windows, linux, macos）
6. 可集成性 （可以與不同的CI平臺集成，如Jenkins, GoCD, Bamboo等）
7. 報告 （有易讀的測試報告）
8. 日志 （有友好的日志與錯誤提示）
9. 技術(shù)棧支持 （可以支持多種語言技術(shù)棧工具）

業(yè)內(nèi)有很多開源的測試框架，大部分具備上述這些特點，如開源社區(qū)的Robot Frameowork, Cucumber, 提供商業(yè)支持的Katalon, 以及阿里的Macaca 和網(wǎng)易的Airtest等，深入研究其中一種即可，詳情可以參見這些項目的官網(wǎng)。

Robot Framework: https://robotframework.org/

Cucumber: https://cucumber.io/

Katalon: https://www.katalon.com/

Airtest: http://airtest.netease.com/

Macaca: https://macacajs.github.io/zh/

03 - 移動端測試工具

工欲善其事，必先利其器

選擇移動端測試工具，目前業(yè)界使用比較多的移動端自動化測試工具有Appium, 它可以同時支持Android和iOS 模擬器和真機的自動化測試。下圖是Appium的一個技術(shù)原理圖。Appium采用B/S架構(gòu)設(shè)計，整體分為服務(wù)端和客戶端兩個部分，Appium服務(wù)端是用nodejs實現(xiàn)的，提供REST API 服務(wù)的一個WEB服務(wù)器，主要是用來管理測試執(zhí)行和結(jié)果反饋的。Appium客戶端則提供了多種語言的三方庫支持，可以方便開發(fā)人員使用自己熟悉的語言調(diào)用Appium客戶端三方庫來與Appium服務(wù)端進(jìn)行交互。

為什么Appium是使用最廣的移動端自動化工具，這也與它的設(shè)計理念有關(guān)：

Appium 的理念

Appium 旨在滿足移動端自動化需求的理念，概述為以下四個原則：

1. 你不應(yīng)該為了自動化而重新編譯你的應(yīng)用或以任何方式修改它。
2. 你不應(yīng)該被限制在特定的語言或框架上來編寫運行測試。
3. 移動端自動化框架不應(yīng)該在自動化接口方面重造輪子。
4. 移動端自動化框架應(yīng)該開源，在精神、實踐以及名義上都該如此。

04 - 執(zhí)行自動化測試

自動化測試腳本不僅僅是本地執(zhí)行，從下圖 DORA 給出的《2019 DevOps 報告》中可以看出，持續(xù)自動化測試是未來的趨勢，因此必須要將自動化測試腳本集成到CI環(huán)境中。

一個好的持續(xù)測試需要關(guān)注以下四點：

速度 （Speed）
可靠性 （Reliability）
數(shù)量 （Quantity）
維護(hù)性（Maintenance）

05 - 測試腳本管理

自動化測試工程腳手架

自動化測試工程腳手架的目的是用于快速初始化一個測試工程項目，并且引入一些最佳的規(guī)范實踐。同時對測試工程模塊化劃分，更有利于測試用例的開發(fā)與維護(hù)。

測試腳本版本控制管理

測試腳本也需要進(jìn)行版本化管理，這樣可以方便多人協(xié)作用例的開發(fā)維護(hù)，同時使用一定的分支策略，也保障了測試腳本的穩(wěn)定性。

腳本可維護(hù)性

BDD + PageObject 構(gòu)建可讀性與可維護(hù)性的用例

1. 用BDD的方式來編寫測試用例，基于Gherkin語法，Given-When-Then這樣的用例更加易讀。

2. 使用PageObject來對UI頁面和頁面上的操作進(jìn)行封裝與頁面對象建模，從而實現(xiàn)對上層用例屏蔽底層的具體實現(xiàn)細(xì)節(jié)，達(dá)到更好的功能復(fù)用。

06 - 自動化測試成效度量

我們可以通過一些指標(biāo)來度量自動化測試的效果，并且快速給出反饋。

其他細(xì)節(jié)指標(biāo)還有很多，可以選擇團(tuán)隊中關(guān)注的部分來統(tǒng)計度量：

1. 自動化測試需求覆蓋率
2. 自動化測試在測試用例中的占比
3. 自動化測試通過率/失敗率
4. 缺陷逃逸率
5. 缺陷發(fā)現(xiàn)率
6. 自動化測試執(zhí)行時間
7. 自動測試失敗流水線終止比率
8. Flaky Test不可靠測試用例數(shù)
9. 更多......

附圖：統(tǒng)一自動化測試架構(gòu)

我們可以用開源的框架和工具快速搭建一套多端自動化測試架構(gòu)，并且具備高度的可擴展性。

工具清單??

1. 通用測試框架：Robot Framework
2. APP測試工具：Appium
3. Web測試工具：Selenium
4. API測試工具：Requests
5. iOS底層框架：XCUITest
6. Android底層框架：Google UIAutomator2
7. 持續(xù)集成平臺：Jenkins
8. 消息通知平臺：Slack, 企業(yè)微信, Email
9. 云測平臺：Testin, SauceLabs, BrowserStack
10. 執(zhí)行環(huán)境：Docker

Q&A

1. 如果單元測試足夠覆蓋的情況下，是否還有必要做端到端自動化測試？

從測試金字塔中可以看出，每一層的側(cè)重點不同，而且都是不可或缺的。
這是因為單元測試是對軟件中最小的單元進(jìn)行功能驗證和測試（從內(nèi)部結(jié)構(gòu)上），完備的最小單元功能的測試覆蓋率
并不能保證端到端不出問題。而UI端到端自動化測試是對
軟件提供的端到端業(yè)務(wù)功能模擬用戶操作進(jìn)行驗收（從外部行為上）。并且基于2/8原則：用戶最常用的功能大致占
軟件所提供功能的20%，我們可以重點保障高業(yè)務(wù)價值，且穩(wěn)定的核心功能自動化，加快回歸測試效率，同時
可以增強團(tuán)隊信心。

2. 如果團(tuán)隊已經(jīng)實現(xiàn)了95%甚至更高的單元測試覆蓋率，“是否還有必要做端到端自動化測試”呢？

高百分比的單元測試覆蓋率并不直接等同于高代碼質(zhì)量，也可能出現(xiàn)需求漏做，異常漏處理等情況。更不能直接等同于業(yè)務(wù)功能需求的覆蓋率。
單元測試有其自身的價值，如增強重構(gòu)信心等；但是不能說100%的單元測試，就不需要其他測試手段，除非我們明確知道單元測試和外部行為的映射
關(guān)系，那么通常我們不太好說單元測試對外部行為的影響，因此也不能完全依賴于單元測試，而是需要多種測試手段從不同維度來保障系統(tǒng)功能正確性。

3. 對于移動端的可測性，目前有無相對成體系的評價標(biāo)準(zhǔn)？

移動端應(yīng)用的可測性相對于API或者Web UI而言，還是偏低的；網(wǎng)絡(luò)/數(shù)據(jù)，應(yīng)用狀態(tài)，APP內(nèi)部存儲等都缺乏可觀察性，對可測性也帶來了挑戰(zhàn)；

目前業(yè)內(nèi)也都在探索一些移動端可測性的一些方法，比如通過deeplink來直接進(jìn)入到待測頁面，避免前序路徑復(fù)雜或者難以到達(dá)等，或者M(jìn)ock數(shù)據(jù)來構(gòu)造場景驗證UI功能等，不過體系化的評價標(biāo)準(zhǔn)，目前還沒有，大家都還在積累一些實踐經(jīng)驗。