1、UI自動化測試簡介
軟件測試簡介
軟件測試是伴隨著軟件開發(fā)一同誕生的，隨著軟件規(guī)模大型化，結(jié)構(gòu)復(fù)雜化，軟件測試也從最初的簡單“調(diào)試”，發(fā)展到當(dāng)今的自動化測試。
自動化測試是什么呢？自動化測試是把以人為驅(qū)動的測試行為轉(zhuǎn)化為機(jī)器執(zhí)行的一種過程，自動化測試通常會借助某些工具或者框架。雖然不能完全取代手工測試，但相比手工測試來講，自動化測試可以減少人力成本，降低重復(fù)工作，從而更快速、高效的進(jìn)行測試活動。
測試金字塔是一種自動化測試過程的金字塔形策略結(jié)構(gòu)，用來指導(dǎo)軟件開發(fā)過程中各層測試投入的工作量比例，其最早由Mike Cohn在2009年的著作《Scrum敏捷軟件開發(fā)》中提出。Mike Cohn在書中指出：測試金字塔從上到下分為三層，分別是UI測試、服務(wù)/接口測試、單元測試，越接近金字塔底部的測試活動，投入的工作量應(yīng)該越多，即單元測試投入工作量最多，接口測試次之，UI測試投入最少。
UI測試
UI測試是最接近軟件真實(shí)用戶使用行為的測試類型。通常是模擬真實(shí)用戶使用軟件的行為，即模擬用戶在軟件界面上的各種操作，并驗(yàn)證這些操作對應(yīng)的結(jié)果是否正確。
接口測試（API測試）
API測試，主要針對的是各模塊暴露的接口，通常采用灰盒測試方法。首先以黑盒方式設(shè)計(jì)如何調(diào)用API的測試用例，同時(shí)在測試執(zhí)行過程中統(tǒng)計(jì)代碼覆蓋率，然后根據(jù)代碼覆蓋率情況來補(bǔ)充更多、更有針對性的測試用例。
單元測試
單元測試，屬于白盒測試的范疇，通常由開發(fā)工程師自己完成，越早發(fā)現(xiàn)缺陷其修復(fù)成本越低。
為什么要做 UI 自動化？
隨著不停的版本迭代，軟件新增功能變的越來越多，對測試資源的需求也變得越來越大，執(zhí)行人工測試的時(shí)間越來越長。對于人工測試的依賴開始變得棘手，因此大家開始尋找解決方案，UI 自動化也應(yīng)運(yùn)而生。
人工測試存在以下的弊端：
- 人工回歸測試需要花費(fèi)很長時(shí)間才能完成，很小的延遲就會讓發(fā)布面臨風(fēng)險(xiǎn)。
- 發(fā)布節(jié)奏受到人工回歸測試的限制。兩天以上的人工回歸測試意味著最好的情況下能夠一個(gè)月發(fā)布兩次。而且，開發(fā)者需要一次性發(fā)布所有東西。要么全部發(fā)布，要么什么都發(fā)布不了，因?yàn)樾枰獙⑺袞|西一起測試。
UI 自動化測試存在以下的優(yōu)點(diǎn)：
解放了測試團(tuán)隊(duì)針對臨時(shí)的和探索性案例的測試時(shí)間；
可以一邊開發(fā)一邊進(jìn)行回歸測試，減少等待時(shí)間；
可重復(fù)性使用，快速進(jìn)行回歸測試；
更好的利用資源（周未/晚上的資源空閑時(shí)段）。
UI 自動化測試的特點(diǎn)
了解到為什么要選擇UI自動化測試之后，我們需要了解UI自動化測試的使用場景。UI 即 User Interface（用戶界面）的簡稱，UI 自動化做的事情就是模擬用戶行為進(jìn)行操作，完成對用戶界面的測試。這也就從本質(zhì)上限制了它的使用場景：
- 軟件需求變動不頻繁
- 產(chǎn)品更新維護(hù)周期長
- 比較頻繁的回歸測試
- 自動化測試腳本可重復(fù)使用
所以在開始之前，我們最好先認(rèn)識清楚哪些業(yè)務(wù)場景是可以自動化測試的。
2、Android UI自動化測試工具
UI自動化測試經(jīng)過多年的發(fā)展，也已經(jīng)涌現(xiàn)出很多優(yōu)秀的測試工具。下面簡單介紹一下Android測試領(lǐng)域內(nèi)的一些常見的測試工具。
1、Monkey
是Android SDK自帶的測試工具，在測試過程中會向系統(tǒng)發(fā)送偽隨機(jī)的用戶事件流（如按鍵輸入、觸摸屏輸入、手勢輸入等)，實(shí)現(xiàn)對正在開發(fā)的應(yīng)用程序進(jìn)行**壓力測試**，也有日志輸出。實(shí)際上該工具只能做程序做一些壓力測試，由于測試事件和數(shù)據(jù)都是隨機(jī)的，不能自定義，所以有很大的局限性。
2、MonkeyRunner
也是Android SDK提供的測試工具。嚴(yán)格意義上來說MonkeyRunner其實(shí)是一個(gè)Api工具包，比Monkey強(qiáng)大，可以**編寫測試腳本**來自定義數(shù)據(jù)、事件。Monkeyrunner 足夠強(qiáng)大了，但是錄制的腳本是以**坐標(biāo)軸來作為定位方式**，而安卓設(shè)備類型眾多，各種分辨率，所以移植性不好。
3、Instrumentation
是早期Google提供的Android自動化測試工具類，雖然在那時(shí)候JUnit也可以對Android進(jìn)行測試，但是Instrumentation允許你對應(yīng)用程序做更為復(fù)雜的測試，甚至是框架層面的。通過Instrumentation你可以模擬按鍵按下、抬起、屏幕點(diǎn)擊、滾動等事件。
Instrumentation是通過將主程序和測試程序運(yùn)行在同一個(gè)進(jìn)程來實(shí)現(xiàn)這些功能，你可以把Instrumentation看成一個(gè)類似Activity或者Service并且不帶界面的組件，在程序運(yùn)行期間監(jiān)控你的主程序。
缺點(diǎn)是對測試人員來說編寫代碼能力要求較高，需要對Android相關(guān)知識有一定了解，還需要配置AndroidManifest.xml文件，不能跨多個(gè)App。
4、UiAutomator
也是Android提供的自動化測試框架，基本上支持所有的Android事件操作，對比Instrumentation它不需要測試人員了解代碼實(shí)現(xiàn)細(xì)節(jié)（可以用UiAutomatorviewer抓取App頁面上的控件屬性而不看源碼）?；贘ava，測試代碼結(jié)構(gòu)簡單、編寫容易、學(xué)習(xí)成本低，一次編譯，所有設(shè)備或模擬器都能運(yùn)行測試，能跨App（比如：很多App有選擇相冊、打開相機(jī)拍照，這就是跨App）。缺點(diǎn)是只支持SDK 16（Android 4.1）及以上，不支持Hybird App、WebApp。
5、Espresso
是Google的開源自動化測試框架。相對于UIAutomator，它的特點(diǎn)是規(guī)模更小、更簡潔，API更加精確，編寫測試代碼簡單，容易快速上手。因?yàn)槭腔贗nstrumentation的，所以不能跨App。
6、Selendroid
基于Instrumentation的測試框架，可以測試Native App、Hybird App、Web App，但是網(wǎng)上資料較少，社區(qū)活躍度也不大。
7、Robotium
也是基于Instrumentation的測試框架，目前國內(nèi)外用的比較多，資料比較多，社區(qū)也比較活躍。缺點(diǎn)是對測試人員來說要有一定的Java基礎(chǔ)，了解Android基本組件，不能跨App。
8、**Appium **
Appium 是目前最主流的移動測試自動化框架，不僅支持 Android 應(yīng)用，而且適用于 iOS、混合和 Web 應(yīng)用程序。
它底層完全使用了 Selenium 和 WebDriver 的 API，所以如果你之前有用過 selenium, 幾乎不需要額外的學(xué)習(xí)成本就可以使用 appium。appium 通過 uiautomator（API 級別 16 或更高）和 Seledroid（API 級別低于 16）支持 Android，但是你不需要具體懂這兩個(gè)框架的具體用法，appium 都已經(jīng)幫你封裝成了統(tǒng)一的使用規(guī)則。Appium 的優(yōu)勢之一是幾乎可以使用任何編程語言（例如 Java、Objective-C、JavaScript、PHP、Ruby、Python 或 C# 等）編寫 Appium 腳本。不需要重新編譯或改變應(yīng)用程序來匹配Appium，Appium有一個(gè)非常大而活躍的社區(qū)。
9、Airtest
是網(wǎng)易出品的一款基于圖像識別和poco控件識別的一款UI自動化測試套件，由Airtest框架、poco框架、airtestIDE 組成。是一個(gè)跨平臺的UI自動化測試框架，適用于游戲和App。用戶不需要一行行的去寫代碼，而是用屏幕截屏的方式，用截出來的圖形排列組合成執(zhí)行的程序。
另外，Airtest也基于poco這個(gè)UI控件搜索框架，這個(gè)框架也是網(wǎng)易自家的跨平臺U測試框架，原理類似于appium，通過控件的名稱，id之類的來定位目標(biāo)控件，然后調(diào)用函數(shù)方法，例如click(),swip()之類的方法來對目標(biāo)控件進(jìn)行點(diǎn)擊或者是操作。
雖然Airtest剛開始是為了游戲測試，現(xiàn)在在app測試中也有很大的應(yīng)用范圍。只是進(jìn)行錄制、執(zhí)行腳本的AirtestIDE沒有開源，不方便進(jìn)行深度定制。
10、Solopi
是螞蟻金服開源的一款移動端APP測試工具，提供腳本錄制、編輯、回放，結(jié)果展示以及一機(jī)多控（即通過設(shè)備間的socket通訊實(shí)現(xiàn)1臺手機(jī)可以控制多臺手機(jī)執(zhí)行腳本）等功能，其測試用例的錄制和執(zhí)行等操作均在手機(jī)端的一個(gè)APP中完成。不需要借助電腦軟件與測試設(shè)備交互，所以通信結(jié)構(gòu)比Appium簡單高效，對元素的識別也是使用類似于appium的控件的方式，并且引入了類似于airtest的圖像識別的方式。
3、SoloPi的介紹
以往的性能測試工具，無外乎三種形態(tài)：PC 驅(qū)動工具、侵入式的測試模塊、ROOT 工具。
PC 工具：除了 Android Studio 自帶的性能測試工具，市面上大多數(shù)文檔都是介紹命令行方法，而且各家方案存在差異，不少還存在錯(cuò)誤，實(shí)際成型的工具也不多。
侵入式的測試模塊：這類工具由于需要侵入到源碼中，需要單獨(dú)打包進(jìn)行測試，工具本身也可能對性能產(chǎn)生影響。
-
ROOT 工具：首先是需要 Android 系統(tǒng)的 Root 權(quán)限，對于權(quán)限管控越來越嚴(yán)格的 Android 系統(tǒng)，其路必將越走越窄。
SoloPi提供了一種能夠在 Android 手機(jī)上不需要 root 也能實(shí)現(xiàn)應(yīng)用提權(quán)的方案。可以簡單概括為：SoloPi是一種無線化、非侵入、免 Root 的 Android 專項(xiàng)測試方案。 傳統(tǒng)的功能測試通常有兩種方式：一種是人工手動執(zhí)行測試，另一種則是編寫基于測試框架的自動化腳本。前者成本巨大，為應(yīng)付不斷加速的產(chǎn)品迭代可能需要投入大量人力；而后者則對測試同學(xué)的代碼能力有不小的要求，這也導(dǎo)致由手動測試轉(zhuǎn)化為自動化測試從而節(jié)省人力的進(jìn)度相對緩慢。 SoloPi將傳統(tǒng)上僅能用于 PC 的自動化測試能力移植到了移動平臺，并根據(jù)手機(jī)的使用習(xí)慣，開發(fā)了一套簡單易用且功能強(qiáng)大的自動化測試框架。不需要測試同學(xué)有代碼能力，降低了使用門檻，更方便推廣。 Solopi主要有以下功能：自動化測試-錄制回放、兼容性測試-一機(jī)多控、性能測試、穩(wěn)定性測試。
image.png
雖然Appium和Airtest都有很大的應(yīng)用范圍，但是Solopi相比于appium和airtest有以下優(yōu)勢：
改進(jìn)的控件匹配算法，更高的匹配成功率；
不需要依賴pc端的桌面應(yīng)用，全部操作都在手機(jī)端的app中完成，實(shí)現(xiàn)了無線化，隨時(shí)可測；
不需要代碼基礎(chǔ)，使用人群覆蓋范圍廣；
提供性能測試的功能等。
（1）整體架構(gòu)
這套方案中，底層依賴主要是 “無線 ADB、系統(tǒng)輔助功能、Chrome 調(diào)試以及圖像識別技術(shù)”，后文將會介紹它們具體的應(yīng)用場景。同時(shí)，在底層依賴的基礎(chǔ)上，封裝了一套核心能力，由 “控件定位、事件驅(qū)動、性能采集以及依賴注入” 組成，并在服務(wù)層實(shí)現(xiàn)了錄制、回放、數(shù)據(jù)處理等公共服務(wù)能力。在架構(gòu)的最頂端，結(jié)合界面交互邏輯包裝出了各個(gè)功能的入口。
（2）錄制回放
在錄制過程中，SoloPi 會對用戶的**操作進(jìn)行攔截**，識別用戶操作的位置，高亮當(dāng)前操作的控件，記錄用戶當(dāng)前要做的操作類型，在每一步操作后，將操作類型及目標(biāo)控件的各種信息都記錄下來。這里的控件信息包括控件的 ID、文字等基本信息，以及相對布局、截圖信息等。
在回放時(shí)，SoloPi會逐條**解析之前錄制的數(shù)據(jù)**，通過智能查找算法，綜合各種屬性，定位目標(biāo)控件，找到控件后，就會執(zhí)行相應(yīng)的操作，如點(diǎn)擊、滑動等。在所有步驟執(zhí)行后，會展示本次回放的結(jié)果，包括日志、截圖等信息，作為本次回放的總結(jié)。
SoloPi 的錄制和回放，基于同一套邏輯，包括控件結(jié)構(gòu)構(gòu)建、控件定位、事件驅(qū)動三個(gè)部分。兩者的區(qū)別主要在于控件定位：
在錄制過程中，SoloPi 會基于用戶的點(diǎn)擊行為進(jìn)行定位；
在用例回放時(shí)，SoloPi 會根據(jù)錄制時(shí)記錄的控件信息，通過 SoloPi 的控件查找算法進(jìn)行定位。
（3）底層依賴的核心功能
1）基礎(chǔ)依賴
下面主要介紹SoloPi的控件查找功能和操作監(jiān)控功能需要依賴的基礎(chǔ)方案：無線ADB方案和AccessiblityService方案。
無線ADB方案
對于 Android 自動化，ADB shell 的執(zhí)行能力是一切的基礎(chǔ)。在 PC 上，通過 Android SDK 提供的ADB client 與同樣運(yùn)行于 PC 中的 ADB server 通信，再由 ADB server 通過 USB 與位于設(shè)備中的 Adbd 通信。要實(shí)現(xiàn)一套無線化的方案，必須要擺脫對 USB 線的依賴。好在 Android 系統(tǒng)還提供了一種基于 Socket 的 ADB 連接模式，既然是這樣，那么只需要按照 ADB 通信協(xié)議在端上與本機(jī)的 5555 端口進(jìn)行通信即可獲得 ADB shell 的執(zhí)行能力。
此無線ADB方案是SoloPi區(qū)別于其他UI自動化測試框架的核心方案之一，大家可以在其他項(xiàng)目中借鑒這種無線化方案。
AccessiblityService方案
輔助功能（AccessibilityService）其實(shí)是一個(gè)Android系統(tǒng)提供給的一種服務(wù)，本身是繼承Service類的。這個(gè)服務(wù)提供了增強(qiáng)的用戶界面，旨在幫助殘障人士或者可能暫時(shí)無法與設(shè)備充分交互的人們。
從開發(fā)者的角度看，主要使用兩種功能：查找界面元素，實(shí)現(xiàn)模擬點(diǎn)擊。
UiAutomator（Appium、Airtest使用的方案）和AccessibilityService是有聯(lián)系的：UiAutomator底層使用的是AccessibilityManagerService，AccessibilityService底層也是使用的AccessibilityManagerService，它們都是通過RPC與AccessibilityManagerService進(jìn)行交互，獲取界面元素和對界面元素進(jìn)行操作的。區(qū)別是：UiAutomator只能在`shell`環(huán)境中執(zhí)行，AccessibilityService是可以運(yùn)行在app環(huán)境中的，但是需要用戶手動開啟服務(wù)。
2）基礎(chǔ)功能
基于以上兩種基礎(chǔ)能力，下面介紹solopi底層依賴的兩種功能：基礎(chǔ)控件查找功能、用戶操作監(jiān)控功能。
控件查找功能
隨著移動端動態(tài)化能力的穩(wěn)步發(fā)展，越來越多的應(yīng)用采用了 “Native + H5/小程序” 這種混合開發(fā)的方案。再考慮到近年來手游行業(yè)的飛速發(fā)展，手機(jī)游戲自動化測試的需求也越來越多。為了盡可能的適配各種場景，SoloPi提供了三種查找模式：
第一種方案的核心就是基于 AccessbilityService 生成當(dāng)前控件視圖樹，并記錄下id、文字等屬性，適用于 Native 場景。
第二種方案基于 Chrome 的調(diào)試協(xié)議，通過注入js可以獲得頁面布局以及各元素屬性，控件的定位思路與輔助功能這一套方案是一致的。適用于 H5/小程序場景。
第三種方案是圖像匹配方案，SoloPi 在端上實(shí)現(xiàn)了一套圖像比對能力，結(jié)合了模板匹配、特征匹配等算法，并做了一定的適配和調(diào)優(yōu)。適用于游戲自動化的場景。
現(xiàn)階段的開源代碼中，native控件和webview中的控件都是使用AccessbilityService生成的控件視圖樹，斷言功能和截圖點(diǎn)擊功能會使用到圖像匹配方案，現(xiàn)階段基于 Chrome 的調(diào)試協(xié)議方案未開源。
用戶操作監(jiān)控功能
a、事件獲取機(jī)制：
關(guān)于用于操作監(jiān)控與控件獲取，AccessibilityService 能夠獲取用戶的操作事件并關(guān)聯(lián)對應(yīng)的控件，可以實(shí)現(xiàn)大部分功能。
但 AccessibilityService 也有不足的地方，比如面向 HTML5 場景，輔助功能獲取控件會出現(xiàn)延遲從而導(dǎo)致獲取的控件結(jié)構(gòu)不夠精確；另外，對于部分自定義控件，輔助功能只能獲取到對應(yīng)的控件，但缺乏具體的坐標(biāo)信息，從而導(dǎo)致控件操作不符合預(yù)期。
因此，SoloPi 采取了“結(jié)合 Android 系統(tǒng) getevnet 功能”策略，通過直接解析系統(tǒng)原生事件，獲取到用戶的操作行為。
簡單來說，通過 getevent，SoloPi 可以獲取到用戶操作屏幕的具體坐標(biāo)，以及手指落下、抬起的具體時(shí)間。不過，getevent 命令的使用需要 SHELL 權(quán)限，這限制了普通 Android 應(yīng)用獲取相關(guān)數(shù)據(jù)的能力。SoloPi 通過Android 系統(tǒng)的無線調(diào)試功能實(shí)現(xiàn)了一套純端的 SHELL 執(zhí)行能力，能夠在 Android 系統(tǒng)上執(zhí)行 adb 相關(guān)命令。在SoloPi應(yīng)用中集成了 AdbLib 開源庫，包裝成一套 ADB 命令執(zhí)行工具。
通過 getevent 命令，SoloPi 獲取到了用戶點(diǎn)擊的具體坐標(biāo)，結(jié)合 AccessibilityService 獲取到當(dāng)前頁面的控件結(jié)構(gòu)樹。遍歷控件樹找到坐標(biāo)點(diǎn)擊位置最上層的控件。
b、事件攔截機(jī)制：
在soloPi代碼中，當(dāng)需要攔截事件時(shí)，就會設(shè)置AccessibilityService進(jìn)入觸摸監(jiān)控模式（通過此標(biāo)志位 FLAG_REQUEST_TOUCH_EXPLORATION_MODE）。在此模式下，系統(tǒng)不會在view樹中分發(fā)事件，各種事件會分發(fā)到AccessibilityService的實(shí)現(xiàn)類中。此時(shí)，soloPi會自己監(jiān)聽get event事件，進(jìn)行事件的分發(fā)和處理。當(dāng)不需要攔截系統(tǒng)分發(fā)事件時(shí)，就會重新設(shè)置AccessibilityService的標(biāo)志位。
（4）回放能力的擴(kuò)展
通過 SoloPi 錄制的用例會以 JSON 的形式存儲起來，用例不僅可以在設(shè)備本地直接回放，還可以通過 SoloPi 的解析器將用例轉(zhuǎn)換為 Appium等目前主流自動化測試框架的腳本，輕松打通云測平臺。另外，得益于文本抓取和圖像識別能力，SoloPi還實(shí)現(xiàn)了在 Android 端錄制一遍用例，生成的腳本能夠同時(shí)在 Android、iOS 雙端回放的能力。
（5）腳本編輯
SoloPi還提供了用例步驟的插入、刪除、修改等用例編輯功能，可以有效降低用例的維護(hù)成本。另外，SoloPi還引入了循環(huán)、條件等流程控制能力，若對用例進(jìn)行合理編排，可輕松實(shí)現(xiàn)需要重復(fù)操作的工具腳本或是需要暴力回放的穩(wěn)定性測試腳本。
（6）一機(jī)多控
在各類專項(xiàng)測試中，兼容性測試是最為耗時(shí)費(fèi)力的一項(xiàng)，測試人員需要關(guān)注各種系統(tǒng)版本、各大手機(jī)廠商，各種類型的屏幕等等，想要通過純?nèi)斯y試來保證兼容性測試的質(zhì)量成本是非常高的。
SoloPi 在錄制回放能力的基礎(chǔ)上實(shí)現(xiàn)了一套兼容性測試的解決方案。在錄制回放的場景中，先是在一臺設(shè)備上記錄了用戶的操作，然后再在任意一臺設(shè)備上實(shí)現(xiàn)操作的回放。如果把場景擴(kuò)展到多臺設(shè)備上，就可以實(shí)現(xiàn)通過一臺設(shè)備操控多臺設(shè)備，這套功能稱為 “一機(jī)多控”。具體說來就是主機(jī)與從機(jī)建立 Socket 連接，然后在主機(jī)上將用戶的操作實(shí)時(shí)發(fā)送到各個(gè)從機(jī)，在從機(jī)上完成操作的回放。
一機(jī)多控的環(huán)境搭建比較靈活，手邊的手機(jī)在安裝 SoloPi 后，通過簡單的建聯(lián)操作即可完成部署。一機(jī)多控適配了目前市面上主流機(jī)型和 ROM，并封裝了一些提升測試效率的快捷功能，如應(yīng)用安裝、數(shù)據(jù)清理、設(shè)備信息查看等等。
（7）性能測試-數(shù)據(jù)采集
性能數(shù)據(jù)隨手測，本地自動生成報(bào)表。數(shù)據(jù)采集支持手工和廣播兩種觸發(fā)方式，易于結(jié)合自動化。
以上只簡單介紹SoloPi的功能，詳細(xì)的功能介紹，可以參考SoloPi的官方開源庫的介紹：`https://github.com/alipay/SoloPi`
參考資料：
https://segmentfault.com/a/1190000039886463
https://www.163.com/dy/article/EGU3J6BD0511G03U.html
https://github.com/alipay/SoloPi
https://testerhome.com/topics/25075
https://testerhome.com/topics/20132
