1、引言
軟件測試是關係到軟件開發和維護成本的重要環節。任何軟件產品在正式發佈之前都必須經過嚴格的測試。隨着計算機技術的迅速發展,軟件的結構越來越複雜,同業競爭越來越激烈。爲了保證軟件產品的高度可靠性和競爭力,很多軟件開發機構都將其主要的研製力量投入到軟件測試之中。
迴歸測試是軟件測試中的重要組成部分,佔有很大的比重。每次例行包發佈前都需要對軟件現有功能進行迴歸驗證，確保無誤以後才能發給各地現場，大家都知道電信業是個發展較快的行業，需求變更快、迭代週期短，從而導致迴歸測試十分頻繁，這個時候如果單靠手工進行測試，會消耗大量的時間和精力，測試人員也隨着耐心的減退而力不從心。爲了避免這種情況，對於原有功能的自動化測試顯得尤爲重要。
2、工具介紹
說到開源自動化測試工具，網上衆說風雲，但別人說好的東西不一定適合你，我們在組合自動化測試工具時，根據自己的實際情況選擇了 Selenium + TestNG + DBUnit組合，我先介紹一下這幾種工具。
Selenium，它所採用的原理是通過錄制應用程序產生的線性腳本進行回放從而達到自動化測試的目的。其優點是簡單，通過錄制就可以得到所需腳本。類似於錄製/回放測試工具有很多，我之所以選擇它的原因是它是開源的，而且它測試直接在瀏覽器中運行，就像真實用戶所做的一樣。Selenium測試可以在 Windows、Linux上的 Internet Explorer、Mozilla和 Firefox 中運行。其他測試工具都不能覆蓋如此多的平臺，更重要的是Selenium支持多種語言、JAVA、Ruby、Python等(如圖1)
圖1
支持這麼多語言說明我們通過Selenium開發的測試腳本可以任意移植到多個平臺，可以繼承Selenium API來擴展一些我們自己的測試類，甚至可以在此基礎上開發出一套屬於我們自己的自動化測試平臺，而其它工具，包括大名鼎鼎的QTP，SilkTest是有所不及的，雖然這些收費的軟件後面有強大的技術支持，學習文檔和參考資料也相當豐富，但這些工具的侷限性太大，一旦使用這些工具，你就會越來越依賴人家的東西，從而無法沉澱出自己的技術，這是我選擇Selenium的根本原因。
Selenium 系列一共有4款工具
Selenium Core：支持DHTML的測試案例（效果類似數據驅動測試），它是Selenium IDE和Selenium RC的引擎。
Selenium IDE：FireFox的一個插件，支持腳本錄製。
Selenium RC：Selenium Remote Control。
Selenium Grid：允許同時並行地、在不同的環境上運行多個測試任務，極大地加快Web應用的功能測試。
通過selenium編寫測試case的理想化是先通過Selenium IDE錄製腳本，通過Firebug輔助定位頁面元素，然後通過Selenium RC來完善測試腳本。Selenium IDE是Firefox的一個插件，是可以進行腳本錄製以及案例轉換，所以Selenium IDE+Firebug會成爲你日後寫測試案例的兩大助手，但遺憾的是上述兩個工具都依賴Firefox瀏覽器,如果你的程序不支持Firefox瀏覽器，就只能通過手工編碼來完成自動化測試腳本，對於初學者來講，如果沒有這兩個工具的輔助，在編寫測試腳本時還是比較困難的，但熟悉了Selenium API和掌握了頁面元素查找的方法以後，這兩個工具就顯得沒那麼重要了。
TestNG，單元測試工具典型代表，可能大部分開發人員只對JUnit比較熟悉，JUnit是 Java 語言單元測試當前的一站式解決方案。這個框架值得稱讚，因爲它把測試驅動的開發思想介紹給 Java開發人員並教給他們如何有效地編寫單元測試。但是，在過去的幾年中，JUnit的改進不大；所以，爲當今複雜的環境編寫測試已經變成一個越來越困難的任務，即 JUnit必須與其他一些補充性測試框架集成起來。而 TestNG是一個測試 Java應用程序的新框架。我選擇TestNG是因爲它是一種基於註釋的測試框架，通過添加諸如靈活的裝置、測試分類、參數測試和依賴方法等特性來克服JUnit的一些不足之處。此外，TestNG運行於Java 5.0（通過註釋）和Java 1.4（通過JavaDoc樣式的註釋）之上。我來列舉一下NG的優勢：
關鍵字：參數化。TestNG將數據驅動的自動化測試的概念詮釋的淋漓盡致，我舉個例子，一個被測試方法根據不同的入參組合出20個CASE,根據數據驅動測試的思想，我們只需要寫一個測試方法，然後準備20種參數組合的數據。如果使用JUnit你可能需要寫20個測試方法，而TestNG通過註釋就可以實現參數化。將20種不同的入參組合整理到一個Excel文件中管理，文件裏可以增加用例描述甚至測試方案等相關信息，如果增加新CASE，只需要增加一行測試數據即可，如圖：
測試方法只需要寫一個，如圖所示：
關鍵字：失敗和重運行，在大型測試套件中，這種重新運行失敗測試的能力顯得尤爲方便。這是TestNG獨有的一個特性。在 JUnit 4中，如果測試套件包括 1000項測試，其中 3項失敗，很可能就會迫使您重新運行整個測試套件（修改錯誤以後）。不用說，這樣的工作可能會耗費幾個小時。一旦 TestNG中出現失敗，它就會創建一個 XML配置文件(如圖4)，對失敗的測試加以說明。如果利用這個文件執行 TestNG運行程序，TestNG就只運行失敗的測試。所以，1000項測試有3項 Failed，這種場景你只需重新運行三個失敗的測試腳本，而不是整個測試套件。
這裏只列舉了TestNG比較明顯的優勢，除了上述優勢以外還有很多，這裏就不詳細闡述。
圖4
DBUnit，它通過有效地管理測試場景中的數據簡化了使用數據庫的工作。其設計理念就是在測試之前，備份數據庫，然後給對象數據庫植入我們需要的準備數據，最後，在測試完畢後，讀入備份數據庫，回溯到測試前的狀態，通過DBUnit還可以輔助數據持久層的測試工作，如驗證一個實體通過被測試程序(DAO)進行持久化的操作是否正確，驗證數據實體是否按照預期寫入數據庫，並且提供了將數據從數據庫與XML文件存儲中互相轉換的功能。
上圖是從客戶表中導出的一條數據，如果測試過程中需要這條數據，那可以通過DBUnit將此條數據初始化到數據庫中。
還有一種情況，如果是新增一個客戶，那這個文件裏的數據可以用來做斷言預期的依據，DBUnit可以將xml轉換爲DataSet甚至 JavaBean，你可以直接通過數據集進行比較而不是每個字段都要比較一次。
不過DBUnit也有自己的缺陷，如上圖所示，當通過DBUnit與數據庫交互時需要檢查表的主鍵，如果某張表沒有設置主鍵就沒有辦法使用DBUnit的API，只能通過其它方式實現。
Fitnesse，業務驅動測試的工具代表，FIT是一種通用的開放框架，將測試人員編寫的測試方法轉換成表格的形式展現給客戶，常用於自動化驗收測試，在頁面上以表格形式記錄測試用例輸入、預期輸出內容，自動運行並顯示測試執行結果。但是增加了開發人員一些工作量，要想讓fit與你的軟件通信，需要自己編寫Fit fixture來實現業務與程序邏輯的轉換。
3、自動化測試實施過程
通過上面幾種工具的組合，靈活使用，就可以搭建出一套適合自己的自動化測試平臺。
下面我來介紹一下，這些工具在不同測試場景下的使用情況：
1、 接口測試
（TestNG+DBUnit）接口自動化測試可以通過單元測試來完成，利用TestNG對每一個接口編寫單元測試代碼，通過DBUnit初始化數據庫，將一個或多個測試並被定義爲<suite>標籤，批量執行測試代碼並生成測試報告。
2、Webservice接口自動化測試
目前大多數互聯網公司都採用SOA架構，因此對於webservice接口類型的測試顯得更加重要。通常測試工程師可能會藉助SoapUI等工具進行web service的測試，不可否認SoapUI在進行單一webservice接口測試中具有非常好的效果，但是在接口組合測試，以及在測試結果需要進行數據庫校驗的情況下就顯得不是那麼的自動化，總是需要人工干預，這在一定程度上導致測試效率偏低，因此我們在這裏介紹如何使用Fitnesse這塊開源產品實現接口測試自動化(未完待有時間補充)
3、WEB應用系統的自動化(Selenium + TestNG + DBUnit)
TestNG 尤其適合與Selenium結合使用，可以實現其他測試框架無法實現的測試，例如使用依賴項進行測試，重新運行失敗了的測試，以及使用單獨文件中定義的參數進行參數化測試。所有這些特性結合在一起，使它在衆多 Web應用程序測試框架中脫穎而出。
在測試自動化中，測試代碼不僅僅包含測試邏輯，還包含許多其他的代碼，比如URL拼接、Html/xml解析、訪問UI控件，等等。若把測試邏輯與這些無關的代碼混在一起，測試邏輯將很難理解，也不容易維護。而採用分層結構可以解決這一問題。在分層的測試框架中，其三層結構爲：
1）數據層，包含UI數據和測試數據；UI數據是指在頁面中需要輸入的數據，如，普通客戶新裝，你需要在頁面裏輸入三戶信息，包括訂購的產品及資源數據。這些通過頁面注入的數據我們統稱爲UI數據，需要在執行測試前提前整理到Excel中，如圖所示：
實現起來比較容易，使用TestNG註釋功能，就可以將這些數據作爲頁面的輸入。而測試數據是指數據庫中基礎數據，這些數據是用來支撐整個系統運作的，比如操作員及組織權限，新裝訂購的套餐，套餐與產品的關係數據等等，沒有這些數據，系統就沒有辦法正常運行，所以執行測試腳本之前要對這些基礎數據進行初始化；還有一種情況當執行完一次測試腳本時產生的新數據會影響測試腳本的二次運行，這意味着運行任何測試之前，都希望數據庫具有一組乾淨的數據，使用 DBUnit 的CLEAN_INSERT 命令確保在先前運行的測試中創建的行被刪除掉，因此我可以重新運行測試，該測試可以不斷創建數據並且不用考慮數據庫約束。將測試數據提前整理到xml文件，也可以從數據庫直接導出到xml文件裏，如圖所示：
在執行測試腳本前，通過DBUnit將這些文件裏的數據提前初始到數據庫裏，這樣一來數據庫就是程序所期望的樣子。
2）測試用例層，包含業務邏輯和控制邏輯。驅動程序WebDriver(Selenium2.0)負責UI數據的載入，在頁面回放時將UI數據輸入到頁面中。前臺頁面回放完成後，數據進入持久階段，這時需要比對後臺業務處理邏輯，比如客戶數據是否正確寫入數據庫，產品訂購是否正確。由於輸入的不同，場景的不同，業務邏輯比對也會不同，所以這塊腳本的編寫是整個環節中比較重要的部分。爲了能夠區分這些分支，需要將整個新裝流程拆分多個模塊進行管理，使用TestNG將測試用例分組，形成多個Test Suite進行控制。
3）待測系統層，與測試端完全分離，被測系統只需要提供URL通過HTTP協議就可以被測試腳本調用執行。
4、自動化測試的持續集成
持續集成是一種軟件開發實踐，對於提高軟件開發效率並保障軟件開發質量提供了理論基礎，持續集成保障了每個時間點上團隊成員提交的代碼是能成功集成的。換言之，任何時間點都能第一時間發現軟件的集成問題，也能儘快將測試腳本投入生產使用。
通過SVN統一代碼管理，在Ant或Maven腳本增加測試組件配置，當例行編譯結束後即可以使用Hudson定時啓動測試腳本的運行工作。運行結束後返回測試報告給測試人員。整個迭代週期如下圖所示：
5、結語
軟件自動化測試彌補了手工測試時重複勞動的缺陷，而且能在軟件開發過程中儘早發現缺陷，因此實施自動化測試是非常有必要的。本文中介紹了幾種自動化測試工具，通過不同的工具組合成適用自己的自動化測試框架，不僅使自動化測試在產品測試中發揮其獨特的作用，而且還節約了資源成本，包括測試工具購買的成本以及人力資源成本等。
轉自：http://blog.csdn.net/congqing2011/article/details/7788754