测试环境部署及冒烟测试方法、装置及电子设备与流程

1.本技术涉及软件测试技术领域，尤其是涉及一种测试环境部署及冒烟测试方法、装置及电子设备。


背景技术：

2.目前，在线下的软件版本测试工作中主要有三大阶段：阶段1，对待测试版本进行测试环境准备及冒烟测试；阶段2，对待测试版本进行各新功能验证及bug修复验证；阶段3，上线前多个功能集成版本的回归验证。
3.对于阶段1，在提出待测试版本的测试单后，首先需要在测试环境部署相应版本，这个过程仍依赖于人为操作及干预。比如，首先需要手动输入版本号、物理机ip及部署脚本，然后登录zeus平台去执行该部署脚本，以对测试环境中所选择的物理机进行测试代码的更新。这种方式依赖于人为手动执行，人工成本高，并且手动输入版本号及物理机ip存在错误的风险，增加了排查及纠正的无意义工作量。


技术实现要素：

4.本技术的目的在于提供一种测试环境部署及冒烟测试方法、装置及电子设备，能够实现版本的自动化部署，提升版本的测试环境的部署效率，从而提高后续的版本冒烟测试效率。
5.第一方面，本技术实施例提供一种测试环境部署方法，方法包括：检测scm版本控制库中是否存在待测试的版本；如果是，获取测试环境中物理机的可用资源信息；根据测试环境中物理机的可用资源信息，确定部署版本的测试环境所需的目标物理机；将版本对应的测试代码部署于目标物理机和指定物理机中；指定物理机为控制节点，目标物理机为计算节点。
6.进一步的，上述检测scm版本控制库中是否存在待测试的版本的步骤，包括：轮训查看scm版本控制库；判断scm版本控制库中是否存在符合预设命名规则的新文件；如果是，确定scm版本控制库中存在待测试的版本。
7.进一步的，上述检测scm版本控制库中是否存在待测试的版本的步骤，包括：轮训查看git提交记录；判断git提交记录中是否存在新的commit编号；如果是，确定scm版本控制库中存在待测试的版本。
8.进一步的，上述获取测试环境中物理机的可用资源信息的步骤之前，还包括：获取版本对应的测试代码在研发自测环境中的冒烟测试结果；监控测试环境中物理机的运行信息；其中，物理机的运行信息包括：运行于物理机上的各个服务组件，及各个服务组件分别对应的服务运行状态；如果冒烟测试结果和物理机的运行信息均正常，执行获取测试环境中物理机的可用资源信息的步骤。
9.进一步的，上述根据测试环境的物理机的可用资源信息，确定部署版本的测试环境所需的目标物理机的步骤，包括：将多个物理机按照其对应的可用资源信息进行排序；从
最大可用资源信息对应的物理机开始，选取指定个数的物理机，作为部署版本的测试环境所需的目标物理机。
10.进一步的，上述测试环境中包括第一物理机集群和第二物理机集群；根据测试环境的物理机的可用资源信息，确定部署版本的测试环境所需的目标物理机的步骤，包括：对第一物理机集群和第二物理机集群中的物理机分别按照物理机的可用资源信息进行排序；根据排序结果，从第一物理机集群和第二物理机集群中分别选取指定个数的物理机作为部署版本的测试环境所需的目标物理机。
11.进一步的，上述将版本对应的测试代码部署于目标物理机中的步骤之前，还包括：检测目标物理机中是否存在正在运行的虚拟机；如果存在，将虚拟机迁移至除目标物理机之外的其它物理机上。
12.进一步的，上述将版本对应的测试代码部署于目标物理机中的步骤之前，还包括：根据版本对应的测试事件涉及的机型，将目标物理机加入到标注有与机型对应标签的物理机集群中。
13.进一步的，上述将版本对应的测试代码部署于目标物理机和指定物理机中的步骤，包括：根据指定物理机的标识和目标物理机的标识，按照预设的部署脚本，将版本对应的测试代码部署于指定物理机和目标物理机对应的测试环境中。
14.第二方面，本技术实施例还提供一种冒烟测试方法，方法包括：根据第一方面所述的测试环境部署方法，将待测试的版本对应的测试代码部署于目标物理机和指定物理机中；根据版本对应的测试代码，选择jenkins上对应的服务组件进行冒烟测试。
15.进一步的，上述根据版本对应的测试代码，选择jenkins上对应的服务组件进行冒烟测试的步骤之前，还包括：监控目标物理机和指定物理机的运行信息；如果运行信息正常，继续执行根据版本对应的测试代码，选择jenkins上对应的服务组件进行冒烟测试的步骤。
16.第三方面，本技术实施例还提供一种测试环境部署装置，装置包括：版本检测模块，用于检测scm版本控制库中是否存在待测试的版本；物理机信息获取模块，用于如果检测到待测试的版本，获取测试环境中物理机的可用资源信息；目标物理机确定模块，用于根据测试环境中物理机的可用资源信息，确定部署版本的测试环境所需的目标物理机；测试环境部署模块，用于将版本对应的测试代码部署于目标物理机和指定物理机中；指定物理机为控制节点，目标物理机为计算节点。
17.第四方面，本技术实施例还提供一种冒烟测试装置，装置包括：测试环境部署模块，用于根据第一方面的版本的测试环境的部署方法，将待测试的版本对应的测试代码部署于目标物理机和指定物理机中；冒烟测试模块，用于根据版本对应的测试代码，选择jenkins上对应的服务组件进行冒烟测试。
18.第五方面，本技术实施例还提供一种电子设备，包括处理器和存储器，存储器存储有能够被处理器执行的计算机可执行指令，处理器执行计算机可执行指令以实现上述第一方面所述的方法。
19.第六方面，本技术实施例还提供一种计算机可读存储介质，计算机可读存储介质存储有计算机可执行指令，计算机可执行指令在被处理器调用和执行时，计算机可执行指令促使处理器实现上述第一方面所述的方法。
20.本技术实施例提供的测试环境部署及冒烟测试方法中，均可以通过对scm版本控制库中的版本进行自动检测，并在检测到待测试的版本后，自动获取测试环境中物理机的可用资源信息，并根据测试环境中物理机的可用资源信息，确定部署该版本的测试环境所需的目标物理机；然后将版本对应的测试代码部署于目标物理机和指定物理机中，本技术实施例能够实现版本的自动化部署，提升版本的测试环境的部署效率，从而提高后续的版本测试效率。
附图说明
21.为了更清楚地说明本技术具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本技术的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
22.图1为本技术实施例提供的一种测试环境部署方法的流程图；
23.图2为本技术实施例提供的一种信息监控方法的流程图；
24.图3为本技术实施例提供的一种冒烟测试方法的流程图；
25.图4为本技术实施例提供的一种测试环境部署装置的结构框图；
26.图5为本技术实施例提供的另一种测试环境部署装置的结构框图；
27.图6为本技术实施例提供的一种冒烟测试装置的结构框图；
28.图7为本技术实施例提供的一种电子设备的结构示意图。
具体实施方式
29.下面将结合实施例对本技术的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
30.目前，在线下的测试工作中主要有三大阶段：阶段1，对待测试版本进行测试环境准备及冒烟测试；阶段2，对待测试版本进行各新功能验证及bug修复验证；阶段3，上线前多个功能集成版本的回归验证。
31.对于阶段1，在提出待测试版本的测试单后，首先需要在测试环境部署相应版本，这个过程仍依赖于人为操作及干预。比如，首先需要手动输入版本号、物理机ip及部署脚本，然后登录zeus平台去执行该部署脚本，以对测试环境中所选择的物理机进行测试代码的更新。这种方式依赖于人为手动执行，人工成本高，并且手动输入版本号及物理机ip存在错误的风险，增加了排查及纠正的无意义工作量。
32.基于此，本技术实施例提供一种测试环境部署及冒烟测试方法、装置及电子设备，下面首先对本技术实施例中涉及到的一些术语进行解释说明：
33.在openstack(一个开源的云计算管理平台项目，是一系列软件开源项目的组合)分布式框架中，可分为控制节点与计算节点，控制节点负责进行资源调度到对应的计算节点上，计算节点则是为虚拟机分配实际的资源，控制节点与计算节点均为linux系统的物理机。
34.nova，openstack中最核心的服务模块，负责管理和维护云计算环境的计算资源，负责整个云环境虚拟机生命周期的管理。
35.neutron，openstack中提供网络服务的核心组件。
36.glance，openstack中提供镜像相关服务组件。
37.cinder，openstack中提供卷相关服务组件。
38.libvirt，管理虚拟机和其他虚拟化功能，提供各种api，供上层来管理不同的虚拟机。
39.qemu-kvm，qemu是个独立的虚拟化解决方案。而kvm是另一套虚拟化解决方案，但它缺乏设备虚拟化以及相应的用户空间管理虚拟机的工具。qemu连同kvm一起构成了另一个独立的虚拟化解决方案。
40.scm，一种版本控制工具，用于产品库在各机房部署中转机，简单便捷的提供产出分发服务。
41.jenkins，是一个开源项目，提供了一种易于使用的持续集成系统，使开发者从繁杂的集成中解脱出来，专注于更为重要的业务逻辑实现上。
42.zeus，内部使用的控制系统工具，可以实现在一批机器跑某个脚本，做部署、初始化、版本检测、漏洞扫描等等，有良好的并发/单台执行控制。
43.图1为本技术实施例提供的一种测试环境部署方法的流程图，测试环境指的是多个物理机组成的大的集群环境，该方法可以由测试环境中的任一个物理机执行，只要该物理机能与产品库管理系统和测试环境中的其它物理机进行通信即可，该方法具体包括以下步骤：
44.步骤s102，检测scm版本控制库中是否存在待测试的版本。
45.上述scm版本控制库是一个产品库管理系统，研发人员在开发出一个新的版本后，都会通过上述系统上传其版本包。本实施例首先检测上述scm版本控制库中是否存在待测试的版本，其检测方式有多种，比如，直接通过轮训查看scm版本控制库，或者轮训查看git提交记录，在此不做具体限定。
46.步骤s104，如果存在待测试的版本，获取测试环境中物理机的可用资源信息。
47.测试环境中的各个物理机上可能运行着不同数量的虚拟机，虚拟机会占用一定的内存，上述测试环境中的物理机的可用资源信息，也就是各个物理机当前还剩余的cpu内存信息。
48.步骤s106，根据测试环境中物理机的可用资源信息，确定部署版本的测试环境所需的目标物理机。
49.在获取到上述物理机的可用资源信息后，可以进一步确定出部署该待测试的版本所需要的目标物理机，可以选取可用资源较多的一个或多个物理机，也可以在不同的物理机集群中分别进行选择，在此不做具体限定。
50.步骤s108，将版本对应的测试代码部署于目标物理机和指定物理机中；指定物理机为控制节点，目标物理机为计算节点。
51.上述确定出的目标物理机实际为计算节点，而测试环境中本身有几台物理机是当作控制节点的，因此，最终需要将待测试的版本对应的测试代码部署于各个物理机中，包括用作计算节点的目标物理机和用作控制节点的指定物理机。
52.本技术实施例提供的测试环境部署方法中，可以通过对scm版本控制库中的版本进行自动检测，并在检测到待测试的版本后，自动获取测试环境中物理机的可用资源信息，并根据测试环境中物理机的可用资源信息，确定部署该版本所需的目标物理机；然后将版本对应的测试代码部署于目标物理机和指定物理机中，本技术实施例能够实现版本的自动化部署，提升版本的测试环境的部署效率，从而提高后续的版本测试效率。
53.上述检测scm版本控制库中是否存在待测试的版本的步骤，可以包括以下两种检测方式：
54.(1)轮训查看scm版本控制库；判断scm版本控制库中是否存在符合预设命名规则的新文件；如果是，确定scm版本控制库中存在待测试的版本。
55.(2)轮训查看git提交记录；判断git提交记录中是否存在新的commit编号；如果是，确定scm版本控制库中存在待测试的版本。
56.为了提高部署的测试环境的稳定性和可靠性，在上述获取测试环境中物理机的可用资源信息的步骤之前，还可以包括以下步骤，如图2所示：
57.步骤s202，获取版本对应的测试代码在研发自测环境中的冒烟测试结果。
58.研发人员在开发出新的版本后，会首先在研发自测环境中进行冒烟测试，该冒烟测试过程通常由研发人员在他们自己的开发环境中部署新版本后去执行的，若新版本的冒烟测试结果为正常，则可允许将该新版本部署至测试环境。若冒烟测试结果中存在没有运行通过的事件，就需要返回重新执行步骤s102。
59.因此，在一种优选的实施方式中，在检测到scm版本控制库中存在待测试的版本后，首先获取该版本对应的测试代码在研发自测环境中的冒烟测试结果。
60.步骤s204，监控测试环境中物理机的运行信息。
61.其中，物理机的运行信息包括：运行于物理机上的各个服务组件，及各个服务组件分别对应的服务运行状态。
62.服务组件包括nova、glance、cinder、neutron以及底层libvirt、qemu-kvm等模块；上述各个服务组件的服务运行状态包括：nova-api、nova-scheduler、nova-compute、cinder-api、cinder-volume和glance-api等。当上述各服务运行状态全部运行正常时，才适合进行后续的版本部署过程。
63.步骤s206，如果冒烟测试结果和物理机的运行信息均正常，执行获取测试环境中物理机的可用资源信息的步骤。
64.在获取到版本对应的测试代码在研发自测环境中的冒烟测试结果和各物理机的运行信息后，判断这两个内容是否均正常，一旦有一个出现异常，就不适合进行后续的版本部署过程。
65.为了提高版本的测试环境的部署效率，需要根据测试环境的物理机的可用资源信息，确定部署版本所需的目标物理机，该过程可以通过以下方式实现：
66.将多个物理机按照其对应的可用资源信息进行排序；从最大可用资源信息对应的物理机开始，选取指定个数的物理机，作为部署版本所需的目标物理机。
67.每台物理机上或多或少都运行有虚拟机，虚拟机会占用一定的cpu内存，因此，物理机的可用资源信息也就是物理机的剩余内存大小，按照各个物理机的剩余内存大小进行实时排序，选择出剩余内存较大的指定个数的物理机作为部署该版本所需的目标物理机。
68.上述指定个数n可以根据自动化测试事件确定，比如，自动化测试事件较多，包含调度算法或并发测试，n需要设置的大一些，大于等于4，如果自动化测试事件很简单，只进行简单的开机操作，无虚拟机迁移等在多物理机之间的操作，则n可以为1。
69.由于在版本部署前，还需要检测上述目标物理机中是否存在正在运行的虚拟机；如果存在，将虚拟机迁移至除目标物理机之外的其它物理机上。因此，选择剩余内存大的物理机，其虚拟机的迁移效率会更快，从而也就可以提高版本部署效率。
70.在另一种实施方式中，测试环境中的多个物理机分为两个大的物理机集群，即：第一物理机集群和第二物理机集群，或者也可称为可用区a和可用区b。
71.上述根据测试环境的物理机的可用资源信息，确定部署版本所需的目标物理机的步骤，还可以通过以下方式实现：
72.对第一物理机集群和第二物理机集群中的物理机分别按照物理机的可用资源信息进行排序；根据排序结果，从第一物理机集群和第二物理机集群中分别选取指定个数的物理机作为部署版本所需的目标物理机。比如，从每个集群中分别选择可用资源较多的n/2个物理机，作为计算节点。这种方式可以防止某个可用区的物理机被过度使用而引起集群性能失衡。
73.另外，在确定出目标物理机后，还可以根据版本对应的测试事件涉及的机型，将目标物理机加入到标注有与机型对应标签的物理机集群中。
74.由于自动化测试事件涉及不同的机型，如本地盘和云盘主机(本地盘和云盘主机还可能区分多个小类型机型)，若要创建出本地盘和云盘主机，则需要物理机在ssd(solid state disk或solid state drive，固态硬盘/固态驱动器)和ebs(elasticblockstore，弹性块存储)对应标签的集群中。故要将目标物理机加入对应集群中，若对应集群上没有标签则要为该集群加上正确的集群标签。
75.上面选择的n个目标物理机为计算节点，是实际虚拟机运行所在节点，为虚拟机分配资源，而整个测试环境有三台固定物理机作为控制节点，作用是接收nova api并处理虚机调度相关请求，处理后发送请求给计算节点，类似于系统的核心处理器。因此，将版本对应的测试代码部署于目标物理机和指定物理机中的步骤，可以通过以下方式实现：
76.根据指定物理机的标识和目标物理机的标识，按照预设的部署脚本，将版本对应的测试代码部署于指定物理机和目标物理机对应的测试环境中。
77.上述部署脚本中包含有下载代码包，解压，编译，安装，重启服务等多个步骤，调用zeus部署平台的api，api中可传入部署脚本及部署对象(目标物理机和指定物理机的ip)，按照编写好的部署脚本去部署上述版本对应的测试代码至指定物理机对应的控制节点与目标物理机对应的计算节点上。
78.本技术实施例提供的测试环境部署方法，能够实现自动化版本部署，既减少了人为部署的重复性工作，规避了因测试环境部署而产生的无效bug，又合理分配利用了测试环境资源，实现各个版本的测试环境分开部署。
79.现有的测试环境部署及冒烟测试过程，通常分为两个人工操作的步骤，即人工测试环境部署相应版本之后，再进行人工的冒烟测试。比如，首先需要手动输入版本号、物理机ip及部署脚本，然后登录zeus平台去执行该部署脚本，以对测试环境中所选择的物理机进行测试代码的更新。在测试代码部署成功后，还需要登录jenkins平台选择对应待测试模
块(包含nova，glance，cinder，neutron以及底层libvirt，qemu-kvm等模块)的自动化工作模块去执行，进行冒烟测试。
80.上述测试环境部署及冒烟测试方案，依赖于人为手动执行，人工成本高，并且手动输入版本号及物理机ip存在错误的风险，增加了排查及纠正的无意义工作量。同时，将测试环境部署及冒烟测试分开成两部分工作进行，极易造成其它问题，比如，新版本部署后因未及时进行冒烟测试，而导致整个测试环境不可用,影响其他模块测试人员的测试工作。再者，目前测试环境仅为一套大环境，往往多个方向会同时使用，对测试结果可能互相影响，对资源要求高的情况下还需要人为去沟通协调独占几台物理机。
81.基于上述情况，本技术实施例还提供一种冒烟测试方法，参见图3所示的冒烟测试方法的流程图，该方法能够从测试环境部署到冒烟测试完全实现自动化，不需要人工干涉，该冒烟测试方法具体包括以下步骤：
82.步骤s302，根据测试环境部署方法，将待测试的版本对应的测试代码部署于目标物理机和指定物理机中；
83.步骤s304，根据版本对应的测试代码，选择jenkins上对应的服务组件进行冒烟测试。
84.为了能够顺利进行冒烟测试，上述根据版本对应的测试代码，选择jenkins上对应的服务组件进行冒烟测试的步骤之前，还包括以下步骤：
85.监控目标物理机和指定物理机的运行信息；如果运行信息正常，继续执行根据版本对应的测试代码，选择jenkins上对应的服务组件进行冒烟测试的步骤。即在上述版本的测试代码部署完成后，需要再次确保控制节点与计算节点上的各个服务状态正常，且无其他虚机的运行。确认环境符合预期后，则按照该版本的模块，选择jenkins上对应模块的自动化工作模块去执行，开始冒烟测试。
86.本技术实施例提供的冒烟测试方法，能够将版本部署与冒烟测试进行紧密结合，同时能基于测试环境资源使用情况，灵活调整每次各个模块新版本测试的集群规模，将一个大的测试环境有效划分成多个小的测试集群，使得多模块能并发进行测试而互不干扰。
87.本技术实施例的优点在于对云计算测试环境的自动化部署及冒烟测试给出一套流程化方案，灵活地解决了测试环境部署问题与各方向测试资源协调问题。既减少了人为部署的重复性工作，规避了因测试环境部署而产生的无效bug，又合理分配利用了测试环境资源，实现各个版本测试分开部署并行冒烟测试。极大提高了测试效率，节约了测试成本，且随着测试环境的变化，也可随时更改配置，可维护性强。
88.基于上述测试环境部署方法实施例，本技术实施例还提供一种测试环境部署装置，参见图4所示，该装置包括：
89.版本检测模块402，用于检测scm版本控制库中是否存在待测试的版本；物理机信息获取模块404，用于如果检测到待测试的版本，获取测试环境中物理机的可用资源信息；目标物理机确定模块406，用于根据测试环境中物理机的可用资源信息，确定部署版本的测试环境所需的目标物理机；测试环境部署模块408，用于将版本对应的测试代码部署于目标物理机和指定物理机中；指定物理机为控制节点，目标物理机为计算节点。
90.参见图5示出的另一种测试环境部署装置的结构框图，除了包括与上一实施例类似的版本检测模块502、物理机信息获取模块504、目标物理机确定模块506和测试环境部署
模块508外，还包括：信息监控模块510。
91.上述信息监控模块510用于：获取版本对应的测试代码在研发自测环境中的冒烟测试结果；监控测试环境中物理机的运行信息；其中，物理机的运行信息包括：运行于物理机上的各个服务组件，及各个服务组件分别对应的服务运行状态；如果冒烟测试结果和物理机的运行信息均正常，执行获取测试环境中物理机的可用资源信息的步骤。
92.在一种可能的实施方式中，上述版本检测模块502还用于：轮训查看scm版本控制库；判断scm版本控制库中是否存在符合预设命名规则的新文件；如果是，确定scm版本控制库中存在待测试的版本。
93.在一种可能的实施方式中，上述版本检测模块502还用于：轮训查看git提交记录；判断git提交记录中是否存在新的commit编号；如果是，确定scm版本控制库中存在待测试的版本。
94.在一种可能的实施方式中，上述目标物理机确定模块506还用于：将多个物理机按照其对应的可用资源信息进行排序；从最大可用资源信息对应的物理机开始，选取指定个数的物理机，作为部署版本的测试环境所需的目标物理机。
95.在一种可能的实施方式中，上述测试环境中包括第一物理机集群和第二物理机集群；上述目标物理机确定模块506还用于：对第一物理机集群和第二物理机集群中的物理机分别按照物理机的可用资源信息进行排序；根据排序结果，从第一物理机集群和第二物理机集群中分别选取指定个数的物理机作为部署版本的测试环境所需的目标物理机。
96.在一种可能的实施方式中，上述装置还包括：虚拟机迁移模块512，用于：检测目标物理机中是否存在正在运行的虚拟机；如果存在，将虚拟机迁移至除目标物理机之外的其它物理机上。
97.在一种可能的实施方式中，上述装置还包括：物理机分类模块514，用于根据版本对应的测试事件涉及的机型，将目标物理机加入到标注有与机型对应标签的物理机集群中。
98.在一种可能的实施方式中，上述测试环境部署模块508还用于，根据指定物理机的标识和目标物理机的标识，按照预设的部署脚本，将版本对应的测试代码部署于指定物理机和目标物理机对应的测试环境中。
99.本技术实施例提供的测试环境部署装置，其实现原理及产生的技术效果和前述测试环境部署方法实施例相同，为简要描述，测试环境部署装置的实施例部分未提及之处，可参考前述测试环境部署方法实施例中相应内容。
100.基于上述冒烟测试方法，本技术实施例还提供一种冒烟测试装置，参见图6所示，该装置包括：
101.测试环境部署模块602，用于根据第一实施例所述的测试环境部署方法，将待测试的版本对应的测试代码部署于目标物理机和指定物理机中；
102.冒烟测试模块604，用于根据版本对应的测试代码，选择jenkins上对应的服务组件进行冒烟测试。
103.在一种可能的实施方式中，上述冒烟测试模块604，还用于：监控目标物理机和指定物理机的运行信息；如果运行信息正常，继续执行根据版本对应的测试代码，选择jenkins上对应的服务组件进行冒烟测试的步骤。
104.本技术实施例提供的冒烟测试装置，其实现原理及产生的技术效果和前述冒烟测试方法实施例相同，为简要描述，冒烟测试装置的实施例部分未提及之处，可参考前述冒烟测试方法实施例中相应内容。
105.本技术实施例还提供了一种电子设备，如图7所示，为该电子设备的结构示意图，其中，该电子设备包括处理器71和存储器70，该存储器70存储有能够被该处理器71执行的计算机可执行指令，该处理器71执行该计算机可执行指令以实现上述测试环境部署方法或冒烟测试方法。
106.在图7示出的实施方式中，该电子设备还包括总线72和通信接口73，其中，处理器71、通信接口73和存储器70通过总线72连接。
107.其中，存储器70可能包含高速随机存取存储器(ram，random access memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口73(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。总线72可以是isa(industry standard architecture，工业标准体系结构)总线、pci(peripheral component interconnect，外设部件互连标准)总线或eisa(extended industry standard architecture，扩展工业标准结构)总线等。所述总线72可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
108.处理器71可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器71中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器71可以是通用处理器，包括中央处理器(central processing unit，简称cpu)、网络处理器(network processor，简称np)等；还可以是数字信号处理器(digital signal processor，简称dsp)、专用集成电路(application specific integrated circuit，简称asic)、现场可编程门阵列(field-programmable gate array，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本技术实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器71读取存储器中的信息，结合其硬件完成前述实施例的测试环境部署方法或冒烟测试方法的步骤。
109.本技术实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令在被处理器调用和执行时，该计算机可执行指令促使处理器实现上述测试环境部署方法或冒烟测试方法，具体实现可参见前述方法实施例，在此不再赘述。
110.本技术实施例所提供的测试环境部署及冒烟测试方法、装置和电子设备的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。
111.除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对步骤、数字表达式和数值并不限制本技术的范围。
112.所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
113.在本技术的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本技术和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本技术的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。
114.最后应说明的是：以上所述实施例，仅为本技术的具体实施方式，用以说明本技术的技术方案，而非对其限制，本技术的保护范围并不局限于此，尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本技术实施例技术方案的精神和范围，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应所述以权利要求的保护范围为准。