常用可用性測試方法（二）

達令LL

北京/設計愛好者/6年前/247瀏覽

版權

常用可用性測試方法（二）

達令LL

文章列舉了常用的9中可以性測試方法、適用階段、注意事項、優(yōu)缺點，可以幫助同學們開啟用研的第一步。參考資料見第三章文末。

4、遠程測試

4.1 方法說明

在遠程測試中，用戶在自己的環(huán)境中執(zhí)行一系列任務，通過軟件記錄完成任務的過程，軟件自動記錄用戶的點擊位置和交互過程，并記錄他們在使用網站或應用程序時發(fā)生的關鍵事件以及用戶提交的反饋。這種類型的測試可以由主持人（使用網絡研討會或電話會議技術）完成，也可以作為自我測試。

在遠程可用性測試當中，還會分為同步和異步兩種。

所謂同步，是通過視頻會議和共享工具（諸如WebEx 和 GoToMeeting）來同步進行遠程可用性測試。同步的可用性測試讓設計者可以實時觀察不同的人是如何使用產品的。另外，如果需要，參與測試的用戶是可以從相關人員那里獲得一定的支持。

異步的遠程可用性測試則相對好處理得多。設計人員會給這些用戶設定一些特定的任務，然后會自動搜集產品交互中所有的用戶數據，包括點擊的位置和用戶使用過程中所出現的錯誤。此外，設計師可能還會要求參與測試的用戶在完成之后對于自己的體驗進行總結，給予反饋。

4.2 適用階段

原型設計階段

4.3 執(zhí)行規(guī)則/注意事項

“遠程”意味著用戶和測試者在不同空間，這就對用戶提出了較高要求，也增加了測試的風險。測試過程中，任何一點挫敗感都可能使任務前功盡棄。

而我們需要做的，就是盡量降低用戶挫敗感，讓測試更順利地進行。

4.3.1 同步測試：挑選連接穩(wěn)定的鏡像工具

如前所述，同步遠程可用性測試中，測試者和用戶是同步進行的。

一般來說，測試者會要求用戶通過鏡像工具，將手機屏幕鏡像到測試者的電腦，類似于遠程投屏。這樣，測試者便能在電腦面前觀看任何一位用戶的手機屏幕及其操作，用戶在哪些地方有所遲疑，對哪個頁面的設計不理解，都能明顯被觀察到。

因此，在同步測試中，主要需要注意的點都集中在鏡像工具的選擇上。

（1）鏡像工具必須支持遠程測試

現在市面上的鏡像工具是很多的，只要一條數據線，就能把手機屏幕投到電腦上觀看。這很方便，但數據線連接并不支持遠程，所謂遠程，就是要在測試者和用戶見不到面的時候，還能讓用戶把他的屏幕連接投射到測試者的電腦上，一般來說，這種遠程投屏工具有兩種：

通過同一賬號密碼登錄進行遠程投屏，如向日葵遠程控制APP。
通過輸入用戶ID進行遠程投屏，如TeamViewer。

（2）鏡像工具必須簡單易用

在遠程測試中，應盡量避免讓用戶產生過多的挫敗感，鏡像工具的使用是其中之一，如果連接失敗或連接不穩(wěn)定，則會極大影響用戶的操作和測試情緒。因此，在選擇鏡像工具時，應進行多次測試。我一般會根據這幾個標準來選擇：

容易連接操作流程簡單，基本上按照“選擇投屏→確定被投屏”的邏輯，在2-3步內就可以操作完成，操作步驟越多，用戶可能產生挫敗感的可能性就越大。
連接速度快按照說明操作后，鏡像連接應在5-10秒內成功建立，等待時間過長或連接失敗頻率高的工具都不適合。
連接穩(wěn)定 建立連接后，用戶就應該要開始測試了，遠程可用性測試一般在15-30分鐘，這個過程中，連接一旦中斷，就可能擾亂用戶的操作過程，影響測試結果，因此，應選擇多次試驗中中斷率最小的鏡像工具。

4.3.2 異步測試：任務輕量化，讓用戶輕松錄屏

顧名思義，異步遠程就是測試者和用戶是不同步的，用戶在進行可用性測試時，需要記錄自己的操作，以便之后提供給測試者進行分析。

整個過程不會有人在旁進行引導和鼓勵，用戶相當于在獨立完成任務，耐心會比現場測試和同步遠程測試要低得多，所以，應更加注意將用戶的挫敗感減到最低。

（1） 明確遠程任務，使用用戶的語言，避免籠統(tǒng)表達

在前期腳本設計中，應對任務進行明確的目標細化，使用用戶的語言，以保證他們正確理解任務。

如“請你體驗產品的下載功能”就不及“請你下載一部2017年的西班牙懸疑電影”來得清晰。

（2）盡量使任務輕量化

試想一下，讓你一個人在家里做可用性測試，你能忍耐多長時間的任務？

一般來說，異步遠程測試的任務最好設置在15-30分鐘內，以包含3-5個任務為宜，為免用戶失去耐心而放棄。

（3）選擇簡單易用的錄屏工具

與同步測試工具不同，異步測試中，用戶和測試者處在不同時空，用戶需要自行錄下任務過程，因此，主要使用的是錄屏工具。

既然是工具，首要考慮便是“簡單易用”。不僅要界面設計清晰，讓人容易理解（最好有新手引導），還要在交互上做得人性化，讓人一下子就懂得怎么用，且用得溜。

推薦的錄屏工具：DU Recorder，人性化，頁面承載內容雖多，但勝在新手指引明確，上手簡易度高。

（4）考慮用戶的手機內存

要知道，一段不到5分鐘的錄屏視頻，大小就可能超過30M，如果一個可用性測試超過了20分鐘，就要占用120M，如果用戶操作相對緩慢，視頻大小可能達到200M以上。這不僅會給用戶的手機內存增加負擔，也提高了視頻傳輸的流量和時間成本，甚至增加傳輸失敗的風險。

而這還不包含錄屏工具本身的大小。

因此，在挑選工具時，一是要考慮工具本身的安裝包大小。小鹿測試過20余款錄屏工具，安裝包在10M左右且功能齊全、簡單易用的工具是不難找到的，前面提到的DU Recorder和大名鼎鼎的Mobizen皆為其中佼佼者。

另外，要注意錄屏工具的功能選擇，是否允許用戶通過調低視頻質量來減小錄屏視頻的大小。一般來說，只要能看清手機屏幕上的文字即可，不需要求高度清晰，以免給用戶帶來內存負擔。

4.4 優(yōu)缺點

優(yōu)點：與實驗室測試相比,它通?？梢怨?jié)省時間和金錢,并且參與者不需要呆在實驗室中,它可以涉及更廣泛的參與者。

它在某些方面更接近于現場測試,因為測試是在用戶的環(huán)境中進行的,而不是人工實驗室環(huán)境。這在許多情況下比實驗室環(huán)境提供更好的結果。

缺點：遠程同步測試方法，不好安排和集中；需要硬件支持，如：視頻工具和共享設備，數據采集設備。

5、A / B測試

5.1 方法說明

為網站或應用程序的界面或流程制作兩個（A/B）或多個（A/B/n）版本，在同一時間維度，分別讓組成成分相同（相似）的訪客群組隨機的訪問這些版本，收集各群組的用戶體驗數據和業(yè)務數據，最后分析評估出最好版本正式采用。

5.2 適用階段

原型設計階段、產品上線后

5.3 執(zhí)行規(guī)則/注意事項

5.3.1 AB測試的基本步驟

AB測試是一個反復迭代優(yōu)化的過程，它的基本步驟如下圖所示可以劃分為：

1.設定項目目標即AB測試的目標

2.設計優(yōu)化的迭代開發(fā)方案，完成新模塊的開發(fā)

3.確定實施的版本以及每個線上測試版本的分流比例

4.按照分流比例開放線上流量進行測試

5.收集實驗數據進行有效性和效果判斷

6.根據試驗結果確定發(fā)布新版本、調整分流比例繼續(xù)測試或者在試驗效果未達成的情況下繼續(xù)優(yōu)化迭代方案重新開發(fā)上線試驗

從對AB測試的定義中可以看出AB測試強調的是同一時間維度對相似屬性分組用戶的測試，時間的統(tǒng)一性有效的規(guī)避了因為時間、季節(jié)等因素帶來的影響，而屬性的相似性則使得地域、性別、年齡等等其他因素對效果統(tǒng)計的影響降至最低。

如何提供對用戶的有效分組以及如何判斷實驗中不同分組用戶屬性的相似性是AB測試需要解決的第一個問題。而在試驗過程中如何收集用戶的體驗和業(yè)務數據，如何對收集的數據進行分析并判斷不同版本間的優(yōu)劣是AB測試需要解決的第二個問題，也是AB測試的目的所在。下面我們對AB測試中這兩個關鍵的問題進一步展開。

5.3.2 AB測試的設計

AB測試中分流的設計直接決定了測試結果是否有效。AB測試是對線上生產環(huán)境的測試，而之所以進行AB測試通常是對測試中的改進版本所產生效果的好壞不能十分確定，所以測試版本的流量通常不宜過大。尤其對于那些影響范圍較大的改版（如主流程頁面的重大調整），影響用戶決策的新產品上線和其他具有風險性的功能上線通常采用先從小流量測試開始，然后逐步放大測試流量的方法。但是，測試版本的流量如果太小又可能造成隨機結果的引入，試驗結果失去統(tǒng)計意義。

舉個例子：某電商網站對我的歷史訂單這個頁面進行改版的AB測試，測試的目標是提升用戶的復購，衡量的指標是經過這個頁面的單UV產生的GMV貢獻（單日GMV總數／單日進入UV）。假設這個頁面每天的UV在2000左右，而我們對新版本取的分流比例是2%，那么一天就會有差不多40個UV進入試驗版本。如果試驗進行1周然后考察試驗結果，這是試驗的結果就很容易受到某些異常樣本的影響，譬如說某個土豪老王恰好分在了試驗組然后購買了一個高價值的東西，那么老王的購買行為就可能帶偏整個測試組的統(tǒng)計結果。

為了規(guī)避這種因為樣本量不足造成的試驗結果不可用，在AB測試設計時可以采用如下措施：

1.試驗設計時預估進入試驗的樣本量，做分流規(guī)劃時避免分配給測試集的樣本量過少。

2.除了進行AB測試外增加關于數據有效性考量的AA測試，將原始版本的流量中分出兩個和測試版本相同的流量也進入測試。例如：為測試一個新的功能，我們原本準備劃分90%流量給老版本，10%流量給新版本；這時我們可以分配70%流量給老版本A，同時生成兩個10%流量的老版本C和D進行AA測試，然后把剩余的10%流量給新版本B；在試驗過程中通過考察分配給老版本C和D的兩股流量是否存在顯著性差異，從而認定試驗分流是否有效。

3.如果參與測試新版本已經分配了很大的流量比例，但是仍然存在樣本量不足的情況，這時就只能通過拉長試驗時間的方式來累積足夠的樣本量進行比較了

AB測試的設計過程中另一個重要的點就是AB測試延續(xù)的時長了，通常AB測試延續(xù)的時間不宜太長，因為AB測試是對線上的多個版本的測試，這也就意味著線上系統(tǒng)需要同時維護多個可用的版本，長時間的AB測試無疑加大了系統(tǒng)的復雜性。但是，另一方面如果試驗進行的時間太短可能會造成試驗樣本量不足的問題。同時，如果進行的是UI改版一類影響用戶體驗的測試，新版本上線后用戶通常需要有一個適應的過程，這時我們通常會在試驗開始時給用戶一個適應期讓用戶適應新的UI版本，然后再考察試驗的結果。適應期的長短通常以足量用戶流量參與試驗后的2到3天為宜。適應期過后的試驗時間長短除了需要考察樣本量的情況外，還需要參考用戶的行為周期，譬如說電商用戶的購買行為有較強的周次規(guī)律，周末流量和購買量與工作日會有顯著差異，這時測試的周期應該能夠覆蓋一個完整的周期，也就是應該大于1周。

在試驗版本的設計過程中還需要考慮線上進行多個試驗相互間的影響，譬如在電商的購買流程中我們同時對搜索算法和商品詳情頁的UI進行優(yōu)化，這兩個變動貫穿在用戶的購物流程中，相互之間可能是有影響的，我們需要區(qū)分試驗中這兩種改動帶來的影響分別是怎樣的。

在這種情況下當然我們可以將用戶流量分成：

A.老的搜索算法和老的詳情頁UI

B.新的搜索算法和老的詳情頁UI

C.老的搜索算法和新的詳情頁UI

D.新的搜索算法和新的詳情頁UI

這樣四個版本，然后進行測試。但是這樣分流的問題是對于流程中元素的改動，測試的版本是呈現指數上升的，在多個改動同時進行時就容易造成版本流量不足的情況。在這種情況下就需要引入試驗分層的概念，將實驗空間橫向和縱向進行劃分，縱向上流量可以進入獨占實驗區(qū)域或者是并行實驗區(qū)域。在獨占實驗區(qū)域，只有一層，實驗可以獨享流量且不受其他實驗的干擾。在分層區(qū)域，不同的應用屬于不同layer，每個應用內部，又可以劃分為多層，層與層之間相互不影響。流量可以橫向經過多層，每一層可有多個實驗。流量在每一層都會被重新打散。

這樣多層次正交的實驗方式使多個并發(fā)實驗都可以保證具備一定流量的并行進行。

最后，在對用戶體驗有明顯影響的實驗中通常采用對用戶穩(wěn)定的分流實現。即分到不同版本的用戶在多次登錄應用落入相同的實驗版本，這樣可以保證用戶體驗的一致性，保證用戶能夠在適應新版本的情況下有穩(wěn)定的表現。通常會采用不同實驗選用不同的hash種子，對用戶的guid和上述分層實驗的實驗層次id的組合進行hash，然后根據hash值取余的方式進行分流。

5.3.3 AB測試效果分析

關于AB測試實驗效果的分析通常分為兩個步驟：實驗有效性的判斷、實驗結果的比較。實驗有效性的判斷即判斷實驗的分流是否已經到達所需要的最小樣本量，從而能夠以較大的概率拒絕兩類統(tǒng)計錯誤的發(fā)生。最小樣本量的判斷可以采用假設實驗目標指標符合正態(tài)分布下，兩類錯誤發(fā)生概率的分位數的方式進行估算。或者更一般的可以采用AA測試，對兩個老版本的實驗結果計算P值，從而判斷其是否存在顯著差異。如果AA實驗的結果不存在顯著差異，那么可以認為實驗結果是有效的，進而可以對新老版本的實驗結果進行進一步的判斷。

在確認實驗有效后就可以對實驗的結果進行判斷了，通常通過比較新實驗版本和老版本是否存在顯著差異（前述的P值判斷），以及計算實驗結果指標的置信區(qū)間（通常選用指標的95%置信區(qū)間），從而判斷新版本是否相對老版本存在顯著提升或下降。

5.3.4 關于AB測試的一些誤區(qū)

誤區(qū)1: AB測試運用成本過高，可以通過灰度發(fā)布的方式來進行AB測試，進而避免同時維護不同版本的情況。

灰度發(fā)布是應用發(fā)布通常采用的方式，即對一個pool的部分服務器發(fā)布新版本的代碼，而其余的服務器采用老版本代碼，在確認應用正常的情況下逐步將新版本發(fā)布到pool的全部服務器。這樣的方式的確可以起到分流的作用，但是這樣的分流是不穩(wěn)定的，用戶的兩次訪問很有可能會被分到新老兩個版本上。同時，灰度發(fā)布的分流單位通常是以服務器的流量為最小單位的，不能做到對測試流量的精確分配。

誤區(qū)2: 用參加實驗的部分用戶的體驗質疑AB實驗結果的正確性。

經常碰到產品經理或是業(yè)務人員提出某些用戶在新版本的實驗中沒有轉化，而實際實驗數據體現新版本效果好于老版本的情況，從而質疑實驗的結果。AB測試是基于統(tǒng)計的結果，是基于大樣本量的有效統(tǒng)計結果，實驗結果的好壞是針對參與實驗的大多數樣本而言的，個例不具備代表性。

誤區(qū)3: AB測試是優(yōu)化Web應用的利器，應該在所有場合都應用AB測試進行優(yōu)化。

AB測試從實驗的設計、實施和實驗結果的收集通常需要一個不短的階段，且進行AB實驗需要在線上維護多個不同的版本，所以不應該所有場景下都采用AB測試對Web應用進行優(yōu)化迭代。對于那些明顯的bug修復，或者對于那些能夠明顯改善用戶體驗的功能，應該采用盡快上線并監(jiān)控關鍵數據指標的方式。此外，AB測試也不是silver bullet, 通常AB測試的時間不會延續(xù)很長時間，對于一些長期效果很難做到有效的監(jiān)測和對比。

例如，某OTA對機票進行捆綁銷售產生的收益進行了為期一年的多版本AB測試，測試的目標是在用戶轉化率沒有顯著下降的情況下提升用戶客單價。在實驗中，通過對價格非敏感用戶的個性化展示、默認勾選等方式的確客單價有了很顯著的提升，同時用戶的線上轉化率并沒有顯著變化甚至有了略微的提升。但是，這種捆綁銷售的方式從長遠來看可能對用戶是有傷害的，這種情況在低頻消費的場景下很難在實驗的結果上有所體現。而且，這種捆綁銷售的產品為媒體和公眾所詬病，這些都不是AB測試能夠體現的。

綜上所述，AB測試是一項復雜的系統(tǒng)工程，除了要掌握AB測試方法，制定嚴謹的AB測試方案之外，還需要依賴科學的AB測試工具進行試驗。

5.4 優(yōu)缺點

優(yōu)點：有效評估出最優(yōu)的設計版本

缺點：需要一定的研發(fā)和設計成本

6、卡片分類

6.1 方法說明

通常用于測試分類或導航結構，讓用戶將一組寫有信息的卡片分組，并為其分配名稱或標簽。卡片分類有助于了解用戶如何看待內容以及他們如何組織信息，從而決定在每個頁面放置什么，對于頁面或功能分類很有幫助。

6.2 適用階段

概念設計階段

6.3 執(zhí)行規(guī)則/注意事項

1）卡片準備

根據項目參與成員的不同，卡片數量也可以不同。比如小孩VS成人，對于小孩，注意力、理解力和精力有限，卡片不宜過多，以免出現完成不了任務的情況；對于成人，相對較好。
一般控制在30~100張。小于30張，用戶很容易完成，但也許不能體現分類；大于100張，用戶會累，而且不易記住分類內容，耗時較多，隨著用戶完成任務動機的提高會影響完成效率。
可選取名片打印紙打印卡片，也可裁剪偏硬的紙張，手寫卡片內容。

2）卡片內容特性

易懂性
a，選擇用戶能夠理解的內容。如：網絡傳輸，有用戶不明白網絡傳輸和藍牙傳輸的區(qū)別，認為藍牙傳輸也是網絡傳輸。
b，內容不具有歧義或誤導性。如：大數據量操作，用戶不清楚是指批量操作很多數據還是指對大數據的量化操作。
可行性
a，選擇能夠進行歸納的內容。如：“wifi，瀏覽器，通訊錄，視頻通話，手機殼”中，前四個明顯屬于手機的功能，最后一個手機殼屬于手機的附屬物。
條理性
a，內容在同一層級上，避免包含關系。如：“手機多媒體，音樂，圖庫，視頻”中，后面三個內容都包含在手機多媒體中，此時不應該同時出現來讓用戶分類。
b，內容和功能任選其一，不能都選。如：“手機尺寸，開關機”中，前者屬于內容，后者屬于功能。

3）招募用戶

可用性專家Nielsen認為大多數可用性研究，5個人就可以達到0.75的( 參與者的實驗結果與最終結果) 相關度，他推薦卡片分類的用戶數只要15人左右即可達到0.9的相關度。

圖片來自：Jakob Nielsen，2004

Tullis與Wood經過實驗分析得出參與者人數最好是20~30 人，此時邀請參與者的實驗結果與最終結果的相關度可達到0.9以上。

圖片來自：Tullis and Wood，2004

個人建議：一般情況下，每一類用戶找15-20名，可以發(fā)現大部分問題；若想對不同類型人員進行對比，則每一類人員中都需要有足夠多的人員。

4）用戶進行分類前

活動介紹：分發(fā)卡片前，清晰地介紹活動，給用戶足夠多的背景信息，讓其明白卡片是關于什么的。
分發(fā)卡片：盡量將卡片分散放在桌子上，鼓勵用戶先看看這些卡片（因為大多數人都不會根據后面看到的卡片來回頭重新組織內容），而不是上來就劃分；
不同類別的分類：開放式分類時，先不要告訴用戶需要進行標簽命名，等到分類結束后再告知，否則用戶一開始就會琢磨標簽命名，而不是考慮如何分組；閉合式分類可以將標簽擺在桌面上。

5）用戶進行分類中