基于持續集成的冒煙測試

姜 文，劉立康

(西安電子科技大學 通信工程學院，陜西 西安 710071)

0 引 言

隨著軟件敏捷開發與測試驅動開發理念的不斷普及與發展，持續集成[1-6]在軟件產品開發過程中的地位越來越重要。為了保證及時發現每天合入配置庫的代碼質量，使用持續集成工具開展每日集成構建工作，進行源代碼更新、基礎靜態檢查、軟件產品模塊編譯、軟件版本包出包以及產品版本包的自動化測試。版本包的自動化測試就是通常所講的“冒煙測試”。

冒煙測試是一種測試策略，是對集成構建生成的版本包進行測試驗證，同時也是進一步開展全面深入測試的預測試。開展冒煙測試工作有助于盡早發現軟件代碼存在的問題，提高軟件代碼的質量和開發效率。基于持續集成的冒煙測試采用自動化測試腳本進行測試工作，能夠提高測試效率，減少測試人員大量的重復測試驗證工作。

文中介紹了冒煙測試、門檻用例；敘述了基于持續集成的冒煙測試的特點、冒煙測試涉及到的角色和軟件測試自動化工廠；詳細敘述了冒煙測試運行的系統架構和運行流程。最后介紹了一個冒煙測試的工作案例進行說明。

1 冒煙測試的特點

1.1 冒煙測試

冒煙測試[7-13]是在軟件開發過程中的一種針對軟件版本包的快速基本功能驗證策略，是對軟件基本功能進行確認驗證的手段，并非對軟件版本包的深入測試。冒煙測試也是針對軟件版本包進行詳細測試之前的預測試，執行冒煙測試的主要目的是快速驗證軟件基本功能是否有缺陷。如果冒煙測試的測試例不能通過，則不必做進一步的測試。進行冒煙測試之前需要確定冒煙測試的用例集，對用例集要求覆蓋軟件的基本功能。這種版本包出包之后的驗證方法通常稱為軟件版本包的門檻用例驗證。

冒煙測試屬于HLT(high level test)測試，HLT通常指SDV(系統設計驗證)/SIT(系統集成測試)/SVT(系統驗證測試)等測試活動。HLT是站在系統的角度對整個版本進行測試，測試對象是一個完整的產品而不是產品內部的模塊，常見的HLT測試包括系統測試和驗收測試。

冒煙測試可以手動執行，也可以自動化執行。穩定的系統適合自動化冒煙測試，集成過程中的系統適合手工冒煙測試，因為冒煙測試內容在動態變化，變化中的自動化腳本維護工作量比較大。

1.2 門檻用例

門檻用例測試，首先需要確定一個測試用例集作為門檻用例集，對軟件版本包進行舊包卸載、新包部署，采用門檻用例集中的測試用例開展基本功能點的測試驗證工作。軟件版本包只有通過門檻用例測試才可以進行下一步開發或者測試工作。反之如果門檻用例測試有執行失敗的用例，需要這個測試用例集的執行責任人第一時間進行用例失敗分析，如果不是環境原因與腳本原因導致的用例失敗，則需要相關模塊的開發人員對問題進行定位，解決之后重新進行測試驗證，直到通過為止。門檻用例測試流程如圖1所示。

1.3 基于持續集成冒煙測試的特點

持續集成工具搭建的構建工程可以每天通過制定定時任務來自動完成從版本庫更新代碼、靜態檢查、編譯、出包、自動化用例測試等任務。持續集成中的自動化用例測試就是通常所說的冒煙測試。冒煙測試是通過自動化工廠執行自動化腳本來完成測試任務。可以分為兩種情形：

(1)每日構建生成增量版本包基線，冒煙測試主要是驗證新增的軟件代碼是否影響前一天軟件版本的基本功能，特別是對原有軟件代碼的修改。

(2)集成構建進行全量編譯，生成轉測試版本包基線，通常一周進行一次。冒煙測試除了驗證以前版本包的基本功能外，也為新增功能測試進行了預測試。通過對新增功能測試完成后，可以向自動化工廠提交新的自動化腳本，從而增加自動化測試用例數量。

圖1 門檻用例測試運行流程

2 冒煙測試涉及到的角色

冒煙測試在測試環境搭建與執行過程中，涉及到的人員包括：測試架構師、管理自動化工廠的測試工程師、開發工程師、持續集成工程師、質量工程師。在冒煙測試環境搭建與執行過程中，以上各角色各司其職，分工協作共同確保冒煙測試正常執行，保證軟件測試版本包能夠通過基本功能驗證，確保每天都有可用的基線版本提供給開發工程師和測試工程師。

2.1 測試架構師

測試架構師(TSE)根據產品目前所有的特性，經過對各特性測試用例的分析，提供冒煙測試的測試用例集。測試用例集的要求是覆蓋目前產品所有特性的基本功能，并隨著產品迭代開發進度，不斷對測試用例集中所包含的測試用例進行調整，確保冒煙測試用例集不斷覆蓋新開發的特性。關注軟件代碼覆蓋率質量指標，覆蓋率質量指標達不到要求，需要查找原因，適時增加門檻用例數量。冒煙測試失敗，參與分析定位處理，關注測試用例設計中存在的各種問題。

2.2 測試工程師

測試工程師根據冒煙測試用例集中的測試用例編寫與調試自動化腳本，將腳本合入自動化工廠。冒煙測試失敗，參與分析定位處理，重點關注自動化腳本的問題。

2.3 開發工程師

當出現冒煙測試執行失敗的情況時，管理自動化工廠的測試工程師進行腳本失敗原因分析之后，排除了測試環境與環境配置的原因，就需要開發工程師根據問題現象和收集到的日志文件對失敗的情況進行分析定位。如果定位結論是軟件代碼缺陷導致的冒煙測試失敗，需要管理自動化工廠的測試工程師在缺陷管理系統提交問題單，開發工程師通過修改軟件代碼并將源代碼合入版本庫。對于一些復雜的問題需要軟件系統架構師參與定位處理。

2.4 持續集成工程師

持續集成工程師從版本庫更新源代碼，搭建集成構建工程；進行靜態檢查、軟件產品模塊編譯、軟件版本包出包；向自動化工廠提交冒煙測試任務。根據自動化工廠的測試結果，通過郵件將信息反饋給相關人員。冒煙測試失敗，從各個環節查找失敗的原因，參與問題的分析定位處理。對接公司質量部門度量頁面，使軟件產品每天都有冒煙測試的相關數據能夠呈現到公司質量部門度量頁面。

2.5 管理自動化工廠的測試工程師

該測試工程師負責自動化工廠管理、運行和維護。自動化工廠收到冒煙測試任務后，需要完成軟件版本包的安裝和冒煙測試環境搭建；自動化腳本的部署；調度執行冒煙測試。完成冒煙測試任務后，將測試結果提交給持續集成工程師。當冒煙測試失敗時，該測試工程師需要查明哪些測試腳本失敗，參與腳本失敗原因分析定位，需要特別關注測試環境的搭建和自動化腳本的部署。

2.6 質量工程師

質量工程師(RQA)需要定期根據公司質量部門對軟件產品冒煙測試相關度量指標[14]進行審計，關注度量指標主要有測試成功率、執行自動化測試步驟的時間、自動化測試用例數目、成功的用例數、運行阻塞用例數、運行失敗用例數；同時關注在開發階段這些質量指標的變化。通過軟件代碼覆蓋率質量指標監測門檻用例數量變化。

圖2為應用軟件冒煙測試用例圖。

圖2 軟件冒煙測試角色用例圖

3 軟件測試自動化工廠

隨著軟件版本迭代開發的進度，自動化測試用例與腳本的數量將不斷增加，測試環境日趨復雜。自動化測試用例與腳本、測試環境需要由專職的測試工程師對自動化工廠[15-16]進行管理和維護。

以某個大型企業的軟件自動化工廠為例敘述自動化工廠的組成。該自動化工廠由四個功能模塊組成：測試任務執行控制中心(test integration control center，TICC)、測試資源管理中心(lab configuration manager，LCM)、自動化測試執行平臺(test execution platform，TEP)、測試信息管理中心(test management service system，TMSS)。自動化工廠通常管理運行多個軟件項目的自動化測試。

3.1 測試任務執行控制中心(TICC)

TICC負責測試任務執行的調度和申請測試環境資源；相關測試信息的接收和傳遞。

3.2 測試資源管理中心(LCM)

LCM是實驗環境配置信息的統一管理平臺，可實現環境錄入、查詢、修改、環境信息保存。負責所有測試資源的整合、歸并與統一管理，為TICC的測試任務分配相關的測試資源。通常創建新版本的門檻用例測試集時，需要在LCM進行測試環境配置與統一管理。進行門檻用例測試需要在LCM上分配專用測試環境。

3.3 自動化測試執行平臺(TEP)

TICC通過TiccAgent工具控制自動化測試任務的下發，TEP負責執行從TICC下發的自動化測試任務，執行任務的PC上安裝自動化測試工具，執行門檻用例自動化腳本，腳本的語言為TCL。

3.4 測試信息管理中心(TMSS)

TMSS負責測試用例、自動化測試腳本以及測試任務相關信息的管理；測試執行結果和測試執行時長等測試執行過程中產生的中間信息都會被該系統自動記錄。門檻測試用例集需要在TMSS上創建一個以版本號_CI的測試用例集和測試用例自動化腳本集。測試人員可以在TMSS上創建測試任務，下發到TICC，進行自動化測試腳本的測試工作。

4 基于持續集成的冒煙測試

采用持續集成工具ICP-CI搭建集成構建工程，通過該自動化工廠開展軟件版本包的冒煙測試。基于持續集成的冒煙測試通常由以下幾部分組成：制定門檻測試用例集；門檻用例自動化腳本編寫與入廠；門檻用例測試環境搭建；集成構建工程任務管理頁面配置冒煙測試任務；冒煙測試任務執行。

冒煙測試運行的系統架構如圖3所示。

圖3 基于持續集成的冒煙測試系統架構

4.1 制定門檻測試用例集

在軟件開發過程中，測試架構師根據目前軟件產品的各特性與功能模塊確定門檻測試用例集，經過評審之后，這些用例由測試架構師導入TMSS下以版本號_CI命名的測試用例集中，并根據軟件開發的情況不斷調整該測試用例集中的測試用例。

4.2 門檻用例自動化腳本編寫與入廠

門檻用例集確定之后，測試工程師完成門檻用例腳本的編寫與調試。測試架構師進行腳本評審，腳本評審通過后，測試工程師通過配置管理工具Git將門檻用例腳本合入配置庫，管理自動化工廠的測試工程師將腳本從配置庫中導入到TMSS下以版本號_CI命名的測試用例腳本集，和測試用例集中的測試用例一一對應。

4.3 門檻用例測試環境搭建

管理自動化工廠的測試工程師編寫與調試卸載舊版本包、安裝新版本包與環境配置的腳本，搭建與配置測試環境。測試包括執行PC、產品軟件環境。對于云環境，虛擬PC機通過VMware軟件來制作，通常制作虛擬機的鏡像文件，操作系統是Windows 2003 Server。虛擬機的規格是系統盤20 G，數據盤40 G。管理自動化工廠的測試工程師需要在LCM上已分配給冒煙測試的環境進行搭建與配置。

4.4 集成構建工程任務管理頁面配置冒煙測試任務

使用ICP-CI工具在集成構建工程的任務管理頁面配置冒煙測試任務，需要配置軟件產品的自動化測試用例庫名稱、冒煙測試服務管理系統名稱、冒煙測試端口號(通常為8080)，控制冒煙任務下發的配置文件放置在ICP-CI主控服務器的構建工程文件夾下和CIMonitor工具路徑下的VersionReleaseInfo.ini文件中。

VersionReleaseInfo.ini文件的配置內容如下所示：

[Summary_Info]

IssueTime=2017-03-19_03.00.11

cVersion=產品名稱 版本號_CI

bVersion=產品名稱 版本號_CIB000 //持續集成冒煙測試用例庫

IssueStatus=0

VerDescription=版本號

CmsType=DailyTest

Priority=0

[STD_LEM_SRV]

Version=版本號

Directory=版本包路徑 //出包任務完成之后，需要將版本包拷貝到該路徑下

Filename=版本包名稱

4.5 冒煙測試任務執行

ICP-CI工具通過執行相應的ANT腳本，將出包步驟生成的版本包拷貝到Directory參數配置的路徑下，通過以下步驟來完成冒煙測試任務。

(1)從ICP-CI工具下發冒煙測試任務，更新VersionReleaseInfo.ini配置文件的IssueTime，觸發CIMonitor工具。

(2)CIMonitor工具將冒煙測試任務提交到TICC，根據bVersion參數(冒煙測試用例庫)配置，TICC從TMSS中查找測試該用例集所需要的資源信息，然后TICC根據資源分配策略從LCM申請測試資源。

(3)TICC將任務下發至TEP。

(4)TEP接受任務后，調用分配到的測試資源，自動執行測試，承擔測試任務的執行機卸載試環境中舊的軟件版本包，安裝本次編譯生成的軟件版本包。從TMSS下載測試用例腳本，開始執行測試工作；測試工作結束后，將測試結果上傳給TICC；所有過程信息和最終測試結果自動保存儲到TMSS中。

(5)TICC通過CIMonitor工具反饋測試結果到ICP-CI的測試結果頁面，ICP-CI工具通過郵件向相關人員發送測試結果信息。

4.6 ICP-CI工具與自動化工廠的對接與調試

管理自動化工廠的測試工程師檢查確認自動化工廠環境狀態正常后，持續集成工程師在集成構建工程上勾選冒煙測試任務，啟動冒煙測試任務。兩人共同觀測以下檢查點：

(a)測試任務是否能夠正常下發到TICC；

(b)測試任務是否能夠正常卸載舊的軟件版本包；

(c)測試任務是否能夠正常安裝新的軟件版本包；

(d)測試任務是否能夠執行通過全部門檻用例；

(e)測試任務結束后是否能夠將測試結果反饋到ICP-CI工具的頁面上。

以上檢查點中，檢查點a和e出現問題由持續集成工程師定位解決；檢查點b、c和d出現問題由管理自動化工廠的測試工程師定位解決。

5 典型案例

5.1 案例介紹

某公司有一個軟、硬件結合的中型軟件開發項目，總的代碼量大約三百萬行。采用持續集成工具每天開展集成構建工作。在軟件項目開發初期，測試組由專人負責自動化工廠的測試工作。隨著軟件開發工作的進展，門檻測試用例集中的測試用例數量隨著軟件特性數量的增加而不斷調整，門檻測試用例數增加到50多個，軟件測試環境也趨于穩定。自動化工廠運行成熟(測試環境與軟件版本包穩定)后，項目測試組將自動化工廠的測試工作移交給部門的自動化工廠管理組。該管理組統一開展部門內多個軟件項目的自動化工廠的測試工作，進一步優化門檻用例腳本，提升測試效率和質量。

5.2 典型問題的處理

在軟件開發過程中，處理了許多冒煙測試的技術問題。下面介紹幾個具有代表性的問題。

5.2.1 代碼修改導致測試失敗

編寫腳本的測試工程師定位之后，發現由于軟件特性有變更，開發工程師修改合入了代碼之后，并沒有及時知會測試工程師，導致測試工程師沒有及時修改入廠腳本，導致腳本運行失敗。測試工程師修改入廠腳本之后，門檻用例執行成功。

5.2.2 測試腳本導致測試失敗

某次冒煙測試出現多處失敗，編寫腳本的測試工程師定位之后，發現由于有一個腳本運行時，需要通過腳本打開一個比較特殊的調試開關，腳本運行完成之后沒有關閉調試開關，導致后續相關的腳本運行失敗。確認問題之后，測試工程師修改入廠腳本，門檻用例執行成功。

5.2.3 測試環境配置導致測試失敗

編寫腳本的測試工程師定位之后，發現門檻測試用例環境上有相關的MML配置有缺失，導致依賴這個MML配置的腳本都執行失敗了，確認問題之后，管理自動化工廠的測試工程師重新添加了相關MML配置之后，門檻用例執行成功。

軟件產品開發過程中引入基于持續集成的冒煙測試之后，先后發現與攔截了多個軟件缺陷。工作實踐表明,執行冒煙測試有助于及早發現并解決軟件缺陷，提高軟件迭代開發階段軟件開發與測試的效率，便于產品主管了解工作進度和解決存在的問題。

6 結束語

集成構建工程完成軟件版本出包之后，進行冒煙測試可以快速對版本包進行測試驗證，及時向開發工程師和測試工程師反饋軟件功能特性驗證信息。發現軟件缺陷，開發工程師能夠盡快修復這些缺陷，有效避免大量的缺陷在軟件開發的某個階段集中爆發，同時也為下一步軟件代碼的開發工作提供了基線版本。長期的工作實踐表明，在軟件的開發過程中采用基于持續集成的冒煙測試，可以提高軟件的質量和開發效率，降低軟件的開發成本；采用自動化測試腳本進行測試工作，提高了測試效率，減少了測試人員大量的重復測試驗證工作；同時也有助于做好軟件項目的管理工作。