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

姜 文，劉立康

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

0 引 言

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

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

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

1 冒煙測試的特點(diǎn)

1.1 冒煙測試

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

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

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

1.2 門檻用例

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

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

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

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

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

圖1 門檻用例測試運(yùn)行流程

2 冒煙測試涉及到的角色

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

2.1 測試架構(gòu)師

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

2.2 測試工程師

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

2.3 開發(fā)工程師

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

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

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

2.5 管理自動(dòng)化工廠的測試工程師

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

2.6 質(zhì)量工程師

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

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

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

3 軟件測試自動(dòng)化工廠

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

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

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

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

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

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

3.3 自動(dòng)化測試執(zhí)行平臺(tái)(TEP)

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

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

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

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

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

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

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

4.1 制定門檻測試用例集

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

4.2 門檻用例自動(dòng)化腳本編寫與入廠

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

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

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

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

使用ICP-CI工具在集成構(gòu)建工程的任務(wù)管理頁面配置冒煙測試任務(wù)，需要配置軟件產(chǎn)品的自動(dòng)化測試用例庫名稱、冒煙測試服務(wù)管理系統(tǒng)名稱、冒煙測試端口號(hào)(通常為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)品名稱 版本號(hào)_CI

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

IssueStatus=0

VerDescription=版本號(hào)

CmsType=DailyTest

Priority=0

[STD_LEM_SRV]

Version=版本號(hào)

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申請(qǐng)測試資源。

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

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

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

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

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

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

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

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

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

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

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

5 典型案例

5.1 案例介紹

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

5.2 典型問題的處理

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

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

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

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

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

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

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

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

6 結(jié)束語

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