靜態測試工具Logiscope的測試機理

1前言
本文介紹了靜態測試工具Logiscope的測試機理。通過對Logiscope測試機理的了解，能幫助我們更好的使用這個工具。

通過閱讀本文，你可以了解到以下信息：

Logiscope是如何分析軟件產品質量的；

Logiscope是如何檢測代碼的編碼規范的；

Logiscope是如何統計測試覆蓋率的；

2 Logiscope總覽
Logiscope有三項主要功能，以三個獨立工具的形式出現，分別是：

軟件質量分析工具——Audit；

代碼規范性檢測工具——Rulechecker；

測試覆蓋率統計工具——TestChecker。

Audit和Rulechecker提供了對軟件進行靜態分析的功能，TestChecker提供了測試覆蓋率統計的功能。
   
Logiscope可以對多種語言實現的代碼進行分析，比如C、C++、Java、Ada，等等。下面的內容與具體的語言基本是沒有關系的，但如果某些地方確實要涉及具體的語言，則我都是以C++為例。

下面，我對Audit、Rulechecker和TestChecker的測試機理，分別進行介紹。

3 Audit測試機理
3．1軟件質量模型
前面已經說過，Audit是審查程序代碼質量的。要討論代碼的質量，就需要先說明一下軟件質量模型的概念，因為理解下面的內容需要軟件質量模型的相關知識。

如果你原來學習過軟件質量保證的相關知識，那么應該會對軟件質量模型這個概念有印象。為了說明Audit的測試機理，在這里只對軟件質量模型做個簡單的介紹。如果你對軟件質量模型的概念比較陌生，建議找一本講述軟件工程方面的書，閱讀一下軟件質量保證部分的內容。

軟件質量模型是一個分層結構，它的一般形式如下圖所示

由圖可以看出，質量因素處于質量模型中最高一級。軟件的質量因素包括功能性、可靠性、易用性、效率、可維護性、可移植性這六個方面（在ISO/IEC 9126中有詳細的描述）。

在質量因素之下，又細分成多個質量標準。

每個質量標準又由多個質量度量元組成。這些質量度量元處于質量模型分層結構中的最底層。

質量因素、質量標準一般是固定的，就是這幾類，但質量度量元不是固定的，可以根據不同的情況發生變化。

軟件質量模型就是一個將程序信息由底層到高層、由細節到概括的一個過程模型，它由簡單、可測量的數據入手，最后分析概括出軟件的特征。

3．2 Audit對軟件質量模型的實現
上面我們了解了軟件質量模型的大體結構，Audit也是按照這種分層、量化的方式來審查代碼質量的。

Audit通過一個文本文件來定義質量模型。在為被測代碼建立Audit檢測項目的過程中，有一步是要求我們“choose a quality”，這就是在要求我們設定一個質量模型，默認的，Audit會提供一個質量模型文件，它的位置在“LogiscopeHOME\Logiscope\Ref\Logiscope.ref”。用記事本打開這個文件，通過觀察我們會發現，文件中首先定義了若干個度量元，并為這些度量元設定了數值范圍，接著通過組合若干個度量元形成質量標準，最后又通過組合質量標準，形成最后的質量因素。這個過程與軟件質量模型中由底層到高層、由細節到概括的結構恰好對應。

除了使用Audit提供的這個質量模型文件外，我們當然可以定義自己的質量模型文件（99%的情況下都需要我們制定符合我們需要的質量模型文件），只要符合Logiscope.ref這個文件的格式即可。

為了方便起見，我們下面就以Audit提供的這個質量模型文件展開討論，講解Audit對軟件質量模型的實現。

對應于質量模型中質量因素這一級，Logiscope提供的默認的質量模型文件對軟件的可維護性這個質量因素進行了實現，使用這個文件，可以通過Audit評價軟件的可維護性水平。

在質量標準級，在質量模型文件中定義了四個質量標準，分別是：易于分析性（ANALYZABILITY）、易于測試性（TESTABILITY）、穩定性（STABILITY）和適應變化性（CHANGEABILITY）。
對于軟件質量模型中最底層的質量度量元級，質量模型文件從Audit提供的度量元中選擇了幾十個度量元構成了基本度量元，比如函數語句數度量元（lc_stat）、類公共數據成員數度量元（cl_data_publ），等等。

那么各層具體的分析結果是如何得出來的呢？我們按照質量度量元、質量標準、質量因素的順序由底到高，依次解釋。

在Audit的內部定義了大量的質量度量元，度量元是檢驗一個軟件質量好壞的最基本元素。在Logiscope提供的這個默認質量模型文件中，選取的度量元都是為最后評價可維護性提供服務的。通過觀察Logiscope.ref質量模型文件，你會發現，度量元都可以量化為數字，允許我們在質量模型文件中為每個度量元設定上限值和下限值。當某一度量元超出我們設定的上限值和下限值的范圍時，Audit就認為被檢測的代碼在該項度量元上不符和要求。

下面舉一個度量元的例子：lc_stat度量。該度量元表示函數中可執行語句的數量。lc_stat度量元對于衡量函數的復雜性是很有用的，比如我們可以設定它的上限值為30，下限值為0，即我們規定了：一個函數中可執行的語句數不能超過30條。這就是Audit對質量模型中度量元級的處理方法。

通過這一個個單獨的度量元，我們還不能判斷程序的可維護性如何，因為過于片面，只有將這些度量元按某種規則組織起來，才能對軟件的可維護性作出評價。通過觀察Logiscope.ref這個質量模型文件我們會發現，每個質量標準都是由若干個度量元按權相加組成的，質量標準最后也用數字來表示它自己的值。通過質量標準值的大小，Audit給出程序代碼遵守該項質量標準的級別。級別共有四個，由高到底依次是EXCELLENT（優秀）、GOOD（良好）、FAIR（合格）、POOR（不合格）。下面從Logiscope.ref文件中摘錄一段，作為如何計算質量標準的例子：

這個質量標準是評價函數的穩定性的。最上面一行是這個質量標準的計算公式：

function_STABILITY = ic_varpe + ct_exit + dc_calls + ic_param

該公式表明，該質量標準由四個度量元所決定，即ic_varpe 、ct_exit、dc_calls、ic_param，每個度量元的權重均為1。該質量標準的最高得分為4分，即當構成該質量標準的四個度量元的值均在我們設定的范圍內時，該項質量標準得分為4分，當有三個度量元的值均在我們設定的范圍內時，該項質量標準得分為3分，以此類推。最后根據具體的得分，可以判定程序代碼在該項質量標準上所處的等級。這就是Audit對質量模型中質量準則級的處理方法，可以看出，質量準則是建立在質量度量元的基礎之上的，是比質量度量元更加綜合的一級。

最后，綜合多個質量標準，得出代碼的可維護性質量因素?？删S護性因素的計算方法如下：

function_MAINTAINABILITY: component  =  function_ANALYZABILITY

+  function_CHANGEABILITY

+  function_STABILITY

+  function_TESTABILITY

這是在計算函數的可維護性。最上面是計算公式，函數的可維護性由四個質量標準的得分相加得出（質量標準得分的計算方法上面已經說過了）。對于這個例子來說，它的最高得分為12分，最低得分為0分。最后根據具體的得分，可以判定程序代碼在可維護性上所處的等級（EXCELLENT、GOOD、FAIR、POOR）。通過層層綜合，最后終于得到了可維護性質量因素的結果。

OK，以上通過Audit為我們提供的默認質量模型，講述了在Audit中由質量度量元、到質量準則、最后到質量因素的逐級評價方法。如果是我們自己制定的質量模型，其原理是完全一樣的。

怎么樣，這個過程清楚了嗎？如果還是有些迷惑，建議你看一看“LogiscopeHOME\Logiscope\Ref\Logiscope.ref”這個文件的內容，那會對你理解這些內容有所幫助。

3．3 作用域的劃分
我們在人工分析一個應用程序的代碼時，通常先會查看應用程序的總體情況，然后分析應用程序中的各個類(對于使用面向對象這類語言實現的代碼來說)，進而再分析類中的成員函數。

Audit在分析、顯示對代碼的審查結果時，也按這種形式進行劃分，我們稱它為作用域，比如對于C++、Java語言實現的代碼，Audit劃分的作用域有：應用程序作用域、類作用域、函數作用域。通過它們的名字，你應該可以猜出各個作用域所包含的內容。應用程序作用域針對整個應用程序，類作用域針對系統中的各個類，函數作用域針對系統中的各個函數。

不同作用域之間是彼此獨立的，但它們都是遵照我們前面提到的那個質量模型對代碼進行分析。

3．4 Audit對代碼的處理過程
對于使用Audit的用戶來說，輸入的是源程序代碼，輸出的是Audit的分析結果。Audit對代碼的處理過程如圖所示：

Audit對代碼的處理過程
3．5 結束
好了，Audit的測試機理到此就介紹完了。

4 Rulechecker檢測機理
現在來介紹一下Logiscope為我們提供的另外一個工具——Rulechecker。Rulechecker也是一個靜態測試工具。

先回想一下我們組織內部的編碼規范。編碼規范中會對程序代碼的注釋、變量命名、書寫格式等各個方面做出規定，其目的，是為了讓開發人員書寫的代碼更健壯，可讀性更好。Rulechecker這個工具也是為了協助我們實現使代碼更健壯，可讀性更好這個目的的。

Rulechecker實現了一個編碼規范集。在這個規范集中的內容，與我們組織內部定義的編碼規范的內容類似，但覆蓋的范圍要更廣，規定的也更細（關于Rulechecker編碼規范集中各條編碼規范的詳細內容，可以閱讀我寫的另一篇文章《RuleChecker編碼規范》，在這里就不做描述了）。

在這個規范集中，有將近一半左右的編碼規范，我們可以對其內容進行定制，這就大大增加了靈活性，使Rulechecker能更好的適應我們實際情況的需要。

在具體的測試過程中，Rulechecker的編碼規范是如何發揮作用的呢？在我們為被測代碼建立Rulechecker項目的過程中，有一步是讓我們“Choose a configuration file”，這就是讓我們選擇一個編碼規范描述文件，Rulechecker為我們提供了一個叫做‘RuleChecker.cfg’的編碼規范描述文件，我們當然可以修改或重新編寫一個.cfg文件，來適應我們的要求。

下面舉Rulechecker編碼規范集中一個編碼規范的例子：Headercom編碼規范

    Headercom編碼規范對代碼文件的文件注釋做出了規定，具體內容為：“每個代碼文件的頭部必須有文件注釋，且注釋要遵照一定的格式”。這個格式可由我們來設定。

我現在將Headercom規范要求的注釋格式，設置成與我所在公司的編碼規范中規定的文件注釋相同的格式。        打開RuleChecker.cfg文件，用下面的內容代替文件Headercom原來的內容。
STANDARD Headercom ON

LIST "HEADER"                "【文件名】"

                                        "【功能模塊和目的】"

                                        "【主要函數及其功能】"

                                        "【主要算法】"

                                        "【接口說明】"

                                        "【開發者及日期】"

                                        "【版本】"

                                        "【更改記錄】" END LIST

LIST "CODE"                    "【文件名】"

                                        "【功能模塊和目的】"

                                        "【主要函數及其功能】"

                                        "【主要算法】"

                                        "【接口說明】"

                                        "【開發者及日期】"

                                        "【版本】"

                                        "【更改記錄】" END LIST

END STANDARD

做完這個操作后，保存成另一個文件，以.cfg為后綴名。在建立被測代碼的RuleChecker項目時，選中這個文件，則RuleChecker會以該格式檢查代碼文件的文件注釋格式，如果哪個文件不符合要求，就會被檢測出來。

OK，RuleChecker的測試機理介紹完了，應該是很好理解的。

5 TestChecker檢測機理
現在來介紹一下Logiscope為我們提供的最后一個工具——TestChecker。TestChecker是用來統計被測試程序的測試覆蓋率的。它提供的覆蓋率數據是邊覆蓋率，或者叫判定到判定的覆蓋(DDP覆蓋)。

所謂邊覆蓋率，也就是我們執行的測試用例對程序流程圖中的邊的覆蓋情況。有一些單元測試工具，比如Numega中的TrueCoverage，Rational的Purecoverage等，它們也可以統計被測試程序的測試覆蓋率，但它們所提供的覆蓋率數據是點覆蓋率（IB覆蓋率），或者叫做語句覆蓋率，這個覆蓋率的覆蓋強度要低于邊覆蓋的覆蓋強度。

TestChecker 的測試機理是這樣：建立起TestChecker項目后，通過TestChecker編譯連接代碼，生成可執行文件，在這個過程中，TestChecker會向程序源代碼中涉及到控制流轉移的語句處，插入一些標志語句（這個過程叫做“插裝”）。在TestChecker中運行起被這個可執行文件，執行測試用例的時候，TestChecker會在后臺運行。由于在程序代碼中“插裝”了標志語句，所以在程序的執行過程中，TestChecker能記錄下程序中哪些分支走到了，哪些分支沒有走到，進而統計出每個測試用例的覆蓋率，以及多個測試用例覆蓋率的總和。

TestChecker的測試機理基本就是這樣。

6 總結
        Logiscope的測試機理到此就介紹完了，象其它的計算機技術一樣，理解、掌握Logiscope的最好辦法就是實際的使用Logiscope去測試一些項目，好了，讓我們開始吧。

原文轉自：http://www.anti-gravitydesign.com