| 2007 年 3 月 26 日 準備好開(kāi)始在您的開(kāi)發(fā)人員測試活動(dòng)中大獲全勝嗎？在本期的 讓開(kāi)發(fā)自動(dòng)化 中，開(kāi)發(fā)自動(dòng)化專(zhuān)家 Paul Duvall 介紹了幾種自動(dòng)化的開(kāi)發(fā)人員測試，每一次改變源代碼都能夠運行這些測試。Paul 提供了 Selenium、DbUnit 和 JUnitPerf 測試的例子，即，如果經(jīng)常 運行這些測試可以幫助您盡早發(fā)現應用程序的問(wèn)題。 在像 Eclipse 那樣的 IDE 中或者比如在 Ant 構建腳本中運行單元測試是確保應用程序質(zhì)量的一個(gè)很好的開(kāi)始；然而，版本控制庫（如 Subversion）中的源代碼一改變，在單獨無(wú)變動(dòng)的構建機上運行單元測試就有助于檢驗開(kāi)發(fā)生命周期中的問(wèn)題。而且，運行各種類(lèi)型的開(kāi)發(fā)人員測試，如組件測試、功能測試和性能測試，能夠在開(kāi)發(fā)生命周期中更早地 將問(wèn)題顯示出來(lái)。 | 關(guān)于本系列
作為開(kāi)發(fā)人員，我們的工作就是為終端用戶(hù)實(shí)現過(guò)程自動(dòng)化；然而，很多開(kāi)發(fā)人員卻忽略了將自己的開(kāi)發(fā)過(guò)程自動(dòng)化的機會(huì )。為此，我編寫(xiě)了 讓開(kāi)發(fā)自動(dòng)化 這個(gè)系列的文章，專(zhuān)門(mén)探討軟件開(kāi)發(fā)過(guò)程自動(dòng)化的實(shí)際應用，并教您何時(shí) 以及如何 成功地應用自動(dòng)化。 | | 通常在持續集成（CI）環(huán)境中運行的開(kāi)發(fā)人員測試有效地扮演著(zhù)代碼質(zhì)量聚光燈的角色。這是因為如果能有效地編寫(xiě)這些測試，則幾乎能夠在問(wèn)題（如缺陷）產(chǎn)生之時(shí)就將其發(fā)現。不經(jīng)常運行測試通常就不怎么有效，因為從產(chǎn)生缺陷到發(fā)現該缺陷的時(shí)間相隔很長(cháng)，但持續地（即，每一次代碼改變時(shí)）運行測試能確?？焖侔l(fā)現無(wú)意識的行為。 本文涵蓋下列內容： - 通過(guò) Ant 運行 JUnit 測試
- 使用 JUnit 和 DbUnit 執行更長(cháng)時(shí)間的運行組件測試
- 使用 JUnitPerf 確定哪些方法花費時(shí)間過(guò)久而執行失敗
- 用 Selenium 運行基于 Web 的功能測試
- 用 Cobertura 訪(fǎng)問(wèn)代碼覆蓋率
- 用 CruiseControl 進(jìn)行持續測試
我提供一個(gè)關(guān)于不同類(lèi)型開(kāi)發(fā)人員測試的概覽，和一些可以添加到構建過(guò)程并使用 Continuous Integration 系統持續運行的例子。 按 JUnit 進(jìn)行單元測試 | 有人稱(chēng)之為單元測試，有人稱(chēng)之為組件測試
經(jīng)常提到的單元測試其實(shí)更像是一個(gè)組件級別的測試。組件測試通常驗證不止一個(gè)類(lèi)，并且依賴(lài)于一些東西，如數據庫或其他重量級系統，如文件系統。但是更重要的是，在測試的基礎上進(jìn)行測試，組件測試比單元測試運行時(shí)間更長(cháng)。 | | 有時(shí)，我聽(tīng)到開(kāi)發(fā)人員將開(kāi)發(fā)人員測試這一術(shù)語(yǔ)與簡(jiǎn)單的單元測試相混淆；然而，我發(fā)現將單元測試這一術(shù)語(yǔ)提練得更加明確很有幫助。對我來(lái)說(shuō)，單元測試是快速運行的 測試，通常測試沒(méi)有大的外部依賴(lài)項（如數據庫）的單獨的類(lèi)。例如，清單 1 定義了一個(gè)單元測試，該測試使用 JUnit 來(lái)驗證一個(gè)叫做 BeerDaoStub 的存根數據類(lèi)。針對并未真正連接到數據庫的接口的測試技術(shù)是一種驗證業(yè)務(wù)功能的方法，使用該方法不會(huì )導致花費昂貴的設置成本。另外，這樣做可使測試保持為一個(gè)真正的單元測試。
清單 1. 一個(gè)簡(jiǎn)單的單元測試
public void setUp() { beerService = new BeerDaoStub(); } public void testUnitGetBeer() { Collection beers = beerService.findAll(); assertTrue(beers != null && beers.size() > 0); } |
一旦編寫(xiě)了一些單元測試，就可以一直通過(guò) IDE 運行這些測試，但您也想要將這些測試作為構建過(guò)程的一部分來(lái)運行。確保該測試通過(guò)構建過(guò)程成功運行意味著(zhù)也能從 CI 構建的上下文中啟動(dòng)這些相同的測試。 清單 2 是一個(gè) Ant 腳本片段，介紹了執行一批單元測試的 junit 任務(wù)。這項任務(wù)與 JUnit 一起運作，其妙處在于：定義過(guò)的所有測試現在都能自動(dòng)運行并且如果其中任何一個(gè)測試失敗，則構建也將失敗 —— 通過(guò)使用 haltonfailure 屬性實(shí)現。
清單 2. 在 Ant 中運行單元測試
<junit fork="yes" haltonfailure="true" dir="${basedir}" printsummary="yes"> <classpath refid="test.class.path" /> <classpath refid="project.class.path"/> <formatter type="plain" usefile="true" /> <formatter type="xml" usefile="true" /> <batchtest fork="yes" todir="${logs.junit.dir}"> <fileset dir="${test.unit.dir}"> <patternset refid="test.sources.pattern"/> </fileset> </batchtest> </junit> |
注意：test.unit.dir 指定測試的位置。這是將這些測試（在本例中為單元測試）和其他測試隔離起來(lái)的有效方法。通過(guò)利用這項技術(shù)，可以通過(guò)定義另外的 Ant 目標來(lái)先運行較快的測試，接著(zhù)運行較慢的測試（如組件測試、功能測試和系統測試）。
集合組件測試 由于單元測試執行得相當快，很容易將它們作為構建的一部分經(jīng)常運行。但這些測試并未達到一個(gè)高的代碼覆蓋率 —— 其隔離的本質(zhì)決定了它們只測試一部分功能。編寫(xiě)具有更多代碼（從而可實(shí)現更多功能）的測試通常要以附屬框架的形式執行更多的調查工作。一旦開(kāi)始使用這些幫助框架來(lái)編寫(xiě)測試，這些測試就開(kāi)始成為更高級別的測試，我把它們歸類(lèi)為組件測試。 組件測試是基本的測試，這些測試將驗證不止一個(gè)類(lèi)，且通常依賴(lài)于外部依賴(lài)項，如數據庫。組件測試的編寫(xiě)方式和單元測試大體一致，只是前者并非通過(guò)模擬或存根類(lèi)來(lái)強制隔離，實(shí)現這些測試可謂勉為其難，但可以利用框架來(lái)便利對外部依賴(lài)項的使用。例如，我通常使用 DbUnit 框架來(lái)幫助管理數據庫，以便組件測試可驗證依賴(lài)數據庫數據的代碼功能。 用 DbUnit 控制數據庫狀態(tài) DbUnit 是一個(gè)框架，它使針對數據庫的測試過(guò)程變得更加簡(jiǎn)單。它提供了一個(gè)標準 XML 格式，用于定義一些測試數據，以便從數據庫中選擇、更新、插入和刪除數據。請牢記，DbUnit 并沒(méi)有替換數據庫；它只是提供了一種更加有效的機制來(lái)處理測試數據。您可以用 DbUnit 來(lái)編寫(xiě)依賴(lài)于特定數據的測試，DbUnit 保證該數據位于底層的數據庫中。 可以在 JUnit 中可編程地使用 DbUnit，或者可以將它作為構建過(guò)程的一部分使用。該框架帶有一個(gè) Ant 任務(wù)，該任務(wù)提供了一種使用 XML 文件來(lái)操作、導出或比較數據庫中數據的方法。例如，清單 3 演示了 dbunit 任務(wù)，在本文的例子中，該任務(wù)將測試數據插入到目標數據庫中，然后在運行完所有組件測試后刪除數據：
清單 3. 在 Ant 中運行組件測試
<target name="component-tests"> <mkdir dir="${logs.junit.dir}" /> <taskdef name="dbunit" classname="org.dbunit.ant.DbUnitTask"/> <dbunit driver="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/brewery" userid="${db.username.system}" classpathref="db.lib.path" password="${db.password.system}"> <operation type="INSERT" src="seedFile.xml"/> </dbunit> <junit fork="yes" haltonfailure="false" failureproperty="tests.failed" haltonerror="true" dir="${basedir}" printsummary="yes"> <classpath refid="test.class.path" /> <classpath refid="project.class.path"/> <formatter type="plain" usefile="true" /> <formatter type="xml" usefile="true" /> <batchtest fork="yes" todir="${logs.junit.dir}"> <fileset dir="${test.component.dir}"> <patternset refid="test.sources.pattern"/> </fileset> </batchtest> </junit> <mkdir dir="${reports.junit.dir}" /> <junitreport todir="${reports.junit.dir}"> <fileset dir="${logs.junit.dir}"> <include name="TEST-*.xml" /> <include name="TEST-*.txt" /> </fileset> <report format="frames" todir="${reports.junit.dir}" /> </junitreport> <dbunit driver="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/brewery" classpathref="db.lib.path" userid="${db.username.system}" password="${db.password.system}"> <operation type="DELETE" src="seedFile.xml"/> </dbunit> </target> |
正如清單 3 所示，現在組件測試可在執行期間依賴(lài)駐留在數據庫中的特定數據。另外，由于在所有測試成功執行后刪除了所有的數據，因而此過(guò)程現在可重復執行。 在數據庫中播種 可以將 dbunit 任務(wù)的 INSERT 和 DELETE 操作類(lèi)型和一個(gè)種子文件起使用，該文件包含表示數據庫表和相關(guān)行的 XML 元素。例如，清單 4 是清單 3 中引用的 seedFile.xml 文件的內容。每個(gè) BEER 元素表示一個(gè)也叫 BEER 的數據庫表，BEER 元素的每個(gè)屬性和其值都映射至相應的數據庫列名稱(chēng)和值。
清單 4. DbUnit 種子文件
<?xml version=‘1.0‘ encoding=‘UTF-8‘?> <dataset> <BEER id=‘6‘ beer_name=‘Guinness Extra Stout‘ brewer=‘St.James Brewery‘ date_received=‘2007-02-01‘ /> <BEER id=‘7‘ beer_name=‘Smuttynose Robust Porter‘ brewer=‘Smuttynose Brewery‘ date_received=‘2007-02-01‘ /> <BEER id=‘8‘ beer_name=‘Wolavers pale ale‘ brewer=‘Wolaver Brewery‘ date_received=‘2007-02-01‘ /> </dataset> |
您也許已經(jīng)從清單 3 中注意到，可以在不同的操作中重用 DbUnit 的種子文件。在本文的例子中，將在運行組件測試前使用清單 4 中的文件在數據庫中播種，然后使用相同的文件指示測試完成時(shí)從數據庫中刪除哪些數據。
參與性能測試 開(kāi)發(fā)人員完成編碼后，常常要經(jīng)過(guò)很長(cháng)時(shí)間才執行性能測試，而事實(shí)通常是可以在開(kāi)發(fā)周期中更早的時(shí)候發(fā)現（并且解決）性能問(wèn)題。幸運地是，有一種方法可解決此問(wèn)題：持續測試或更具體地、持續地運行 JUnitPerf 測試。 對性能測試來(lái)說(shuō) JUnitPerf 是完美的 JUnitPerf 是一個(gè)同 JUnit 協(xié)調工作的框架，該框架在一個(gè)預定的時(shí)間限制內執行測試用例：如果一個(gè)測試中的方法所用的時(shí)間比預期的閾值長(cháng)，則認為該測試是失敗的。通過(guò)將性能測試集成到自動(dòng)化構建中，您能有效地監控應用程序的性能甚至能在出現性能問(wèn)題時(shí)使構建失敗。 但我傾向于將 JUnitPerf 用作一種發(fā)現早期性能問(wèn)題的簡(jiǎn)單方法，而不是將其作為一種機制來(lái)衡量執行時(shí)間；像 profilers 這樣的工具更善于提供此類(lèi)衡量。在本質(zhì)上，可以認為 JUnitPerf 是一個(gè)早期的警告系統。 在清單 5 中，我定義了一個(gè) JUnit 測試，該測試使用 JUnitPef 來(lái)驗證 BeerServicePerformanceTest 測試類(lèi)中的 testLongRunningMethod 測試的執行時(shí)間。如果執行該測試方法所花的時(shí)間多于 1000 毫秒，則測試失敗。
清單 5. 使用 JUnitPerf 的基于性能的測試
package com.beer.business.service; import com.clarkware.junitperf.*; import junit.framework.Test; public class ExampleTimedTest { public static Test suite() { long maxElapsedTime = 1000; Test testCase = new BeerServicePerformanceTest("testLongRunningMethod"); Test timedTest = new TimedTest(testCase, maxElapsedTime); return timedTest; } public static void main(String[] args) { junit.textui.TestRunner.run(suite()); } } |
使用精確計時(shí)作為方法執行時(shí)間的標準時(shí)要小心；測試的建立和銷(xiāo)毀時(shí)間包含在整個(gè)執行時(shí)間中。此外，在早期的性能測試中，精確測定執行速度在更大程度上是一門(mén)藝術(shù)而不是科學(xué)。
使用 Selenium 進(jìn)行功能測試 可隨意編寫(xiě)所有需要的單元測試和組件測試，但如果要編寫(xiě)一個(gè)提供某種類(lèi)型的用戶(hù)界面的應用程序（例如 Web 應用程序），則需要測試表示層。以 Web 應用程序為例，需要驗證用戶(hù)場(chǎng)景的導航，另外還要驗證場(chǎng)景的功能是正常的。盡管如此，直到最近，這類(lèi)測試都常被證明是一個(gè)負擔，需要購買(mǎi)工具來(lái)促進(jìn)開(kāi)發(fā)周期晚期的測試。此外，這些工具幾乎不能適合構建過(guò)程，即使測試構建得足夠早也是如此。 深入 Selenium 但近幾年來(lái)，一些著(zhù)眼于功能測試的開(kāi)放源碼工具脫穎而出；而且，能輕易地在開(kāi)發(fā)生命周期的早期使用這些工具。工具如 Selenium 和 Watir 都是開(kāi)放源碼的；另外，它們構建時(shí)考慮到了開(kāi)發(fā)人員。除了用各種語(yǔ)言（例如 Java 編程和 Python）編程定義 Selenium 測試之外，Selenium 也提供了一種易于學(xué)習的表格驅動(dòng)格式，此格式也能被非技術(shù)類(lèi)型使用。 Selenium 框架使用 JavaScript 來(lái)執行基于 Web 的接受測試，該測試打開(kāi)一個(gè)瀏覽器并運行表格驅動(dòng)測試。例如，清單 6 展示了一個(gè)表示簡(jiǎn)單的 Selenium 測試的 HTML 表。該測試的多個(gè)步驟打開(kāi)一個(gè) Web 應用程序，然后使用有效的用戶(hù)名和密碼執行登錄。測試結果生成到一個(gè) HTML 表中，在 Selenium 運行完所有的測試后，能查看該表。
清單 6. 使用 Selenium 的功能測試
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>MyTest</title> </head> <body> <table cellpadding="1" cellspacing="1" border="1"> <thead> </thead><tbody> <tr> <td>open</td> <td>/beer/</td> <td></td> </tr> <tr> <td>type</td> <td>username</td> <td>admin</td> </tr> <tr> <td>type</td> <td>password</td> <td>password</td> </tr> <tr> <td>clickAndWait</td> <td>//input[@value=‘Login‘]</td> <td></td> </tr> <tr> <td>verifyTextPresent</td> <td>Logged in as admin</td> <td></td> </tr> </tbody></table> </body> </html> |
使用清單 6 中基于表格的格式，可以定義多個(gè)接受測試。也可以將測試分組成套，一次執行一整套測試。 使用 Ant 驅動(dòng) Selenium Selenium 的偉大之處在于它是在考慮了 CI 的基礎上從頭創(chuàng )建的，因為你能在像 Ant 那樣的構建工具中運行 Selenium。此外，由于框架設計者的高瞻遠矚，如果任何 Selenium 接受測試失敗，您也可以讓整個(gè)構建失敗。例如，清單 7 展示了一個(gè) Ant 任務(wù)，該任務(wù)使用 Selenium 遠程控制服務(wù)器在一個(gè) Web 應用程序中執行一系列表格驅動(dòng)測試：
清單 7. 使用 Ant 運行 Selenium
<?xml version="1.0" encoding="iso-8859-1"?> <project name="functional-tests" default="run-selenium-tests" basedir="."> <property file="${basedir}/selenium.properties"/> <import file="${basedir}/common-environment.xml"/> <property name="acceptance.test.lib.dir" value="${functional.test.dir}" /> <property name="firefox" value="*firefox" /> <property name="base.url" value="http://${web.host.name}:${web.port}" /> <property name="acceptance.test.list.dir" value="${functional.test.dir}" /> <property name="acceptance.test.report.dir" value="${functional.test.dir}" /> <target name="run-selenium-tests"> <mkdir dir="${reports.dir}" /> <java jar="${acceptance.test.lib.dir}/selenium-server.jar" fork="true"> <arg line="-htmlSuite "${firefox}""/> <arg line=""${base.url}""/> <arg line=""${acceptance.test.list.dir}/${test.suite}""/> <arg line=""${reports.dir}/index.html""/> <arg line="-timeout ${timeout}"/> </java> </target> <target name="stop-server"> <get taskname="selenium-shutdown" src="http://${web.host.name}: ${selenium.rc.port}/selenium-server/driver/?cmd=shutDown" dest="result.txt" ignoreerrors="true" /> <echo taskname="selenium-shutdown" message="Errors during shutdown are expected" /> </target> </project> |
執行 Selenium 測試時(shí)，當框架打開(kāi) Web 瀏覽器、閃電般執行測試，然后關(guān)閉該瀏覽器并生成 HTML 報告時(shí)，不要被嚇到。這是一種在開(kāi)發(fā)生命周期的早期更快更容易地發(fā)現問(wèn)題的方法（此時(shí)它們更易處理）。
使用 Cobertura 報告代碼覆蓋率 | 是否達到 100% 就是問(wèn)題所在
運行像 Cobertura 或者 Emma 這樣的工具時(shí)，記住以下方面很重要：在一個(gè)特殊的方法中實(shí)現 100% 的行覆蓋并不意味著(zhù)該方法沒(méi)有缺陷或者它已被完全測試。例如，如果您編寫(xiě)了一個(gè)針對 if 語(yǔ)句的測試，該測試包含邏輯 And，而測試針對的是表達式的左側部分，則像 Cobertura 這樣的工具將報告 100% 行覆蓋，但是實(shí)際上，您僅執行了該語(yǔ)句的 50%；因此僅完成了 50% 的分支覆蓋。 | | 現在已經(jīng)編寫(xiě)了一些測試，如何確定所有這些測試執行什么 呢？幸運的是，此問(wèn)題可由像 Cobertura 這樣的代碼覆蓋工具來(lái)解答。代碼覆蓋工具可報告測試覆蓋率 —— 以行覆蓋或分支覆蓋形式表示 —— 它表示測試運行時(shí)所涉及的代碼量。 清單 8 展示了一個(gè) Ant 腳本。該腳本使用 Cobertura 生成一份關(guān)于代碼覆蓋率的 HTML 報告，代碼覆蓋率通過(guò)運行一系列 JUnit 測試獲得：
清單 8. 使用 Ant 和 Cobertura 報告代碼覆蓋率
<target name="instrument-classes"> <mkdir dir="${instrumented.dir}" /> <delete file="cobertura.ser" /> <cobertura-instrument todir="${instrumented.dir}"> <ignore regex="org.apache.log4j.*" /> <fileset dir="${classes.dir}"> <include name="**/*.class" /> <exclude name="**/*Test.class" /> </fileset> </cobertura-instrument> </target> <target name="run-instrumented-tests" depends="instrument-classes"> <mkdir dir="${logs.junit.dir}" /> <junit fork="yes" haltonfailure="true" dir="${basedir}" printsummary="yes"> <sysproperty key="net.sourceforge.cobertura.datafile" file="cobertura.ser" /> <classpath location="${instrumented.dir}" /> <classpath location="${classes.dir}" /> <classpath refid="test.class.path" /> <classpath refid="project.class.path"/> <formatter type="plain" usefile="true" /> <formatter type="xml" usefile="true" /> <batchtest fork="yes" todir="${logs.junit.dir}"> <fileset dir="${test.component.dir}"> <patternset refid="test.sources.pattern"/> </fileset> </batchtest> </junit> </target> |
Cobertura 產(chǎn)生了一個(gè)如圖 1 中所示的 HTML 報告。請注意行覆蓋和分支覆蓋的百分比是以包計算的?？蓡螕裘恳粋€(gè)包，獲得類(lèi)級別的行百分比和路徑百分比，甚至能看到執行的源代碼行和它們執行的次數。
圖 1. 使用 Cobertura 和 Ant 生成 HTML 報告
| 需要多高的代碼覆蓋率?
理想情況下，您可能想針對每個(gè)路徑執行一次測試。也就是說(shuō)，如果整個(gè)代碼基址有 20,000 的循環(huán)復雜度的話(huà)，則需要 20,000 次測試。我從未遇到過(guò)具有 100% 的路徑覆蓋的項目，不過(guò)我曾見(jiàn)過(guò)具有近 100% 的行覆蓋的團隊。 | | 已經(jīng)介紹了多種類(lèi)型的測試，甚至介紹了如何測量這些測試的覆蓋率 —— 但是如何確保以正常的間隔執行 這些測試呢？恰好，這正是 CI 服務(wù)器（如 CruiseControl）大顯身手的地方，接下來(lái)對它進(jìn)行介紹。 持續運行測試 一旦將這些各式各樣的開(kāi)發(fā)人員測試類(lèi)型合并到一個(gè)構建過(guò)程中時(shí)，可以將這些測試中的一些（或者全部）作為 CI 過(guò)程的一部分運行。例如，清單 9 是 CruiseControl 的 config.xml 文件的一個(gè)片段，我在其中定義了一些東西。首先，我讓 CruiseControl 每?jì)煞昼姳O控一次 Subversion 庫中的改變。如果發(fā)現任何改變，則 CruiseControl 將啟動(dòng)一個(gè)叫做 build-${project.name}.xml 的委托 構建腳本（通常，此腳本用 Ant 編寫(xiě)）。該委托構建腳本調用項目的構建腳本，后者執行編譯并運行測試。 我也定義了一些邏輯，將所有不同類(lèi)型的測試結果合并到一個(gè) CruiseControl 日志文件中。而且，我還利用 CruiseControl 的功能將不同工具生成的報告鏈接（使用 artifactspublisher 標簽）到 Build Artifacts 鏈接中，Build Artifacts 可以從 CruiseControl 的顯示板應用程序中獲得。
清單 9. 使用 CruiseControl 的 CI
... <modificationset quietperiod="30"> <svn RepositoryLocation="http://your-domain.com/trunk/brewery" username="bfranklin" password="G0Fly@Kite"/> </modificationset> <schedule interval="120"> <ant anthome="apache-ant-1.6.5" buildfile="build-${project.name}.xml"/> </schedule> <log dir="logs/${project.name}"> <merge dir="projects/${project.name}/_reports/unit"/> <merge dir="projects/${project.name}/_reports/component"/> <merge dir="projects/${project.name}/_reports/performance"/> <merge dir="projects/${project.name}/_reports/functional"/> <merge dir="projects/${project.name}/_reports/coverage"/> </log> <publishers> <artifactspublisher dir="projects/${project.name}/_reports/" dest="projects/artifacts/${project.name}"/> </publishers> ... |
在將每個(gè)源變更應用到版本控制庫中時(shí)，不必運行每個(gè)定義的測試。例如，可以設置 CI 系統執行構建（通常稱(chēng)作提交構建），該構建只在代碼簽入時(shí)運行單元測試?？梢詾樘峤粯嫿ㄑa充一些更重量級的構建，例如像運行組件測試、功能測試、性能測試以及甚至執行代碼檢查的構建（請參閱 參考資料）。這些構建可以以更低的頻率運行（如一天一次）。您也可以選擇在提交構建之后立即運行這些測試和檢查。
調用所有測試 持續測試包括了廣度和頻度。通過(guò)授權執行不同類(lèi)型的測試，可獲得更大范圍的覆蓋和信任。此外，通過(guò)持續運行這些測試，幾乎能在問(wèn)題產(chǎn)生就發(fā)現它們。 僅僅進(jìn)行單元測試（至少我所定義的單元測試），并不能使你在項目上走得很遠。取得更高的代碼覆蓋率并且增加團隊的信心，需要通力合作并執行自動(dòng)化組件測試、性能測試和功能測試。此外，使用框架和像 JUnit、Selenium 以及 Cobertura 這樣的工具能輕松實(shí)現構建自動(dòng)化，這也意味著(zhù)在 CI 系統的幫助下，能夠在每次將變更提交到版本控制庫中時(shí)，有效地執行測試套件。這肯定是一種萬(wàn)無(wú)一失的提高平均成功率的方法，您不這么認為嗎？
參考資料 學(xué)習
- 您可以參閱本文在 developerWorks 全球站點(diǎn)上的 英文原文 。
- “用 Cobertura 測量測試覆蓋率”（Elliotte Rusty Harold，IBM developerWorks，2005 年 5 月）：Elliotte Rusty Harold 介紹了如何通過(guò) Cobertura 發(fā)現潛伏著(zhù) bug 的未測試代碼。
- “Effective Unit Testing with DbUnit”（Andrew Glover，OnJava，2004 年 1 月）：Andrew Glover 介紹了使用 DbUnit 的數據庫-依賴(lài)測試。
- “ 追求代碼質(zhì)量: 用 JUnitPerf 進(jìn)行性能測試”（Andrew Glover，IBM developerWorks，2006 年 11 月）：兩個(gè)監控可擴縮性和性能的簡(jiǎn)單測試。
- “選擇持續集成服務(wù)器”（Paul Duvall，IBM developerWorks，2006 年 9 月）：對開(kāi)源 CI 服務(wù)器：CruiseControl、Luntbuild 和 Continuum 的調查。
- 通過(guò)測試分類(lèi)實(shí)現敏捷構建（Andrew Glover，IBM developerWorks，2006 年 10 月）：Andrew Glover 揭示了三種確保端對端系統健壯性所需的測試，然后介紹如何按類(lèi)別自動(dòng)排序和運行測試。
- 可重復的系統測試 （Andrew Glover，IBM developerWorks，2006 年 9 月）：Andrew Glover 介紹了 Cargo，這是一個(gè)以通用方式自動(dòng)化容器管理的開(kāi)源框架，所以您每次都能編寫(xiě)邏輯上可重復的系統測試。
- “用 Selenium 自動(dòng)化驗收測試”（Christian Hellsten，IBM developerWorks，2005 年 12 月）：如何用 Selenium 測試工具對 Ruby on Rails 和 Ajax 應用程序進(jìn)行功能測試。
- “Continuous Integration”（Martin Fowler）：Fowler 關(guān)于持續集成實(shí)踐的基本文章。
- “JUnitPerf”（Mike Clark）：了解如何將 JUnitPerf 用于早期性能測試。
- 讓開(kāi)發(fā)自動(dòng)化 系列（Paul Duvall，IBM developerWorks）：探討實(shí)踐中對自動(dòng)化軟件開(kāi)發(fā)過(guò)程的使用，了解何時(shí)及如何成功地應用自動(dòng)化。
- 追求代碼質(zhì)量 （Andrew Glover，IBM developerWorks）：了解更多有關(guān)代碼規格、測試框架和編寫(xiě)高質(zhì)量代碼的信息。
- developerWorks Java 技術(shù)專(zhuān)區：數百篇關(guān)于 Java 編程各方面的文章。
獲得產(chǎn)品和技術(shù)
關(guān)于作者 | 
