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

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

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

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

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布局的文章，但歸結起來說：顯示布局應該很容易讓你在屏幕上找到你要的東西。

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

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

――菜單布局錯誤

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

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

――對話框布局錯誤

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

――模糊不清的指示

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

――閃爍的誤用

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

――顏色的誤用

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

――過于依賴顏色

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

――與整體風格不符合

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

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

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

原文轉自：http://www.anti-gravitydesign.com