最近在工作中做了不少的可用性測試，抽空閑的時間總結一下自己的心得，以下是我們團隊展開可用性測試的步驟與方法。

列舉任務清單并排序

這是可用性測試的第一步，你需要根據產品的功能列舉出需要進行測試的任務，列舉完后再回頭與功能進行對比，看列舉出來的任務是否覆蓋了需要測試的所有功能。以短信舉例，列舉 的任務如下：

1. 發一條短信
2. 查看一條短信并找到短信的詳細信息
3. 刪除一條短信

接下來對列舉的測試任務進行排序，測試任務的順序要盡量符合典型用戶的典型行為習慣，還是以短信舉例，人們對短信的一般操作流程是，打開短信—查看短信—刪除短信。測試任務的順序也需要按照這樣的行為習慣來。

設計測試任務

設計測試任務是整個可用性測試過程中最重要的一步，任務描述的合理性會直接影響到測試結果的真實性，那么到底怎么來設計測試任務呢？下面以短信來舉例的測試任務描述：

1.發一條短信

描述：今天是你媽媽的生日，你現在想給她發一條短信表達你的祝福之情。

2.查看一條短信并找到短信的詳細信息

描述：你媽媽昨天給你發了一條短息但是你沒有看到，現在你想要找到那條短信并看看是什么時候給你發的。

3.刪除一條短信：

描述：收件箱短信太多了，導致你手機內存滿了，你需要刪除一部分垃圾短信。

設計任務時需要注意的幾點：

1. 弄清楚用戶的需求以及產生該需求的場景：設計測試任務時必須先弄清楚用戶的需求以及需求的場景，這樣你設計出來的任務才能將被測試的用戶帶入實際的場景中去。比如說一個客戶經常到偏遠的地方出差，這些地方的網絡條件很差，幾乎無法訪問你的產品，于是你為該用戶提供了一個離線訪問的功能?？蛻舻男枨缶褪悄茉诰W絡較差的情況下訪問產品，而產生該需求的場景就是客戶經常到偏遠的地方出差。
2. 根據需求場景來描述測試任務：描述任務的時候需要根據實際場景和需求來給任務加一些劇情，劇情不要太復雜和啰嗦，這樣會增加測試者的理解和記憶負擔。
3. 設計測試任務時盡量避免基于功能的任務描述：還是拿短信來舉例，如果你這樣描述“請你用這個工具發一條短信”，這樣的描述看起來并沒有什么不合理的地方，但實際上它把測試的重點指向了發短信這個功能上了，它不包含實際場景，不能反映出用戶的實際需求與目標。必須記住，任何需求都是產生在某些具體的場景中，在設計任務時你必須反復拿這個任務來問自己，“這個任務是否反映出了實際用戶的目標與需求呢”。
4. 在任務中不要包含任何會引導用戶操作的線索：產品中的術語，操作行為等等都會給用戶提供任務線索?！澳銒寢尳裉焐樟?，你現在打開短信創建一條新信息發送給你媽咪，祝你媽咪生日快樂”，“打開短信創建一條新信息”就成為了明顯的任務線索。
5. 將你認為用戶可能出錯的任務做一個特殊標記：為什么要這樣做，因為有時候用戶完成一項你認為比較難以理解的任務可能是由于巧合，這項任務雖然做對了，但是他的理解可能與你設計的本意相差甚遠，這個時候你必須追問他為什么會這樣做，他是怎么理解的。

總結

設計測試任務時必須要抓住“人”、“情景”、“目標”這三個要素，這三個要素一定要在你的測試任務中體現出來，最終的描述形式就是“誰在在什么情況下要做什么”。

尋找合適的受試用戶

在設計好測試任務后，現在就該去找參與測試的用戶了，眾多研究表明（當然我還沒有研究過.5個測試用戶就能發現80%的可用性問題，我們公司在做測試時一般都是12個，原因是因為我們需要把這些定性的數據量化成數字，這樣有助于幫助我們判定什么問題比較嚴重，什么問題必須得改。這樣也能有效地避免團隊間意見分歧的問題。如果說沒有量化的需求，建議5個就夠了。

什么是合適的受試用戶：如果是新產品就得根據用研時創建的persona去尋找合適的用戶了（我還沒做過一個完整新產品的測試，這里就不多講了.。對于已經有用戶量的產品來講，測試者應該由真實用戶和對產品陌生的目標或者非目標用戶來組成。為什么會有對產品陌生的用戶以及非目標用戶呢？

其一，在大環境下，人的行為存在著驚人的一致性，如果說你的設計存在嚴重問題那么誰都能測出來。

其二，對產品熟悉的用戶已經掌握了產品的某些行為，他們的行為習慣完全不同于新手用戶，在測試這些人時他們可以憑借自己使用該產品的經驗克服一些可用性問題，所以說某些問題測試他們是測試不出來的，不熟悉產品的目標用戶或者非目標用戶就能彌補這一塊的問題。當然，如果你測試的任務必須要該產品的專業用戶才能理解的話就必須找實際用戶了。

展開可用性測試

1.資源配置

如果資源足夠，測試過程中一個人扮演主持者，一個人扮演記錄者，如果資源不夠，這兩個角色由一個人來扮演也是可以的。測試的過程必須得錄屏和錄音，在條件允許的情況下還可以對測試過程進行錄像，以便后面對用戶的行為進行分鏡式分析。當然，還有更加專業的測試工具，比如說眼動儀，還有一些可以記錄用戶行為并將其轉換成熱力圖的軟件。這些工具和軟件中小型公司一般都不會配置。

2.調節測試氛圍

大部分的測試者在參加測試時都是緊張的，他們會擔心自己無法完成測試任務等等。比如說前幾天進行了一個測試，在把測試者請來時他就一直在不停的說“哎呀，找我測試呀，我做不來怎么辦呀，我很笨的”。所以說，展開測試的第一步是緩和測試的氛圍，消除被測試者的緊張情緒，你需要向他表明本次測試的目的。

3.開始測試

這個過程中需要做到“一看”、“二記”、“三問”、“四聽”

看與記：整個過程中需要認真觀察用戶的操作過程，對用戶有疑問、遲疑、困惑的地方進行記錄。

問與聽：用戶完成一項測試任務后，需要問他在這個任務的過程中有沒有碰到難以理解的地方，如果有，需要追問用戶為什么難以理解，他最后是怎么理解的。如果你觀察到用戶在某個地方產生了遲疑 ，需要問用戶為什么會產生遲疑，比如說，“我剛剛看到你在點擊發送短信時猶豫了很久，你為什么會在這里猶豫呢”。在這個過程中你需要認真傾聽用戶的意見，并肯定用戶的提議，這樣會讓他得到一種成就感，有利于接下來的測試。

測試過程中需要注意的問題：

測試過程中用戶如果有什么想要表達的，邀請他表達出來，如果他太善于表達，需要進行適當的制止，讓他回到測試任務上來。

識別用戶情緒，在用戶實在無法完成任務時，終止該任務的測試

不要以任何方式（手勢、表情、語言等.表現出用戶正在犯錯或者操作太慢，需要明白這不是他的錯，是你設計的問題。

用戶遇到困難時盡量不要提供幫助，可以適當鼓勵用戶，比如“你可以在嘗試一下”。

多問用戶幾個為什么，比如“為什么你剛剛會這樣操作”、“為什么你會這樣理解呢”等等

測試結果統計整理（填入指標表.）

測試過程完成后，這個階段就是統計測試結果了，如何統計測試結果呢？不同的團隊會有不同的統計方式，這得根據自己團隊所制定的可用性測試規范來，我們團隊是這樣統計的（如下圖）

分為5個指標進行統計：

• “完成情況”
• “流暢度”
• “具體問題”
• “問題嚴重程度”
• “用戶預期”

其中最重要的就是具體的問題了，統計時不要只記錄一個干癟癟的問題，用戶遇到問題的具體場景一定要記錄下來，這有利于你去分析用戶究竟為什么會產生這樣的問題，對問題的改進有很大的幫助。

另外，統計時需要注意一下幾點：

1. 不要靠自己的回憶去統計，一定要回頭去看測試時錄制的視頻
2. 對用戶行為有疑問的地方及時回訪，把問題弄明白。
3. 有些問題是你通過觀察用戶行為發現的，但它似乎不能被計入指標中的話，這時需要另外記錄這些問題，在團隊討論的時候提出來（如下圖）：

確定需要修改的問題

在將指標統計完后，接下來就是確定什么問題需要修改了。

統計問題產生的概率（如下圖）：

將所有的問題列在一個excel表格中，誰出現了這樣的問題就在誰下面打勾，然后計算出問題出現的概率，如果有及時的方案，在備注列添加一下。

確認什么問題需要修改（如下圖）：

上圖是一套判定問題嚴重性的規范，這個有助于去判定什么問題需要修改以及什么問題可以暫時不用修改。當然這并不能作為唯一的標準，因為它只是一個數據性的參考，實際過程中還需要進行定性的分析，比如說有的問題只有一個用戶出現了，但是經過分析這的確是個問題；有的問題大部分的用戶都出現了，但是這些問題只是出現在了用戶第一次使用的過程中，后面就沒有出現過了，改動起來的成本較高，這種問題我們稱為可接受的學習成本問題。

修改問題并準備下一次的測試

這個過程就沒多少可說的了，修改確定后的問題，然后準備下一次的測試，直到產品方案滿意為止。

本文由 @不知名屌絲設計師 原創發布于人人都是產品經理?，未經許可，禁止轉載。