軟件GUI測試中的關注點(2)

　　6)功能性必須由用戶創建

　　最常見的情況之一就是要求用戶自己配置軟環境(如配置數據源，一般都可以在安裝程序中自動完成;當然還包括程序用到的組件在系統中不存在，安裝程序 沒有提供相應的支持，這對用戶是不能接受的)。這類問題不完全一定都是錯誤，比如微軟提供的Office宏的開發，是為了滿足客戶對于自身特色而設計的適 合其專業工作的程序。

　　7)不能做用戶期望的工作

　　例如，極少有人會期望一個本來編寫用來對姓名進行排序的程序卻按照ASCII碼的順序排序。他們也不會指望用它來計算首位空格或區分大小寫。當然用戶名的排序還是要做的，問題是開發者需要重新構想一個新的排序規則來滿足用戶需求。

　　· 人機交互

　　人機交互，程序與操作者之間的通信與交流。這不是早些年的科幻電影，我們也許每天都在做，在取款機前，在自動售賣機前。

　　1)遺漏信息

　　你應該知道，所有的事都能從計算機屏幕上得到有效的消息。不要遺漏任何對于用戶而言至關重要的信息，即使這些信息對你而言毫無用處。

　　――沒有任何屏幕指令

　　如何找到程序的名稱?如何退出程序?你應該怎么樣獲取幫助?如果程序使用了某種命令語言，如何才能得到命令列表?程序可能僅僅只在它啟動時顯示這些 內容。當然你也可以從幫助手冊中獲取這些信息，但并不是必要的。沒有任何屏幕指令的程序可能會讓人受不了，查詢手冊的話需要花費的時間可能會更長，也可能 就會讓用戶覺得軟件學習起來太復雜了。

　　――假定打印出的文件隨時可得

　　丟了用戶手冊怎么辦?有經驗的用戶不會非要依賴打印好的文檔，提供一份電子版的吧。

　　――無正式文字證明(說明)的功能特征

　　如果大多數的功能特征或命令在屏幕上提供文字說明，那么所有的都應如此。僅略過幾個功能特征將會導致UI形式上的混亂。同樣，如果程序為很多命令描 述其“特殊情況”下的行為，那么所有的命令都需要提供這類說明。這種情況在國人的軟件開發過程中時有發生，并不是不能，而是不想……

　　――看起來不可能退出的狀態

　　如何取消一條命令或在一個深層菜單樹中進行備份?程序應該允許你可以避免那些你不希望遇到的情況。比如，在軟件安裝時，要求插入磁盤，如果不插入正確磁盤就不能退出安裝程序。沒有告訴你如何避免就和發生災難時，沒有提供一條逃生路徑一樣糟糕。

　　――沒有光標

　　大多數用戶都依賴于光標。一個光標可以讓用戶覺得計算機仍然在正常運轉(盡管有時候死機也是如此)，每個交互程序都應該顯示光標，當然，在關閉光標時別忘了提醒用戶注意。

　　――沒有對輸入做出響應

　　每個程序都應該對輸入做出回應。如果沒有，呵呵，保管80%以上的用戶產生疑問：怎么沒有響應?還要等多久?是不是我的電腦過時了?

　　如果有以下幾種情況，一般視為正常：

　　選擇一個菜單項時，如果你的按鍵操作沒有回應，只要下一個屏幕立刻出現并且此屏幕上的標題與菜單項一樣，就可以視為正常。

　　如果程序忽視錯誤的命令或按鍵操作，當然可以不對其進行回應。

　　如果你告訴程序不要對輸入回應，它必須沉默，如果它進行了回應，應該立即告訴開發人員對其進行修改(可能是在忘記了繼續處理另一種情況)。

　　如果輸入的是安全性代碼(如密碼等)，那么程序決不應在屏幕上做出不恰當的回應(如顯示你輸入的密碼明文)。

　　――在長期延遲時沒有表示其活動

　　給一段較長時間的程序延遲一個合適的響應，將是非常必要的舉動。相信這樣不需要再給用戶做出過多的解釋了。

　　――當某個改變即將生效時沒有給出建議

　　一個程序可能會比你預計的更早或更晚執行一個命令，例如：刪除某些重要數據時，(而這個過程將持續一段時間)，必要的提示是必須的。

　　――沒有對已經打開的文件進行檢查

　　這個錯誤是非常常見的，尤其對于那些輸入關鍵數據的程序而言。用戶可能不會注意，但是在以后的工作中將發現略微的一絲更改就會引出大量的問題。你不 能保證程序會對同一個文件在某個時刻做出不同修改所帶來的后果。所以，決不允許同一文件同時被打開兩次甚至更多，以確保程序輸出的唯一性。

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