具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本说明书。但是本说明书能够以很多不同于在此描述的其它方式来实施,本领域技术人员可以在不违背本说明书内涵的情况下做类似推广,因此本说明书不受下面公开的具体实施的限制。
在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书一个或多个实施例范围的情况下,第一也可以被称为第二,类似地,第二也可以被称为第一。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
首先,对本说明书一个或多个实施例涉及的名词术语进行解释。
容器:容器就是将软件打包成标准化单元,以用于开发、交付和部署。
容器生命周期:容器从创建到删除的全过程。
容器项目模型:单个容器生命周期内的所有操作的组合。
项目场景:多个随机变化的容器项目模型及其配置数据结合后的长时间混合运行。
稳定性测试:测试***(如测试平台)在不同程度的环境下稳定运行的能力。通常包括功能长时间不断重复运行的稳定性,以及并发压力下功能运行稳定性。
混沌工程:是一种提高技术架构弹性能力的复杂技术手段。Chaos工程(即混沌工程)经过实验可以确保***的可用性。混沌工程旨在将故障扼杀在襁褓之中,也就是在故障造成中断之前将它们识别出来。通过主动制造故障,测试***在各种压力下的行为,识别并修复故障问题,避免造成严重后果。
模糊测试:模糊测试是一种软件测试技术,通常是自动或半自动的,涉及向计算机程序的输入提供无效、意外或随机数据。然后监测程序是否有异常,例如崩溃、内置代码断言失败或查找潜在的内存泄漏。
cpu:一般指中央处理器。中央处理器(central processing unit,简称cpu)作为计算机***的运算和控制核心,是信息处理、程序运行的最终执行单元。
memory:内存(memory)是计算机的重要部件之一,也称内存储器和主存储器,它用于暂时存放cpu中的运算数据,与硬盘等外部存储器交换的数据。
virtiofsd:同样在qemu仓库中:一种在guest之间共享文件***的方案。主要使用场景包括:在kata-container场景中替换9p,作为容器rootfs。
overlayfs:是一种堆叠文件***,它依赖并建立在其它的文件***之上(例如ext4fs和xfs等等),并不直接参与磁盘空间结构的划分,仅仅将原来底层文件***中不同的目录进行“合并”,然后向用户呈现,这也就是联合挂载技术。
devmapper:是一种从逻辑设备到物理设备的映射机制,在该机制下,用户能够很方便的根据自己的需要实现对存储资源的管理。
ip vlan:是linux内核提供的网卡虚拟化技术,能够从物理网卡虚拟出多个虚拟网卡。多个虚拟网卡有相同mac地址,但是有独立的IP。
eni trunking:它是正常的弹性网卡,方案中充当通信通道的角色。
Internet:因特网(Internet)是一组全球信息资源的总汇。
vpc:Virtual Private Cloud,简称VPC,中文全称:专用网络。
为了提升软件稳定性的测试工具包括混沌工程、模糊测试两种,其中,混沌工程是验证***稳定性和可用性的常用工具,它可以在整个***中在随机位置(包括容器)引发故障,检查服务是否具备抗失效能力并帮助维持***的健康运转。例如Kube-monkey可以快速验证构建的k8s服务是否健壮,是否可以弹性扩容,是否可以处理计划外的故障等。而模糊测试,也叫Fuzz测试,是一种挖掘软件安全漏洞、检测软件健壮性的测试,它通过向软件输入大量随机和非法的字段,观测被测试软件是否异常而实现。它能解决测试输入无法列举穷尽,人工测试考虑不全面等问题,基于反馈机制变异生成测试输入组合,提升测试覆盖率。它是软件测试、漏洞挖掘领域的最有效的手段之一。
但是,Kube-monkey测试的目标不是容器。它通过主动制造故障,可以提升k8s服务集群在各种压力下的稳定性。它主要针对k8s服务集群稳定性和可用性,测试服务集群故障处理和恢复能力,重点不在提升容器自身的稳定性。并且,传统的模糊测试与测试产品代码紧耦合,它通过大量随机和无效的输入增加测试覆盖,提升软件的质量。但是它在增加覆盖率的同时也引入大量无效测试,甚至测试数据过于庞大导致测试***。除此之外,它针对源码和二进制程序进行测试,测试数据的生成与软件编程语言强绑定,主要用于自动生成功能测试用例,很少用于构建复杂的项目场景测试。
由此可知,容器技术相关的稳定性测试方案较为欠缺,目前也没有商业化的机构提供能用于生产环境的稳定的容器产品,因此急需构建高效的容器稳定性测试方案,以提升容器技术稳定性用于生产环境。
在本说明书中,提供了一种容器测试方法。本说明书一个或者多个实施例同时涉及一种容器测试装置,一种计算设备,以及一种计算机可读存储介质,在下面的实施例中逐一进行详细说明。
参见图1,图1示出了根据本说明书一个实施例提供的一种容器测试***的架构示意图。
如图1所示,所述容器测试***包括项目模型库102、容器配置库104和线程池106,其中,
所述项目模型库102,被配置为基于项目信息构建多个包括至少一个操作的容器项目模型,并基于所述多个容器项目模型构建所述项目模型库102;
所述容器配置库104,被配置为根据预设配置规则,为所述项目模型库中的每个容器项目模型的每个操作配置对应的配置参数集合,并基于所述配置参数集合构建所述容器配置库104;
所述线程池106,被配置为确定测试线程,基于所述测试线程从所述项目模型库以及所述容器配置库中选择待运行容器项目模型以及所述待运行容器项目模型中每个操作对应的配置参数;且获取所述测试线程基于待运行容器项目模型以及所述待运行容器项目模型的每个操作对应的配置参数创建并运行容器的运行结果,基于所述运行结果对所述容器进行测试。
其中,项目包括但不限于数据处理项目(如数据查询项目、数据增加项目等)、资源处理项目(如支付项目、收款项目)等。具体的,项目可以根据实际应用进行设置,本说明书对此不做任何限定。
而操作包括但不限于创建操作、启动操作、删除操作、暂停操作、恢复操作、停止操作等等。容器项目模型则可以理解为由一个、两个或多个操作形成的容器项目模型。
举例说明,容器项目模型1为:create->start->stop->rm(创建操作-启动操作-停止操作-删除操作)。
容器项目模型2为:run->exec->restart->stats->pause->unpause->update->stop->rm(运行操作-执行操作-重启操作-查看容器操作-暂停操作-恢复操作-更新操作-删除操作)。
每个容器项目模型的每个操作对应的配置参数,可以理解为容器的cpu、内存等等。
具体实施时,首先根据规则构建项目模型库和容器配置库,其中,规则可以理解为根据项目的特征定义的规则,比如若该项目对应的某个容器项目模型使用的容器较小,则可以给该容器项目模型中的操作定义的少一些;若该项目对应的某个容器项目模型使用的容器较大,则可以给该容器项目模型中的操作定义的多一些等。具体的,规则的出发点就是测试尽量模拟真实的项目场景,确保测试的有效性,减少模糊测试引入的大量无效测试。基于这个原则,已上线的项目可以直接通过项目监测和日志提取对应的容器项目模型和每个容器项目模型中每个操作的配置参数集,以构建项目模型库和容器配置库;若是新项目,则通过产品的需求和接口文档,结合项目实际需求(不同项目侧重点不一样:譬如容器cpu与memory比例2:1,最大规格不超过16核,存储方案采用virtiofsd等类似的项目限制)定义规则。
其次,基于通过上述方式构建的项目模型库和容器配置库,测试***根据硬件的资源(如cpu与memory)等动态确定并发测试线程池的大小,测试线程池中的每个测试线程随机从项目模型库和容器配置库,选择容器项目模型和每个容器项目模型中每个操作的配置参数创建并运行容器,模拟多个容器并发运行的真实项目场景,测试运行过程中,容器配置不断随机变化,测试线程也随机操作单个或多个容器,随着生命周期的结束,测试线程随机的创建以及运行不同类型的容器,实现对容器的稳定性测试。
本说明书实施例的容器测试***开创性的将模糊测试的思想用于***稳定性测试,提供通用的容器稳定性测试方案。一方面通过动态随机生成的容器项目模型和配置参数的组合模拟持续变化的容器项目,在此基础上利用线程池构建大量差异化配置的容器并发运行的复杂项目场景,增加测试覆盖从而提升产品稳定性;另一方面测试定义规则限定合理的容器项目场景和配置数据组合,使得测试跟真实项目场景接近,避免常规模糊测试生成大量无效测试,更重要的是防止无穷尽的测试组合导致测试***;最后测试对象从底层软件源码或者二进制转变为更上层的项目场景,这使得测试的实现仅依赖于通用的容器功能接口,支持任意编程语言的容器产品,适用于开源和闭源软件,解决常规模糊测试对被测对象代码和编程语言的强依赖,部分模糊测试只支持开源软件等技术问题。
参见图2,图2示出了根据本说明书一个实施例提供的一种容器测试方法的流程图,所述容器测试方法应用于测试平台,具体包括以下步骤。
步骤202:基于项目信息构建多个包括至少一个操作的容器项目模型。
其中,项目、操作以及容器项目模型的详细解释可以参见上述实施例,在此不再赘述。
具体的,项目信息包括但不限于已上线的项目的项目请求、项目监测和日志等信息,未上线的项目的产品需求文档和接口文档等信息。
因此,对于容器项目模型的构建,一种方法的具体实现方式如下所述:
所述基于项目信息构建多个包括至少一个操作的容器项目模型,包括:
确定项目的项目状态,在所述项目状态为运行状态的情况下,基于所述项目的运行信息构建多个初始容器项目模型,并确定每个初始容器项目模型包括的操作;
将操作相同的初始容器项目模型进行聚合,以获得包括至少一个操作的容器项目模型。
其中,运行状态可以理解为已上线状态,即项目可以开始运行,可以基于接收的项目处理请求进行项目操作等。
此时,项目的运行信息则可以理解为项目在运行过程中的项目请求、项目监测以及产生的项目日志等信息。
具体的,在项目状态为运行状态的情况下,可以基于项目的运行信息构建多个初始容器项目模型,比如项目的运行信息为数据查询请求,那么该初始容器项目模型可以为:创建-查询-删除。
在确定了多个初始容器项目模型之后,获得每个初始容器项目模型包括的操作,将操作相同的初始容器项目模型进行聚合,以获得最终的包括至少一个操作的容器项目模型。
例如初始容器项目模型1为:创建-查询-删除,初始容器项目模型2为:创建-查询-更新-删除,初始容器项目模型3为:创建-查询-删除,可以确定初始容器项目模型1和初始容器项目模型3的操作相同,则将初始容器项目模型1和初始容器项目模型3进行聚合(如删除初始容器项目模型3),获得最终的包括至少一个操作的容器项目模型:初始容器项目模型1和初始容器项目模型2。
本说明书实施例中,为了考虑测试效率的问题,可以将操作相同的容器项目模型进行合并,仅保留最精简的有效的又接近真实的容器项目模型。此外,为了丰富后续的项目场景,还可以基于项目的产品需求对初始容器项目模型做合理扩展,用于随机生成后续很多的项目场景,提高容器测试准确性。
另一种方法的具体实现方式如下所述:
所述基于项目信息构建多个包括至少一个操作的容器项目模型,包括:
确定项目的项目状态,在所述项目状态为待运行状态的情况下,基于所述项目的项目文档信息通过预设构建规则构建多个包括至少一个操作的容器项目模型。
其中,待运行状态可以理解为未上线状态,即项目仅做除了产品需求文档或者设计文档等,还没有开始上线运行。
此时,项目的项目文档信息则可以理解为项目设计时的产品需求文档和接口文档等。
具体的,在项目状态为待运行状态的情况下,可以基于项目的项目文档信息通过预设构建规则构建多个包括至少一个操作初始容器项目模型;其中,预设构建规则可以根据实际应用进行设置,本说明书对此不做任何限定,例如可以根据产品需求文档和接口文档中的项目实现功能设置。
本说明书实施例中,在项目为未上线状态的情况下,没有现成的项目流量作为参考,则需要基于项目的产品需求文档和接口文档,提供自定义规则构建容器项目模型,以便后续可以基于容器项目模型和配置数据构建项目场景,实现对容器的稳定性测试。
参见图3,图3示出了根据本说明书一个实施例提供的一种容器测试方法中容器项目模型的构建示意图。
如图3所示,具体包括镜像、已创建、运行中、已删除、已暂停、已退出等状态,其中,创建容器之前去公共镜像仓库或者用户镜像仓库拉取所需镜像,然后就可以通过不同的容器项目模型以及每个容器项目模型中的每个操作的配置参数来创建以及运行容器,实现对容器的测试。
图3中的创建、运行、启动、删除、强制删除、暂停、恢复、停止/杀掉、容器进程退出/服务挂掉、查看进程、查看容器、执行、重启、更新以及重命名等均可以理解为容器的操作。实际应用中,多个操作可以构建一个容器项目模型,例如容器项目模型为:创建-启动-停止-删除等。具体的,每个容器项目模型中的每个操作对应一个操作状态。
容器从创建到删除的完整过程就是容器的生命周期,在这个过程中不同的容器操作会改变容器的状态,同时不同状态的容器只能做指定的容器操作,在容器的整个生命周期中间所有容器操作的集合就是容器生命的路径(即容器项目模型),也是容器在真实项目场景的体现。基于图3以及根据产品需求测试定义的规则(譬如容器longtime运行,不同状态的容器只能做正常操作,cpu资源配置不超过32核等规则)以及随机生成容器生命周期的路径,用于测试模拟单个容器在真实项目场景的表现。
步骤204:根据预设配置规则为每个容器项目模型中的每个操作配置对应的配置参数集合。
其中,预设配置规则可以根据实际应用进行设置,本说明书实施例对此不做任何限定。例如在项目状态为运行状态的情况下,可以根据项目的历史运行参数为每个容器项目模型中的每个操作配置对应的配置参数集合。
具体的,所述根据预设配置规则为每个容器项目模型中的每个操作配置对应的配置参数集合,包括:
根据所述项目的历史运行参数通过等价类划分和功能点正交的方式,为所述每个容器项目模型中的每个操作配置对应的多组配置参数,并基于所述多组配置参数形成配置参数集合。
其中,历史运行参数包括但不限于处理任意一个项目功能(如数据查询功能或者数据更新功能等)耗费的cpu和内存占用等参数。
具体的,可以根据项目的历史运行参数通过等价类划分和功能点正交的方式,为每个容器项目模型中的每个操作配置对应多组配置参数,并将每个操作对应的多组配置参数形成该操作对应的配置参数集合。即每个容器项目模型中的每个操作可以对应多组配置参数,在实际应用中,项目场景构建时,每个容器项目模型中的每个操作的配置参数不同,就可以构建一个不同的项目场景。
具体实施时,容器项目模型中每个容器操作都有对应配置参数,数据无法穷举,本说明书实施例中,通过等价类划分和功能点正交的方式,既可以保证测试覆盖,又可以将测试控制在有效的测试范围之内。
按照等价类划分的资源配置与功能点进行正交,最终可以生成大量不同类型不同配置的容器项目模型中的每个操作的参数组合,用于后续容器创建。其中,资源配置包括有效值、边界值、无效值;功能点包括:存储方案、网络方案、启动类型、网络访问。具体参见表1。
表1
资源配置 |
存储方案 |
网络方案 |
启动类型 |
网络访问 |
有效值 |
overlayfs |
网卡直通 |
冷启动 |
internet |
边界值 |
devmapper |
ipvlan |
温启动 |
vpc |
无效值 |
virtiofs |
enitrunking |
热启动 |
Internet+vpc |
本说明书实施例中,可以根据项目的历史运行参数通过等价类划分以及功能点正交的方式,为每个容器项目模型中的每个操作配置合适的多组配置参数,以提高后续项目场景的有效性。
另一种情况下,在项目状态为待运行状态的情况下,项目不存在历史运行参数,则可以基于测试平台的配置参数为每个容器项目模型中的每个操作配置对应的配置参数集合。具体实现方式如下所述:
所述根据预设配置规则为每个容器项目模型中的每个操作配置对应的配置参数集合,包括:
基于所述测试平台的配置参数通过等价类划分和功能点正交的方式,为所述每个容器项目模型中的每个操作配置对应的多组配置参数,并基于所述多组配置参数形成配置参数集合。
其中,测试平台可以理解为一台测试机器,那么测试平台的配置参数可以理解为测试机器的cpu和内存空间。
实际应用中,测试平台在进行容器测试时,测试平台的所有测试线程运行的容器的资源不能超过测试平台的资源,因此在为每个容器项目模型中每个操作配置参数时,要考虑到测试平台的配置参数,以避免后续测试平台的测试线程在运行容器时造成测试***。
具体的,在项目不存在历史运行参数的情况下,可以基于测试平台的配置参数通过等价类划分和功能点正交的方式,为每个容器项目模型中的每个操作配置对应的多组配置参数,以保证后续测试平台的测试线程对容器测试的稳定性。
步骤206:确定测试线程从所述多个容器项目模型以及所述配置参数集合中,选择的待运行容器项目模型以及所述待运行容器项目模型中的每个操作对应的配置参数。
实际应用中,测试线程可以是基于测试平台的配置参数确定的,也可以是人为预先设置的;以测试线程基于测试平台的配置参数确定进行说明,其具体实现方式如下所述:
所述确定测试线程从所述多个容器项目模型以及所述配置参数集合中,选择的待运行容器项目模型以及所述待运行容器项目模型中的每个操作对应的配置参数,包括:
基于所述测试平台的配置参数确定至少一个测试线程;
确定每个测试线程从所述多个容器项目模型以及所述配置参数集合中,选择的待运行容器项目模型以及所述待运行容器项目模型中的每个操作对应的配置参数。
其中,测试平台的配置参数可以参见上述实施例的介绍,在此不再赘述。
具体的,可以根据测试平台的硬件资源(如cpu和内存)等动态的确定测试线程的数量,然后将确定出的测试线程放置在构建的线程池中,便于后续应用。
而在确定测试线程之后,每个测试线程会随机的从多个容器项目模型以及所述配置参数集合中,选择待运行容器项目模型以及所述待运行容器项目模型中的每个操作对应的配置参数,模拟多个容器并发的真实项目场景,实现对容器的测试。
本说明书实施例中,具体测试时,可以根据测试平台的硬件资源合理的确定测试线程的数量,以保证后续可以基于该测试线程实现对容器的稳定性进行测试。
另一种情况下,所述确定测试线程从所述多个容器项目模型以及所述配置参数集合中,选择的待运行容器项目模型以及所述待运行容器项目模型中的每个操作对应的配置参数,包括:
基于预设配置规则确定至少一个测试线程;
确定每个测试线程从所述多个容器项目模型以及所述配置参数集合中,选择的待运行容器项目模型以及所述待运行容器项目模型中的每个操作对应的配置参数。
其中,预设配置规则可以根据实际应用进行设置,本说明书对此不做任何限定,例如预设配置规则为根据容器项目模型的数量确定测试线程等或者是项目的真实运行场景。
以预设配置规则为项目的真实运行场景为例,若项目的真实运行场景通常会有30个容器同时运行,那么则可以设置30个测试线程,但是基于测试平台的硬件资源去设置30个测试线程对应的容器的资源,30个容器在测试运行过程中的总消耗的资源不能超过测试平台的硬件资源。各个用户可以根据自己的实际情况设置测试线程的数量,可以是10个或者200个,具体根据项目情况本身设定,容器并发数量多,那么单个容器的资源肯定就小,而若有大的容器运行,则可以通过多个测试线程并发执行一个容器。
具体实施时,每个测试线程只操作一个容器是最基础的场景,还有一种场景是先创建30个容器,然后各个测试线程对30个容器中任意容器操作,模拟多个测试线程操作同一个容器或者单个线程操作多个容器的场景。
本说明书实施例中,通过线程池中的测试线程可以模拟多个容器在同一台机器上运行的项目场景,随机的容器项目模型和配置参数的并发合并会自动生成尽量多的项目场景,甚至一些不太容易构造的冲突和极端的情况,在测试的过程中,可以发现更多的问题,实现更全面的容器测试。
步骤208:获取所述测试线程基于待运行容器项目模型以及所述待运行容器项目模型的每个操作对应的配置参数创建并运行容器的运行结果,基于所述运行结果对所述容器进行测试。
具体的,每个测试线程在选择于待运行容器项目模型以及所述待运行容器项目模型的每个操作对应的配置参数后,创建并运行容器。测试平台可以基于每个容器的运行结果对容器进行测试。
所述基于所述运行结果对所述容器进行测试,包括:
基于所述运行结果确定所述容器的结束状态,以及获取所述容器对应的容器项目模型的目标操作;
基于所述结束状态与所述目标操作的对应关系,对所述容器进行测试。
其中,容器的结束状态可以理解为容器执行对应的容器项目模型中的操作之后返回的状态,例如暂停状态或者删除状态等。
容器对应的容器项目模型的目标操作可以理解为容器项目模型的最后一个操作,例如容器项目模型为:创建-更新-暂停,那么目标操作则为暂停操作。
实际应用中,如果容器运行后的状态符合预期(如暂停容器后,容器的结束状态为暂停状态),则可以确定容器测试通过。
在一种可实现方式中,还可以根据容器运行后的配置参数对容器进行测试,例如:
所述基于所述运行结果对所述容器进行测试,包括:
基于所述运行结果确定所述容器的运行参数,以及获取所述容器对应的所述待运行容器项目模型中每个操作对应的配置参数;
将所述运行参数和所述配置参数进行比对,基于比对结果对所述容器进行测试。
其中,运行参数可以理解为容器基于容器项目模型以及对应的配置参数运行之后获得的参数。
具体的,若容器的配置参数与运行参数一致,则说明容器的状态稳定。若容器的配置参数与运行参数不一致,则说明容器在运行的过程中出现了某些问题,则可以确定该容器的性能不稳定。
本说明书实施例中,通过判断容器的运行参数是否与配置参数一致的方式,可以快速的确定容器状态是否正常。
具体实施时,测试线程会根据预先设置的循环次数一直运行,每次循环每个测试线程均会从项目模型库和容器配置库中,选择容器项目模型以及每个容器项目模型中的每个操作的配置参数,创建并运行容器。具体的,若容器项目模型的第一个操作是创建,这个时候创建容器,后面根据选择的容器项目模型执行容器的其他操作(例如重启、暂停、执行命令、查看容器状态等),最后删除容器,进入下一轮循环,直至循环次数结束。具体的循环测试方式如下所述:
所述确定测试线程从所述多个容器项目模型以及所述配置参数集合中,选择的待运行容器项目模型以及所述待运行容器项目模型中的每个操作对应的配置参数之后,还包括:
确定所述测试线程从所述项目模型库以及所述配置参数集合中,选择的待运行容器项目模型以及所述待运行容器项目模型中的每个操作对应的配置参数的选择次数;
判断所述选择次数是否大于预设次数阈值,
若是,则将所述测试平台运行前的配置参数和运行后的配置参数进行比对,基于比对结果对所述容器进行测试,
若否,则获取所述测试线程基于选择的容器项目模型以及所述容器项目模型的每个操作对应的配置参数创建并运行容器的运行结果,基于所述运行结果对所述容器进行测试。
其中,选择次数可以根据实际应用进行设置,例如设置10次或者20次等。
实际应用中,测试线程会根据预先设置的循环次数一直运行,每次循环每个测试线程均会从项目模型库和容器配置库中,选择容器项目模型以及每个容器项目模型中的每个操作的配置参数,创建并运行容器。具体的,若容器项目模型的第一个操作是创建,这个时候创建容器,后面根据选择的容器项目模型执行容器的其他操作(例如重启、暂停、执行命令、查看容器状态等),最后删除容器,进入下一轮循环,直至循环次数结束。并且循环里面每一个步骤都会检查容器操作是否符合预期(如暂停容器后,容器的状态是否为暂停状态),以判断容器状态是否正常。整体的循环结束后检查整个测试平台的资源(cpu和内存等)是否正确回收,有没有容器进程、cgroup(控制组群,contro l groups)等资源残留,如果这些都正常,测试过程也没有出错,测试就算通过。
本说明书实施例提供的所述容器测试方法通过随机生成的容器项目模型和配置参数的组合,模拟持续变化的容器项目,并且利用测试线程构建大量差异化配置的容器并发运行的复杂项目场景,增加测试覆盖从而提升容器稳定性。
此外,所述容器测试方法将模糊测试与测试产品代码解耦,应用于项目场景测试,一方面继承模糊测试有效发掘问题的能力来提升容器产品稳定性,另一方面提升模糊测试通用性,支持各种类型(不同变成语言,开源和闭源)的容器产品。并且可以基于规则定义项目模型库和容器配置库,使得测试接近真实项目场景,避免大量无效测试,从而提升测试有效性。
与上述方法实施例相对应,本说明书还提供了容器测试装置实施例,图4示出了本说明书一个实施例提供的一种容器测试装置的结构示意图。如图4所示,该装置包括:
模型构建模块402,被配置为基于项目信息构建多个包括至少一个操作的容器项目模型;
参数构建模块404,被配置为根据预设配置规则为每个容器项目模型中的每个操作配置对应的配置参数集合;
场景构建模块406,被配置为确定测试线程从所述多个容器项目模型以及所述配置参数集合中,选择的待运行容器项目模型以及所述待运行容器项目模型中的每个操作对应的配置参数;
测试模块408,被配置为获取所述测试线程基于选择的容器项目模型以及所述容器项目模型的每个操作对应的配置参数创建并运行容器的运行结果,基于所述运行结果对所述容器进行测试。
可选地,所述模型构建模块402,进一步被配置为:
确定项目的项目状态,在所述项目状态为运行状态的情况下,基于所述项目的运行信息构建多个初始容器项目模型,并确定每个初始容器项目模型包括的操作;
将操作相同的初始容器项目模型进行聚合,以获得包括至少一个操作的容器项目模型。
可选地,所述模型构建模块402,进一步被配置为:
确定项目的项目状态,在所述项目状态为待运行状态的情况下,基于所述项目的项目文档信息通过预设构建规则构建多个包括至少一个操作的容器项目模型。
可选地,所述参数构建模块404,进一步被配置为:
根据所述项目的历史运行参数通过等价类划分和功能点正交的方式,为所述每个容器项目模型中的每个操作配置对应的多组配置参数,并基于所述多组配置参数形成配置参数集合。
可选地,所述参数构建模块404,进一步被配置为:
基于所述测试平台的配置参数通过等价类划分和功能点正交的方式,为所述每个容器项目模型中的每个操作配置对应的多组配置参数,并基于所述多组配置参数形成配置参数集合。
可选地,所述场景构建模块406,进一步被配置为:
基于所述测试平台的配置参数确定至少一个测试线程;
确定每个测试线程从所述多个容器项目模型以及所述配置参数集合中,选择的待运行容器项目模型以及所述待运行容器项目模型中的每个操作对应的配置参数。
可选地,所述场景构建模块406,进一步被配置为:
基于预设配置规则确定至少一个测试线程;
确定每个测试线程从所述多个容器项目模型以及所述配置参数集合中,选择的待运行容器项目模型以及所述待运行容器项目模型中的每个操作对应的配置参数。
可选地,所述测试模块408,进一步被配置为:
基于所述运行结果确定所述容器的结束状态,以及获取所述容器对应的容器项目模型的目标操作;
基于所述结束状态与所述目标操作的对应关系,对所述容器进行测试。
可选地,所述装置,还包括:
循环模块,被配置为:
确定所述测试线程从所述项目模型库以及所述配置参数集合中,选择的待运行容器项目模型以及所述待运行容器项目模型中的每个操作对应的配置参数的选择次数;
判断所述选择次数是否大于预设次数阈值,
若是,则将所述测试平台运行前的配置参数和运行后的配置参数进行比对,基于比对结果对所述容器进行测试,
若否,则获取所述测试线程基于选择的容器项目模型以及所述容器项目模型的每个操作对应的配置参数创建并运行容器的运行结果,基于所述运行结果对所述容器进行测试。
本说明书实施例提供的所述容器测试装置通过随机生成的容器项目模型和配置参数的组合,模拟持续变化的容器项目,并且利用测试线程构建大量差异化配置的容器并发运行的复杂项目场景,增加测试覆盖从而提升容器稳定性。
上述为本实施例的一种容器测试装置的示意性方案。需要说明的是,该容器测试装置的技术方案与上述的容器测试方法的技术方案属于同一构思,容器测试装置的技术方案未详细描述的细节内容,均可以参见上述容器测试方法的技术方案的描述。
图5示出了根据本说明书一个实施例提供的一种计算设备500的结构框图。该计算设备500的部件包括但不限于存储器510和处理器520。处理器520与存储器510通过总线530相连接,数据库550用于保存数据。
计算设备500还包括接入设备540,接入设备540使得计算设备500能够经由一个或多个网络560通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备540可以包括有线或无线的任何类型的网络接口(例如,网络接口卡(NIC))中的一个或多个,诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口,等等。
在本说明书的一个实施例中,计算设备500的上述部件以及图5中未示出的其他部件也可以彼此相连接,例如通过总线。应当理解,图5所示的计算设备结构框图仅仅是出于示例的目的,而不是对本说明书范围的限制。本领域技术人员可以根据需要,增添或替换其他部件。
计算设备500可以是任何类型的静止或移动计算设备,包括移动计算机或移动计算设备(例如,平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如,智能手机)、可佩戴的计算设备(例如,智能手表、智能眼镜等)或其他类型的移动设备,或者诸如台式计算机或PC的静止计算设备。计算设备500还可以是移动式或静止式的服务器。
其中,处理器520用于执行如下计算机可执行指令,该计算机可执行指令被处理器执行时实现上述容器测试方法的步骤。
上述为本实施例的一种计算设备的示意性方案。需要说明的是,该计算设备的技术方案与上述的容器测试方法的技术方案属于同一构思,计算设备的技术方案未详细描述的细节内容,均可以参见上述容器测试方法的技术方案的描述。
本说明书一实施例还提供一种计算机可读存储介质,其存储有计算机指令,该计算机可执行指令被处理器执行时实现上述容器测试方法的步骤。
上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是,该存储介质的技术方案与上述的容器测试方法的技术方案属于同一构思,存储介质的技术方案未详细描述的细节内容,均可以参见上述容器测试方法的技术方案的描述。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
所述计算机指令包括计算机程序代码,所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括:能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM,Read-Only memory)、随机存取存储器(RAM,RandomAccess memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是,所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减,例如在某些司法管辖区,根据立法和专利实践,计算机可读介质不包括电载波信号和电信信号。
需要说明的是,对于前述的各方法实施例,为了简便描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本说明书实施例并不受所描述的动作顺序的限制,因为依据本说明书实施例,某些步骤可以采用其它顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定都是本说明书实施例所必须的。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其它实施例的相关描述。
以上公开的本说明书优选实施例只是用于帮助阐述本说明书。可选实施例并没有详尽叙述所有的细节,也不限制该发明仅为所述的具体实施方式。显然,根据本说明书实施例的内容,可作很多的修改和变化。本说明书选取并具体描述这些实施例,是为了更好地解释本说明书实施例的原理和实际应用,从而使所属技术领域技术人员能很好地理解和利用本说明书。本说明书仅受权利要求书及其全部范围和等效物的限制。