做者:曾夏,微信客戶端測試開發
商業轉載請聯繫騰訊WeTest得到受權,非商業轉載請註明出處。 java
2017年4月,企鵝智酷公佈了最新的《2017微信用戶&生態研究報告》。報告數據顯示,截止到2016年12月微信全球共計8.89億月活用戶,新興的公衆號平臺擁有1000萬個。微信這一年來直接帶動了信息消費1742.5億元,至關於2016年中國信息消費總規模的4.54%。web
坐擁如此量級的用戶,也意味着,微信發生一個小問題,即會影響大量的用戶體驗。基於此,微信很是注重質量。算法
目前國內不少硬件廠商,對於Android版本,深度定製本身的ROM、系統版本,例如小米的MIUI、華爲的EMUI、聯想的VIBEUI等。這就是N個廠商乘以M個版本,致使的版本數量爆炸,牽引出各類適配問題。數據庫
微信應用去適配那麼多的設備花費了大量精力時間。在這個環境下,微信團隊寄託於自動化測試,但願把更多的測試環節放在雲端自動化地運行。api
兼容性測試覆蓋的環節衆多,微信優先選取核心的環節進行測試。並把必測的環節儘可能以自動化,雲端化的方式實現。那麼,哪些問題屬於高優先級?微信
安裝和啓動問題是屬於最嚴重的bug。這種問題通常比較少出現,可是一出現就是大問題。安裝和啓動失敗,極可能形成微信團隊的監控數據不充分,有時沒法主動發現問題,最後只能經過用戶反饋感知到這種錯誤。此時可能已經給用戶形成很大影響了。微信開發
好比曾經發現華爲和三星某臺機型的getDrawable這個api掛掉了,致使這兩款機型部分用戶啓動不了微信,雖然影響用戶量不大,但很是嚴重。安裝失敗和啓動失敗是兼容性測試最基本的要求。app
Crash率是微信團隊衡量一個版本是否穩定的重要標準,尤爲是新出現的Crash。當測試包灰度出去以後,若是Crash率偏高,或新出現的Crash佔比較高,微信團隊通常會採起換包,撤包措施。這會帶來如下連鎖反應框架
一、給用戶形成極差的使用體驗工具
二、給開發和測試形成額外的工做
三、形成因版本發佈延遲引發的一系列損失
所以,新出現的Crash必定是微信最關注的質量標準之一。
上面說起的兼容性問題,出現任何一種狀況都是極其嚴重。微信團隊根據同行的積累和歷史經驗,針對不一樣的問題,作不一樣的測試。
覆蓋安裝,顧名思義就是用新版本的應用覆蓋舊版本。
覆蓋安裝的測試流程以下:
針對安裝和啓動問題是影響最嚴重的問題,微信團隊目前在版本發佈前都要作覆蓋安裝測試。將要發佈的包,安裝而且啓動成功以後保證微信基本功能能正常運行。微信的每一個正式版本基本都會修改配置的版本號,Android也是根據版本號來判斷App是否有更新。當覆蓋安裝完以後,App有專門的代碼處理更新,保證數據兼容。通常第三方商店都是以這個值來檢測軟件是否更新。
覆蓋安裝測試的流程較簡單,儘量模擬真實用戶升級安裝使用的場景。覆蓋安裝以後,用戶啓動微信時,後臺發出升級指令,升級主要是確認老版本的數據可否在新版本中使用;最後經過冒煙測試,檢測微信核心功能(覆蓋到主要的數據庫)可否正常經過。微信團隊重視覆蓋安裝測試,除了監測一些數據兼容性問題外,還需檢測新打的包是否有問題。此外tinker的patch包也須要通過相似的測試,保證patch成功以及基本的核心功能。
覆蓋安裝測試只在發佈前夕作,由於微信這邊是持續集成開發,分佈分支上的包一直在更新,因此只拿即將發佈的包來作,經過以後纔會進行外網發佈。
Crash問題對應的測試是穩定性測試。對於app的穩定性測試,官方的測試工具是monkey。monkey會產生一些列隨機性事件(具體比例能夠配置)測試目標APP是否出現Crash。
Monkey測試的侷限性
微信團隊發現monkey不會去檢測界面上的控件,所以產生的事件過於隨機,不太符合微信的測試需求。所以,微信開發了一個基於控件的定製化monkey來作穩定性測試。
要基於控件開發一個定製化monkey,首先就須要獲取界面(Activity)的全部控件(View)。
選擇框架修改Monkey腳本
一開始採用robotium框架,但微信自己是一個多進程的App,好比打開相冊,或者webview的時候,都是在一個tools進程中的,而robotium只針對單個進程,須要去改框架源碼才能夠支持多進程的微信App,實現起來比較繁瑣。所以後面微信團隊開始使用官方框架UIAutomator。
利用框架獲取控件(View)
google並無給出公開接口獲取全部控件,若是使用selector來獲取,速度很慢,由於google爲了保證ui自動化的執行,不少地方加了等待,而monkey測試須要快速的點擊。經過參考UIAutomator的源碼實現,微信團隊決定利用java的反射原理拿到AccessibilityNodeInfo,中間去掉無謂的等待或者減小等待事件增長重試次數。AccessibilityNodeInfo 跟view(控件)有一對一的關係,在uiautomator裏面就跟一個UiObject對應。目前外面不少的搶紅包插件也是利用AccessibilityService拿到AccessibilityNodeInfo來作識別和點擊。
定製化Monkey的誕生
經過反射的方案,獲取當前activity的速度能夠保證在十幾毫秒之內完成。獲取全部控件以後,就能夠針對控件作隨機探索了!
爲了更好的遍歷儘量多的activity,微信團隊採用改造以後深度遍歷算法。咱們稱之爲「定製化Monkey」。定製化monkey的運行邏輯比較簡單,其中,還有一些特殊處理,好比返回的時候要檢查是否有彈框,打開webview的時候檢查是否有彈框(地理位置),跑的時候是否有退出登陸等。目前來看改造的效果比原生的效果有必定的提高,下面是單機的測試結果:
從上圖能夠看出,相對於原生的monkey,行覆蓋率大約有80%的提高,activity覆蓋率大約有將近200%的提高。並且從曲線上能夠看到,這兩個monkey在登陸以後的1個小時之內,行覆蓋率和activity覆蓋率都有明顯的提高,在1到2個小時之內也會緩慢提高,而兩個小時以後提高就很是緩慢了。
微信團隊天天都會取最新代碼編的apk包進行穩定性測試,收集出現的Crash,而且把新出現的Crash,提交bug給對應開發。
兼容性測試根本仍是要覆蓋機型,微信團隊在作一些自動化方案目的就是爲了在多種機器上並行執行。原先,微信團隊用來作自動化的機型數量較少。上面提到的覆蓋安裝測試和定製化monkey測試,可能只跑典型的6到10臺機型。
如今兼容性測試遷移到WeTest平臺上,測試基於WeTest給微信搭建的私有云平臺進行,同時公有云的機型做爲補充。
至此,微信團隊實現了機型管理雲端化,設備覆蓋也有了實質性提高。
微信團隊天天都會在測試平臺上申請上百臺手機跑多輪定製化Monkey測試,日均測出十幾個Crash,一些新特性上線的高峯期有時可達40/50個。
除以上問題以外,新功能上線時,微信團隊會很是關注其是否會產生新的適配問題。譬如,字體截斷問題,鍵盤問題等。一年多前,微信發佈小視頻功能,發現多個廠商定製ROM致使的視頻方向錯誤,黑屏,播放失敗等問題,嚴重影響用戶體驗。
每一個版本都有功能兼容性問題,而且每一個版本的測試內容都不同。目前採用的方式還比較低級,主要依靠人力在主流機型上進行兼容性測試以及衆測。
版本間差別大,自動化陷入困境
功能測試通常針對某個特定版本,所以自動化腳本基本只適用特定版本,複用性弱,自動化不能帶來好的收益。同時,功能測試路徑有時比較特殊,自動化腳本難寫,驗證麻煩。好比小視頻功能測試,自動化腳本判斷不出來是否出現黑屏、花屏,必需要人眼判斷。
部分特性能夠自動化實現:半自動化測試
一些特性能夠作自動化或者半自動化測試。好比H5測試,主要是檢測在不一樣手機上打開頁面,看看頁面是否有UI問題。半自動化測試方案:經過腳本驅動UI操做和webview操做,同時在關鍵的頁面截圖,生成帶一系列截圖的測試報告。過後肉眼查看截圖,比對判斷測試是否經過。
功能兼容性問題目前咱們尚未一個通用的解決方案,都是根據不一樣的需求利用目前手頭資源作儘量完善的測試。
功能自動化測試遷入WeTest平臺
針對功能適配兼容性測試,微信團隊也把H5適配兼容性測試和部分高優先級自動化用例遷移到WeTest平臺上。
● 創建微信私有云:在私有云上,微信團隊不間斷提交自動化腳本進行24小時測試。當私有云缺乏某臺特定機型時,WeTest公有云上的機型做爲補充測試。
● 微信質量系統與私有云對接:WeTest將一些接口開放給微信,微信利用這些接口,搭建了本身的雲端質量管理平臺,直觀、便捷地進行測試管理工做,大大提高了效率。
微信團隊經過自動化、雲端化測試,在兼容性和功能測試方面效率提高了1倍多,更快速、精準地定位解決問題,累計發現並解決的問題數達數千個,覆蓋億級用戶,提供了流暢穩定的體驗環境。
後續,咱們期待雲端化、自動化測試深度覆蓋到更多測試環節,使測試過程和測試結果變得更加流暢、可視化。經過技術的力量,持續提高產品的質量!
立刻進入「專家兼容測試」界面,找騰訊測試專家團隊幫您把關移動應用質量吧!點擊連接便可使用專家兼容測試服務:http://wetest.qq.com/product/expert-compatibility-testing
恰逢WeTest鉅惠煥新季,還有手遊專家兼容豪華大禮包哦!特大優惠不容錯過:
http://wetest.qq.com/activities/20170419
能夠聯繫wetest小助手搶先了解優惠詳情,諮詢預定(QQ:800024531)
親愛的讀者,爲了可以提供更好的網站內容,但願您填寫咱們的問卷,咱們會隨機抽取讀者回饋20Q幣以示感謝!問卷入口:https://wj.qq.com/s/1221194/26ad