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對質量模型中質量準則級的處理方法，可以看出，質量準則是建立在質量度量元的基礎之上的，是比質量度量元更加綜合的一級。

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