[[327741]]

【51CTO.com快譯】

常言道：沒有經歷測試，您怎么能夠判定軟件開發的質量呢?對于一名測試人員來說，他需要通過測試來確定目標軟件是否滿足所有既定的要求?軟件是否安全、易用?響應是否迅速、完整?這些對于確保軟件在發布之后得到良好反饋，并避免技術性的補救都是至關重要的。

作為一個“調查”的過程，測試人員會通過各種測試來捕獲軟件中隱藏的錯誤、缺陷、意料之外的運行結果、以及功能上的不一致性。測試人員通過提交詳細的測試報告，以幫助開發人員修復所有發現的問題，使其能夠按照預期平穩運行。

總的說來，目前業界常用的軟件測試方法有三大類：黑盒、白盒和灰盒測試方法。它們在開展方式上截然不同，在功能用途上也各有優缺點。下面，讓我們一起來深入討論吧。

黑盒測試

黑盒測試方法的主要特點是：執行測試的人員并不了解被測軟件的內部結構和源代碼。可以說，他們甚至不需要具備對于編程語言的深入了解，或出色的編程技能，便可開展測試。畢竟此類測試方法的目標并非深入研究代碼，遍歷軟件內部，而是直接與用戶界面進行交互，測試其功能，并確保系統的每個輸入與輸出，均符合既定的標準與要求。因此，黑盒測試也可以被稱為功能測試(請參見--https://testfort.com/functional-testing)、或基于規范的測試。

在軟件測試生命周期(STLC)內，黑盒測試通常是由獨立的測試團隊，從最終用戶的角度開展的。通過提供有效或無效的輸入，他們會根據預期結果去驗證軟件的輸出，將任何意外的結果和偏差都記錄在案，并最終反饋給開發團隊，以協助盡早發現并消除軟件在功能上的不足與錯誤。

黑盒測試方法幾乎適用于軟件測試的每個階段，包括：單元、集成、系統和驗收。

• 在單元測試(請參見--https://testfort.com/blog/thing-avoid-unit-testing-ios-apps)中，黑盒方法可被用于根據客戶端給出的不同規范，去測試接口。
• 在集成測試中，黑盒方法的目標是：發現并消除接口在集成組件之間的交互錯誤。
• 在系統測試中，黑盒方法可以有效地分析系統是否符合各項要求。
• 在驗收測試中，黑盒方法通過針對各種意外情況的模擬測試，以協助驗證軟件產品的可接受性。

目前，最常見的黑盒測試設計技術有：

• 決策表測試在基于嵌入式if-then-else和switch-case之類的決策表語句調試時，非常實用。據此，測試人員可以有效地查找到哪些錯誤對應于哪些條件。
• 錯誤猜測可以讓測試人員根據他們的直覺和過往的測試經驗，來設計測試用例。據此，他們可以確定可能導致軟件故障或出現錯誤的具體原因。
• All-pairs測試是一種用于測試每一對輸入參數的所有可能性的離散組合技術。據此，測試人員可以發現那些隱藏在參數對的交互過程中的常見錯誤。
• 等價類劃分技術涉及到將輸入數據分成不同的較小分區，以及可以從測試用例中導出的數據等價類。據此，測試人員可以構建出覆蓋每個分區的測試用例，從而減少測試所需要的時間。

黑盒測試的利與弊

黑盒測試可以協助測試人員識別出功能規格中的任何歧義、模糊、以及矛盾。他們能夠在并不觸碰軟件大量代碼段的情況下，評估和提高功能實現的質量。

黑箱測試的無偏見性體現在：由一個獨立的團隊以最終用戶的觀點去執行，因此它有別于開發人員的視角。相比另兩種方法，黑盒測試具有最快的測試用例開發能力，畢竟它既不需要編程知識，又可以由沒有技術背景的測試人員去輕松地執行。

不過，黑盒方法的有效性僅限于測試小型軟件。而對于大型復雜軟件進行全面測試時，它不但效率低下并且非常耗時。此外，該方法需要事先提供明確而周詳的規范，否則，我們不但難以設計測試用例，并且測試覆蓋的范圍也將十分有限。

白盒測試

與側重于功能的黑盒測試相反，白盒測試方法的目標是對軟件的內部結構、及其背后的邏輯進行分析。因此，白盒測試有時也被稱為結構測試、或邏輯驅動測試。此類方法不但比較耗時，并且要求測試人員具有強大的編程能力，能夠對所測軟件進行全面了解，并且可以訪問到所有的源代碼、以及體系架構的相關文檔。否則，測試人員將無法設計出適當的測試用例。

因此，白盒測試通常是由專業開發人員去執行的。他們運用專業知識，以及源代碼分析與調試專用工具，在弄清軟件的內部結構和代碼細節的基礎上，逐步檢查語句和條件、代碼的路徑、數據流、以及各種有效或無效的輸入，驗證程序是否能按照預期輸出結果。據此，開發人員可以開展有針對性的修復，以確保沒有隱藏的錯誤、或容易產生缺陷的元素。

雖然白盒測試可以被應用于單元測試，但是如今它被主要用在集成測試(請參見-- https://testfort.com/integration-testing)和回歸測試(請參見-- https://testfort.com/regression-testing)中。

• 在單元測試中，測試人員可以檢查出內部路徑里的代碼缺陷，以及其他可能導致軟件無法按照預期工作的問題。
• 在集成測試中，白盒方法有助于分析不同的接口和子系統之間的交互。
• 在回歸測試期間，測試人員可以有效地使用在單元和集成測試級別上“回收”的白盒測試用例。

目前，最常見的白盒測試設計技術有：

• 控制流測試是一種結構化測試策略。憑借著軟件的控制流，它可以通過執行各種輸入值，來檢查它們是否滿足既定的結果，進而驗證測試代碼的邏輯。
• 數據流測試可以檢測對于數據值的不當使用，以及由編碼錯誤所造成的數據流異常。該技術旨在通過更多的測試，來捕獲不可靠的代碼區域，進而修復或消除相應的錯誤。
• 分支測試側重于驗證那些被分離出來，執行不同真假條件的特定功能，進而消除異常。

白盒測試的利與弊

與黑盒測試不同，白盒方法是在理解源代碼的基礎上，通過刪除多余的代碼段，以發現隱藏在代碼中的錯誤。此外，它可以在源代碼級別上通過跟蹤每一項測試，來捕獲對于軟件的各種代碼級別的變更。可以說，該方法為開發團隊提供了最大的覆蓋范圍，以及清晰、簡潔的反饋。憑借著白盒測試的自動化，開發團隊能夠更容易地維持和優化代碼的質量。

當然，無論是否自動化，白盒測試通常都是耗時且復雜的。它要求測試人員具有一流的編程技能，并對被測軟件有著透徹的代碼級理解。這就意味著項目組要聘請頂尖的測試工程師來提高測試效率，這也在無形中拉高了成本。此外，由于白盒測試的結果會與代碼本身強關聯，因此代碼內容一旦發生了變化，哪怕其實現的功能是相同的，測試人員也需要重新開展白盒測試，畢竟過往的測試用例肯定是無效的。

灰盒測試

至此，您一定已經看出：由于黑盒測試和白盒測試的關注點各不相同，它們在實際使用中也是各有利弊。而灰盒測試則綜合了黑盒與白盒方法的優勢，并有效地避開了兩者各自的缺陷。

灰盒方法通過涵蓋被測軟件的所有層面，以增加技術的覆蓋范圍。如果說黑盒測試人員需要確保界面和功能方面的正常;白盒測試人員通過深入研究軟件的內部結構，以修復源代碼級別的錯誤，那么灰盒測試則是以非干擾的方式(non-intrusive)同時處理兩方面的測試。

面對復雜的系統，灰盒方法借用簡單的黑盒方法，讓開發人員、測試人員、以及最終用戶都能夠上手測試。在測試用例方面，工程師需要具備部分內部結構的相關知識，其中包括：數據結構、體系架構、以及軟件功能規范的文檔。在此基礎上生成的測試用例，可以有效地發現并消除由于軟件使用不當，而暴露出的結構缺陷問題。

灰盒測試非常適合于集成測試，包括：缺乏源代碼和二進制文件的Web應用，以及某些業務領域的需求規范性測試。

目前，最常見的灰盒測試設計技術有：

• 矩陣測試通過跟蹤并映射用戶的需求，以確保測試用例能夠涵蓋所有的方面。它能夠像狀態報告那樣，通過全面的驗證測試，來輕松地識別出任何缺少的功能。
• 回歸測試是一種軟件變更的影響分析。它往往能夠檢查出軟件在被修改后是否還能夠正常工作。據此，測試人員能夠確保軟件的變更既不會阻礙現有的功能，又不會引入新的錯誤。
• 模型測試會分析和檢查在過往的構建、設計和軟件體系架構中，測試到的缺陷。此類分析可被用于查找根本原因，以及某些給定缺陷背后的具體根源，進而防止復發。

灰盒測試的利弊

由于灰盒測試方法是基于功能規范、接口和文檔等非干擾的方式開展的，因此它使得測試人員僅在宏觀上獲悉軟件的體系架構，而不必完全訪問其源代碼或二進制文件。這就意味著測試人員和開發人員之間存在清晰的界線，進而保障了此類測試方法不帶有任何的“偏見”。此外，灰盒測試還可以針對一些特殊的智能化授權測試場景，實現對數據類型、通信協議、以及各種異常的分析。

開展灰盒方法往往需要測試團隊具有出色的項目管理能力。也就是說，如果開發人員已經運行過了相關的測試用例，則不一定非要開展灰盒測試。與此同時，如果測試人員對于軟件內部結構的了解非常有限，并且無法訪問到其對應的源代碼，那么灰盒測試可能會出現許多未經測試的代碼路徑，進而造成覆蓋面的不足。它顯然不適用于各種算法領域的測試。另外，如果您使用灰盒方法，在分布式系統中識別關聯缺陷時，也往往會感覺到力不從心。

總結

通過上述討論，我們基本了解了測試團隊在確保其產品代碼的質量，并嚴守軟件需求規范時常用的三種主要測試方法。從長遠來看，它們有助于軟件開發企業消除那些將來有可能變成巨大技術債務(technical debt)潛在問題。

那么您一定很好奇：到底哪一種軟件測試方法最好呢?客觀地說：不同的方法有著不同的適用場景和實現目標。黑盒測試能夠通過從需求視角，來獲得外部期望，并消除功能上的錯誤與不一致。白盒測試通過審查源代碼，以確保沒有隱藏的錯誤、或容易暴露缺陷的元素。而灰盒測試則能夠使用高級數據和功能規范，來捕獲各種缺陷，并確保軟件滿足各項最終的要求。

原標題：Difference Between Black-Box, White-Box, and Grey-Box Testing，作者: Andrew Smith

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】