從壹個移動APP開發角度出發，定義終端設備有四個基本特征：
1．操作系統：由“API指標”（ 1 ～18 ）專業定義的安卓操作系統版本（ 1.1～ 4.3 ），。
2．顯示器：屏幕主要是由屏幕分辨率（以像素為單位），屏幕像素密度（ 以DPI為單位），和/或屏幕尺寸（以英寸為單位）定義的。
3．CPU：該“應用程序二進制接口” （ABI ）定義CPU的指令集。這裏的主要區別是ARM和基於Intel的CPU。
4．內存：壹個設備包括內存儲器（ RAM）和Dalvik 虛擬存儲器（ VM堆）的預定義的堆內存。
這是前兩個特點，操作系統和顯示器，都需要特別註意，因為他們是直接由最終用戶明顯感受，且應該不斷嚴格地被測試覆蓋。至於安卓的版本， 2013年7月市場上有八個同時運行導致不可避免的碎片的不同版本。七月，近90％這些設備中的34.1 ％正在運行Gingerbread版本（ 2.3.3-2.3.7 ），32.3 ％正在運行Jelly Bean（ 4.1.x版），23.3 ％正在運行Ice Cream Sandwich（ 4.0.3 - 4.0.4 ）。
考慮設備顯示器，壹項TechCrunch從2013年4月進行的研究顯示，絕大多數（79.9％）有效設備正在使用尺寸為3和4.5英寸的“正常”屏幕。這些設備的屏幕密度在“MDPI”（～160 DPI），“hdpi”（～240 DPI）和“xhdpi”（～320 DPI）之間變化。也有例外， 壹種只占9.5％的設備屏幕密度低“hdpi”（～120 DPI）且屏幕小。
如果這種多樣性在質量保證過程中被忽略了，那麽絕對可以預見：bugs會潛入應用程序，然後是bug報告的風暴，最後Google Play Store中出現負面用戶評論。因此，目前的問題是：妳怎麽使用合理水平的測試工作切實解決這壹挑戰？定義測試用例及壹個伴隨測試過程是壹個應付這壹挑戰的有效武器。
用例—“在哪測試”、“測試什麽”、“怎麽測試”、“何時測試”？
“在哪測試”
為了節省妳測試工作上所花的昂貴時間，我們建議首先要減少之前所提到的32個安卓版本組合及代表市場上在用的領先設備屏的5-10個版本的顯示屏。選擇參考設備時，妳應該確保覆蓋了足夠廣範圍的版本和屏幕類型。作為參考，您可以使用OpenSignal的調查或使用手機檢測的信息圖[3]，來幫助選擇使用最廣的設備。
為了滿足好奇心，可以從安卓文件[5]將屏幕的尺寸和分辨率映射到上面數據的密度（“ldpi”，“mdpi”等）及分辨率（“小的”，“標準的”，等等）上。
有了2013手機檢測研究的幫助，很容易就找到了代表性的壹系列設備。有壹件有趣的瑣事：30％印度安卓用戶的設備分辨率很低只有240×320像素，如上面列表中看到的，三星Galaxy Y S5360也在其中。另外，480×800分辨率像素現在最常用（上表中三星Galaxy S II中可見）。
“測試什麽”
移動APP必須提供最佳用戶體驗，以及在不同尺寸和分辨率（關鍵字“響應式設計”）的各種智能手機和平板電腦上被正確顯示（UI測試）。與此同時，apps必須是功能性的和兼容的（兼容性測試），有盡可能多的設備規格（內存，CPU，傳感器等）。加上先前獲得的“直接”碎片化問題（關於安卓的版本和屏幕的特性）， “環境相關的”碎片化有著舉足輕重的作用。這種作用涉及到多種不同的情況或環境，其中用戶正在自己的環境中使用的終端設備。作為壹個例子，如果網絡連接不穩定，來電中斷，屏幕鎖定等情況出現，妳應該慎重考慮壓力測試[4]和探索性測試以確保完美無錯。
有必要提前準備覆蓋app最常用功能的所有可能的測試場景。早期bug檢測和源代碼中的簡單修改，只能通過不斷的測試才能實現。
“怎麽測試”
將這種廣泛的多樣性考慮在內的壹種務實方法是， 安卓模擬器 - 提供了壹個可調節的工具，該工具幾乎可以模仿標準PC上安卓的終端用戶設備。簡而言之，安卓模擬器是QA流程中用各種設備配置（兼容性測試）進行連續回歸測試（用戶界面，單元和集成測試）的理想工具。探索性測試中，模擬器可以被配置到壹個範圍廣泛的不同場景中。例如，模擬器可以用壹種能模擬連接速度或質量中變化的方式來設定。然而，真實設備上的QA是不可缺少的。實踐中，用作參考的虛擬設備依然可以在壹些小的（但對於某些應用程序來說非常重要）方面有所不同，比如安卓操作系統中沒有提供程序特定的調整或不支持耳機和藍牙。真實硬件上的性能在評價過程中發揮了自身的顯著作用，它還應該在考慮了觸摸硬件支持和設備物理形式等方面的所有可能終端設備上進行測試（可用性測試）。
“何時測試”
既然我們已經定義了在哪裏（參考設備）測試 ，測試什麽（測試場景），以及如何（ 安卓模擬器和真實設備）測試，簡述壹個過程並確定何時執行哪壹個測試場景就至關重要了。因此，我們建議下面的兩級流程：
1 ．用虛擬設備進行的回歸測試。
這包括虛擬參考設備上用來在早期識別出基本錯誤的連續自動化回歸測試。這裏的理念是快速地、成本高效地識別bugs。
2 ．用真實設備進行的驗收測試。
這涉及到：“策劃推廣”期間將之發布到Google Play Store前在真實設備上的密集測試（主要是手動測試），（例如，Google Play[ 5 ]中的 alpha和beta測試組） 。
在第壹階段，測試自動化極大地有助於以經濟實惠的方式實現這壹策略。在這壹階段，只有能輕易被自動化（即可以每日執行）的測試用例才能包含在內。
在壹個app的持續開發過程中，這種自動化測試為開發人員和測試人員提供了壹個安全網。日常測試運行確保了核心功能正常工作，app的整體穩定性和質量由測試數據透明地反映出來，認證回歸可以輕易地與最近的變化關聯。這種測試可以很輕易地被設計並使用SaaS解決方案（如雲中的TestObject的UI移動app測試）從測試人員電腦上被記錄下來。
當且僅當這個階段已被成功執行了，這個過程才會在第二階段繼續勞動密集測試。這裏的想法是：如果核心功能通過自動測試就只投入測試資源，使測試人員能夠專註於先進場景。這個階段可能包括測試用例，例如性能測試，可用性測試，或兼容性測試。這兩種方法相結合產生了壹個強大的移動apps質量保證策略[ 7 ] 。