Daniel Knott 用過各種不同編程語言和軟件質量保證工具。他在軟件開發(fā)和測試方面干了七年，自2010年起，他一直在德國漢堡的XING AG公司職，幾個項目里，比如XING調查和XING建議，他負責測試管理，測試自動化和測試執(zhí)行。Daniel現(xiàn)在是XING移動和XING API團隊的質量保證團隊負責人。在XING移動團隊中，他還負責XING安卓和iPhone Apps的測試管理和測試自動化。Daniel在包括像Robotium， KIF (Keep It Functional)， Selenium and Java一類工具的軟件測試自動化方面經(jīng)驗豐富。他還在各類敏捷大會上作了陳述且定期發(fā)表到他的博客上和XING博客上。

　　一提到軟件測試，測試員基本想到的是去檢查文件，功能，API，性能并確定軟件是否安全，以及關于軟件特定部分的其他事項。而對于移動測試，測試員不得不基于用戶移動使用模式考慮移動相關的功能。
　　本文是基于我的工作經(jīng)驗而寫的。作為一名敏捷軟件開發(fā)團隊的軟件質量保證經(jīng)理，我一心投入iPhone， Android， Windows Phone 7的移動apps和移動web apps。在XING移動團隊的日常工作以及與其他移動測試專家交流的過程中，我深刻了解了移動測試工作的困難。漸漸地，我明確了什么是幫助改進同事們和我的測試工作并為用戶提供更高質量app的移動佳做法。

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

　　總結：
　　▪▪把app作為“黑盒”進行測試并試著中斷它。
　　▪▪打開移動app的每個屏幕并將設備從縱屏變?yōu)闄M屏再變回縱屏。
　　▪▪別忘了去測試設備特定的功能，比如傳感器和通信接口。
　　▪▪為移動app編寫測試自動化腳本。
　　▪▪選擇一個適應公司策略和結構的測試自動化工具。
　　▪▪測試和產品代碼應該用同一種語言。

　　非功能測試
　　移動app測試的另一重要方面是移動app的非功能需求。移動app在推出市場或進行進一步開發(fā)前，移動測試員有許多需要測試的問題。
　　早期開發(fā)階段要進行的第一個測試應該是實用性測試。通常是由alpha用戶或同事進行的。走進一家咖啡館或餐廳，問問里面的人他們的app使用情況。讓他們看看現(xiàn)階段開發(fā)的第一個版本并收集反饋，看看用戶是否能很好地使用新功能，以便得出第一印象。
　　檢查app的性能。將推出的版本與當前版本做一番比較，看看性能是一樣？更好？還是更差？將app安裝到舊的設備上，看看該app在舊設備上是否仍能運作，無論硬件設備好或差。先進的設備也一樣要這么做。
　　測試電話，短信，彩信，微博或其他通知進來時app的反應。使用app時檢查一下電量。確保測試過程測試設備是充滿電的并每十分鐘檢查一下電池使用情況，看看該app有沒有太耗電。在低電量時把app安裝到設備上看看會發(fā)生什么。檢查app的內存使用情況。如果app在本地文件系統(tǒng)中存儲數(shù)據(jù)，測測不同內存卡的使用情況。想想看本地存儲快滿時會發(fā)生什么呢——app會崩潰或彈出出錯提醒框來通知用戶嗎？
　　測試app的安裝和刪除過程。更重要的是，測試從老版本升級為新版本的過程�；蛟S本地數(shù)據(jù)庫已經(jīng)改變了，這樣會引起一些嚴重的遷移問題。
　　App被本地化了嗎？測試員需要用不同的語言測試app。記得在不同的網(wǎng)絡載體上以不同的網(wǎng)速進行測試。確定該app在GPRS， EDGE， UMTS， LTE和WiFi環(huán)境下都能運作。
　　別忘了檢查網(wǎng)絡連接不好或完全掉了時app會怎么反應。飛行模式下使用該app看看如果一個請求失敗了會發(fā)生什么。將測試設備連接到電腦上并檢查開發(fā)日志文件有沒有例外、警告或其他奇怪的異常之處。這些只是移動測試員和開發(fā)員開發(fā)和測試一個app時應該考慮的非功能需求中的一部分。每方面都檢查到位是絕不可能的，因此整體團隊應該支持QA成員盡量覆蓋更多方面以防用戶得到不好的體驗。 

　　總結：
　　▪▪做實用性測試。
　　▪▪比較app已推出版本和新版本的性能。
　　▪▪檢查電話，短信，彩信或微博或進來時app的反應。
　　▪▪檢查測試設備的電量。
　　▪▪測試app的內存使用情況。
　　▪▪安裝并刪除app。
　　▪▪測試從舊版本升級到新版本的過程。
　　▪▪檢查語言的轉換。
　　▪▪在不同的載體和網(wǎng)絡連接，如GPRS，WiFi， or LTE，環(huán)境中使用app。
　　▪▪檢查日志文件的錯誤或例外。