姜 文，劉立康

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

0 引 言

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

冒煙測試是一種測試策略，是對集成構(gòu)建生成的版本包進行測試驗證，同時也是進一步開展全面深入測試的預(yù)測試。開展冒煙測試工作有助于盡早發(fā)現(xiàn)軟件代碼存在的問題，提高軟件代碼的質(zhì)量和開發(fā)效率?；诔掷m(xù)集成的冒煙測試采用自動化測試腳本進行測試工作，能夠提高測試效率，減少測試人員大量的重復(fù)測試驗證工作。

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

1 冒煙測試的特點

1.1 冒煙測試

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

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

冒煙測試可以手動執(zhí)行，也可以自動化執(zhí)行。穩(wěn)定的系統(tǒng)適合自動化冒煙測試，集成過程中的系統(tǒng)適合手工冒煙測試，因為冒煙測試內(nèi)容在動態(tài)變化，變化中的自動化腳本維護工作量比較大。

1.2 門檻用例

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

1.3 基于持續(xù)集成冒煙測試的特點

持續(xù)集成工具搭建的構(gòu)建工程可以每天通過制定定時任務(wù)來自動完成從版本庫更新代碼、靜態(tài)檢查、編譯、出包、自動化用例測試等任務(wù)。持續(xù)集成中的自動化用例測試就是通常所說的冒煙測試。冒煙測試是通過自動化工廠執(zhí)行自動化腳本來完成測試任務(wù)?？梢苑譃閮煞N情形：

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

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

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

2 冒煙測試涉及到的角色

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

2.1 測試架構(gòu)師

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

2.2 測試工程師

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

2.3 開發(fā)工程師

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

2.4 持續(xù)集成工程師

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

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

該測試工程師負(fù)責(zé)自動化工廠管理、運行和維護。自動化工廠收到冒煙測試任務(wù)后，需要完成軟件版本包的安裝和冒煙測試環(huán)境搭建；自動化腳本的部署；調(diào)度執(zhí)行冒煙測試。完成冒煙測試任務(wù)后，將測試結(jié)果提交給持續(xù)集成工程師。當(dāng)冒煙測試失敗時，該測試工程師需要查明哪些測試腳本失敗，參與腳本失敗原因分析定位，需要特別關(guān)注測試環(huán)境的搭建和自動化腳本的部署。

2.6 質(zhì)量工程師

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

圖2為應(yīng)用軟件冒煙測試用例圖。

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

3 軟件測試自動化工廠

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

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

3.1 測試任務(wù)執(zhí)行控制中心(TICC)

TICC負(fù)責(zé)測試任務(wù)執(zhí)行的調(diào)度和申請測試環(huán)境資源；相關(guān)測試信息的接收和傳遞。

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

LCM是實驗環(huán)境配置信息的統(tǒng)一管理平臺，可實現(xiàn)環(huán)境錄入、查詢、修改、環(huán)境信息保存。負(fù)責(zé)所有測試資源的整合、歸并與統(tǒng)一管理，為TICC的測試任務(wù)分配相關(guān)的測試資源。通常創(chuàng)建新版本的門檻用例測試集時，需要在LCM進行測試環(huán)境配置與統(tǒng)一管理。進行門檻用例測試需要在LCM上分配專用測試環(huán)境。

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

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

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

TMSS負(fù)責(zé)測試用例、自動化測試腳本以及測試任務(wù)相關(guān)信息的管理；測試執(zhí)行結(jié)果和測試執(zhí)行時長等測試執(zhí)行過程中產(chǎn)生的中間信息都會被該系統(tǒng)自動記錄。門檻測試用例集需要在TMSS上創(chuàng)建一個以版本號_CI的測試用例集和測試用例自動化腳本集。測試人員可以在TMSS上創(chuàng)建測試任務(wù)，下發(fā)到TICC，進行自動化測試腳本的測試工作。

4 基于持續(xù)集成的冒煙測試

采用持續(xù)集成工具ICP-CI搭建集成構(gòu)建工程，通過該自動化工廠開展軟件版本包的冒煙測試?；诔掷m(xù)集成的冒煙測試通常由以下幾部分組成：制定門檻測試用例集；門檻用例自動化腳本編寫與入廠；門檻用例測試環(huán)境搭建；集成構(gòu)建工程任務(wù)管理頁面配置冒煙測試任務(wù)；冒煙測試任務(wù)執(zhí)行。

冒煙測試運行的系統(tǒng)架構(gòu)如圖3所示。

圖3 基于持續(xù)集成的冒煙測試系統(tǒng)架構(gòu)

4.1 制定門檻測試用例集

在軟件開發(fā)過程中，測試架構(gòu)師根據(jù)目前軟件產(chǎn)品的各特性與功能模塊確定門檻測試用例集，經(jīng)過評審之后，這些用例由測試架構(gòu)師導(dǎo)入TMSS下以版本號_CI命名的測試用例集中，并根據(jù)軟件開發(fā)的情況不斷調(diào)整該測試用例集中的測試用例。

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

門檻用例集確定之后，測試工程師完成門檻用例腳本的編寫與調(diào)試。測試架構(gòu)師進行腳本評審，腳本評審?fù)ㄟ^后，測試工程師通過配置管理工具Git將門檻用例腳本合入配置庫，管理自動化工廠的測試工程師將腳本從配置庫中導(dǎo)入到TMSS下以版本號_CI命名的測試用例腳本集，和測試用例集中的測試用例一一對應(yīng)。

4.3 門檻用例測試環(huán)境搭建

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

4.4 集成構(gòu)建工程任務(wù)管理頁面配置冒煙測試任務(wù)

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

VersionReleaseInfo.ini文件的配置內(nèi)容如下所示：

[Summary_Info]

IssueTime=2017-03-19_03.00.11

cVersion=產(chǎn)品名稱 版本號_CI

bVersion=產(chǎn)品名稱 版本號_CIB000 //持續(xù)集成冒煙測試用例庫

IssueStatus=0

VerDescription=版本號

CmsType=DailyTest

Priority=0

[STD_LEM_SRV]

Version=版本號

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

Filename=版本包名稱

4.5 冒煙測試任務(wù)執(zhí)行

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

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

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

(3)TICC將任務(wù)下發(fā)至TEP。

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

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

4.6 ICP-CI工具與自動化工廠的對接與調(diào)試

管理自動化工廠的測試工程師檢查確認(rèn)自動化工廠環(huán)境狀態(tài)正常后，持續(xù)集成工程師在集成構(gòu)建工程上勾選冒煙測試任務(wù)，啟動冒煙測試任務(wù)。兩人共同觀測以下檢查點：

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

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

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

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

(e)測試任務(wù)結(jié)束后是否能夠?qū)y試結(jié)果反饋到ICP-CI工具的頁面上。

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

5 典型案例

5.1 案例介紹

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

5.2 典型問題的處理

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

5.2.1 代碼修改導(dǎo)致測試失敗

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

5.2.2 測試腳本導(dǎo)致測試失敗

某次冒煙測試出現(xiàn)多處失敗，編寫腳本的測試工程師定位之后，發(fā)現(xiàn)由于有一個腳本運行時，需要通過腳本打開一個比較特殊的調(diào)試開關(guān)，腳本運行完成之后沒有關(guān)閉調(diào)試開關(guān)，導(dǎo)致后續(xù)相關(guān)的腳本運行失敗。確認(rèn)問題之后，測試工程師修改入廠腳本，門檻用例執(zhí)行成功。

5.2.3 測試環(huán)境配置導(dǎo)致測試失敗

編寫腳本的測試工程師定位之后，發(fā)現(xiàn)門檻測試用例環(huán)境上有相關(guān)的MML配置有缺失，導(dǎo)致依賴這個MML配置的腳本都執(zhí)行失敗了，確認(rèn)問題之后，管理自動化工廠的測試工程師重新添加了相關(guān)MML配置之后，門檻用例執(zhí)行成功。

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

6 結(jié)束語

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