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

　　例如，某軟件產品的核心初始化模塊需要開發一個配置文件內容的引用功能。我們如何來以用戶為中心設計一個有價值的場景吶?

　　第一步，我們將該功能的用戶進行區分，發現該功能非常具體且細化，而與此功能有實際聯系意義的用戶主要是基于此軟件進行二次開發的軟件開發技術人員和軟件生產環境下的運營維護人員?；趯τ脩舴诸惖亩x，發現他們分別屬于最終用戶和合作用戶。所以，通過結合軟件二次開發技術人員的視角，我們得出第一步的結論：使用該產品的二次開發的技術人員可以在系統初始化過程中使用配置文件的引入功能，將其他的配置信息引入到主配置文件之中;通過結合運營維護人員的視角，我們得出第一步結論：使用該產品的運營維護人員可以在系統初始化過程中使用配置文件的引入功能，將其他的配置信息引入到主配置文件之中。

　　第二步，明確指出該用戶場景分別能夠給他們帶來的價值。通過結合軟件二次開發技術人員的視角，我們得出第二步的結論：使用該產品的二次開發的技術人員可以在系統初始化過程中使用配置文件的引入功能，將其他的配置信息引入到主配置文件之中，最有效地實現配置信息的復用，避免配置信息的重復使用，提高組件的模塊化，并且不會對初始化過程產生性能影響。通過結合運營維護人員的視角，我們得出第二步結論：使用該產品的運營維護人員可以在系統初始化過程中使用配置文件的引入功能，將其他的配置信息引入到主配置文件之中，實現配置文件的分級分層管理，避免大量配置信息在單一文件中的堆積，優化配置文件的管理效率。

　　可用性測試的范圍

　　在實際的軟件開發過程中，測試人員是產品的第一個使用者，可用性測試包括從需求調研到產品設計開發到文檔和安裝等多個環節。這小節作者介紹可用性測試的范圍，并根據所參與產品 (WebSphere Multi-channel Bank Transformation Toolkit , BTT) 開發過程中的一些實踐所得和體會，介紹軟件可用性測試包含哪些方面以及內容。

　　作者從從四個方面介紹可用性測試：需求的可用性測試，設計的可用性測試，開發的可用性測試，安裝的可用性測試，配置的可用性測試，以及文檔的可用性測試。

　　需求的可用性測試

　　作者認為需求的可用性是最重要的一項，因為這是后面所有其他可用性的前提。沒有正確的需求，就猶如路和方向就是錯誤的，那盡管在這條路上走的多好，多穩，也不會通向理想的目的地。所以，可用性測試就是要注重 Identifying the right product，也強調 outside-in development。做正確的事情，說起來簡單，但做起來是最為困難和艱險的一件差事。在這里一步走錯，就會導致整個產品全盤皆輸，因為產品定位和需求都錯了，那再如何努力開發和測試也是枉然的。

　　設計的可用性測試

　　設計的可用性包括架構和設計的可用性以及界面設計的可用性。架構和設計可用性是指架構和設計方法的邏輯性和合理性，并且是否符合主流的架構模式和設計模式。良好的架構，應該是采用標準，結構清晰，一目了然，并層次分明的。架構邏輯性、層次性依賴于架構師的功力，業內有一些最佳實踐和標準，是值得大家去遵循。

　　界面設計可用性是指系統和用戶進行很好的交互。根據作者經驗，界面設計的可用性測試至少要驗證系統符合下面這些點：

　　信息清晰原則。盡量少用縮寫，除非你的縮寫已經眾人皆知，比如像 PPT 這樣的詞語。但像 VC=Verification Code，這樣的縮寫應盡量避免。

　　可視性的設計原則。用戶界面的操作盡量讓人一看就知道如何操作，而不用記憶或查閱文檔。如，界面中隱含操作順序而不用用戶牢記;用星號標記出必選項等。產品界面是否好用用戶第一次使用，或者用戶很長時間不使用后重新使用，他是否能夠很方便的進行使用很關鍵。好的設計無需用戶記憶，在設計中隱含著可視性的提示，便于用戶完成操作。

　　限制性原則。盡量限制在界面上的用戶錯誤操作。界面上應屏蔽用戶當時不能輸入的輸入框等，盡量不讓用戶操作會引起錯誤的界面元素。限制錯誤的操作，指示正確的操作，只給用戶一條正確的路，用戶就能無需去判斷錯誤，容易的完成操作。

　　反饋原則。反饋是控制科學和信息理論中的一個常用的概念， 其含義為： 向用戶提供信息， 使用戶知道其某一操作是否已經完成以及操作產生的結果。在界面設計時用戶輸入信息時，界面上應該能驗證輸入信息的正確性，并提供反饋信息給客戶。

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