敏捷開發中的可用性測試(6)

　　多一些例子，比如 Struts 框架提供了 show case 等一系列例子，教導用戶如何開發和使用技巧，這些比純文字的文檔形象直接，效果更是不可同日而語。

　　文檔中盡量少用縮寫，除非是人盡皆知的縮寫，如 IBM, EJB 等詞語。如果需要使用縮寫，需要在一些地方標記出全名。

　　可用性測試的最佳實踐

　　實踐一：Persona

　　現在產品有功能測試、集成測試和性能測試等階段。但很少產品有單獨的可用性測試階段，也很少有可用性的 Defect。鑒于可用性的重要性，作者覺得很有必要增加一個產品的可用性測試階段，用于提高產品的可用性。這個階段中，測試人員對上面介紹的產品各方面進行可用性測試，并開相應的可用性 Defect。測試人員畢竟不是客戶，因此，可用性測試的方法也非常重要。本小節闡述實踐方法以提高可用性測試的有效性。

　　首先，要運用上文提到的 Persona 方法來設計合理的 Persona。Persona 可能不止一個，所以需要分析并確認出不同的 Persona，并設定所有 Persona 的背景，需求，期望等。Persona 的簡單模板包括姓名、照片、人物簡介、工作目標、工作場景描述等。作者的經驗中，Persona 的方法論非常有利于理清思路，在設計測試場景和執行可用性測試階段非常重要。

　　其次，在設計場景時，可以根據 Persona 來定義其相應的角色，功能需求和目標等，然后設計其對應的設計場景，然后在其下面設計具體的功能點?？梢赃\用“我是一個(某角色，如應用架構師)，我想做(某功能)來幫助我實現(某目標)”的模式進行場景設計。如此設計測試場景，測試人員將從客戶的角度出發，去分析客戶的目標及功能需求，使其更容易發現可用性方面的問題。

　　實踐二：觀察法

　　可用性測試的執行也與普通的功能性測試不同。對功能性測試來說，對功能熟悉的測試人員更容易發現和定位問題;而對于可用性測試來說，問題反而被新用戶發現。因此建議在可用性測試中，測試人員可以互換測試模塊進行測試 , 扮演不同的 Persona 去進行測試。在執行測試時，應參照上文提到的測試范圍，還要考慮一下幾個方面：

　　效率 – 用戶要花多少時間，多少個步驟才能完成一個任務。比如注冊用戶，查找一篇文檔。

　　準確 – 在操作的執行過程中，用戶犯了多少錯?測試人員要時刻記住，用戶在使用產品中犯錯，是設計人員的錯，而不是用戶的錯。

　　無需記憶性 – 用戶第一次使用是否能容易的使用產品?或者用戶多長時間不用后，還能記得如何操作產品?好的產品設計是無需用戶記憶，一切使用規則是隱含在設計中。

　　情感反映 – 用戶完成任務后的感覺是什么?是放松，還是緊張，該用戶是否會推薦產品給用戶。用戶使用產品，就猶如和設計師對話，好的設計師處處為用戶考慮，用戶使用完產品后會很放松甚至興奮，會迫不及待的推薦產品給其他用戶。

　　從心理學的角度看，人都有歸咎于自己的心理傾向。這會給可用性測試帶來很大的影響。當測試人員發現操作錯誤時，容易懷疑是自己操作不當而忽略了其中隱含的可用性問題，其中的問題可能是設計的不合理而使誤導用戶，文檔不夠等等。為了避免這樣的問題，本文推薦使用一人執行另外一人觀察的方法，就是一人進行操作，執行測試，另外一個人觀察其操作時的表現，尤其是情感反映。一個可用性優秀的產品，在用戶使用的過程中應該非常輕松得手，完成任務后應該是放松而不是緊張。

　　實踐三：可用性問題管理最佳實踐

　　軟件產品的可用性問題是指在可用性測試過程中發現的各種各樣的問題，有些問題是軟件產品功能相關的問題甚至是軟件缺陷，有些則是用戶體驗相關的問題?？捎眯詥栴}的管理主要是指如何高效的管理測試過程中發現的可用性問題，并結合軟件產品整體質量來維護和提升軟件產品的全方位用戶體驗。

　　可用性問題的管理主要包括可用性問題的分類和處置流程。

　　可用性問題的分類大致分類如下 , 從而有效的對相關問題進行分析和選擇處置方案 .

　　潛規則 (特殊用法或默認值類等)

　　不連貫 (如生成的項目卻沒有生成足夠的默認文件或 jar 包等)

　　易用性 (如常用的功能不在最容易發現的位置等)

　　其他

　　可用性問題的管理可以依據下圖所示的流程 , 從而和軟件產品質量的全面管理形成有效的集成。

原文轉自：http://www.uml.org.cn/Test/201007084.asp