設計安卓 Apps測試案例

標籤：style   blog   class   tar   ext   http   

Erik Nijkamp（[email protected] testobject.com）是TestObject股份有限公司（其總部在柏林郊區的Hennigsdorf）的CEO。TestObject專攻移動領域的QA解決方案，並提供雲端式的應用程式測試服務（該服務用直觀的測試記錄器從根本上簡化能提供測試自動化並可以隨時使用任一手機APP的測試的UI測試）。作為產品所有者，他專註於TestObject業務解決方案的戰略聯盟。他在矽谷（美國IBM研究所）及諮詢公司（IBM德國股份有限公司）期間，他獲得了非常寶貴的高科技領域的經驗。

　　在當今競爭激烈的市場上一個APP的成功離不開一個可靠的使用者介面（UI）。因此，對功能和使用者體驗有一些特殊關注和照顧的UI的全面測試是必不可少的。當涉及到安卓平台及其提出的獨特問題的數量（安卓就UI提出顯著挑戰）時，挑戰變得更加複雜。關鍵字“片段化”象徵著行動裝置 App全面測試的最大障礙，還表明了發布到市場上的所有形態、大小、配置類型的安卓裝置所引起的困難。本文將介紹安卓模擬器如何能通過使用一些技巧和簡單的實踐提供覆蓋大量裝置類型的廣泛測試。

　　簡介—分散裝置裡的測試
　　 一般安卓開發人員在其日常工作中面臨的最大挑戰之一是：終端裝置和作業系統版本的範圍太廣。OpenSignal進行的一項研究表明，2013年7月市場上有超過11，828的不同安卓終端裝置，所有裝置在類型/大小/螢幕解析度以及特定配置方面有所不同。考慮到前一年的調查僅記錄有3，997款不同裝置，這實在是一個越來越大的挑戰障礙。

圖1.11，828 款安卓裝置類型（ OpenSignal研究， 2013年7月[ 1 ] ）分布

　　從一個移動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 ）。

圖2.16款安卓版本分布（OpenSignal研究，2013年7月[1]）

　　考慮裝置顯示器，一項TechCrunch從2013年4月進行的研究顯示，絕大多數（79.9％）有效裝置正在使用尺寸為3和4.5英寸的“正常”螢幕。這些裝置的螢幕密度在“MDPI”（160 DPI），“hdpi”（240 DPI）和“xhdpi”（320 DPI）之間變化。也有例外， 一種只佔9.5％的裝置螢幕密度低“hdpi”（120 DPI）且螢幕小。

圖3. 常見的螢幕尺寸和密度的分布（Google研究，2013年4月）[2]

　　如果這種多樣性在品質保證過程中被忽略了，那麼絕對可以預見：bugs會潛入應用程式，然後是bug報告的風暴，最後Google Play Store中出現負面使用者評論。因此，目前的問題是：你怎麼使用合理水平的測試工作切實解決這一挑戰？定義測試案例及一個伴隨測試過程是一個應付這一挑戰的有效武器。

　　用例—“在哪測試”、“測試什麼”、“怎麼測試”、“何時測試”？
　　 “在哪測試”
　　 為了節省你測試工作上所花的昂貴時間，我們建議首先要減少之前所提到的32個安卓版本組合及代表市場上在用的領先裝置屏的5-10個版本的顯示屏。選擇參考裝置時，你應該確保覆蓋了足夠廣範圍的版本和螢幕類型。作為參考，您可以使用OpenSignal的調查或使用手機檢測的資訊圖[3]，來協助選擇使用最廣的裝置。
　　 為了滿足好奇心，可以從安卓檔案[5]將螢幕的尺寸和解析度映射到上面資料的密度（“ldpi”，“mdpi”等）及解析度（“小的”，“標準的”，等等）上。

圖5.多樣性及分布很高的安卓終端裝置的六個例子（手機檢測研究，2013年2月）[3]

　　有了2013手機檢測研究的協助，很容易就找到了代表性的一系列裝置。有一件有趣的瑣事：30％印度安卓使用者的裝置解析度很低只有240×320像素，如上面列表中看到的，三星Galaxy Y S5360也在其中。另外，480×800解析度像素現在最常用（上表中三星Galaxy S II中可見）。

　　“測試什麼”
　　 移動APP必須提供最佳使用者體驗，以及在不同尺寸和解析度（關鍵字“響應式設計”）的各種智能手機和平板電腦上被正確顯示（UI測試）。與此同時，apps必須是功能性的和相容的（相容性測試），有儘可能多的裝置規格（記憶體，CPU，感應器等）。加上先前獲得的“直接”片段化問題（關於安卓的版本和螢幕的特性）， “環境相關的”片段化有著舉足輕重的作用。這種作用涉及到多種不同的情況或環境，其中使用者正在自己的環境中使用的終端裝置。作為一個例子，如果網路連接不穩定，來電中斷，螢幕鎖定等情況出現，你應該謹慎考慮壓力測試[4]和探索性測試以確保完美無錯。

圖6. 測試安卓裝置的各個方面

　　 有必要提前準備覆蓋app最常用功能的所有可能的測試情境。早期bug檢測和原始碼中的簡單修改，只能通過不斷的測試才能實現。

　　“怎麼測試”
　　 將這種廣泛的多樣性考慮在內的一種務實方法是， 安卓模擬器 - 提供了一個可調節的工具，該工具幾乎可以模仿標準PC上安卓的終端使用者裝置。簡而言之，安卓模擬器是QA流程中用各種裝置配置（相容性測試）進行連續迴歸測試（使用者介面，單元和整合測試）的理想工具。探索性測試中，模擬器可以被配置到一個範圍廣泛的不同情境中。例如，模擬器可以用一種能類比連線速度或品質中變化的方式來設定。然而，真實裝置上的QA是不可缺少的。實踐中，用作參考的虛擬設備依然可以在一些小的（但對於某些應用程式來說非常重要）方面有所不同，比如安卓作業系統中沒有提供者特定的調整或不支援耳機和藍芽。真實硬體上的效能在評價過程中發揮了自身的顯著作用，它還應該在考慮了觸摸硬體支援和裝置物理形式等方面的所有可能終端裝置上進行測試（可用性測試）。

　　“何時測試”
　　 既然我們已經定義了在哪裡（參考裝置）測試 ，測試什麼（測試情境），以及如何（ 安卓模擬器和真實裝置）測試，簡述一個過程並確定何時執行哪一個測試情境就至關重要了。因此，我們建議下面的兩級流程：
　　 1 ．用虛擬設備進行的迴歸測試。 
這包括虛擬參考裝置上用來在早期識別出基本錯誤的連續自動化迴歸測試。這裡的理念是快速地、成本高效地識別bugs。
　　 2 ．用真實裝置進行的驗收測試。 
這涉及到：“策劃推廣”期間將之發布到Google Play Store前在真實裝置上的密集測試（主要是手動測試），（例如，Google Play[ 5 ]中的 alpha和beta測試組） 。
　　 在第一階段，測試自動化極大地有助於以經濟實惠的方式實現這一策略。在這一階段，只有能輕易被自動化（即可以每日執行）的測試案例才能包含在內。 
　　 在一個app的持續開發過程中，這種自動化測試為開發人員和測試人員提供了一個安全網。日常測試回合確保了核心功能正常工作，app的整體穩定性和品質由測試資料透明地反映出來，認證迴歸可以輕易地與最近的變化關聯。這種測試可以很輕易地被設計並使用SaaS解決方案（如雲中的TestObject的UI移動app測試）從測試人員電腦上被記錄下來。 
　　 若且唯若這個階段已被成功執行了，這個過程才會在第二階段繼續勞動密集測試。這裡的想法是：如果核心功能通過自動化的測試就只投入測試資源，使測試人員能夠專註於先進情境。這個階段可能包括測試案例，例如效能測試，可用性測試，或相容性測試。這兩種方法相結合產生了一個強大的移動apps品質保證策略[ 7 ] 。

　　結論 - 做對測試
　　 用正確的方式使用，測試可以在對抗零散的安卓的鬥爭中成為一個有力的工具。一個有效測試策略的關鍵之處在於定義手頭app的定製測試案例，並定義一個簡化測試的工作流程或過程。測試一個移動app是一個重大的挑戰，但它可以用一個結構化的方法和正確的工具集合以及專業知識被有效解決掉。

 

　　著作權聲明：本文出自 SPASVO澤眾軟體測試網：http://www.spasvo.com/news/html/2014429143529.html

　　原創作品，轉載時請務必以超連結形式標明本文原始出處、作者資訊和本聲明，否則將追究法律責任。