移動App測試中的最佳做法

移動App測試中的最佳做法

來自專欄 自動化測試

一說起軟體測試,測試員想到肯定是去檢查文件,功能,API,性能並確定軟體是 否安全,以及關於軟體特定部分的其他事項。但是對於移動測試,測試員不得不基於用戶移動使用模式考慮移動相關的功能。

本文是基於我的工作經驗而寫的。作為一名敏捷軟體開發團隊的軟體質量保證經理,我一心投入iPhone,Android,WindowsPhone7的移動apps和移動webapps。在XING移動團隊的日常工作以及與其他移動測試專家交流的過程中,我深刻了解了移動測試工作的困難。漸漸地,我明確了什麼是幫助改進同事們和我的測試工作並為用戶提供更高質量app的移動最佳做法。

功能測試

每項開發的新功能都需要進行測試。移動app測試中功能測試是一個重要方面,移動測試員應該要進行手動測試和自動化測試。剛開始測試時,測試員必須把移動app當做"黑盒"一樣進行手動測試,看看提供的功能是否正確並如設計的一樣正常運作。除了經典軟體測試,像點擊按鈕看看會發生什麼,測試員還必須執行更多功能的移動設備專門的測試。

如今,現代移動設備都有觸摸屏,要求多點觸控動作來與它們互動。設備可以是縱向或橫向顯示屏。它們提供動作,傾斜和螺旋感測器。它們有不同的介面可以連接其他設備或服務,比如GPS,NFC,照相機,LED等等。

移動軟體測試員必須確保app的所有特定設備功能在app里都能用。移動設備的種類這麼多,測試時要將所有的覆蓋是不可能的,所以功能測試時測試員要專註於他們app的關鍵之處。什麼是真的簡單有效的呢?設備旋轉。我測試工作期間發現有許多bug僅需將設備從縱向旋轉為橫向再旋轉回來就好了。

除了整個手動測試過程,測試自動化對移動app也很重要。每個代碼變化或新功能都可能影響現存功能及它們的狀態。通常手動回歸測試時間不夠,所以測試員不得不找一個工具去進行自動化回歸測試。現在市面上有很多移動測試自動化工具,有商業的也有開源額,面向各個不同平台,如Android,iPhone,WindowsPhone7,BlackBerry以及移動webapp。根據開發策略和結構,質量保證專家需要找出最適合他們環境的自動化工具。

安卓的話,就有Robotium[ROB01],Robolectric[ROB02],Roboguice[ROB03],MonkeyTalk[MON01],Monkeyrunner[MON02],NativeDriver[NAT01]andCalabashforAndroid[CAL01]等開源工具。自動化工具Robotium已經變成開源界的實際標準。它用起來很簡單且是基於安卓測試設備的。

iPhone的測試自動化工具包括KIF(KeepItFunctional)[KIF01],UIAutomation[UIA01],MonkeyTalk[MON01],CalabashforiOS[CAL02],Frank[FRA01],Zucchini[Zuc01]等等。所有這些工具也可以在設備或iOS模擬器上模擬真實用戶互動。選擇一個工具對測試自動化並不容易,但做決定時有一點要牢記,因為很重要:測試自動化應該使用同樣的編程語言作為產品代碼。如果測試和產品代碼用一樣的語言去寫,那對測試員和開發員都有好處,因為這就使得他們做配對代碼時可以輕鬆些。測試員可以和開發員在同一水平進行交流,他們可以執行測試和產品代碼的代碼審查。對於測試自動化,開發員可以用他們習慣的語言編寫他們自己的腳本。

總結:

把app作為"黑盒"進行測試並試著中斷它。

打開移動app的每個屏幕並將設備從縱屏變為橫屏再變回縱屏。

別忘了去測試設備特定的功能,比如感測器和通信介面。

為移動app編寫測試自動化腳本。

選擇一個適應公司策略和結構的測試自動化工具。

測試和產品代碼應該用同一種語言。

非功能測試

移動app測試的另一重要方面是移動app的非功能需求。移動app在推出市場或進行進一步開發前,移動測試員有許多需要測試的問題。

早期開發階段要進行的第一個測試應該是實用性測試。通常是由alpha用戶或同事進行的。走進一家咖啡館或餐廳,問問裡面的人他們的app使用情況。讓他們看看現階段開發的第一個版本並收集反饋,看看用戶是否能很好地使用新功能,以便得出第一印象。

檢查app的性能。將推出的版本與當前版本做一番比較,看看性能是一樣?更好?還是更差?將app安裝到舊的設備上,看看該app在舊設備上是否仍能運作,無論硬體設備好或差。最先進的設備也一樣要這麼做。

測試電話,簡訊,彩信,微博或其他通知進來時app的反應。使用app時檢查一下電量。確保測試過程測試設備是充滿電的並每十分鐘檢查一下電池使用情況,看看該app有沒有太耗電。在低電量時把app安裝到設備上看看會發生什麼。檢查app的內存使用情況。如果app在本地文件系統中存儲數據,測測不同內存卡的使用情況。想想看本地存儲快滿時會發生什麼呢--app會崩潰或彈出出錯提醒框來通知用戶嗎?

測試app的安裝和刪除過程。更重要的是,測試從老版本升級為新版本的過程。或許本地資料庫已經改變了,這樣就會引起一些嚴重的遷移問題。

App被本地化了嗎?測試員需要用不同的語言測試app。記得在不同的網路載體上以不同的網速進行測試。確定該app在GPRS,EDGE,UMTS,LTE和WiFi環境下都能運作。

別忘了檢查網路連接不好或完全掉了時app會怎麼反應。飛行模式下使用該app看看如果一個請求失敗了會發生什麼。將測試設備連接到電腦上並檢查開發日誌文件有沒有例外、警告或其他奇怪的異常之處。這些只是移動測試員和開發員開發和測試一個app時應該考慮的非功能需求中的一部分。每方面都檢查到位是絕不可能的,因此整體團隊應該支持QA成員盡量覆蓋更多方面以防用戶得到不好的體驗。

總結:

做實用性測試。

比較app已推出版本和新版本的性能。

檢查電話,簡訊,彩信或微博或進來時app的反應。

檢查測試設備的電量。

測試app的內存使用情況。

安裝並刪除app。

測試從舊版本升級到新版本的過程。

檢查語言的轉換。

在不同的載體和網路連接,如GPRS,WiFi,orLTE,環境中使用app。

檢查日誌文件的錯誤或例外。

測試設備--碎片

對於一個移動質量保證者來說,關於移動測試設備的關鍵問題是,"測試該用哪個工具比較好呢?"這個問題必須解決,因為無法在每台設備上都測試一遍!就此來看,移動設備市場上有兩大玩家:Android和iOS!但是因為地理位置的原因,一些其他平台也常用到。幾乎每個平台都有不同的供應商在售賣擁有不同硬體,軟體規格和定製用戶界面的智能機。比如安卓,就有像Samsung,HTC,ASUS,LG,Motorola,Sony,Huawei等供應商。這是設備碎片的一個重要例子,且要找到恰當的測試設備真的很難。移動網頁是另一個相當難搞的問題,因為移動瀏覽器種類太多,如:Safari,OperaMini,Dolphin,AndroidandRIMnative,GoogleChrome,Firefox,InternetExplorer9以及其他功能機瀏覽器!那麼到底該選什麼測試設備呢?就用最新的瀏覽器版本嗎?把市場上的每種設備都買來?還是使用模擬器?在此對模擬器小注一下:別用模擬器測試!它們或許對基本測試有所幫助,但其結果與真機上的結果卻是不同的。以我之見,解決這個測試設備問題的一個不錯的主意就是將設備和瀏覽器組合起來。比如,移動測試員可以根據他們的硬體和軟體規格將設備組合起來。每個組合確定一個優先事項,比如A=最高,B=平均,C=最低。每組都包含根據平台和供應商分配到那一類的設備。

可能的組合概述:

組1,優先事項C:CPU和RAM小,解析度低的小設備。舊的軟體版本和瀏覽器

組2,優先事項B:一般CPU,RAM<512MB,顯示屏大小和解析度好的中檔設備。軟體不是最新的。

組3,優先事項A:雙核/四核CPU,RAM>512MB,解析度高的高檔設備。最新的軟體版本。

這三組涵蓋了一個特定平台上的絕大多數用戶,也代表了市場上適合這一組的其他手機。這可以減少開發和測試過程中要求的工作。

總結:

組合併選出優先測試設備和瀏覽器版本。

不要用模擬器進行測試。

組合工具

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

總結:

組合測試工具並將之集成為一個連續的系統。

內部Beta版本

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

總結:

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

了解顧客

如果開發員和測試團隊了解以後將會使用app的顧客的話,移動測試就會更加有效。收集顧客信息的好地方是特定供應商的app商店(AppleAppStore,GooglePlayStore,WindowsMarketplace等)。如果一個團隊在這些商店中已有了一款app,他們就會獲得關於顧客使用的設備,軟體版本,語言以及載體的信息。移動網頁,卻沒有app商店提供相關用戶數據。所以,收集關於移動網頁里所使用的"用戶代理"(設備,瀏覽器)的信息就有意義了。意識到這點,團隊就可以優化各種設備和軟體版本並減少花在開發和測試它們上的精力了。

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

總結:

了解你的顧客所使用的設備和軟體版本

利用來自供應商市場的數據

認真對待app商店裡的評論

在論壇社區主動出擊

這是最後一個最佳做法,它與日常移動測試工作不直接相關,但或許可以幫你從不同的角度思考並獲得新的想法。

在社區里做一個主動積極的軟體測試員,就像:在這樣的社區里,軟體測試員可以和其他(移動)質量保證專家就各種測試話題交流觀點意見。他們可以共享知識,幫助其他人解決他們遇到的問題。測試員可以在寫測試用例時得到很棒的想法:關於如何寫出好的bug報告,並且還可以提高他們自己的測試和測試自動化技能。

推薦閱讀:

TAG:自動化測試 | APP測試 | 軟體測試 |