Android應用測試的幾個要點

無論你多努力，代碼設計花費多少時間，編程時候有多小心，你的程序中都會有Bug,這是不可避免的。但是，大家都清楚，早期發現Bug會節約一大筆項目資源、減少軟件維護費用。這就是為開發項目寫測試用例的最好理由，不久你就會發現效率提高了。

另外，寫測試用例的過程中，迫使你對需求了解更透徹，對要解決的問題了解更深入全面。如果你不了解被測對象，是不可能寫好測試用例的。同樣，寫好測試用例可以清晰了解舊程序和第三方代碼，讓你能力倍增，更加有信心升級（舊程序、第三方代碼）代碼。

測試覆蓋率越高，發現隱藏Bug的概率就越高。通過覆蓋率分析，發現測試用例沒有覆蓋到的地方，就應該新增測試用例。

測試覆蓋技術需要Android平臺構造一個特殊的監控器來收集監測數據，但是不能發布，因為它會影響性能，從而嚴重影響應用的表現。

為了彌補這個空白，請訪問EMMA。它是一個開源工具，用于測量和報告Java代碼測試覆蓋率，可以衡量類的覆蓋率。它的報告有幾個維度：

類覆蓋率；

方法覆蓋率；

行覆蓋率；

基礎塊覆蓋率。

覆蓋率報告同樣可以設置成不同的格式。從某種程度上說，EMMA是基于Andoid框架的，所以，可以建一個帶EMMA模擬器版本的Android系統。

圖1展示了在裝了兼容的plugin后，經過EMMA覆蓋率分析后，用Eclipse編輯器打開并分析的文件，綠色（運行后可看到，全書同）的代碼行表示該行已經覆蓋到了。

圖1　EMMA覆蓋率分析結果

不幸的是，這個插件不支持Android測試，因此，你只能用它來做Junit單元測試，而且你只能通過HTML來看Android覆蓋率分析報告。

測試應該有自動化，每當你更改或者新增代碼時，你就可以運行一部分或者全量測試用例來確保之前的邏輯是對的，以及新代碼邏輯也是符合測試預期的。這就是我們說的持續集成，第8章我們將介紹。它依賴于自動化測試和自動化構建過程。

如果你沒用到自動化測試，那實際上不可能把持續集成作為開發過程的一部分，而且很難保證代碼變更情況下，不破壞現有代碼邏輯。

1　測試的內容是什么呢

一個Android應用，測試點是什么呢？嚴格地說，代碼的每一行都應該經過測試。不過，根據不同的測試標準，你可以采用只需要覆蓋到重要的路徑分支或者一部分重要內容的方法。通常，有一些不可能被打破而產生Bug的地方就沒有必要測試。比如：getter方法和setter方法測起來就沒啥意思。這就好比編譯器早就有自己的測試工程，而你也不可能在自己的代碼中來測試編譯器一樣。

除了程序功能屬于測試要點之外，Android應用還有一些特殊的地方需要考慮。我們將在下面幾節進行描述。

2　Activity生命周期中的事件

Activity對生命周期中的事件是否能夠正確響應是一個測試點。

比如，你的Activity在OnPause()事件和OnDestroy()事件中需要保存自身的狀態，然后在OnCreate(Bandle savedInstanceState)時恢復狀態。那么，你應該重復執行并驗證在這些條件下狀態是否能夠正確保存、是否能恢復正常。

在測Activity時，還需要驗證配置項變化事件的響應。因為配置變化后，當前的Activity需要重新生成。此時，你要驗證新生成的Activity對事件的響應是否正常以及先前的狀態是否恢復正常。定時循環事件也會觸發配置的變化。因此，你還要看看應用是否能夠正確處理這些事件。

3　數據庫和文件系統的操作

數據庫操作和文件的正確讀寫也是一個測試點。對這些操作的測試應該在底層系統測試中完成，在ContentProviders中進行高層次的測試，需要跟應用本身隔離開。

要對這些部件進行獨立的測試，Android提供了Mock對象的工具，在andriod.test.mock包中。

4　設備的物理特征

在你發布應用程序之前，要確保它能在不同的設備上正常運行。至少你能把握大概的情況并想好對策。

在設備的物理特性中，有以下幾個測試點：

網絡容量；

屏幕分辨率；

屏幕厚度；

屏幕尺寸；

傳感器；

鍵盤和其他輸入設備；

GPS；

擴容。

由于有上述幾個方面需要測試，虛擬器尤為重要。因為虛擬器可以讓你通過簡單配置達到上述條件的硬件特性。但是，如之前提到的，到最后的測試階段，還是要用真機來操作，模擬真實用戶的使用過程來測試。

本文節選自《Android 應用測試指南》

本文轉載自異步社區。

軟件開發 移動開發 Android

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。