【轉】移動端App測試實用指南

轉自：互聯網那點事

英文原文: http://mobile.smashingmagazine.com/2012/10/22/a-guide-to-mobile-app-testing/

測試人員常被看做bug尋找者，但你曾想過他們實際是如何開展測試的嗎？你是否好奇他們究竟都作些什麼，以及他們如何在一個典型的技術項目中體現價值？

做者將帶你經歷測試人員的思惟過程，探討他們測試移動app時的各類考慮。本文的目的在於揭示測試人員的這一思惟過程，並展現他們一般所考慮內容的廣度和深度。

 

測試人員須要詢問問題

測試人員的核心能力在於提出有挑戰性的相關問題。若是你能將調查、詢問技巧和技術、產品的知識結合起來，漸漸地，你也會成爲一個好的測試人員。

好比，測試人員可能會問：

·　這個App應該在什麼平臺上使用？

·　這個App究竟是幹什麼的？

·　若是我這樣作，會發生什麼狀況？

諸如此類。

測試人員能從各類場景中發現問題，它們可能來自對話、設計、文檔、用戶反饋或者是產品自己。這些可能性太多了……所以，讓咱們一探究竟吧！

 

從哪裏開始測試

理想狀況下，測試人員應該掌握所測產品的全部最新細節資料。但事實上這不多見，所以，像其餘人同樣，測試人員只能將就使用手上有限的資料。但這不是不能測試的藉口！測試人員實際上是能夠從內部和外部多種不一樣的來源處收集信息的。

這個階段，測試人員能夠問這些問題：

· 　有哪些信息：規格？項目會議？用戶文檔？知識淵博的團隊成員？有支持論壇或者是公司在線論壇提供幫助？有現存Bug的記錄嗎？

·　該應用是在什麼系統、平臺和設備上進行運做和測試？

·　該應用是處理什麼類型的數據（好比我的信息、信用卡等等）？

·　該應用有整合外部應用（好比API和數據來源）嗎？

·　該應用須要用到特定的移動端網頁嗎？

·　現有消費者如何評價這個產品？

·　有多少時間可用於測試？

·　測試的優先級和風險是什麼？

·　哪些用戶使用起來不愉快，爲何？

·　如何發佈和更新？

基於以上收集的信息，測試人員能夠制定測試計劃了。一般預算決定測試方法，一天測完，一個星期或一個月測完的方法確定不一樣。當你逐漸熟悉團隊、工做流程以及這類問題的解決方式時，你就更容易預測結果了。

 

案例：Facebook App的社會評論

看成爲一名測試人員收集信息時，我喜歡選用Facebook App做爲案例，由於用戶的抱怨處處都是。如下僅僅展現了部分遇到難題的用戶在iTunes App Store中發表的評論，網絡上還有不少。

iPhone上的Facebook App有不少負面的評論

若是我接受挑戰去測試Facebook這個App，我確定會考慮這些反饋，不然就是傻子。

 

測試人員的創造力

你可能知道這個App本來想作的事，可是它究竟能夠作什麼事呢？用戶其實是如何使用它的？測試人員擅長做爲旁觀者來思考，嘗試不一樣的事物，以及不斷地詢問「若是。。。會怎麼樣」和「爲何」的問題。

好比，移動端的測試人員經常以不一樣的用戶角色進行測試——固然有點誇張，可是，這種把本身當成不一樣用戶進行思考、分析和設想的能力對測試是備受啓發的。

測試人員可能會設想本身是如下用戶：

·　毫無經驗；

·　頗有經驗；

·　愛好者；

·　黑客；

·　競爭對手。

固然還有更多可選的角色，這主要取決於大家所開發的產品是什麼。其實除了角色特色外，其操做行爲和工做流程也很重要。人們使用產品方式經常很奇怪，好比：

·　在不該該返回的時候返回了；

·　不耐心並且屢次敲按鍵；

·　輸入錯誤的數據；

·　不理解該怎麼作；

·　可能沒有按要求進行設置；

·　可能會自覺得是地認爲本身知道該怎作什麼（好比一般不閱讀說明）。

 

測試人員遇到這些問題時，也經常發現意料以外的Bug。有時候，這些Bug微不足道，可是更深刻的調查就會發現更嚴重的問題。

不少問題是能夠被預先肯定和測試的。測試移動端App時，如下的問題並不都有關，可是也能夠嘗試問問：

·　是否按照所說的來作呢？

·　是按設計完成任務的嗎？

·　不是按設計完成任務的嗎？

·　若是處於一直被使用或者負荷狀況下，情況會怎麼樣？會反應遲鈍嗎？會崩潰嗎？會更新嗎？有反饋嗎？

·　崩潰報告會反饋到App嗎？

·　用戶可能有哪些創造性的、邏輯性的或是消極的導航方式？用戶相信你的品牌嗎？

·　用戶的數據安全如何？

·　有可能被中斷或是被破解嗎？

·　運行到極限時會發生什麼情況？

·　會要求打開相關服務嗎(如GPS、Wi-Fi)？若是用戶打開會怎樣？沒打開又會怎樣？

·　將用戶從新引向哪兒？去網頁？仍是從網頁到App？這會致使問題出現嗎？

·　溝經過程和市場反饋是否符合該App的功能、設計和內容？

·　登陸流程是怎樣的？能在App上直接登陸仍是要去網頁端？

·　登陸是否整合了其餘服務，好比用Facebook和Twitter賬號登陸？

 

案例：Run Keeper’s gy Update

RunKeeper，是一款能跟蹤你健身活動的App，最新發布的版本里有個「目標設置」的功能，對此我很感興趣去體驗一下，一部分從測試人員的角度來看，更多的是做爲一個真心喜歡產品的用戶來體驗。但我發現了一些問題：

1.   默認單位是英鎊，我卻想要把公斤做爲重量單位；

2.   英鎊和公斤間的切換根本很差用；

3.   當設定目標後，會致使展現錯誤的數據和圖表，這讓我很迷惑；

4.   因爲第3條，我想刪除目標，但卻根本找不到刪除的地方；

5.   爲了解決這一問題，我不得不改變的我的體重的值，直到 「目標設置「範圍以內，這樣目標達到了，就能從新設定目標了；

6.   我會再次嘗試添加目標；

正由於以上疑惑，我花了更長的時間把玩它，看能不能找到其餘的問題；

如下是一些發現問題的屏幕截圖：

該App的最新版本包含了一個新的「目標」部分。設置日期的時候，我發現開始和結束的日期均可以從公元1年開始，另外，爲何有兩個1年可選（譯者注：年份那列從上往下應該顯示爲「一、二、3」）？

另外一個Bug，是「當前體重」部分的一個拼寫錯誤，當清空數據時會出現拼寫錯誤的「Enter「（應用中用的是Etner），這只是一個小Bug，可是看上去很是不專業。

發現問題沒有捷徑，你只能反覆的慢慢的試用。每一個App及其團隊都會面臨不少不一樣的挑戰。可是，測試人員的典型的特色就是：超越極限，作一些很是規 的、能夠改變周圍事物的事情，保持長時間的測試（測試幾天、幾個星期甚至幾月，而不是幾分鐘就測完），即便明明知道這些事情是不可能發生的。這些也正是可 以找到和引出的場景所在。

 

哪兒有全部的數據？

測試人員喜歡從數據上找問題，這讓開發人員有時候很鬱悶。事實上，用戶或者是軟件開發人員在信息流中確實太容易迷惑了，由於可能會出現不少錯誤，因此基於數據和雲的服務更爲重要

也許你能夠嘗試在如下場景中檢查出問題：

·　 移動設備數據已滿；

·　測試人員移除了全部的數據；

·　測試人員刪除了App，那數據怎麼辦？

·　 測試人員刪除並重裝了App，數據怎麼辦？

·　 過多或者過少的內容致使設計和佈局的改變；

·　在不一樣的時間段和時區使用；

·　 數據不一樣步；

·　同步被中斷；

·　數據更新影響其餘的服務（好比網頁和雲端服務）；

·　快速處理數據或是處理大量的數據；

·　使用無效的數據；

 

案例：Soup.me的錯誤

我試用過的Soup.me， 是一個能夠經過地圖和顏色將我的Instagram 中的照片進行分類的網頁服務，可是我卻沒用多久。當註冊時，它提 示我Instagram上的照片不夠多，然而個人帳號中明明有500多張照片。我並不清楚問題出在哪兒，也許是數據問題，也許是表現層的問題，也有多是 該App出錯提示的問題。

 

另外一個案例：Quicklytics

Quickytics是一個iPad上的網頁分析應用。在使用過程當中，儘管我已經從Google Analytics中刪除了網站配置，但它仍然存在。這裏有一些問題：

·　我已經刪除了網站配置，爲何仍是有這些信息？

·　左邊模塊沒有解釋爲何「該操做沒法完成」，那麼是否是能夠改進以免迷惑用戶呢？

 

測試人員也很喜歡測試極限數據下的狀況。他們經常是做爲典型用戶來了解這個App，因此極限下的測試並不會花很長的時間。數據是混亂的，因此測試人員要考慮到軟件的用戶類型，以及在不一樣的數據場景下如何進行測試。

好比，他們可能嘗試如下場景：

·　測試用戶可輸入的極限值；

·　用重複的數據進行測試；

·　在全新無數據的手機裏測試；

·　在老手機上測試；

·　預先安裝不一樣類型的數據；

·　考慮彙集你們的資源來進行測試；

·　讓一些測試自動化；

·　用一些超出預期的數據去測試，看它是怎麼處理的；

·　分析信息和數據是怎麼影響用戶體驗的；

·　無論用戶看到的是否正確，都要一直問問題。

 

 

建立出錯提醒和消息

這裏，我不是從設計師的角度來要談論好的錯誤消息的設計，而是想從用戶或是測試者的角度來看這個問題。出錯提醒和消息是測試人員很容易發現問題的地方。

關於錯誤信息要問的問題:

請考慮如下問題：

·　出錯提醒的UI設計能夠接受嗎？

·　錯誤信息內容能夠理解嗎？

·　錯誤信息是否保持一致？

·　這些錯誤信息有幫助嗎？

·　錯誤信息內容是否合適？

·　這些錯誤是否符合慣例和標準？

·　這些錯誤信息自己是否安全？

·　運行記錄和崩潰是否能被用戶和開發者得到？

·　是否全部的錯誤都被測試過？

·　用戶處理完錯誤信息後，將處於什麼狀態

·　是否在用戶應該接受錯誤信息時，卻沒有錯誤信息彈出？

錯誤信息會影響用戶體驗。然而，很差或無用的出錯提醒無處不在。雖最理想的狀態是避免用戶遭遇錯誤信息，但這幾乎不可能。出錯狀況的設計、實現和確承認能與預期相反，可是，測試者每每善於發現意料外的Bug，並能仔細考究是否改進它們。

錯誤信息的案例

我很是喜歡舉iPhone上Facebook App這個例子。這些冗長又晦澀的文字不只僅試圖涵蓋了許多不一樣的場景，並且還可能無故地丟失。

 

可能以下的消息提示框能夠列入反例「名人堂」了？

 

看看這款iPad上的The Guardian應用，若是我不想「重試」，該怎麼辦呢？

 

特定平臺上的注意事項

對於任何項目團隊成員來講，瞭解相關平臺的業務、技術和設計上的限制，都是相當重要的。

那麼，移動端App的測試人員應該找出哪些平臺相關的問題呢？

·　是否遵守了這個特定平臺的設計規範？

·　與競爭對手以及行業內的設計相好比何？

·　是否適應外圍設備？

·　觸摸屏支持手勢嗎，如：輕拍、雙擊、長按、拖動、搖動、夾捏、輕拂、滑動？

·　這個App能夠被理解嗎？

·　當轉動設備的方向時，有什麼變化？

·　可使用地圖和GPS嗎？

·　有用戶指南嗎？

·　電子郵件的工做流程友好嗎？

·　經過網絡分享時，它運行得流暢嗎？是否整合了其餘社交應用或網站？

·　當用戶正在進行多任務工做，並在不一樣App間切換的時候，它還運行正常嗎？

·　當用戶更新它時，它是否會顯示時間進度？

·　默認設置如何?有通過調整嗎？

·　使用音效會有不一樣嗎？

 

案例：ChimpStats

ChimpStats是iPad上一個查看郵件廣告詳情的應用。我第一次使用這個應用是處於橫屏模式。當我須要輸入API密碼的時候，我被困住了。我根本不能在水平模式中輸入API密碼，直到切換成豎屏模式，才輸入成功。

 

 

鏈接和中斷的問題當鏈接斷斷續續或是意外中斷時，不少有趣的事情就可能發生了。

你是否嘗試過在如下場景中使用App：

·　走動環境下？

·　Wi-Fi鏈接下？

·　沒有Wi-Fi的狀況下？

·　3G模式下？

·　間歇性地鏈接？

·　設置爲飛行模式？

·　一個電話打進來時？

·　接收到一條信息時？

·　接收到一個提醒通知時？

·　在電量很低甚至自動關機時？

·　被強制更新時？

·　收到一條語音留言時？

這類測試最容易發現錯誤和Bug。我強烈建議你在這些狀況下進行測試（不只僅只是開機、確認它能夠正常工做，還要嘗試用戶使用的整個流程，並在特定的時間間歇內強制鏈接和中斷）。

·　這個App提供了足夠多的反饋嗎？

·　數據傳輸爲用戶所知嗎？

·　它會慢慢中止，而後崩潰嗎？

·　開啓時會發生什麼？

·　任務完成中會發生什麼？

·　是否可能丟失未保存的操做？

·　你能夠忽視通知提醒嗎？忽視後會發生什麼？

·　你能夠對通知提醒作出響應嗎？響應後會發生什麼？

·　對某些問題，使用錯誤信息是否恰當？

·　當登陸過時或超時會發生什麼？

 

App的維護

想要加快整個測試的過程很簡單，只需測試一次就一勞永逸了，對嗎？請三思。

此刻我遇到的一個問題是： iPad上的一些App在更新後，不再能下載了。對於一個用戶來講，這是很是使人沮喪的。

可能，這也是開發者控制不了的。誰知道呢？我只知道它對於用戶來說是不能用的。我也嘗試卸載App，而後重裝，但這個問題始終未能解決。我在網上大量的搜索，除了找到一些關於更新操做系統的建議外，沒有任何其餘解決方式。可能，下次有空時候，我還會再試試看。

關鍵問題在於：若是一個應用只被測試過一次，且只有一次（或僅在很短的一段時間內測試過），不少問題你都發現不了。一個App自身可能不會發現變化，但外界條件卻可讓這些問題發生。

當外界環境持續變化時，App又會受到哪些影響呢？讓咱們問問本身：

·　我能夠下載這個App嗎？

·　我能夠下載並安裝更新嗎？

·　更新以後還能使用嗎？

·　當不少App處於等待更新狀態時，我能更新它嗎？

·　系統更新後，它會發生什麼？

·　系統未更新，它又會發生什麼？

·　它會經過iTunes自動同步下載到其餘設備嗎？

·　它自動執行任務或測試有意義嗎？

·　它會鏈接到網絡服務嗎？這會帶來什麼不一樣？

 

移動端的App每個版本發佈後，最好都去測試一下。每次發佈新版本時，先定義最高優先級測試，確保其能在各類條件下進行（主要是在主流的平臺上）。隨着時間的推移，測試能夠變得自動化。但請記住，自動化不是靈丹妙藥，發現問題，只能經過人的眼睛。

 

案例：iPhone上的Analytics應用

我使用這個App已經兩年了，以前它一直沒有什麼問題。可是如今，它卻顯示出我某些網站數據爲零（但實際上，不止一我的一個月內訪問過個人網站！）。從App Store的評論來看，我不是惟一一個遇到這個問題的人。

另一個案例是iPhone上的Twitter。更新並啓動這個App後，我瞬間看到了以下這個提示語：「你的時間線數據顯示爲空，你至今沒有關注任何人」 (但我是擁有5年經驗的活躍用戶)。我擔憂了一下子，慶幸的是，這個消息很快就消失，而後加載出歷史數據。

 

測試不是對錯判斷

咱們討論了移動測試的一些方面，但這些前提是：帶着問題，才能發現問題。

一般，測試被認爲是徹底合乎邏輯的、可計劃的和可預測的，過程包括：測試腳本和測試計劃、經過和失敗、正確和錯誤的反饋。走完這些測試流程就離真相不遠了。

固然，若是必要，咱們能夠用上述方法進行測試，但這並非測試的目的。咱們不只是爲了建立測試用例、發現Bug，更重要的是找到關鍵的問題，爲項目組決定何時發佈App提供有價值的信息。而找到那些關鍵問題的最好方法就是：提問！