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

　　程序員有時候會有意引入不一致性來對程序進行優化。的確很吸引人，但是也要注意優化所帶來的風險和一些優化的必要性：保存一兩次按鍵操作是否與學習時間的增加或信任度的減少價值相當?未必。

　　――不一致的縮寫

　　如果沒有很明確的縮寫規則，縮寫就不能容易地被記住。把Delete縮寫為Del，把Grep縮寫為Grep，是沒有任何意義的。

　　――不一致的終止規則

　　程序應該為多重鍵錄入要求終結符。

　　――不一致的命令選項

　　如果一個選項對兩個或者更多的命令有意義，那么它就應該對這些命令都可用(都不可用)，它應該具有同樣的名稱，并且應該在兩種情況下以同樣的順序被調用。

　　――名稱相似的命令

　　如果兩個命令名稱相似，就很容易搞混。盡量不要使用相似的名稱命名命令。這個問題在中文界面的軟件中表現得尤為突出。

　　――不一致的大寫

　　如果命令錄入是區分大小寫的，所有命令的第一個字符都應該使用大寫(小寫)。命令中嵌入單詞的第一個字符應該一直大寫(小寫)。另外，如非必要，不要在一個命令中使用多國語言。

　　――不一致的菜單位置

　　如果同一命令在不同子菜單中出現，那么要在不同菜單的同一位置保留同一命令是很困難的。這句話不是很好理解，不過把話說白了就好理解很多：要保持命令在同一子菜單中的位置，而不是讓它東搬西遷在其他的子菜單中停留。

　　――不一致的功能鍵用途與其說明

　　功能鍵的意義在程序中應始終保持一致(顛倒或是功能沖突是不能接受的)。

　　――不一致的錯誤處理規則

　　當程序檢測到一個錯誤之后，它可能會公布該錯誤，或者嘗試更正錯誤。任何一個程序的行為都應該是可預測的。如果當提交錯誤數據時沒有任何的提示或嘗試更正錯誤的說明，那么用戶就無法確認數據是否是干凈的。

　　――不一致的編輯規則

　　當你輸入或稍后檢查任何數據時，同樣的鍵和命令應該可以用來對其進行修改。

　　――不一致的數據保存規則

　　應該在每處都以同樣的方式，在同樣的時間和范圍內保存數據。它不應該在每個區域輸入數據時保存數據，而其他時間則在一個記錄、一組記錄的末尾保存數據，或恰好在退出前保存數據。

　　――浪費時間

　　看起來為了浪費時間而進行的設計會激怒每個人，應該把時間花在更有意義的事情上去。

　　――曲折路徑

　　如果為了到達想要的命令，你必須一個接一個做出選擇。結果到最后發現，該命令不存在、不能實現或者要求你先完成某件事甚至幾件事后才能使用――明顯 的欺詐行為!相信客戶的不滿和你(測試人員)的不滿幾乎沒有任何區別。舉個例子說：當用戶辛辛苦苦填滿了整整一頁的數據，最后提交時發現：該頁數據中的某 項已經被使用了時，用戶的焦躁可想而知。

　　――不能采用的選擇

　　事實上沒有任何接口在一個不能建立的菜單中包含選擇項。如果沒有任何數據存在，你如何評審、保存和擦除數據?沒有打印機，如何打印文檔?有的命令不 適合出現在某些條件下(雖然對使用沒有什么影響)，但是開發人員可能為了圖方便而保留了此類命令(很遺憾地說：這太不專業了);有時候，程序會提示尋求幫 助，而當你真的去使用的時候，程序卻告訴你“您沒有使用幫助的權限”――面對可望而不可及的東西，很多人寧愿選擇不去看見。這種情況很常見，至于常常被開 發人員和測試人員共同忽略――但這是不應該存在的錯誤。

　　――你真的，真的確定么?

　　嚴重毀壞數據的命令需要這樣重復的確認。是的，這是必須的，如：對一個寫滿數據的硬盤進行格式化的確需要多次確認。但是沒有必要對每個細小的刪除操 作進行繁復的確認操作，用戶會變得不耐煩，其結果有可能是：當用戶真的在進行嚴重毀壞性命令時，無視屏幕提示，造成不可預計的后果。

　　――模糊不清或者帶有個人風格的命令

　　命令名應該明確指示該命令的作用。不要讓用戶一邊使用軟件，一邊查詢用戶手冊中關于該命令的解釋。調查表明：大多數用戶在使用軟件產品的時候只對軟 件手冊做大概的了解，甚至根本不閱讀。別指望用戶會很完整地閱讀手冊，那是我們的工作。沒有任何理由在發布的程序中生成如：finger等帶有明顯個人風 格的命令，當然，如果在程序中出現了臟話，我希望(僅僅是希望)客戶沒有氣到火冒三丈。

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