Logiscope測試機理(2)

　　最后，綜合多個質量標準，得出代碼的可維護性質量因素?？删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對代碼的處理過程如圖所示：

　　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能記錄下程序中哪些分支走到了，哪些分支沒有走到，進而統計出每個測試用例的覆蓋率，以及多個測試用例覆蓋率的總和。

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