自動化測試是研發(fā)人員進(jìn)行質(zhì)量保障的重要一環(huán)，良好的自動化測試機(jī)制能夠讓開發(fā)者及早發(fā)現(xiàn)編碼中的邏輯缺陷，將風(fēng)險前置。日常研發(fā)中，由于快速迭代的原因，我們經(jīng)常需要在各個業(yè)務(wù)線上進(jìn)行主流程回歸測試，目前這種測試大部分由人工進(jìn)行，費(fèi)時費(fèi)力，重復(fù)勞動多。如果能將UI自動化測試與主流程回歸結(jié)合到一起，一方面保證了代碼質(zhì)量，另一方面大大節(jié)約人力成本，可謂一舉兩得。

為什么需要UI自動化測試

原因主要是以下三點：

• 保證質(zhì)量——及早發(fā)現(xiàn)代碼缺陷，風(fēng)險前置。

• 減少重復(fù)勞動，節(jié)約人力——快速迭代中經(jīng)常需要進(jìn)行主流程回歸，測試完整個主流程，需要耗費(fèi)相當(dāng)大的人力成本。

• 統(tǒng)一標(biāo)準(zhǔn)——每個人對測試用例以及業(yè)務(wù)理解程度不同，標(biāo)準(zhǔn)可能存在不一致。

進(jìn)行UI自動化測試面臨的問題

• 工具選擇。

• 降低對后端的依賴，避免因為測試環(huán)境后端不穩(wěn)定導(dǎo)致的測試失敗。

• 整合測試用例，增加復(fù)用，降低用例維護(hù)成本。

自動化測試工具對比

業(yè)界UI測試工具發(fā)展迅速，目前有Robotium、Appium、Espresso、UIAutomator、Calabash等等，其中在Android中應(yīng)用最廣泛的當(dāng)屬UIAutomator、Robotium、Appium。

下面列表比較說明：

除了Android、Hybrid類型的App，Appium還可以在iOS設(shè)備上運(yùn)行。加上之前組內(nèi)有同事做過Appium方面的分享，在這方面有一定的基礎(chǔ)，所以最終我們選擇了Appium。

接口穩(wěn)定性與數(shù)據(jù)可變性

業(yè)務(wù)特性決定我們的case在運(yùn)行過程中會經(jīng)常向后端請求數(shù)據(jù)，然后根據(jù)后端接口返回的數(shù)據(jù)決定頁面元素展示。因此，有兩個難點是必須克服的：

1. 后端接口穩(wěn)定性
   測試環(huán)境并不像線上，能在7x24內(nèi)保持穩(wěn)定。業(yè)務(wù)接口經(jīng)常出現(xiàn)因所依賴的外部環(huán)境異常而請求失敗的情況，以往處理這種情形，我們能做的事情往往很有限，最糟糕的就是必須要等待第三方修改完成后，才能繼續(xù)我們的測試。因此，如何保持接口穩(wěn)定，將成為UI自動化測試不得不面對的問題。

2. 測試數(shù)據(jù)配置與保存
   克服了1中提到的接口穩(wěn)定難點后，仍然要面對第二個難點——頻繁修改配置以適應(yīng)測試用例的條件。舉個例子，對于閃惠業(yè)務(wù)，用例里面會對于商戶配置的多種情況進(jìn)行測試（無優(yōu)惠、有優(yōu)惠未開始、僅有閃惠優(yōu)惠、有閃惠和團(tuán)購、閃惠打折、閃惠贈品等），這里面的條件是復(fù)雜多變的。如果每一次進(jìn)行測試前，都由執(zhí)行測試人在商戶后臺登錄后手動修改配置，將耗費(fèi)巨大的人力成本。因此我們勢必找出一條途徑，將這種繁瑣的配置過程自動化。

接入Appmock

注：使用Appmock，需建立在App底層網(wǎng)絡(luò)請求模塊已經(jīng)具備切換mock地址的功能的基礎(chǔ)上。

Appmock是美團(tuán)點評平臺組制作的非常優(yōu)秀的mock工具，其前身是美團(tuán)點評同事張文東所編寫的wendong.dp（僅供美團(tuán)點評內(nèi)部使用）。在Appmock上可以進(jìn)行網(wǎng)絡(luò)請求的查看與mock。那么，是否可以讓我們的自動化測試用例在運(yùn)行時訪問Appmock，獲取預(yù)設(shè)的mock數(shù)據(jù)呢？做過相關(guān)App開發(fā)的同事都知道，在App中這是很容易實現(xiàn)的，只要訪問某個特定HTTP鏈接進(jìn)行注冊即可。

現(xiàn)在我也找了很多測試的朋友，做了一個分享技術(shù)的交流群，共享了很多我們收集的技術(shù)文檔和視頻教程。
如果你不想再體驗自學(xué)時找不到資源，沒人解答問題，堅持幾天便放棄的感受
可以加入我們一起交流。而且還有很多在自動化，性能，安全，測試開發(fā)等等方面有一定建樹的技術(shù)大牛
分享他們的經(jīng)驗，還會分享很多直播講座和技術(shù)沙龍
可以免費(fèi)學(xué)習(xí)！劃重點！開源的！??！
qq群號：110685036

Appmock使用界面

由此，“后端接口穩(wěn)定性”的問題，在Appmock的幫助下就解決了，如果把后端數(shù)據(jù)直接配置在Appmock上，請求失敗的概率就微乎其微。即便如此，仍然要面臨頻繁修改配置的需求，只不過是把修改的操作從商家后臺頁面轉(zhuǎn)移到了mock系統(tǒng)。有沒有什么方法，可以讓修改配置的操作自動化進(jìn)行呢？

在研讀過Appmock的源碼后，我們想到，可以自己搭建一個mock-server，把不同階段的mock數(shù)據(jù)保存在數(shù)據(jù)庫中，并且開放出網(wǎng)絡(luò)接口，用來切換各個測試用例所需的mock數(shù)據(jù)。具體的系統(tǒng)結(jié)構(gòu)如下圖所示。

上圖描述了一次用例運(yùn)行的簡要過程，事前需要在數(shù)據(jù)庫中準(zhǔn)備好測試數(shù)據(jù)，mock-server基于Appmock，使用NodeJS進(jìn)行二次開發(fā)完成。

編寫測試用例

為了簡化用例編寫，減少開發(fā)與維護(hù)的工作量，使用Page Object模式進(jìn)行用例開發(fā)。

Page Object定義為抽象頁面的對象，通過對頁面功能的封裝，進(jìn)行相應(yīng)操作。它的優(yōu)點是：

• 減少重復(fù)代碼，增加復(fù)用性。

• 提高代碼可讀性、穩(wěn)定性。

• 易于維護(hù)。

UI自動化測試框架的編寫方式類似于MVC架構(gòu)，我們將測試用例中的業(yè)務(wù)邏輯、各個頁面間的元素以及測試數(shù)據(jù)相分離后獨立編寫，以下均用排隊業(yè)務(wù)的主流程舉例。

測試類組成

測試類的組成包括setUp()，tearDown()方法以及各個測試用例testXXXX()，所有的測試用例必須以小寫test開頭，如正常排號下的testQueueNormalQueue()：

@Beforepublic void setUp() throws Exception {
 ? ?File apk = new File(APK_NOVA);
 ? ?DesiredCapabilities capabilities = DesiredCapabilities.android();
 ? ?capabilities.setCapability("device", Platform.ANDROID);
 ? ?capabilities.setCapability(CapabilityType.VERSION, "5.1");
 ? ?…… ? ? ? // capabilities各個常量字段
 ? ?driver = new AndroidDriver<AndroidElement>(new URL("http://127.0.0.1:4723/wd/hub"), capabilities);
 ? ?splashScreen = new SplashScreen(driver);
 ? ?mainPage = new MainPage(driver);
 ? ?…… ? ? ? // Page Object初始化}@Afterpublic void tearDown() throws Exception {
 ? ?driver.quit();
}@Testpublic void testQueueNormalQueue() { ? ?// 略}

測試用例中不用直接對頁面元素進(jìn)行操作，我們所要做的事情僅僅是業(yè)務(wù)層面的邏輯，包括表單數(shù)據(jù)的提交、頁面按鈕的點擊跳轉(zhuǎn)等等。

頁面類編寫

頁面類的編寫采用Page Object模式，包括頁面中會使用到的元素、頁面元素的操作方法集以及頁面元素的檢驗方法集。

所有的Page子類均繼承BasePage父類，它要做的事情很簡單，無非就是1個driver，2個driverWait用于延時加載的等待時間，以及頁面元素的初始化：

public class BasePage { ? ?private static final int TIMEOUT = 1; ? ? ? ? ? ? // short timeout for web-element
 ? ?private static final int TIMEOUT_LONG = 10; ? ? ? // long timeout for web-element
 ? ?public AndroidDriver<AndroidElement> driver; ? ?public WebDriverWait driverWait; ? ?public WebDriverWait driverLongWait; ? ?public BasePage(AndroidDriver<AndroidElement> driver) { ? ? ? ?this.driver = driver; ? ? ? ?this.driverWait = new WebDriverWait(this.driver, TIMEOUT); ? ? ? ?this.driverLongWait = new WebDriverWait(this.driver, TIMEOUT_LONG);
 ? ? ? ?PageFactory.initElements(this.driver, this); ?// 這句非常重要，如果不寫的話盡管編譯不會報錯，但是后面要說的頁面元素在運(yùn)行時一個都找不到
 ? ?}
}

然后是各個Page子類的實現(xiàn)方法：

public class ShopInfoPage extends BasePage { ? ?public ShopInfoPage(AndroidDriver<AndroidElement> driver) { ? ? ? ?super(driver);
 ? ?}
 ? ?…… // 頁面元素 @FindBy
 ? ?…… // 操作方法，比如login()、clickXXXXXXButton()、gotoXXXXXXPage()
 ? ?…… // 檢驗方法，比如checkLoaded()、checkLoginSuccess()、checkQueue_LoginReadyQueue()}

Page子類的元素定位我們使用@FindBy注解方式進(jìn)行統(tǒng)一的管理。

元素定位最基本的方法就是使用id/name/class等，如果不行的話就用相對復(fù)雜卻無所不能的xpath，如：

// 點擊登錄按鈕@FindBy(id = "login_tip")private WebElement clickLoginButton;// MAPI域名輸入框@FindBy(xpath = "http://*[contains(@resource-id, 'id/mapi_item')]//*[contains(@resource-id, 'id/debug_domain')]")private WebElement mapiDomainText;

Page中的操作和檢驗方法調(diào)用已經(jīng)封裝好的BaseUtils中的方法，如：

BaseUtils.waitForElement(driverWait, loginButton).click(); ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?// 等待元素出現(xiàn)并點擊Assert.assertTrue(BaseUtils.waitForElementVisibility(driverLongWait, usernameText)); ? ?// 檢驗元素應(yīng)該展示在頁面上

BaseUtils方法

BaseUtils中封裝好了一些通用的方法，還需要不斷完善并擴(kuò)展。下面介紹其中一些常用及重要的方法：

1. openDebugPanel()：每次直接調(diào)用該方法來打開Debug面板，由于Debug面板是一個系統(tǒng)層面的懸浮窗，它不屬于任何頁面中的元素（你完全沒辦法通過ID甚至XPath獲得）。

2. clickPoint()：點擊某個坐標(biāo)+持續(xù)時間，坐標(biāo)采用相對屏幕位移的方式（左上為0,0），這里只實現(xiàn)了簡單的單指的點擊操作，實際上driver.tap可以模擬多指的共同操作。

3. swipeToUp() & swipeToDown()：上拉 & 下拉頁面操作，需要傳的是次數(shù)和每次持續(xù)時間，模擬手指在屏幕上的滑屏操作，主要用于刷新頁面以及繞過某些有坑的scrollTo。

4. prepareMockData()：這里要做的就是，在關(guān)鍵步驟操作前傳入mock_data_id，我們會將數(shù)據(jù)請求發(fā)送給服務(wù)器，然后服務(wù)器從數(shù)據(jù)庫拉到對應(yīng)的mock data并更新。

5. saveScreenshot()：顧名思義，截圖。在每個重要的頁面操作方法中加入即可，需要傳入的是case_id以及操作或檢查時的keyword，方便在用例執(zhí)行完以后看截圖分析和Bug復(fù)現(xiàn)。

6. waitForElementXXX()：在預(yù)設(shè)等待時間內(nèi)等待元素出現(xiàn)并定位元素。

UI自動化測試運(yùn)行效果

在排隊與閃惠兩條業(yè)務(wù)線進(jìn)行了UI自動化測試實踐，它們執(zhí)行完成全套用例的耗時均不超過20min。相比于之前人工進(jìn)行主流程測試動輒花費(fèi)半天的工作量的情況，大大降低了人力成本，將工程師寶貴的時間節(jié)約給了更有價值的研發(fā)工作。

當(dāng)然，自動化測試前期的環(huán)境搭建、數(shù)據(jù)準(zhǔn)備、用例編寫等任務(wù)是必不可少的，這些準(zhǔn)備工作很多都是一次性投入，一勞永逸，也正是自動化測試的價值所在。

今天的分享就到此結(jié)束了， 如果文章對你有幫助，記得點贊，收藏，加關(guān)注。會不定期分享一些干貨哦....文章來源地址http://www.zghlxwxcb.cn/news/detail-719242.html

到了這里，關(guān)于基于 Appium 的 Android UI 自動化測試！的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！