如果：
你所在的公司剛開始推行UCD，一切都剛起步；
沒有固定的人手，沒有很多的資源，測試研究的時間和經濟成本非常局限；
你看了不少有關的書和文章，但實際開始做的時候還是覺得有不少困惑
那么，希望這篇文章可以幫助你。
時間
測試的時機
理想地說，可用性測試盡早開始越好，也應該是產品開發的一環，可以有一個迭代的過程。但是對于初次的嘗試來說，不一定能夠做到：也許你的Boss不希望把“半成品”拿出來給人看，也許你們的開發進度緊迫插不進這樣的時間，但是也不必放棄，晚測試總比不測試好，實在不行就把發現的問題放到下個版本去修改。亡羊補牢，為時未晚。
當你的同事和上司看到了可用性測試的價值后，你做測試也慢慢上手了，就能爭取到加入開發環節的機會、迭代測試和開發的機會�；蛘吣愕漠a品頻繁有少量改動的更新，這樣子測試問題也不大。
你需要的，只是抽出下面提到的一些時間。
準備時間
測試前，你可能需要在一兩周的工作時間穿插可用性測試的準備工作。若是剛開始在公司嘗試可用性測試，你應該寫一份簡單的測試計劃——告訴你的Boss你要做什么事情、也幫助自己規劃做測試的一系列工作。
然后也許你需要申請一些資源，空間、硬件、人員協助等等～
Check一下這次要測試的功能，設計一下測試的任務。如果是第一次測試，心里過一下整個測試的過程，開始-測試時的引導-結束，有機會做次導測的話會讓你更有信心。
還有就是招募受測。這個根據你招募的方法需要的時間不同，具體的招募請見下面的部分。
測試時間
準備好了，和受測也約好時間，就可以開始測試了。
你的受測很可能是上班族，這也就意味著測試會安排在非工作時間，比如晚上、周末。就算你很經濟，用的是同事，也可能因為他們工作繁忙需要一起占用午休時間或者下班后多留一會兒。>_<真是辛苦，測試難免會需要你加班。而唯一的好處就是，如果你是在本職工作之余做這件事，對原先工作的進度影響就沒那么大了。
分析&結果分享時間
測試結束之后，整理下你的記錄(如果有條件錄像的話，還要回看錄像)，分析歸納寫一份測試報告，寫下發現的問題，附上些截圖或者關鍵錄像片段。報告不必弄得很詳細，目的是為了把測試發現的問題讓同事了解。個人覺得比較好的是PPT，不必很多文字，可以現場講解問題的具體情況和背后的原因、還可以大家一起討論修改的方案。如果沒時間做presentation，給同事看文檔，寫簡單一些，挑重要的寫。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
