軟件測試之單元測試
1、
什麼是單元測試
軟件測試的方法有不少種,從不一樣的角度來看,也有不一樣德分類,若從一個軟件開發的過程來看,通常把軟件測試分紅單元測試、集成測試、確認測試、驗收測試、系統測試,可見,單元測試是軟件開發過程當中進行的最低級別的測試活動,在單元測試活動中,軟件的獨立單元將在與程序的其餘部分相隔離的狀況下進行測試。單元測試是由程序員本身來完成,最終受益的也是程序員本身。能夠這麼說,程序員有責任編寫功能代碼,同時也就有責任爲本身的代碼編寫單元測試。執行單元測試,就是爲了證實某段代碼的行爲和咱們指望的一致。
單元測試通俗的說就是一個實現簡單功能的函數,用一組特定的輸入
(
測試用例
)
測試函數的功能是否正常,而且返回了正確的輸入。
2、
單元測試之基本路徑法
單元測試的方法也有幾種,我要介紹的是運用比較普遍的基本路徑法。基本路徑法事基於程序控制流程圖
(
控制流程圖和程序的語句能夠說是對應
)
的一種對某段代碼的各個執行路徑一一進行測試的方法。因此,說到基本路徑法就不得不先介紹一下程序控制流程圖。
例:
注:
上圖是組成完整控制流圖的幾個基本的單元結構。
下面我給你們寫一段程序,而後畫出這個程序的控制流圖
代碼:
控制流圖:
注
:
圖中的數字是指代的代碼的行號。看到這個流圖以後,你們多少會有點疑惑,圖中的那些代碼行號是怎麼選擇出來的,爲何要選擇圖中的那些呢?是這樣的:
圖中選擇的行號的代碼都是出現了選擇分支,循環操做,判斷等,順序執行的語句能夠合併成。這也是畫控制流圖的通常規則。
3、
圈複雜度
有了控制流圖之後,很天然地,咱們要知道咱們到底要寫幾個測試用例,才能來知足基本路徑測試。
當你們看到上面介紹的控制流程圖的時候,學過離散數學或者是數據結構的人,我想都是會有很一種很熟悉的感受,不錯,控制流程圖就是來源於圖及有向圖
(
這會不會再一次讓你們感受到數學對咱們的重要性呢
?)
下面我就介紹一下新的概念——圈複雜度。
圈複雜度是一種爲程序邏輯複雜性提供定量測試的軟件度量。將該度量用於計算程序的基本獨立路徑數目。爲確保全部語句至少執行一次的測試數量的上界。
公式圈複雜度
V
(
G
)
=E-N+2
,
E
是流圖中邊的數量,
N
是流圖中結點的數量。
公式圈複雜度
V
(
G
)
=P+1
,
P
是流圖
G
中斷定結點的數量。
通俗的說圈複雜度就是判斷單元是否是複雜,是否是好測試的標準。通常來講若是圈複雜度若是大於
20
就表示這個單元的可測試性很差,太複雜
從圖中咱們能夠看到,
V
(
G
)
=10
條邊
-8
結點
+2=4
V
(
G
)
=3
個斷定結點
+1=4
上圖的圈複雜圖是
4
。這個結果對咱們來講有什麼意義呢?它表示咱們只要最多
4
個測試用例就能夠達到基本路徑覆蓋。
4、
程序基本路徑
如今咱們知道了起碼要寫
4
個測試用例,可是怎麼設計這
4
個測試用例?導出程序基本路徑,根據程序基本路徑設計測試用例子。
程序基本路徑:基本獨立路徑就是從程序的開始結點到結束能夠選擇任何的路徑遍歷,可是每條路徑至少應該包含一條已定義路徑未曾用到的邊。(看起來很差理解,讓咱們看例子)。
讓咱們看上面的流程圖:從結點
4
到
24
有幾條路徑呢?很明顯:
A 13->35
B 13->15->17->35
C 13->15->23->29->33->13->35
D 13->15->23->25->33->13->35
還有嗎??
E 13->15->23->29->33->13->15->17->35
算嗎?
不算,爲何?由於上面的
4
條路徑已經包括了全部的邊。第
5
條路徑已經不包含沒有用過的邊了。全部的路徑都遍歷過了。
好了,如今咱們有了
4
條基本獨立路徑根據獨立路徑咱們能夠設計測試用例。
A 13->35
輸入數據:
flag=0
,或者是
flag<0
的某一個值。
預期結果:
temp=0.
B 13->15->17->35
輸入數據:
count =1; flag=0
預期結果:
temp=101.
C 13->15->23->29->33->13->35
輸入數據:
count =1;flag=1
預期結果:
temp=10.
D 13->15->23->25->33->13->35
輸入數據:
count =1; flag=2
預期結果:
temp=20.
上面的測試用例還能夠簡化嗎?固然能夠
來看
路徑
A 13->35
和
C 13->15->23->29->33->13->35
,路徑
1
是路徑
4
的真子集,因此
1
是能夠沒必要要的。上圖的圈複雜度是
4
。這個結果對咱們來講有什麼意義呢?它表示咱們只要最多
4
個測試用例就能夠達到基本路徑覆蓋。因此說圈複雜度標示是最多的測試用例個數,不是必定要
4
個測試用例才能夠。不過有一點要申明的是測試用例越簡化表明你的測試越少,這樣程序的安全性就越低了。
接下來的任務就是根據咱們的測試用例來使用測試工具進行測試了。
5、
小結
到這,單元測試的基本路徑法已經簡單的給你們介紹了一下,一個完整的測試是多種測試方法結合在一塊兒進行的。另外,我還想說的一點就是,不管你設計多少測試用例,不管你運用了多少種的測試方法,也無論你的測試方案是多麼的完美,你都不可能
100%
的發現全部的
BUG
,咱們進行測試,要作的就是用最少的資源,作最多的測試檢測,來讓程序儘量少的出現
BUG
。還有一點就是,窮舉測試是最有效的,可是那是不可能的,這也是咱們這個基本路徑法運用這麼普遍的一個緣由。
想要了解更多的關於單元測試的知識能夠登錄
51CTO
技術博客!