Logiscope測試機理(3)

　　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 總結

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