[[327741]]

【51CTO.com快譯】

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

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

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

黑盒測(cè)試

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

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

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

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

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

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

黑盒測(cè)試的利與弊

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

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

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

白盒測(cè)試

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

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

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

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

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

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

白盒測(cè)試的利與弊

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

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

灰盒測(cè)試

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

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

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

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

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

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

灰盒測(cè)試的利弊

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

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

總結(jié)

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

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

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

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