移動APP測試實用指南

看到一篇app測試的文章，感覺很好，特意将重點記了下來   原文位址http://www.uisdc.com/app-test-guideline

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

作者将帶你經曆測試人員的思維過程，探讨他們測試移動App時的各種考慮。本文的目的在于揭示測試人員的這一思維過程，并展示他們通常所考慮内容的廣度和深度。

測試人員需要詢問問題

測試人員的核心能力在于提出有挑戰性的相關問題。如果你能将調查、詢問技巧和技術、産品的知識結合起來，漸漸地，你也會成為一個好的測試人員。

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

• 這個App應該在什麼平台上使用？
• 這個App到底是幹什麼的？
• 如果我這樣做，會發生什麼情況？

諸如此類。

測試人員能從各種場景中發現問題，它們可能來自對話、設計、文檔、使用者回報或者是産品本身。這些可能性太多了……是以，讓我們一探究竟吧！

從哪裡開始測試

理想情況下，測試人員應該掌握所測産品的所有最新細節資料。但事實上這很少見，是以，像其他人一樣，測試人員隻能将就使用手上有限的資料。但這不是不能測試的借口！測試人員其實是可以從内部和外部多種不同的來源處收集資訊的。

這個階段，測試人員可以問這些問題：

• 有哪些資訊：規格？項目會議？使用者文檔？知識淵博的團隊成員？有支援論壇或者是公司線上論壇提供幫助？有現存Bug的記錄嗎？
• 該應用是在什麼系統、平台和裝置上進行運作和測試？
• 該應用是處理什麼類型的資料（比如個人資訊、信用卡等等）？
• 該應用有整合外部應用（比如API和資料來源）嗎？
• 該應用需要用到特定的移動端網頁嗎？
• 現有消費者如何評價這個産品？
• 有多少時間可用于測試？
• 測試的優先級和風險是什麼？
• 哪些使用者使用起來不愉快，為什麼？
• 如何釋出和更新？

基于以上收集的資訊，測試人員可以制定測試計劃了。通常預算決定測試方法，一天測完，一個星期或一個月測完的方法肯定不同。當你逐漸熟悉團隊、工作流程以及這類問題的解決方式時，你就更容易預測結果了。

測試人員的創造力

你可能知道這個App原本想做的事，但是它究竟可以做什麼事呢？使用者實際上是如何使用它的？測試人員擅長作為旁觀者來思考，嘗試不同的事物，以及不斷地詢問“如果。。。會怎麼樣”和“為什麼”的問題。

比如，移動端的測試人員常常以不同的使用者角色進行測試——當然有點誇張，但是，這種把自己當成不同使用者進行思考、分析和設想的能力對測試是備受啟發的。

測試人員可能會設想自己是以下使用者：

• 毫無經驗；
• 很有經驗；
• 愛好者；
• 黑客；
• 競争對手；

當然還有更多可選的角色，這主要取決于你們所開發的産品是什麼。其實除了角色特點外，其操作行為和工作流程也很重要。人們使用産品方式常常很奇怪，比如：

• 在不應該傳回的時候傳回了；
• 不耐心而且多次敲按鍵；
• 輸入錯誤的資料；
• 不了解該怎麼做；
• 可能沒有按要求進行設定；
• 可能會自以為是地認為自己知道該做什麼（比如通常不閱讀說明）。

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

很多問題是可以被預先确定和測試的。測試移動端App時，以下的問題并不都有關，但是也可以嘗試問問：

• 是否按照所說的來做呢？
• 是按設計完成任務的嗎？
• 不是按設計完成任務的嗎？
• 如果處于一直被使用或者負荷情況下，狀況會怎麼樣？會反應遲鈍嗎？會崩潰嗎？會更新嗎？有回報嗎？
• 崩潰報告會回報到App嗎？
• 使用者可能有哪些創造性的、邏輯性的或是消極的導航方式？使用者相信你的品牌嗎？
• 使用者的資料安全如何？
• 有可能被中斷或是被破解嗎？
• 運作到極限時會發生什麼狀況？
• 會要求打開相關服務嗎(如GPS、Wi-Fi)？如果使用者打開會怎樣？沒打開又會怎樣？
• 将使用者重新引向哪兒？去網頁？還是從網頁到App？這會導緻問題出現嗎？
• 溝通過程和市場回報是否符合該App的功能、設計和内容？
• 登入流程是怎樣的？能在App上直接登入還是要去網頁端？
• 登入是否整合了其他服務，比如用Facebook和Twitter帳号登入？

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

哪兒有所有的資料？

測試人員喜歡從資料上找問題，這讓開發人員有時候很郁悶。事實上，使用者或者是軟體開發人員在資訊流中确實太容易迷惑了，因為可能會出現很多錯誤，是以基于資料和雲的服務更為重要。

也許你可以嘗試在以下場景中檢查出問題：

• 移動裝置資料已滿；
• 測試人員移除了所有的資料；
• 測試人員删除了App，那資料怎麼辦？
• 測試人員删除并重裝了App，資料怎麼辦？
• 過多或者過少的内容導緻設計和布局的改變；
• 在不同的時間段和時區使用；
• 資料不同步；
• 同步被中斷；
• 資料更新影響其他的服務（比如網頁和雲端服務）；
• 快速處理資料或是處理大量的資料；
• 使用無效的資料；

測試人員也很喜歡測試極限資料下的情況。他們常常是作為典型使用者來了解這個App，是以極限下的測試并不會花很長的時間。資料是混亂的，是以測試人員要考慮到軟體的使用者類型，以及在不同的資料場景下如何進行測試。

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

• 測試使用者可輸入的極限值；
• 用重複的資料進行測試；
• 在全新無資料的手機裡測試；
• 在老手機上測試；
• 預先安裝不同類型的資料；
• 考慮聚集大家的資源來進行測試；
• 讓一些測試自動化；
• 用一些超出預期的資料去測試，看它是怎麼處理的；
• 分析資訊和資料是怎麼影響使用者體驗的；
• 不管使用者看到的是否正确，都要一直問問題。

建立出錯提醒和消息

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

關于錯誤資訊要問的問題：

• 請考慮以下問題：
• 出錯提醒的UI設計可以接受嗎？
• 錯誤資訊内容可以了解嗎？
• 錯誤資訊是否保持一緻？
• 這些錯誤資訊有幫助嗎？
• 錯誤資訊内容是否合适？
• 這些錯誤是否符合慣例和标準？
• 這些錯誤資訊本身是否安全？
• 運作記錄和崩潰是否能被使用者和開發者獲得？
• 是否所有的錯誤都被測試過？
• 使用者處理完錯誤資訊後，将處于什麼狀态
• 是否在使用者應該接受錯誤資訊時，卻沒有錯誤資訊彈出？

錯誤資訊會影響使用者體驗。然而，不好或無用的出錯提醒無處不在。雖最理想的狀态是避免使用者遭遇錯誤資訊，但這幾乎不可能。出錯情況的設計、實作和确認可能與預期相反，但是，測試者往往善于發現意料外的Bug，并能仔細考究是否改進它們。

特定平台上的注意事項

對于任何項目團隊成員來說，了解相關平台的業務、技術和設計上的限制，都是至關重要的。

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

• 是否遵照了這個特定平台的設計規範？
• 與競争對手以及行業内的設計相比如何？
• 是否适應外圍裝置？
• 觸摸屏支援手勢嗎，如：輕拍、輕按兩下、長按、拖動、搖動、夾捏、輕拂、滑動？
• 這個App可以被了解嗎？
• 當轉動裝置的方向時，有什麼變化？
• 可以使用地圖和GPS嗎？
• 有使用者指南嗎？
• 電子郵件的工作流程友好嗎？
• 通過網絡分享時，它運作得流暢嗎？是否整合了其他社交應用或網站？
• 當使用者正在進行多任務工作，并在不同App間切換的時候，它還運作正常嗎？
• 當使用者更新它時，它是否會顯示時間進度？
• 預設設定如何?有經過調整嗎？
• 使用音效會有不同嗎？

連接配接和中斷的問題當連接配接斷斷續續或是意外中斷時，很多有趣的事情就可能發生了。

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

• 走動環境下？
• Wi-Fi連接配接下？
• 沒有Wi-Fi的情況下？
• 3G模式下？
• 間歇性地連接配接？
• 設定為飛行模式？
• 一個電話打進來時？
• 接收到一條資訊時？
• 接收到一個提醒通知時？
• 在電量很低甚至自動關機時？
• 被強制更新時？
• 收到一條語音留言時？

這類測試最容易發現錯誤和Bug。我強烈建議你在這些情況下進行測試（不僅僅隻是開機、确認它可以正常工作，還要嘗試使用者使用的整個流程，并在特定的時間間歇内強制連接配接和中斷）。

• 這個App提供了足夠多的回報嗎？
• 資料傳輸為使用者所知嗎？
• 它會慢慢停止，然後崩潰嗎？
• 開啟時會發生什麼？
• 任務完成中會發生什麼？
• 是否可能丢失未儲存的操作？
• 你可以忽視通知提醒嗎？忽視後會發生什麼？
• 你可以對通知提醒做出響應嗎？響應後會發生什麼？
• 對某些問題，使用錯誤資訊是否恰當？
• 當登入過期或逾時會發生什麼？

App的維護

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

此刻我遇到的一個問題是：iPad上的一些App在更新後，再也不能下載下傳了。對于一個使用者來說，這是非常令人沮喪的。

可能，這也是開發者控制不了的。誰知道呢？我隻知道它對于使用者來講是不能用的。我也嘗試解除安裝App，然後重裝，但這個問題始終未能解決。我在網上大量的搜尋，除了找到一些關于更新作業系統的建議外，沒有任何其他解決方式。可能，下次有空時候，我還會再試試看。

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

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

• 我可以下載下傳這個App嗎？
• 我可以下載下傳并安裝更新嗎？
• 更新之後還能使用嗎？
• 當很多App處于等待更新狀态時，我能更新它嗎？
• 系統更新後，它會發生什麼？
• 系統未更新，它又會發生什麼？
• 它會通過iTunes自動同步下載下傳到其他裝置嗎？
• 它自動執行任務或測試有意義嗎？
• 它會連接配接到網絡服務嗎？這會帶來什麼不同？

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

測試不是對錯判斷

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

通常，測試被認為是完全合乎邏輯的、可計劃的和可預測的，過程包括：測試腳本和測試計劃、通過和失敗、正确和錯誤的回報。走完這些測試流程就離真相不遠了。

當然，如果必要，我們可以用上述方法進行測試，但這并不是測試的目的。我們不僅是為了建立測試用例、發現Bug，更重要的是找到關鍵的問題，為項目組決定什麼時候釋出App提供有價值的資訊。而找到那些關鍵問題的最好方法就是：提問！