【複製自：原文鏈接：https://www.cnblogs.com/Test-xiaobai/p/9066331.html 】
【注：文中提到的Xtest已下線】
山雨欲來風滿樓，最近微信小程序相關開發文章吹遍大江南北，亦有摧枯拉朽萬象更新之勢。問小程序形爲何物，直教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 86280 SyS_epoll_ 0000000000 S com.tencent.mm:sandbox
一共四個進程，再看一下當前顯示微信畫面的進程，從名字來看應該是com.tencent.mm。
shell@HWNXT:/ $ dumpsys activity top | grep ACTIVITY
ACTIVITY com.tencent.mm/.ui.LauncherUI 44c445f pid=7593
2、接下來，看一下啓動官方微信小程序demo之後的進程變化。
u0_a539 6688 533 1750852 84420 SyS_epoll_ 0000000000 S com.tencent.mm:push
u0_a539 7593 533 2223164 272116 SyS_epoll_ 0000000000 S com.tencent.mm
u0_a539 9853 533 2092872 117492 SyS_epoll_ 0000000000 S com.tencent.mm:tools
u0_a539 9896 533 2351160 212336 SyS_epoll_ 0000000000 S com.tencent.mm:appbrand0
多了一個進程，com.tencent.mm:appbrand0,那微信小程序是在哪個進程運行的呢？
看一下top進程：
shell@HWNXT:/ $ dumpsys activity top | grep ACTIVITY
ACTIVITY com.tencent.mm/.plugin.appbrand.ui.AppBrandUI 15a772 pid=9896
當前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個部分組成，TopActionBar，中間是一個騰訊自己的WebView，用的應該是騰訊自研的X5內核，下面是一個Bottom ActionBar，在X5 WebView中展示了小程序的內容部分。
可見，微信小程序的頁面展示使用了Android原生控件與WebView的H5混合顯示方案，這相當於市面上相當常見的H5混合應用。
三、如何做微信小程序的自動化測試
目前Android自動化測試框架主要分6大類：
1、單元測試常用的Robolectric，具體實現方案是通過實現一套JVM能運行的Android代碼，然後在unittest運行的時候去截取android相關的代碼調用，轉到他們的實現的代碼去執行這個調用的過程，並且在android標準類基礎上又豐富了很多擴展接口，這確實極大便利了單元測試過程，但是對於我們關注功能層面的測試同學確實有些麻爪啊，實踐意義不是很大。
2、Monkey是Android系統自帶的一款穩定性測試工具，很多廠商也將其作爲內置產品的穩定性驗收衡量工具，他雖然簡單易用方便快捷，但是正如其名一樣，猴子畢竟還是猴子是無法完成確定功能用例的測試過程，遺憾啊，等着猴子進化成人吧。
3、UIAutomator是爲數不多的Android官方支持的自動化測試框架之一，最早發佈的版本爲API Level17。作爲基於控件的自動化框架，UIAutomator確實接口明晰容易上手，基於UIAutomator也發展出了鼎鼎大名的Appium開源自動化框架，業界地位大有捨我其誰之勢。然而使用UIAutomator的前提是可以用UIAutomatorViewer查看到我們預操作控件的屬性信息，上面分析我們已經看到，小程序部分控件的父容器是weview，此webview還非標準結構，應該是騰訊自研的X5內核。想用appium UIAutomator跑自動化的念頭自此打消了。
4、還有Instrumentation這種Android基因型測試方案可以考慮，著名的Robotium自動化測試框架就誕生於此，但是經過一番瞭解後，逐漸明白Instrumentation也好robotium也好，需要有產品源碼或者簽名，測試工程通常是與產品源碼放在相同項目目錄下，那麼問題來了，誰能把微信的源碼給我，簽名也行啊，喂，大哥你有麼？喂，喂，有人能聽到嗎？!@#@%&^
5、早期還有一種通過系統提權注入實現的自動化測試能力，例如百度的café，阿里的arthrun，大多copy了xposed架構模式，具有強大的系統控制能力。然而試問這些框架今何在啊，原來因爲androidroot難度越來愈高，到目前6.0版本幾乎成爲不可能，所以這類開源框架早在2014年左右就停止維護了，不靠譜靠不住，還得另謀他法。
6、基於圖像識別也有一些自動化測試框架，例如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也通過他們的工具上傳到手機端，給到我的具體建議是：
用其他相機應用替換掉默認系統相機，然後將此apk上傳到手機端測試
採用自動化+人工交互方式
我對後者十分好奇，什麼是自動化+人工？搞搞試試，於是乎根據他們的幫助還真的搞定了，具體就是在腳本里面插入一條語句：完成自動化與人工的交互過程，結束後按音量鍵上報測試結果，之後自動化接管任務繼續執行。看來今後測試行業也要走工廠流水線了，想想富士康工廠裏愈來愈像人的設備與愈來愈像機械的人，小生不僅打了一個冷顫。
2、多賬號分發測試
看到上圖中有4臺機器一起在運行，微信程序測試需要賬號登錄，XTest本身就支持多機聯測，微信小程序登陸賬號由server統一管理，在運行時下發到手機端完成登錄。
看到圖中四個賬號是server端分配的唯一賬號，各不相同，保證每臺設備可以順利登錄，並由框架驅動多機聯測。
3、聯測報告展示
完成多賬號分發多機聯測後，就可直接在server端查看測試報告了。
上圖是用Xtest進行多機聯測後一臺設備的性能數據展示。從截圖可以看到當進入小程序的視頻界面開始播放後（第6步），曲線圖的紅色線（CPU）開始斜坡上升，隨着視頻加載緩存（第7、8步），代表上下行流量的綠色線（NetFlow）開始陡增。嗯，還是比較符合人類宏觀認知理論的。如果配合腳本的場景編寫，應該很容易就可以完成壓測中的性能數據收集，並根據圖片手順定位哪步操作會導致性能數據異常。
看到這裏小生不僅感嘆，一套免費的工具做到如此程度，夫復何求啊！
尾篇 —— 總結
經過了以上由淺入深又由深到銷魂的測試過程，看似陌生神祕的小程序，在我們測試工程師的眼裏變得如此熟悉與親密。無論從性能數據獲取、專項測試佈局，到多機聯測、多賬號分發，再到最後豐富的報告結果展示，XTest彷彿早已爲小程序做好了準備。這一切到底是天意還是巧合？或者乾脆就是騰訊早已爲我們布好了完整的局，這燒腦的懸疑已經完全超出了小編單核cpu所能承載的計算量。我只知道面對小程序測試我已經做好了充足的準備，讓小程序的暴風雨來得更猛烈些吧。