用戶體驗，簡單的說就是用戶使用方便，用戶使用方便說起來容易，但作為測試怎么樣才能衡量“用戶使用方便”，你提出來的用戶體驗問題如何才能說服開發或者UED去修改呢?很多做過測試的人在測試的過程中多多少少都會遇到一些這樣的問題。可能大家平時遇到一個功能就是用的不爽但也說不出個所以然來，像這樣公說公有理婆說婆有理，最后問題得不到好的解決。導致上線后出現一系列問題，傷害用戶傷害公司傷害自己。
很多時候我們可能都是通過主觀意識來做事情，尤其對待用戶這塊。大家平時都在說要站在用戶的角度去思考問題，去做事情。平時我們提出的所謂用戶體驗的問題，也都這樣說“我是站在用戶的角度來考慮的”，但是這些語言總是顯得蒼白無力。為什么？我一直在思考這個問題。靜下心想想，我們真的是站在用戶的角度嗎？我們真的了解用戶嗎？我們的依據是什么？其實不光我們測試，任何人都需要思考這些問題。
單就測試這邊而言我覺得我們可以在測試準備階段加上用戶數據和用戶行為的收集，采集這一環節。作為測試過程中我們測試工程師用戶體驗測試一個強有力的依據。讓我們真正代表用戶去提出問題，解決問題。最終達到用戶和公司都滿意！
說歸說大家可能在想我們后續如何去收集數據？什么人去收集？收集哪些數據？收集完數據如何利用好這些數據？是否每個項目都適用？用完是否真的對我們的用戶體驗有所幫助？投入與產出是否成正比？
針對以上問題我拿一個某功能模塊改造項目為例來嘗試回答以上問題。項目立項之后由需求人員對該改造的項目的用戶類型以及每種用戶的行為進行分析，并從數據分析部門（上一個項目發布后會對數據分析部提出這樣數據采集的需求，等到下個項目來臨就可以輕松獲得數據，形成一個循環）收集相應的數據產出一份用戶數據報告。測試人員（其他人員可能也會利用到這份報告，我這里單講測試人員如何利用這樣的數據）拿到這份數據報告，在測試準備階段，根據這份報告產出相應的用戶體驗測試用例以及用戶體驗實體數據，這些數據可以自己造，當然必要的情況下也可以找DBA協助。準備工作完畢后 在集成測試執行階段進行到各功能模塊基本穩定就可以執行我們的用戶體驗測試用例啦。當然根據實際情況用戶體驗測試也可以提前一點來做。執行完畢并產出用戶體驗執行報告。等到項目達到發布條件就可以發布啦。
項目發布后我們就可以對我們的用戶體驗測試的效果進行評估了。需求人員跟蹤用戶反饋問題結合我們產出的用戶體驗執行報告進行綜合評估，看看我們測試所做的用戶體驗測試是否真正對用戶有幫助。通過過程中采集相應的用戶體驗的工作量與我們測試出來的用戶體驗問題帶到線上的代價預估最終得出投入與產出比。還可以對項目之間進行橫向的對比，看看哪些項目適合這么做，哪些不適合這么做。
以上僅為個人的一點想法和一些不成熟的實施方案，僅供參考，呵呵！