【摘要】 本文列數了軟件黑盒測試過程中，在被測試軟件中可能存在的常見軟件問題。本文不會詳細討論基本的軟件測試思想與常用技術，僅針對在軟件黑盒測試過程中若干的問題做描述，并提供個人的參考測試意見與防范意見，希望可以為初學者提供些許幫助。

【關鍵詞】 軟件測試，黑盒測試

【引言】不能不說的二個問題

軟件測試中的“二八”原則

80％左右的錯誤在進行用戶測試之前已經被發現，而在剩余20％左右的錯誤中，存在80％左右的顯性錯誤，剩余20％左右的錯誤是較難發現的隱性錯 誤。這條原則源自經濟學的80-20原理。所以，我并不認為自己從事了一項偉大的工作，但是必須承認做好了這項工作對于整個軟件開發體系在用戶心目中的意 義巨大。

軟件黑盒測試解決的問題

簡單來說，黑盒測試所解決的問題主要在于以用戶眼光驗證軟件的結果。白盒測試關注范圍（控制結構），而黑盒測試更關注結果（即我們常說的所見即所得）。黑盒測試試圖發現以下幾類錯誤：

功能錯誤或遺漏
界面錯誤
數據結構或外部數據庫訪問錯誤
性能錯誤
初始化錯誤和終止錯誤
以下內容將會詳細說明在軟件黑盒測試中常見的各類錯誤。

【正文】軟件黑盒測試常見錯誤類型及說明

用戶界面錯誤

軟件是為了滿足用戶需求而誕生的產物，無論是操作系統、游戲軟件還是其他類型的應用軟件。黑盒測試的很大一部分工作集中在用戶界面上，不需要深入研 究其內在結構，而是“表面化”地使用軟件，從輸入輸出的信息內容中尋找可能的錯誤和紕漏?？傮w上講，用戶對于軟件的看法很大程度上依賴以下幾點：

功能性（實現軟件應具備的基本功能）
易用性（用戶學習掌握該軟件所耗費的時間及在具體業務流程上的簡化）
執行速度（多數是啟動速度，查詢速度，刷新速度及響應時間等因素）
用戶使用時產生錯誤的比率（在允許用戶任意使用的情況下，越少越好）
用戶滿意度（這里指的是用戶界面設計與功能設計的用戶評價）
下面我們分開對該類型錯誤進行分析與描述。

· 功能性

如果出現了以下情況之一，可以認為程序可能存在功能性錯誤：程序可以完成的某些事進行得非常困難，笨拙（繁瑣），令人迷惑甚至難以忍受。主要表現為以下幾個方面：

1）過度功能性

將簡單功能復雜化，這是設計上一個較常見的問題。嘗試進行太多工作任務的系統將很難學習和掌握，而且容易忘記。它要求大量的文檔（開發文檔，幫助文 檔和屏幕）。如果功能模塊間模塊過于緊密，則發生關聯錯誤的幾率要提高不少。有時候，用戶需要的只是簡單功能，而不要讓它過于膨脹成為一個“怪物”。

2）夸大的功能性印象

用戶手冊和營銷傳單不能使程序功能實現得更多，尤其是營銷傳單。記住，在用戶手冊中哪怕寧愿對功能略微輕描淡寫也不能夸大其詞（當然，我們并不希望這樣，我們總是要對此如實地進行編寫――這是我們的責任）。

3）對手頭任務的不適當性

我們可以把它直觀的理解為需求設計錯誤。對于任何一個項目，由于功能關鍵事項（就是常說的需求提煉）不存在、太有限（多數是因為沒有完成）或者太慢 （需要改進程序結構或是內部算法）而不能完成真正的工作。舉例來說，查詢一個有8000條記錄的數據庫需要1個小時（天哪，我想我連10分鐘都等不了）， 雖然說具備了查詢的功能，但是實在很令人懷疑此項功能是否會有人使用，更糟糕的情況是：由于用戶使用了該功能而造成的惡劣印象難以在短時間內消除――雖然 對于開發人員來說那可能只是一個參數拼寫錯誤了而已。

4）遺漏功能

功能沒有實現，卻出現在了用戶手冊中?；蛘呤潜緛響摼邆涞靥卣餍怨δ?，在程序只能看到一個“影子”（有其名無其實）。多半情況下是由于需求變更時 沒有對手冊進行檢查和更新，也有可能是因為遺漏了需求說明中應包含的功能（如果是那樣，需要好好檢查以前的工作方式是否正確）。

5）錯誤功能

一個本來應該完成查詢工作的功能卻干了排序的活兒。這種疏忽一般不是因為沒有實現功能，而是在分配功能的時候出現了問題，當然這種情況的發現和排除應該不是一件困難的事。

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

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

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

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

· 人機交互

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

1）遺漏信息

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

――沒有任何屏幕指令

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

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

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

――無正式文字證明（說明）的功能特征

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

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

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

――沒有光標

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

――沒有對輸入做出響應

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

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

選擇一個菜單項時，如果你的按鍵操作沒有回應，只要下一個屏幕立刻出現并且此屏幕上的標題與菜單項一樣，就可以視為正常。
如果程序忽視錯誤的命令或按鍵操作，當然可以不對其進行回應。
如果你告訴程序不要對輸入回應，它必須沉默，如果它進行了回應，應該立即告訴開發人員對其進行修改（可能是在忘記了繼續處理另一種情況）。
如果輸入的是安全性代碼（如密碼等），那么程序決不應在屏幕上做出不恰當的回應（如顯示你輸入的密碼明文）。
――在長期延遲時沒有表示其活動

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

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

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

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

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

――錯誤的、誤導的或令人迷惑的信息

每個錯誤都會讓你對程序顯示的所有其他東西產生懷疑。使用戶做出虛假歸納的細小錯誤，如遺漏條件或是不適宜的類比會比清楚的事實錯誤更讓測試人員感到惱火――因為更難對它們進行改正。

簡單的事實錯誤
在一個程序改變之后，更新屏幕顯示是低優先級任務，結果則是：屏幕上大量的信息過時。記?。簾o論何時程序發生改變，都要仔細檢查可能指示程序特征的每個消息，最簡單的辦法就是直接對更改后的屏幕進行刷新。

拼寫錯誤（錯別字）
我相信，這絕對不是設計上的問題，我也相信開發人員可能會不以為然。Oh，但是客戶會在乎，會抱怨這些的--還是改正它們吧。

不準確的簡化
在保持一個特征的描述盡可能簡單的愿望中，一條消息的創作者可能只覆蓋特征行為的最簡單方面，而忽略了重要條件。舉例來說，這種情況可能會引發歧 義，比如說關閉（到底是關閉文件還是關閉程序？）。作為一個測試人員，需要你足夠仔細的研究可能會出現問題的任何一個微不足道的細節。寧可錯殺，不能放 過?。m然要極力避免錯殺的情況。）

無效的比喻（圖標之類可以指示功能（特征）的事物）
例如：回收站的圖標可能不是一個好的比喻；對于文件一旦移除就永久消失的情況來說，碎紙機的圖標可能來得更好一些。

令人迷惑不解的特征（功能）名稱
如果一個命令名稱在計算機領域中或語言中有一個標準含義，就必須與其含義一致。別指望著胳膊能擰得過大腿，確定現行的標準是可靠的。

同一特征（功能）具有多個名稱
相同的功能特征只要一個名稱就夠了――只要能表述清楚；用戶可不一定有時間玩同義詞的游戲。另外，這種情況對軟件在用戶面前顯示的復雜度也有影響。

信息超載
不要讓你的文檔和幫助屏幕看起來太過專業――太多技術細節了。用戶會不耐煩的，況且效果也不好。如果實在需要，可以把他們另外列出。盡量使用直白，用戶能理解的話表述這些信息。另外，信息超載的另一個意義意味著煩瑣冗長的語句，那是要極力避免的。

數據何時得到保存
假設你輸入了一些程序需要保存的信息。當你進行切換或程序退出時，當你需要每隔一段時間進行保存時，它是否會把數據按照你想的方式進行保存呢？何時 完成呢？如果你對答案感到困惑，那就意味著可能有問題出現了。曾經在同事的項目中發現過很多次這樣的情況：每次修改后直接關閉程序，卻不提示用戶保存―― 我只知道，修改信息在關閉時也消失了。在對某個模塊進行修改時，你應密切注意這個問題。

很差的外部模塊性
外部模塊性指的是程序從外部看起來產品的模塊化程度（如同程序是可分割的實體）。你如何容易地理解模塊組件？很差的外部模塊會耗費大量的時間來學習產品，還會嚇跑新用戶--它看上去太復雜了！盡可能讓信息獨立展示出來，對任何特定任務而言，你需要知道的越少越好。

2）幫助文本和錯誤信息

幫助文本和錯誤信息通常被認為是產品的次要部分。它們可能是由初級程序員編寫的（比如我）或是作者編寫，對其進行更新的工作可能被賦予低優先級。然 而，作為產品而言，這又是必不可少的部分，一份看上去賞心悅目的幫助文檔可以“主觀 ”的降低軟件的學習難度和用戶的使用興趣。

當你感到困惑或是有麻煩時，尋求幫助或傾向于使用錯誤處理程序將是一個明智的選擇。你可能會覺得不爽，更多的時候是不耐煩。而如果其中有信息誤導了你，那么無異于火上澆油。以下列出的是我以往在審核幫助文檔及錯誤信息時碰到的一些常見問題。

不合適的閱讀層次
在計算機終端上，人們不能很好的進行閱讀。幫助文本和錯誤信息應該盡量措辭簡單明了，多用主動語態，盡量少使用技術術語，即便用戶中有計算機經驗也是如此。

冗長
避免你的幫助文檔和錯誤信息變成裹腳布。大多數用戶在需要更多信息時，會選擇通過菜單獲得進一步的信息。最好讓他們自己選擇所需的信息。

不合適的情緒語氣
盡量不要使用感嘆號，如“終止”、“崩潰”之類的帶有激烈意味的詞語都應如此。

事實錯誤
記得測試時需要測試那些更新過的功能，在舊的幫助上的方法可能在新軟件中是行不通的。這個時候開發人員的代碼更新日志就顯得很必要了，你不必對每項功能進行檢查，完全可以把這類回歸測試交給自動化測試工具完成，而你只需要關注其新內容即可。

上下文錯誤
不要把上下文之間的關系搞錯了，這會帶來閱讀時的不便。比較清晰的方法是首先列出上下文關聯列表，并按照操作順序的先后進行組織。

沒有識別出錯誤來源
通常，一個好的錯誤信息不僅可以指出是什么情況，而且還要指出為什么有些東西出了錯，以及如何處理此類錯誤的方法。在過往的項目中，常常有很多這樣 的問題：如“打印錯誤”、“保存錯誤”等等含糊的說明。如果用戶在獲得了錯誤信息后，還是一臉茫然，那就應該認真考慮一下錯誤說明的編寫方式是否可以再改 進一些了。

不能立刻重現的錯誤很可能是個大問題
沒有說明原因就禁止一個資源
如果程序嘗試使用打印機、內存控件等資源，卻做不到，錯誤信息應當包含的不僅僅是宣布失敗，還需要說明原因。

報告說沒有錯誤
首先，還是先承認這種情況是不太可能會出現的；錯誤信息只能由錯誤狀態出發，如果大部分是通常情況的調試消息，或者是少部分并不一定由某個缺陷引起的事件報告，那么，你可能就會忽略所有的錯誤信息。

3）顯示上的（問題）缺陷

這是一個比較客觀的問題，至少表面上看上去是這樣的。任何可見的錯誤都會產生讓人不快的感覺（盡管這些問題不一定很嚴重），用戶就不一定會相信或者 購買該產品?？赡苁且驗榇祟愬e誤大多都是屬于低級錯誤，通常并不受到開發人員和項目經理的重視，但是我們必須重視它――它就是問題（Bug），它就是我們 要找的東西之一。

另外提一點：總是拘泥于這類Bug――放過重要的功能需求，“吹毛求疵”――可能會使測試失去意義，它可能是造成開發人員和項目經理不重視測試的一個借口。盡管如此，我們還是要提出這類問題，但并不是說可以遺漏重要的功能需求。

――數據寫到了錯誤的屏幕位置

光標提示在正確的位置，但是數據卻顯示在屏幕錯誤的位置（張冠李戴）。這類錯誤對開發人員而言，不應該是個很棘手的問題，但對用戶來說，那是致命的。

――未能清除部分屏幕

一條信息在屏幕上顯示了幾秒鐘，接著卻只有一部分被擦除了；或者你對前一問題的回應仍然留在屏幕上，我們固然可以以計算機整體性能為借口，但也不能 排除技術因素。為了輸入一些新東西，不得不在提示或不相關的回應上輸入，這是令人頭疼而且迷惑不解的。在以前測試的項目中，就曾經出現過由于屏幕未正確刷 新導致的清屏不完整及無故彈出不相關提示的問題――這種問題比較普遍，需要多加注意。

――未能突出顯示部分屏幕

如果程序常常需要突出顯示某個特定類別的項目，例如提示或者在激活窗口中的所有文本，那么它就必須一直這么做。

――未能清除突出顯示

屏幕位置的屬性與顯示的文本分開儲存時這是很普遍的。程序員刪除了突出顯示的文本，但是忘記了從屏幕的那一區域清除突出顯示。這類問題一般都和數據刷新有關系，無論是界面上的處理還是系統底層的處理。

――顯示的字符串錯誤或不完整

顯示的消息可能是毫無價值的文本，一個冗長的信息的一個片斷或是一條應該顯示在其他時間出現的完整信息。這其中任何一條都可能反映出程序邏輯上，用來發現消息文本的指針的值或者已儲存的文本副本中的錯誤。

――顯示信息過長或者不夠長

消息在屏幕上顯示的時間應該足夠長，至少應該保持到能讓用戶讀到結束為止。如果對同一條消息有時顯示時間長，有時顯示時間短則需要注意，這可能預示著外部資源之間的競爭條件（比如對內存資源的爭奪），往往這些條件是在我們考慮之外的，需要認真對待。

4）界面布局的顯示

屏幕看上去應該是很有條理的，別讓它看起來像是一個亂糟糟的房間。不同類別的對象應該在可預知的區域分開顯示。你可以參考一些關于UI布局的文章，但歸結起來說：顯示布局應該很容易讓你在屏幕上找到你要的東西。

――從美學角度看屏幕布局很拙劣

屏幕可能是不平衡的，大多數情況下是這樣子，行或者列不對齊，或者只是看起來很“糟糕”。好好利用你的鑒賞力，如果沒有信心，可以問問別人的意見， 參考一些界面設計很合理的軟件。如果對你而言它的布局的確看起來很糟，相信你的直覺，肯定有什么東西錯了，盡管現在你還沒有發現。

――菜單布局錯誤

這是最常見的問題之一了：我們有時候會發現在編輯菜單下突然冒出了一個文件關閉的選項，而一般它是放在文件一欄下的。在很多的參考文獻中，已經對這方面的內容做了比較詳實的說明，我想強調的是以下一些問題：

相似的或從概念上相關的菜單選擇應該分組，或者應該在屏幕上說明。
選擇一個菜單項通常應該獨立。為了獲得一個獨立的結果，用戶不應該必須在不同的菜單上做出兩個或更多的選擇（這可絕對“難”用）。
通過鍵入其首字母來選擇菜單項通常要比使用數字來得好。當然，你要留神不要給菜單項過于奇怪的名稱；另外，還要注意不要在同一欄下面不要出項重復的字母。
――對話框布局錯誤

對話框應該一致。如：他們應該一致使用大小寫，字體和文本對齊規則。對話框標題應當占據某個一致的位置，并與用來調用該對話框的命令名相符合。相 同的快捷方式在不同對話框之間應該起相同作用――如<ESC>不應取消某些對話框，而在其他類似情況下完成其他的任務。
對話框中的控件布局必須合理安排。應使用必要的間隔把組隔開。
選擇和錄入區域應該垂直和水平排列，這樣用戶就可以以直線模式操作光標的運動（為了方便）。
留意對話框之間的相互依賴性。如果某個對話框中的選擇將最終決定另一個對話框的選項將是令人困惑的。如果程序不得不這樣做，務必要求開發人員給出具體提示。
――模糊不清的指示

你應該總是知道去哪里查找以找出下一步。如果屏幕排得很滿，總是應該為命令和消息留出一塊空間。使用氣泡顯示信息也是一個不錯得選擇。

――閃爍的誤用

閃爍的圖片或文本很引人注意，不過記得不要太多閃爍。太多的閃爍會讓人覺得不舒服。你應該每次最多只讓一個目標進行閃爍而且頻率不能太高。

――顏色的誤用

不要太多顏色，它會讓我們的眼睛很疲勞。顏色不應該使我們分散注意力，也不能使屏幕看上去雜亂無章，盡量使用統一風格的顏色，如果程序的顏色組合看上去很難看，抗議吧，沒有人會愿意買毫無美感的產品的。

――過于依賴顏色

如果程序在項之間使用顏色為唯一分隔符，那么它將限制使用者的范圍，對于一些特殊的產品，需要考慮到例如色盲之類對顏色不敏感的人群或是使用單色顯示器的用戶。

――與整體風格不符合

如果與計算機相關的風格提供了某種一致性和便利，盡量好好利用。也許對程序員來說可以使用更好的技術來代替，對于用戶來說也未必不是不可接受的。例 如：在習慣了鼠標和圖標之后，恐怕很少有用戶會習慣敲擊鍵盤書寫命令來完成計算機可以使用鼠標完成的工作。當大多數其他的程序以某種特定方式在屏幕的特定 位置顯示錯誤信息時，新程序也應該是這樣的。

――不能去掉屏幕上的信息

在屏幕上某個部分的可用命令選擇菜單是很好的選擇。一旦用戶精通了程序，有些菜單就會成為屏幕空間資源的浪費。你應該可以提交一個命令能去掉和重新調用它。這點上，值得向微軟的Office系列軟件學習。

3、命令結構和錄入

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

不一致性

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

“最優化”

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

――不一致的縮寫

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

――不一致的終止規則

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

――不一致的命令選項

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

――名稱相似的命令

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

――不一致的大寫

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

――不一致的菜單位置

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

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

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

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

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

――不一致的編輯規則

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

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

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

――浪費時間

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

――曲折路徑

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

――不能采用的選擇

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

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

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

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

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

菜單

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

――過于復雜的菜單層次

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

－不適當的菜單導航系統

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

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

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

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

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

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

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

――鍵盤不能正確使用

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

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

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

――光標和編輯鍵的非標準使用

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

――功能鍵的非標準使用

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

――不能過濾無效鍵

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

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

鍵盤上的燈或屏幕信息應該告訴你何時你的Num Lock鍵和其他類似的狀態轉換特征是開著的。

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

你應該能夠告訴計算機從它正在進行的工作中退出；程序應該總是能辨別出任何其他系統指定的鍵――即那些本機上的程序通?？梢院芸熳R別出來的鍵。

4、遺漏的命令

1）狀態轉換

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

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

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

――不能在程序中間退出

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

――不能在命令中間停止

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

――不能暫停

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

2）危機預防

系統故障和用戶錯誤發生了，程序應具備將其后果降到最低的能力。

――沒有備份工具

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

――不能撤銷

撤銷一個你已經發出的編輯命令，至少是一步?；謴捅粍h除的文件是一種受限制的撤銷，它能讓你恢復錯誤刪除的數據。撤銷是可取的，恢復被刪除文件也應是必須的。

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

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

――沒有增量保存

當輸入大量文本或數據時，你應該能告訴程序相隔一定時間對你的工作進行保存，至少應該提供用戶此類選項。對于突發的掉電和硬件損壞情況這樣做將是非常有好處的。

3）由用戶進行的錯誤處理

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

――沒有用戶能指定的過濾器

當設計數據錄入表格和電子表格模板時，你應該能夠讓每個區域指定什么樣的數據類型有效、程序應忽略或拒絕什么。例如，你可以讓程序拒絕數字、字母、不在某個特定范圍內的數值，一個有效日期或者與磁盤上匹配的日期等等。

――難用的錯誤更正

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

――不能包括注釋

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

――不能顯示變量之間的關系

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

4）其他問題

――隱私和安全性

對于某些特定的程序，需要考慮數據的充分安全性，保護公司，集體或個人的機密和隱私。在多用戶系統上，你應該能很好的隱藏你的文件（一般都是通過加密手段實現的），并且能很好的鎖定你的文件不被篡改或閱讀。

――安全性的困擾

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

――隱藏菜單

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

――不支持標準O/S特征

例如：如果系統使用了子目錄，那么程序就應該能引用其他子目錄。如果操作系統提供了通配符（比如*），那么程序也應該能使用。

――不允許長名稱

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

5、程序僵化

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

1）用戶可調整性

――不能關掉噪音

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

――不能關閉大小寫區分

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

――不能配合手邊的硬件

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

――不能改變設備初始化

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

――不能關閉自動保存

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

――不能改變滾動速度

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

――不能重復上次的操作

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

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

此類問題對數據編輯特別是文本編輯類的程序較為常見。應當提供保存的文件列表，除非用戶禁止了它。

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

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

――無法保存定制的命令

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

――特征更改的副作用

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

――無限可調整性

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

2）控制方式

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

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

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

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

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

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

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

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

――人工智能與自動化

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

――過?；蚨嘤嗟谋匦栊畔?/p>

過剩和多余的必需信息就像我們身上的贅肉一樣討厭。有些程序會請求他們從來不會使用或者只會用來在屏幕上顯示一次的信息，或者會要求你重新輸入你已經輸入過的數據――并非是為了驗證，僅僅只是重新獲取一次數據，這對時間的浪費是非常驚人的。

――不必要的步驟重復

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

――不必要的限制

為什么要把一個數據庫限定為如此多的字段或記錄，或限制一個電子表格僅使用數字，把一個項目經理限制在如此多的任務中，一個字處理程序限制在如此多的字符呢？對性能或可靠性而言并非必要的限制不應該成為約束條件。

6、性能

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

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

程序速度：執行標準任務的速度有多快？
用戶吞吐量：你能使用程序執行標準任務的速度有多快？
感覺到的性能：在用戶看來，該程序速度有多塊？它是否令你滿意？
無論如何定義，程序速度總是一個關鍵因素。但是一個界面設計拙劣的快速程序無論怎么看都要比它實際的運行和處理速度要慢得多。

1）降低程序速度

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

2）緩慢回應

程序應立即對輸入做出響應，如果在你輸入一個字母的時刻和你看到這個字母的時刻有延遲，顯然，程序就太慢了?？焖俜答亴θ魏屋斎胧录急仨毷怯行Ф沂潜匾?，它包括：鼠標，鍵盤，軌跡球，鍵盤等等。

3）如何減少用戶吞吐量

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

任何可能使用戶錯誤更可能發生的事情。（培訓不周，用戶習慣，程序風格等等）
緩慢的錯誤恢復。如：在輸入一長串字符后發現錯誤卻必須要重新輸入。
任何使你感到迷惑，卻得不到幫助文檔或手冊提供資料的事情。
輸入很多，卻做得很少的程序――這不是一個好程序。如：把一個簡單任務劃分成很小的子任務，要求對所有事情進行確認等等。
在測試時，使用比較性測試是個有效的方法：即把開發中的產品與競爭對手的產品進行比較，如果人們使用你的產品花費的時間要更長，那么發現這個問題就是有意義的。

4）反應拙劣

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

5）沒有提前輸入

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

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

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

7）程序太多提示和詢問

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

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

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

7、輸出

程序的輸出應如輸入一樣完整。它要求更精確，盡量快速和能實現多路徑及對輸出內容更有效的管理，這四類標準幾乎決定了輸出功能的主要表現特性。

1）不能輸出某種數據

你應該能打印出你輸入的任何信息，打印不出輸入的內容對任何程序而言都是致命傷。

2）不能重定向輸出

你應該可以重定向輸出。特別是，你應該能向磁盤發送一個很長的“打印輸出”標記，并稍后打印該磁盤文件。程序不應該阻止你把數據輸出發送到預料之外的設備，如繪圖儀，磁帶，打印機等。

3）與一個后續過程不兼容的格式

如果一個程序聲明能夠以第二個程序可以理解的格式保存數據，那么就應該測試它是否可以真正做到。這意味著購買或借用第二個程序的副本。使用第一個程序保存數據，用第二個程序讀數據，同時看看第二個程序得到了什么，這是對此進行測試的最簡單方法。

4）必須輸出的很少或很多

你應該可以修改報告，從而呈現你需要的信息。不得不在僅包含少量有用信息行的打印輸出的大量頁中找出所需信息，幾乎和沒有得到信息一樣糟糕。

5）不能控制輸出布局

你應該可以改變字體，對輸出信息增加特殊標記來強調信息。你應該可以修改信息之間的間距，最低限度來說，程序應該可以以一種由合適文字處理進行修飾的格式把報告輸出到磁盤文件。

6）荒謬的精度輸出級別

要是說4.2加上3.1等于7.3000000或者說3.1111+2.11等于5.22110102都是很愚蠢的。在最終輸出的結果中，程序應該按照規定的格式和精度輸出最后的數據。

7）不能控制表或圖的標記

你應當能夠改變字型，措辭及任何說明，包括標題，表格，圖形或是圖表中文本的位置。

8）不能控制圖形的縮放比例

繪圖程序應該提供默認的垂直和水平比例，不要告訴我你最后輸出打印報表中的圖形超出了整個頁面或是只占據了整個頁面的一角。

二、錯誤處理

在處理錯誤時發生的錯誤通常是最常見的缺陷。錯誤處理產生的錯誤包括：未預料到錯誤發生的可能性并防止其發生，沒有注意錯誤狀態，以及較嚴重的：程序可能與錯誤數據一起工作并最終產生錯誤結果的情況。

1、錯誤預防

程序應具備這種能力：它能保護自己不受到系統其他部分的影響（包括有害輸入和有害處理）。如果程序可能與錯誤數據共同工作，確保其在發生嚴重可怕的影響之前（如程序崩潰，數據丟失與錯誤，系統崩潰等），檢查并消除這些問題。

1）不充分的初始狀態驗證

如果內存的某個區域必須以其中所有位都是0開始，那么程序應該可以運行一個抽樣檢查，而不是假定已經存在0值。這會導致程序初始化時發生內存錯，甚至不能啟動。

2）不充分的用戶輸入檢查

此類問題非常常見，開發人員可能會在編寫程序時遺漏掉大量這方面的問題。告訴人們輸入1位到3位數是不夠的，有些人可能會輸入5位甚至更多，也有人 會輸入特殊字符或是運算符，還有些人會按下功能鍵一次或多次，如果程序允許輸入，那么程序就應能順利應付，而不是一打非專業人士不能明白的提示甚至更糟的 情況。

3）對受損數據不能充分預防

沒有人能保證磁盤上的數據是好的?？赡苁怯腥艘呀浘庉嬤^或者根本是有硬件問題。即使開發人員認定在保存前的文件是有效的，那么他也應該檢查（校驗）下次打開的是否是同一個文件。

4）不充分的參數傳遞測試

一個子程序不應該假定得到了正確的調用（事實上，采用相反的想法可能會讓測試進行得更加順利一些）。它應該確保傳遞給它的數據在其可控制的范圍之內。

5）針對操作系統的預防不充分

操作系統存在缺陷――不光是過去，現在甚至將來也是，應用程序可能會觸發其中存在的問題。如：如果開發人員知道，他把數據送到磁盤后很快又把數據送到打印機，會引起一些操作系統的崩潰，那么他就應該確保程序在任何情況下都不會這樣做。

6）不適當的版本控制

如果可執行代碼不止存在于一個文件中，那么有人會嘗試把某一文件的新版本和老版本一起使用，客戶對其軟件升級使得這類問題時常發生，但是又不能明白出了什么問題。新版本應確保所有的代碼都是最新的，當然也要對老版本有完整的備份。

7）針對惡意使用的不充分預防

人們有時會有意無意的提供程序有害輸入，或者嘗試觸發錯誤狀況（特別是做測試的家伙們）。不要假定“任何有理智的人都不會這么做”，相信我：程序不完全是為了“有理智”的人開發的。

2、錯誤檢測

程序通常有足夠的可用信息來檢測數據中或其操作中的錯誤。這部分內容將指導一部分常見的錯誤檢測方式并對其進行歸類。

1）忽視溢出

一個數值計算結果對于程序來說太大以至于無法處理時，就會產生溢出。溢出由較大數字相加和相乘或者被0除或是由于過小的分數除而引起。在有既定規則的情況下，溢出是很容易檢測到的。

2）忽視不可能的值

在計算機當中，幾乎沒有什么不可能發生的事。程序應該檢查其變量，以確保它們在合理的界限之內，它應可以捕獲并拒絕如2月31日這樣的日期值。如果 當變量為0時，程序完成某動作，變量為1時完成另一工作，并假設其他所有值都是不可能，那么就必須保證變量只能為0或者是1，對其他所有值進行額外的處 理。在一個項目中，經過數年維護編程后，舊的假定就不一定安全了。

3）忽視看上去不真實的值

有些人可能會從自己帳戶里提取100，000，000，000的錢，那么就算他有這么多錢，也應該在通過交易之前向幾個不同的人進行確認。這類看似荒唐的用例往往包藏著錯誤的禍心，應該小心應付。

4）忽視錯誤標志

程序調用了一個子程序，結果操作不成功，它在一個被稱為錯誤標志的特殊變量中報告了該失敗。與通常一樣，程序能檢查或忽略它，并把從例程返回的誤用數據當作真實的進行處理。

5）忽視硬件缺陷或錯誤情況

程序應該假定它能連接的設備是失敗的，許多設備能夠發送警告某件事情出錯的返回信息。如果有設備這樣做了，停止嘗試與其交互，并向某人或更高級別的控制程序報告該事件。不能忽視該類情況以避免造成不必要的困擾。

6) 數據比較

結算銀行存折時，你有一個你自己認為的余額數值，銀行也會提供一個余額數值。在考慮了服務費，銀行利息，最近帳單等等數據之后，兩個數據不吻合，那么就要好好查一查了。在互相檢查兩個數據集或計算結果集時，也會產生類似的情況。

3、錯誤恢復

程序中存在錯誤，程序已經檢測到了錯誤，而且現在正設法對其進行處理。許多錯誤恢復代碼只是稍微進行了測試，或者根本沒有進行測試。錯誤恢復例程中的缺陷可能比原始問題更嚴重。

1）自動錯誤更正

通過檢查其他數據或規則集，有時程序不僅能檢測錯誤，而且還能糾正錯誤，而用不著麻煩任何人。這樣的程序是令人滿意的，但僅當這種“糾正”是正確的情況時才是如此。

2）未能報告一個錯誤

程序應該報告任何檢測到的內部錯誤，即使它能自動糾正錯誤產生的后果也一樣。在稍微不同的環境下，它可能檢測不到相同的錯誤。程序可以向用戶報告這 一錯誤，也可以向一個多用戶系統的操作員，向磁盤上的日志文件，或者是這些對象的任一組合報告錯誤?？傊?，不管怎么樣，只要發生了，它就必須報告。

3）未能設置一個錯誤標志

某子程序被調用，但是結果失敗，假定它在失敗時設置了一個錯誤標志，它把控制返回給調用程序，卻沒有對這個標志進行設置，那么調用程序就會把無用數據當作有效數據傳回去，這是應堅決避免的狀況。這可能會造成數據冗余，臟數據或是直接導致當前操作失效，嚴重的則會引起崩潰。

4）程序要走向何方？

一部分代碼失效了。它記錄了錯誤，并設置了一個錯誤標志，接下來干嘛呢？尤其是經過了幾個跳轉的情況下，它如何才能得知程序中的什么地方返回了控制？

5）中止錯誤

停止了程序，或者當它在檢測到錯誤時自動停止了，那么它是否關閉了任何打開的輸出文件呢？它是否在關閉時會記錄退出的原因呢？在最普通的條件下，在即將結束之前它是否進行了整理或者它只是結束但可能留下一團混亂呢？這都是開發人員和測試人員需要考慮的問題之一。

6）從硬件問題中恢復

程序應該適度地處理硬件故障。如果磁盤或其目錄已滿，你應該能夠放入一張新的磁盤，而不只是關閉了你所有的數據。如果一個設備很長時間還沒有準備好接收輸入，你就沒有應該假定它已經斷線或斷開連接而進行處理。程序決不能夠讓我們永遠在那里坐等。

7）不能從遺失磁盤中退出

假定你的程序要求你插入一張具有它需要的文件的磁盤，如果插入的磁盤不正確，它會再次提醒你，直到插入了正確的磁盤為止。然而，如果沒有正確的磁盤，你就沒有任何辦法可以退出，除非你重啟系統。不，這種做法是極端蠻橫的，決不能允許出現這樣的問題。

4、邊界相關的錯誤

一個邊界描述了程序的一個改變點，假定程序在邊界的一邊以某種方式做所有事，而在邊界的另一邊，它以不同的方式完成所有事。

邊界相對立的兩邊的典型“東西”就是數據值。存在三種標準邊界缺陷：

邊界情況的處理不當
如果一個程序把任何小于100的兩個數相加，不接收任何大于100的數，那么當你恰恰輸入100時它會做何反應？它又該怎么做？

錯誤邊界
規格說明表示，程序應該把任意兩個小于100的數相加，同時不接收大于95的數。

邊界外情況的錯誤處理
邊界某一邊的值是不可能，不可信，不能接收，或是預料之外的，沒有為其編寫任何處理代碼。程序是否成功拒絕了大于100的值？或者是否當它獲取了一個大于100的值時就會崩潰？

我們把邊界的概念看得更廣泛，邊界描述了考慮一個程序以及它在其極限周圍得行為得方式。存在很多種的極限：最大，最小，最新，最舊，最近，第一個等等。相同類型的缺陷可以伴隨其中任何一種極限而產生，我們可以用相同或類似的觀點考慮它們。

不同邊界錯誤的考慮方式

不同類型的邊界，其考慮方式也是不同的，但是其思想基本上都相近：無外乎上溢出與下溢出。

1）數值邊界

有些數值邊界是任意的，如大于100；而有些則要描述自然極限，如三角形的特征和子母的ASCII碼等。

2）與一個邊界相等

在一個列表中的所有元素可能相同，也可能不同。如果你試著對任一列表進行排序，會發生什么？如果列表由數字組成，當你嘗試計算平均值，標準偏差，對稱系數時又會發生什么？（以上是概要統計概念，按算法，對稱系數可能會計算為0或引起被0除的錯誤。）

3）多種多樣的邊界

一個輸入串可以長達80個字符么？如果你輸入79、80或81個字符會如何？程序是否在每種情況下都接收你的輸入？一個列表可以只是一個元素么？沒有元素可以么？僅含一個數值的標準偏差又是什么呢？

4）空間中的邊界

例如，如果一個繪圖程序繪制了一個圖形，并在其周圍繪制了一個方框，那么該如何處理一個應當在方框外正確顯示的點？

5）時間的邊界

假定程序顯示了一個提示，停留60秒等待你回應。然后，如果你沒有輸入內容就顯示菜單，如果正當它開始顯示菜單時，你開始輸入內容，會發生什么？

假定你在計算機仍然在從磁盤中裝入程序時按下空格鍵，發生了什么事？空格鍵是被發送給操作系統，為正在裝載的程序進行了保存，還是僅僅因為預料之外而導致計算機崩潰？

6）硬件相關邊界

如果一臺主機可以連接100臺終端，那么當你加入99，100，101臺時會發生什么？如果你讓100臺終端同時登陸會怎樣？

如果磁盤已經塞滿了會如何？如果一個目錄能保存1000個文件，當你嘗試保存第999、1000、1001個的時候會發生什么？如果打印機有較大的輸入緩沖區，當你的數據填滿緩沖區，但是卻還沒有更多數據要傳遞時，會發生什么？當打印機缺紙或顏料用完了又會發生什么？

5、計算錯誤

程序計算一個數據得到了一個錯誤的結果。發生計算錯誤通常因為下面三種類型的原因：

很差的邏輯：
可能存在一個錄入錯誤，開發人員可能會在編制程序時無意中錯誤簡化了復雜關系地表達式，或者由于拼寫錯誤或筆誤導致。另外一種糟糕的情況則是設計錯誤，開發人員關于代碼如何做的概念可能一開始就錯了。

很差的算法：
如果1＋1＝1，可以理解為一種特殊邏輯，但是如果把它作為數值運算，恐怕是沒有人會同意的。無論何時，一個錯誤的算法總不會得出正確的結果。

不精確計算：
由于使用了舍入的計算方法，很可能在計算時丟失精度。

【小結】

這篇文章最早成形于2004年10月，當時正接手一個項目的黑盒測試工作。然而，在對軟件項目實施黑盒測試的過程中，的確也看到了很多值得思考的地 方。作為一名剛進入測試行業的學步小兒，也談不上有什么豐富的經驗累積，唯希冀本文能給剛進入測試領域的同仁提供了一些有價值的參考。