軟體GUI測試中的關注點（二）

5、命令結構和錄入

這裡只處理實現中的缺陷。（即假定程式員對風格的選擇是合理的）

不一致性

增加永真規則的數量可以縮短學習時間，並減少文檔，而且使程式看上去更專業。不一致性如此的普遍，是因為它需要規劃並進行鬥爭來選擇能一直遵循的操作規則。每個微小的不一致性都是不重要的，但是一旦達到了一定量，一個本來構想很好的產品有可能會變得難以使用，甚至變成廢品。從開發人員本身來講，也體現出其開發本身的嚴密性。一個好的測試實踐要標註出所有發現的不一致性，無論多麼微不足道都要如此。

“最佳化”

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

――不一致的縮寫

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

――不一致的終止規則

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

――不一致的命令選項

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

――名稱相似的命令

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

――不一致的大寫

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

――不一致的菜單位置

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

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

功能鍵的意義在程式中應始終保持一致（顛倒或是功能衝突是不能接受的）。

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

當程式檢測到一個錯誤之後，它可能會公布該錯誤，或者嘗試更正錯誤。任何一個程式的行為都應該是可預測的。如果當提交錯誤資料時沒有任何的提示或嘗試更正錯誤的說明，那麼使用者就無法確認資料是否是乾淨的。

――不一致的編輯規則

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

――不一致的資料儲存規則

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

――浪費時間

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

――曲折路徑

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

――不能採用的選擇

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

――你真的，真的確定嗎？

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

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

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

菜單

菜單應該盡量簡潔，當存在了太多風格不一，冗長和拙劣的表徵圖或命令名，以及當選擇隱藏在不明顯的主題之下的子項時，理解它們將會變得非常複雜。一個菜單覆蓋的命令越多，無論如何規劃，都會變得複雜，如果沒有良好的規劃，這對使用者的使用將是一大障礙。

――過於複雜的菜單層次

如果必須在最後到達你想要的命令之前很吃力地通過一個又一個菜單，那麼我想我會選擇使用另外一個功能相近的程式。建立深層菜單樹的程式員所引用的設計規則表明，沒有哪個菜單應該具有七個以上的選項，這一點對新手來說可能時最好的。有經驗的使用者更傾向於每個菜單層級有更多選擇，犯更少錯誤並更快速有效做出反應，只要選項能合理組織，整齊排版，而且沒有可笑的擁擠或拼字錯誤就行了。

－不適當的菜單導航系統

即使在一個最適當的深層菜單系統中，你也必須能夠返回到前一菜單，或者移到菜單結構的頂層，並能在任何時刻離開程式。

――太多重路徑到達相同位置

如果許多命令在菜單中重複出現，那麼程式就需要重新組織。讓一個命令在不同位置重複可能會很便捷，但是存在一定的限制。如果感覺上你可以從程式的任何位置到達另一個任意位置――那就得重新考慮下程式的內部結構和可靠性。

――相關的命令被歸屬到不相關的菜單

把一個複雜菜單中對命令或主題進行分組並不是一件容易的事情。人們都很容易忽視兩項之間明顯關係，並把它們分配到分開的菜單中去，當需要對此進行調整時，我們需要做的是：解釋兩項之間的關係，並建議兩者都應屬於哪個菜單。

――不相關命令被放置到同一菜單下

有些命令被扔到了完全無關的菜單下，這樣並不好，寧可重新選擇一個更進階別的標題並重新組織這些命令也不要那麼做――如果那樣做導致的混亂比較嚴重的話。

――鍵盤不能正確使用

不能正確使用鍵盤無論在何時都是一個問題。

――無法使用編輯按鍵或功能鍵

如果一個程式從某些其他沒有這些鍵的機器上移植過來，那沒關係。相反可能就不行。要確保程式可以使用已有的編輯按鍵和功能鍵。

――游標和編輯按鍵的非標準使用

這些鍵應該按照他們通常在該機器上工作的方式進行工作，而不是按照他們通常在其他某個機器上工作的方式來工作。

――功能鍵的非標準使用

如果大多數程式用F1作為協助鍵，那麼如果在程式中將它定義為其他的功能，那將是不合適的。

――不能過濾無效鍵

程式應該能擋住並拋棄無效字元，比如進行數字相加時輸入的字母。它不應該做出回應。與錯誤訊息相比，這樣做更快更有效。

――未能指示鍵盤狀態的改變。

鍵盤上的燈或螢幕資訊應該告訴你何時你的Num Lock鍵和其他類似的狀態轉換特徵是開著的。

――未能掃描功能鍵或快速鍵

你應該能夠告訴電腦從它進行中的工作中退出；程式應該總是能辨別出任何其他系統指定的鍵――即那些本機上的程式通常可以很快識別出來的鍵。

6、遺漏的命令

1）狀態轉換

大多數程式從一個狀態轉到另一個狀態，在你選擇某個功能表項目或者提交一個命令之前，程式處於某種狀態。為了回應你的選擇，程式回到另一個狀態。程式員通常會對他們的代碼進行足夠的測試，以確保你能達到任何你應該可以達到的狀態。

――什麼都不作就退出（狀態返回）

你應該能夠告訴應用程式，你做出的最後一個選擇有誤，並返回到其前一個狀態。

――不能在程式中間退出

當使用一個程式但還沒有對儲存的資料造成不利影響時，你應該能夠從中退出；如果你正在編輯的檔案出現了預想不到的錯誤，在中止後應能回到先前儲存過的狀態。

――不能在命令中間停止

告訴程式停止一個命令很容易，而返回到起始點或選擇一個其他的命令也應該不太難。如果其中任何一個方面出現了問題，就需要重新考量先前的設計是否真的合理了。

――不能暫停

如果程式限定了你輸入的時間，時間一到，狀態就改變，那麼當你離開時你就需要它暫停一會兒。這中類型的情況在遊戲軟體中見得較多，比如說暫停遊戲。

2）危機預防

系統故障和使用者錯誤發生了，程式應具備將其後果降到最低的能力。

――沒有備份工具

對開發人員而言，為了一個檔案做一個額外備份應該不是一件困難的事。如果你正在修改一個檔案，電腦應當保留原始版本的一個副本，因此如果你的更改有錯誤，還能返回到一個已知的好的版本。

――不能撤銷

撤銷一個你已經發出的編輯命令，至少是一步。恢複被刪除的檔案是一種受限制的撤銷，它能讓你恢複錯誤刪除的資料。撤銷是可取的，恢複被刪除檔案也應是必須的。

――沒有“你確定嗎？“的提示

提交一個大量資料清除的工作，或者提出一個清除少量資料但是會影響其他作業的命令或者很容易錯誤提交的命令，都需要程式在使用者操作時進行確認，不聲不響地進行將會帶來安全方面的隱患（尤其是在後台進行暗箱操作時，這種危險性更高）。

――沒有增量儲存

當輸入大量文本或資料時，你應該能告訴程式相隔一定時間對你的工作進行儲存，至少應該提供使用者此類選項。對於突發的掉電和硬體損壞情況這樣做將是非常有好處的。

3）由使用者進行的錯誤處理

人們可以捕獲自己的錯誤，而經驗告訴我們，他們還容易犯其他的錯誤。他們應能自理修複錯誤，並建立自己的錯誤檢查機制。

――沒有使用者能指定的過濾器

當設計資料錄入表格和試算表模板時，你應該能夠讓每個地區指定什麼樣的資料類型有效、程式應忽略或拒絕什麼。例如，你可以讓程式拒絕數字、字母、不在某個特定範圍內的數值，一個有效日期或者與磁碟上匹配的日期等等。

――難用的錯誤更正

修改一個錯誤應該很容易。不應該因為犯了錯誤的資料錄入而讓整個系統重新啟動。在輸入一串資料時，你應該能在不重新輸入剩餘部分的情況下，更正錯誤的資料。

――不能包括注釋

當設計資料錄入表格，電子模板，專家系統時，你應該能夠為未來參考和調試輸入注釋資訊，這是很必要的。

――不能顯示變數之間的關係

錄入表格、電子模板中有些變數是相互關聯的，應該能很容易的檢查任意變數對其他變數的依賴性。這在設計時應該被周密考慮到。在大多數的財務管理系統中，這類應用是較普遍的。

4）其他問題

――隱私和安全性

對於某些特定的程式，需要考慮資料的充分安全性，保護公司，集體或個人的機密和隱私。在多使用者系統上，你應該能很好的隱藏你的檔案（一般都是通過加密手段實現的），並且能很好的鎖定你的檔案不被篡改或閱讀。

――安全性的困擾

一個程式的安全性控制應儘可能謹慎考慮與實施。

――隱藏菜單

很多程式在頂端、底部或螢幕邊緣顯示一個菜單（包括我以前測試的大多數應用程式）。它們使用螢幕的剩餘部分作為資料錄入和處理的地區。菜單只是記憶的輔助物。一旦使用者瞭解了他所需要的所有命令後，就應該給予使用者充分的自由，讓其選擇是否需要保留菜單的權力。

――不支援標準O/S特徵

例如：如果系統使用了子目錄，那麼程式就應該能引用其他子目錄。如果作業系統提供了萬用字元（比如*），那麼程式也應該能使用。

――不允許長名稱

應當允許使用長名稱（只要不是太離譜），畢竟，記憶體不足和編譯器反應遲鈍的時代已經成為過去了。別讓自己的程式也成了文物。

7、程式僵化

程式有靈活與固定之分。靈活的程式更顯個人化一些，而固定僵化的程式一般都是由於商務程序的關係而不得不如此。如借還書的過程，必先借了才能還。別給使用者太多的自由，否則程式看起來會讓人覺得鬆散，也不要把程式定得死死的，那看上去給人太多壓力了。

1）使用者可調整性

――不能關掉噪音

犯錯誤時，許多程式都會給出“咄”的警告聲。而如果每次接觸鍵盤都發聲，這簡直是不能容忍的――特別是在公用場所。必須關閉沒有必要的噪音，至少程式要提供這類控制選項。

――不能關閉大小寫區分

一個能區分大小寫系統應該允許你告訴它忽略大小寫問題。

――不能配合手邊的硬體

有些程式被鎖定針對了特定的輸入輸出程式。升級或更換了裝置的使用者可能就無法使用這些功能了。這是令人遺憾的。同時，也會讓使用者覺得是否是一種商業捆綁的模式而拒絕使用此產品。盡量讓開發人員編寫通用的硬體介面代碼以適應大部分通用的硬體裝置。

――不能改變裝置初始化

一個應用程式應該能夠發送使用者定義的初始狀態，或者至少應該讓它保持現狀。每次啟動都需要重新設定將會是很煩人的工作。假定你想要向一個印表機發送控制碼，以轉換到壓縮字元，如果列印資料的程式不讓你初始化印表機，你就不得不從裝置來改變印表機的模式和狀態，然後重新運行程式。如果程式阻撓了你的印表機設定，那就是一個設計錯誤。

――不能關閉自動儲存

自動儲存是件好事，不過無事生非也是一件糟糕的事情。過於頻繁的自動儲存可能會讓使用者覺得程式不可靠。所以還是老老實實加上關閉自動儲存的選項吧。

――不能改變捲動速度

嚴格來說，這不是一個很嚴重的問題。目前很多的裝置驅動中已經提供了此類選項。

――不能重複上次的操作

這樣的例子比如Word軟體中的Redo。

――無法找到你上次完成的內容

此類問題對資料編輯特別是文本編輯類的程式較為常見。應當提供儲存的檔案清單，除非使用者禁止了它。

――無法執行一個定製的命令

在程式選項中，一旦對其更改，應該立即生效，不需要再次重新啟動程式進行載入――特殊情況除外（如果你無法避免）。

――無法儲存定製的命令

你不應該只告訴程式此次運行關閉了警告聲，而是應該讓程式永遠可以關閉這些――只要設定沒有發生變化。

――特徵更改的副作用

這種情況較常見，修改了某一個特徵，相關的特徵也會改變。如果確實存在副作用，應當在手冊和螢幕中提供詳實的文檔證明和提示。

――無限可調整性

開發人員可以改變某些程式的方方面面。但是在開篇時說過，提供了太多靈活性的程式並非一直都是一件好事。好好斟酌再做決定要比草率地修改來得更好。

2）控制方式

有些程式很“霸道”。它們的錯誤資訊和協助訊息自認為高人一等，它們的風格不可原諒的不便――你甚至無法放棄命令或者在輸入資料後變更。程式應該使你覺得能更容易，更愜意地完成一個任務。至少，它不應該浪費你的時間。

――一個概念風格的不必要和不合理要求

有些程式要求你以某種順序輸入資料，或要求你在進行下一步之前先完成某項任務，再要麼就要求你再考慮它們的潛在後果之前做出決定。例如：

當設計一種資料錄入格式時，為何你必須再螢幕顯示之前確定一個資料錄入域的名稱，類型，寬度或者計算順序？當你察覺不同的域放在一起看起來有神麼不妥的時候，你是否會更改某些域，把它們的位置換來換去，甚至去掉少數域？你可能不得不在使用該格式之前輸入欄位的規格說明，但是在該約束條件下，你應該決定何時填充細節。

當向一個專案管理系統描述任務時，為何你必須首先列出所有的任務，然後列出說有可用的人員，接著在為下一項工作輸入任何資料之前就把分配給某個人的工作完全對應？既然你可能試著決定什麼工作分配給什麼人，那麼你不想看到結果後再更改這些資料嗎？

限制的數量如此多，是因為有些開發人員認為，人們應該以某種方式組織它們的工作。但是他們所想的最佳途徑未必都是最佳的。我們應該更清醒地意識到，除了商務程序上的禁錮，不需要再對使用者在風格上多加任何的限制――當然，如果使用者需要的話。

――對新手友好，但是對老手並不一定友好

為初學者設計的進行過最佳化的過程可能為他們掌握系統會有協助，但是同時會令一些有經驗的老手帶來煩惱。他們更希望能自由地使用軟體；其中一個解決辦法就是提供兩條以上地路徑實現對不同層次使用者的需求。

――人工智慧與自動化

有些更智能和更便利的程式會猜測你的下一步動作，並枉加執行這些猜測；自動錯誤修正的程式的確很好，除非它“糾正”了正確的資料。而有時候，使用者並不一定希望這樣做。提供可用的選項可以緩衝一下這方面的矛盾。

――過剩或多餘的必需資訊

過剩和多餘的必需資訊就像我們身上的贅肉一樣討厭。有些程式會請求他們從來不會使用或者只會用來在螢幕上顯示一次的資訊，或者會要求你重新輸入你已經輸入過的資料――並非是為了驗證，僅僅只是重新擷取一次資料，這對時間的浪費是非常驚人的。

――不必要的步驟重複

如果你在輸入一個較長的命令步驟或資料時犯了一個錯誤，有些程式就不管青紅皂白讓你重新輸入；有的程式則強迫你重新輸入或確定可能有錯誤的任何命令。為了某些任務，你甚至可能需要確認每個步驟。相信我：不必要的重複或確認都是浪費時間。

――不必要的限制

為什麼要把一個資料庫限定為如此多的欄位或記錄，或限制一個試算表僅使用數字，把一個專案經理限制在如此多的任務中，一個文書處理程式限制在如此多的字元呢？對效能或可靠性而言並非必要的限制不應該成為約束條件。

8、效能

許多有經驗的使用者認為效能是最重要的可用性因素：使用一個快速程式，他們感到更能集中精神工作，而且更多的東西處在掌握之中。在極少出現異常的情況下，程式越快越好。

效能有很多定義，大致來說主要有如下的感性認識：

程式速度：執行標準任務的速度有多快？

使用者輸送量：你能使用程式執行標準任務的速度有多快？

感覺到的效能：在使用者看來，該程式速度有多塊？它是否令你滿意？

無論如何定義，程式速度總是一個關鍵因素。但是一個介面設計拙劣的快速程式無論怎麼看都要比它實際的運行和處理速度要慢得多。

1）降低程式速度

很多設計和代碼錯誤會降低一個程式的執行錯誤。程式可能會執行很多不必要的工作，如對一個在讀前會被重寫的記憶體地區進行初始化；也可能會對工作進行不必要的重複，如在一個在迴圈中執行的任務可以在迴圈外完成；設計的決策也會影響到程式的速度，而且通常要比明顯錯誤導致的慢速情況更加嚴重。

2）緩慢回應

程式應立即對輸入做出響應，如果在你輸入一個字母的時刻和你看到這個字母的時刻有延遲，顯然，程式就太慢了。快速反饋對任何輸入事件都必須是有效而且是必要的，它包括：滑鼠，鍵盤，軌跡球，鍵盤等等。

3）如何減少使用者輸送量

一個閃電般快的程式執行任務時可能比蝸牛還要慢。這包括：

任何可能使使用者錯誤更可能發生的事情。（培訓不周，使用者習慣，程式風格等等）

緩慢的錯誤恢複。如：在輸入一長串字元後發現錯誤卻必須要重新輸入。

任何使你感到迷惑，卻得不到協助文檔或手冊提供資料的事情。

輸入很多，卻做得很少的程式――這不是一個好程式。如：把一個簡單任務劃分成很小的子任務，要求對所有事情進行確認等等。

在測試時，使用比較性測試是個有效方法：即把開發中的產品與競爭者的產品進行比較，如果人們使用你的產品花費的時間要更長，那麼發現這個問題就是有意義的。

4）反應拙劣

我曾經測試過一個產品，在輸入第一條資料後，居然花了將近一分鐘才從資料庫中將資料取回。這不能不說是一個反應很慢的程式。一份表單做下來將近300條資料，按此速度計算，我將花上至少半天才能完成輸入。這種情況是不能允許的。迅速地對輸入做出回應是一個程式最最基本的功能。一個反應迅速的程式不會強迫你在提交下一個命令之前讓你持續等待，而是讓你繼續做其他事。

5）沒有提前輸入

一個允許提前輸入的程式會讓你在它從事其他工作的時候仍然可以鍵入，它會記住輸入內容，加以顯示並在稍後進行處理。你不應該等著輸入下一個命令。

6）沒有給出某個操作會花很長時間的警告

如果程度需要超過幾秒鐘的時間來進行某事，程式應該告知使用者。對於較長時間的任務，它應該給你一個大概的時間印象而不是讓你乾等著它結束。給出大致需要完成的時間或是進度條是處理此類問題一般的方法。

7）程式太多提示和詢問

提示，警告以及詢問可能很有用，不過如果它們出現得太頻繁，就會讓人很窩火。

8）盡量使用簡單命令和提示

在慢速終端上，協助文本，長菜單以及漂亮的圖片常常會令人不耐煩。你應該使用簡要的語言取而代之。不要使用諸如“你真的想以500k/s的速度傳送此郵件到某郵箱”麼之類羅嗦的語句。