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

　　分類原則。這點當界面上的信息多時，尤為重要。把所有信息分類，并把同類的信息顯示在一個區域，能非常方便用戶瀏覽信息。

　　差異性原則。用顏色和和字體體現不同的界面元素，如必選項用紅色標記，字體用粗體。顏色和心理學和公司或國家常規是相關的，否則會適得其反。

　　邏輯性原則。邏輯上兩種元素的結構關系，可以通過界面上的視覺結構體現出來。中的層次結構，如層次包含結構，在界面上應該用縮進、層級菜單等結構體現出來。

　　開發的可用性測試

　　開發規范可用性是在開發的過程中，開發人員編碼規范和編碼習慣的可用性。好的編碼機構清晰，讀起來毫不費力，是一種享受。開發規范可用性測試的范圍包括：程序代碼結構可用性，代碼格式可用性，注釋可用性，包結構和命名可用性，類名和方法名可用性，變量名可用性等。

　　代碼結構可用性在于開發人員不斷重構，把代碼按照邏輯結構分成不同的包。

　　代碼格式可用性一般可以通過編輯器的代碼模板和格式器來控制。

　　注釋可用性即符合 Java doc 或 .net 的注釋格式書寫注釋。

　　這里強調一點是命名的可用性，不管是包命名，類命名還是變量命名，命名時應該采用能夠讓人看懂的名字，名字長一些往往更好，盡量少用不清晰的縮寫。如：People 對象，應該用 “people” 等能夠一目了然的命名，而不是“p” 或 “pe” 等簡短不清晰的命名。

　　安裝的可用性測試

　　安裝現在是大多產品一個很大的問題，由于計算機業分工越來越細，一般來說一個產品很難單獨使用，需要其他一系列的產品輔助才行。這就造成了安裝上的極大困難，甚至出現幾天才能搭建一個環境的情況。安裝的可用性測試就是驗證產品安裝對用戶來說是否足夠簡單，包括：

　　安裝的操作簡單，盡量通過鼠標點擊就可以完成安裝;

　　安裝的說明準確并易于理解;

　　安裝過程中應有幫助說明，在用戶不明白的情況下給與足夠清晰的指導和說明;

　　安裝完盡量已經完成配置，免去用戶配置的復雜性;

　　安裝中有依賴其他軟件的，應給與提示，并可以提供所依賴軟件的安裝，或者提供足夠的安裝信息。

　　如果產品安裝非常簡單，在 1 分鐘內安裝完成后，環境也自動配置好了，包括所有所需軟件的環境，那肯定會受到用戶的好評。

　　配置的可用性測試

　　現在產品越來越多的配置，有基于 XML 的，基于 Property 文件的，基于編輯器的。配置帶來產品靈活性的同時，也帶來了可用性問題。配置的可用性測試是驗證產品配置對用戶來說是否足夠簡單易用，包括：

　　配置集中化?，F在產品配置步驟繁多，大都需要配置多個地方，多個文件，如果其中一個沒有配置就會導致所有的配置不起作用。建議能用一個配置，盡量不用兩個配置;能在一個文件，盡量不要分散在多個文件中。

　　配置向導化。配置也好，調整也罷，你需要告訴客戶都要做哪幾步配置，在哪里配置，怎么配置?，F在大多數的配置需要在成千上萬頁的文檔中查閱，然后一一對應，有時候配置的順序還有關系。建議如果有多步的配置，采用向導的方式，一步一步的指導用戶完成正確配置。

　　配置驗證性。用戶配置了許多的配置，配置完了，大多產品不給用戶足夠的反饋結果，提示配置是否出錯，出什么錯，哪里出錯。而需要用戶在運行環境按經驗去找錯，看 log, trace。結果好不容易找到了，興許也就是一個很小的大小寫的錯誤。用戶興許會想，都是自己不小心，怪自己疏忽。但作者認為這是設計開發人員的可用性錯誤，不注重可用性的今天，用戶幫著承擔了。建議：用戶的配置應及時甚至當場就提供給客戶反饋信息，提示用戶配置的結果，如果配置錯誤，應提供足夠的錯誤信息，哪里錯誤，出什么錯，有什么解決方法。

　　文檔的可用性測試

　　文檔的目的是讓人學會使用產品，可用性的最高境界莫過于連文檔都不需要了，如傻瓜相機，雖然也帶了文檔，但由于其易于操作，用戶無須知道光學原理，焦距，曝光就可以使用，而很少有人去查閱文檔。對于文檔的可用性測試，應該保證文檔盡量簡單易讀。下面是文檔可用性的幾個實踐：

　　能用視頻少用圖片，能用圖片少用字?，F在用 Flash 視頻教學是非常流行的一種教學方式，盡量多用一些 Flash 視頻的教學方式，如果沒有視頻，也盡量多一些圖片，產品截圖等。

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