單元測試=白箱測試? 這是很多人的想法. 一聽到白箱測試, 就認為他就是單元測試. 或者認為單元測試時, 就是要用白箱測試的方法來進行.
事情是這樣嗎? 讓我們繼續看下去:
當我們要測試這個程式時
stack push(stack s, int key)
你會怎麼測試呢? 你可能會考慮以下幾種狀況
(1) 空的 stack, 第一次 push
(2) 不是空的 stack, 然後 push 東西
(3) stack 是滿的, push 個東西看會不會有問題
(4) 不是空的 stack, 然後 push 乙個字元
(5) 不是空的 stack, 然後 push 乙個指標
你所做的大多是根據程式思考邏輯, 或者是根據輸入的值域來做參考, 來建立測試個案.
這些方式其實都是黑箱測試(用到了 use case testing 和 equivalence class testing等方法, 可自行去網路上找詳細介紹), 也就是不管程式內部如何被實作. 只根據行為和輸入值域來開立測試.
那真正的白箱測試會是怎麼進行呢?
基本上, 可以測試的狀況有無限多種. 而白箱測試是要根據程式內容來決定要怎樣挑最小可測試的集合.
那程式內有甚麼東西, 可以讓我們來做挑選的判斷呢? 一般常見的是根據程式控制邏輯. 例如: 是否經過所有的敘述(statement); 是否經過程式所有分支等等.
如果以經過所有的敘述為例, 對於下面的程式
01: stack push(stack s, int key)
02: else
10: return s;
11: }
你會找出這組路徑, 來當作最小需要測試的集合, 然後對它建立其相對應的測試個案
path1: 01-02-03-05-06-07-08-09-10-11
test case 1:
push (s, 3)
path2: 01-02-03-04-10-11
test case 2:
push (s, 3) (repeat 10 times, 如果 stack 大小是10 的話)
push (s, 3)
(當然你可以只用test case 2, 因為它涵蓋了 test case 1 的狀況)
一般人通常不會先分析執行路徑, 再找測試個案. 大多是根據一些準則, 找出測試個案就開始測試了. 所以一般單元測試是用黑箱測試方式在進行, 而非白箱測試.
那為何大家會有錯覺單元測試 = 白箱測試呢?
那 是因為在進行白箱測試時, 對於乙個大的系統要找出可執行路徑, 會是一件很複雜的事情. 但是對於每個單元時, 這件事情變得比較容易, 比較有可能不借由工具的輔助, 就能自己進行. 也就是說在單元測試時, 比較容易進行白箱測試. 可是不知怎麼傳的, 很多人就把這兩個視為同義.
白盒測試例項 單元測試的步驟
白盒測試 與黑盒測試 的過程和方法是有一些區別的。單元測試 的步驟 1 理解需求和設計 理解設計是很重要的，特別是要搞清楚被測試模組在整個軟體中所處的位置，這對測試的內容將會有很大的影響。需要記住的乙個原則就是 好的設計，各模組只負責完成自己的事情，層次與分工是很明確的。在單元測試的時候，可以不用測...
真的要做單元測試嗎？
單元測試可以降低 的耦合度。我們知道，耦合度高的 很難做單元測試，反過來，如果你必須做單元測試，你是不會把 寫的耦合度很高的 打個比方，單元測試像是花盆裡的沙子，它會降低土壤的粘度。單元測試可以讓你知道你對 的修改是否影響到了原來就有的功能。但是這也是所有的回歸測試都可以做的。單元測試的特點在於 它...
單元測試 單元測試文章收藏
前言 前段時間公司計畫做自動化測試，自己也打算圍繞幾個點做相關調研，現在想想呢？其實對自動化測試的概念都還不是十分清晰，當時主要還是圍繞 單元測試 向qa小夥伴學習了一段時間，現由於公司重組，學習中斷，這裡簡單記錄一些單元測試好文，留待後續參考.什麼叫自動化測試？自動化測試覆蓋率？覆蓋率如何做到的？...