持續集成與測試自動化

　　　　　　　　　　　　　　　　　　　　51CMM.COM原創 作者：黃良生
一、背景
　　我從畢業到現在, 曾在大小不同的三個公司就職: 有民營的、有外資的、也有上市公司。 但以前大多都是做項目，從事軟件開發工作，絕大部分公司對測試都不重視，即使有也沒有成規模， 更談不上建立測試體系�？傊�，重開發輕測試的管理思想在中國延續了幾十年、并且還要繼續，看看他們給測試工程師開的低工資和老師在課堂上講到測試時一筆帶過就知道測試被中國的老板所忽略。
最近兩年,我從事CRM軟件產品的測試、項目管理工作。 由于公司對軟件的質量要求特別高， 這必然引起了大家對測試工作的重視，不但要求有強大的測試團隊，該團隊必須具備在業務方面、測試技能方面的專業水平， 而且在軟件開發過程方面經常由于測試而作持續不斷地調整。
　　幸運的是，隨著軟件開發技術和工具的提高，軟件工程和軟件過程實踐的推廣， 軟件測試日益得到重視和專業化。 我從事測試工作期間，一直研究CMM、測試理論、自動化測試工具，并建立了一套完整的測試體系。
在此并不介紹整個測試體系，而是介紹測試方面最值得探討的部分：持續集成與測試自動化。目的是與大家共同進步。當然已經有很多關于持續集成和自動化測試方面的介紹,但我要介紹的不只是持續集成,也不只是自動化測試,而是測試如何的自動化.
二、測試自動化
　　自動化測試就是希望能夠通過自動化測試工具或其他手段，按照測試工程師的預定計劃進行自動的測試，目的是減輕手工測試的勞動量，從而達到提高軟件質量的目的。自動化測試的目的在于發現老缺陷。而手工測試的目的在于發現新缺陷。
測試自動化涉及到測試流程、測試體系、自動化化編譯、持續集成、自動發布測試系統以及自動化測試等方面整合。也就是說要讓測試能夠自動化，不僅是技術、工具的問題，更是一個公司和組織的文化問題。首先公司從資金、管理上支持您，其次要有專門的測試團隊去建立適合自動化測試的測試流程、測試體系；其次就是把原代碼從受控庫中取出、編譯、集成、發布可運行系統、進行自動化的單元測試和自動化的功能測試的過程。
（一）、自動化測試的好處
1、 對新版本執行回歸測試－－測試每個特征
對于產品型的軟件，每發布一個新的版本，其中大部分功能和界面都和上一個版本相似或完全相同，這部分功能特別適合于自動化測試， 從而可以讓測試達到測試每個特征的目的。
2、 更多更頻繁的測試－－沉悶、耗時
　　我們的產品向市場的發布周期是3個月，也就是我們的開發周期只有短短的3個月，而在測試期間是每天/每2天都要發布一個版本供測試人員測試，一個系統的功能點有幾千個上萬個，人工測試是非常的耗時和繁瑣，這樣必然會使測試效率低下。
3、替代手工測試的困難－－300個用戶有些非功能性方面的測試：壓力測試、并發測試、大數據量測試、崩潰性測試，用人來測試是不　　可能達到的。 在沒有引入自動化測試工具之前，為了測試并發，研發中心的一、兩百號人在研發經理的口令：1－、2－、3！， 大家同時按下同一個按鈕�；叵肫疬@中情景也蠻有意思的。
4、具有一致性和可重復性
　　由于每次自動化測試運行的腳本是相同的, 所以每次執行的測試具有一致性, 人是很難做到的. 由于自動化測試的一致性，很容易發現被測軟件的任何改變。
5、更好的利用資源－－周未/晚上
　　理想的自動化測試能夠按計劃完全自動的運行, 在開發人員和測試人員不可能實行三班倒的情況下, 自動化測試可以勝任這個任務, 完全可以在周末和晚上執行測試. 這樣充分的利用了公司的資源,也避免了開發和測試之間的等待.
6、解決測試與開發之間的矛盾
　　通常在開發的末期,進入集成測試階段, 由于每發布一個版本的初期,測試系統的錯誤比較少,這時開發人員有等待測試人員測試出錯誤的時間. 事實上在疊代周期很短的開發模式中，存在更多的矛盾， 但自動化測試可以解決其中的主要矛盾。
7、增加軟件信任度
　　總之，自動化測試的好處和收益是很明顯的，但也只有順利事實了自動化測試才能從中獲得它的益處。
(二)、 自動化測試－－ 誤區、限制自動化化測試好處很多，但也有很多的局限，也正因為很多老板對自動化測試的期望太高，所以有很多執行自動化測試失敗的例子。
1、 期望自動化測試能取代手工測試
不能期望自動化測試來取代手工測試， 測試主要還是要靠人工的。
2、期望自動測試發現大量新缺陷
同樣不能期望自動化測試去發現更多新的缺陷， 事實證明新缺陷越多，自動化測試失敗的幾率就越大。發現更多的新缺陷應該是手工測試的主要目的。測試專家James Bach總結得 85%的缺陷靠手工發現，而自動化測試只能發現15％的缺陷。
其實我認為自動化測試能夠很好的發現老缺陷。
3、工具本身不具有想象力
工具畢竟是工具，出現一些需要思考、體驗、界面美觀方面的測試，自動化測試工具無能為力。
4、技術問題、組織問題、腳本維護
自動化測試的推行，有很多阻力，比如組織是否重視， 是否成立這樣的測試團隊，是否有這樣的技術水平，對于測試腳本的維護工作量也挺大的，是否值得維護等等問題都必須考慮。
(三)、 不適合自動化測試情況
自動化測試不是適合所有的公司、所有的項目。
1、定制型項目（一次性的）
為客戶定制的項目，維護期由客戶方承擔的，甚至采用的開發語言、運行環境也是客戶特別要求的，即公司在這方面的測試積累就少，這樣的項目不適合作自動化化測試。
2、項目周期很短的項目
項目周期很短，測試周期很短，就不值得花精力去投資自動化測試，好不容易建立起的測試腳本，不能得到重復的利用是不現實的。
3、業務規則復雜的對象
業務規則復雜的對象，有很多的邏輯關系、運算關系，工具就很難測試。
4、美觀、聲音、易用性測試
人的感觀方面的：界面的美觀、聲音的體驗、易用性的測試，也只有人來測試
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進行功能測試時，則會失敗。因為自動化測試工具最基本的要求是：進入條件和出口條件必須在錄制與回放時完全相同。 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進行測試。
讓所有的重復的繁瑣的事情都完全自動化，并且要經常進行集成，讓重復的測試自動化。
四、測試套件實現測試流程.
當具備持續集成和測試自動化的能力后，需要一套測試體系來支持和維護您的測試流程，確保測試過程是符合流程、標準，而且是持續改進的。
（一）、為什么需要一個流程？很多公司投入了大量的測試經費，然而還是沒有收到預期的收益。這可能是因為：缺乏足夠的測試計劃、缺乏測試的優先次序、工作的重復、沒有利用工具來配合人工測試、沒有利用測試自動化工具、測試自動化運用不夠或者運用的不恰當等等。所以需要有測試套件的實施流程。
（二）、 為什么需要工具？
工具能夠加快測試的進度，可以把控制和管理引入整個測試過程，比如MI公司的TestDirector就是一個很好使用的測試管理系統，而且是web版的。測試管理系統有很多的作用：
測試管理和報告：測試管理系統能夠保證系統開發和測試流程你不的問題盡快得到解決。
審核跟蹤的憑據：TestDirector存貯了所有的測試結果，全部修改被寫進一個審核跟蹤器里，如：時間、日期、修改人、錯誤授權，能夠很清晰的看到把錯誤當皮球踢不負責人的整個過程。
提高測試覆蓋率：通過自動化測試工具的數據驅動來測試功能，可以提高測試覆蓋率。
（四）、測試套件--測試體系的主要目標(5W3H)
測試體系的建立是為了確保軟件測試的全部活動按計劃、按標準的進行，是測試人員的行動綱領和職責指導。也就是有這樣的一個體系、流程來指導他們的工作，培養了他們的主人翁責任感。讓測試工作開展得有條不紊。
主要的內容有：測試流程，測試方針、測試規程、文檔模版、質量標準、測試工具、測試技術和方法等內容。
測試體系的主要目標(5W3H)：目的是告訴與測試活動相關的人員在什么樣的時間，什么樣的地點，由誰來做，做什么樣的事情，為什么做，如何做，怎么樣才算完成，缺陷任何分析和預防等�？梢院喎Q：5W3H.
1、為什么要測試系統(Why) ？
測試新功能：每發布一個新的版本，首先要去測試它的新功能。創建回歸測試的測試套件驗證缺陷修改：在這個測試周期中要驗證上個測試周期的缺陷修改情況。驗證系統性能檢測新硬件
2、如何測試系統(How)？ 系統測試：檢查系統總體功能
壓力測試：在反復相同的操作下、或其他壓力條件下，比如：低內存空間/低磁盤空間等，檢測軟件的反應。
安裝測試：檢驗系統安裝得是否正確，而且與已安裝的軟件不發生沖突。
安全測試：測試系統存取權限和授權的級別
邊界測試：利用數據邊界和系統邊界檢驗程序
3、什么時候進行測試（When）？ 在開發流程的哪個階段開始測試?
在需求規格說明書一出來，或項目管理計劃一出來，測試人員就開始有事做：寫測試計劃、編寫測試用例、執行測試、測試報告和缺陷分析。很多老板以為要編碼結束后才開始測試工作，所以不肯有專職的測試人員，怕他們在項目前期沒有事做。
前提條件和附屬條件是什么?
多長時間需要進行一次測試?
交貨的時間表是什么?
什么時候停止測試? 什么時候停止測試是很有學問的，很多公司多半是在沒有時間、沒有資金是，老板或項目經理說了停止就停止。事實上根據bug預測、bug發現率與錯誤修正率的時間曲線來決定的。只有當這個曲線達到水平線后方才可以停止。4、誰來實施測試(Who) ？硬件：具備什么樣的服務器、客戶端及其網絡環境。
軟件：安裝什么樣的軟件環境最適合作這些測試。
體系架構：測試的類別有很多，不同的人進行不同的測試，比如開發人員做單元測試，測試人員作功能測試、集成測試、非功能性測試，而讓市場、需求人員、客戶去做驗收測試
數據：需要什么樣的測試數據來實施這一次的測試，這些測試數據的設計。
人力資源：按測試計劃的要求安排相關的人力資源。5、在哪里進行測試(Where) ？在開發服務器上測試？
開發人員可能會叫你在測試服務器上測試，事實上這樣對測試效率和測試人員的情緒影響是很大的，因為開發服務器是一個極不穩定的環境。而且也沒明顯的測試階段。
建立一個測試實驗室 ?
對于有很多項目的公司，建立一個測試實驗室是很必要的，主要用來做環境的兼容性測試，壓力、性能測試，驗收測試等等。
為了減輕測試者本地機器的負荷，使之在進行測試的同時可以做其他測試，
遠程定時執行測試的機制。6、測試什么(What) ？自動測試中應用程序的主要特點是什么?
按重要性將這些特點排序？
自動測試各部分的相對重要性?
總體質量目標是什么(可用性，功能，可靠性，性能等等)?
7、怎么樣才算完成(How)?
要定義測試的完成條件和完成標準, 以便達到這些條件和標準后應該立即停止測試,否則在經濟和時間上是不允許的,因為測試可以永遠下去.
8、缺陷如何分析和預防(How)?
測試過后應該對測試出的錯誤類別,錯誤特點作分析和提出預防措施,以便在將來的項目中有意識的去避免,這就是CMM5中說的缺陷預防.
五、自動化測試工具(WinRunner)
另外在此簡單的介紹一下自動化測試工具的原理。
1、 Winrunner基本原理－－錄制/回放功能
――錄制
錄制前的Add-in選擇：它對不同的語言開發了不同的Add-in
錄制前的參數設置
錄制方式選擇：
Context Sensitive
Analog
錄制技巧
保存錄制腳本和GUI
――調試
修改錄制好的腳本。
添加同步點和等待時間。
添加檢查點checkpiont。
修改GUI-MAP,提高可讀性、可維護性 。
回放的前提條件。
執行測試方式：
驗證方式：核對應用程序是否正確。
調試方式：增加新特征和功能
更新方式：用新版本應用程序中得到的運行結果更新期望結果。
分析結果。
2、 參數化數據驅動測試
特點：用相同測試腳本執行不同測試優點：提高測試覆蓋率
步驟：
1).轉換你的測試為數據驅動測試:datadriver
2).在數據表中增加數據
3).校正腳本使用正確的表達式
4).自定義結果信息 (tl_step)
3、 運用WinRunner的風險
產品性的軟件，會有很多自己開發的組件、控件或引入新的技術如xml,htc等，這有可能使得自動化測試工具不認識，導致整個自動化測試失敗，已往積累的測試腳本將全部廢棄。

總之，由于商業社會對軟件的質量要求越來越高，軟件開發過程的持續改進，軟件項目的持續集成與測試自動化的發展是必然的，其作用也將越來越明顯。不同的技術和開發環境對測試如何自動化有不同的要求，還有很多值得研究的地方。