https://www.cnblogs.com/Test-xiaobai/p/9066331.html
山雨欲來風滿樓，最近微信小程序相關開發文章吹遍大江南北，亦有摧枯拉朽萬象更新之勢。問小程序形為何物，直教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.腳本開頭加入電池數據清空代碼
|
1
|
shell(
'dumpsys batterystats --reset && echo True'
)
|
2.腳本結束將電量信息輸出到logcat
--輸出耗電結果|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
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所能承載的計算量。我只知道面對小程序測試我已經做好了充足的准備，讓小程序的暴風雨來得更猛烈些吧。
更多精彩內容關注本公眾號
