1 概述

Rational ClearCase是一個業界領先的軟件配置管理工具，Rational ClearQuest則是IBM Rational在變更管理和缺陷跟蹤方面的軟件。業界對于變更管理軟件和配置管理軟件的集成有著強烈的需求，因此IBM Rational也提供了ClearCase和ClearQuest集成的功能。

所謂Base ClearCase和ClearQuest的集成，就是將ClearQuest中的變更請求(Change Requeset)關聯到一個或多個ClearCase中元素(Element)的版本(Version)上。一個變更請求可以被關聯到一個或多個版本上，實施變更的這些版本的集合被稱作變更請求的變更集(Change Set)。一個版本可以被關聯到一個或多個變更請求，這些變更請求的集合被稱作版本的請求集(Request Set)。

集成對于不同的角色，有以下不同的功能：

一個項目經理指定在什么情況下需要讓用戶關聯版本到變更請求。也可以指定關聯變更請求的VOBs，branches，以及element types。

ClearQuest的管理員添加ClearCase的定義到ClearQuest的schema中。這使得變更請求可以顯示與它關聯的變更集。

使用ClearCase進行開發的人員，可以在Check Out或者Check In一個版本的時候，將這個版本關聯到一個或者更多的變更請求上。也可以查看一個變更請求的變更集。

在這篇文章中，我們將對Base ClearCase與ClearQuest集成的設計原理和運行環境的搭建與設置進行介紹，最后再提供一些操作范例。

2 基本概念

2.1 集中方式(Central Server)

所謂的Central Server就是將所有的腳本文件及配置文件放在一個目錄，當進行集成的時候，ClearCase就會在這個目錄中尋找配置文件（config.pl）、cqcc_launch腳本以及其他的代碼，而不是使用本地默認目錄的相應文件，因此提高了安全性和可維護性。與之對應的本地方式(Local Server)則是使用本地ClearCase目錄中的配置文件、腳本以及其他代碼。

2.2 批處理(Batching Enabled)

就是將一個ClearCase操作中的所有與ClearQuest相關的操作，記錄到一個批處理文件中，ClearCase操作完成之后，再將這些操作一次性寫入到ClearQuest中。從而降低了登陸ClearQuest和在查詢ClearQuest的次數，大大的提高了性能。

2.3 序列(Batching Series)

批處理序列是將批處理的概念進一步擴展的產物。ClearCase認為所有進行的ClearCase都是在一個批處理當中，它記錄所有與ClearQuest相關的操作到批處理文件當中，以便在以后的某個時間完成與ClearQuest相關的操作。

2.4 檢入后提交(Postcheckin commit)

就是在ClearCase的Check in完成之后，再進行ClearQuest的操作。一般的情況下，在ClearCase的Check in操作完成之后，才進行與ClearQuest相關的操作。這樣在Check in操作失敗的情況下，會造成ClearCase和ClearQuest的數據不一致。啟用此功能則可以避免這種錯誤。

2.5 自動關聯(Auto-association)

就是在將變更請求關聯到某個版本的時候，不需要手工選擇，而是靠預先設置的請求ID或者根據ClearCase操作的注釋自動提取請求ID，來決定關聯的請求。

2.6 使用CQWeb方式的集成

在本地沒有安裝ClearQuest，或者不愿意使用本地的ClearQuest的情況下，可以使用CQWeb的方式使用CQWeb Server上的ClearQuest來實現ClearCase和ClearQuest的集成。

3 何時采用Base ClearCase

我們知道UCM是一種對版本控制的配制管理流程，而UCM是基于Base ClearCase的管理流程演變而來的。因此掌握并了解Base ClearCase的管理就顯得至關重要。Base ClearCase包含了一系列功能，它們能夠使開發人員做到并行開發，項目管理者也能通過制定相關的規則來使開發工作有序的進行。

在開發過程中，Base ClearCase應用"分支(Branch)"的方法來允許開發人員進行并行開發。任何在配制管理下的元素(Element)，例如：文本文件，程序原代碼等，都會生成一個主分支，而主分支下還可以有多個下屬分支，它們的作用是用來支持在主分支上的開發。Base ClearCase 允許創建復雜的分支體系。在開發過程中，通過視圖（View）可以訪問特定元素集的特定版本，而這通過修改視圖的規則(Config Specification)就可以實現。UCM也使用"分支"的方法，但是這些分支不需要用手工來操作，而是通過"流(Stream)"來實現，通常情況下，一個項目存在一個集成流和多個開發流。

在項目管理方面，我們通過對項目的源文件打基線(Baseline)來呈現項目早期較穩定版本的雛形，并且基線可以用來連接一系列相關的源文件，比如像源代碼，測試計劃等等。UCM自動完成基線的創建，而Base ClearCase則通過對元素(Elements)的版本打標簽來創建基線。

通過以上對UCM和Base ClearCase的比較，因此在一個項目不是很大，并且業務流程相對簡單的情況下適合用Base ClearCase。

4 運行環境的搭建與設置

4.1 運行環境的搭建

在Base CCCQ集成的過程中，運行環境的搭建尤為重要。

圖 (01) 系統結構圖

首先，需要在ClearCase客戶端和ClearCase注冊服務器安裝ClearCase。在ClearQuest Unix服務器和ClearQuest Windows服務器安裝ClearQuest。準備數據庫服務器。在ClearQuest Unix服務器上配置好DBSet，并添加User DB。之后就可以配置集成了。

4.2 ClearCase與ClearQuest集成的配制

集成的配置需要在ClearCase和ClearQuest上分別進行配置，才能完成。在ClearCase側，需要對VOB配置。當對一個VOB配置了集成之后，針對與這個VOB的ClearCase相關操作（例如CheckOut, CheckIn）都會激發腳本對ClearQuest數據庫的訪問，進而完成Base CC和CQ的集成。

在ClearQuest側，需要在數據庫中添加ClearCase的定義，只有加入了定義之后，數據庫中的請求的變更集才能夠顯示出來。

下面具體介紹配置過程。

4.2.1 將ClearCase package加入到一個ClearQuest DBset

由于ClearQuest schema包含了一些與多個ClearQuest user databases相關聯的特性，例如數據記錄的類型，區域，和形式。在開發人員將ClearCase中文件的版本與ClearQuest用戶數據庫中的變更請求相聯系的時候，必須將ClearCase的特性也加入到ClearQuest schema，此過程要在Windows端完成且過程如下所述：

• 開始 -> 程序 -> Rational Software -> Rational ClearQuest -> ClearQuest Designer
• 在ClearQuest Designer中，點擊Package -> Package Wizard
• 在安裝Package向導中，找到ClearCase 1.0和ClearCase Upgrade 1.0，如果這些Packages沒有列出，則點擊"More Packages"，并將上述的兩個Packages添加到列表中。
• 選擇ClearCase 1.0 Package并點擊"下一步"
• 選擇一個將會應用ClearCase 1.0 Package的schema e.g. Defect Tracking，點擊"下一步"
• 選擇數據紀錄的類型并點擊"完成"
• 選擇File -> Check In來保存schema的最新版本
• 選擇Database -> Upgrade Database把schema的最新版本升級到ClearQuest user database中

4.2.2 在ClearCase VOBs上安裝觸發器(Triggers)

CCCQ的集成應用到了針對cleartool checkin, checkout和uncheckout操作的觸發器，觸發器的安裝與配制需要在Windows端配制，該Windows的Registry Server必須與UNIX上建VOBs的那臺Server指向同一臺Registry Server。具體配置過程如下所述：

4.2.2.1 同步UNIX與Windows上的ClearCase Regions

1) 在Windows上新建一個Region，名稱與需要同步的UNIX上的Region名稱相同，這時UNIX上的Region就在Registry Server上注冊了。

2) 運行 -> cleartool -> mkregion -tag <UNIX region>

3) 開始 -> 程序 -> Rational Software ->

4) Rational ClearCase'Administration'Region Synchronizer

圖 (02) 導入Unix服務器上的VOB

5) 選擇需要同步的Windows Region和UNIX Region, 在Import Type一項上選擇"VOB Tags"并且選中"Show full storage directory paths.

6) 在"Unix VOB tags not found in the Windows region"列表中選擇需要引入的VOB，點擊"Import"，這時"Create VOB Tag"對話框會顯示出來。在"Global Storage"一項中輸入在UNIX服務器上的VOB的網絡存儲路徑，并且在"Hostname"一項中輸入在Region內能夠解析的主機名。

圖 (03) 創建Tag

4.2.2.2 將一個VOB安裝上Trigger

當一個VOB被引入（Import）后，我們可以對其安裝Trigger 在ClearCase中，點擊開始 -> 程序 -> Rational Software'Rational ClearCase'Administration'Integrations'ClearQuest Integration Configuration. 這時出現如下圖所示的對話框。

圖 (04) 應用Trigger

在"ClearCase - ClearQuest Integration Configuration"對話框中，我們可以看到所有在UNIX服務器端建立好的VOBs，并且可以對其中任何一個VOB安裝trigger。在這里，我們對VOB int4安裝Checkout和Checkin的trigger。Trigger的配制文件在config.pl中有詳細說明，關于trigger選擇的詳細內容可以參看上一章節。

提示：

• 觸發器使用config.pl配制文件來控制本地集成的配制參數。當選擇V2觸發器時，配置應用程序會將config.pl文件路徑設為CQCC/config.pl，在這個路徑中CQCC代表了本地的cc-home-dir/lib/perl5/CQCCTrigger/CQCC這個路徑，用戶可以根據需要將這個路徑改變為一個UNC路徑，因此所有的集成操作將調用一個中心配制文件config.pl。
• 在安裝觸發器時，只有VOB的所有者才可以對自己創建的VOB安裝觸發器。如果一個用戶e.g. Harry登陸Windows，他想對Andy在UNIX上創建的VOB安裝觸發器，這時會出現"無法得到觸發器類型"等警告。如果Harry希望可以對VOB安裝觸發器，那么需要執行以下兩步：
• 在DOS模式下運行Runas /user:RATIONALCC\Andy cmd.exe命令，這個命令將以Andy的身份打開一個DOS窗口，并提示輸入用戶名和密碼。
• 在驗證通過登陸后，另一個DOS窗口將會打開，在這個窗口中，運行"cqconfig"來以Andy的身份在VOB上安裝觸發器。

4.2.3 核心文件config.pl的配置

config.pl文件的配置在Base ClearCase與ClearQuest集成的操作中起到重要的作用。config.pl文件中包含了一系列變量及參數的設置，設置的描述，以及在哪里可以配制這些參數（是在config.pl文件本身中設置還是在系統環境變量中設置）。

config.pl文件在不同操作系統上的存儲路徑：
Windows:C:\Program Files\Rational\Clearcase\lib\perl5\CQCCTrigger\CQCC\config.pl
UNIX: /usr/atria/sun5/lib/perl/CQCCTrigger/CQCC/config.pl

下面就一些重要的參數配置進行詳細的說明：

4.2.3.1 定義用戶數據庫

&SetConfigParm("CQCC_DATABASE_ENTITY_LIST","SAMPL: defect");
CQCC_DATABASE_ENTITY_LIST參數定義了一個或多個數據庫和數據庫所支持的數據紀錄類型。當定義多個數據庫時，參數的使用格式為：dbname1: entity1,entity2; dbname2: entity3,entity4。值得注意的是數據紀錄類型必須為在schema中已定義好的內容。

4.2.3.2 定義DBsets

&SetConfigParm("CQCC_DATABASE_SET", "<db_set_name>");
在ClearQuest中，當建立有多個DBsets時，即有多個schema存儲空間時，CQCC_DATABASE_SET參數用來指定一個當前可以使用的schema存儲空間。

4.2.3.3 選擇集成模式: 文本模式或圖形模式

&SetConfigParm("CQCC_GUI_ENABLE", "OFF");
此參數是一個開啟Perl/TK GUI圖形界面的開關。如果設置為"ON"（默認情況下），那么圖形界面會在需要的情況下顯示，例如，在運行xclearcase時。如果設置為"Always"，那么圖形界面會在命令行操作的形式也顯示。如果設置為"OFF"，那么圖形界面將永遠不顯示，因此只可以用命令行操作。

4.2.3.4 開啟DEBUG模式

&SetConfigParm("CQCC_DEBUG", "1");

此參數用來控制在運行時模式下DEBUG報告的輸出級別。0 - 代表沒有輸出；1 - 代表基本輸出（針對高級別的操作）；2 - 代表細節輸出。

提示：其他參數設置的詳細說明請參看config.pl文件。

4.2.4 執行Base CCCQ集成的最后檢驗

此時，根據以上所提供的信息，我們應能夠完成cqcc檢驗，檢驗ClearCase與ClearQuest是否能夠很有效的結合，并可以開始完成一些簡單的操作。

在UNIX客戶端運行：cqcc_launch -test

此時，cqcc_launch命令將會調用config.pl里的參數并試圖連接ClearQuest，如果連接成功，exit_status會顯示0，否則將顯示1（如下圖所示）

圖 (05) 驗證配置

5 在Windows的平臺上的操作范例

可以說，Base ClearCase的基本操作，就是Check Out和Check in兩個操作，下面就簡單介紹一下這兩個操作。

5.1 Check Out

1) 在ClearCase Explorer中，選中一個文件，進行Check Out操作。如果是配置完成后第一次進行操作，需要輸入ClearQuest的用戶名和密碼。

圖 (06) 登陸窗口

2) 登陸成功后，就會出現QSW(Query Association Window)窗口，顯示滿足條件的缺陷。選擇缺陷，點擊Association按鈕，可以將其放到上側窗口中，點擊OK，即可完成關聯。

圖 (07) 關聯窗口

3) 關聯成功后，在ClearQuest中打開相應的缺陷，在ClearCase頁中，可以查看到關聯的文件。

圖 (08) 在ClearQuest中查詢關聯的文件

4) 在ClearCase Explorer中右鍵點擊被關聯的文件，選擇版本屬性，查看被關聯的缺陷。

圖 (09) 在ClearCase中查詢關聯的問題

5.2 Check In

1) 在ClearCase Explorer中選中文件，進行Check Out操作，彈出QSW窗口。

圖 (10) 關聯窗口

2) 在ClearQuest中查看被關聯的文件。

圖 (11) 在ClearQuest中查詢關聯的文件

3) 在ClearCase中查看被關聯的缺陷。

圖 (12) 在ClearCase中查詢關聯的文件

1.在不同網絡環境中ClearCase的管理
http://www-128.ibm.com/developerworks/cn/rational/r-hanss/

2.IBM Rational ClearCase-Samba 協同環境的設置和問題解決
http://www-128.ibm.com/developerworks/cn/rational/r-cc-samba/

3.ClearCase Interoperation實例詳解
http://www-128.ibm.com/developerworks/cn/rational/06/r-shixl2/index.html

我也別貼了，到這里去找吧。
http://www-128.ibm.com/developerworks/cn/views/rational/articles.jsp

Windows Server 2003 部署通用結構分步指南

第一部分：將 Windows Server 2003 安裝為域控制器
http://www.microsoft.com/china/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/stepbystep/domcntrl.mspx

?

Win2K安裝與服務器配置(下)
http://article.pchome.net/00/01/79/90/

Windows Server 2003中的Active Directory服務
http://www.microsoft.com/china/technet/community/columns/profwin/pw0503.mspx

輕松配置Windows2003自帶MAIL服務器
http://server.chinabyte.com/91/2394591.shtml
手把手教您架設Windows2003共享服務器
http://server.chinabyte.com/185/2482185.shtml

checkstyle 是一個幫助開發者按照某種習慣編寫 java 代碼的工具，他實現了代碼檢查的自動化，幫助人們從這種繁瑣的工作中解放出來。

默認提供了對 sun 編程規范的支持，但是 checkstyle 是一個具有高可配置性的，你完全可以根據自己的要求來配置需要檢查的內容。

有以下這些東西
\lib\checkstyle-3.1\contrib\checkstyle-noframes.xsl
\lib\checkstyle-3.1\checkstyle-all-3.1.jar
\lib\checkstyle-3.1\sun_checks.xml????????????????????

在build.xml文件中添加
??? <patternset id="java.files.pattern" includes="**/*.java"/>

??? <target name="checkstyle" depends="prepare"?????????? 依賴prepare target
??????? description="Check code style for compliance with coding standards">
??????? <property name="checkstyle.data.dir"
??????????? location="${build.dir}/docs/checkstyle"/>???????????????? 存放路徑
??????? <property name="checkstyle.data.file"
??????????? location="${checkstyle.data.dir}/checkstyle.xml"/>???? xml文件
??????? <property name="checkstyle.report.file"
??????????? location="${checkstyle.data.dir}/checkstyle.html"/>?? html文件
??????? <property name="checkstyle.xsl.file"
??????????? location="${checkstyle.dir}/contrib/checkstyle-noframes.xsl"/>?? 選用的樣式表，checkstyle.dir為jar包的位置
??????? <mkdir dir="${checkstyle.data.dir}"/>
??????? <taskdef resource="checkstyletask.properties" classpath="${checkstyle.jar}"/>? 引入jar文件
??????? <checkstyle config="${checkstyle.dir}/sun_checks.xml"????????????????????? 選用sun的規范，可以修改為自己的最佳實踐
??????????? failOnViolation="false" failureProperty="checkstyle.failure">
??????????? <fileset dir="src">?????????????????????????????????????????????????????????????????? 對src目錄進行檢查
??????????????? <patternset refid="java.files.pattern"/>
??????????? </fileset>
??????????? <fileset dir="test">????????????????????????????????????????????????????????????????? 對test目錄進行檢查
??????????????? <patternset refid="java.files.pattern"/>
??????????? </fileset>
??????????? <!-- uncomment to print to console as well -->
??????????? <!--formatter type="plain"/-->
??????????? <formatter type="xml" toFile="${checkstyle.data.file}"/>???????? 生成xml文件
??????? </checkstyle>
??????? <xslt in="${checkstyle.data.file}" out="${checkstyle.report.file}"
??????????? style="${checkstyle.xsl.file}"/>??????????????????????????????????????? 生成報告,其格式取決于checkstyle.xsl.file
??? </target>

如圖所示：圖1列出了所有文件，圖2列出了所以錯誤








下面解釋了一些常見的輸出結果，以供參考。 ?
序號 ? ? ? ? ? ?輸出內容意義 ? ?
1 ?Type ?is ?missing ?a ?javadoc ?commentClass ? ?缺少類型說明 ? ?
2“{” ?should ?be ?on ?the ?previous ?line ?“{” ?應該位于前一行 ? ?
3Methos ?is ?missing ?a ?javadoc ?comment方法前面缺少javadoc注釋 ? ?
4Expected ?@throws ?tag ?for ?“Exception”在注釋中希望有@throws的說明 ? ?
5“.” ?Is ?preceeded ?with ?whitespace ?“.” ?前面不能有空格 ? ?
6“.” ?Is ?followed ?by ?whitespace“.” ?后面不能有空格 ? ?
7“=” ?is ?not ?preceeded ?with ?whitespace“=” ?前面缺少空格 ? ?
8“=” ?is ?not ?followed ?with ?whitespace“=” ?后面缺少空格 ? ?
9“}” ?should ?be ?on ?the ?same ?line“}” ?應該與下條語句位于同一行 ? ?
10Unused ?@param ?tag ?for ?“unused”沒有參數“unused”，不需注釋 ? ?
11Variable ?“CA” ?missing ?javadoc變量“CA”缺少javadoc注釋 ? ?
12Line ?longer ?than ?80characters行長度超過80 ? ?
13Line ?contains ?a ?tab ?character行含有”tab” ?字符 ? ?
14Redundant ?“Public” ?modifier冗余的“public” ?modifier ? ?
15Final ?modifier ?out ?of ?order ?with ?the ?JSL ?suggestionFinal ?modifier的順序錯誤 ? ?
16Avoid ?using ?the ?“.*” ?form ?of ?importImport格式避免使用“.*” ? ?
17Redundant ?import ?from ?the ?same ?package從同一個包中Import內容 ? ?
18Unused ?import-java.util.listImport進來的java.util.list沒有被使用 ? ?
19Duplicate ?import ?to ?line ?13重復Import同一個內容 ? ?
20Import ?from ?illegal ?package從非法包中 ?Import內容 ? ?
21“while” ?construct ?must ?use ?“{}”“while” ?語句缺少“{}” ? ?
22Variable ?“sTest1” ?must ?be ?private ?and ?have ?accessor ?method變量“sTest1”應該是private的，并且有調用它的方法 ? ?
23Variable ?“ABC” ?must ?match ?pattern ?“^[a-z][a-zA-Z0-9]*$”變量“ABC”不符合命名規則“^[a-z][a-zA-Z0-9]*$” ? ?
24“(” ?is ?followed ?by ?whitespace“(” ?后面不能有空格 ?25“)” ?is ?proceeded ?by ?whitespace“)” ?前面不能有空格
25 Line has trailing spaces? 行的最后不能有空格

根據sun_checks.xml文件的內容，可以到http://checkstyle.sourceforge.net/checks.html這里查看具體的配置，實現你們的最佳實踐

用 Jester 對測試進行測試 測試套件有缺陷，這不是玩笑

文檔選項 將此頁作為電子郵件發送 未顯示需要 JavaScript 的文檔選項 最新推薦 Java 應用開發源動力 － 下載免費軟件，快速啟動開發

級別: 初級

Elliotte Rusty Harold , 副教授, Polytechnic University

2005 年 6 月 02 日

全面的單元測試套件對健壯的程序是必不可少的。但是如何才能保證測試套件測試了應當測試的每件事呢？Ivan Moore 的 JUnit 測試的測試器 Jester，擅長發現測試套件的問題，并提供對代碼基本結構的深入觀察。Elliotte Rusty Harold 介紹了 Jester 并展示如何使用它才能得到最佳結果。

測試先行的開發是極限編程（XP）中爭議最少、采用最廣泛的部分。到目前為止，大多數專業 Java 程序員都可能捕捉過測試 bug。（請參閱 參考資料 獲得有關“被測試傳染”的更多信息。） JUnit 是 Java 社區事實上的標準測試框架，沒有經過全面的 JUnit 測試套件測試過的系統是不完整的。如果您的項目有全面的測試套件，那么恭喜您：您將制作出質量良好的、有利于工作的軟件。但是大多數代碼基礎相當復雜。您能確定每個方法都被測試到、每個分支都進入過么？如果不能，那么當這些方法和分支在生產中執行的時候，應用程序會如何表現呢？

代碼覆蓋

對代碼進行測試的下一步是用 代碼覆蓋 工具對測試進行度量。代碼覆蓋是一種查看一套測試覆蓋了多少代碼的方法。信心的獲得，不僅需要知道測試了程序整體，還要知道每個方法在全部可能情況下都得到測試。傳統情況下，這類度量的執行方法是在測試執行時對測試進行監視，可以通過 Java 虛擬機調試接口（JVMDI）或 Java 虛擬機工具接口 （JVMTI）進行，或者直接處理字節碼。一次都沒有執行過的語句是測試不到的。

Clover 和 EMMA（參閱 參考資料） 這類工具采用的這種方法對于發現測試不到的語句很有價值 —— 但是還不夠。知道測試套件沒有執行某個語句，可以證明該語句沒測試到。但是，反過來不成立。如果執行了某一行代碼，并不一定代表它得到測試。完全有可能存在這樣的情況：測試并沒有檢查代碼行是否生成正確結果。

當然，沒有人會編寫測試套件對每個語句的結果都進行驗證。在眾多的問題當中，這個問題可能會破壞封裝。您可能認為，針對特定輸入，只有方法中的每一行都操作正確，方法才會生成預期結果。但是這個假設并不合理。例如，如果沒有測試到所有可能輸入，也就沒有測試到為處理邊際情況而設計的代碼，這時會如何呢？有可能還會測試到每行代碼，但有可能遺漏真正的 bug。

并不簡單 Jester 的方法并不簡單。這個工具有可能會報告大量假陽性。例如，它可能把 System.out.println("Copyright 2005 Elliotte Rusty Harold") 語句改成 System.out.println("Copyright 3005 Elliotte Rusty Harold") ，然后報告沒有破壞發生。但是，假陽性一般很容易過濾出來。另外，通常也有合適的理由懷疑像這個示例一樣的情況是否真的是假陽性。例如，對于版權日期 3005 是否是測試套件應當通知的 bug，有人可能會有異議。

回頁首

Jester 簡介

這正是 Jester 發揮作用的地方。與 Clover 這類傳統的代碼覆蓋工具不同，Jester 不去查看報告了哪行代碼。相反，Jester 會修改源代碼、重新編譯源代碼，然后運行測試套件，查看是否有什么事出錯。例如，它會把 1 改成 2，或者把 if (x > y) 改成 if (false)。如果測試套件的關注不夠，沒有注意到修改，那么就說明遺漏了某項測試。

我將通過在開源的 Jaxen XPath 工具（參閱 參考資料）上應用 Jester 而對它進行演示。Jaxen 有一個基于 JUnit 的測試套件，而且這個套件的代碼覆蓋并不完善。

入門

在運行 Jester 之前，所有對沒有修改的源代碼的單元測試都必須測試通過。如果不是這樣，那么 Jester 就無法知道是不是它的修改造成了破壞。（為了演示，我不得不修復一個 bug，我過去為它編寫了測試用例，但是沒有跟蹤修復它。）

Jester 與 IDE 的集成不是特別好（或者根本不好），所以要讓測試通過，重要的是正確設置 CLASSPATH 和目錄。運行測試套件所需要的命令行對于每個項目都是不同的。因為 Jaxen 測試使用指向特定測試文件的相對 URL ，所以它的測試必須在 jaxen 目錄中運行。下面是我最后運行 Jaxen 測試的方式：

												
														$ java -classpath ../jester136/jester.jar:target/lib/junit-3.8.1.jar
:target/lib/dom4j-core-1.4-dev-8.jar:target/lib/jdom-b10.jar
:target/lib/xom-1.0d21.jar:target/test-classes:target/classes 
junit.textui.TestRunner org.jaxen.JaxenTests
												
										

在運行 Jester 之前，還需要清楚針對測試套件的一項附加限制。除非測試失敗，否則不能打印有關 System.err 的任何內容。Jester 要通過檢查打印的內容來判斷測試是否成功，所以對 System.err 的程序輸出會把 Jester 弄混。

測試套件運行無誤之后，請做一份源代碼樹的拷貝。記住，Jester 要向代碼故意加入 bug，所以您可不要冒險在出現問題的情況下遺漏一個 bug。（如果您在使用源代碼控制，那么這不會是個大問題。如果沒有，請暫停閱讀本文，立即把代碼簽入 CVS 或 Subversion 倉庫。）

運行 Jester

要運行 Jester，在路徑中必須同時擁有 jester.jar 和 junit.jar（JUnit 沒有和 Jester 綁在一起。需要分別下載）。Jester 在類路徑中查找它的配置文件，所以必須還要把 Jester 的主目錄放在類路徑中。當然，還需要添加所測試的應用程序需要的其他 JAR。主類是 jester.TestTester。傳遞給這個程序的參數是測試應用程序的測試套件名稱。（我不得不為 Jaxen 編寫一個主類，因為它沒有包含一個可以運行它的全部測試的類。）如果把全部必要的 JAR 文件和目錄都添加到 CLASSPATH 環境變量，而不是把它們添加到 jre/lib/ext 或者用 -classpath 引用它們，那么 Jester 工作起來會更加穩定。下面是我針對 Jaxen 運行初始測試的方式：

												
														$ export CLASSPATH=src2/java/main:../jester136/jester.jar:../jester136
:target/lib/junit-3.8.1.jar:target/lib/dom4j-core-1.4-dev-8.jar
:target/lib/jdom-b10.jar:target/lib/jdom-b10.jar:target/lib/xom-1.0d21.jar
:target/test-classes:target/classes
$ java  jester.TestTester org.jaxen.JaxenTests src2/java/main 
												
										

Jester 運行很慢，即使檢測一個文件也是如此。它顯示一個進度對話框，如圖 1 所示，并在 System.out 上打印輸出，讓您知道它在做的工作，并向您保證它并沒有完全掛起。

如果在第一次運行若干分鐘（或者時間足夠運行完整的測試套件，甚至更長）之后，什么輸出也沒有看到，那么 Jester 可能 確實 掛起了，這很可能是因為類路徑的問題。如果每件事都進行順利，那么應當看到像清單 1 所示的輸出：

												
																		Use classpath: src2/java/main:../jester136/jester.jar
:../jester136:target/lib/junit-3.8.1.jar:target/lib/dom4j-core-1.4-dev-8.jar
:target/lib/jdom-b10.jar:target/lib/jdom-b10.jar:target/lib/xom-1.0d21.jar
:target/test-classes:target/classes
...
src2/java/main/org/jaxen/BaseXPath.java 
 - changed source on line 192 (char index=7757) from 1 to 2
             answer.size() == ?1 )
        {
            Object first = answ

src2/java/main/org/jaxen/BaseXPath.java 
 - changed source on line 691 (char index=24848) from 0 to 1


        return results.get( ?0 );
    }
}

lots more output...
src2/java/main/org/jaxen/BaseXPath.java 
 - changed source on line 691 (char index=24848) from 0 to 1


        return results.get( ?0 );
    }
}



10 mutations survived out of 11 changes. Score = 10
took 1 minutes
												
										

從清單 1 中可以看到，BaseXPath 沒有得到很好的測試。Jester 對類進行了 11 項修改，而只有一項造成測試失敗。有些修改是假陽性，但是 11 處修改肯定不應當只報告 1 處。

下一步是在不破壞測試套件的情況下查看 Jester 改變的代碼，看看是否需要為它編寫測試。Jester 在 GUI 中顯示它進行的修改，如 圖 1 所示（它不能在無人控制的情況下運行，這有點煩人），在控制臺上打印輸出，如 清單 1 所示，并生成 XML 文件，文件中是沒有產生影響的修改列表，如清單 2 所示：

												
																		<JesterReport>
<JestedFile fileName="src2/java/main/org/jaxen/BaseXPath.java" absolutePathFileName=
"/Users/elharo/Documents/articles/jester/jaxen/src2/java/main/org/jaxen/BaseXPath.java" 
numberOfChangesThatDidNotCauseTestsToFail="8" numberOfChanges="11" score="28">
<ChangeThatDidNotCauseTestsToFail index="7691" from="if (" to="if (true ||"/>
<ChangeThatDidNotCauseTestsToFail index="7691" from="if (" to="if (false &&"/>
<ChangeThatDidNotCauseTestsToFail index="7703" from="!=" to="=="/>
<ChangeThatDidNotCauseTestsToFail index="7754" from="==" to="!="/>
<ChangeThatDidNotCauseTestsToFail index="7757" from="1" to="2"/>
<ChangeThatDidNotCauseTestsToFail index="7826" from="if (" to="if (true ||"/>
<ChangeThatDidNotCauseTestsToFail index="7826" from="if (" to="if (false &&"/>
<ChangeThatDidNotCauseTestsToFail index="24749" from="if (" to="if (false &&"/>
</JestedFile></JesterReport>
												
										

Jester 的行號報告通常不是個好方法，所以最好是在控制臺輸出中查找修改的代碼。下面是 清單 1 的報告中的修改：

												
														src2/java/main/org/jaxen/BaseXPath.java 
 - changed source on line 691 (char index=24848) from 0 to 1


        return results.get( ?0 );
    }
}
												
										

在這個方法中，這個修改是在類的結束處：

												
														protected Object selectSingleNodeForContext(Context context) throws JaxenException 
{
  List results = selectNodesForContext( context );

  if ( results.isEmpty() )
  {
    return null;
  }

        return results.get( 0 );
}
												
										

對測試套件迅速查找之后發現，實際上沒有測試調用 selectSingleNodeForContext。所以下一步就是為這個方法編寫一個測試。這個方法是 protected 的方法，所以測試不能直接調用它。有時需要編寫一個子類（通常作為內部類）來測試 protected 的方法。但是在這個例子中，稍做一點檢查就很快發現這個方法由同一個類中的兩個 public 方法（stringValue 和 numberValue）直接調用。所以也可以用這兩個方法來測試它：

												
														    public void testSelectSingleNodeForContext() throws JaxenException {
        
        BaseXPath xpath = new BaseXPath("1 + 2");
        
        String stringValue = xpath.stringValueOf(xpath);
        assertEquals("3", stringValue);
        
        Number numberValue = xpath.numberValueOf(xpath);
        assertEquals(3, numberValue.doubleValue(), 0.00001);
        
    }
												
										

最后一步是運行測試用例，確定它通過。下面是結果：

												
														java.lang.NullPointerException
	at org.jaxen.function.StringFunction.evaluate(StringFunction.java:121)
	at org.jaxen.BaseXPath.stringValueOf(BaseXPath.java:295)
	at org.jaxen.BaseXPathTest.testSelectSingleNodeForContext(BaseXPathTest.java:23)
												
										

Jester 捕捉到一個 bug！方法沒有像預期的那樣工作。更有趣的是，對 bug 的調查揭示出潛在的設計缺陷。BaseXPath 類可能更適合作為抽象類而不是具體類。我發誓，我并不是特意挑選這個示例來公開這個 bug。我從 BaseXPath 開始只是因為它是頂級 org.jaxen 包的第一個類，而且我選擇 selectSingleNodeForContext 作為所測試的方法也只是因為它是 Jester 報告的最后一個錯誤。我真的認為這個方法沒有什么問題，但是我錯了。如果某些事沒有經過測試，那么就應當假設它是有問題的。Jester 會告訴您出了什么問題。

下一步顯而易見：修復 bug。（請確保同時對 Jester 正在處理的源樹拷貝和實際樹中的 bug 進行了修復。）然后，迭代 —— 針對這個類重新運行 Jester，直到任何修改都不能通過，或者可以通過的修改都是不相關的。在我為這個 bug 添加測試（并修復）之后，Jester 就報告 11 個修改中只有 8 個沒有檢測到，如 清單 2 所示。這在調試中是經常出現的事：修復了一個問題就修復（或者暴露了）另外幾個。

回頁首

Jester 的性能

因為 Jester 重新編譯代碼基，而且要為自己做的每個修改都重新運行測試套件，所以它的運行要比 Clover 這樣的傳統工具慢得多。因此，對性能加以關注是很重要的?？梢杂迷S多技術加快 Jester 的運行。

首先，如果編譯在 Jester 執行時間中占了顯著部分，那么請嘗試使用一個更快的編譯器。許多用戶都報告采用 Jikes 代替 Javac 后速度有顯著提高（參閱 參考資料）。可以在 Jester 主目錄中的 jester.cfg 文件中修改 Jester 使用的編譯命令。

第二，剖析和優化測試套件。一般情況下，人們對單元測試運行的速度沒太注意，但是如果乘上 Jester 上千次執行測試套件的次數，那么任何節約都會非常顯著。具體來說，要在測試套件中查找在正常代碼中不會出現的問題。JUnit 會重新初始化每個執行方法的全部字段，所以如果不是測試類的每個方法都用的字段，那么把測試數據從字段中拿出來放在本地變量中，可以顯著提高速度。如果形成的代碼副本不合您的風格，請嘗試把測試套件分成更小、更模塊化的類，以便所有的初始數據可以在全部測試方法之間共享。

第三，重新組織測試套件的 suite 方法，以便最脆弱的測試（修改之后最有可能出錯的）在不太脆弱的測試之前運行。只要 Jester 發現一個測試失敗，就會終止運行，所以盡早失敗可以短路大量耗時的額外測試。

第四，出于相似的原因，當測試失敗的機會差不多時，把最快的測試放在第一位。按照大概的執行時間給測試排序。只在內存中執行的測試在訪問磁盤的測試之前，訪問磁盤的測試在訪問 LAN 的測試之前，訪問 LAN 的測試在訪問 Internet 的測試之前。如果有些測試特別慢，試試去掉它們，即便這會增加假陽性的數量。在 XOM （一個用 Java 語言處理 XML 的 API）的測試套件中，在 50 個測試類中，只有很少的幾個就占據了 90% 以上的執行時間。在測試的時候清除這些類可以帶來 10 倍的性能提升。

最后，也是最重要的，就是不要一次測試整個代碼基。每次把測試限制在一個類上，而且只運行能夠暴露這個類的覆蓋不足的測試?？赡苄枰L時間來測試每個類，但是用這種方法，幾乎可以立即填補不足、修復 bug，而不必為 Jester 的一次運行完成等上好幾天。

回頁首

結束語

Jester 是聰明的程序員的工具包中一個重要的附加。它可以發現其他工具不能發現的代碼覆蓋不足，這會直接變成發現和修復 bug。使用 Jester 對代碼基進行測試，可以制造出更強壯的軟件。

回頁首

參考資料

• 您可以參閱本文在 developerWorks 全球站點上的 英文原文。
  
  
• 從 SourceForge 下載 Jester。
  
  
• 得到 test infected。
  
  
• JUnit 是 Java 代碼事實上的標準單元測試框架，也是 Jester 依賴的框架。
  
  
• 在本文中作為示例的 Jaxen 項目是一個用于 Java 語言的開源 XPath 引擎，適用于許多不同的對象模型。
  
  
• Clover 是一個更傳統的測試覆蓋工具，是 Jester 的有益補充。它比 Jester 更容易使用，也快得多；但是它只能測試在測試期間執行的代碼，而不是它真正要測試的代碼。
  
  
• EMMA 是一個免費、開源的代碼覆蓋工具。請學習面向 Java 程序員的各種不同的 開源單元測試工具 和 開源代碼覆蓋工具 的更多內容。
  
  
• 請閱讀 Dave Thomas 和 Andy Hunt 的 Pragmatic Unit Testing in Java With JUnit（Pragmatic Bookshelf, 2003）。
  
  
• Dennis M. Sosnoski 通過介紹開源的 Hansel 和 Gretel 代碼覆蓋工具，開始 了 Classworking 工具箱 系列。
  
  
• David Carew 和 Sandeep Desai 撰寫的“Keeping critters out of your code: How to use WebSphere and JUnit to prevent programming bugs”（developerWorks, 2003 年 6 月），介紹了采用 XP 方法進行測試。
  
  
• Malcolm Davis 撰寫的“利用 Ant 和 JUnit 進行增量開發”（developerWorks，2000 年 11 月），解釋了如何把 JUnit 集成到自己的項目中。
  
  
• Eric Allen 和 Roy Miller 在他們各自的專欄 診斷 Java 代碼 和 揭開極端編程的神秘面紗 中頻繁地涉及到單元測試。
  
  
• Erik Hatcher 撰寫的“讓編譯和測試過程自動化”（developerWorks，2001 年 8 月），介紹了如何把增量測試和持續構建組合到一個自動的過程中。
  
  
• Testdriven.com 是一個關于測試驅動開發的文章和資源的全面集合。
  
  
• Jikes 是一個用 C 編寫的開源的 Java 編譯器，運行起來比 javac 快得多。
  
  
• 在 developerWorks Java 技術專區 可以找到 Java 編程各方面的文章。
  
  
• 請訪問 Developer Bookstore，獲得技術書籍的完整列表，其中包括數百本 Java 相關主題 的圖書。
  
  
• 通過參與 developerWorks blogs 加入 developerWorks 社區。
  

回頁首

關于作者

		Elliotte Rusty Harold 來自新奧爾良，現在他還定期返回新奧爾良研究一盆秋葵。但是，他和妻子 Beth 及他們的貓咪 Charm（以夸克命名）和 Marjorie（以他的岳母為名），定居在布魯克林附近的 Prospect Heights。他是 Polytechnic 大學計算機科學的副教授，他在該校講授 Java 和面向對象編程。他的 Web 站點 Cafe au Lait 已經成為 Internet 上最流行的獨立 Java 站點之一，他的分站點 Cafe con Leche 已經成為最流行的 XML 站點之一。他的書包括 Effective XML、Processing XML with Java、Java Network Programming和 The XML 1.1 Bible。他目前在開發處理 XML 的 XOM API 和 XQuisitor GUI 查詢工具。

Quilt

Go To Quilt

EMMA

Go To EMMA

NoUnit

Go To NoUnit

InsECT

Go To InsECT

Hansel

Go To Hansel

Jester

Go To Jester

JVMDI Code Coverage Analyser

Go To JVMDI Code Coverage Analyser

GroboCodeCoverage

Go To GroboCodeCoverage

jcoverage/gpl

Go To jcoverage/gpl

JBlanket

Go To JBlanket

Cobertura

Go To Cobertura

Coverlipse

Go To Coverlipse

追求代碼質量: 監視圈復雜度 當代碼復雜度超出想像時該如何做

文檔選項 將此頁作為電子郵件發送 未顯示需要 JavaScript 的文檔選項 討論 最新推薦 Java 應用開發源動力 － 下載免費軟件，快速啟動開發

級別: 初級

Andrew Glover , 總裁, Stelligent Incorporated

2006 年 4 月 25 日

如果復雜度與缺陷緊密相關，那么監視代碼庫的復雜度值不是很有意義嗎？Andrew Glover 將展示如何使用簡單的代碼度量工具和基于 Java? 的工具來監視圈復雜度 (cyclomatic complexity)。

每位開發人員對代碼質量的含義都有著自己的看法，并且大多數人對如何查找編寫欠佳的代碼也有自己的想法。甚至術語代碼味道（code smell） 也已進入大眾詞匯表，成為描述代碼需要改進的一種方式。

圈什么？ 關于這篇文章和代碼質量主題的任何其他文章的問題，請訪問由 Andrew Glover 主持的 Improve your Java Code Quality 討論論壇。

代碼味道通常由開發人員直接判定，有趣的是，它是許多代碼注釋綜合在一起的味道。一些人聲稱公正的代碼注釋是好事情，而另一些人聲稱代碼注釋只是解釋過于復雜的代碼的一種機制。顯然，Javadocs? 很有用，但是多少內嵌注釋才足以維護代碼？如果代碼已經編寫得足夠好，它還需要解釋自己嗎？

這告訴我們，代碼味道是一種評估代碼的機制，它具有主觀性。我相信，那些聞起來味道糟透了的代碼可能是其他人曾經編寫的最好的代碼。以下這些短語聽起來是不是很熟悉？

是的，它初看起來有點亂，但是您要看到它多么可擴展?。?/i>

或者

它讓您感到迷惑，但顯然您不了解它的模式。

我們需要的是客觀評估代碼質量的方法，某種可以決定性地告訴我們正在查看的代碼是否存在風險的東西。不管您是否相信，這種東西確實存在！用來客觀評估代碼質量的機制已經出現了一段時間了，只是大多數開發人員忽略了它們。這些機制被稱為代碼度量 (code metric)。

代碼度量的歷史

幾十年前，少數幾個非常聰明的人開始研究代碼，希望定義一個能夠與缺陷關聯的測量系統。這是一個非常有趣的主張：通過研究帶 bug 代碼中的模式，他們希望創建正式的模型，然后可以評估這些模型，在缺陷成為缺陷之前 捕獲它們。

在這條研究之路上，其他一些非常聰明的人也決定通過研究代碼看看他們是否可以測量開發人員的生產效率。對每位開發人員的代碼行的經典度量似乎只停留在表面上：

Joe 生產的代碼要比 Bill 多，因此 Joe 生產率更高一些，值得我們花錢聘請這樣的人。此外，我注意到 Bill 經常在飲水機邊閑晃，我認為我們應該解雇 Bill。

但是這種生產率度量在實踐中是非常令人失望的，主要是因為它容易被濫用。一些代碼測量包括內嵌注釋，并且這種度量實際上受益于剪切粘貼式開發 (cut-and-paste style development)。

Joe 編寫了許多缺陷！其他每條缺陷也都是由他間接造成的。我們不該解雇 Bill，他的代碼實際上是免檢的。

可以預見，生產率研究被證實是非常不準確的，但在管理團隊 (management body) 廣泛使用這種生產率度量以期了解每個人的能力的價值之前，情況并非如此。來自開發人員社區的痛苦反應是有理由的，對于一些人而言，那種痛苦感覺從未真正走遠。

未經雕琢的鉆石

盡管存在這些失敗，但在那些復雜度與缺陷的相互關系的研究中仍然有一些美玉。大多數開發人員忘記進行代碼質量研究已有很長一段時間了，但對于那些仍正在鉆研的人而言（特別是如果您也正在為追求代碼質量而努力鉆研），會在今天的應用中發現這些研究的價值。例如，您曾注意到一些長的方法有時難以理解嗎？是否曾無法理解嵌套很深的條件從句中的邏輯？您的避開這類代碼的本能是正確的。一些長的方法和帶有大量路徑的方法是 難以理解的，有趣的是，這類方法容易導致缺陷。

我將使用一些例子展示我要表達的意思。

回頁首

數字的海洋

研究顯示，平均每人在其大腦中大約能夠處理 7（±2）位數字。這就是為什么大多數人可以很容易地記住電話號碼，但卻很難記住大于 7 位數字的信用卡號碼、發射次序和其他數字序列的原因。

此原理還可以應用于代碼的理解上。您以前大概已經看到過類似清單 1 中所示的代碼片段：

清單 1. 適用記憶數字的原理

if (entityImplVO != null) { List actions = entityImplVO.getEntities(); if (actions == null) { actions = new ArrayList(); } Iterator enItr = actions.iterator(); while (enItr.hasNext()) { entityResultValueObject arVO = (entityResultValueObject) actionItr .next(); Float entityResult = arVO.getActionResultID(); if (assocPersonEventList.contains(actionResult)) { assocPersonFlag = true; } if (arVL.getByName( AppConstants.ENTITY_RESULT_DENIAL_OF_SERVICE) .getID().equals(entityResult)) { if (actionBasisId.equals(actionImplVO.getActionBasisID())) { assocFlag = true; } } if (arVL.getByName( AppConstants.ENTITY_RESULT_INVOL_SERVICE) .getID().equals(entityResult)) { if (!reasonId.equals(arVO.getStatusReasonID())) { assocFlag = true; } } } }else{ entityImplVO = oldEntityImplVO; }

清單 1 展示了 9 條不同的路徑。該代碼片段實際上是一個 350 多行的方法的一部分，該方法展示了 41 條不同的路徑。設想一下，如果您被分配一項任務，要修改此方法以添加一項新功能。如果您該方法不是您編寫的，您認為您能只做必要的更改而不會引入任何缺陷嗎？

當然，您應該編寫一個測試用例，但您會認為該測試用例能將您的特定更改在條件從句的海洋中隔離起來嗎？

回頁首

測量路徑復雜度

圈復雜度 是在我前面提到的那些研究期間開創的，它可以精確地測量路徑復雜度。通過利用某一方法路由不同的路徑，這一基于整數的度量可適當地描述方法復雜度。實際上，過去幾年的各種研究已經確定：圈復雜度（或 CC）大于 10 的方法存在很大的出錯風險。因為 CC 通過某一方法來表示路徑，這是用來確定某一方法到達 100% 的覆蓋率將需要多少測試用例的一個好方法。例如，以下代碼（您可能記得本系列的第一篇文章中使用過它）包含一個邏輯缺陷：

清單 2. PathCoverage 有一個缺陷！

public class PathCoverage { public String pathExample(boolean condition){ String value = null; if(condition){ value = " " + condition + " "; } return value.trim(); } }

作為響應，我可以編寫一個測試，它將達到 100% 的行覆蓋率：

清單 3. 一個測試產生完全覆蓋！

import junit.framework.TestCase; public class PathCoverageTest extends TestCase { public final void testPathExample() { PathCoverage clzzUnderTst = new PathCoverage(); String value = clzzUnderTst.pathExample(true); assertEquals("should be true", "true", value); } }

接下來，我將運行一個代碼覆蓋率工具，比如 Cobertura，并將獲得如圖 1 中所示的報告：

圖 1. Cobertura 報告

哦，有點失望。代碼覆蓋率報告指示 100% 的覆蓋率，但我們知道這是一個誤導。

二對二

注意，清單 2 中的 pathExample() 方法有一個值為 2 的 CC（一個用于默認路徑，一個用于 if 路徑）。使用 CC 作為更精確的覆蓋率測量尺度意味著第二個測試用例是必需的。在這里，它將是不進入 if 條件語句而采用的路徑，如清單 4 中的 testPathExampleFalse() 方法所示：

清單 4. 沿著較少采用的路徑向下

import junit.framework.TestCase; public class PathCoverageTest extends TestCase { public final void testPathExample() { PathCoverage clzzUnderTst = new PathCoverage(); String value = clzzUnderTst.pathExample(true); assertEquals("should be true", "true", value); } public final void testPathExampleFalse() { PathCoverage clzzUnderTst = new PathCoverage(); String value = clzzUnderTst.pathExample(false); assertEquals("should be false", "false", value); } }

正如您可以看到的，運行這個新測試用例會產生一個令人討厭的 NullPointerException。在這里，有趣的是我們可以使用圈復雜度而不是 使用代碼覆蓋率來找出這個缺陷。代碼覆蓋率指示我們已經在一個測試用例之后完成了此操作，但 CC 卻會強迫我們編寫額外的測試用例。不算太壞，是吧？

幸運的是，這里的測試中的方法有一個值為 2 的 CC。設想一下該缺陷被隱藏在 CC 為 102 的方法中的情況。祝您好運找到它！

回頁首

圖表上的 CC

Java 開發人員可使用一些開放源碼工具來報告圈復雜度。其中一個這樣的工具是 JavaNCSS，它通過檢查 Java 源文件來確定方法和類的長度。此外，此工具還收集代碼庫中每個方法的圈復雜度。通過利用 Ant 任務或 Maven 插件配置 JavaNCSS，可以生成一個列出以下內容的 XML 報告：

• 每個包中的類、方法、非注釋代碼行和各種注釋樣式的總數。
  
  
• 每個類中非注釋代碼行、方法、內部類和 Javadoc 注釋的總數。
  
  
• 代碼庫中每個方法的非注釋代碼行的總數和圈復雜度。

該工具附帶了少量樣式表，可以使用它們來生成總結數據的 HTML 報告。例如，圖 2 闡述了 Maven 生成的報告：

圖 2. Maven 生成的 JavaNCSS 報告

此報告中帶有 Top 30 functions containing the most NCSS 標簽的部分詳細描述了代碼庫中最長的方法，順便提一句，該方法幾乎總是 與包含最大圈復雜度的方法相關聯。例如，該報告列出了 DBInsertQueue 類的 updatePCensus() 方法，因為此方法的非注釋行總數為 283，圈復雜度（標記為 CCN）為 114。

正如上面所演示的，圈復雜度是代碼復雜度的一個好的指示器；此外，它還是用于開發人員測試的一個極好的衡量器。一個好的經驗法則是創建數量與將被測試代碼的圈復雜度值相等的測試用例。在圖 2 中所見的 updatePCensus() 方法中，將需要 114 個測試用例來達到完全覆蓋。

回頁首

分而治之

在面對指示高圈復雜度值的報告時，第一個行動是檢驗所有相應測試的存在。如果存在一些測試，測試的數量是多少？除了極少數代碼庫以外，幾乎所有代碼庫實際上都有 114 個測試用例用于 updatePCensus() 方法（實際上，為一個方法編寫如此多的測試用例可能會花費很長時間）。但即使是很小的一點進步，它也是減少方法中存在缺陷風險的一個偉大開始。

如果沒有任何相關的測試用例，顯然需要測試該方法。您首先想到的可能是：到重構的時間了，但這樣做將打破第一個重構規則，即將編寫一個測試用例。先編寫測試用例會降低重構中的風險。減少圈復雜度的最有效方式是隔離代碼部分，將它們放入新的方法中。這會降低復雜度，使方法更容易管理（因此更容易測試）。當然，隨后應該測試那些更小的方法。

在持續集成環境中，隨時間變化 評估方法的復雜度是有可能的。如果是第一次運行報告，那么您可以監視方法的復雜度值或任何相關的成長度（growth）。如果在 CC 中看到一個成長度，那么您可以采取適當的動作。

如果某一方法的 CC 值在不斷增長，那么您有兩個響應選擇：

• 確保相關測試的健康情況仍然表現為減少風險。
• 評估重構方法減少任何長期維護問題的可能性。

還要注意的是，JavaNCSS 不是惟一用于 Java 平臺促進復雜度報告的工具。PMD 是另一個分析 Java 源文件的開源項目，它有一系列的規則，其中之一就是報告圈復雜度。CheckStyle 是另一個具有類似的圈復雜度規則的開放源碼項目。PMD 和 CheckStyle 都有 Ant 任務和 Maven 插件（請參閱 參考資料，從那里獲得關于至此為止討論的所有工具的更多信息。）

回頁首

使用復雜度度量

因為圈復雜度是如此好的一個代碼復雜度指示器，所以測試驅動的開發 (test-driven development) 和低 CC 值之間存在著緊密相關的聯系。在編寫測試時（注意，我沒有暗示是第一次），開發人員通常傾向于編寫不太復雜的代碼，因為復雜的代碼難以測試。如果您發現自己難以編寫某一代碼，那么這是一種警示，表示正在測試的代碼可能很復雜。在這些情況下，TDD 的簡短的 “代碼、測試、代碼、測試” 循環將導致重構，而這將繼續驅使非復雜代碼的開發。

所以，在使用遺留代碼庫的情況下，測量圈復雜度特別有價值。此外，它有助于分布式開發團隊監視 CC 值，甚至對具有各種技術級別的大型團隊也是如此。確定代碼庫中類方法的 CC 并連續監視這些值將使您的團隊在復雜問題出現時 搶先處理它們。

回頁首

參考資料

學習

• 您可以參閱本文在 developerWorks 全球站點上的 英文原文 。
  
  
• “追求代碼質量: 不要被覆蓋報告所迷惑”（Andrew Glover，developerWorks，2006 年 1 月）：測試覆蓋率的測量是否讓您誤入歧途？找出新系列中的第一篇文章！
  
  
• “測試優先 Ruby 編程”（Pat Eyler，developerWorks，2005 年 5 月）：test-first 開發中的一個簡單練習，其中包括關于重構的討論。
  
  
• “用 Cobertura 測量測試覆蓋率”（Elliotte Rusty Harold，developerWorks，2005 年 5 月）：關于使用 Cobertura 來測量測試覆蓋率的初級讀物。
  
  
• Java 技術專區 ：數百篇 Java 編程各方面的文章。

獲得產品和技術

• JavaNCSS ：適用于 Java 平臺的一個源代碼測量套件。
  
  
• PMD ：這個流行的開放源碼工具掃描 Java 代碼以發現問題。
  
  
• CheckStyle ：來自 SourceForge 的另一個 Java 分析工具。
  
  

討論

• 參與論壇討論 。
  
  
• developerWorks blogs ：加入 developerWorks 社區！
  
  

回頁首

關于作者

		Andrew Glover 是 Stelligent Incorporated 的總裁，該公司采用有效的開發人員測試策略和持續集成技術（讓團隊能夠盡早且經常地監視代碼質量）幫助其他公司解決軟件開發質量問題。他還是 Java Testing Patterns（Wiley，2004 年 9 月）一書的合著者。