持續集成與測試自動化(2)

　　5、測試很少運行：一個月只運行一次

　　測試很少運行，對自動化測試就是一種浪費。自動化測試就是讓它不厭其煩的、反反復復的運行才有效率。

　　6、軟件不穩定

　　軟件不穩定，則會由于這些不穩定因素導致自動化測試失敗。只有當軟件達到相對的穩定，沒有界面性嚴重錯誤和中斷錯誤才能開始自動化測試。

　　7、涉及物理交互

　　工具很難完成與物理設備的交互，比如刷卡的測試等。

　　(四)、什么樣的情況適合自動化測試自動化測試之所以能在很多大公司實施起來，就是有它適合自動化測試的特點和高的投資回報率。

　　1、產品型項目

　　產品型的項目，每個項目只改進少量的功能，但每個項目必須反反復復的測試那些沒有改動過的功能。這部分測試完全可以讓自動化測試來承擔， 同時可以把新加入的功能的測試也慢慢地加入到自動化測試當中。

　　2、增量式開發、持續集成項目

　　由于這種開發模式是頻繁的發布新版本進行測試，也就需要自動化測試來頻繁的測試，以便把人從中解脫出來測試新的功能。

　　3、能夠自動編譯、自動發布的系統

　　要能夠完全實現自動化測試，必須能夠具有自動化編譯，自動化發布系統進行測試的功能。 當然，不能達到這個要求也可以在手工干預下進行自動化測試。

　　4、回歸測試

　　回歸測試試自動化測試的強項，它能夠很好的確保你是否引入了新的缺陷，老的缺陷是否修改過來了。在某種程度上可以把自動化測試工具叫做回歸測試工具。

　　5、多次重復、機械性動作

　　自動化測試最喜歡測試：多次重復、機械性動作，這樣的測試對它來說從不會失敗。比如要向系統輸入大量的相似數據來測試壓力和報表。

　　6、需要頻繁運行測試

　　在一個項目中需要頻繁的運行測試，測試周期按天算，就能最大限度的利用測試腳本，提高工作效率。

　　7、將煩瑣的任務轉化為自動化測試

　　三、持續集成及其自動化編譯

　　"持續集成(Continuous Integration)"的概念來自于XP(極限編程)的一個實踐, 我們的開發模式是建立在CMM的基礎之上,引入了某些XP的概念，所以我們的思想是取各方面的精華來適合自己。

　　持續集成是指能夠自動的集成已經提交(Check-in)的代碼，直至發布到測試服務器供測試的整個過程。

　　1、實現自動化日構建需要做以下幾部分的工作：

　　2、將所有的源代碼保存在單一的開發服務器，讓所有人都能從這里獲取最新的源代碼(需要用配置管理工具存放源代碼: 如VSS/CVS/ClearCase)。

　　3、使創建過程完全自動化，讓任何人都可以只輸入一條命令就完成系統的創建。

　　4、使測試完全自動化，讓任何人都可以只輸入一條命令就運行一套完整的系統測試。

　　5、確保所有人都可以得到最新、最好的可執行文件。

　　6、自動化編譯： 為了能夠提供自動化測試，所以所有的代碼必須能夠實現自動化編譯。其實很多在做持續集成的公司都實現了改功能：如java程序可以采用在Ant + Junit 的基礎之上添加自己的功能既可以實現持續集成―――我們把這個工具叫：日構建

　　但很多公司并沒有實現對JSP的自動編譯，對于采用jsp編寫的web頁面，它是編譯執行語言，由于第一次執行要先編譯，即第一次的速度稍慢，如果要采用自動化測試工具winrunner進行功能測試時，則會失敗。因為自動化測試工具最基本的要求是：

　　1、進入條件和出口條件必須在錄制與回放時完全相同。

　　2、持續集成最的好處：

　　完全可以取代人工的發布， 在J2EE中有個角色叫deployer., 它的主要工作就是經常發布新的系統供開發、測試，一般每發布一次至少要一個小時，如遇到一些問題一個上午就耗費掉了， 但使用“日構建”后就可以完全實現自動化，時間幾乎只等于編譯時間。

　　它完全避免了開發者們的"除蟲會議"--以前開發者們經常需要開這樣的會，因為某個人在工作的時候踩進了別人的領域、影響了別人的代碼，而被影響的人還不知道發生了什么，于是bug就出現了。

　　這樣的bug絕大多數都可以在引入的同一天就被發現。由于一天之中發生變動的部分并不多，所以可以很快找到出錯的位置。

　　持續集成可以把發現的錯誤根據源代碼的作者，以郵件和日志的方式分發給作者，第二天一上班的第一件事就是先修改錯誤。

　　持續集成可以減少集成階段"捉蟲"消耗的時間、 頻繁發布新版本的時間，從而最終提高生產力和軟件質量。

　　3、理想的持續集成的實現方法：

　　A)、同一個軟件產品要有集中的同一臺開發服務器，即所有人的最新的、各自編譯通過的源代碼都在配置管理工具如VSS中。

　　B)、有一臺運行主創建的機器，有計劃的運行日構建, 日構建中有一個創建進程，該創建進程是在一個隨時保持運行的Java類中進行的，如果沒有創建任務，創建進程就一直循環等待。

　　C)、守護進程將全部代碼(包括原程序和配置文件，數據庫腳本等)提取到創建機器的一個目錄中。提取完成之后，守護進程就會在這個目錄里調用Ant腳本。

　　D)、Ant會接管整個創建過程，對所有源代碼做一次完整的創建。Ant腳本會負責整個編譯過程，并把得到的class文件放進六個jar包里，發布到EJB服務器上。

　　創建結束之后，創建守護進程會給所有向最新一次創建歸還了代碼的開發者發一個e-mail，匯報創建的情況。

　　E)、當Ant完成了編譯和發布的工作之后，創建守護進程就會在EJB服務器上開始運行新的jar，同時開始運行BVT測試套件：即利用Junit進行單元測試。

　　單元測試完成后，日構建會把單元測試報告發給有錯誤的開發人員。

　　F)、為了利用自動化工具(WINRUNNER)進行功能測試，必須對JSP編譯，利用jspc命令進行包裝一層，就可以自動的對所有的jsp文件進行編譯， 但由于編譯jsp的時間非常長(越比編譯java代碼時間長)，所以一般利用單獨的編譯服務器進行編譯。 發布編譯好的jsp文件進行自動化測試的成功率高(因為第一次運行jsp文件非常慢，而自動化測試最忌諱運行時和錄制時等待得時間不一樣)。 而功能性自動化測試也需要按計劃有順序的執行，這需要TestDirector測試管理系統來調度Winrunner進行測試。

原文轉自：http://www.kjueaiud.com