[[327741]]

【51CTO.com快譯】

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

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

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

黑盒測試

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

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

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

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

目前，最常見的黑盒測試設(shè)計技術(shù)有：

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

黑盒測試的利與弊

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

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

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

白盒測試

與側(cè)重于功能的黑盒測試相反，白盒測試方法的目標(biāo)是對軟件的內(nèi)部結(jié)構(gòu)、及其背后的邏輯進(jìn)行分析。因此，白盒測試有時也被稱為結(jié)構(gòu)測試、或邏輯驅(qū)動測試。此類方法不但比較耗時，并且要求測試人員具有強(qiáng)大的編程能力，能夠?qū)λ鶞y軟件進(jìn)行全面了解，并且可以訪問到所有的源代碼、以及體系架構(gòu)的相關(guān)文檔。否則，測試人員將無法設(shè)計出適當(dāng)?shù)臏y試用例。

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

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

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

目前，最常見的白盒測試設(shè)計技術(shù)有：

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

白盒測試的利與弊

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

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

灰盒測試

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

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

面對復(fù)雜的系統(tǒng)，灰盒方法借用簡單的黑盒方法，讓開發(fā)人員、測試人員、以及最終用戶都能夠上手測試。在測試用例方面，工程師需要具備部分內(nèi)部結(jié)構(gòu)的相關(guān)知識，其中包括：數(shù)據(jù)結(jié)構(gòu)、體系架構(gòu)、以及軟件功能規(guī)范的文檔。在此基礎(chǔ)上生成的測試用例，可以有效地發(fā)現(xiàn)并消除由于軟件使用不當(dāng)，而暴露出的結(jié)構(gòu)缺陷問題。

灰盒測試非常適合于集成測試，包括：缺乏源代碼和二進(jìn)制文件的Web應(yīng)用，以及某些業(yè)務(wù)領(lǐng)域的需求規(guī)范性測試。

目前，最常見的灰盒測試設(shè)計技術(shù)有：

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

灰盒測試的利弊

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

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

總結(jié)

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

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

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

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