Android/測試
測試是一個廣泛的主題,包含各種結合不同方法的測試方法,但其本質是試圖確保使用者的體驗令人滿意:直觀、可靠、響應迅速、安全等。諸如測試驅動開發和行為驅動開發之類的實踐在撰寫本文時很流行,使用諸如 單元測試 和 整合測試 這樣的方法,但更廣泛的測試領域包括檢查使用者是否能夠直觀地瞭解如何實現目標,而不會感到沮喪或文化上的誤解,以及檢查應用程式執行的伺服器是否能夠承受預期的平均吞吐量、優雅地處理峰值負載、能夠抵抗攻擊等等。
單元測試是在與(大部分)應用程式的其餘部分隔離的情況下測試一個類,並且是測試驅動開發的重要組成部分,其中會編寫失敗的測試,以便應用程式能夠被“除錯到存在”。
當正在開發的程式碼與 Android 無關時,標準的 Java 單元測試技術適用,但當代碼與 Android 系統發生互動時,需要進行一定程度的變通(類似於處理遺留程式碼時所需的操作),以克服包括以下問題在內的困難
- 開發機器上的 android.jar(應用程式構建在其上)在嘗試執行其方法時丟擲異常
- Android 將這些丟擲異常的方法中的許多宣告為final,這使得它們無法直接包含在被測程式碼中
- Android 使用static方法,同樣無法直接測試。
關於 單元測試 的部分提供了可以幫助解決這些問題的各種方法;你需要評估它們對你來說是否有效。
以下工具可能也與上述方法一起使用,可以證明很有用
- Robolectric - 提供對 Android 類的單元測試友好模擬,這些模擬在主機 PC 上執行,比在手機或具有非原生架構的模擬器上執行具有更快的編譯/執行週期。 [1]
- Hamcrest - 提供有用的和可讀的抽象來構建帶有有用診斷資訊的斷言條件
- awaitility - 幫助進行非同步測試
- 模擬物件 庫提供了構建模擬物件的強大方法
- 依賴注入,它允許你根據介面和對映系統而不是直接透過類來請求物件,因此你可以在不破壞編譯程式碼的情況下替換測試類。這可能會簡化你的程式碼,減少程式碼閱讀量……或者使其更難跟蹤到底是誰呼叫了什麼,並且它可能會使啟動時間無法接受地變慢。
- RoboGuice
- Spring
- 相關
- Android Annotations - 作為減少樣板(進而減少編碼錯誤)的一種手段很有前景,但與測試沒有直接關係。它的單元測試部分提到了 Robolectric,這很好。
- Android Binding 不是完全的依賴注入,而是試圖使用 MVVM 來分離關注點,可能值得檢視。
單元測試是在很大程度上隔離地測試類,而系統測試則檢查整個程式集在目標平臺上執行時的工作情況,整合測試則檢查選定的一組部件是否能夠正確地組合在一起——在更容易設定和操作且可以直接訪問程式程式碼的受控條件下。
官方 Android 文件傾向於關注基於 AndroidTestCase 及其子類的測試,評論者經常稱它們為“單元測試”。這些測試絕對不是單元測試:因為它們與 Android 系統整合,所以它們至少是整合測試,但由於它們過於嵌入且執行速度太慢,無法作為單元測試,同時它們與程式碼本身的耦合度過高,無法作為系統測試。(也就是說,在基於英特爾的開發機器上,模擬器啟動英特爾 Atom Android 映象的時間不到 15 秒,而基於 ARM 的映象則需要 40 秒,這使得它變得更加有用。)
系統測試 對系統進行端到端測試:應用程式將位於裝置上,如果使用伺服器,它將與伺服器通訊。它們比單元測試執行速度慢,並且基於以“黑盒”方式透過 UI 驅動應用程式。它們是行為驅動開發的一部分。
由於它們在手機上執行,單元測試的編譯/執行週期變成了編譯/打包/安裝/執行週期,但它們針對的是真實實現,因此不會受到單元測試存根和模擬物件帶來的實現不準確性的風險。
以下工具可能很有用
- Robotium - 類似於 Android 上的 Selenium
- Sikuli - 一種螢幕抓取執行系統
- Monkeyrunner - 一種指令碼化的 UI 驅動工具
- Android SDK 測試 - 與 Android SDK 一起提供的舊測試系統。
對於隨機、長時間執行的測試
- Monkey - 一個隨機事件生成器,是 Android SDK 的一部分
一些商業工具在你的裝置上執行
- SeeTest、EggPlant(TestPlant)、Apphance
一些商業工具在工具提供商的裝置上執行
- DeviceAnywhere
一些應用程式是為瀏覽器編寫的,而不是針對 SDK。對於這些應用程式,Selenium 受支援——尤其是在 ICS 下使用 WebDriver。
有一些商業公司可以將你的應用程式提交給它們,以便在各種裝置上進行測試,這樣你就不用擁有所有各種平板電腦、手機和支援 Web 的冰箱,人們可能想要在這些裝置上執行你的應用程式。好的公司會透過嘗試向你出售各種測試方法(除了本書中介紹的方法)來提供隱含的諮詢:安全性、效能、可用性和本地化。他們能夠提供的功能測試通常會限於黑盒測試,儘管有人可能會開始提供靜態檢查和架構建議,這並非不可能。
在網上搜索“Android 測試”應該會顯示幾家此類公司的廣告。
測試也是程式碼,也可能存在錯誤!諸如變異測試以及條件、分支或行覆蓋之類的工具有助於確定你的程式碼中有多少程式碼實際上被測試過或僅看起來被測試過。
應用內截圖可以作為一種有用的除錯工具。 [2]