APP 自動化測試封裝結構模式

標籤：一個個   manifest   模仿   版本   roi   round   ui自動化   自動化   alt   

原文出處http://www.toutiao.com/a6268089772108333314/

做過UI自動化測試同學，都會深深體會幾個痛點：維護量大、適配量大、編寫代碼巨大等。基於這些問題，大家都會想到抽象封裝通用常用方法，編過程式的同學都知道，如何提高編程速度，那就是有一套自己熟悉和好用的函數庫，這樣編程很大部分就如搭積木遊戲，可以快速搭建程式。基於此我們設計了第一套封裝結構模式，如所示：

從以上結構，不難發現應用基礎庫比較淩亂，沒有分類。如果是自己寫的還記得住，要是移交給別人，就顯得很糟糕了，別人不願意去看去用。那麼，急需解決的問題就是如何分類比較合理。

從基於UI測試的測試對象出發，我們測試的對象為一個個的Activity，那我們可以使用Activity來進行分類。首先每個Activity 都有自己的專有方法，如撥號介面，會有輸入號碼、撥號、刪除號碼等功能，我們將每個Activity劃分為一個單獨的類，類裡面把這個Activity 涉及的方法都寫好提供給用例調用，如撥號介面的屬性與功能的基礎分解。

依據以上 Activity 封裝模式，我們還需要在結構中再加入一層 Activity 函數庫，那麼，新的結構圖如下所示：

這裡涉及了幾個Activity的查詢方法。[LG1]

方法1：從開發那取得manifest檔案

方法2：使用命令查詢應用的全部Activity

adb shell dumpsys package <包名>

方法3：查詢當前Activity 棧頂的Activity，推薦使用此方法

adb shell dumpsys activity

找到棧頂Activity

[LG1]這幾個查詢方法再做下比較吧？

方法4：找焦點Activity

adb shell dumpsys activity | find “mFocusedActivity”

簡化搜尋字元

adb shell dumpsys activity | find “mF”

以上方法，最快捷的是方法四可以馬上知道當前的頁面資訊，最全面的是方法1與方法2，使用哪種方法需要依據實際使用方式進行選擇。

之前我們介紹過，基於同種布局抽象出通用方法。我們將常用的通用方法，放在公用庫中，將每個介面方法放於每個單獨介面的類中。下面來看一下基本基本類圖：

在各種方法都固化完後，編寫用例就成了搭積木遊戲，可以快速的搭建需要的用例。將用例的邏輯寫在用例中，用例的資料分離出來全部寫在對應的Activity 類中。這樣平時主要維護已有的各個Activity內方法與資料。

最後再按照功能將用例結構抽象成為一個標準架構層理論，這樣大家就更容易明白與理解了。

基於此架構，基本不變的層為：布局層、組件層、通用層。介面層會因為介面的變化而進行維護變化。設計時候尤其注意函數的通用性、函數的參數、各種重載函數，以及各種異常情況都需要重點考慮和規避。作為通用的方法，為了保證函數的調用不出問題，也是需要測試的，我們必須寫一份用例來測試這些方法，模仿單元測試方式來檢查這些通用方法的可用性、穩定性、可靠性，以此來保證在應用變化，Android版本變化時候能快速的發現哪些函數存在的不相容現象，進行及時的修改，保證業務的正常進行。

介面層的所有方法都基於介面方式進行設計，實際的用例由這些介面方法組成。當版本變化的時候只需要重新實現介面重新變化一份，用例只需要變換一下執行個體化的類就可以完成切換用例。如此這樣，用例的固定步驟也可以不用變化，僅僅變化每塊積木裡面的內容就可以。

以上內容總結為如下幾點：

• 合理封裝方法，最佳化工程架構

• 組件化

• 布局化

• 介面化

• 介面化

 

APP 自動化測試封裝結構模式