基于持续集成的冒烟测试

姜 文，刘立康

(西安电子科技大学 通信工程学院，陕西 西安 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 结束语

集成构建工程完成软件版本出包之后，进行冒烟测试可以快速对版本包进行测试验证，及时向开发工程师和测试工程师反馈软件功能特性验证信息。发现软件缺陷，开发工程师能够尽快修复这些缺陷，有效避免大量的缺陷在软件开发的某个阶段集中爆发，同时也为下一步软件代码的开发工作提供了基线版本。长期的工作实践表明，在软件的开发过程中采用基于持续集成的冒烟测试，可以提高软件的质量和开发效率，降低软件的开发成本；采用自动化测试脚本进行测试工作，提高了测试效率，减少了测试人员大量的重复测试验证工作；同时也有助于做好软件项目的管理工作。