什麼是黑盒測試?

2022-09-06 15:36:09 字數 4715 閱讀 4255

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

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

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

功能不正確或遺漏;

介面錯誤;

資料庫訪問錯誤;

效能錯誤;

初始化和終止錯誤等。

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

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

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),故有 種規則.

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

③填入條件項.

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

⑤簡化.合併相似規則(相同動作).

b. beizer 指出了適合使用判定表設計測試用例的條件:

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

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

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

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

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

正交試驗設計法,就是使用已經造好了的正交**來安排試驗並進行資料分析的一種方法,目的是用最少的測試用例達到最高的測試覆蓋率。

黑盒測試的優點

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

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

黑盒測試的缺點

1. 結果取決於測試例的設計,測試例的設計部分來勢**於經驗,ouspg的東西很值得借鑑

2. 沒有狀態轉換的概念,目前一些成功的例子基本上都是針對pdu來做的,還做不到針對被測試程式的狀態轉換來作

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

什麼是黑盒測試

在北京德潤教育這段時間的學習中我學習了很多知識,包括在以前都不知道什麼是軟體測試,經過這兩個月的系統培訓中知道什麼是軟體功能測試。黑盒測試也稱功能測試,它是通過測試來檢測每個功能是否都能正常使用。在測試中,把程式看作乙個不能開啟的黑盒子,在完全不考慮程式內部結構和內部特性的情況下,在程式介面進行測試...

什麼是 黑盒測試 白盒測試 靜態測試?

單元測試 看源 分析程式內部邏輯結構 整合測試 對設計的檢測 系統測試 測試功能 交接測試 即確認測試 測試是否符合使用者需求 黑盒測試法 一般用來確認軟體功能的正確性和可操作性,目的是檢測軟體的各個功能是否能得以實現,把被測試的程式當作乙個黑盒,不考慮其內部結構,在知道該程式的輸入和輸出之間的關係...

什麼是冒煙測試?什麼是回歸測試?

一 什麼是冒煙測試?冒煙測試 smoke testing 是指 針對每個版本或每次需求變更之後,在正式測試之前,對產品或系統的一次簡單的驗證性測試,驗證產品或系統的 基本功能 流程是否正常。我們可以將冒煙測試理解為是在執行正式測試之前的 試 二 冒煙測試的目的是什麼?目的是確認軟體的基本功能正常,可...