黑盒測試常見錯誤類型及說明
使用者界面錯誤
1、功能性
2、易用性（使用者學習使用程式的時間和記住怎樣使用程式的時間）
3、執行速度（多數是啟動速度，查詢速度，重新整理速度及響應速度等）
4、使用者使用時産生錯誤的比率（在允許使用者任意使用的情況下，越低越好）
5、使用者滿意度（很大程度上決定UI設計及功能設計的好壞）
功能性
如果出現了以下情況之一，認為程式可能存在功能性錯誤：
程式可以完成的某些事進行得非常困難，笨拙（繁瑣），令人迷惑甚至難以忍受。
主要表現為以下幾個方面：
過度功能性
将簡單功能複雜化，這是設計上一個較常見的問題。嘗試進行太多工作任務的系統将很難學習和掌握，而且容易忘記。它要求大量的文檔（開發文檔，幫助文檔和螢幕）。性能相對可能會好些，但是複雜化所花費的時間相對于性能（功能）提高不值得；而且，若功能子產品間子產品緊密，則發生關聯錯誤的幾率要提高不少。
誇大的功能性印象：
使用者手冊和營銷傳單不能使程式功能實作得更多。記住，在使用者手冊中哪怕甯願對功能略微輕描淡寫也不能誇大其詞（當然，我們并不希望這樣，我們總是要如實地記錄）。
對手頭任務的不适當性：
由于功能關鍵事項不存在、太有限（多數是因為沒有完成）或者太慢（需要改程序式結構或是内部算法）而不能完成真正的工作。舉例來說，查詢一個有8000條記錄的資料庫需要1個小時（天哪，我想我連10分鐘都等不了），雖然說具備了查詢的功能，但是實在很懷疑此項功能是否會有人使用。
遺漏功能：
功能沒有實作，卻出現在了使用者手冊中。或者是本來應該具備地特征性功能，在程式隻能看到一個“影子”（有其名無其實）。多半情況下是由于需求變更時沒有對手冊進行檢查和更新，也有是因為遺漏了需求說明中應包含的功能。
錯誤功能：
一個本來應該完成查詢工作的功能卻幹了排序的活兒。這種疏忽一般不是因為沒有實作功能，而是在配置設定功能的時候出現了問題。
功能性必須由使用者建立：
最常見的情況之一就是要求使用者自己配置軟環境（如配置資料源，一般都可以在程式中自動完成；當然還包括程式用到的元件在系統中不存在，使用者還需要自己購買，這對使用者是不能接受的）。
不能做使用者期望的工作
例如，極少有人會期望一個本來編寫用來對姓名進行排序的程式卻按照ASCII碼的順序排序。他們也不會指望用它來計算首位空格或區分大小寫。當然使用者名的排序還是要做的，問題是開發者需要重新構想一個新的排序規則來滿足使用者需求。
人機互動（易用性）
人機互動，程式與操作者之間的通信與交流。這不是科幻電影，我們也許每天都要做，在取款機前，在自動售賣機前――
遺漏資訊
你應該知道，所有的事都能從計算機螢幕上得到有效的消息。
沒有任何螢幕指令
如何找到程式的名稱？如何退出程式？你應該怎麼樣擷取幫助？如果程式使用了某種指令語言，如何才能得到指令清單？程式可能僅僅隻在它啟動時顯示這些内容。當然你也可以從幫助手冊中擷取這些資訊，但并不是必要的。沒有任何螢幕指令的程式可能會讓人受不了，查詢手冊的話需要花費的時間可能會更長——這可能就會讓使用者覺得軟體學習起來太複雜了。
假定列印出的檔案随時可得
丢了使用者手冊怎麼辦？有經驗的使用者不會非要依賴列印好的文檔，提供一份電子版的吧。
無正式檔案證明（說明）的功能特征
如果大多數的功能特征或指令在螢幕上提供檔案說明，那麼所有的都應如此。僅略過幾個功能特征将會導緻混亂。同樣，如果程式為很多指令描述其“特殊情況”下的行為，那麼所有的指令都需要提供這類說明。
看起來不可能退出的狀态
如何取消一條指令或在一個深層菜單樹中進行備份？程式應該允許你可以避免那些你不希望遇到的情況。比如，在軟體安裝時，要求插入磁盤，如果不插入正确磁盤就不能退出安裝程式。沒有告訴你如何避免就和沒有提供一條逃逸路徑一樣糟糕。
沒有光标
大多數使用者都依賴與光标。一個光标可以讓使用者覺得計算機仍然在正常運轉（盡管有時候當機也是如此），每個互動程式都應該顯示光标，當然，在關閉光标時别忘了告訴使用者。
沒有對輸入做出響應
每個程式都應該對輸入做出回應。如果沒有，呵呵，保管80％以上的使用者會對軟體産生懷疑：怎麼沒有響應？還要等多久？
如果有以下幾種情況，一般視為正常：
1．選擇一個菜單項時，如果你的按鍵操作沒有回應，隻要下一個螢幕立刻出現并且此螢幕上的标題與菜單項那個一樣，就可以視為正常。
2．如果程式忽視錯誤的指令或按鍵操作，當然可以不對其進行回應。
3．如果你告訴程式不要對輸入回應，它必須不回應，如果它進行了回應，應該告訴開發人員：嘿，看那，它不聽話（可能是在忘記了繼續處理另一種情況）。
4．如果輸入的是安全性代碼（如密碼等），那麼程式決不應在螢幕上做出回應（如果你輸入錯誤則是另外一回事）。
在長期延遲時沒有表示其活動
給一段較長時間的程式延遲一個合适的響應，将是非常必要的舉動。相信這樣不需要再給使用者做出過多的解釋了。
當某個改變即将生效時沒有給出建議
一個程式可能會比你預計的更早或更晚執行一個指令，例如：删除某些重要資料時，（而這個過程将持續一段時間），必要的提示是必須的。
沒有對已經打開的檔案進行檢查
據統計，這個錯誤是非常常見的。使用者可能不會注意，但是在以後的工作中将發現略微的一絲更改就會引出大量的問題。你不能保證程式會對同一個檔案在某個時刻做出不同修改所帶來的後果。是以，決不允許同一檔案同時被打開兩次甚至更多。
錯誤的、誤導的或令人迷惑的資訊
每個錯誤都會讓你對程式顯示的所有其他東西産生懷疑。使使用者做出虛假歸納的細小錯誤，如遺漏條件或是不适宜的類比會比清楚的事實錯誤更讓測試人員感到惱火――因為更難對它們進行改正。
1．簡單的事實錯誤
在一個程式改變之後，更新螢幕顯示是低優先級任務，結果則是：螢幕上大量的資訊過時。記住：無論何時程式發生改變，都要仔細檢查可能訓示程式特征的每個消息，最簡單的辦法就是直接對更改後的螢幕進行重新整理。
2．拼寫錯誤（錯别字）
我相信，這絕對不是設計上的問題，我也相信開發人員可能會不以為然。Oh，但是客戶會在乎，會抱怨這些的――還是改正它們吧。
3．不準确的簡化
在保持一個特征的描述盡可能簡單的願望中，一條消息的創作者可能隻覆寫特征行為的最簡單方面，而忽略了重要條件。舉例來說，這種情況可能會引發歧義，比如說關閉（到底是關閉檔案還是關閉程式？）。作為一個測試人員，需要你足夠仔細的研究可能會出現問題的任何一個微不足道的細節。甯可錯殺，不能放過！（雖然要極力避免錯殺的情況。）
4．無效的比喻（圖示之類可以訓示功能特征的事物）
例如：資源回收筒的圖示可能不是一個好的比喻；對于檔案一旦移除就永久消失的情況來說，碎紙機的圖示可能來得更好一些。
5．令人迷惑不解的特征（功能）名稱
如果一個指令名稱在計算機領域中或語言中有一個标準含義，就必須與其含義一緻。别指望着胳膊能擰得過大腿，确定現行的标準是可靠的。
6．同一特征（功能）具有多個名稱
相同的功能特征隻要一個名稱就夠了――隻要能表述清楚；使用者可不一定有時間玩同義詞的遊戲。另外，這種情況對軟體在使用者面前顯示的複雜度也有影響。
7．資訊超載
不要讓你的文檔和幫助螢幕看起來太專業――太多技術細節了。使用者會不耐煩的，況且效果也不好。如果實在需要，可以把他們另外列出。盡量使用直白，使用者能明白的話表述這些資訊。
8．資料何時得到儲存
假設你輸入了一些程式需要儲存的資訊。當你進行切換或程式退出時，當你需要每隔一段時間進行儲存時，它是否會把資料按照你想的方式進行儲存呢？何時完成呢？如果你對答案感到困惑，那就意味着可能有問題出現了。曾經在同僚的項目中發現過很多次這樣的情況：每次修改後進行切換，不提示儲存――我隻知道，我又白幹了。在對某個子產品進行修改時，你會發現，是遺漏了必要的步驟。
9．很差的外部子產品性
外部子產品性指的是程式從外部看起來産品的子產品化程度（就像程式是可分割的）。你如何容易地了解子產品元件？很差的外部子產品會耗費大量的時間來學習産品，還會吓跑新使用者――天那，它看上去太複雜了！盡可能讓資訊獨立展示出來，對任何特定任務而言，你需要知道的越少越好。
幫助文本和錯誤資訊
幫助文本和錯誤資訊通常被認為是産品的次要部分。它們可能是由低級程式員編寫的（比如我）或是作者編寫，對其進行更新的工作可能被賦予低優先級。
當你感到困惑或是有麻煩時，尋求幫助或傾向于使用錯誤處理程式将是一個明智的選擇。你可能會覺得不爽，更多的時候是不耐煩。而如果其中有資訊誤導了你，其餘的倒還不如沒有來得更好。以下列出的是幾種常見的問題。
1．不合适的閱讀層次
在計算機終端上，人們不能很好的進行閱讀。幫助文本和錯誤資訊應該盡量措辭簡單明了，多用主動語态，盡量少使用技術術語，即便使用者中有計算機經驗也是如此。
2．冗長
避免你的幫助文檔和錯誤資訊變成裹腳布。大多數使用者在需要更多資訊時，會選擇通過菜單獲得進一步的資訊。最好讓他們自己選擇所需的資訊。
3．不合适的情緒語氣
盡量不要使用感歎号，如“終止”、“崩潰”之類的帶有激烈意味的詞語都應如此。
4．事實錯誤
記得測試時需要測試那些更新過的功能，在舊的幫助上的方法可能在新軟體中是行不通的。
5．上下文錯誤
不要把上下文之間的關系搞錯了。這會帶來閱讀時的不便。
6．沒有識别出錯誤來源
通常，一個好的錯誤資訊不僅可以指出是什麼情況，而且還要指出為什麼有些東西出了錯，以及如何處理此類錯誤的方法。
7．16進制轉儲不是錯誤資訊
8．沒有說明原因就禁止一個資源
如果程式嘗試使用列印機、記憶體控件等資源，卻做不到，錯誤資訊應當包含的不僅僅是宣布失敗，還需要說明原因。
9．報告說沒有錯誤
首先，還是承認這種情況不太可能出現；錯誤資訊隻能由錯誤狀态出發，如果大部分是通常情況的調試消息，亦或者是少部分并不一定由某個缺陷引起的事件報告，那麼，你可能就會忽略所有的錯誤資訊。
顯示上的（問題）缺陷
這是一個比較客觀的問題，至少表面上看上去是這樣的。任何可見的錯誤都會産生讓人不快的感覺（盡管這些問題不一定很嚴重），使用者就不一定會相信或者購買該産品。可能是因為此類錯誤大多數都是屬于低級錯誤，通常并不受到開發人員和項目經理的重視，但是我們必須重視它――它就是問題（Bug），它就是我們要找的東西之一。
兩個光标
程式員在跳轉螢幕的時候忘記擦除舊光标，嘿，我該相信哪個才是我要的。更糟的是：第二個光标可能反映儲激活區域附近代碼中的混亂（即使程式可以正确回應，可程式還是有可能誤解）。如果光标在測試期間行為不正常，還是先儲存再檢查你輸入的任何資料。
光标消失
有時候光标會消失，因為程式員在其上顯示了一個字元，或者移動了它，但是忘了對它重新顯示。然而，一個程式的光标指針可能不可用。當它指向一個用于資料或程式存儲的記憶體位置，而不是螢幕記憶體時，你會看不見光标。無論何時程式嘗試顯示光标，它都會重寫記憶體中的資訊。
光标顯示在了錯誤的位置
程式在某個位置顯示了光标卻在另一個位置對輸入做出了回應。這不是令人興奮的發現，至少它誤導了你走向了錯誤的方向。一個錯位的光标可能會警告：程式會截斷輸入的字元串，或者用無用資料将其填滿。在有雙光标的情況下，輸入文本可能得到正确響應，卻未必會正确儲存。
光标移動到資料錄入區域之外
光标不應該離開資料錄入區域，這通常是由于編碼錯誤引起的。有些程式員有意讓你把光标移動到螢幕的任何地方，然後告訴你一個錯誤資訊，說明你不能在此輸入任何東西――－這還是一個錯誤――設計錯誤。
資料寫到了錯誤的螢幕位置
光标提示在正确的位置，但是資料卻顯示在螢幕錯誤的位置（張冠李戴）。
未能清除部分螢幕
一條資訊在螢幕上顯示了幾秒鐘，接着卻隻有一部分被擦除了；或者你對前一問題的回應仍然留在螢幕上。為了輸入一些新東西，不得不在提示或不相關的回應上輸入，這是令人頭疼，而且迷惑不解的。在以前測試的項目中，就曾經出現過由于螢幕未正确重新整理導緻的清屏不完整及無故彈出不相關提示的問題――這種問題比較普遍，需要多加注意。
未能突出顯示部分螢幕
如果程式常常需要突出顯示某個特定類别的項目，例如提示或者在激活視窗中的所有文本，那麼它就必須一直這麼做。
未能清除突出顯示
螢幕位置的屬性與顯示的文本分開儲存時這是很普遍的。程式員删除了突出顯示的文本，但是忘記了從螢幕的那一區域清除突出顯示。
顯示的字元串錯誤或不完整
顯示的消息可能是毫無價值的文本，一個冗長的資訊的一個片斷或是一條應該顯示在其他時間出現的完整資訊。這其中任何一條都可能反映出程式邏輯上，用來發現消息文本的指針的值或者已儲存的文本副本中的錯誤。
顯示資訊過長或者不夠長
消息在螢幕上顯示的時間應該足夠長，至少應該保持到能讓使用者讀到結束為止。對同一條消息有時顯示時間長，有時顯示時間短需要注意，這可能預示着外部資源之間的競争條件，往往這些條件是在我們考慮之外的，需要認真對待。
界面布局的顯示
螢幕看上去應該是很有條理的，别讓它看起來像是一個亂糟糟的房間。不同類别的對象應該在可預知的區域分開顯示。你可以參考一些關于UI布局的文章，但歸結起來說：顯示布局應該很容易讓你在螢幕上找到你要的東西。
從美學角度看螢幕布局很拙劣
螢幕可能是不平衡的，大多數情況下是這樣子，行或者列不對齊，或者隻是看起來很“糟糕”。好好利用你的鑒賞力，如果沒有信心，可以問問别人的意見，參考一些界面設計很合理的軟體。如果對你而言它的布局的确看起來很糟，相信你的直覺，肯定有什麼東西錯了，盡管現在你還沒有發現。
菜單布局錯誤
這是最常見的問題之一了：我們有時候會發現在編輯菜單下突然冒出了一個檔案關閉的選項，而一般它是放在檔案一欄下的。在很多的參考文獻中，已經對這方面的内容做了比較詳實的說明，我想強調的是以下一些問題：
1．相似的或從概念上相關的菜單選擇應該分組，或者應該在螢幕上說明。
2．選擇一個菜單項通常應該獨立。為了獲得一個獨立的結果，使用者不應該必須在不同的菜單上做出兩個或更多的選擇（這可絕對“難”用）。
3．通過鍵入其首字母來選擇菜單項通常要比使用數字來得好。當然，你要留神不要給菜單項過于奇怪的名稱，另外，還要注意不要在同一欄下面不要出項重複的字母。
對話框布局錯誤
就強調幾點吧。
1．對話框應該一緻。如：他們應該一緻使用大小寫，字型和文本對齊規則。對話框标題應當占據某個一緻的位置，并與用來調用該對話框的指令名相符合。相同的快捷方式在不同對話框之間應該起相同作用――如不應取消某些對話框，而完成其他的任務。
2．對話框中的控件布局必須合理安排。應使用必要的間隔把組隔開。
3．選擇和錄入區域應該垂直和水準排列，這樣使用者就可以以直線模式操作光标的運動（為了友善）。
4．留意對話框之間的互相依賴性。如果某個對話框中的選擇将最終決定另一個對話框的選項将是令人困惑的。
模糊不清的訓示
你應該總是知道去哪裡查找以找出下一步。如果螢幕排得很滿，總是應該為指令和消息留出一塊空間。在螢幕中央顯示資訊也是一個不錯得選擇。
閃爍的誤用
閃爍的圖檔或文本很引人注意，不過記得不要太多閃爍。太多的閃爍會讓人覺得不舒服。你應該每次最多隻讓一個目标進行閃爍而且頻率不能太高。
顔色的誤用
不要太多顔色，它會讓我們的眼睛很疲勞。顔色不應該使我們分散注意力，也不能使螢幕看上去雜亂無章，盡量使用統一風格的顔色，如果程式的顔色組合看上去很難看，抗議吧，沒有人會願意買毫無美感的産品的。
過于依賴顔色
如果程式在項之間使用顔色為唯一分隔符，那麼它将限制使用者的範圍，對于一些特殊的産品，需要考慮到例如色盲之類對顔色不敏感的人群或是使用單色顯示器的使用者。
與環境風格不符合
如果與計算機相關的風格提供了某種一緻性和便利，盡量好好利用。也許對程式員來說可以使用更好的技術來代替，對于使用者來說也未必不是不可接受的。例如：在習慣了滑鼠和圖示之後，恐怕很少有使用者會習慣敲擊鍵盤書寫指令來完成計算機可以使用滑鼠完成的工作。當大多數其他的程式以某種特定方式在螢幕的特定位置顯示錯誤資訊時，新程式也應該是這樣的。
不能去掉螢幕上的資訊
在螢幕上某個部分的可用指令選擇菜單是很好的選擇。一旦使用者精通了程式，有些菜單就會成為螢幕空間資源的浪費。你應該可以送出一個指令能去掉和重新調用它。這點上，值得向微軟的Office系列軟體學習。
指令結構和錄入
這裡隻處理實作中的缺陷。（即假定程式員對風格的選擇是合理的）
不一緻性
增加永真規則的數量可以縮短學習時間，并減少文檔，而且使程式看上去更專業。不一緻性如此的普遍，是因為它需要規劃并進行鬥争來選擇能一直遵循的操作規則。每個微小的不一緻性都是不重要的，但是一旦量變到質變，一個本來構想很好的産品有可能會變得難以使用，甚至變成廢品。一個好的測試實踐要标注出所有發現的不一緻性，無論多麼微不足道都要如此。
“最優化”
程式員有時候會有意引入不一緻性來對程式進行優化。的确很吸引人，但是也要注意優化所帶來的風險和一些優化的必要性：儲存一兩次按鍵操作是否與學習時間的增加或信任度的減少價值相當？未必。
不一緻的文法
不一緻的指令錄入風格
你可以通過指向它，按下一個功能鍵，或者鍵入其名稱、縮寫或數字來選擇一個指令。一個程式應該使用一個指令風格。如果程式為完成同樣的任務提供了可選的風格，那麼它應該在每處都提供相同的可選項。如果必須在程式的不同部分之間轉換風格，那麼它必須弄清楚什麼時候用哪一個。
不一緻的縮寫
如果沒有很明确的縮寫規則，縮寫就不能容易地被記住。把Delete縮寫為Del，把Grep縮寫為Grep，是沒有任何意義的。
Fp firstpage frontpage
Ep end page
Lp lastpage
不一緻的終止規則
程式應該為多重鍵錄入要求終結符。
不一緻的指令選項
如果一個選項對兩個或者更多的指令有意義，那麼它就應該對這些指令都可用（都不可用），它應該具有同樣的名稱，并且應該在兩種情況下以同樣的順序被調用。
名稱相似的指令
如果兩個指令名稱相似，就很容易搞混。盡量不要使用相似的名稱命名指令。
不一緻的大寫
如果指令錄入是區分大小寫的，所有指令的第一個字元都應該使用大寫（小寫）。指令中嵌入單詞的第一個字元應該一直大寫（小寫）。另外，如非必要，不要在一個指令中使用多國語言。
不一緻的菜機關置
如果同一指令在不同子菜單中出現，那麼要在不同菜單的同一位置保留同一指令是很困難的。
不一緻的功能鍵用途與其說明
功能鍵的意義在程式中應始終保持一緻（颠倒或是功能沖突是不能接受的）。
不一緻的錯誤處理規則
當程式檢測到一個錯誤之後，它可能會公布該錯誤，或者嘗試更正錯誤。任何一個程式的行為都應該是可預測的。
不一緻的編輯規則
當你輸入或稍後檢查任何資料時，同樣的鍵和指令應該可以用來對其進行修改。
不一緻的資料儲存規則
應該在每處都以同樣的方式，在同樣的時間和範圍内儲存資料。它不應該在每個區域輸入資料時儲存資料，而其他時間則在一個記錄、一組記錄的末尾儲存資料，或恰好在退出前儲存資料。
浪費時間
看起來為了浪費時間而設計的程式會激怒每個人。
曲折路徑
如果為了到達想要的指令，你必須一個接一個做出選擇。結果到最後發現，該指令不存在或是不能實作亦或者要求你先完成某件事甚至幾件事後才能使用。――明顯的欺詐行為。相信客戶的不滿和你的幾乎沒有任何差別。
不能采用的選擇
事實上沒有任何接口在一個不能建立的菜單中包含選擇項。如果沒有任何資料存在，你如何評審、儲存和擦除資料？沒有列印機，如何列印文檔？有的指令不适合出現在某些條件下（雖然對使用沒有什麼影響），但是開發人員可能為了圖友善而保留了此類指令（很遺憾地說：這太不專業了）；有時候，程式會提示尋求幫助，而當你真的去使用的時候，程式卻告訴你“您沒有使用幫助的權限”――這還不如不讓使用者使用來得更好。這種情況很常見，至于常常被開發人員和測試人員共同忽略――但這是不應該存在的錯誤。
你真的，真的确定麼？
嚴重毀壞資料的指令需要這樣重複的确認。是的，這是必須的，如：對一個寫滿資料的硬碟進行格式化的确需要多次确認。但是沒有必要對每個細小的删除操作進行繁複的多次确認操作，使用者會變得不耐煩，其結果是：當使用者進行嚴重毀壞性指令時，無視螢幕提示，造成不可預計的後果。
模糊不清或者帶有個人風格的指令
指令名應該明确訓示該指令的作用。不要讓使用者一邊使用軟體，一邊查詢使用者手冊中關于該指令的解釋。調查表明：大多數使用者在使用軟體産品的時候隻對軟體手冊做大概的了解，甚至根本不閱讀。别指望使用者會很完整地閱讀手冊，那是我們的工作。沒有任何理由在釋出的程式中生成如：finger等帶有個人風格的指令，當然，如果在程式中出現了髒話，哦不，這是絕對不能允許的。
菜單
菜單應該盡量簡潔，當存在了太多風格不一，冗長和拙劣的圖示或指令名，以及當選擇隐藏在不明顯的主題之下的子項時，了解它們将會變得非常複雜。一個菜單覆寫的指令越多，無論如何規劃，都會變得複雜，如果沒有良好的規劃，這對使用者的使用将是一大障礙。
過于複雜的菜單層次
如果必須在最後到達你想要的指令之前很吃力地通過一個又一個菜單，那麼我想我會選擇使用另外一個功能相近的程式。建立深層菜單樹的程式員所引用的設計規則表明，沒有哪個菜單應該具有七個以上的選項，這一點對新手來說可能時最好的。有經驗的使用者更傾向于每個菜單級别有更多選擇，犯更少錯誤并更快速有效的做出反應，隻要選項能合理組織，整齊排版，而且沒有可笑的擁擠或拼寫錯誤就行了。
不适當的菜單導航系統
即使在一個最适當的深層菜單系統中，你也必須能夠傳回到前一菜單，或者移到菜單結構的頂層，并能在任何時刻離開程式。
太多路徑到達相同位置
如果許多指令在菜單中重複出現，那麼程式就需要重新組織。讓一個指令在不同位置重複可能會很便捷，但是存在一定的限制。如果感覺上你可以從程式的任何位置到達另一個任意位置――那就得重新考慮下程式的内部結構和可靠性。
相關的指令被歸屬到不相關的菜單
把一個複雜菜單中對指令或主題進行分組并不是一件容易的事情。人們都很容易忽視兩項之間明顯關系，并把它們配置設定到分開的菜單中去，當需要對此進行調整時，我們需要做的是：解釋兩項之間的關系，并建議兩者都應屬于哪個菜單。
不相關指令被放置到同一菜單下
有些指令被扔到了完全無關的菜單下，這樣并不好，甯可重新選擇一個更進階别的标題并重新組織這些指令也不要那麼做――如果那樣做導緻的混亂比較嚴重的話。
指令行【一般比較少用到】
在沒有提示的情況下鍵入指令要比在菜單中辨認指令要難得多。但是如果存在許多指令和選項，有經驗的使用者會更樂意使用更快更有效的指令行輸入方式錄入。此類軟體如AutoCAD等。菜單系統對使用者可能太過于龐大了。
大小寫之間的強迫性差别
如果沒有正确的大小寫，有些程式不能識别一個正确的拼寫指令。通常，這不是一個特色，而是一件麻煩事。
參數颠倒或是指令意義模糊
最常見的例子就是源檔案和目标檔案之間的差别。比如：Copy File1 File2；你可能根本就不知道它是指檔案1到檔案2的拷貝，還是檔案2到檔案1的拷貝，或者僅僅是拷貝了檔案1和檔案2？順序并不重要（這些習慣可以被後天培養），但是需要使指令的意義明确并保持一緻。應用程式必須遵循作業系統的慣例，而不是特意地重新定義――除非必要。
全指令名不被允許
縮寫是很好，但是你總應該允許Delete的存在，而不僅僅隻是Del。一個可記的指令全名要比縮寫可靠得多，尤其是不存在任何縮寫規則時更是如此。
不允許縮寫
你應該允許鍵入Del代替鍵入Delete的全名。很多系統并不允許縮寫，但是這不是一個設計錯誤。如果适當的加以實作，就是一個很好的功能改善。
複雜的指令行輸入
盡量不要使用過于複雜的指令行輸入，除非它對其他人是易懂的，邏輯清晰的。編寫過于複雜的指令行對使用者而言可能會産生很多錯誤，進而影響他對程式的信任度。
建議批處理輸入
沒有批處理指令行的程式是令人頭疼的，當使用者輸入了大量的指令行，結果卻隻執行了其中某一行（通常是）或者幾行，這種設計是不能讓人滿意的。
不能編輯指令
在輸入指令時，應該至少能後退一格。如果你試用執行一條沒有正确輸入的指令，那麼至少你應該可以調回它，修改錯誤的部分并重新執行。這可以參考Dos的系統的設計。
鍵盤不能正确使用
不能正确使用鍵盤無論在何時都是一個問題。
無法使用編輯鍵或功能鍵
如果一個程式從某些其他沒有這些鍵的機器上移植過來，那沒關系。相反可能就不行。要確定程式可以使用已有的編輯鍵和功能鍵。
光标和編輯鍵的不标準使用
這些鍵應該按照他們通常在該機器上工作的方式進行工作，而不是按照他們通常在其他某個機器上工作的方式來工作。
功能鍵的不标準使用
如果大多數程式用F1作為幫助鍵，那麼如果在程式中将它定義為其他的功能，那将是不合适的。
不能過濾無效鍵
程式應該能擋住并抛棄無效字元，比如進行數字相加時輸入的字母。它不應該做出回應。與錯誤消息相比，這樣做更快更有效。
未能訓示鍵盤狀态的改變。
鍵盤上的燈或螢幕資訊應該告訴你何時你的Num Lock鍵和其他類似的狀态轉換特征是開着的。
未能掃描功能鍵或快捷鍵
你應該能夠告訴計算機從它正在進行的工作中退出；程式應該總是能辨識出任何其他系統指定的鍵――即那些本機上的程式通常可以很快識别出來的鍵。
遺漏的指令
狀态轉換
大多數程式從一個狀态轉到另一個狀态，在你選擇某個菜單項或者送出一個指令之前，程式處于某種狀态。為了回應你的選擇，程式回到另一個狀态。程式員通常會對他們的代碼進行足夠的測試，以確定你能達到任何你應該可以達到的狀态。
什麼都不作就退出（狀态傳回）
你應該能夠告訴應用程式，你做出的最後一個選擇有誤，并傳回到其前一個狀态。
不能在程式中間退出
當使用一個程式但還沒有對存儲的資料造成不利影響時，你應該能夠從中退出；如果你正在編輯的檔案出現了預想不到的錯誤，在中止後應能回到先前儲存過的狀态。
不能在指令中間停止
告訴程式停止一個指令很容易，而傳回到起始點或選擇一個其他的指令也應該不太難。
不能暫停
如果程式限定了你輸入的時間，時間一到，狀态就改變，那麼當你離開時你就需要它暫停一會兒。
危機預防
系統故障和使用者錯誤發生了，程式應具備将其後果降到最低的能力。
沒有備份工具
對開發人員而言，為了一個檔案做一個額外備份應該不是一件困難的事。如果你正在修改一個檔案，計算機應當保留原始版本的一個副本，是以如果你的更改有錯誤，還能傳回到一個已知的好的版本。
不能撤銷
撤銷一個你已經發出的編輯指令，至少是一步。恢複被删除的檔案是一種受限制的撤銷，它能讓你恢複錯誤删除的資料。撤銷是可取的，恢複被删除檔案也應是必須的。
沒有“你确定嗎？“的提示
送出一個大量資料清除的工作，或者提出一個清除少量資料但是會影響其他作業的指令亦或者很容易錯誤送出的指令，都需要程式在使用者操作時進行确認，不聲不響地進行将會帶來安全方面的隐患。
沒有增量儲存
當輸入大量文本或資料時，你應該能告訴程式相隔一定時間對你的工作進行儲存，至少應該提供使用者此類選項。對于突發的掉電和硬體損壞情況這樣做将是非常有好處的。
由使用者進行的錯誤處理
人們可以捕獲自己的錯誤，而經驗告訴我們，他們還容易犯其他的錯誤。他們應能自理修複錯誤，并建立自己的錯誤檢查機制。
沒有使用者能指定的過濾器
當設計資料錄入表格和電子表格模闆時，你應該能夠讓每個區域指定什麼樣的資料類型有效、程式應忽略或拒絕什麼。例如，你可以讓程式拒絕數字、字母、不在某個特定範圍内的數值，一個有效日期或者與磁盤上比對的日期等等。
難用的錯誤更正
修改一個錯誤應該很容易。不應該因為犯了錯誤的資料錄入而讓整個系統重新啟動。在輸入一串資料時，你應該能在不重新輸入剩餘部分的情況下，更正錯誤的資料。
不能包括注釋
當設計資料錄入表格，電子模闆，專家系統時，你應該能夠為未來參考和調試輸入注釋資訊。這是很必要的。
不能顯示變量之間的關系
錄入表格、電子模闆中有些變量是互相關聯的，應該能很容易的檢查任意變量對其他變量的依賴性。這在設計時應該被周密考慮到。
其他問題
隐私和安全性
對于某些特定的程式，需要考慮資料的充分安全性，保護公司，集體或個人的機密和隐私。在多使用者系統上，你應該能很好的隐藏你的檔案（一般都是通過加密手段實作的），并且能很好的鎖定你的檔案不被篡改或閱讀。
安全性的困擾
一個程式的安全性控制應盡可能謹慎考慮與實施。
不能隐藏菜單
很多程式在頂端、底部或螢幕邊緣顯示一個菜單（包括我以前測試的大多數應用程式）。它們使用螢幕的剩餘部分作為資料錄入和處理的區域。菜單隻是記憶的輔助物。一旦使用者了解了他所需要的所有指令後，就應該給予使用者充分的自由，讓其選擇是否需要保留菜單的權力。
不支援标準O/S特征
例如：如果系統使用了子目錄，那麼程式就應該能引用其他子目錄。如果作業系統提供了通配符（比如*），那麼程式也應該能使用。
不允許長名稱
應當允許使用長名稱，畢竟，記憶體不足和編譯器反應遲鈍的時代已經成為過去了。别讓自己的程式也成了文物。
程式僵化
程式有靈活與固定之分。靈活的程式更顯個性化一些，而固定僵化的程式一般都是由于業務流程的關系而不得不如此。如借還書的過程，必先借了才能還。别給使用者太多的自由，否則程式看起來會讓人覺得松散，也不要把程式定得死死的，那看上去給人太多壓力了。
使用者可調整性
不能關掉噪音
犯錯誤時，許多程式都會給出“咄”的警告聲。而如果每次接觸鍵盤都發聲，這簡直是不能容忍的――特别是在公共場所。必須關閉沒有必要的噪音。
不能關閉大小寫區分
一個能區分大小寫的系統應該允許你告訴它忽略大小寫的問題。
不能配合手邊的硬體
有些程式被鎖定針對了特定的輸入輸出程式。更新或更換了裝置的使用者可能就無法使用這些功能了。這是令人遺憾的。同時，也會讓使用者覺得是否是一種商業捆綁的模式而拒絕使用此産品。盡量讓開發人員編寫通用的硬體接口代碼以适應大部分通用的硬體裝置。
不能改變裝置初始化
一個應用程式應該能夠發送使用者定義的初始狀态，或者至少應該讓它保持現狀。每次啟動都需要重新配置将會是很煩人的工作。假定你想要項一個列印機發送控制代碼，以轉換到壓縮字元，如果列印資料的程式不讓你初始化列印機，你就不得不從裝置來改變列印機的模式和狀态，然後重新運作程式。如果程式阻撓了你的列印機設定，那就是一個設計錯誤。
不能關閉自動儲存
自動儲存是件好事，不過無事生非也是一件糟糕的事情。過于頻繁的自動儲存可能會讓使用者覺得程式的不可靠。是以還是老老實實加上關閉自動儲存的選項吧。
不能改變滾動速度
嚴格來說，這不是一個很嚴重的問題。現在很多的裝置驅動中已經提供了此類選項。
不能重複上次的操作
這樣的例子比如Word軟體中的Redo。
無法找到你上次完成的内容
此類問題對資料編輯特别是文本編輯類的程式較為常見。應當提供儲存的檔案清單，除非使用者禁止了它。
無法執行一個定制的指令
在程式選項中，一旦對其更改，應該立即生效，不需要再次重新啟動程式進行加載――特殊情況除外（如果你無法避免）。
無法儲存定制的指令
你不應該隻告訴程式此次運作關閉了警告聲，而是應該讓程式永遠可以關閉這些――隻要設定沒有發生變化。
特征更改的副作用
這種情況較常見，修改了某一個特征，相關的特征也會改變。如果确實存在副作用，應當在手冊和螢幕中提供詳實的文檔證明和提示。
無限可調整性
開發人員可以改變某些程式的方方面面。但是在開篇時說過，提供了太多靈活性的程式并非一直都是一件好事。好好斟酌再做決定要比草率地修改來得更好。
控制方式
有些程式很“霸道”。它們的錯誤資訊和幫助消息自認為高人一等，它們的風格不可原諒的不便――你甚至無法放棄指令或者在輸入資料後進行更改。程式應該使你覺得能更容易，更惬意地完成一個任務。至少，它不應該浪費你的時間。
一個概念風格的不必要的不合理要求
有些程式要求你以某種順序輸入資料，或要求你在進行下一步之前先完成某項任務，再要麼就要求你再考慮它們的潛在後果之前做出決定。例如：
當設計一種資料錄入格式時，為何你必須再螢幕顯示之前确定一個資料錄入域的名稱，類型，寬度或者計算順序？當你察覺不同的域放在一起看起來有神麼不妥的時候，你是否會更改某些域，把它們的位置換來換去，甚至去掉少數域？你可能不得不在使用該格式之前輸入域的規格說明，但是在該限制條件下，你應該決定何時填充細節。
當向一個項目管理系統描述任務時，為何你必須首先列出所有的任務，然後列出說有可用的人員，接着在為下一項工作輸入任何資料之前就把配置設定給某個人的工作完全對應？既然你可能試着決定什麼工作配置設定給什麼人，那麼你不想看到結果後再更改這些資料麼？
限制的數量如此多，是因為有些開發人員認為，人們應該以某種方式組織它們的工作。但是他們所想的最佳途徑未必都是最佳的。我們應該更清醒地意識到，除了業務流程上的禁锢，不需要再對使用者在風格上多加任何的限制――當然，如果使用者需要的話。
對新手友好，但是對老手并不一定友好
為初學者設計的進行過優化的過程可能為他們掌握系統會有幫助，但是同時會令一些有經驗的老手帶來煩惱。他們更希望能自由地使用軟體；其中一個解決辦法就是提供兩條以上地路徑實作對不同層次使用者的需求。
人工智能與自動化
有些更智能和更便利的程式會猜測你的下一步動作，并枉加執行這些猜測；自動糾錯的程式的确很好，除非它“糾正”了正确的資料。而有時候，使用者并不一定希望這樣做。
過剩或多餘的必需資訊
過剩和多餘的必需資訊就像我們身上的贅肉一樣讨厭。有些程式會請求他們從來不會使用或者隻會用來在螢幕上顯示一次的資訊，或者會要求你重新輸入你已經輸入過的資料――并非是為了驗證，僅僅隻是重新擷取一次資料，這對時間的浪費是非常驚人的。
不必要的步驟重複
如果你在輸入一個較長的指令步驟或資料時犯了一個錯誤，有些程式就不管青紅皂白讓你重新輸入；有的程式則強迫你重新輸入或确定可能有錯誤的任何指令。為了某些任務，你甚至可能需要确認每個步驟。相信我：不必要的重複或确認都是浪費時間。
不必要的限制
為什麼要把一個資料庫限定為如此多的字段或記錄，或限制一個電子表格僅使用數字，把一個項目經理限制在如此多的任務中，一個字處理程式限制在如此多的字元呢？對性能或可靠性而言并非必要的限制不應該成為限制條件。
性能
許多有經驗的使用者認為性能是最終要的可用性因素：使用一個快速程式，他們感到更能集中精神工作，而且更多的東西處在掌握之中。在極少出現異常的情況下，程式越快越好。
性能有很多定義，大緻來說主要有如下的感性認識：
1．程式速度：執行标準任務的速度有多快？
2．使用者吞吐量：你能使用程式執行标準任務的速度有多快？
3．感覺到的性能：在使用者看來，該程式速度有多塊？它是否令你滿意？
無論如何定義，程式速度總是一個關鍵因素。但是一個界面設計拙劣的快速程式無論怎麼看都要比它實際的運作和處理速度要慢得多。
降低程式速度
很多設計和代碼錯誤會降低一個程式的執行錯誤。程式可能會執行很多不必要的工作，如對一個在讀前會被重寫的記憶體區域進行初始化；也可能會對工作進行不必要的重複，如在一個在循環中執行的任務可以在循環外完成；設計的決策也會影響到程式的速度，而且通常要比明顯錯誤導緻的慢速情況更加嚴重。
緩慢回應
程式立即對輸入做出響應，如果在你輸入一個字母的時刻和你看到這個字母的時刻有延遲，那程式就太慢了。快速回報對任何輸入事件都必須是有效而且是必要的。它包括：滑鼠，鍵盤，軌迹球，鍵盤等等。
如何減少使用者吞吐量
一個閃電般快的程式執行任務時可能比蝸牛還要慢。這包括：
1．任何可能使使用者錯誤更可能發生的事情。（教育訓練不周，使用者習慣，程式風格等等）
2．緩慢的錯誤恢複。如：在輸入一長串字元後發現錯誤卻必須要重新輸入。
3．任何使你感到迷惑，卻得不到幫助文檔或手冊提供資料的事情。
4．輸入很多，确做得很少的程式――這不是一個好程式。如：把一個簡單任務劃分成很小的子任務，要求對所有事情進行确認等等。
在測試時，使用比較性測試是個有效的方法：即把開發中的産品與競争對手的産品進行比較，如果人們使用你的産品花費的時間要更長，那麼發現這個問題就是有意義的。
反應拙劣
我曾經測試過一個産品，在輸入第一條資料後，居然花了将近一分鐘才從資料庫中将資料取回。這不能不說是一個反應很慢的程式。一份表單做下來将近300條資料，按此速度計算，我将花上至少半天才能完成輸入。這種情況是不能允許的。迅速地對輸入做出回應是一個程式最最基本的功能。一個反應迅速的程式不會強迫你在送出下一個指令之前要你等待。而是讓你繼續做其他事。
沒有提前輸入
一個允許提前輸入的程式會讓你在它從事其他工作的時候仍然可以鍵入，它會記住輸入内容，加以顯示并在稍後進行處理。你不應該等着輸入下一個指令。
沒有給出某個操作會花很長時間的警告
如果程度需要超過幾秒鐘的時間來進行某事，程式應該告知使用者。對于較長時間的任務，它應該給你一個大概的時間印象而不是讓你幹等着它結束。給出大緻需要完成的時間是處理此類問題一般的方法。
程式太多提示和詢問
提示，警告以及詢問可能很有用，不過如果它們出現得太頻繁，就會讓人很窩火。
盡量使用簡單指令和提示
在慢速終端上，幫助文本，長菜單以及漂亮的圖檔常常會令人不耐煩。你應該使用簡要的語言取而代之。不要使用諸如“你真的想以500k/s的速度傳送此郵件到某郵箱”麼之類羅嗦的語句。
輸出
程式的輸出應如輸入一樣完整。它要求更精确，盡量快速和能實作多路徑及對輸出内容更有效的管理。
不能輸出某種資料
你應該能列印出你輸入的任何資訊，列印不出輸入的内容對任何程式而言都是緻命傷。
不能重定向輸出
你應該可以重定向輸出。特别是，你應該能向磁盤發送一個很長的“列印輸出”标記，并稍後列印該磁盤檔案。程式不應該阻止你把資料輸出發送到預料之外的裝置，如繪圖儀，錄音帶，列印機等。
與一個後續過程不相容的格式
如果一個程式聲明能夠以第二個程式可以了解的格式儲存資料，那麼就應該測試它是否可以真正做到。這意味着購買或借用第二個程式的副本。并用第一個程式儲存資料，用第二個程式讀資料，同時看看第二個程式得到了什麼。
必須輸出的很少或很多
你應該可以修改報告，進而呈現你需要的資訊。不得不在僅包含少量有用資訊行的列印輸出的大量頁中找出所需資訊，幾乎和沒有得到資訊一樣糟糕。
不能控制輸出布局
你應該可以改變字型，對輸出資訊增加特殊标記來強調資訊。你應該可以修改資訊之間的間距，最低限度來說，程式應該可以以一種合适由文字處理進行修飾的格式把報告輸出到磁盤檔案。
荒謬的精度輸出級别
要是說4.2加上3.1等于7.3000000或者說3.1111+2.11等于5.22110102都是很愚蠢的。在最終輸出的結果中，程式應該按照規定的格式和精度輸出最後的資料。
不能控制表或圖的标記
你應當能夠改變字型，措辭及任何說明，包括标題，表格，圖形或是圖表中文本的位置。
不能控制圖形的縮放比例
繪圖程式應該提供預設的垂直和水準比例，不要告訴我你最後輸出列印報表中的圖形超出了整個頁面。
錯誤處理
在處理錯誤時發生的錯誤通常是最常見的缺陷。錯誤處理産生的錯誤包括：未預料到錯誤發生的可能性并防止其發生，沒有注意錯誤狀态，以及較嚴重的：程式可能與錯誤資料一起工作并最終産生錯誤結果的情況（這類情況比較難發現，一般都不會提示已經發生了錯誤，或是發生了錯誤，資料已經在不經意的時候被程式更改，而測試人員無法對其進行校驗而遺漏）。
錯誤預防
程式應具備這種能力：它能保護自己不受到系統其他部分的影響（包括有害輸入和有害處理）。如果程式可能與錯誤資料共同工作，確定其在發生嚴重可怕的影響之前（如程式崩潰，資料丢失與錯誤，系統崩潰等），檢查并消除這些問題。
不充分的初始狀态驗證
如果記憶體的某個區域必須以其中所有位都是0開始，那麼程式應該可以運作一個抽樣檢查，而不是假定已經存在0值。這會導緻程式初始化時發生記憶體錯，甚至不能啟動。
不充分的使用者輸入檢查
此類問題非常常見，開發人員可能會在編寫程式時遺漏掉大量這方面的問題。告訴人們輸入1位到3位數是不夠的，有些人可能會輸入5位甚至更多，也有人會輸入特殊字元或是運算符，還有些人會按下功能鍵一次或多次，如果程式允許輸入，那麼程式就應能順利應付，而不是一打非專業人士不能明白的提示甚至更糟的情況。
對受損資料不能充分預防
沒有人能保證磁盤上的資料是好的。可能是有人已經編輯過或者根本是有硬體問題。即使開發人員認定在儲存前的檔案是有效的，那麼他也應該檢查（校驗）下次打開的是否是同一個檔案。
不充分的參數傳遞測試
一個子程式不應該假定得到了正确的調用（事實上，采用相反的想法可能會讓測試進行得更加順利一些）。它應該確定傳遞給它的資料在其可控制的範圍之内。
針對作業系統的預防不充分
作業系統存在缺陷――不光是過去，現在甚至将來也是，應用程式可能會觸發其中存在的問題。如：如果開發人員知道，他把資料送到磁盤後很快又把資料送到列印機，會引起一些作業系統的崩潰，那麼他就應該確定程式在任何情況下都不會這樣做。
不适當的版本控制
如果可執行代碼不止存在于一個檔案中，那麼有人會嘗試把某一檔案的新版本和老版本一起使用，客戶對其軟體更新使得這類問題時常發生，但是又不能明白出了什麼問題。新版本應確定所有的代碼都是最新的，當然也要對老版本最好完整的備份。
針對惡意使用的不充分預防
人們有時會有意無意的提供程式有害輸入，或者嘗試觸發錯誤狀況（特别是做測試的家夥們）。不要假定“任何有理智的人都不會這麼做”，相信我：程式不完全是為了“有理智”的人開發的。
錯誤檢測
程式通常有足夠的可用資訊來檢測資料中或其操作中的錯誤。
忽視溢出
一個數值計算結果對于程式來說太大以至于無法處理時，就會産生溢出。溢出由較大數字相加和相乘或者被0除或是由于過小的分數除而引起。溢出是很容易檢測到的，程式也的确需要對溢出情況做出相應的處理。
忽視不可能的值
在計算機當中，幾乎沒有什麼不可能發生的事。程式應該檢查其變量，以確定它們在合理的界限之内，它應可以捕獲并拒絕如2月31日這樣的日期值。如果當變量為0時，程式完成某動作，變量為1時完成另一工作，并假設其他所有值都是不可能，那麼就必須保證變量隻能為0或者是1，對其他所有值進行額外的處理。在一個項目中，經過數年維護程式設計後，舊的假定就不一定安全了。
忽視看上去不真實的值
有些人可能會從自己帳戶裡提取100，000，000，000的錢，那麼就算他有這麼多錢，也應該在通過交易之前向幾個不同的人進行确認。
忽視錯誤标志
程式調用了一個子程式，結果操作不成功，它在一個被稱為錯誤标志的特殊變量中報告了該失敗。與通常一樣，程式能檢查或忽略它，并把從例程傳回的誤用資料當作真實的進行處理。
忽視硬體缺陷或錯誤情況
程式應該假定它能連接配接的裝置是失敗的，許多裝置能夠發送警告某件事情出錯的傳回資訊。如果有裝置這樣做了，停止嘗試與其互動，并向某人或某更進階别的控制程式報告此事件。
資料比較
結算銀行存折時，你有一個你自己認為的餘額數值，銀行也會提供一個餘額數值。在考慮了服務費，銀行利息，最近帳單等等資料之後，兩個資料不吻合，那麼就要好好查一查了。在互相檢查兩個資料集或計算集時，也會産生類似的情況。
錯誤恢複
程式中存在錯誤，程式已經檢測到了錯誤，而且現在正設法對其進行處理。許多錯誤恢複代碼隻是稍微進行了測試，或者根本沒有進行測試。錯誤恢複例程中的缺陷可能比原始問題更嚴重。
自動錯誤更正
通過檢查其他資料或規則集，有時程式不僅能檢測錯誤，而且還能糾正錯誤，而用不着麻煩任何人。這樣的程式是令人滿意的，但僅當這種“糾正”是正确時才是如此。
未能報告一個錯誤
程式應該報告任何檢測到的内部錯誤，即使它能自動糾正錯誤産生的後果也一樣。在稍微不同的環境下，它可能檢測不到相同的錯誤。程式可以向使用者報告這一錯誤，也可以向一個多使用者系統的操作員，向磁盤上的日志檔案，或者是這些對象的任一組合報告錯誤。總之，不管怎麼樣，它必須報告。
未能設定一個錯誤标志
某子程式被調用，但是結果失敗，假定它在失敗時設定了一個錯誤标志，它把控制傳回給調用程式，卻沒有對這個标志進行設定，那麼調用程式就會把無用資料當作有效資料傳回去。
程式要走向何方？
一部分代碼失效了。它記錄了錯誤，并設定了一個錯誤标志，接下來幹嘛呢？尤其是經過了幾個跳轉的情況下，它如何才能得知程式中的什麼地方傳回了控制？
中止錯誤
停止了程式，或者當它在檢測到錯誤時自動停止了，那麼它是否關閉了任何打開的輸出檔案呢？它是否在關閉時會記錄退出的原因呢？在最普通的條件下，在即将結束之前它是否進行了整理或者它隻是結束但可能留下一團混亂呢？這都是開發人員和測試人員需要考慮的問題之一。
從硬體問題中恢複
程式應該适度地處理硬體故障。如果磁盤或其目錄已滿，你應該能夠放入一張新的磁盤，而不隻是關閉了你所有的資料。如果一個裝置很長時間還沒有準備好接收輸入，你就沒有應該假定它已經斷線或斷開連接配接而進行處理。程式決不能夠讓我們永遠在那裡坐等。
不能從遺失磁盤中退出
假定你的程式要求你插入一張具有它需要的檔案的磁盤，如果插入的磁盤不正确，它會再次提醒你，直到插入了正确的磁盤為止。然而，如果沒有正确的磁盤，你就沒有任何辦法可以退出，除非你重新開機系統。不，這種做法是極端蠻橫的，決不能允許出現這樣的問題。
邊界相關的錯誤
一個邊界描述了程式的一個改變點，假定程式在邊界的一邊以某種方式做所有事，而在邊界的另一邊，它以不同的方式完成所有事。
邊界相對立的兩邊的典型“東西”就是資料值。存在三種标準邊界缺陷：
邊界情況的處理不當
如果一個程式把任何小于100的兩個數相加，不接收任何對于100的數，那麼當你恰恰輸入100時它會做何反應？它又該怎麼做？
錯誤邊界
規格說明表示，程式應該把任意兩個小于100的數相加，同時不接收大于95的數。
邊界外情況的錯誤處理
邊界某一邊的值是不可能，不可信，不能接收，或是預料之外的，沒有為其編寫任何處理代碼。程式是否成功拒絕了大于100的值？或者是否當它擷取了一個大于100的值時就會崩潰？
我們把邊界的概念看得更廣泛，邊界描述了考慮一個程式以及它在其極限周圍得行為得方式。存在很多種的極限：最大，最小，最新，最舊，最近，第一個等等。相同類型的缺陷可以伴随其中任何一種極限而産生，我們可以用相同或類似的觀點考慮它們。
數值邊界
有些數值邊界是任意的，如大于100；而有些則要描述自然極限，如三角形的特征和子母的ASCII碼等。
與一個邊界相等
在一個清單中的所有元素可能相同，也可能不同。如果你試着對任一清單進行排序，會發生什麼？如果清單由數字組成，當你嘗試計算平均值，标準偏差，對稱系數時又會發生什麼？（以上是概要統計概念，按算法，對稱系數可能會計算為0或引起被0除的錯誤。）
多種多樣的邊界
一個輸入串可以長達80個字元麼？如果你輸入79、80或81個字元會如何？程式是否在每種情況下都接收你的輸入？一個清單可以隻是一個元素麼？沒有元素可以麼？僅含一個數值的标準偏差又是什麼呢？
空間中的邊界
例如，如果一個繪圖程式繪制了一個圖形，并在其周圍繪制了一個方框，那麼該如何處理一個應當在方框外正确顯示的點？
時間的邊界
假定程式顯示了一個提示，停留60秒等待你回應。然後，如果你沒有輸入内容就顯示菜單，如果正當它開始顯示菜單時，你開始輸入内容，會發生什麼？
假定你在計算機仍然在從磁盤中裝入程式時按下空格鍵，發生了什麼事？空格鍵是被發送給作業系統，為正在裝載的程式進行了儲存，還是僅僅因為預料之外而導緻計算機崩潰？
硬體相關邊界
如果一台主機可以連接配接100台終端，那麼當你加入99，100，101台時會發生什麼？如果你讓100台終端同時登陸會怎樣？
如果磁盤已經塞滿了會如何？如果一個目錄能儲存1000個檔案，當你嘗試儲存第999、1000、1001個的時候會發生什麼？如果列印機有較大的輸入緩沖區，當你的資料填滿緩沖區，但是卻還沒有更多資料要傳遞時，會發生什麼？當列印機缺紙或顔料用完了又會發生什麼？
計算錯誤
程式計算一個資料得到了一個錯誤的結果。發生計算錯誤通常因為下面三種類型的原因：
很差的邏輯：
可能存在一個錄入錯誤，開發人員可能會在編制程式時無意中錯誤簡化了複雜關系地表達式，或者由于拼寫錯誤或筆誤導緻。另外一種糟糕的情況則是設計錯誤，開發人員關于代碼如何做地概念可能一開始就錯了。
很差的算法：
如果1＋1＝1，可以了解為一種特殊邏輯，但是如果把它作為數值運算，恐怕是沒有人會同意的。無論何時，一個錯誤的算法總不會得出正确的結果。
不精确計算：
由于使用了舍入的計算方法，很可能在計算時丢失精度。
![如何做好軟體系統自動化？[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)