黑盒測試

黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程式看作一個不能打開的黑盒子，在完全不考慮程式內部結構和內部特性的情況下，在程式接口進行測試，它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試著眼於程式外部結構，不考慮內部邏輯結構，主要針對軟體界面和軟體功能進行測試。

黑盒測試是以用戶的角度，從輸入數據與輸出數據的對應關係出發進行測試的。很明顯，如果外部特性本身設計有問題或規格說明的規定有誤，用黑盒測試方法是發現不了的。

基本介紹

• 中文名：黑盒測試
• 外文名：Black Box Testing
• 別名：功能測試
• 測試角度：用戶
• 套用領域：計算機
• 作用：發現軟體錯誤

作用

黑盒測試法注重於測試軟體的功能需求，主要試圖發現下列幾類錯誤。

功能不正確或遺漏；

界面錯誤；

輸入和輸出錯誤；

資料庫訪問錯誤；

性能錯誤；

初始化和終止錯誤等。

測試方法

概述

從理論上講，黑盒測試只有採用窮舉輸入測試，把所有可能的輸入都作為測試情況考慮，才能查出程式中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但可能的輸入進行測試。這樣看來，完全測試是不可能的，所以我們要進行有針對性的測試，通過制定測試案例指導測試的實施，保證軟體測試有組織、按步驟，以及有計畫地進行。黑盒測試行為必須能夠加以量化，才能真正保證軟體質量，而測試用例就是將測試行為具體量化的方法之一。具體的黑盒測試用例設計方法包括等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法、場景法等。

等價類劃分的辦法是把程式的輸入域劃分成若干部分（子集），然後從每個部分中選取少數代表性數據作為測試用例。每一類的代表性數據在測試中的作用等價於這一類中的其他值。該方法是一種重要的，常用的黑盒測試用例設計方法。

劃分等價類

1) 劃分等價類： 等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對於揭露程式中的錯誤都是等效的，併合理地假定：測試某等價類的代表值就等於對這一類其它值的測試.因此，可以把全部輸入數據合理劃分為若干等價類，在每一個等價類中取一個數據作為測試的輸入條件，就可以用少量代表性的測試數據.取得較好的測試結果.等價類劃分可有兩種不同的情況：有效等價類和無效等價類。

有效等價類：是指對於程式的規格說明來說是合理的，有意義的輸入數據構成的集合.利用有效等價類可檢驗程式是否實現了規格說明中所規定的功能和性能。

無效等價類：與有效等價類的定義恰巧相反。

設計測試用例時，要同時考慮這兩種等價類.因為，軟體不僅要能接收合理的數據，也要能經受意外的考驗.這樣的測試才能確保軟體具有更高的可靠性。

劃分等價類

2）劃分等價類的方法：下面給出六條確定等價類的原則。

①在輸入條件規定了取值範圍或值的個數的情況下，則可以確立一個有效等價類和兩個無效等價類。

②在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下，可確立一個有效等價類和一個無效等價類.

③在輸入條件是一個布爾量的情況下，可確定一個有效等價類和一個無效等價類。

④在規定了輸入數據的一組值（假定n個），並且程式要對每一個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類。

⑤在規定了輸入數據必須遵守的規則的情況下，可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）。

⑥在確知已劃分的等價類中各元素在程式處理中的方式不同的情況下，則應再將該等價類進一步的劃分為更小的等價類。

3）設計測試用例：在確立了等價類後，可建立等價類表，列出所有劃分出的等價類：

輸入條件

輸入條件 有效等價類 無效等價類

然後從劃分出的等價類中按以下三個原則設計測試用例：

①為每一個等價類規定一個唯一的編號。

②設計一個新的測試用例，使其儘可能多地覆蓋尚未被覆蓋地有效等價類，重複這一步.直到所有的有效等價類都被覆蓋為止。

③設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重複這一步.直到所有的無效等價類都被覆蓋為止。

邊界值分析法

邊界值分析是通過選擇等價類邊界的測試用例。邊界值分析法不僅重視輸入條件邊界，而且也必須考慮輸出域邊界。它是對等價類劃分方法的補充。

（1）邊界值分析方法的考慮：

長期的測試工作經驗告訴我們，大量的錯誤是發生在輸入或輸出範圍的邊界上，而不是發生在輸入輸出範圍的內部.因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。

使用邊界值分析方法設計測試用例，首先應確定邊界情況.通常輸入和輸出等價類的邊界，就是應著重測試的邊界情況.應當選取正好等於，剛剛大於或剛剛小於邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。

（2）基於邊界值分析方法選擇測試用例的原則：

1）如果輸入條件規定了值的範圍，則應取剛達到這個範圍的邊界的值，以及剛剛超越這個範圍邊界的值作為測試輸入數據。

2）如果輸入條件規定了值的個數，則用最大個數,最小個數，比最小個數少一，比最大個數多一的數作為測試數據。

3）根據規格說明的每個輸出條件，使用前面的原則1）。

4）根據規格說明的每個輸出條件，套用前面的原則2）。

5）如果程式的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最後一個元素作為測試用例。

6）如果程式中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界上的值作為測試用例。

7）分析規格說明，找出其它可能的邊界條件。

錯誤推測法

錯誤推測法是基於經驗和直覺推測程式中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法.

錯誤推測方法的基本思想： 列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例。 例如，在單元測試時曾列出的許多在模組中常見的錯誤. 以前產品測試中曾經發現的錯誤等，這些就是經驗的總結。還有，輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況。可選擇這些情況下的例子作為測試用例。

因果圖法

前面介紹的等價類劃分方法和邊界值分析方法，都是著重考慮輸入條件，但未考慮輸入條件之間的聯繫，相互組合等。 考慮輸入條件之間的相互組合，可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情，即使把所有輸入條件劃分成等價類，他們之間的組合情況也相當多. 因此必須考慮採用一種適合於描述對於多種條件的組合，相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）。

因果圖方法最終生成的就是判定表。它適合於檢查程式輸入條件的各種組合情況。

生成測試用例

（1) 分析軟體規格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），並給每個原因和結果賦予一個標識符。

(2) 分析軟體規格說明描述中的語義。找出原因與結果之間，原因與原因之間對應的關係. 根據這些關係，畫出因果圖。

(3) 由於語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現. 為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。

(4) 把因果圖轉換為判定表。

(5) 把判定表的每一列拿出來作為依據，設計測試用例。

從因果圖生成的測試用例（局部，組合關係下的）包括了所有輸入數據的取TRUE與取FALSE的情況，構成的測試用例數目達到最少，且測試用例數目隨輸入數據數目的增加而線性地增加。

前面因果圖方法中已經用到了判定表。判定表（Decision Table）是分析和表達多邏輯條件下執行不同操作的情況下的工具.在程式設計發展的初期，判定表就已被當作編寫程式的輔助工具了.由於它可以把複雜的邏輯關係和多種條件組合的情況表達得既具體又明確。

判定表組成法

條件樁（Condition Stub）：列出了問題的所有條件.通常認為列出的條件的次序無關緊要。

動作樁（Action Stub）：列出了問題規定可能採取的操作.這些操作的排列順序沒有約束。

條件項（Condition Entry）：列出針對它左列條件的取值.在所有可能情況下的真假值。

動作項（Action Entry）：列出在條件項的各種取值情況下應該採取的動作。

規則：任何一個條件組合的特定取值及其相應要執行的操作.在判定表中貫穿條件項和動作項的一列就是一條規則.顯然，判定表中列出多少組條件取值，也就有多少條規則，既條件項和動作項有多少列。

判定表的建立步驟

①確定規則的個數。假如有n個條件.每個條件有兩個取值（0,1），故有2n種規則。

②列出所有的條件樁和動作樁。

③填入條件項。

④填入動作項.等到初始判定表。

⑤簡化.合併相似規則（相同動作）。

B. Beizer 指出了適合使用判定表設計測試用例的條件：

①規格說明以判定表形式給出，或很容易轉換成判定表。

②條件的排列順序不會也不影響執行哪些操作。

③規則的排列順序不會也不影響執行哪些操作。

④每當某一規則的條件已經滿足，並確定要執行的操作後，不必檢驗別的規則。

⑤如果某一規則得到滿足要執行多個操作，這些操作的執行順序無關緊要。

正交試驗設計

就是使用已經造好了的正交表格來安排試驗並進行數據分析的一種方法，目的是用最少的測試用例達到最高的測試覆蓋率。

場景法

軟體幾乎都是用事件觸發來控制流程的，事件觸發的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟體設計方面的思想也可以引入到軟體測試中，可以比較生動地描繪出事件觸發時的情景，有利於測試設計者設計測試用例，同時使測試用例更容易理解和執行。

基本流和備選流

基本流和備選流：如下圖所示，圖中經過用例的每條路徑都用基本流和備選流來表示，直黑線表示基本流，是經過用例的最簡單的路徑。備選流用不同的色彩表示，一個備選流可能從基本流開始，在某個特定條件下執行，然後重新加入基本流中（如備選流1和3）；也可能起源於另一個備選流（如備選流2），或者終止用例而不再重新加入到某個流（如備選流2和4）。

流程

測試計畫

首先，根據用戶需求報告中關於功能要求和性能指標的規格說明書，定義相應的測試需求報告，即制訂黑盒測試的最高標準，以後所有的測試工作都將圍繞著測試需求來進行，符合測試需求的應用程式即是合格的，反之即是不合格的；同時，還要適當選擇測試內容，合理安排測試人員、測試時間及測試資源等。

測試設計

將測試計畫階段制訂的測試需求分解、細化為若干個可執行的測試過程，並為每個測試過程選擇適當的測試用例（測試用例選擇的好壞將直接影響到測試結果的有效性）。

測試開發

建立可重複使用的自動測試過程。

測試執行

執行測試開發階段建立的自動測試過程，並對所發現的缺陷進行跟蹤管理。測試執行一般由單元測試、組合測試、集成測試、系統聯調及回歸測試等步驟組成，測試人員應本著科學負責的態度，一步一個腳印地進行測試。

測試評估

結合量化的測試覆蓋域及缺陷跟蹤報告，對於套用軟體的質量和開發團隊的工作進度及工作效率進行綜合評價。

優點

1. 基本上不用人管著，如果程式停止運行了一般就是被測試程式crash了

2. 設計完測試用例之後，下來的工作就是爽了，當然更苦悶的是確定crash原因

缺點

1. 結果取決於測試用例的設計，測試用例的設計部分優勢來源於經驗，OUSPG的東西很值得借鑑

2. 沒有狀態轉換的概念，一些成功的例子基本上都是針對PDU來做的，還做不到針對被測試程式的狀態轉換來實現

3. 就沒有狀態概念的測試來說，尋找和確定造成程式crash的測試例是個麻煩事情，必須把周圍可能的測試例單獨確認一遍。而就有狀態的測試來說，就更麻煩了，尤其不是一個單獨的testcase造成的問題。這些在堆的問題中表現的更為突出。

工具選擇

如何高效地完成功能測試？選擇一款合適的功能測試工具並培訓一支高素質的工具使用隊伍無疑是至關重要的。儘管現階段存在少數不採用任何功能測試工具，從事功能測試外包項目的軟體服務企業。短期來看，這類企業盈利狀況尚可，但長久來看，它們極有可能被自動化程度較高的軟體服務企業取代。

用於功能測試的工具軟體有很多，針對不同架構軟體的工具也不斷推陳出新。這裡重點介紹的是其中一個較為典型自動化測試工具，即Mercury公司的WinRunner。

WinRunner是一種用於檢驗應用程式能否如期運行的企業級軟體功能測試工具。通過自動捕獲、檢測和模擬用戶互動操作，WinRunner能識別出絕大多數軟體功能缺陷，從而確保那些跨越了多個功能點和資料庫的應用程式在發布時儘量不出現功能性故障。

WinRunner的特點在於： 與傳統的手工測試相比，它能快速、批量地完成功能點測試； 能針對相同測試腳本，執行相同的動作，從而消除人工測試所帶來的理解上的誤差； 此外，它還能重複執行相同動作，測試工作中最枯燥的部分可交由機器完成； 它支持程式風格的測試腳本，一個高素質的測試工程師能藉助它完成流程極為複雜的測試，通過使用通配符、宏、條件語句、循環語句等，還能較好地完成測試腳本的重用； 它針對於大多數程式語言和Windows技術，提供了較好的集成、支持環境，這對基於Windows平台的應用程式實施功能測試而言帶來了極大的便利。

工作流程

識別GUI

在WinRunner中，我們可以使用GUI Spy來識別各種GUI對象，識別後，WinRunner會將其存儲到GUI Map File中。它提供兩種GUI Map File模式： Global GUI Map File和GUI Map File per Test。其最大區別是後者對每個測試腳本產生一個GUI檔案，它能自動建立、存儲、載入，推薦初學者選用這種模式。但是，這種模式不易於描述對象的改變，其效率比較低，因此對於一個有經驗的測試人員來說前者不失為一種更好的選擇，它只產生一個共享的GUI檔案，這使得測試腳本更容易維護，且效率更高。

建立測試腳本

在建立測試腳本時，一般先進行錄製，然後在錄製形成的腳本中手工加入需要的TSL（與C語言類似的測試腳本語言）。錄製腳本有兩種模式： Context Sensitive和Analog，選擇依據主要在於是否對滑鼠軌跡進行模擬，在需要回放時一般選用Analog。在錄製過程中這兩種模式可以通過F2鍵相互切換。

只要看看現代軟體的規模和功能點數就可以明白，功能測試早已跨越了單靠手工敲敲鍵盤、點點滑鼠就可以完成的階段。而性能測試則是控制系統性能的有效手段，在軟體的能力驗證、能力規劃、性能調優、缺陷修復等方面都發揮著重要作用。

腳本除錯

在WinRunner中有專門一個Debug Toolbar用於測試腳本除錯。可以使用step、pause、breakpoint等來控制和跟蹤測試腳本和查看各種變數值。

測試腳本

當應用程式有新版本發布時，我們會對應用程式的各種功能包括新增功能進行測試，這時當然不可能再來重新錄製和編寫所有的測試腳本。我們可以使用已有的腳本，批量運行這些測試腳本測試舊的功能點是否正常工作。可以使用一個call命令來載入各測試腳本。還可在call命令中加各種TSL腳本來增加批量能力。

分析測試結果

分析測試結果在整個測試過程中最重要，通過分析可以發現應用程式的各種功能性缺陷。當運行完某個測試腳本後，會產生一個測試報告，從這個測試報告中我們能發現應用程式的功能性缺陷，能看到實際結果和期望結果之間的差異，以及在測試過程中產生的各類對話框等。

回報缺陷

在分析完測試報告後，按照測試流程要回報應用程式的各種缺陷，然後將這些缺陷發給指定人，以便進行修改和維護。

常用方法

功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能。常用的測試方法如下

1. 頁面連結檢查：每一個連結是否都有對應的頁面，並且頁面之間切換正確。

2. 相關性檢查：刪除/增加一項會不會對其他項產生影響，如果產生影響，這些影響是否都正確。

3. 檢查按鈕的功能是否正確：如update,cancel,delete,save等功能是否正確。

4. 字元串長度檢查： 輸入超出需求所說明的字元串長度的內容，看系統是否檢查字元串長度，會不會出錯.

5. 字元類型檢查： 在應該輸入指定類型的內容的地方輸入其他類型的內容（如在應該輸入整型的地方輸入其他字元類型），看系統是否檢查字元類型，會否報錯.

6. 標點符號檢查： 輸入內容包括各種標點符號，特別是空格，各種引號，回車鍵.看系統處理是否正確.

7. 中文字元處理： 在可以輸入中文的系統輸入中文，看會否出現亂碼或出錯.

8. 檢查帶出信息的完整性： 在查看信息和update信息時，查看所填寫的信息是不是全部帶出.，帶出信息和添加的是否一致

9. 信息重複： 在一些需要命名，且名字應該唯一的信息輸入重複的名字或ID，看系統有沒有處理，會否報錯，重名包括是否區分大小寫，以及在輸入內容的前後輸入空格，系統是否作出正確處理.

10. 檢查刪除功能：在一些可以一次刪除多個信息的地方，不選擇任何信息，按”delete”，看系統如何處理，會否出錯；然後選擇一個和多個信息，進行刪除，看是否正確處理.

11. 檢查添加和修改是否一致： 檢查添加和修改信息的要求是否一致，例如添加要求必填的項，修改也應該必填；添加規定為整型的項，修改也必須為整型.

12. 檢查修改重名：修改時把不能重名的項改為已存在的內容，看會否處理，報錯.同時，也要注意，會不會報和自己重名的錯.

13. 重複提交表單：一條已經成功提交的紀錄，back後再提交，看看系統是否做了處理。

14. 檢查多次使用back鍵的情況： 在有back的地方，back，回到原來頁面,再back，重複多次，看會否出錯.

15. search檢查： 在有search功能的地方輸入系統存在和不存在的內容，看search結果是否正確.如果可以輸入多個search條件，可以同時添加合理和不合理的條件，看系統處理是否正確.

16. 輸入信息位置： 注意在游標停留的地方輸入信息時，游標和所輸入的信息會否跳到別的地方.

17. 上傳下載檔案檢查：上傳下載檔案的功能是否實現，上傳檔案是否能打開。對上傳檔案的格式有何規定，系統是否有解釋信息，並檢查系統是否能夠做到。

18. 必填項檢查：應該填寫的項沒有填寫時系統是否都做了處理，對必填項是否有提示信息，如在必填項前加*

19. 快捷鍵檢查：是否支持常用快捷鍵，如Ctrl+C Ctrl+V Backspace等，對一些不允許輸入信息的欄位，如選人，選日期對捷徑是否也做了限制。

20. 回車鍵檢查： 在輸入結束後直接按回車鍵，看系統處理如何，會否報錯。