QCon2015專場有很多關於架構優化、專項領域調優專題,但能系統性描述產品測試方向只有《攜程無線App自動化測試實踐》。編程
(一). 攜程的無線App自動化架構
1. 先總結下他們作到了些什麼:併發
(1). 移動設備真機自動化測試集羣,及集羣監控。框架
(2). 集羣中設備可提供遠程人工控制服務(遠程操做手機屏幕)。高併發
(3). 基於Appium編寫案例。工具
(4). 創建基本的自動化測試模式(自動化案例:手工案例 爲 3:7)。測試
2. App自動化測試的產出效果:優化
(二). 反思設計
1. 攜程的可改進之點:
(1). PC利用率低下:攜程1臺PC只掛2臺移動設備。
adb查找設備/模擬器 端口是5555~5585,每一個設備/模擬器佔2個端口,因此PC通常能夠掛15個設備/模擬器。當時咱們作移動自動化測試時,就是一臺PC掛6~8臺移動設備。
固然,攜程不這麼作確定有緣由:
a)adb-server與移動設備 I/O 時,會不按期出現卡死。
緣由:移動設備沒有返回,致使adb-server一直read()不到數據。另外,adb-server和設備I/O時,是加鎖而且沒timeout的,這將致使:一臺設備讀卡死,其餘設備也別想幹活了……
解決方案:adb監控,發現異常adb,幹掉並重啓。重啓adb會有反作用(執行中案例會失敗),但可經過:案例執行的冪等 與 重複執行失敗案例 解決。
b)adb沒法承受大量 I/O 併發
(2). 測試結果 不具有 功能正確性 結論
攜程的某些測試類型(如:可達性測試、及所謂的冒煙測試......)不能給出功能正確性判斷。這在業界是有爭議的,一部分人認爲:可測試Activity頁是否崩潰/Webpage是否加載成功;另外一部分則認爲:須要人手返工測試,保證功能正確性,因此它不必存在。我的更傾向後者。另外,這也從側面反應出一個問題:UI級別的自動化測試實施不容易,這裏就不扯遠了。
2. 攜程的可取之處:
(1). 提供設備遠程人工控制服務(遠程操做手機屏幕)。
該功能其實並不新鮮,Testin早在2012年已對外提供相似服務,只不過13年後屏蔽對外。它的優勢在於統籌資源,可減小設備冗餘。
(2). 基於Appium編寫案例。
我以前也負責過YY的移動端測試框架"TestAgent"的實現與維護,之因此認爲 基於Appium實施自動化測試 可取,緣由有二:
a)能提供良好的 案例編寫/編程 風格。
UI自動化測試框架實施,我認爲有3個重點:
1. 操做 被測試應用 UI元素 的方法。
2. 提供易讀,易用API。
3. 提供方便,完備的 元素索引 方式。
其中2,3是編寫優雅測試案例的基礎。固然,對於2,3,Appium和TestAgent都是具有的。
b)開源社區支持。
Appium與其餘測試框架(包括:阿里,百度,還有YY……)差異就在這裏。
(3). 攜程擁有獨立的基礎工具研發部門支撐各上層業務測試
以上說的優與劣,皆技術層面問題。但這個非技術性問題,纔是我最大感觸。