基于环境资源自动匹配的云测试框架研究与应用

鞠炜刚 欧林宝

1(中兴通讯南京研究所 江苏 南京 210012) 2(中兴通讯天津研究所 天津 300308)

0 引 言

软件测试在软件生命周期中占有十分重要的地位，是保障软件质量的重要手段，必须不断地对软件进行测试[1-2]，首先要搭建配置测试环境，然后执行测试用例获取结果。传统的方式是测试人员根据测试要求搭建、调整测试环境资源，随着软件测试环境的复杂度越来越高，这种方式越来越不能满足需要。采用基于虚拟化技术的云测试可以有效获取资源，生成并配置所需测试环境[3]。但也存在一定局限性，例如复杂环境自动生成时间较长，同时对不支持虚拟化需要在真实硬件组网环境下测试的软件不能满足要求，对这类情况需要采用一种新的技术和方法。本文提出一种测试环境资源云化，测试用例按需自动匹配环境、分布式调度执行的云测试思路。在此基础上设计开发了云测试框架，以更好地完成对复杂环境组网下的软件产品的测试。

1 测试环境资源使用方式概述

在软件测试中如何高效地使用测试环境资源进行测试一直是重要的课题，包括测试环境的建立、使用、释放和管理，要求建立、释放时间短，利用率高等[4]。

1.1 传统方式

在传统方式中，测试人员根据测试需要搭建或调整测试环境资源，修改测试用例环境参数，执行测试用例，返回结果报告[5]，但存在以下问题：

(1) 测试环境资源缺乏管理，执行测试用例时很难快速找到合适的空闲环境，环境资源利用率低下。

(2) 找不到合适环境的情况下，需要根据需求搭建、调整、配置环境，测试准备时间长，效率低，而且可能存在重复搭建，浪费资源。

(3) 测试用例和环境资源数据紧耦合，移植到目标环境比较困难。

(4) 对于批量用例执行，只能在一套环境执行，效率不高，采用手工分解的方式比较困难，结果也不容易合并。

1.2 基于虚拟化的云测试

随着云计算技术的发展诞生了云测试，云测试是一种有效利用云计算环境资源对软件进行测试的新方式[6-7]。其中一种方法是基于虚拟化的云测试，在测试用例执行前获取虚拟化的计算、存储、网络等云资源，自动创建配置廉价、便捷、高效的测试环境，测试完成后释放资源，加速了整个软件测试进程，同时测试环境资源按需动态申请和释放，资源利用率很高，但是有两个主要限制：

(1) 一些软件产品并没有设计在虚拟化平台上运行，需要改造适配，而为了测试改造产品是不合适的，而另一些软件产品必须在真实硬件环境组网下测试。

(2) 对于一些环境组网和配置复杂的软件系统，获取虚拟资源并自动创建、配置环境的时间较长，不能满足测试要求。

针对以上传统方式存在的问题和基于虚拟化技术的云测试的一些局限性，我们提出了一种测试环境资源云化，按需自动匹配环境，分布式调度执行的云测试新思路。在此基础上设计开发了云测试框架，可以有效地使用测试环境资源进行测试，提高环境利用率和执行效率，并在通信系统产品测试中进行了有效的应用。

2 基于环境资源自动匹配的云测试框架

2.1 物理架构

基于环境资源自动匹配的云测试框架的物理架构如图1所示。

图1 物理架构

云测试物理框架由一个云测试服务器master节点通过网络连接多个客户端slave节点组成，属于典型的分布式架构[8]，可以由大量廉价的PC机组成，也可以在IAAS上基于虚机或PAAS上基于容器来部署，非常灵活[9-10]。

云测试服务器master是云测试的调度中心，主要根据测试任务中测试用例的要求进行环境资源匹配，将用例各自分发调度到合适的测试环境执行，并汇总结果报告输出。云测试客户端slave节点连接测试环境并运行测试执行器进行测试，测试环境可以直接部署在客户端slave节点，也可以由多个设备组成复杂的组网环境，由slave节点进行对接，所有的测试环境构成测试环境资源池，实现了测试环境的云化。云测试框架同时支持真实环境和虚拟化环境，以满足各种软件的测试需要。

2.2 工作原理

基于环境资源自动匹配的云测试框架的基本工作原理如图2所示。

图2 工作原理

如图所示，在云测试框架中，每个客户端slave节点都有一个环境资源描述文件，用来描述所连接的环境资源信息，客户端节点会定时向服务器master上报更新环境资源信息。

测试人员通过云测试创建测试任务，任务由一个或多个测试用例构成，用例用文件描述对环境资源的需求，可以按单用例或一组用例来进行描述。

当向云测试服务器master提交测试任务时，服务器对测试任务中的每个用例根据其对环境资源的需求，调用资源匹配算法，与上报的客户端环境资源信息进行预匹配。预匹配成功后将测试用例放到调度队列中等待调度，同一个任务中不同的测试用例根据需要可以匹配到不同的测试环境。

当某个客户端节点空闲后会向服务器请求测试用例执行， master从调度队列中获取和该客户端节点匹配的测试用例，请求客户端slave节点调度执行，执行完成后将测试结果报告回送给服务器。当一个测试任务中所有测试用例均执行完成后，master会汇总合并整个测试任务的结果报告。

2.3 关键技术

2.3.1 测试环境云化

基于环境资源匹配的云测试首先要将测试环境云化，建立共享环境资源池，供云测试系统根据用例需求进行匹配和调度。云化的基础是测试环境标准化，在根据需求进行测试设计时，一方面分析测试业务流程，根据功能特性对测试用例进行分类，划分测试集，另一方面要分析各种可能的测试组网环境，进行整理和归类，形成标准化的环境集。环境标准化是建立在对本领域测试环境分类基础上的一种对环境资源类型、数量、拓扑组网和配置属性的标准化，其原则是根据测试需求对环境分类，再根据已分类环境的特征按本领域的标准进行部署、配置，形成满足测试需求的环境资源池，下面给出一般的规则和方法：

1) 根据业务场景对测试环境分类 针对需求特性中不同业务场景对测试环境进行分类，不同类别环境中需要的资源及资源的业务配置属性有所不同，例如不同业务场景需要不同类型的服务器组合及业务配置，对于相同的可以归为一大类环境。

2) 根据非功能性需求对测试环境分类 针对需求特性中的非功能需求部分，包括高可用性、性能、安全等的要求对测试环境进行分类，不同类别的测试环境中资源的数量、拓扑组网和非功能性配置属性有所不同，例如高可用性需要数据库主从环境或业务服务器多活配置，对于相同的可以归为一大类环境。

3) 对分类的环境确定标准化的部署特性 对已划分出的几大类典型环境，进一步对每一类测试环境需要的资源类型、数量、组网方式及业务或非功能性配置属性进行归纳，就可以形成本领域的部署标准，从而达成针对某需求的测试环境标准化的目标。

环境标准化后即根据要求来搭建、配置测试环境，可以部署在真实或虚拟化平台上，然后将测试环境挂接到云测试框架的slave节点上接入云测试，形成云化的共享环境资源池[11]。

2.3.2 资源描述和匹配

为了将测试用例对环境资源的需求和云化的环境资源进行匹配，必须对两者分别进行描述，然后调用资源匹配算法进行匹配，输出是否匹配的结果，如图3所示。

图3 环境资源匹配

云化的环境资源是通过slave节点接入云测试框架的，每个slave节点上都有一个环境资源描述文件，描述测试环境中资源节点和节点间拓扑连接关系，资源节点描述包括基本属性和扩展属性；测试用例对环境资源的需求用环境资源请求文件来描述，具有相同资源需求的测试用例或用例集可以共享同一个描述文件，描述对资源节点和节点间拓扑连接的要求，其中资源节点可以描述对资源类型和各种属性的具体要求。

测试人员提交测试任务时，将任务中用例对环境资源的请求文件和环境资源池中已具备的环境资源描述文件应用匹配算法进行自动匹配，做到了测试用例与环境完全隔离。

2.3.3 分布式调度

一个测试任务包括多个测试用例，每个测试用例可以根据对环境资源的需求匹配调度到不同的测试环境分布式执行，执行完毕后汇总结果报告，极大提高了空闲环境利用率，同时用例分发到多个环境分布式执行，极大地提高了测试执行效率[12]。

3 云测试框架的设计和实现

3.1 框架设计

云测试在框架设计上整个系统分为云服务器master节点、客户端Slave节点和浏览器三部分，master节点和slave节点通过JSON格式的消息进行通信[13]，master节点通过restful接口和浏览器交互，如图4所示。

图4 系统框架

3.1.1 云服务器master节点

master节点是云调度中心，由一个Web Server和一个调度Server组成，其中Web Server主要处理测试任务、测试环境、用户和日志的管理，调度Server则专门负责处理用例对环境资源的匹配、任务调度和执行触发，Web Server和调度Server通过消息通信来相互协作。整个框架设计采用了DDD的四层架构，分为表示层、服务层、领域层和基础设施层[14]，其中表示层由Web Server来提供任务、环境、用户和日志管理的操作界面。服务层包括Web Server提供的测试任务、环境、用户、日志操作服务和调度Server提供的匹配、调度、执行触发等服务。领域层则由Model提供的领域对象组成，包括任务、用例和环境等各种领域对象，服务层提供的服务由领域层对象交互协作提供。基础设施层则提供了对测试引擎、数据库、SVN以及消息通信等底层的处理。

3.1.2 客户端slave节点

slave节点是客户端节点，层次相对比较简单，分领域层和基础设施层，其中领域层有测试用例和报告等领域对象，主要处理用例申请、用例执行和结果上报，基础设施层则包括了对测试框架、消息通信、日志等的基础处理。

3.2 资源匹配

3.2.1 资源描述

在云测试框架中，资源描述包括了对资源池中已有的环境资源描述和用例对环境资源要求的描述两大类。

3.2.1.1 环境资源描述

对于资源池中已存在的环境资源，描述中应包括资源描述resources和资源间拓扑关系links这两大部分，下面对如图5所示的测试环境进行描述。

图5 环境资源结构

图5环境描述如下：

{″id″: 资源id1, ″type″:设备类型1,″attributes″:{″属性″: ″属性值″ }},

{″id″: 资源id2, ″type″:设备类型1,″attributes″:{″属性″: ″属性值″ }},

{″id″: 资源id3, ″type″:设备类型3,″attributes″:{″属性″: ″属性值″ }},

{″id″: 资源id4, ″type″:设备类型4,″attributes″:{″属性″: ″属性值″ }}]

″links″: [

{″id″:连接id1, ″nodes″: [″资源id1″,″资源id3″]},

{″id″:连接id2, ″nodes″: [″资源id2″,″资源id4″]},

{″id″:连接id3, ″nodes″: [″资源id3″,″资源id4″]}]

其中resources部分是描述资源节点，一个环境可以包括一个或多个资源节点。对于每个资源节点包括基本属性和扩展属性，其中id为资源id，type为资源类型，都属于基本属性，可以根据实际需要扩展资源属性，扩展属性放在attributes中，可以有一个或多个。

2.培养业务人员和财务人员税务筹划意识及业务能力，最大限度地节约采购成本。餐饮行业进项税发票的取得直接关系到企业的经营成本及利润的多寡，营改增后在企业里应对相关政策进行宣传和培训，尤其要对业务人员和财务人员加强增值税及发票知识的培训，让他们清楚地知道能否取得可抵扣发票及取得发票的税率对于经营成本和企业利润都产生直接的影响。采购人员应减少向小规模纳税人的供应商采购，因为小规模纳税人一般只能开具增值税普通发票，即使到税务局代开发票也只是3%的税率。在和供应商的价格谈判过程中，除了要考虑采购总价还要考虑可抵扣的税金对于成本的影响。

links部分描述了resources中资源节点的拓扑连接关系，可以根据实际情况描述一个或多个连接关系。其中每个连接包括了连接id和nodes属性，nodes用来描述拓扑连接的两端，例如图5的环境描述″links″中的{″id″:连接id1, ″nodes″: [″资源id1″,″资源id3″]}，表示了资源id1连接到资源id3这样一个连接。

3.2.1.2 用例对环境资源需求描述

″resources″：

{

″资源1″: {″reqType″: ″资源类型1″, ″扩展属性1″: ″扩展属性1值″},

″资源3″: {″reqType″: ″资源类型3″},

″资源1-资源3″: {″reqType″: ″link″, ″nodes″: [″资源1″,″资源3″]},

}

如上分别描述了资源节点和节点间拓扑连接关系的要求。

对于资源节点要求的描述，可以描述一个或多个需要的资源节点，这里和已有环境资源描述不同的是，在资源节点请求中只需要描述需要匹配的属性，可以包括基本属性和扩展属性。对于基本属性 ，reqType表示需要的资源类型，对于扩展属性，根据实际需要描述一个或多个需要匹配的扩展属性，例如上述描述中资源1携带了扩展属性1和期望值1，表示希望扩展属性1具有期望值1，如果不需要匹配扩展属性，则可以不描述，如资源3。

对于节点间拓扑连接关系要求的描述，可根据需要描述一个或多个。例如上述例子描述了名为″资源1-资源3″的连接关系，其中″nodes″: [″资源1″,″资源3″]表示了需要资源节点1连接到资源节点3。

3.2.2 资源匹配算法

环境资源匹配算法接受两个输入，一是测试用例对环境资源的需求描述，二是实际存在的某个环境资源描述，通过执行匹配算法，输出是否匹配的结果，具体的匹配算法分两个步骤：资源节点匹配和拓扑连接关系匹配。

第1步资源节点匹配

为用例的环境资源请求中每一个资源节点从待匹配的环境资源描述文件中找到所有匹配上的资源节点，具体方法如下：

1) 遍历用例对环境资源请求中的所有资源节点，对每个资源节点i继续2)。

2) 遍历环境资源描述中已存在的所有资源节点，对每个资源节点j继续3)。

3) 比较请求的资源节点i和已有的资源节点j是否匹配。

4) 如果匹配将资源节点j加入到资源节点i的匹配节点列表matched[i][]中。

注意在3)中进行比较时，对节点的基本属性和需要的扩展属性进行比较匹配，当所有请求的属性都匹配时，节点才匹配成功。

以3.2.1节中资源描述和资源请求为例，资源请求中资源节点1匹配到2个资源节点：[{″id″: 资源id1}，{″id″: 资源id2}]；资源节点3匹配到1个资源节点：[{″id″: 资源id3}]。

第2步拓扑连接关系匹配

在第1步资源节点匹配中，每个需要的资源节点都会匹配到一个或多个满足要求的环境资源节点，接下来进行拓扑连接关系匹配，具体方法如下：

1) 针对第1步环境资源请求中每个资源节点匹配到的环境资源节点(1个或多个)，获取笛卡尔积的各种组合关系。

2) 针对环境资源请求中对资源节点间拓扑关系的要求，遍历笛卡尔积组合关系中的每个组合，进行拓扑连接关系匹配，记录下每个匹配上的组合关系。

3) 如果存在一个或多个组合关系满足匹配要求，则选择其中一个资源节点组合作为匹配结果，否则返回无法匹配。

以3.2.1节中资源描述和资源请求为例，在第1步资源节点匹配中，资源节点1匹配到的节点为：[{″id″: 资源id1}，{″id″: 资源id2}]；资源节点3匹配到的节点为：[{″id″: 资源id3}]。那么根据步骤1)，笛卡尔积有两个组合，分别为组合1：[{″id″: 资源id1},{″id″: 资源id3}]和组合2：[{″id″: 资源id2},{″id″: 资源id3}]。再根据步骤2)进行匹配，从这两个组合关系中根据拓扑连接关系的要求，组合1中资源id1连接到资源id3，组合关系的两个端点的类型符合3.2.1节资源请求中拓扑连接的要求，而组合2不符合要求，因此匹配到唯一符合要求的组合1并记录下来，该环境满足测试用例对环境资源的要求，匹配成功。

3.3 调度匹配过程

云测试框架的资源匹配和调度过程由master节点和slave节点协作完成[15]，如图6所示。

图6 匹配调度过程

其中master节点包括任务、调度、匹配、环境管理和报告5个核心模块，slave节点包括执行器和环境管理2个核心模块，它们之间交互协作完成了整个调度匹配，可以分为预匹配和正式匹配两个过程。

3.3.1 预匹配过程

测试任务提交后，云服务器master根据每个测试用例对环境资源的要求和各客户端节点slave已有的环境资源描述进行预先匹配的过程，具体步骤如下：

(1) 测试人员向云测试master节点提交测试任务，任务模块接收到处理请求后向调度模块发送调度请求。

(2) 调度模块接收到请求后向匹配模块发送匹配请求，请求对任务中的测试用例进行环境资源匹配。

(3) slave节点的环境管理模块会定期将环境信息上报给master节点的环境管理模块。匹配模块从环境管理模块获取环境资源描述信息，调用匹配算法，进行预匹配，针对每个测试用例找到符合匹配要求的环境列表并返回调度模块。

(4) 调度模块将匹配的环境列表记录到用例的预匹配数据区中，然后将用例放入等待调度队列，并向任务模块返回应答，预匹配过程完成。

3.3.2 正式匹配过程

(1) 当测试环境空闲后，slave节点的执行器会向master的调度模块发送请求，请求执行用例。

(2) master的调度模块从调度队列中根据前面预匹配的结果找到一个和该slave环境匹配的可执行用例，然后向slave发送执行用例的请求。

(3) slave的执行器收到执行请求后，再进行一次正式匹配，如果匹配将本地环境参数注入到测试用例，执行器开始执行用例，通过消息交互对被测环境进行实际测试。

(4) slave的执行器测试完成后同时向master的报告模块和调度模块上报测试报告和用例执行完成的消息。

(5) 调度模块等待空闲的slave请求执行用例，继续对测试任务中的用例进行调度分发执行，如果存在多个满足条件的空闲slave就可以并行执行。

(6) 调度模块完成任务中所有用例执行后向报告模块请求合并获取完整的测试报告，报告模块对各用例的执行报告进行合并，形成完整的测试报告返回给调度模块，调度模块将测试报告保存起来供用户查看，测试任务匹配调度执行结束。

4 应用实例

在大型复杂通信系统产品A测试中，由于其产品特点，整个产品的一大部分对处理效率的严格要求，目前只能在纯硬件设备上运行。而另一部分虽然实现了虚拟化，但由于系统的复杂性，获取虚拟化资源并自动创建、配置环境的时间较长，达到了20分钟左右。由于产品A只能部分虚拟化，纯硬件部分无法自动创建，且虚拟化部分的自动创建时间也很长，无法采用基于虚拟化的云测试技术来有效提升环境的部署和利用效率，为此应用基于环境资源自动匹配的云测试框架来实施。

对于产品A根据功能特性对测试用例划分测试集，同时采用2.3.1中测试环境标准化的原则和方法对产品A的业务场景和非功能性要求进行分析，对各种可能的测试环境组网进行整理和归纳，部署标准化的环境资源池，有8种标准化环境。

接下来对这8种标准化环境用资源描述语言进行描述，主要描述环境中资源节点关键属性和资源节点间的拓扑连接关系，然后通过slave节点上报到master上。以下是其中一套环境的描述：

″resources″: [

{″id″:″net″,″type″:″NETTYPE″,″attributes″:{″ip″: ″10.43.145.28″,″bureau″:″2″,″version″:″v3.20.1″}},

{″id″:″testpc″,″type″:″TESTPC″,″attributes″:{″ip″: ″10.43.145.20″ }}]

″links″: [{″id″:″testpc_net″,″nodes″: [″testpc″,″net″]}

针对云化的标准化环境资源池，在测试用例上用环境描述语言对环境资源的要求进行描述如下：

″resources″：

{″testpc″: {″reqType″: ″TESTPC″},

″net″: {″reqType″: ″NETTYPE″ },

″testpc_net″:{″reqType″: ″link″, ″nodes″: [″testpc ″,″net″]}

}

在测试执行时，建立了5个测试任务，共1 000多条用例，其中3个测试任务用于功能测试，2个测试任务用于自动化测试。当测试任务触发执行时，测试用例会自动根据对环境资源的要求匹配到合适的空闲环境执行。当8套标准化环境中有多套空闲且满足用例要求时，测试任务中的用例会在这些环境中并行执行，完成后将结果汇总上报。

应用基于资源匹配和调度的云测试框架在功能测试和自动化测试中均取得了较好的效果，主要有以下几点：

1) 产品A的各种典型测试环境云化，测试用例按需自动匹配到合适的空闲环境执行，减少了环境间的冲突，提高了环境资源的利用率。

2) 测试用例匹配到合适的环境执行，测试用例对环境的依赖大大降低，提高了灵活性和可移植性。

3) 产品A的业务场景复杂，用例多，由于云测试框架可采用分布式并行执行，使得自动化测试的时间由8小时缩短为2小时，极大地提高了效率。

5 结 语

基于资源匹配和调度的云测试框架在不同的行业领域都可以应用。需要充分考虑各种业务场景和非功能性要求对典型环境组网的要求，合理规划云化的环境资源池，并通过环境描述语言描述后挂载到云测试上，通过环境资源匹配接受测试用例的调度执行，极大地提高了环境资源的利用率和测试任务的执行效率。

未来云测试框架应该向自动检测目标环境并生成环境资源描述以及更丰富的匹配调度策略这两个方向继续探索研究，发挥更大的作用。

[1] Patton R.软件测试[M].北京:机械工业出版社,2002:1-50.

[2] 吴显光.软件自动化测试[J].中国新通信,2012,14(14):67-69.

[3] 周楠,舒辉,董卫宇.基于虚拟机的网络测试环境搭建与调度自动化实现[J].信息工程大学学报,2008,9(1):100-104.

[4] 张媛媛.测试环境管理的研究及应用[D].北京:北京邮电大学,2010.

[5] 龚丹.自动化测试之我见[J].计算机光盘软件与应用,2012(17):83-84.

[6] 李乔,柯栋梁,王小林.云测试研究现状综述[J].计算机应用研究,2012,29(12):4401-4406.

[7] 李乔,郑啸.云计算研究现状综述[J].计算机科学,2011,38(4):32-37.

[8] Hanawa T,Banzai T,Koizumi H,et al.Large-scale software testing environment using cloud computing technology for dependable parallel and distributed systems[C]//Proc of the 3rd International Conference on Software Testing,Verification,and Validation.Washington DC:IEEE Computer Society,2010:428-433.

[9] 徐鹏,陈思,苏森.互联网应用PaaS平台体系结构[J].北京邮电大学学报,2012,35(1):120-124.

[10] 徐风,王伟平.基于综合形式(PAAS+IAAS)的云计算平台的研究与构建[J].科技资讯,2010(32):19-19.

[11] Takayuki B,Hitoshi K,Ryo K,et al.D-cloud:design of a software testing environment for reliable distributed systems using cloud computing technology[C]//Proc of the 10th International Conference on Cluster,Cloud,and Grid Computing.Washington DC:IEEE Computer Society,2010:631-636.

[12] 王跃科,明德祥.基于网络互联的分布式测试系统开放体系结构与技术[J].计算机测量与控制,2002,10(8):496-498.

[13] 袁栋梁,孙忠林,田刚,等.基于JSON格式的信息资源共享技术的应用研究[J].计算机与现代化,2010,(9):175-178.

[14] Evans E.领域驱动设计[M].北京:人民邮电出版社,2010.

[15] 左利云,曹志波.云计算中调度问题研究综述[J].计算机应用研究,2012,29(11):4023-4027.