?為什么要制定測試計劃?

合理的做法是：當你知道將要進行測試的那一刻起，就該著手準備測試計劃了。之后隨著項目推進，不斷完善計劃，收集反饋，如此往復。當然，靈活也是有限 度的，你在測試前必須設定某個時間節點，確保在此之后，計劃不會變動。同時，測試的產品在這個時間節點后，也不允許再有任何改動，直到測試結束。你可能已 經發現測試計劃是產品開發周期中唯一具有明確時間點的文檔，因此格外重要。

當期限臨近時，你要竭盡所能不要去變動將要進行測試的設計產品。額外改動會令之前制定的測試方案變得不再可靠，譬如需要研究的問題甚至是數據收集方法 的信度都會受到影響。如果在計劃的時間點之后被迫更改測試，那要確保每個人都了解此舉帶來的風險：測試可能是無效的，并且臨近測試前改動的產品有可能無法 正常使用。

下文列出了為何需要制定詳實計劃的原因，以及在開發團隊中測試計劃作為溝通工具的使用方法。

作為測試的計劃準則

正如圖紙精確畫出了所要建造的房子一樣，測試計劃也精確描述了將如何去測試你的產品。你肯定不愿意建筑承包商在建造房屋時不按計劃地即興發揮，可用性測試同樣遵循這一邏輯。測試計劃確保一切有據可循。在測試第一位被試時，你肯定不希望測試中仍存在尚不清楚的事項。

作為主要溝通工具

測試計劃是設計師、開發者、測試主持人以及團隊其他成員的主要溝通工具。開發團隊和管理團隊(如果他們感興趣且在團隊中)的相關人員應該仔細閱讀測試 計劃的文檔報告：了解測試是如何進行的，并確認是否已滿足他們的具體需求。你可以利用計劃從其他成員那兒獲得建議和反饋，以保證每個人都同意將要進行的實 戰測試。進行的項目每天每周都會有變化，你也不想在測試結束后某人質疑他或她的某些需求沒在測試里出現。另外，如果這是你組織的第一次測試，更要讓測試結 果的相關負責人員審查測試計劃。這也保證了計劃的商業性和政治性。

計劃寫明或暗含所需資源

測試計劃描述或暗示了測試所需要的內部和外部資源。一旦你準確列出了何時將進行何事，那預估測試所需的資源這一任務就變得清晰容易了。無論是直接寫明亦或是間接暗示，測試計劃包含了成功測試所必需的資源。

計劃是測試和實際階段的連接點

沒有測試計劃，細節就會變得模糊不清，尤其是在截止時間的壓力下。測試計劃迫使你的測試方法具有系統性，提醒開發團隊即將到來的截止日期。說了這么 多，這是完全可以接受的，并且是極有可能發生的。當你逐漸了解更多的測試目標，與參與測試的被試溝通更多時，測試計劃在這個階段中也會逐漸優化。項目是動 態的，當測試真正開始時，即便是看起來最完美的計劃也不得不變更。通過優化測試計劃，你可以適應過程中遇到的變數。例如，當你的時間和資源的限制越來越清 晰的時候，你可能變得不那么雄心勃勃了，而是想敷衍了事?；蛘?，也許你沒有按照自己的設想找到足夠多合格的參與者。也許不是文檔中所有模塊或章節的需求都 將按時準備好。也許你的測試目標太不精確，需要簡化和集中。這些都是來自真實世界的例子，他們迫使你修改測試過程和測試計劃。

注意：當你制定計劃時要始終將最終用戶牢記心中。隨著項目進行，你很有可能忘記你要測試的內容：具有某些特點的用戶與產品的關系，而不是測試產品本身。

測試計劃的組成部分

測試類型不同，或是你所在的組織對測試規范度的要求不同，測試計劃的格式也是不同的。不過，通常會包含以下9部分，下文將對它們具體地描述。

■ 測試目的、目標和對象

■ 研究問題

■ 被試特征

■ 方法(測試設計)

■ 任務清單

■ 測試環境、儀器和后勤準備

■ 測試中主持人的作用

■ 收集的數據和評估方法

■ 報告內容和呈現

其中，由于測試中主持人的作用巨大，在第4章將作為獨立章節詳加討論。其余部分則在本章闡述。

回顧測試目的和目標

文檔的這部分描述了進行該項測試的原因。這里不是要你說出測試考察的具體目標或問題;相反，你的焦點或出發點應該是站在組織的角度，關注重點的問題。例如：

■ 測試旨在解決的問題是：公司的呼叫中心或技術支持先前上報過的問題嗎?

■ 服務器日志或網站使用數據是否已表明公司網站的訪客在某個流程中的某一節點離開，使得業務無法完成?

■ 公司是否最近公布了新規范要求所有產品在發布前進行測試?

■ 管理者是否意識到開發團隊在此時了解真實用戶是非常重要的?

測試目的拔高到較高的高度是合適的：因為后續的研究問題及描述部分可以將大目標具體到可測量水平。測試與組織的商業目標緊密相關這點非常重要，這樣測試才會成為解決問題和探尋機會的最佳工具。

什么時候不進行測試

下面幾條是產品應該進行可用性測試的非常模糊和不恰當的理由。這些理由可能很少會被書面化，通常是口頭交流。但是，下列的測試理由并不合理，反而最終會影響整個項目。

■你可以提升用戶體驗(你只能測試產品部分的用戶體驗，而不是產品與用戶的所有接觸點)。

■其他人都在做可用性測試項目(其他人還有很多別的事兒呢)。

■ 用作可用性測試的會議室本月的第三周都是空閑的(會議室每天晚上也空著)。

■ Lou先生剛參加了新一屆計算機協會人機交互特別興趣組ACM SIGCHI的會議，并且學會了這種有用的測試技術(那先讓Lou先生向公司高層推薦這一有用的技術)。

■ 你想要確認是否該類型的產品有市場需求的(這個邏輯顯然反了，焦點小組和問卷才是更為恰當的在產品早期階段使用的方法)。

你可能會說服自己，尤其是當你非常迫切開展可用性測試時，“我只是想做測試，我并不關心原因，我們可以后續再考慮測試結果?！倍唐趤砜?，前面的任何理 由都可以開始測試。但從長遠角度看，如果你希望測試是開發產品中不可或缺的部分，你必須將測試與產品需求和組織的整體商業需求結合起來。否則，你會面臨測 試被當成短期流行的新技術的困境。

進行測試的最佳理由

以下清單列出了進行測試的合理原因，它們幫助得出有效的結果，并為未來測試奠定基礎。

■ 你想確定是否你的兩類主要用戶都能很好地使用產品。

■ 你想了解提供文檔是否可以解決界面中的某些普遍問題。

■ 你收到了大量使用產品中的投訴。你想確定這些投訴的本質，以及在今年開發預算下如何修復這些問題。

圖5-1給出了一個示例：在線酒店預訂網站的可用性測試目標。

　　圖5-1 可用性測試的目的和目標示例

溝通研究問題

這一章節是測試計劃中最重要的部分，它描述了需要解決的問題和研究焦點，以及與測試計劃、設計和操作相關的部分。研究問題必須盡可能地準確、精確、清 晰并且可測量的(或是可觀察的)。就算是產品開發早期進行的探索性測試——非結構化的測試，仍需要精確地闡述你希望從中得到什么。

如果沒有清晰簡潔的研究目標，你會發現自己陷入了不利境地，執行的測試無法解答項目團隊成員所關心的核心問題?；蛘?，你會發現測試總是處于無休止的爭 論中，因為根本問題“測試的是什么”還未達成一致。從我自身的經歷來說，我們遇到過準備工作推進著，但測試本身爭議不斷的情況，這其實還是測試目的沒有落 實成書面報告的緣故。

以下兩個例子的研究問題就太模糊，太不明確了。

■ 例子1：當前的產品是有用的嗎?

■ 例子2：該產品是否可以發布還是需要更多工作要做?

研究的困難之處并非是說這些問題毫無意義。而是說這些問題是不完整、含糊不清的，沒有說明或暗含該如何測量或量化結果。依據此類描述來進行的測試最終 會引起結果偏差。為什么?如果相關人員就需要解決的問題都無法達成一致，那你又如何確認已經找到問題的解決之道了呢?當然，在這樣的情況下，通常是連研究 問題都找不到。

下表列出了幾類不同產品的研究問題，這些案例的研究問題恰當，重點明確。研究問題是在和開發團隊或開發人員、技術人員、市場人員的討論中形成的。如果他們很難歸納出測試目標或者僅僅提出了大概的問題或目標，也無需沮喪，這可能正說明：

■ 他們還沒有做好測試的準備。

■ 他們需要更充分地了解測試目標、目的和過程。

■ 他們在將目標轉化為具體的可測量和可觀察的研究問題上需要幫助。你不要猶豫，是時候介入其中或提供幫助。

如果你發現自己很難設計測試方案和(或)合適的量表，又或是確定不了合適的終端用戶，甚至是無法確定數據收集的形式，你不妨再回到研究問題本身，確認它們是否是清晰、需要進一步細化的。

下圖5-2 給出了某個在線酒店預訂網站的可用性測試的研究問題。

　　圖5-2 研究問題示例

描述被試特征

測試計劃的這個部分是描述測試產品的終端用戶特征。與組織內的其他成員通力合作，從而確定目標用戶的特點是非常重要的。有關如何建立用戶檔案和招募被試的具體過程可參見第7章。圖5-3舉例某在線酒店預訂網站可用性測試中的被試特征。

當描述被試特征時，首先要牢記招募合適數量的被試。當說到參與測試的被試數量時，最重要的原則是“你不可能有太多被試”。從結果在統計學上的有效性考 慮，小樣本量缺乏統計效力，無法檢驗組間的差異顯著性。真實的實驗設計中，你必須確保每個條件下至少有10-12名被試。但是，對于非正式的可用性測試來 說，研究證明，有4-5名具有代表性的用戶就夠了。這群代表目標群體的被試將會發現產品80%的可用性問題，而這80%正是產品的主要問題。當然，如果你 有時間或資源去測試超過4-5名的被試，你有可能會發現另外20%產品的重要問題。

我們參與的很多測試同樣印證了上述原則。在某個測試中，Jeff測試了8名被試，其中80%的問題在對前4名被試的測試中就已經發現了。但是，第8名 被試，也是最后1名被試，在某個任務中出現了嚴重錯誤，不得不尋求產品的呼叫幫助。如果只測試4名被試，我們將永遠無法發現這個嚴重問題。如果你的測試經 驗還不豐富，那招募盡可能多的被試無疑會降低漏掉重要問題的可能性，同時也提供了額外機會鍛煉你的測試技能。

如果你沒有時間和大筆預算，你可能會想要試下“打折”的可用性測試：在開發周期內進行幾次小型的，迭代的可用性測試。一場測試招募4-5名目標用戶， 進行1-2組任務條件，將結果應用到界面設計中。隨后，進行另一場規模和任務類似的測試。3-4次測試后，你已經有了相對較大的樣本量，并且開發團隊也能 發現不同測試間的變化。

　　圖5-3 被試特征及合理人數示例

描述測試方法

測試計劃的這部分將會詳細敘述如何對被試進行研究，以及如何展開測試。實質上，測試方法就是你測試設計的大綱：被試到達至被試離開的整個測試過程中的 每一節點的細致闡述，以便測試觀察者可以大概了解內容。為何測試計劃中需要包含如此多的細節內容?下面列出的理由可以解開你的疑惑。

■它幫助其他人員理解測試的過程并使之可視化呈現，以便他人可以提出意見或建議。

■ 它有助于你從測試執行者的角度關注被試到達前需要準備的材料和事項。

■它提醒你需要將測試計劃與其他資源方溝通協調。譬如前臺，當被試到來時不至于忘記問候。

■它使多個測試主持人(如果測試計劃需要如此的話)可以遵照相似的流程和規范執行測試。

設計測試是可用性專家必備的且具有高度專業性的技能，通常涉及實驗設計和方法，以及基礎的統計分析知識。設計可用性測試，首先需要明確和理解測試目 標，然后根據提出的測試問題設計出解決問題的最有效的測試計劃。如果測試設計是有缺陷的，或者執行測試時沒有嚴格的實驗控制，那結果會是不可信的。這不僅 會導致錯誤的建議，更糟糕的是會直接損害組織中可用性工程的建設。因此，在進行可用性測試前，請富有經驗的同事審閱你的測試計劃，聽取他們的建議和反饋是 非常重要的。

測試設計主要以兩類測試目標——產品本身和產品的使用者為基礎?，F有的資源、阻礙甚至是你的創造力，都會極大地影響設計成果。時間、金錢、管理層和開 發團隊的支持、被試招募的能力，以及其他現實生活中的問題都會成為限制因素。下文將列出幾個你可能會遇到的，常見情形中的測試設計案例。另外，我們給出了 一些確保實驗嚴格性的指導原則。

最簡單的測試設計：測試幾名不同用戶，用戶均屬于同一類型(如老年人)，要求他們完成網站不同部分的某些有代表性的任務。

獨立組間設計或被試間設計

顧名思義，獨立組間設計是指網站的每一部分都是由不同的用戶測試的。如下表所示，組間設計要求15名被試，每名被試僅完成一個任務。這樣會消除任務的 先后順序造成的潛在的學習遷移效應。用戶完成任務A可能會幫助他們順利完成任務B，因此與任務B有關的可用性問題很難被發現。另外，如果每個任務都非常 長，被試有可能疲憊，你也應該使用這種設計。

被試內設計

測試15名被試有可能是難以實現的?，F實是，你只有5名被試，不得不讓他們每人都完成全部的3個模塊。這就是被試內設計。但是，你需要考慮學習的遷移效應。你可以使用平衡抵消的技術來消除學習效應。

為了平衡抵消，如下圖所示，你需要改變任務的順序，每名被試完成任務的順序是不同的。任務順序隨機化減弱了遷移效應，在上述例子中你最少只要4名被試 就夠了。但是，隨機化順序會引起其他問題。在日常生活中很多流程本身就是有順序的(譬如注冊后才能進行付款)，如此一來你就不得不做出權衡：到底是讓用戶 按照正常順序完成任務，但有可能掩蓋后續任務的可用性問題(可以測量被試在任務過程中是否有學習效應)呢?還是提供隨機順序的任務(一般是在實驗室中)， 但被試有可能迷惑和陌生?大多數人同意你應該保持合理的任務順序。如果你決定這樣做的話，你需要注意可能的遷移效應。你可以在正式任務前，讓被試預先進行 訓練，使被試間的使用經驗達到相同水平。另外，在進行完每個部分后被試要有間隔時間休息。

測量多個產品版本

現在讓我們來看另外一種常規情況。譬如你想要比較某個產品的2個不同版本，版本A和版本B，以便確定最終設計采用哪個版本更好。同時，你想要比較兩類用戶組，主管和技術人員，使用產品的差別。這就相當于2×2的矩陣設計。

如果你采用獨立組間設計，你的測試計劃是表中的數量單元格指不同的被試。該設計需要16名被試，分配到4個不同的條件：4名主管使用版本A，4名技術 人員使用版本A，以此類推。如果你只有8名被試，那每個條件的單元格只有2名被試，這樣每個類別的數據過少，測試結果可能是無意義的。但是，如果你讓兩組 的每名被試，主管和技術人員，都操作兩個版本，使用一個版本后再使用另一版本。和前述例子一樣，后測試的版本可能會有優勢，被試在第一個版本的測試中可能 學會了某些任務。但是，另一方面，這種效應可能會反過來：被試在第一個版本中形成了某些習慣，而無法適應第二個版本，尤其是當兩個版本差異非常大的話。不 管哪種情況，你的結果都會有偏差。

考慮到這種潛在的問題，你需要平衡兩個版本的順序。如上表所示，8名被試中，一半被試先測試版本A，另一本被試先測試版本B。注意，每個版本被第一次測試的次數和最后一次測試的次數是一樣的，這樣可以消除潛在的順序偏差效應。

測試多個用戶組別

現在讓我們進入略微復雜的實際場景。假設你的用戶檔案包括兩類不同的用戶組：經理和柜員。你的測試目標之一，是了解兩組或多組用戶(經理和柜員)在使 用產品時是否存在差異;另一目標是每個用戶組內的新手和專家用戶的使用差異。因此在使用經驗和工作類型這兩個因素上，分別有兩個水平。你的矩陣設計如下：

4類條件的被試都是不同集合的。也就是說，如果你想每類條件(也就是上圖單元格)有4名被試，那總共需要16名被試。即使出于預算或時間的考慮，16 名被試太多(每個條件至少要有4名被試才能測量組間差異)，你也不能簡單地就采用組間設計。你只能減少每個單元格中的被試數量或者是簡化你的研究。要注意 的是，每個單元格的被試數量少于4時將會嚴重影響結論的推廣。你可能需要簡化研究，不再探索組間差異(圖5.4)。

　　圖5-4 測試方法舉例

注意：如果你是可用性測試的新手，還不能信心十足地保證測試中的實驗嚴格性，請務必使你的測試簡單。測試越簡潔明了，執行時更容易保證流程順利和一 致。從簡單精悍的研究中獲得了有意義的結果，遠比進行大型研究得到一堆無意義的數據要好得多。你最好盡早并盡可能多地開展可用性測試，它可是極為有用和劃 算的。