iT邦幫忙

DAY 24
5

如何提升系統設計品質 - 技術與工具以.NET為例系列 第 24

[如何提升系統品質-Day24]測試 - Code Coverage

承接著之前單元測試相關的文章中,提到了程式的可測試性為系統重要的品質指標之一。這篇文章要提的,則是也很常用來當作檢視測試的品質指標之一。

測試不是有做就好,做心安的...透過code coverage,可以快速的得知,目前系統中,有多少程式被測試過,以及測試的過程中,程式執行的路徑為何。

[如何提升系統品質]系列文章連結
Code Coverage的定義
基本上就是測試程式碼的涵蓋範圍,不考量成本跟投資效益比,涵蓋率越高,當然代表品質提升面也會比較廣。

Code Coverage的種類
Code Coverage種類不少,以下舉出幾種:
1.function coverage:
以function為單位,檢測有哪些function曾經被測試程式測試過。只要有測試到該function,就當作測過了。假設production code裡面有10個function,只有1個被測試過,那function coverage就是10%。

2.Line Coverage:
也就是是否production code的每一行程式碼,都有被測試程式執行到。也是一般.NET的code coverage工具裡面,最常看到的涵蓋率。

如果,你以為每一行都有跑到,Line Coverage 100%就代表這是測試品質的最高表現,那就錯了,Line Coverage只是幾個涵蓋率分類裡面的子集合而已。

3.Statement Coverage:
與line Coverage一行一行用斷行符號來分的切入角度不同,而是使用statement來當檢測單位。在許多的程式語言中,是允許一行裡面出現多個statement的,當一行裡面擁有多個statement,而測試程式中,只有檢測到其中一個statement,那麼line coverage會涵蓋到,statement coverage卻可以抓出其中涵蓋度不足的部分。

4.Decision Coverage:
就像決策樹一般,每一個決策分歧點,也就是程式執行路徑,為檢測單位。值得一提的是,Decision coverage針對的是分歧後的結果。然而,Decision Coverage可以涵蓋到Statement coverage的死角,舉個例子:

        public double Sample(double a, double b, double x)
        {

            if (a > 0 && b == 0)
            {
                x = x / a;
            }

            if (a == 2 || x == 1)
            {
                x = x / b;
            }

            return x;
        }

statement coverage要100%,test case只需要a=2, b=0, x=0,即每一個statement都會跑到。但一樣每一個statement都測到了,就代表這個測試完美了嗎?no, 因為判斷式的條件有多個,判斷式裡面的陳述式所回傳的bool值,可能發生意想不到的錯誤。

5.Condition Coverage:
即使是Decision Coverage,也有不足之處。不足處在於Decision針對的是每條不同路徑要測試的程式主體,但判斷式本身,卻不過問。而Condition Coverage是連判斷式裡面的陳述式(sub-expression),每一種陳述式所回傳的bool正反兩種情境都要測到。

以wiki上的例子來說:

if a and b then

只要測試
a=true, b=false
a=false, b=true
就能滿足Condition Coverage。

6.Condition/Decision Coverage:
沒錯!就是摻在一起做撒尿牛丸。除了判斷式中每個陳述式的bool都要測true/false,也要測試各種路徑裡面的各種結果。

7.Modified condition/decision coverage:
可以說是Condition/Decision Coverage的完成體,一樣以wiki上的例子來說:

if (a or b) and c then

要滿足Condition Coverage (Decision就只是測試判斷式的大括號肚子裡面的內容,這邊先略過),基本上只要測試
a=true, b=true, c=true
a=false, b=false, c=false
就是三種陳述式的true/false都測到了。

但,有測試到最後組合出來的結果嗎?
以這個例子來說,整個if陳述式由兩個子陳述式所組成,一個是 (a or b),一個是c。
先看第一個(a or b),要測試整個陳述式結果為true跟false,而(a or b)又有a與b兩個子陳述式。
所以,要滿足各種可能,則需測試:
a=false, b=false, c=true => 第一個陳述式為false,第二個陳述式為true,and結果為false
a=true, b=false, c=true => 第一個陳述式為true,第二個陳述式為true,and結果為true
a=false, b=true, c=true => 第一個陳述式為true,第二個陳述式為true,and結果為true
a=true, b=true, c=false => 第一個陳述式為true,第二個陳述式為false,and結果為false

也就是組合條件,去測到每一個子陳述式的true/false。

8.Multiple Condition Coverage:
最後當然就是最瘋狂的一種,每一個陳述式都有true/false,去做2的n次方種組合。
以上面的例子就是:
a=false, b=false, c=false
a=false, b=false, c=true
a=false, b=true, c=false
a=false, b=true, c=true
a=true, b=false, c=false
a=true, b=false, c=true
a=true, b=true, c=false
a=true, b=true, c=true

Code Coverage的工具
很抱歉的是,我知道的都是需要收費的。一個open source不用收費的PartCover(簡介),作者沒有再維護了。(這就是open source現實的地方)
其他收費的工具,請參考wiki上的介紹:

Tools for C# .NET
DevPartner
JetBrains dotCover
Kalistick
NCover
TestDriven.NET
Visual Studio 2010

補充工具
Microsoft Research有出一個很棒的東西叫做Pex and Moles,可以讓你很『快速』的產生高程式碼覆蓋率的單元測試程式,且支援多種Unit Test Framework。這邊的快速,指的是可以省去我們思考不同的test case滿足不同路徑的時間,但Pex還是需要時間、CPU去計算出滿足所有路徑的input/output。

針對重要的Scenario,可以透過它來補足測試遺漏的地方。

它也有個有趣的網頁,是可以讓我們寫程式,讓Pex來跑所有可能性,請參考:PexForFun

與VS2010整合得很好,最上面的例子,跑完Pex parse出來的結果會像下圖這樣:

產生的單元測試碼,請見下圖

自動產生的test case,請見下圖

結論
Code Coverage的迷思
上面介紹了這麼多種Code Coverage的分類,幾乎是一個比一個還嚴苛,您覺得呢?我只能說,這太遙不可及了,多少人連單元測試都還沒寫過。越往下的測試分類所花的成本越高,投資效益比越低。

即使只有line coverage,我也認為足夠用了。什麼叫做足夠用,除非是寫一個完完全全不容許任何差錯,沒有bug,沒有絲毫遺漏的系統。不然,系統多少都有bug,多少都得fix bug。NASA發射太空梭都有失敗的了,何況我們的程式。

請把code coverage的數字當作一個健康指標 (甚至稱不上系統品質指標,勉強稱得上是測試的品質指標),用來檢查什麼?
1.有沒有做單元測試?
2.重要的Scenario有沒有涵蓋多一點情境?
3.現在有哪些程式碼沒有被測過?
4.發生測試失敗時,失敗的原因點production code是否有被test case涵蓋到。

夠了,這樣就很夠了。

請把更多的時間,花在如何寫出具有可測試性的production code,如何落實Unit Test,以及如何用最少的成本,最低的阻力建立自動化的環境。重點在於,如何讓每一次的重構、每一次的需求異動、每一次的bug,都能快速且準確的增加對應的Unit Test,才是要中之要。

Reference
1.http://en.wikipedia.org/wiki/Code\_coverage
2.http://blog.udn.com/chungchia/3341216
3.http://www.51testing.com/?uid-3733-action-spacelist-type-blog-itemtypeid-9157,動態圖片解說很讚


上一篇
[如何提升系統品質-Day23]測試 - 單元測試工具的選擇(for .NET)
下一篇
[如何提升系統品質-Day25]測試 - 自動化測試經驗分享
系列文
如何提升系統設計品質 - 技術與工具以.NET為例30

尚未有邦友留言

立即登入留言