黑盒測試

黑盒測試又叫功能測試、數據驅動測試或基於需求規格説明書的功能測試。該類測試注重於測試軟件的功能性需求。 ^[2] 

採用這種測試方法，測試工程師把測試對象看作一個黑盒子，完全不考慮程序內部的邏輯結構和內部特性，只依據程序的《需求規格説明書》，檢查程序的功能是否符合它的功能説明。測試工程師無需瞭解程序代碼的內部構造，完全模擬軟件產品的最終用户使用該軟件，檢查軟件產品是否達到了用户的需求。黑盒測試方法能更好、更真實地從用户角度來考察被測系統的功能性需求實現情況。在軟件測試的各個階段，如單元測試、集成測試、系統測試及驗收測試等階段中，黑盒測試都發揮着重要作用，尤其在系統測試和確認測試中，其作用是其他測試方法無法取代的。 ^[2] 

黑盒測試方法着重測試軟件的功能需求，是在程序接口上進行的測試，主要是為了發現以下錯誤。 ^[1] 

(1)是否有功能錯誤，是否有功能遺漏。 ^[1] 

(2)是否能夠正確地接收輸入數據併產生正確的輸出結果。 ^[1] 

(3)是否有數據結構錯誤或外部信息訪問錯誤。 ^[1] 

(4)是否有程序初始化和終止方面的錯誤。 ^[1] 

(1)接受性測試。

黑盒測試是從軟件的接口接受測試輸出結果，具有接受性測試的特點。 ^[3] 

(2)α/β測試。

測試是項目組內的成員對被測軟件進行的測試，α/β測試是由項目組外的人員參加的測試。α/β測試也適合於黑盒測試。也就是説，當測試發現錯誤後在開發人員修改的同時，項目經理也會對產品計劃做出相應的調整，產品特徵不斷地被修改。 ^[3] 

(3)菜單/幫助測試。

在軟件測試過程中，開發人員將修復測試人員發現的錯誤，而且對軟件的有些功能進行修改，同時項目經理也將根據情況調整軟件的特性，因而在軟件開發和測試的過程中，所有的功能都可以進行調整。因此，在軟件產品開發的最後階段，文檔裏發現的問題往往最多。 ^[3] 

(4)發行測試。

在正式發行前，產品要經過非常仔細的測試。除了專門的測試人員外，還需要幾千個甚至幾十萬其他用户與合作者通過使用來對產品進行測試。然後將錯誤信息反饋到技術部門到了發行測試時，如果出現非改不可的錯誤，就必須推遲軟件的發行，在推遲時間內需要重新對軟件產品進行全面的測試，將耗費大量的時間、人力和物力。 ^[3] 

(5)迴歸測試。

在此階段，首先要檢查以前找到的錯誤是否已經更正了。迴歸測試可使已更正的錯誤不再重現，並且不會產生新的錯誤。 ^[3] 

(6)RTM測試。

RTM測試是指在產品發行階段所進行的測試。在這一測試階段，每一個錯誤都需要經過高端人員同意才能更正。因為這時候修改軟件非常容易產生其他的錯誤，所以只有那種非修復不可的錯誤才將允許進行修改。如果在發行階段軟件還有許多嚴重錯誤的話，就不能按時發佈。 ^[3] 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）邊界值分析方法的考慮： ^[2] 

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

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

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

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

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

3）根據規格説明的每個輸出條件，使用前面的原則1）。 ^[2] 

4）根據規格説明的每個輸出條件，應用前面的原則2）。 ^[2] 

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

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

7）分析規格説明，找出其它可能的邊界條件。 ^[2] 

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

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

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

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

生成測試用例： ^[2] 

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

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

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

(4) 把因果圖轉換為判定表。 ^[2] 

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

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

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

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

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

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

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

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

判定表的建立步驟：

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

②列出所有的條件樁和動作樁。 ^[2] 

③填入條件項。 ^[2] 

④填入動作項.等到初始判定表。 ^[2] 

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

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

①規格説明以判定表形式給出，或很容易轉換成判定表。 ^[2] 

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

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

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

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

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

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

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

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

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

建立可重複使用的自動測試過程。 ^[4] 

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

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

(1)黑盒測試的優點：適用於功能測試、可用性測試及可接受性測試;對照説明書測試程序功能;可測試長的、複雜的程序的工作邏輯，易被理解。 ^[5] 

(2)黑盒測試的缺點：不可能進行完全的、毫無遺漏的輸入測試，有一些軟件Bug或人為設置的故障通過黑盒測試是無法檢測出來的。正是因為黑盒測試的測試數據來自規格説明書，這一方法的主要缺點是它依賴於規格説明書的正確性。實際上，人們並不能保證規格説明書完全正確。如在規格説明書中規定了多餘的功能，或是漏掉了某些功能，這對於黑盒測試來説是完全無能為力的。 ^[5]