1拦键、UI自動化測試簡介
軟件測試簡介
軟件測試是伴隨著軟件開發(fā)一同誕生的虽填，隨著軟件規(guī)模大型化恨樟，結構復雜化耻警，軟件測試也從最初的簡單“調試”拘央，發(fā)展到當今的自動化測試涂屁。
自動化測試是什么呢？自動化測試是把以人為驅動的測試行為轉化為機器執(zhí)行的一種過程灰伟，自動化測試通常會借助某些工具或者框架拆又。雖然不能完全取代手工測試，但相比手工測試來講栏账，自動化測試可以減少人力成本遏乔，降低重復工作，從而更快速发笔、高效的進行測試活動盟萨。
測試金字塔是一種自動化測試過程的金字塔形策略結構，用來指導軟件開發(fā)過程中各層測試投入的工作量比例了讨，其最早由Mike Cohn在2009年的著作《Scrum敏捷軟件開發(fā)》中提出捻激。Mike Cohn在書中指出：測試金字塔從上到下分為三層制轰，分別是UI測試、服務/接口測試胞谭、單元測試垃杖，越接近金字塔底部的測試活動，投入的工作量應該越多丈屹，即單元測試投入工作量最多调俘，接口測試次之，UI測試投入最少旺垒。
UI測試
UI測試是最接近軟件真實用戶使用行為的測試類型彩库。通常是模擬真實用戶使用軟件的行為，即模擬用戶在軟件界面上的各種操作先蒋，并驗證這些操作對應的結果是否正確骇钦。
接口測試（API測試）
API測試，主要針對的是各模塊暴露的接口竞漾，通常采用灰盒測試方法眯搭。首先以黑盒方式設計如何調用API的測試用例鳞仙，同時在測試執(zhí)行過程中統(tǒng)計代碼覆蓋率，然后根據(jù)代碼覆蓋率情況來補充更多繁扎、更有針對性的測試用例糊闽。
單元測試
單元測試，屬于白盒測試的范疇右犹，通常由開發(fā)工程師自己完成，越早發(fā)現(xiàn)缺陷其修復成本越低盼忌。
為什么要做 UI 自動化？
隨著不停的版本迭代掂墓，軟件新增功能變的越來越多谦纱，對測試資源的需求也變得越來越大，執(zhí)行人工測試的時間越來越長君编。對于人工測試的依賴開始變得棘手跨嘉，因此大家開始尋找解決方案，UI 自動化也應運而生吃嘿。
人工測試存在以下的弊端：
- 人工回歸測試需要花費很長時間才能完成祠乃，很小的延遲就會讓發(fā)布面臨風險梦重。
- 發(fā)布節(jié)奏受到人工回歸測試的限制。兩天以上的人工回歸測試意味著最好的情況下能夠一個月發(fā)布兩次亮瓷。而且琴拧，開發(fā)者需要一次性發(fā)布所有東西。要么全部發(fā)布嘱支，要么什么都發(fā)布不了蚓胸，因為需要將所有東西一起測試。
UI 自動化測試存在以下的優(yōu)點：
解放了測試團隊針對臨時的和探索性案例的測試時間除师；
可以一邊開發(fā)一邊進行回歸測試沛膳，減少等待時間；
可重復性使用馍盟，快速進行回歸測試于置；
更好的利用資源（周未/晚上的資源空閑時段）茧吊。
UI 自動化測試的特點
了解到為什么要選擇UI自動化測試之后贞岭，我們需要了解UI自動化測試的使用場景。UI 即 User Interface（用戶界面）的簡稱搓侄，UI 自動化做的事情就是模擬用戶行為進行操作瞄桨，完成對用戶界面的測試。這也就從本質上限制了它的使用場景：
- 軟件需求變動不頻繁
- 產(chǎn)品更新維護周期長
- 比較頻繁的回歸測試
- 自動化測試腳本可重復使用
所以在開始之前讶踪，我們最好先認識清楚哪些業(yè)務場景是可以自動化測試的芯侥。
2乳讥、Android UI自動化測試工具
UI自動化測試經(jīng)過多年的發(fā)展云石，也已經(jīng)涌現(xiàn)出很多優(yōu)秀的測試工具汹忠。下面簡單介紹一下Android測試領域內的一些常見的測試工具宽菜。
1继谚、Monkey
是Android SDK自帶的測試工具犬庇，在測試過程中會向系統(tǒng)發(fā)送偽隨機的用戶事件流（如按鍵輸入、觸摸屏輸入捂襟、手勢輸入等)葬荷，實現(xiàn)對正在開發(fā)的應用程序進行**壓力測試**宠漩，也有日志輸出。實際上該工具只能做程序做一些壓力測試室囊，由于測試事件和數(shù)據(jù)都是隨機的盼铁，不能自定義饶火，所以有很大的局限性肤寝。
2鲤看、MonkeyRunner
也是Android SDK提供的測試工具刨摩。嚴格意義上來說MonkeyRunner其實是一個Api工具包澡刹，比Monkey強大罢浇，可以**編寫測試腳本**來自定義數(shù)據(jù)攒岛、事件灾锯。Monkeyrunner 足夠強大了顺饮，但是錄制的腳本是以**坐標軸來作為定位方式**兼雄，而安卓設備類型眾多赦肋，各種分辨率佃乘，所以移植性不好恕稠。
3扶欣、Instrumentation
是早期Google提供的Android自動化測試工具類，雖然在那時候JUnit也可以對Android進行測試澎羞，但是Instrumentation允許你對應用程序做更為復雜的測試妆绞，甚至是框架層面的括饶。通過Instrumentation你可以模擬按鍵按下启盛、抬起、屏幕點擊卧抗、滾動等事件。
Instrumentation是通過將主程序和測試程序運行在同一個進程來實現(xiàn)這些功能浦马，你可以把Instrumentation看成一個類似Activity或者Service并且不帶界面的組件张漂，在程序運行期間監(jiān)控你的主程序磺陡。
缺點是對測試人員來說編寫代碼能力要求較高币他，需要對Android相關知識有一定了解蝴悉，還需要配置AndroidManifest.xml文件拍冠，不能跨多個App庆杜。
4晃财、UiAutomator
也是Android提供的自動化測試框架断盛，基本上支持所有的Android事件操作钢猛，對比Instrumentation它不需要測試人員了解代碼實現(xiàn)細節(jié)（可以用UiAutomatorviewer抓取App頁面上的控件屬性而不看源碼）厢洞∩ミ矗基于Java公你，測試代碼結構簡單迂尝、編寫容易垄开、學習成本低溉躲，一次編譯，所有設備或模擬器都能運行測試净捅，能跨App（比如：很多App有選擇相冊荆永、打開相機拍照屁魏，這就是跨App）。缺點是只支持SDK 16（Android 4.1）及以上抵碟，不支持Hybird App拟逮、WebApp敦迄。
5苦囱、Espresso
是Google的開源自動化測試框架撕彤。相對于UIAutomator羹铅，它的特點是規(guī)模更小、更簡潔廉邑，API更加精確蛛蒙，編寫測試代碼簡單牵祟，容易快速上手诺苹。因為是基于Instrumentation的，所以不能跨App坪哄。
6、Selendroid
基于Instrumentation的測試框架禁悠，可以測試Native App粱坤、Hybird App若厚、Web App蜒什，但是網(wǎng)上資料較少测秸，社區(qū)活躍度也不大。
7灾常、Robotium
也是基于Instrumentation的測試框架霎冯，目前國內外用的比較多，資料比較多钞瀑，社區(qū)也比較活躍沈撞。缺點是對測試人員來說要有一定的Java基礎，了解Android基本組件雕什，不能跨App贷岸。
8螟蒸、**Appium **
Appium 是目前最主流的移動測試自動化框架诵原，不僅支持 Android 應用，而且適用于 iOS猴誊、混合和 Web 應用程序。
它底層完全使用了 Selenium 和 WebDriver 的 API墨状，所以如果你之前有用過 selenium, 幾乎不需要額外的學習成本就可以使用 appium。appium 通過 uiautomator（API 級別 16 或更高）和 Seledroid（API 級別低于 16）支持 Android砖瞧，但是你不需要具體懂這兩個框架的具體用法持隧，appium 都已經(jīng)幫你封裝成了統(tǒng)一的使用規(guī)則呀狼。Appium 的優(yōu)勢之一是幾乎可以使用任何編程語言（例如 Java貌踏、Objective-C蜒秤、JavaScript、PHP、Ruby掩驱、Python 或 C# 等）編寫 Appium 腳本。不需要重新編譯或改變應用程序來匹配Appium吆你，Appium有一個非常大而活躍的社區(qū)贬循。
9、Airtest
是網(wǎng)易出品的一款基于圖像識別和poco控件識別的一款UI自動化測試套件柠衅，由Airtest框架、poco框架谣蠢、airtestIDE 組成。是一個跨平臺的UI自動化測試框架，適用于游戲和App。用戶不需要一行行的去寫代碼，而是用屏幕截屏的方式，用截出來的圖形排列組合成執(zhí)行的程序贝椿。
另外访雪，Airtest也基于poco這個UI控件搜索框架计寇，這個框架也是網(wǎng)易自家的跨平臺U測試框架元莫，原理類似于appium离陶，通過控件的名稱片习，id之類的來定位目標控件瓣铣，然后調用函數(shù)方法答朋，例如click(),swip()之類的方法來對目標控件進行點擊或者是操作。
雖然Airtest剛開始是為了游戲測試坯沪，現(xiàn)在在app測試中也有很大的應用范圍绿映。只是進行錄制、執(zhí)行腳本的AirtestIDE沒有開源，不方便進行深度定制叉弦。
10丐一、Solopi
是螞蟻金服開源的一款移動端APP測試工具，提供腳本錄制淹冰、編輯库车、回放，結果展示以及一機多控（即通過設備間的socket通訊實現(xiàn)1臺手機可以控制多臺手機執(zhí)行腳本）等功能樱拴，其測試用例的錄制和執(zhí)行等操作均在手機端的一個APP中完成柠衍。不需要借助電腦軟件與測試設備交互，所以通信結構比Appium簡單高效晶乔，對元素的識別也是使用類似于appium的控件的方式珍坊，并且引入了類似于airtest的圖像識別的方式。
3正罢、SoloPi的介紹
以往的性能測試工具阵漏，無外乎三種形態(tài)：PC 驅動工具、侵入式的測試模塊翻具、ROOT 工具履怯。
PC 工具：除了 Android Studio 自帶的性能測試工具，市面上大多數(shù)文檔都是介紹命令行方法裆泳，而且各家方案存在差異叹洲，不少還存在錯誤，實際成型的工具也不多工禾。
侵入式的測試模塊：這類工具由于需要侵入到源碼中运提，需要單獨打包進行測試，工具本身也可能對性能產(chǎn)生影響帜篇。
-
ROOT 工具：首先是需要 Android 系統(tǒng)的 Root 權限糙捺，對于權限管控越來越嚴格的 Android 系統(tǒng)，其路必將越走越窄笙隙。
SoloPi提供了一種能夠在 Android 手機上不需要 root 也能實現(xiàn)應用提權的方案洪灯。可以簡單概括為：SoloPi是一種無線化竟痰、非侵入签钩、免 Root 的 Android 專項測試方案。 傳統(tǒng)的功能測試通常有兩種方式：一種是人工手動執(zhí)行測試坏快，另一種則是編寫基于測試框架的自動化腳本铅檩。前者成本巨大，為應付不斷加速的產(chǎn)品迭代可能需要投入大量人力莽鸿；而后者則對測試同學的代碼能力有不小的要求昧旨，這也導致由手動測試轉化為自動化測試從而節(jié)省人力的進度相對緩慢拾给。 SoloPi將傳統(tǒng)上僅能用于 PC 的自動化測試能力移植到了移動平臺，并根據(jù)手機的使用習慣兔沃，開發(fā)了一套簡單易用且功能強大的自動化測試框架蒋得。不需要測試同學有代碼能力，降低了使用門檻乒疏，更方便推廣额衙。 Solopi主要有以下功能：自動化測試-錄制回放、兼容性測試-一機多控怕吴、性能測試窍侧、穩(wěn)定性測試。
image.png
雖然Appium和Airtest都有很大的應用范圍转绷，但是Solopi相比于appium和airtest有以下優(yōu)勢：
改進的控件匹配算法伟件，更高的匹配成功率；
不需要依賴pc端的桌面應用暇咆，全部操作都在手機端的app中完成锋爪，實現(xiàn)了無線化，隨時可測爸业；
不需要代碼基礎，使用人群覆蓋范圍廣亏镰；
提供性能測試的功能等扯旷。
（1）整體架構
這套方案中，底層依賴主要是 “無線 ADB索抓、系統(tǒng)輔助功能钧忽、Chrome 調試以及圖像識別技術”，后文將會介紹它們具體的應用場景逼肯。同時耸黑，在底層依賴的基礎上，封裝了一套核心能力篮幢，由 “控件定位大刊、事件驅動、性能采集以及依賴注入” 組成三椿，并在服務層實現(xiàn)了錄制缺菌、回放、數(shù)據(jù)處理等公共服務能力搜锰。在架構的最頂端伴郁，結合界面交互邏輯包裝出了各個功能的入口。
（2）錄制回放
在錄制過程中蛋叼，SoloPi 會對用戶的**操作進行攔截**焊傅，識別用戶操作的位置剂陡，高亮當前操作的控件，記錄用戶當前要做的操作類型狐胎，在每一步操作后鹏倘，將操作類型及目標控件的各種信息都記錄下來。這里的控件信息包括控件的 ID顽爹、文字等基本信息纤泵，以及相對布局、截圖信息等镜粤。
在回放時捏题，SoloPi會逐條**解析之前錄制的數(shù)據(jù)**，通過智能查找算法肉渴，綜合各種屬性公荧，定位目標控件，找到控件后同规，就會執(zhí)行相應的操作循狰，如點擊、滑動等券勺。在所有步驟執(zhí)行后绪钥，會展示本次回放的結果，包括日志关炼、截圖等信息程腹，作為本次回放的總結。
SoloPi 的錄制和回放儒拂，基于同一套邏輯寸潦，包括控件結構構建、控件定位社痛、事件驅動三個部分见转。兩者的區(qū)別主要在于控件定位：
在錄制過程中，SoloPi 會基于用戶的點擊行為進行定位蒜哀；
在用例回放時斩箫，SoloPi 會根據(jù)錄制時記錄的控件信息，通過 SoloPi 的控件查找算法進行定位凡怎。
（3）底層依賴的核心功能
1）基礎依賴
下面主要介紹SoloPi的控件查找功能和操作監(jiān)控功能需要依賴的基礎方案：無線ADB方案和AccessiblityService方案校焦。
無線ADB方案
對于 Android 自動化，ADB shell 的執(zhí)行能力是一切的基礎统倒。在 PC 上寨典，通過 Android SDK 提供的ADB client 與同樣運行于 PC 中的 ADB server 通信，再由 ADB server 通過 USB 與位于設備中的 Adbd 通信房匆。要實現(xiàn)一套無線化的方案耸成，必須要擺脫對 USB 線的依賴报亩。好在 Android 系統(tǒng)還提供了一種基于 Socket 的 ADB 連接模式，既然是這樣井氢，那么只需要按照 ADB 通信協(xié)議在端上與本機的 5555 端口進行通信即可獲得 ADB shell 的執(zhí)行能力弦追。
此無線ADB方案是SoloPi區(qū)別于其他UI自動化測試框架的核心方案之一，大家可以在其他項目中借鑒這種無線化方案花竞。
AccessiblityService方案
輔助功能（AccessibilityService）其實是一個Android系統(tǒng)提供給的一種服務劲件，本身是繼承Service類的。這個服務提供了增強的用戶界面约急，旨在幫助殘障人士或者可能暫時無法與設備充分交互的人們零远。
從開發(fā)者的角度看，主要使用兩種功能：查找界面元素厌蔽，實現(xiàn)模擬點擊牵辣。
UiAutomator（Appium、Airtest使用的方案）和AccessibilityService是有聯(lián)系的：UiAutomator底層使用的是AccessibilityManagerService奴饮，AccessibilityService底層也是使用的AccessibilityManagerService纬向，它們都是通過RPC與AccessibilityManagerService進行交互，獲取界面元素和對界面元素進行操作的戴卜。區(qū)別是：UiAutomator只能在`shell`環(huán)境中執(zhí)行逾条，AccessibilityService是可以運行在app環(huán)境中的，但是需要用戶手動開啟服務叉瘩。
2）基礎功能
基于以上兩種基礎能力膳帕，下面介紹solopi底層依賴的兩種功能：基礎控件查找功能、用戶操作監(jiān)控功能薇缅。
控件查找功能
隨著移動端動態(tài)化能力的穩(wěn)步發(fā)展，越來越多的應用采用了 “Native + H5/小程序” 這種混合開發(fā)的方案攒磨。再考慮到近年來手游行業(yè)的飛速發(fā)展泳桦，手機游戲自動化測試的需求也越來越多。為了盡可能的適配各種場景娩缰，SoloPi提供了三種查找模式：
第一種方案的核心就是基于 AccessbilityService 生成當前控件視圖樹灸撰，并記錄下id、文字等屬性拼坎，適用于 Native 場景浮毯。
第二種方案基于 Chrome 的調試協(xié)議，通過注入js可以獲得頁面布局以及各元素屬性泰鸡，控件的定位思路與輔助功能這一套方案是一致的债蓝。適用于 H5/小程序場景。
第三種方案是圖像匹配方案盛龄，SoloPi 在端上實現(xiàn)了一套圖像比對能力饰迹，結合了模板匹配芳誓、特征匹配等算法，并做了一定的適配和調優(yōu)啊鸭。適用于游戲自動化的場景锹淌。
現(xiàn)階段的開源代碼中，native控件和webview中的控件都是使用AccessbilityService生成的控件視圖樹赠制，斷言功能和截圖點擊功能會使用到圖像匹配方案赂摆，現(xiàn)階段基于 Chrome 的調試協(xié)議方案未開源。
用戶操作監(jiān)控功能
a钟些、事件獲取機制：
關于用于操作監(jiān)控與控件獲取烟号，AccessibilityService 能夠獲取用戶的操作事件并關聯(lián)對應的控件，可以實現(xiàn)大部分功能厘唾。
但 AccessibilityService 也有不足的地方褥符，比如面向 HTML5 場景，輔助功能獲取控件會出現(xiàn)延遲從而導致獲取的控件結構不夠精確抚垃；另外喷楣，對于部分自定義控件，輔助功能只能獲取到對應的控件鹤树，但缺乏具體的坐標信息铣焊，從而導致控件操作不符合預期。
因此罕伯，SoloPi 采取了“結合 Android 系統(tǒng) getevnet 功能”策略曲伊，通過直接解析系統(tǒng)原生事件，獲取到用戶的操作行為追他。
簡單來說坟募，通過 getevent，SoloPi 可以獲取到用戶操作屏幕的具體坐標邑狸，以及手指落下懈糯、抬起的具體時間。不過单雾，getevent 命令的使用需要 SHELL 權限赚哗，這限制了普通 Android 應用獲取相關數(shù)據(jù)的能力。SoloPi 通過Android 系統(tǒng)的無線調試功能實現(xiàn)了一套純端的 SHELL 執(zhí)行能力硅堆，能夠在 Android 系統(tǒng)上執(zhí)行 adb 相關命令屿储。在SoloPi應用中集成了 AdbLib 開源庫，包裝成一套 ADB 命令執(zhí)行工具渐逃。
通過 getevent 命令够掠，SoloPi 獲取到了用戶點擊的具體坐標，結合 AccessibilityService 獲取到當前頁面的控件結構樹朴乖。遍歷控件樹找到坐標點擊位置最上層的控件祖屏。
b助赞、事件攔截機制：
在soloPi代碼中，當需要攔截事件時袁勺，就會設置AccessibilityService進入觸摸監(jiān)控模式（通過此標志位 FLAG_REQUEST_TOUCH_EXPLORATION_MODE）雹食。在此模式下，系統(tǒng)不會在view樹中分發(fā)事件期丰，各種事件會分發(fā)到AccessibilityService的實現(xiàn)類中群叶。此時，soloPi會自己監(jiān)聽get event事件钝荡，進行事件的分發(fā)和處理街立。當不需要攔截系統(tǒng)分發(fā)事件時，就會重新設置AccessibilityService的標志位埠通。
（4）回放能力的擴展
通過 SoloPi 錄制的用例會以 JSON 的形式存儲起來赎离，用例不僅可以在設備本地直接回放，還可以通過 SoloPi 的解析器將用例轉換為 Appium等目前主流自動化測試框架的腳本端辱，輕松打通云測平臺璧针。另外髓帽，得益于文本抓取和圖像識別能力箱吕，SoloPi還實現(xiàn)了在 Android 端錄制一遍用例栋操，生成的腳本能夠同時在 Android、iOS 雙端回放的能力渗柿。
（5）腳本編輯
SoloPi還提供了用例步驟的插入个盆、刪除、修改等用例編輯功能朵栖，可以有效降低用例的維護成本颊亮。另外，SoloPi還引入了循環(huán)陨溅、條件等流程控制能力编兄，若對用例進行合理編排，可輕松實現(xiàn)需要重復操作的工具腳本或是需要暴力回放的穩(wěn)定性測試腳本声登。
（6）一機多控
在各類專項測試中，兼容性測試是最為耗時費力的一項揣苏，測試人員需要關注各種系統(tǒng)版本悯嗓、各大手機廠商，各種類型的屏幕等等卸察，想要通過純人工測試來保證兼容性測試的質量成本是非常高的脯厨。
SoloPi 在錄制回放能力的基礎上實現(xiàn)了一套兼容性測試的解決方案。在錄制回放的場景中坑质，先是在一臺設備上記錄了用戶的操作合武，然后再在任意一臺設備上實現(xiàn)操作的回放临梗。如果把場景擴展到多臺設備上，就可以實現(xiàn)通過一臺設備操控多臺設備稼跳，這套功能稱為 “一機多控”盟庞。具體說來就是主機與從機建立 Socket 連接，然后在主機上將用戶的操作實時發(fā)送到各個從機汤善，在從機上完成操作的回放什猖。
一機多控的環(huán)境搭建比較靈活，手邊的手機在安裝 SoloPi 后红淡，通過簡單的建聯(lián)操作即可完成部署不狮。一機多控適配了目前市面上主流機型和 ROM，并封裝了一些提升測試效率的快捷功能在旱，如應用安裝摇零、數(shù)據(jù)清理、設備信息查看等等桶蝎。
（7）性能測試-數(shù)據(jù)采集
性能數(shù)據(jù)隨手測驻仅，本地自動生成報表。數(shù)據(jù)采集支持手工和廣播兩種觸發(fā)方式俊嗽，易于結合自動化雾家。
以上只簡單介紹SoloPi的功能，詳細的功能介紹绍豁，可以參考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
