Logiscope測試機理[2] 軟件測試
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
文章來源于領測軟件測試網 http://www.kjueaiud.com/
