持續檢查--把自己從軟件檢查員尋常的手工檢查工作中解放出來

對每個更改都進行檢查，將缺陷控制在限度內

每當團隊成員向版本控制存儲庫提交更改時，代碼就會發生改變。但它是怎么改變的呢？被修改的代碼是受到復制-粘貼工作的影響嗎？復雜性會增加嗎？了解這些的惟一方式就是在每次簽入 時都運行軟件檢查器。此外，在持續的基礎上接受目前為止討論過的每種風險的反饋，這是一種自動 讓代碼基進行健康檢查的一種可靠方式！

Cruise 與 CI

CruiseControl 是 Java™ 社區使用最廣的開源 CI 工具之一。這個工具被配置成在后臺運行，用于檢索版本控制存儲庫，例如 CVS。在發現源代碼更改時（例如，有人簽入了代碼），CruiseControl 就會執行源代碼簽出，并運行預定義的構建腳本。

所以，只要 版本控制存儲庫中發生了變化，團隊就可以運行 CheckStyle、CPD 和 JavaNCSS 這樣的軟件檢查器。這種能力允許團隊長時間地進行監視和執行檢查，通過使用許多 CI 工具，團隊可以使用報告、電子郵件甚至使用 Ambient Orb 這樣的設備生成報告（參見 圖 5）。

清單 5 演示了使用 CruiseControl 的配置文件（通常名為 config.xml）在 CruiseControl 控制板上顯示 CheckStyle 報告的結果。其他軟件檢查器使用類似的語法將結果合并到 CruiseControl 儀表板中。

<listeners>  <currentbuildstatuslistener file="logs/${project.name}/status.txt"/></listeners><modificationset quietperiod="30">  <svn RepositoryLocation="http://www.qualitylabs.org/svn/ambientorb"    username="[username]"    password="[password]"  /></modificationset><schedule interval="60">  <ant anthome="apache-ant-1.6.5" buildfile="build-${project.name}.xml"/></schedule><log>  <merge dir="merge dir="checkout/${project.name}/_reports/checkstyle" /></log>

圖 4 顯示了用 CruiseControl 和 CheckStyle 生成的示例報告。請注意，可以配置 CruiseControl，顯示其他工具（像 CPD 和 JavaNCSS）的報告，而且通過對每個源代碼更改 都運行這些報告，團隊可以實時地積極改進代碼，不必等到周期末期。

Ambient 反饋

對于使用 CI 工具持續運行軟件檢查器而言，最酷的事就是團隊有了無數任意使用的通知機制。有時，構建可能并沒有失敗，但是有些事 的變化要求早些而不是晚些采取糾正行動。例如，實際上可以很容易地配置一個設備（就像 Ambient Orb），在代碼復雜度有所上升時，或者在違反一定數量的代碼標準時，使用該設備改變顏色。

清單 6 使用了 Ambient Orb Ant 任務和 Ruby 腳本，在 20 個以上的類超過 300 個源代碼行（SLOC）時，就改變 Orb 的顏色和動畫。在這個示例中，我選擇在類滿足條件時將 orb 的顏色改成 magenta，將動畫改成 crescendo。

  <target name="checkSloc" >    <exec dir="${basedir}" executable="cmd.exe">      <arg line="/c ${config.dir}/javancss/SlocThreshold.rb           ${reports.javancss.dir}/javancss_metrics.xml 20 ${javancss.file}"/>    </exec>    <available file="${basedir}/${javancss.file}" property="sloc.exceeded"/>    <antcall target="notifyOrb" />  </target>  <target name="notifyOrb" if="sloc.exceeded">    <taskdef classname="org.qualitylabs.ambientorb.ant.OrbTask"     name="orb" classpathref="orb.class.path"/>    <orb query="http://myambient.com:8080/java/my_devices/submitdata.jsp"      deviceId="AAA-9A9-AA9"      colorPass="green"      colorFail="magenta"      animationPass="none"      animationFail="crescendo"      commentFail="SLOC+Exceeded" />      </target>

圖 5 演示了代碼基中有太多較大的類時，orb 看起來的樣子：

使用這種 Ambient Orb 通知方法，就不會收到無窮盡的電子郵件，只要看一眼 SLOC Threshold Orb，就可以快速了解我有多少個大型類，它們提醒我要重定向重構工作。當然，組合 ambient orb 與軟件監視器（稍帶些創意）也會創造無窮的可能性！

在合適的時候自動化

請記住，可以選擇許多不同的軟件檢查器。雖然這里分析了三個我喜歡的軟件檢查器，但我還是被 JDepend、PMD 和 FindBugs 工具（后兩個檢查器在 developerWorks 上已詳細討論過）所打動。一旦開始持續檢查過程，插入一個新的檢查器只是幾分鐘的事而已。

持續檢查不會也不應該消除手工軟件檢查；但是，通過對版本控制存儲庫中的每個更改都運行一套自動檢查工具，將要執行的 這些手工檢查會帶來更高的生產率和效率。而且，持續檢查帶來的額外好處有：風險在每一步上都可以降低，而不必等到項目后期。

下一個月，我將深入研究一些更有趣的持續集成工具，例如 CruiseControl、Luntbuild 和 Continuum，并讓您確定哪一個工具最適合您。自動化從未 這么有趣過！

文章來源于領測軟件測試網 http://www.kjueaiud.com/