Android應用測試：解決方案匯總
譯文【51CTO譯文】對Android或者iOS平臺上的應用程序進行檢查其實并不像大家想象的那么特別。我們工作的目標是一樣的，期望的結果是一樣的，操作的過程也是一樣的。與桌面平臺相比，移動應用測試的主要區別在于我們需要更多地留心細節，而這也正是今天這篇文章所要討論的重點。
1. 基本原則
在我們深入討論之前，首先來聊聊關于測試的一些基本原則。除非大家已經透徹了解并且熟知整套測試體系，否則對相關背景知識進行說明能幫助各位快速明確自己有哪些解決思路可供選擇。
Android上的挑戰
真正讓Android得到人們青睞的在于它那不計其數的可能性。在iOS陣營當中，我們能夠想到的只有iPhone、iPad以及iPod Touch。它們在樣式上有所不同，但卻擁有iOS設備所共通的像素密度、屏幕分辨率、處理器速度以及內存大小等等。
但在Android這邊，同樣的外觀尺寸、屏幕分辨率與大小、處理器速度乃至內存容量等可以構建出無數具體組合——而“錦上添花”的是，操作系統版本的碎片化又讓這一切變得更加復雜。
說起操作系統的版本，運營商與手機制造商在推出產品之后很快停止為其提供版本更新的作法在Android陣營可以說是屢見不鮮。這到底算不算是問題呢？當然是。感興趣的朋友可以點擊此處查看谷歌官方提供的Android市場份額統計，了解這一問題到底有多嚴重。
在市場份額下降的項目當中，我們看到了果凍豆（4.1至4.3版本）、姜餅（2.3版本）與冰淇淋三明治（4.0版本）的身影。
相比之下，蘋果iOS 7的接受比例則明顯理想得多。截至今年一月底，已經有八成iOS設備運行iOS 7。需要提醒大家的是，iOS 7是在去年九月才正式發布的——相較而言，二者的表現可謂判若云泥。
學習、對比與參照
不知道大家有沒有真正體驗過糟糕的Android應用程序？相較于那些從頭到尾一無是處的應用，更為可惡的是那些充斥著無數漏洞、讓人根本捉摸不透其運行結果的垃圾。
根據我的個人經驗，要讓測試過程變得更順利、更富成效，大家的關注重點起著非常關鍵的作用——包括我們使用什么、喜歡什么和憎惡什么。雖然憎惡這個詞似乎有些太過強烈，但我確信各位在使用過程中的確體會到過這樣的感受。
請大家客觀回答以下幾個問題：
- 你最喜歡的應用程序有哪些？為什么它們能獲得你的肯定？
- 你曾經體驗過哪些糟糕的應用程序？
- 一款應用程序是靠哪些因素而變得出色的？它們是否在開發過程中注意到了細節？
- 糟糕的應用程序是不是會在運行當中經常卡死？會不會一個勁兒崩潰？或者在設計思路上就存在問題？
了解自己要應對的是哪些Android設備
讓我們再說回之前談到的Android操作系統市場份額參考圖表。可以看出，對每一臺設備以及每一個Android版本進行測試根本就是癡人說夢、也并無必要。
我的觀點是，我們需要考慮發行方面的具體需求。我們的應用程序是什么、面向的又是哪類目標市場？這是一款游戲還是實用工具類應用？
如果這是一款游戲，那么關注重點可能僅僅放在更新、更高端的設備知上。不過對于實用工具類應用程序來說，大家則需要吸引到更為廣泛的客戶群體并支持數量更龐大的設備類型。
#p#
2. 實施方案
我感覺大多數朋友沒能做好測試工作的主要原因在于，我們都與自己的項目太過貼近也太過熟悉。我們很清楚自己的應用程序在何處情況下會出現故障，也知道該如何將其重新扳回運行正軌。有鑒于此，我會刻意讓自己站在普通用戶的立場之上。我一般會把用戶分為兩大類——一類是狂點按鈕型、另一類才是真正的普通用戶。
狂點按鈕型
狂點按鈕型指的是那些從應用程序啟動之后就不斷鼓搗屏幕的使用者，他們一會點這個按鈕、一點碰那個按鈕，一刻也閑不下來。“剛剛點的那個按鈕沒起作用，我再點別的試試。”
我們對不同用戶類型的學習將貫穿整個應用程序的開發周期。如果出現某些情況、接收到某種請求或者發生某種操作，我們的應用程序是否會大量占用處理器資源或者是用盡設備的內存容量？這類情況又是否會導致應用程序陷入崩潰？
另一個值得關注的重要問題是，“我們該如何通知用戶即將出現的結果。”為什么他們沒有等待，反而選擇了直接點觸其它按鈕？我們能否利用載入界面幫助他們弄清自己該如何操作？
普通用戶型
普通用戶擁有明確的使用意圖。用更好的方式來解釋的話，這類用戶會花一點時間查看用例并了解應用程序的使用方法。如果提供一套特定任務執行流程，他們會希望加以體驗并遵循應用本身給出的操作步驟。
我們需要了解自己的應用程序在為用戶提供處理流程或者操作指引方面是否表現得足夠明確。借助這種思路，我們會理解用戶為何在使用過程中感到迷惑，又有哪些部分值得留意或者重新定義。
我們已經討論過了努力目標與不同用戶類型，但我們能夠給出哪些選項、又該如何對其進行測試呢？很幸運，可選方案非常豐富，而且我建議大家盡可能多了解這類可行性選項。
#p#
3.可選方案
給朋友打電話
如果大家沒有奢侈到擁有自己的常見問題部門或者測試實驗室，那么不妨先從與朋友交流開始。我們需要自己的親身體驗與相關物理設備。
在進行移動應用程序測試時，數量起到的作用其實非常顯著，特別是在大家擁有大量可用設備的情況下。
工具與單元測試
自動化測試方案是我們的好朋友。盡管***的測試辦法仍然是親手對應用程序進行完整體驗，但了解代碼層面的狀況以及應用程序會在特定條件下、特別是在壓力條件下作出怎樣的編程化反應同樣非常關鍵。
更重要的是，單元測試能幫助大家在開發的同時完成測試工作，這會在應用程序真正發布之前為我們節約下大量的測試與常見問題解決時間。
Android SDK
Android SDK為我們提供Android測試框架，這套框架主要由基于JUnit與monkeyrunner的測試API所構成。
Android JUnit擴展允許開發人員針對Android組件編寫出單元測試機制，而該Android API還具備面向特定組件的預置測試類。
基于Python的monkeyruuner則是另一套API，允許大家編寫出能夠以用戶的角度出發實現設備控制的程序。這意味著大家可以創建出可以運行在多種設備或者模擬器上的測試方案，向其發送按鍵點擊記錄并獲取屏幕截圖。
其它測試框架
目前市面上可用的測試框架可謂層出不窮。其中一部分的人氣相對較高，最典型的代表就是Robolectric與Robotium。
Robolectric是一套運行在我們IDE環境下的單元測試框架，它同時也是一套能夠對預建代碼進行良好審計的卓越方案。Robotium的測試對象則主要是模擬器環境下的Android API。雖然它在完成測試的時耗方面表現得更長，但大家的應用程序代碼將在其幫助下變得更為堅實，效果其實不遜于對設備以及API進行實際測試。
另一套有趣的備選方案則是Espresso。與前面兩套選項相比，它主要面向某些較為特殊的測試目標。具體而言，它是一套專門對Android UI進行測試的API。
前面提到的各類選項都相當出色，不過如果大家打算創建一套混合型應用程序，那么它們也許幫不上什么忙。Appium是一套跨平臺自動化框架，允許大家構建起能夠面向各類語言、兩大主流移動平臺的測試機制。
報告與分析
多查看一些統計數據也會很有幫助，而且更重要的是，大家應該收集錯誤與崩潰日志。如果大家擁有多位應用程序測試人員，這種方式將變得更為實用，因為我們可以借此將每一位用戶的日志記錄收集起來。
除了追蹤應用程序使用情況之外，Google Analytics還能夠帶來一些意外驚喜。Flurry屬于另一套測試選項。其實這項功能已經存在了相當一段時間了，其報告與崩潰記錄也包含有較為詳盡的信息。
盡管它無法在應用程序開發階段為我們帶來幫助，但谷歌能夠收集Play Store中應用程序的崩潰記錄。
#p#
4. 第三方備選方案
我們都希望擁有幾百臺物理設備用來測試，正如我們在網站上見過的那些規模龐大的測試實驗室一般。然而大家都知道，這明顯不切實際。為了解決這個難題，如果大家愿意在測試方面作出投資、那么可用的服務也是很多的。
這些服務可謂五花八門，從一對一人力測試到數百臺設備上的全自動測試應有盡有。如果大家愿意選擇付費項目，這些方案都是完全可行的。
我自己其實也沒體驗過那么多方案，但User Testing作為其中之一給我留下了很深的印象。他們會派出一位專員關注我們的測試腳本，并通過應用程序體驗給出來自外部的建議與意見。
下面幾項服務也都值得認真考慮，感興趣的朋友請立刻打開搜索引擎吧：
總結
我經歷過很多消極的狀況，開發者誤以為常見問題匯總與測試似乎應該是后期處理工作。但事實上，它們正是開發流程當中非常重要的組成部分。
作為一套擁有眾多版本的龐大陣營，Android操作系統似乎看起來難于打理、甚至有些可怕，然而在采用編程化解決方案之后、它完全可以成為開發流程的固有步驟。為此投入額外的時間與精力完全是物有所值，請大家注意——高質量應用程序不會憑空而來。
