【騰訊優測乾貨分享】微信小程式之自動化親密接觸
導語
山雨欲來風滿樓，最近微信小程式相關開發文章吹遍大江南北，亦有摧枯拉朽永珍更新之勢。問小程式形為何物，直教IT眾生怡情悅性高潮迭起。作為一名有著遠大理想“包袱”與網際網路變革 “使命感”的測試工程師，我再也按耐不住內心中的渴望與好奇，代表測試行業各大門派肩負起了迎接時代變革的挑戰。話說經歷了圍觀檢視、溜邊打探等種種過程，終於在隔壁老王那裡弄到了測試體驗資格，開始了一場對小程式的自動化親密接觸。
上篇 —— 小程式初探
上手的小程式是微信官方的測試Demo，類似Android Api Demos一樣，官方小程式中展示的也是各種控制元件的使用方法及常用介面擴充套件能力。通過新增開發者微信賬號後，掃描二維碼既可以開啟微信小程式。
一、小程式執行時分析
1、首先，啟動微信，檢視一下微信都有哪些程序。
shell@HWNXT:/ $ ps | grep u0_a539
u0_a539 6688 533 1751392 84976 SyS_epoll_ 0000000000 S com.tencent.mm:push
u0_a539 7593 533 2228476 252492 SyS_epoll_ 0000000000 S com.tencent.mm
u0_a539 8047 533 1984672 854121 SyS_epoll_ 0000000000 S com.tencent.mm:tools
u0_a539 8117 533 1770972 一共四個程序，再看一下當前顯示微信畫面的程序，從名字來看應該是com.tencent.mm。
shell@HWNXT:/ $ dumpsys activity top | grep ACTIVITY
ACTIVITY com.tencent.mm/.ui.LauncherUI 44c445f pid=7593通過命令檢視，當前top程序是7593，確實是com.tencent.mm。
2、接下來，看一下啟動官方微信小程式demo之後的程序變化。
u0_a539 6688 多了一個程序，com.tencent.mm:appbrand0,那微信小程式是在哪個程序執行的呢？
看一下top程序：
shell@HWNXT:/ $ dumpsys activity top | grep ACTIVITY
ACTIVITY com.tencent.mm/.plugin.appbrand.ui.AppBrandUI 15a772 pid=9896
shell@HWNXT:/ $當前top程序是9896，果然是com.tencent.mm:appbrand0。
可見，微信為了保證小程式的資源和獨立性，為小程式單獨開了程序。
3、微信小程式和微信裡面開啟一個網頁，是同一個模組實現的嗎？
微信裡開啟一個網頁，然後檢視一下程序情況:
shell@HWNXT:/ $ ps | grep u0_a539
u0_a539 6688 533 1751212 86184 SyS_epoll_ 0000000000 S com.tencent.mm:push
u0_a539 7593 533 2187672 263352 SyS_epoll_ 0000000000 S com.tencent.mm
u0_a539 8047 533 2336360 224436 SyS_epoll_ 0000000000 S com.tencent.mm:tools程序沒有變化，看看top程序:
shell@HWNXT:/ $ dumpsys activity top | grep ACTIVITY
ACTIVITY com.tencent.mm/.plugin.webview.ui.tools.WebViewUI 1502038 pid=14685網頁居然是在com.tencent.mm:tools程序裡面開啟的，並且兩者的Activity也不一樣，小程式是.plugin.appbrand.ui.AppBrandUI，網頁是.plugin.webview.ui.tools.WebViewUI。
看來微信小程式和單純的一個網頁還是有區別的。
二、小程式的畫面構成
使用UIAutomator分析一下構成微信小程式畫面的元件
通過UIAutomator分析畫面，發現微信小程式Demo整體由3個部分組成，Top ActionBar，中間是一個騰訊自己的WebView，用的應該是騰訊自研的X5核心，下面是一個Bottom ActionBar，在X5 WebView中展示了小程式的內容部分。
可見，微信小程式的頁面展示使用了Android原生控制元件與WebView的H5混合顯示方案，這相當於市面上相當常見的H5混合應用。
三、如何做微信小程式的自動化測試
目前Android自動化測試框架主要分6大類：
單元測試常用的Robolectric，具體實現方案是通過實現一套JVM能執行的Android程式碼，然後在unit test執行的時候去擷取android相關的程式碼呼叫，轉到他們的實現的程式碼去執行這個呼叫的過程，並且在android標準類基礎上又豐富了很多擴充套件介面，這確實極大便利了單元測試過程，但是對於我們關注功能層面的測試同學確實有些麻爪啊，實踐意義不是很大。
Monkey是Android系統自帶的一款穩定性測試工具，很多廠商也將其作為內建產品的穩定性驗收衡量工具，他雖然簡單易用方便快捷，但是正如其名一樣，猴子畢竟還是猴子是無法完成確定功能用例的測試過程，遺憾啊，等著猴子進化成人吧。
UIAutomator是為數不多的Android官方支援的自動化測試框架之一，最早釋出的版本為API Level17。作為基於控制元件的自動化框架，UIAutomator確實介面明晰容易上手，基於UIAutomator也發展出了鼎鼎大名的Appium開源自動化框架，業界地位大有捨我其誰之勢。然而使用UIAutomator的前提是可以用UIAutomatorViewer檢視到我們預操作控制元件的屬性資訊，上面分析我們已經看到，小程式部分控制元件的父容器是weview，此webview還非標準結構，應該是騰訊自研的X5核心。想用appium UIAutomator跑自動化的念頭自此打消了。
還有Instrumentation這種Android基因型測試方案可以考慮，著名的Robotium自動化測試框架就誕生於此，但是經過一番瞭解後，逐漸明白Instrumentation也好robotium也好，需要有產品原始碼或者簽名，測試工程通常是與產品原始碼放在相同專案目錄下，那麼問題來了，誰能把微信的原始碼給我，簽名也行啊，喂，大哥你有麼？喂，喂，有人能聽到嗎？!@#@%&^
早期還有一種通過系統提權注入實現的自動化測試能力，例如百度的café，阿里的arthrun，大多copy了xposed架構模式，具有強大的系統控制能力。然而試問這些框架今何在啊，原來因為android root難度越來愈高，到目前6.0版本幾乎成為不可能，所以這類開源框架早在2014年左右就停止維護了，不靠譜靠不住，還得另謀他法。
基於影象識別也有一些自動化測試框架，例如sikuli還有testin的自動化工具，然而小生之所以直接就把這類框架pass掉是因為這種測試指令碼基本不具備擴充套件性，系統ui風格變更，想要做斷言驗證，以及日後用例維護等等，想都不敢想。
鐵鞋踏破仍無路，靚女帥哥也躊躇啊，忽然間靈感一現，騰訊自家會不會有什麼奇葩產品可用啊，知行合一谷歌百度，搜尋騰訊自動化立馬看到騰訊優測的介紹，到官網裡翻了一下找到一款叫XTest的自動化測試工具，看到簡介目前只支援Android平臺，想想前面歷程這般痛苦，還要啥自行車啊。於是乎趕忙下載了一套熱氣騰騰的XTest，安裝完畢，一切準備就緒，關門，放XTest。在經過一番折騰後基本領悟了XTest的使用心法，下面我就從大家平時經常開展的效能測試走起。
中篇 —— 效能測試
一、錄製指令碼，加入迴圈等操作
使用XTest錄製從體驗上確實簡單便捷，簡單到不用插線不用PC，可以躺著錄走著錄，即使撩妹都不耽誤測試，跟平時操作App無異。對比早期錄製指令碼又抓控制元件又摸路徑受的罪，幸福感大增。錄製很容易上手，就是在錄製模式下，按照case跑一遍就OK了，指令碼自動生成，這裡不做贅述，為了讓測試更加充分，我又徒手一口氣在複雜路徑加了50個迴圈。真的是徒手，因為就是用手機端的指令碼編輯功能就實現了。
二、開始回放檢視結果
搞定指令碼後可進行本地回放或多機聯測，由於是基於控制元件的錄製技術，所以回放過程比較順利。測試結束後在手機/sdcard/kat/result路徑下會生成kat_Performance.csv檔案，這就是測試過程的效能資料了，具體資訊如下：
效能資料比較中規中矩，記憶體，cpu，電池溫度，流量，幀率資料都有，頁面切換滑動點選均無丟幀現象（不過這也可能跟XTest腳本回放速度比較慢有關，這點是這款工具目前看來一個比較讓人吐槽的點）。
僅此結果就能滿足小生的慾望麼？那是絕對不可能的，沒有裝置耗電資訊怎麼能算是一個完整的效能測試呢。
三、匯出指令碼，追加耗電資訊輸出
通過前期學習，瞭解到XTest可以匯出指令碼進行二次編輯並且支援130多個API作為複雜測試任務的擴充套件，長話短說我將錄製的指令碼匯出到sublime編輯器，加入電量測試程式碼（自定義的程式碼，寫的不完美不歡迎吐槽）
1.指令碼開頭加入電池資料清空程式碼
-- 電池資料清空
shell('dumpsys batterystats --reset && echo True')2.指令碼結束將電量資訊輸出到logcat
--輸出耗電結果
shell("dumpsys batterystats > /sdcard/kat/Result/batterystats.txt && echo True")
--讀取txt檔案的程式碼
local f = io.open('/sdcard/kat/Result/batterystats.txt', 'r')
for line in f:lines() do
print(line)
shell('log -p i -t getbatterystats "' .. line .. '" && echo True')
end
f:close()3.重新啟動測試，測試完成後到logcat日誌中收割電量測試結果，目標檔案就在/sdcard/kat/result目錄下(logcat.txt)如下：
好吧，看起來也都正常，我只是想說嗯這個也可以測，因為這個xtest可以擺脫usb線束縛無線回放指令碼，這樣才能獲取到較為精準的電量資訊。當然，希望今後類似的專項測試也能有個好的報表展現方式。
PS：注意這是耗電測試，所以充電壓脈帶，也正是XTest這種可無線測試的自動化引擎，才能方便搞定之前需要頻繁插拔usb線才能完成的測試任務。
下篇 —— 微信小程式測試
一、小程式分析
弄完了效能測試，我們切回主題，搞一下小程式，著手開展小程式UI自動化前，我們需要關注一下XTest是否可以輕鬆擼到小程式的控制元件
1、小程式的Hybrid控制元件
小程式對當前已支援的元件給出了演示程式，首先看下這些控制元件的真面目
使用XTest輔助工具對控制元件抓取可知，在X5 WebView內，控制元件也是如Android原生控制元件一樣具有屬性欄位的。
E/Kat: setString=={name:SPAN,type:notFound,X:99,Y:777,X2:171,Y2:831}
E/Kat: name = SPAN;type=notFound;label=text;x=99 y=777 x2=171 y2 = 831
E/Kat: top-result:168,1016,[99,990,72,54],-2,top=[SPAN,text],valid=[SPAN,text],30000000,0,0,weight=0
E/Kat:@0%1:android.widget.FrameLayout%1:android.widget.FrameLayout%1:android.widget.FrameLayout%1:android...例如控制元件的resource-id屬性欄位為”SPAN”; text屬性欄位為”text”, 以及控制元件的矩形座標範圍值和layout層級結構，這些資料使用XTest都可以準確獲取。
2、特殊控制元件也可以獲取到物件屬性麼？
switch、video、canvas、map等元件都可以獲取到物件屬性，基於這些資料，可以完成UI自動化的控制元件抓取。
二、小程式測試實踐
1、視訊介面測試
小程式演示中除了提供元件之外也展示了部分介面功能，從中抽取代表性的“選擇視訊”這一較為複雜用例進行測試：（介面型別：媒體–視訊）
通過前導路徑進入當點選圖片中的+控制元件後，進入系統相機，什麼？什麼！……..，XTest失控了，失控了，無法錄製系統相機操作過程。Demo宣傳裡面提到什麼跨程序，這回怎麼跨到溝裡去了？帶著憤恨跟疑問勾搭了一下XTest開發同學，他們提到工具本身確實支援跨程序測試，前提是需要把涉及到的apk也通過他們的工具上傳到手機端，給到我的具體建議是：
1)用其他相機應用替換掉預設系統相機，然後將此apk上傳到手機端測試
2)採用自動化+人工互動方式
我對後者十分好奇，什麼是自動化+人工？搞搞試試，於是乎根據他們的幫助還真的搞定了，具體就是在腳本里面插入一條語句：完成自動化與人工的互動過程，結束後按音量鍵上報測試結果，之後自動化接管任務繼續執行。 看來今後測試行業也要走工廠流水線了，想想富士康工廠裡愈來愈像人的裝置與愈來愈像機械的人，小生不僅打了一個冷顫。
2、多賬號分發測試
看到上圖中有4臺機器一起在執行，微信程式測試需要賬號登入，XTest本身就支援多機聯測，微信小程式登陸賬號由server統一管理，在執行時下發到手機端完成登入。
看到圖中四個賬號是server端分配的唯一賬號，各不相同，保證每臺裝置可以順利登入，並由框架驅動多機聯測。
3、聯測報告展示
完成多賬號分發多機聯測後，就可直接在server端檢視測試報告了。
上圖是用Xtest進行多機聯測後一臺裝置的效能資料展示。從截圖可以看到當進入小程式的視訊介面開始播放後（第6步），曲線圖的紅色線（CPU）開始斜坡上升，隨著視訊載入快取（第7、8步），代表上下行流量的綠色線（NetFlow）開始陡增。嗯，還是比較符合人類巨集觀認知理論的。如果配合指令碼的場景編寫，應該很容易就可以完成壓測中的效能資料收集，並根據圖片手順定位哪步操作會導致效能資料異常。
看到這裡小生不僅感嘆，一套免費的工具做到如此程度，夫復何求啊！
尾篇 —— 總結
經過了以上由淺入深又由深到銷魂的測試過程，看似陌生神祕的小程式，在我們測試工程師的眼裡變得如此熟悉與親密。無論從效能資料獲取、專項測試佈局，到多機聯測、多賬號分發，再到最後豐富的報告結果展示，XTest彷彿早已為小程式做好了準備。這一切到底是天意還是巧合？或者乾脆就是騰訊早已為我們布好了完整的局，這燒腦的懸疑已經完全超出了小編單核cpu所能承載的計算量。我只知道面對小程式測試我已經做好了充足的準備，讓小程式的暴風雨來得更猛烈些吧。
更多精彩內容歡迎關注騰訊優測的微信公眾賬號：
騰訊優測是專業的移動雲測試平臺，為應用、遊戲、H5混合應用的研發團隊提供產品質量檢測與問題解決服務。不僅在線上平臺提供app自動化測試、雲真機遠端操控與除錯、私有自動化測試工具XTest等多種質量檢測工具，更為VIP客戶配備了專家團隊提供定製化綜合測試解決方案。