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)，等等。

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

原文轉自：http://www.uml.org.cn/Test/200609075.htm