眾所周知，任何測試都會花費成本，用戶體驗測試也不例外�？紤]實際收益，用戶體驗測試的設計需要慎之又慎，它需要對軟件測試的目的、介入時間、測試的周期、場景、人員的選型都要做出深入的分析和界定。
有關用戶體驗測試的目的，我想大的概念應該都是基于用戶第一而展開，針對不同軟件在細節上的關注點會有所區別，可以說它是介入時間、人員選型等其它設計內容的先決條件，其它內容的設定都將圍繞它展開。
目前我們選擇進行用戶體驗測試的一個很重要目的是為了判定我們的產品是否能讓用戶快速的接受和使用，或者更直接的說法是驗證我們的產品是否會不符合用戶的習慣，甚至讓用戶對產品產生抗拒。顯然針對這一目的進行的用戶體驗測試介入時間一定要盡可能的早，試想如果在系統快要發布前才進行該項測試，很可能因為在用戶體驗測試時發現頁面結構不合用戶操作習慣，或者有些功能對于用戶而言需要強化，或者操作步驟過繁，在不推遲發布時間的情況下，此時對代碼進行修改和優化，誰都知道這樣的行為無疑是危險的。因此，較為合理的做法是當頁面的demo定稿時我們就需進行用戶體驗測試，但是由于此時的測試是靜態的，所以還不足以保證用戶實際的操作感受，我們還需要在系統提交功能測試后，當功能測試人員驗證主流程已能正常流轉，用戶體驗測試就可以再次介入進來，此時的用戶體驗測試不需要像功能測試那樣關注細節的實現，更重要的是收集用戶的操作習慣和使用感受。假使我們不需要說明使用方法用戶就可以流暢的進行操作并且在操作過程中不會對操作習慣進行過多的抱怨，那么我們可以認為系統的交互、設計是合理的，反之，我們就需要考慮作出相應的修改和調整。
說到用戶在使用過程中的抱怨，這里就不得不提到人員的選定，可以從這一點很明顯的看出，用戶體驗測試不宜選取熟悉的人，比如同事等，因為熟悉的同事很有可能因為礙于面子不去直接表達自己的感受，尤其是同一部門的人員，極有可能因為長期的接觸，導致習慣同化，這就失去了測試本身的意義�；蛘呖梢钥紤]在測試之前，組織測試的人員鼓勵用戶提出看法和想法，并對這些意見進行客觀的分析。并且進行功能測試和組織用戶體驗測試的人員最好也不要相同，因為參與了功能測試的人員很有可能被局限在系統現有的設計中，而無法全面的收集意見和作出判斷。但同時功能測試人員和組織用戶體驗測試的人員應該要做到及時的溝通，否則就會出現“脫節”。
此外，個人還覺得用戶體驗測試并不應該僅僅拘泥于用計劃來限制實際測試。在項目功能驗證完成之后正式發布之前，任何一個非項目組人員有機會使用到系統（甚至不需要使用，只是了解了系統的部分功能）所提出的建議，都可以認知為一種用戶體驗測試。整個項目組成員都應該主動將這類信息進行收集，并及時的商討判定信息的價值，以便作出修改和完善。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/