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

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

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

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

作為測試的計劃準則

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

作為主要溝通工具

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

計劃寫明或暗含所需資源

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

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

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

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

測試計劃的組成部分

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

■ 測試目的、目標和對象

■ 研究問題

■ 被試特征

■ 方法(測試設(shè)計)

■ 任務(wù)清單

■ 測試環(huán)境、儀器和后勤準備

■ 測試中主持人的作用

■ 收集的數(shù)據(jù)和評估方法

■ 報告內(nèi)容和呈現(xiàn)

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

回顧測試目的和目標

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

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

■ 服務(wù)器日志或網(wǎng)站使用數(shù)據(jù)是否已表明公司網(wǎng)站的訪客在某個流程中的某一節(jié)點離開，使得業(yè)務(wù)無法完成?

■ 公司是否最近公布了新規(guī)范要求所有產(chǎn)品在發(fā)布前進行測試?

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

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

什么時候不進行測試

下面幾條是產(chǎn)品應(yīng)該進行可用性測試的非常模糊和不恰當?shù)睦碛伞＿@些理由可能很少會被書面化，通常是口頭交流。但是，下列的測試理由并不合理，反而最終會影響整個項目。

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

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

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

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

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

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

進行測試的最佳理由

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

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

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

■ 你收到了大量使用產(chǎn)品中的投訴。你想確定這些投訴的本質(zhì)，以及在今年開發(fā)預(yù)算下如何修復(fù)這些問題。

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

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

溝通研究問題

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

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

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

■ 例子1：當前的產(chǎn)品是有用的嗎?

■ 例子2：該產(chǎn)品是否可以發(fā)布還是需要更多工作要做?

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

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

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

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

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

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

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

　　圖5-2 研究問題示例

描述被試特征

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

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

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

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

　　圖5-3 被試特征及合理人數(shù)示例

描述測試方法

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

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

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

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

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

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

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

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

獨立組間設(shè)計或被試間設(shè)計

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

被試內(nèi)設(shè)計

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

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

測量多個產(chǎn)品版本

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

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

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

測試多個用戶組別

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

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

　　圖5-4 測試方法舉例

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