移動端App測試實用指南

譯者注：本文從測試人員的角度出發，提出了100多個在測試移動App過程中需要考慮的問題。 不管你是測試人員、開發、產品經理或是交互設計師，在進行移動App開發時，這些問題都很有參考價值。 我和Queen合力譯出此文，分享給大家，希望有所説明和啟發。

英文原文: 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年可選（譯者注：年份那列從上往下應該顯示為「1、2、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提供有價值的資訊。 而找到那些關鍵問題的最好方法就是：提問！

瞭解「CDC翻客」，請移步：【CDC翻客 】翻客來襲！ Fanke is coming！ (連結：HTTP://cdc.tencent.com/?p=6518)

(本文出自Tencent CDC Blog，轉載時請注明出處)