寫給Android開發者的UI自動化測試上手指南

咱們經常聽到這樣的問題：「爲何軟件的開發者們不適合測試他們本身開發的軟件？」。事實上，要回答這個問題須要明白開發者去進行測試的目的。本篇文章不會深刻到自動化測試的具體細節，是對如何減小重複測試進行簡單實踐，讓業務開發人員可以簡單快速上手纔是最終目的。

開發人員測試本身所開發軟件的行爲就像學生在完成考試後對本身的成績進行評估，因此可能會出現下面的問題：

• 開發人員對其所寫代碼有主觀認同感
• 開發人員對軟件過於樂觀的心態
• 開發人員對需求易產生誤差與混淆
• 開發人員擅長修復但不擅長拆解
• 開發人員缺少對軟件後續開發的展望
• 開發人員缺少測試經驗和方法

---

開發者測試的目的

就如前面所說，軟件開發者測試本身開發的程序好像並沒多大意義，測試工程師具備不少優點條件，那做爲開發者進行自動化測試的目的是什麼？ 其實從下面的圖就能解釋一切，程序員這個職業存在的意義不就是最大化利用機器，經過自動化來完成工做嗎？

做爲軟件開發者需求很明顯，當須要對本身開發的功能進行驗證時，老是須要反覆調試後才能提測。這不可避免的須要咱們重複UI操做去覆蓋測試路徑，經過查看界面內容和日誌輸出驗證問題。而UI自動化測試偏偏能夠知足這一點，減小咱們重複操做ui驗證的步驟。

---

Android自動化測試介紹

關於Android自動化測試，能夠去官網看一下介紹Getting Started with Testing。

本篇文章不會對深刻到自動化測試的細節進行描述，只是做爲開發人員對如何減小重複工做量進行簡單的實踐，因此這裏直接推薦騰訊U測社區的一篇文章： 5個最佳的Android測試框架，有興趣的童鞋能夠了解一下目前主流的自動化測試框架。

解放你的雙手

做爲一個業務開發人員，解放雙手進行功能驗證性測試纔是最根本的需求，因此下面介紹一下使用Espresso進行UI自動化測試的流程。

爲何選擇Espresso測試框架？ 很簡單，Espresso是Google針對Android平臺開源的一款最新的Android自動化測試框架。不用考慮跨平臺、兼容性等各類問題，最貼合需求才是最好的。

UI自動化測試依據

UI自動化測試的基本思路：把本身當成用戶，只關注我能看到的東西。

咱們把本身做爲使用程序的最終用戶，要讓機器模擬個人測試過程，那麼就須要針對那些我能看到的東西，也就是UI組件進行驗證。 **好比說，**做爲用戶並不關心某個網絡請求返回值的具體數據是否正確，我關心的是能在UI上看到但願看到的結果。

基於此，作各個測試用例的一個通用的思路就是：**找到某個元素，作一些操做，檢查結果。**這裏包含了三個流程：

• **找元素：**找到UI上測試所針對的元素；
• **作操做：**給這個元素作一些操做；
• **檢查結果：**這個元素作出了我指望的行爲。

再直觀一點，咱們測試向一個EditText輸入一段文字，那麼整個過程就能夠描述爲：

• **找元素：**找到EditText組件；
• **作操做：**向EditText輸入字符串；
• **檢查結果：**EditText顯示了我輸入的字符串，驗證內容是否符合。

以上三個小步驟實際上也是咱們做爲用戶在使用一個APP的時候所遵循的流程。而咱們的測試也是基本遵循這樣一個流程的。下面是官方文檔中給出的一個簡單測試用例的代碼：

@Test
public void greeterSaysHello() {
  onView(withId(R.id.name_field))
    .perform(typeText("Steve"));
  onView(withId(R.id.greet_button))
    .perform(click());
  onView(withText("Hello Steve!"))
    .check(matches(isDisplayed()));
}
複製代碼

代碼邏輯也是典型的三步：

1. 首先經過withId方法找到了id爲name_field的EditText組件，而且調用typeText方法對其進行設置text內容爲"Steve"；

2. 再經過withId方法找到id爲greet_button的Button組件，掉頭click方法模擬點擊該按鈕；
3. 最後經過withText方法查找text內容等於"Hello Steve!"的TextView組件，調用check方法判斷該組件是否匹配(matches方法)是否可見狀態(isDisplayed)。

UI自動化具體實例

這裏建議參照官方文檔給出的步驟進行實踐，示例給出本身在實踐demo中配置自動化測試的基本步驟。Espresso setup instructions

1. 在gradle添加支持 在app目錄下build.gradle中dependencies設置對Espresso庫的編譯依賴，在android.defaultConfig設置InstrumentationRunner。

// 在app目錄下的build.gradle添加對Espresso的依賴
dependencies {
  androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {    
     exclude group: 'com.android.support', module: 'support-annotations'
  })
  androidTestCompile 'com.android.support.test.espresso:espresso-idling-resource:2.2.2'
  ...
}

// 在app目錄下的build.gradle中設置instrumentation runner
defaultConfig {
  ...
  testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
複製代碼

2. 建立Test Case文件 在Android Studio執行測試的代碼類文件須要在app模塊的androidTest文件夾下建立。以下圖所示:

3. 編寫測試用例代碼 好比當咱們爲TestActivity建立TestActivityTest測試用例類文件成功之後：

• 首先須要在測試用例類的類體前添加@RunWith的註解，並設置測試運行平臺爲AndroidJUnit4
• 若是容許測試須要較大消耗，可使用@LargeTest註解
• 設置ActivityTestRule用來指明被測試的Activity，使用@Rule註解。

運行測試時用例時會自動啓動到對應的Activity，而且經過ActivityTestRule的示例獲取到被測試Activity的context。

• 編寫測試方法，按照前面說的「找元素，作操做， 驗證結果」三個步驟編 寫測試方法，使用@Test註解。

建議使用test做爲方法名的開頭，這樣能夠更好區分普通方法和測試方法

如上圖所示，代碼爲TestActivity建立了測試用例類TestActivityTest，其中testDeciceName爲其中一個測試用例方法。該方法主要是經過id查找到EditText，自動輸入內容後模擬點擊id爲bt_get_string的button，最後驗證textview顯示內容是否符合。

4. 運行Test Case 在Android Studio的終端中輸入gradlew connectedAndroidTest 或 gradlew cAT執行測試用例。 總體運行效果以下：

5. 異步和延遲 有時點擊一個按鈕，ui操做後須要執行一個較爲耗時的事情時一般會採用異步回調的方式通知顯示結果，這時進行UI自動化測試的第三步驗證結果的時機就不能才能同步的方式去執行，而是須要作異步回調通知執行或延遲執行。

Espresso提供了原生的異步測試支持，經過實現IdlingResource接口，複寫getName()、isIdleNow()、registerIdleTranstionCallback()方法。 如圖所示FuncExecuteIdlingResource：

而後在測試用例的類中註冊和反註冊接口： Espresso.registerIdlingResources(idlingResource);

當方法執行完成，調用ResourceCallback.onTransitionToIdle();則會進行回調通知測試線程繼續執行驗證代碼。

總結

一切能自動化完成的測試操做就不要浪費時間用手動完成。後續將會對單元測試進行說明，共同窗習，相互提高。