移動App測試中的最佳做法

標籤：android   style   http   io   ar   os   使用   sp   java   

Daniel Knott 用過各種不同程式設計語言和軟體品質保證工具。他在軟體開發與測試方面幹了七年，自2010年起，他一直在德國漢堡的XING AG公司就職，幾個項目裡，比如XING調查和XING建議，他負責測試管理，測試自動化和測試執行。Daniel現在是XING移動和XING API團隊的品質保證團隊負責人。在XING移動團隊中，他還負責XING安卓和iPhone Apps的測試管理和測試自動化。Daniel在包括像Robotium， KIF (Keep It Functional)， Selenium and Java一類工具的軟體測試自動化方面經驗豐富。他還在各類敏捷大會上作了陳述且定期發表到他的部落格上和XING部落格上。

?

　　一提到軟體測試，測試員基本想到的就是去檢查檔案，功能，API，效能並確定軟體是否安全，以及關於軟體特定部分的其他事項。而對於Mobile Testing，測試員不得不基於使用者移動使用模式考慮移動相關的功能。
　　 本文是基於我的工作經驗而寫的。作為一名敏捷式軟體開發 (Agile Software Development)團隊的軟體品質保證經理，我一心投入iPhone， Android， Windows Phone 7的移動apps和移動web apps。在XING移動團隊的日常工作以及與其他Mobile Testing專家交流的過程中，我深刻瞭解了Mobile Testing工作的困難。漸漸地，我明確了什麼是協助改進同事們和我的測試工作並為使用者提供更高品質app的移動最佳做法。

　　功能測試
　　 每項開發的新功能都需要進行測試。移動app測試中功能測試是一個重要方面，Mobile Testing員應該要進行手動測試和自動化測試。剛開始測試時，測試員必須把移動app 當做“黑盒”一樣進行手動測試，看看提供的功能是否正確並如設計的一樣正常運作。除了經典軟體測試，像點擊按鈕看看會發生什麼，測試員還必須執行更多功能的行動裝置專門的測試。
　　 如今，現代行動裝置都有觸控螢幕，要求多點觸控動作來與它們互動。裝置可以是縱向或橫向顯示屏。它們提供動作，傾斜和螺旋感應器。它們有不同的介面可以串連其他裝置或服務，比如GPS，NFC，照相機，LED等等。 
　　 移動軟體測試員必須確保app的所有特定裝置功能在app裡都能用。行動裝置的種類這麼多，測試時要將所有的覆蓋是不可能的，所以功能測試時測試員要專註於他們app的關鍵之處。什麼是真的簡單有效呢？裝置旋轉。我測試工作期間發現有許多bug僅需將裝置從縱向旋轉為橫向再旋轉回來就好了。 
　　 除了整個手動測試過程，測試自動化對移動app也很重要。每個代碼變化或新功能都可能影響現存功能及它們的狀態。通常手動迴歸測試時間不夠，所以測試員不得不找一個工具去進行自動化迴歸測試。現在市面上有很多Mobile Testing自動化工具，有商業的也有開源額，面向各個不同平台，如Android，iPhone，Windows Phone 7， BlackBerry以及移動web app。根據開發策略和結構，品質保證專家需要找出最適合他們環境的自動化工具。 
　　 安卓的話，就有Robotium[ROB01]， Robolectric [ROB02]， Roboguice [ROB03]， MonkeyTalk [MON01]，Monkeyrunner [MON02]， NativeDriver [NAT01] and Calabash for Android[CAL01]等開源工具。自動化工具Robotium已經變成開源界的實際標準。它用起來很簡單且是基於安卓測試裝置的。 
　　 iPhone的測試自動化工具包括KIF (Keep It Functional) [KIF01]，UIAutomation [UIA01]， MonkeyTalk [MON01]， Calabash for iOS [CAL02]，Frank [FRA01]， Zucchini [Zuc01]等等。所有這些工具也可以在裝置或iOS模擬器上類比真實使用者互動。選擇一個工具對測試自動化並不容易，但做決定時有一點要牢記，因為很重要: 測試自動化應該使用同樣的程式設計語言作為產品代碼。如果測試和產品代碼用一樣的語言去寫，那對測試員和開發員都有好處，因為這就使得他們做配對代碼時可以輕鬆些。測試員可以和開發員在同一水平進行交流，他們可以執行測試和產品代碼的代碼審查。對於測試自動化，開發員可以用他們習慣的語言編寫他們自己的指令碼。

　　總結：
　　 ??把app作為“黑盒”進行測試並試著中斷它。
　　 ??開啟移動app的每個螢幕並將裝置從縱屏變為橫屏再變回縱屏。 
　　 ??別忘了去測試裝置特定的功能，比如感應器和通訊介面。 
　　 ??為移動app編寫測試自動化指令碼。 
　　 ??選擇一個適應公司策略和結構的測試自動化工具。 
　　 ??測試和產品代碼應該用同一種語言。

　　非功能測試
　　 移動app測試的另一重要方面是移動app的非功能需求。移動app在推出市場或進行進一步開發前，Mobile Testing員有許多需要測試的問題。
　　 早期開發階段要進行的第一個測試應該是實用性測試。通常是由alpha使用者或同事進行的。走進一家咖啡館或餐廳，問問裡面的人他們的app使用方式。讓他們看看現階段開發的第一個版本並收集反饋，看看使用者是否能很好地使用新功能，以便得出第一印象。 
　　 檢查app的效能。將推出的版本與目前的版本做一番比較，看看效能是一樣？更好？還是更差？將app安裝到舊的裝置上，看看該app在舊裝置上是否仍能運作，無論硬體裝置好或差。最先進的裝置也一樣要這麼做。 
　　 測試電話，簡訊，多媒體訊息，微博或其他通知進來時app的反應。使用app時檢查一下電量。確保測試過程測試裝置是充滿電的並每十分鐘檢查一下電池使用方式，看看該app有沒有太耗電。在低電量時把app安裝到裝置上看看會發生什麼。檢查app的記憶體使用量情況。如果app在本地檔案系統中儲存資料，測測不同記憶卡的使用方式。想想看本機存放區快滿時會發生什麼呢——app會崩潰或彈出出錯提醒框來通知使用者嗎？ 
　　 測試app的安裝和刪除過程。更重要的是，測試從老版本升級為新版本的過程。或許本機資料庫已經改變了，這樣就會引起一些嚴重的遷移問題。 
　　 App被本地化了嗎？測試員需要用不同的語言測試app。記得在不同的網路載體上以不同的網速進行測試。確定該app在GPRS， EDGE， UMTS， LTE和WiFi環境下都能運作。 
　　 別忘了檢查網路連接不好或完全掉了時app會怎麼反應。飛航模式下使用該app看看如果一個請求失敗了會發生什麼。將測試裝置串連到電腦上並檢查開發記錄檔有沒有例外、警告或其他奇怪的異常之處。這些只是Mobile Testing員和開發員開發與測試一個app時應該考慮的非功能需求中的一部分。每方面都檢查到位是絕不可能的，因此整體團隊應該支援QA成員盡量覆蓋更多方面以防使用者得到不好的體驗。?

　　總結：
　　 ??做實用性測試。
　　 ??比較app已推出版本和新版本的效能。 
　　 ??檢查電話，簡訊，多媒體訊息或微博或進來時app的反應。 
　　 ??檢查測試裝置的電量。 
　　 ??測試app的記憶體使用量情況。 
　　 ??安裝並刪除app。 
　　 ??測試從舊版本升級到新版本的過程。 
　　 ??檢查語言的轉換。 
　　 ??在不同的載體和網路連接，如GPRS，WiFi， or LTE，環境中使用app。 
　　 ??檢查記錄檔的錯誤或例外。

　　測試裝置——片段
　　 對於一個移動品質保證者來說，關於Mobile Testing裝置的關鍵問題是，“測試該用哪個工具比較好呢？”這個問題必須解決，因為無法在每台裝置上都測試一遍！就此來看，行動裝置市場上有兩大玩家：Android和iOS!但是因為地理位置的原因，一些其他平台也常用到。有Windows，BlackBerry， webOS， SymbianOS， 以及功能機。圖一的表格中列出了中國、德國以及美國供應商提供的智能機作業系統的使用方式。

圖一：智能機作業系統
資料來源：www.thinkwithgoogle.com/mobileplanet/en

　　幾乎每個平台都有不同的供應商在售賣擁有不同硬體，軟體規格和定製使用者介面的智能機。比如安卓，就有像Samsung， HTC， ASUS， LG， Motorola， Sony， Huawei等供應商。這是裝置片段的一個重要例子，且要找到恰當的測試裝置真的很難。移動網頁是另一個相當難搞的問題，因為行動瀏覽器種類太多，如：Safari， Opera Mini，Dolphin， Android and RIM native， Google Chrome， Firefox， Internet Explorer9以及其他功能機瀏覽器！那麼到底該選什麼測試裝置呢？就用最新的瀏覽器版本嗎？把市場上的每種裝置都買來？還是使用模擬器？
　　 在此對模擬器小注一下：別用模擬器測試！它們或許對基本測試有所協助，但其結果與真機上的結果卻是不同的。
　　 以我之見，解決這個測試裝置問題的一個不錯的主意就是將裝置和瀏覽器混合起來。比如，Mobile Testing員可以根據他們的硬體和軟體規格將裝置群組合起來。每個組合確定一個優先事項，比如A=最高，B=平均，C=最低。每組都包含根據平台和供應商分配到那一類的裝置。 
　　 可能的組合概述：
　　 ??組1，優先事項C：CPU和RAM小，解析度低的小裝置。舊的軟體版本和瀏覽器 
　　 ??組2，優先事項B：一般CPU， RAM <512 MB， 顯示屏大小和解析度好的中檔裝置。軟體不是最新的。
　　 ??組3，優先事項A：雙核/四核CPU， RAM >512 MB， 解析度高的高檔裝置。最新的軟體版本。
　　 這三組涵蓋了一個特定平台上的絕大多數使用者，也代表了市場上適合這一組的其他手機。這可以減少開發與測試過程中要求的工作。

　　總結：
　　 ??組合并選出優先測試裝置和瀏覽器版本。
　　 ??不要用模擬器進行測試。

　　組合工具
　　 正如之前所提到的，Mobile Testing員必須對移動app進行測試自動化以保證代碼變化不會影響現在的功能。另一個最佳做法就是組合測試載入器並將它們整合為一個連續的整合服務器以便從中心開始執行這些工具。開發員需要為他們的代碼寫單元測試以確保每個細小的組件的且如期運作。另外，使用像Robotium或Keep It Functional一類的工具進行端到端的檢查測試，就像使用者一樣，很有用。

　　總結：
　　 ??組合測試載入器並將之整合為一個連續的系統。

　　內部Beta版本
　　 如果一個移動團隊想要早點與移動app的beta測試員溝通，他們可以建立他們自己的內部app商店，比如安卓的和iPhone.的。有了hockeykit [HOC01]工具，團隊就可以通過公司WIFI把app的新版本傳給同事。這是從同事那獲得重要反饋的有效方法，尤其是如果團隊或測試員沒機會向外界展示該app。Hockeykit也提供關於怎樣測試該app以及同事們用了哪種OS版本和裝置的有用資料。它還包括一個crash reporter以便看到導致現開發版本錯誤和崩潰的原因。

　　總結：
　　 用內部beta版本獲得早期反饋。

　　瞭解顧客
　　 如果開發員和測試團隊瞭解以後將會使用app的顧客的話，Mobile Testing就會更加有效。收集顧客資訊的好地方是特定供應商的app商店（Apple App Store， Google Play Store， Windows Marketplace等）。如果一個團隊在這些商店中已有了一款app，他們就會獲得關於顧客使用的裝置，軟體版本，語言以及載體的資訊。下面圖2是Google Play Store的執行個體，展示了一個發行的安卓app的資料。而移動網頁，卻沒有app商店提供相關使用者資料。所以，收集關於移動網頁裡所使用的“使用者代理程式”（裝置，瀏覽器）的資訊就有意義了。意識到這點，團隊就可以最佳化各種裝置和軟體版本並減少花在開發與測試它們上的精力了。

? 圖2： Google Play Store關於使用的安卓裝置和OS版本的資料

　　除了使用者資料，app商店裡的顧客評論也需要細細整理以便收集重要的反饋以及他們對新功能的期待，並對所報bug做出回應。

　　總結：
　　 ??瞭解你的顧客所使用的裝置和軟體版本
　　 ??利用來自供應商市場的資料 
　　 ??認真對待app商店裡的評論

　　在論壇社區主動出擊
　　 這是最後一個最佳做法，它與日常Mobile Testing工作不直接相關，但或許可以幫你從不同的角度思考並獲得新的想法。
　　 在社區裡做一個主動積極的軟體測試員，就像： 
　　 ?? utest (www.utest.com) 
　　 ?? mobileqazone (www.mobileqazone.com) 
　　 ?? softwaretestingclub (www.softwaretestingclub.com)

　　在這樣的社區裡，軟體測試員可以和其他（移動）品質保證專家就各種測試話題交流觀點意見。他們可以共用知識，協助其他人解決他們遇到的問題。測試員可以在寫測試案例時得到很棒的想法：關於如何寫出好的bug報告，並且還可以提高他們自己的測試和測試自動化技能。

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

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

移動App測試中的最佳做法