定義：在一個發聲思考測試中，測試的參與者在執行任務行為時實時的說出自己腦子中所想的內容
這看上去是一個很簡單的要求，但是在實際過程中要求一個測試者不停地說出自己所想是非常困難的，所以測試的實施者必須不斷的提醒測試者。
進行一個基本的發聲思考
可用性測試，只需要做3件事情
招募代表性用戶
讓他們執行有代表性的任務
閉上嘴聽測試用戶說
發聲的好處
首先這個方法有一大堆優勢。其中最重要的是，發聲為想法提供了一個可見的窗口，透過窗口你可以發現用戶到底是如何使用和看待你的設計的。特別的，你可以發現他們產生誤解的地方，這些往往是需要進行重新設計的，所有引起誤解的元素都必須改變。更重要的是，你可以從中發現為什么用戶會產生誤解，為什么其他的設計方式會更易用。
發聲的好處還有
低花費。不需要特殊的儀器，只需要你坐在測試對象旁邊記錄他所說的話。收集到足夠多數量的用戶測試信息可能會花費一整天的時間，但這一定是值得的
可信度高。大多數的實驗者都缺乏經驗所以大多數時候測試都不能夠按照最正確的方式進行。但是除非你嚴重干涉誤導測試者，即使在不標準的測試中你依然能夠獲得大量有價值的發現。相比之下，定量的可用性研究對于方法的精確度要求的更加嚴格，很小的錯誤也可能導致研究結果出現巨大偏差。定量的研究往往也花費更高。
靈活度高。在開發的任意時期你都可以進行這樣的測試，從紙上的原型到已經成型的原型。發聲思考特別適合
敏捷式的開發模式。你可以運用這種方法測試任意形式的用戶界面，雖然用發聲的方式測試聲音交互界面有點奇怪，但是你可以參考這篇
文章里關于進行有實力測試障礙的人的測試。不論是網站，軟件，局域網，消費類產品，企業級軟件，
移動設計，發聲測試都可以運用，因為他只依賴于可以思考的用戶
有說服力。最老練的開發者，傲慢的設計師，吝嗇的總經理在直接面對消費者的時候態度都會變得溫和。讓他們坐下來聽聽在發聲測試中用戶的想法并不會花費他們太多的時間，并且有可能促使他們重視可用性。
簡單易懂。
發聲思考的問題
花費低和不容易出錯是定性研究方法諸如發聲思考的巨大優勢。但他們不好的一面是除非你進行的是一個巨大昂貴的實驗，否則是不能形成定量數據的。當然你可以選擇做一個巨大昂貴的實驗，但是我的建議是這些精力和經費投資在更多的設計迭代過程中更值得。
其他問題
不自然。除非測試者是個怪人，大多數普通人不會坐在那里自言自語一整天。所以想要讓測試者在測試過程中保持自言自語其實是一個比較困難的過程。幸運的是來參加測試的人一般都會比較積極的配合，以至于有時可能忘記自己僅僅是在進行一項測試。
想法過濾。測試者被要求說出他們腦中呈現的第一印象，而不是說出經過了思考之后的分析結果。但是與此同時，大多數人希望自己表現的像個聰明人，于是他們更傾向于在說出自己所想之前先思考一番。千萬不要陷入了這個陷阱，獲得測試用戶最原始的想法是非常重要的。所以一般情況下，實驗者必須不斷的提醒用戶不斷的說。
誤導用戶行為。指導和解釋說明在測試過程中是必要的，但假如是一個不專業的實驗者來進行，那么他給予的信息很可能會改變用戶原本的行為。有誤導存在的情況下，用戶的行為是沒有代表性的，更無法提供設計依據。至少，你必須能夠識別出在哪些測試中用戶的行為是被誤導了的，作廢這些觀測結果。最糟糕的情況就是你不知道自己在哪些地方做錯了，這樣你提供給設計團隊的意見很有可能就是錯誤的
不一定通用。只要你同時使用其他的方法，不通用事實上并不是一個真正的缺點。發聲思考可以在大多數情況下使用，但也并非全部情況下通用。一旦你在可用性測試這方面有了一定的經驗，你會有其他很多測試方法可以選擇
不要因為這些問題就退縮，如果你還沒有使用過這個方法，你可以現在就為自己正在進行的設計項目進行一次。這個方法是如此的簡單易行，每周一次都是完全可行的。所以如果你這一周犯了錯誤，下一周你一定可以做的更好。