发明内容
本申请实施例提供了一种测试用例的处理方法及服务器来解决目前人工编写测试用例以及自动生成的测试用例无法满足可靠性测试需求的问题。
本申请实施例的第一方面提供一种测试用例的处理方法,该方法可包括,首先接收总控制台发送的描述文件,该描述文件用于描述一个或者一组测试用例的结构化流程,因此可以从该描述文件确定出目标测试用例的测试操作以及这些测试操作的测试流程,接着,便可以调用测试库集合中对应所述测试操作的测试方法,对于测试库集合来说,其中存储有对应所述测试操作的测试方法;最后,即可根据所述测试流程和所述测试方法生成所述目标测试用例。
可以看出,由于可以直接根据描述文件中的结构化流程确定出相应需要哪些测试操作以及测试流程,从而可以根据这些测试操作以及测试流程生成相应的包含测试操作和测试流程的代码,完成测试用例的编写,对于测试操作,本申请实施例中设有测试库集合,在该测试库集合中存储了对应测试操作的一些测试方法,这些测试方法本质上是一些函数,本申请实施例能够通过调用测试方法实现测试操作,并通过测试流程实现测试操作之间的复杂流程,从而能够创建出具有分支和循环等复杂结构的测试用例,并且测试方法是可重用的测试方法,简化测试用例的开发流程的同时,提高测试用例的开发效率。
在一些实施例中,测试库集合实际可以包括故障库、业务库和监控库,这三种库在生成目标测试用例时,作用各有不同,具体的,故障测试方法均存储在故障库内,而对应被测系统的业务的接口则存储在业务库中,另外监控库可用于执行测试用例时,对被测系统进行监控;其中,测试操作包括库方法测试操作,而库方法测试操作包括故障测试操作,并且所述测试方法包括故障测试方法;所述故障测试操作对应所述故障测试方法;此时,所述调用测试库集合中对应所述测试操作的测试方法包括:根据所述描述文件确定故障模式,所述故障库中存储有不同的故障场景,每个故障场景对应至少一个故障模式;接着,根据所述故障模式从所述故障库中调用对应所述故障测试操作的故障测试方法,每个所述故障模式对应一种故障测试方法,所述故障库中存储的故障测试方法采用相同或者不同的计算机语言实现。可以看出,故障场景的划分可以是一个树状结构,即包含所有故障场景的根节点,细化的子场景作为分支节点,最后细分到叶子节点即故障模式,是一个可实例化的故障。从而能够增强本申请实施例方法的可实现性。
在一些实施例中,每个故障模式包括具有故障注入能力的故障注入接口和提供故障预期判断的故障预期接口,所述故障注入接口用于为所述故障模式提供可复用的故障注入方法,所述故障预期接口用于为所述故障模式提供故障预期判断逻辑的故障预期判断方法。即对于每个故障模式,在执行测试用例时,均需要调用故障注入接口注入故障,使得被测系统处于该故障状态,而后调用故障预期接口进行故障预期测试,首先监控该被测系统的一些信息,而后将这些信息与故障模式的故障预期的值进行比对,从而确定被测系统是否异常。从而能够增强本申请实施例方法的可实现性。
在一些实施例中,故障模式的故障预期的值可以是一些指标,该指标包括业务关键绩效指标KPI类指标和系统状态类指标,并且故障预期接口包括业务KPI类的故障预期接口和系统状态类的故障预期接口这两类;其中,业务KPI类的故障预期接口用于通过被测系统被注入所述故障时的业务受损值确定所述业务KPI类的故障预期,业务KPI类指标包括预设的业务受损阈值;而所述系统状态类的故障预期接口用于通过判断系统状态和系统行为是否符合预设的系统状态和系统行为确定所述系统状态类的故障预期,所述系统状态类指标包括预设的系统状态或系统行为。能够增强本申请实施例方法的可实现性。
在一些实施例中,生成目标测试用例的具体过程可以是生成一些代码并组成目标测试用例,具体的,创建以同步方式调用所述故障注入接口的第一代码;创建调用所述被测系统对应所述故障模式的业务功能的第二代码;创建以异步调用方式调用所述业务KPI类的故障预期接口的第三代码;和/或,创建以异步调用方式调用所述系统状态类的故障预期接口第四代码;创建通过调用监控库的监控接口监控所述故障模式的第五代码;最后,便可根据所述测试步骤和创建的所述第一代码、所述第二代码、和第五代码,以及所述第三代码段和/或第四代码段生成所述目标测试用例。可以看出,生成的目标测试用例可以有三种情况,第一种是仅测试业务KPI指标,第二种是仅测试系统状态类指标,第三种即可以同时测试业务KPI指标以及系统状态类指标。能够增强本申请实施例方法的可实现性。
在一些实施例中,该方法还包括两种情况,第一种,如果调用故障注入接口失败,则执行结束操作生成的代码,该结束操作用于结束代码创建,且该代码也属于目标测试用例中的代码;第二种,若以异步调用方式调用所述业务KPI类的故障预期接口或者所述系统状态类的故障预期接口,由于是异步调用,并且对于结束操作来说,需要等待这些操作完成才进行结束操作,因此该结束操作生成等待异步调用返回的代码,该代码也属于目标测试用例中的代码。能够增强本申请实施例方法的可实现性。
在一些实施例中,除了上述生成目标测试用例的过程之外,还可以执行该目标测试用例。
在一些实施例中,若目标测试用例包括故障测试操作时,则在执行目标测试用例时,首先会调用所述故障测试操作对应的故障模式的故障注入接口向所述被测系统注入所述故障模式;接着,在第一预设时间窗内每隔第一预设时长采集所述业务KPI指示的样本;并且会分析所述预设时间窗内采集的样本集合,生成所述故障模式业务KPI类的故障预期结果。即,对于故障测试操作,需要调用故障注入接口和故障预期接口两种接口来对目标测试用例进行执行,并生成故障预期结果。
在一些实施例中,分析所述预设时间窗内采集的样本集合,生成所述故障模式业务KPI类的故障预期结果的具体过程可以有三种情况,第一种,计算所述样本集合中样本的均值、极值和百分位数之中的至少一种,当所述均值、极值和百分位数之中的至少一种超出预设的均值阈值、极值阈值和百分位数阈值之中的至少一种时,均能够作为业务异常的判断基础类确定被测系统异常,因此,会生成故障预期结果;第二种,分析所述样本的波动,当所述样本的波动幅度大于预设波动幅度,能够作为业务异常的判断基础确定被测系统异常,并生成故障预期结果;第三种,分析所述样本的变化趋势,当所述变化趋势超出预设的变化趋势时,能够作为业务异常的判断基础确定被测系统异常,并生成故障预期结果。可以看出,三种方式单独均能确定被测系统是否异常,三种方式之间任意组合也能确定被测系统是否异常。从而能够增强本申请实施例的方法的可扩展性。
在一些实施例中,对故障模式中的除了业务KPI的故障预期还有系统状态类的故障预期,此时,在执行目标测试用例时,首先会调用所述故障测试操作对应的故障模式的故障注入接口向所述被测系统注入所述故障模式;接着,在第一时刻采集所述系统状态信息,所述第一时刻为从当前时刻起经过第二预设时间窗的时刻;采集完系统状态信息后,便可进行判断,具体的,当所述系统状态信息超出预设的系统状态及系统行为预期时,确定所述业务异常,并生成故障预期结果。从而能够增强本申请实施例的方法的可实现性。
在一些实施例中,对于库方法测试操作,调用测试库集合中对应所述测试操作的测试方法包括:首先从所述描述文件的结构化流程中提取库方法测试操作、入参信息和出参信息;接着通过函数调用的方式调用测试库集合中对应库方法测试操作的测试方法;在此情形下,生成目标测试用例的过程则可以是,根据所述测试流程并将所述入参信息和所述出参信息作为所述调用函数的参数信息生成所述目标测试用例。从而能够增强本申请实施例的方法的可实现性。
在一些实施例中,从所述描述文件的结构化流程中提取库方法、入参信息和出参信息的过程具体可以是,根据所述结构化流程确定所述库方法、所述库方法的循环次数、入参信息和出参信息;而通过函数调用的方式调用测试库集合中的库方法则可变为,根据所述库方法的循环次数生成对应所述循环次数的内部循环调用代码;接着,在生成目标测试用例时,便会出现生成代码的两种情况,第一种,当确定所述调用为同步调用时,创建在当前线程中等待调用结果返回的代码;第二种,当确定所述调用为异步调用时,根据所述异步调用中线程管理信息和信号处理信息生成用于异步调用的代码;最后,便可根据所述同步调用或所述异步调用生成的代码以及将所述入参信息和所述出参信息作为所述函数参数信息生成所述目标测试用例。从而能够增强本申请实施例的方法的可实现性。
在一些实施例中,除了对测试库集合中的一些测试操作,描述文件中本身也可以携带一些代码片段,这些代码片段也可以是一些测试操作,但是并非是测试库集合中能够进行重用的测试操作,对于代码片段,由于需要放入目标测试用例,因此,需要对该代码片段做一些处理,具体的,该方法还可包括,首先从描述文件获取代码片段,接着,检查该代码片段的语法,并对所述代码片段的语义进行分析;完成后,生成目标测试用例时,便会变为根据所述测试流程、所述代码段和所述代码测试方法生成所述目标测试用例,即在生成所需的信息中带有该代码片段。从而能够增强本申请实施例的方法的可扩展性。
在一些实施例中,根据所述描述文件确定所述测试操作的测试流程包括,确定所述测试操作的测试流程的流向,并生成测试流程的代码,所述流向包括正向和反向。正向流向表示该测试操作执行完成后,便进行后续一个测试操作,而流向为反向时,则一个测试操作完成后,可能返回至前一个或前几个测试操作,此方式可能构成循环操作。从而使得本申请实施例的方法能够支持复杂的测试流程,增强本申请实施例的方法的可实现性。
在一些实施例中,当测试操作的测试流程具有至少两个并列分支时,需要确定每个分支的流向,具体的,确定测试操作的流向可以是,确定所述测试操作的测试流程的每个分支的流向,并生成所述测试流程的每个分支的流向的代码。
在一些实施例中,对于整体流程来说,需要进行一些条件限定,例如,所有的流向均汇入同一测试操作,才能生成正确的测试用例,因此需要对流向汇入进行检测;具体检测过程可以是,首先获取测试流程的流向的信息,接着,当所述测试流程的每个流向均扇入至同一汇聚的测试操作时,创建测试流程的代码。创建此代码,则意味着所有的流向均流入同一测试操作。从而能够增强本申请实施例的可实现性。
在一些实施例中,如果出现调用测试库集合中对应所述测试操作的测试方法失败,或者一些测试流程中出现失败时,结束操作会返回测试用例生成失败信息,这些测试用例生成失败信息中会包含测试方法调用失败的信息,即包括是调用失败还是流程中流向不能汇入同一测试操作等的信息,便于开发者确定测试用例生成失败的情况。从而能够增强本申请实施例的可扩展性。
本申请第四方面提供了一种服务器,该服务器包括了用于执行第一方面或第一方面的任一种实现方式中提供的测试用例的处理方法的至少一个单元。
本申请又一方面提供了一种计算机可读存储介质,该存储介质中存储了程序代码,该程序代码被终端运行时,使得计算机执行上述各方面所述的方法。该存储介质包括但不限于快闪存储器(flash memory),硬盘(hard disk drive,简称HDD)或固态硬盘(solidstate drive,简称SSD)。
具体实施方式
本申请实施例提供了一种测试用例的处理方法及服务器来解决目前人工编写测试用例以及自动生成的测试用例无法满足可靠性测试需求的问题。
为了使本技术领域的人员更好地理解本申请方案,下面将结合本申请实施例中的附图,对本申请实施例进行描述。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外,术语“包括”或“具有”及其任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
可靠性测试作为确保软件质量的关键环节,随着软件的复杂度越来越高,变得越来越重要,尤其是在系统研发过程测试验收阶段,需要有丰富的测试用例来验证系统的质量,因此对可靠性测试用例编排的效率和质量提出了更高的要求。当前的测试用例主要采用人工编写程序代码的方式,因此,需要用例开发人员熟悉一种编程语言,并且能够根据业务场景的要求完成特定的测试用例的开发,并在此基础上完成测试用例本身的编译、调试和发布,最终能够供测试工具加载使用。
举例来说,请参阅图1,图1是一种开源自动化测试框架(robot framework)用例编辑系统的示意图,该系统基于可复用的测试方法进行测试用例编排,可以不需要掌握通用编程语言。如图1所示,上半部分一个测试用例的编写需要的流程,如包括文档(documentation)、计划(setup)、拆解(teardown)、超时(timeout)、模板(template)和标记(tags)这些部分,每个部分均需要开发人员进行手动编写代码;下半部分的表格代表拆解过程中的拆解的多个步骤按照串行化执行,表格中每一行表示拆解出的一个测试步骤,每个测试步骤给出操作方法和入参,表格完成后以文本化形式保存起来,由后台解释程序执行。例如表格第一行,即步骤1为打开浏览器(open browser),入参为firefox浏览器和网址“http://www.google.de”,该步骤即用firefox浏览器打开网址“http://www.google.de”;接着步骤2为选择窗口(select window),入参为“main”,该步骤即选择主窗口;步骤3,设置硒速度(set selenium speed),入参为2,即将该硒速度设置为2;步骤4,最大化窗口(maxmize window),即将选择的窗口进行最大化操作;步骤5,输入文本(input text),入参为“q”以及“codecentric GmBH”;步骤6,点击按钮(click button),入参为“btnG”;步骤7,页面应该包含(page should contain),入参为“codecentric GmBH”;步骤8,捕捉屏幕截图(capture screenshot)。从而完成一个测试用例的编写过程。以上步骤1至步骤8即为拆解流程中将一个测试用例拆解出的8个步骤。
然而,上述方式由于采用手工编程,一方面,用编程方法产生用例,需要可靠性测试人员有开发经验,掌握一种编程语言,由于用例编程本身属于代码开发,此过程容易引入错误,影响可靠性测试结果的评估;另一方面,人工编程方式创建用例,工作效率低;再一方面,编程方式产生的用例,只能根据文档或者注释来了解用例的意图,不容易维护。另外一种采用表格语言的方式,一方面,只能编写按顺序执行指定操作的简单测试用例,不支持包含分支、循环、并发等流程的复杂用例,无法满足可靠性测试需求;另一方面,用例只能以私有文本格式保存,并由专有解释程序执行,难以移植及复用。
对于复杂分布式软件系统的可靠性测试实施困难,测试用例编写及维护困难是主要原因有以下几个方面:
首先是技术门槛高。用例编写者不仅需要了解目标被测系统的功能及业务流程,还需要掌握诸如Python之类的通用编程语言,以及故障注入及故障预期分析等可靠性领域知识。其次是用例编写效率低下。现有技术编写测试用例效率很低,对于复杂的软件分布式系统而言,动辄成百上千的测试用例,需要花费大量时间。最后是用例管理维护困难。现有技术编写的测试用例风格不一,维护困难,且可复用性差。
可见,上述开源自动化测试框架由于采用手工编程以及表格语言,并不能很好的用在负载分布式软件系统的可靠测试用例的编写,不能解决复杂分布式软件系统的可靠性测试实施困难,测试用例编写及维护困难。
有鉴于复杂分布式软件系统的可靠性测试实施困难,测试用例编写及维护困难,本申请实施例给出了一种测试用例的处理方法,通过自动化的编写测试用例来解决上述困难。本申请实施例的可靠性测试用例(下面简称为测试用例)采用可靠性测试装置进行自动编写,具体架构可参阅图2,图2是本申请实施例的分布式软件系统的可靠性测试系统示意图,如图2所示,该系统中的可靠性测试装置可包括总控制台,用例生成器、用例执行器、测试监控器、测试库集合以及测试代理共五个逻辑实体。其中总控制台、用例生成器、用例执行器和测试监控器可以集中部署在单台物理服务器上,也可以分散部署到物理服务器集群。本申请实施例不对部署方式进行限定。其中,测试库监控模块能够连接到目标被测系统的节点,测试库集合则可以通过远程过程调用等技术与测试代理通信。
需要说明的是,基于性能及可靠性等工程化因素的考虑,用例执行器可以采用的多实例部署方式部署到专属的用例执行集群,以适应大规模并发测试的需要。测试库集合本质上是一组函数库集合,通常部署在用例生成器及用例执行器所在的物理服务器。测试代理部署到被测分布式系统的各个需求测试的物理节点上。
其中,总控台提供统一的测试控制入口。用户可以通过总控制台创建并执行测试用例,并通过测试监控模块观察测试过程,分析目标被测系统存在的可靠性问题。
测试库是一组可复用的测试方法集合,每个测试方法本质上一个函数或者几个函数的集合,是构建测试用例的基础单元,以不同的语言的代码被存储在测试库集合中。本申请实施例给出的可靠性测试装置中,测试用例构建在一组测试库上,称为测试库集合。测试库从语义上可以划分为三类:业务库、故障库和监控库。
业务库是被测系统业务功能可调用接口的组合,是启动被测系统业务流程的入口。例如,一个虚拟分布式存储系统,虚拟卷管理功能以卷操作测试库的形式给出,提供虚拟卷的创建、挂载、卸载、读写、删除等功能。
故障库是进行可靠性测试特有的测试库。可靠性工程化实践中积累了大量故障模式库,针对这些故障模式构建基于故障注入的测试用例,是可靠性测试的基本方法。当前故障模式库作为可靠性测试设计等活动的参考,无法做到可靠性测试能力代码级的传播和复用;而本申请实施例中的故障库是一种实例化的故障模式库,封装了针对这些故障模式的故障注入、故障监控以及故障预期判断方面的能力,是构建测试用例的关键。故障库基于故障分析、测试分析等负向分析方法积累的可靠性工程领域知识,对故障场景进行分类,例如进行基于树状结构的分类,每类故障场景下可以有若干故障模式,每个故障模式都提供故障注入能力、故障预期判断能力相关的可重用接口,以故障库的形式供测试用例脚本调用,来实现故障重现。
监控库则是用于获取被测系统的实时状态。测试用例调用监控库中的方法获取预设的某个或某组KPI指标的实时数据,配合故障库的故障预期判断能力,确定故障注入测试的结果。
通用库是常用的公共方法的组合,用于进一步提升一些能够共用的代码的复用能力。
本申请实施例的可靠性测试系统的具体执行过程是先由总控制台生成或者获取到具有结构化流程的描述的描述文件,具体的,可以是由总控制台提供某种结构化流程的编辑界面,用户采用该界面编辑并输出某个或某组测试用例的结构化流程描述文件,该文件被导入到用例生成器后,由用例生成器自动生成可执行的测试用例脚本或脚本集合;接着转到用例生成器,由用例生成器根据该描述文件中涉及的结构化流程生成测试用例,该测试用例的生成过程中,会根据被测系统的需求,从测试库集合中选取对应的不同的测试方法,这些测试方法以函数或者函数集合的方式体现,在具体执行时,需要链接到测试库结合并条用相应的函数或者函数集合实现这些测试方法;接着,在完成测试用例的生成后,便会由用例执行器进行测试用例的执行,用例执行器执行已经生成的可靠性测试用例脚本。在执行可靠测试用例时,测试库集合中的测试方法通过远程过程调用等技术与测试代理通信,由测试代理执行业务控制、故障注入及数据采集管理等操作;同时测试监控模块按照预设指标,并通过安装在目标被测系统的节点上的测试代理从目标被测系统收集并储存数据。测试代理是安装在目标被测系统的各节点上的逻辑实体,实现对目标系统的业务控制、故障注入以及指标数据采集等具体操作。对于故障类测试,可通过将采集的数据与故障预期的数据进行比较,即可确定目标被测系统在出现被测试的故障时,是否产生预期的效果,若不符合,则表明被测系统需要返回给被测系统的开发者对系统进行修改。对于代码片段以及一些库方法测试,若测试未通过,则返回给被测系统的开发者对系统进行修改。
需要说明的是,本申请实施例中的测试用例或者目标测试用例有多种类型,例如可各个不同格式的执行文件或者不同计算机语言的脚本,对于本申请实施例后续出现的测试用例脚本应视为测试用例的一种呈现类型。
下面对本申请实施例的测试用例的处理方法进行说明,请参阅图3和图4,图3是本申请实施例的可靠性测试系统中的用例生成器的架构示意图,图4是本申请实施例的测试用例的处理方法的一个实施例图。图3中,该用例生成器的输入是具有结构化流程的描述文件,该描述文件来自总控制台,输出则是生成的用于用例执行器执行的可执行用例脚本。该用例生成器包括解析器和转化器两部分;其中,解析器用于解析出描述文件中的结构化流程,该结构化流程包括如何进行测试,具有哪些测试步骤,哪些测试步骤之间是同步执行的,哪些是异步执行的,哪些是并发执行的等信息,解析器可以根据需要处理可扩展标记语言(extensible markup language,简称XML)、领域专用语言(domain specific language,简称DSL)和JS对象标记(JavaScript object notation,简称JSON)等格式的文件,或者还可以是定制的私有格式文件。转化器为结构化流程中的各种基本单元提供对应的处理插件,每个处理插件根据预定规则将基本单元转化为基于目标语言的可执行测试脚本,在常用的实施例中,目标语言通常为Python(一种面向对象的解释型计算机程序设计语言)。转化器具体可包括开始插件、步骤插件、流向插件、分支插件、并发插件和结束插件。当然,具体的划分方式并不限定于这些插件,只要能将结构化流程转换成可执行脚本即可。开始插件主要用于提取描述文件中的文本信息,并通过目标语言注释的方式生成用例描述代码,这些代码主要起到描述作用,在执行可执行脚本时,并不会运行这些代码。步骤插件则用于生成各种库方法测试、代码片段测试以及故障测试的代码;流向插件、分支插件和并发插件主要用于对步骤插件中产生的各步骤和流向对应到结构化流程;结束插件则用于生成一些清理代码,避免资源泄露,如果测试用例的生成过程中没有测试库集合中的测试方法调用失败,则返回测试用例脚本生成成功。
如图4所示,该方法可包括:
401、接收总控制台发送的描述文件。
其中,描述文件用于描述一个或者一组测试用例的结构化流程。该描述文件可以是直接从总控制台获取的,该描述文件可以是由用户在总控台的图像化界面上编写的,也可以是总控制台直接从其他设备或者网络获取的,该描述文件的文件格式有多种,例如XML、DSL以及JSON等格式均可。举例来说,请参阅图5,图5是一个测试用例结构化流程的图形化表达示意图,其中每个方框内的步骤即为一个测试操作,可以看出,该图5中,开始后,会并列执行四个分支,其中第一个分支具有三个测试操作,其余三个分支各一个测试操作,在所有分支均执行完毕后,会扇入到同一个测试操作执行,接着顺序执行后续的一个测试操作,完成后,最后执行后续的三个结束操作,以释放测试用例执行过程中所占用的资源。
402、根据所述描述文件确定目标测试用例的测试操作。
其中,测试操作包括库方法测试操作库方法测试操作即该操作所使用的测试方法均来至测试库集合。当然,测试操作除了是库方法测试操作之外,也可以是描述文件中携带的代码片段所对应的测试操作,当然该代码片段也不一定能够组成完整的测试操作,可以是生成的测试用例脚本中的其他内容。下面对库方法测试操作和代码片段分别进行说明:
对于描述文件中携带代码片段,本申请实施例的用例生成器在将该代码片段加入到目标测试用例之前,会对该代码片段进行检测和予以分析。例如,对被测代码片段进行语法检查以及一定的语义分析后,可以生成包含该代码片段的代码,该部分代码会出现在目标测试用例脚本中。其中,该语义分析可包括:检查代码片段中是否有变量和全局变量命名冲突,若是,则测试脚本自动创建失败,返回错误;检查代码片段是否引用了不可识别的全局变量,若是,测试脚本自动创建失败,返回错误;检查代码片段是否引用了结构化流程前序单元中,某异步调用的测试库方法的出参等,若是,则需要生成代码等待该方法调用返回。
对于库方法测试操作,主要针对一些测试库内的共用或者常用的测试操作,当然,对于不同的被测系统,共用或者常用的测试操作可以是不同的,当然库方法测试操作还可包括一些针对被测系统特有的测试操作。
需要说明的是,对于库方法测试操作,共用或者常用的测试操作,或者是针对被测系统特有的测试操作,一般仅需要抵用一个接口即可,而对于一些库方法测试操作中一些,例如故障测试操作,需要调用故障注入接口和故障预期接口才可实现。下面对故障测试操作进行说明。
请参阅图6,图6是本申请实施例的故障场景模块结构示意图;该故障场景模块用于故障注入以及故障预期分析能力。本申请实施例中的故障场景模块将故障场景归类成一个树状的结构,所有的故障作为根故障场景,各种不同的故障场景则作为子场景,例如资源类故障场景则为一个子场景,并且,每个子场景下还可以具有不同的子场景,直至细分到一个具体的可实例化的故障模式,例如内存泄露故障模式等。本申请实施例的故障场景模块可包括场景分析子模块,用于分析具体属于哪一个故障场景下的具体的故障模式;故障注入子模块,用于故障注入;故障预期子模块,用于进行故障预期分析;对于一个故障模式来说,可以具有对应的指标,这些指标都预设有对应的取值范围,这些指标按照衡量角度的不同可分为两种,一种是业务KPI类指标,该指标对应到业务受损的角度,通过将该指标作为对业务受损程度的故障预期来对被测系统进行故障测试,另一种是系统状态类指标,该指标对应到系统状态是否为预期系统状态的角度,通过对该指标作为预设的系统状态变化的故障预期来对被测系统进行故障测试,。该故障场景模块还连接到故障库,该故障库内存储有故障注入接口、业务KPI类的故障预期以及系统状态类的故障预期。该故障场景模块在执行具体的故障模式时,会从故障库中调用相应的故障注入接口、业务KPI类的故障预期以及系统状态类的故障预期。
403、根据所述描述文件确定所述测试方法的测试步骤。
其中,测试步骤即如图5中的各个分支即流向的步骤,当然,对于某一故障模式,可能调用的测试方法包括多个函数,那么这些函数之间的同步调用和异步调用均可以作为该测试步骤。其中,同步调用需要在当前线程中等待返回结果,否则便会使得执行该调用的线程挂起,同步调用的多个函数相互之间可以没有依赖关系。而异步调用则可以是不用立即返回结果,而是执行该异步调用的线程继续执行其他函数,直到该异步调用完成时,才会由该线程返回结果。当然,在有些情况下,一个函数需要引用或者将上一个函数的出参作为入参。可以看出,若具有多个分支时,共同汇入到后一个测试操作时,若该测试操作需要所有分支的执行结果作为入参进行执行,由于各分支的执行速度并不完全相同,且有的分支的测试操作会比较多,执行时长较长,因此会在该汇入的测试小左会出现等待的情况,等待所有的分支均完成再执行该测试操作。
具体的,对于测试操作的测试流程中的流向,通过图3中的流向插件进行处理,若流向为正向,则选择指向的流程基本单元,由对应的插件进行处理;若流向为反向,即指向一个前序的单元,则生成代码,将程序流程转入到流向所指的基本单元对应的代码。同时,若某个测试操作同时扇出多个步骤或分支,即有多个流向箭头,则交由图3中的并发插件进行处理。
对于测试操作的分支,通过图3中的分支插件进行处理,分支插件提取结构化流程中分支单元的二元判断逻辑,生成被测系统所支持的分支代码,并在每个分支交由图3中的流向插件处理。分支插件须对判断逻辑进行必要的语法分析,需要避免引入语法错误,该语法分析可参见代码片段测试操作中的语义分析过程。
对于并发过程的处理,通过图3中的并发插件从前序进行处理的流向插件处获取多个扇出的流向信息,进行如下处理:检查每个流向,确保所有流向最终扇入到同一个汇聚的步骤或分支单元(称为汇聚单元),若否,测试脚本自动创建失败,返回错误;对每个流向,在到达汇聚单元前,生成代码,单独创建一个线程,该流向的后续步骤或分支,交由对应的插件进行处理,并确保这些插件生成的代码在新线程中执行;处理汇聚单元前,生成代码,等待每个流向中所有步骤执行完成。注意,若流向中有异步调用,必须等待调用返回,若返回失败,则生成代码,将流程转向结束插件产生的代码;交由汇聚单元对应的插件处理汇聚单元,该汇聚单元可以是如图5中的各个分支汇合的测试操作。
404、调用测试库集合中对应所述测试操作的测试方法。
其中,所述测试库集合中存储有对应所述测试操作的测试方法。对于调用一个接口的库方法测试操作,步骤404具体可包括:
从所述描述文件的结构化流程中提取库方法测试操作、入参信息和出参信息。
其中,库方法测试操作对应的测试方法的出参自动作为用例脚本程序的全局变量,可以在结构化流程后续的基本单元使用。
通过函数调用的方式调用测试库集合中对应库方法测试操作的测试方法。
其中,在生成库方法测试用例时,是以函数调用的方式调用测试库集合中的对应库方法测试操作的测试方法来生成代码。
需要说明的是,对于库方法的调用,除了标准的函数调用语义之外,为了匹配可靠性测试的需要,还可以对调用次数和调用方法进行限定。其中,调用次数是该库方法能够执行的次数,在确定次数后,会自动生成指定次数的内部循环调用代码,实现方法的重复调用。该函数调用方式包括同步调用和异步调用两种,对于同步调用,在构建代码时,会在当前线程中等待调用结果返回。对于异步调用,回利用线程管理及信号处理等特性,自动生成代码,在新线程中调用库方法,并通过信号通知主线程该异步调用的库方法的执行结果。主线程等待异步调用返回的点可以有以下几种,1、下一个同步条用的库方法执行之前;2、下一个分支,该分支的判断逻辑引用了该异步调用的出参;3、下一个任意代码片段,代码片段引用了该异步调用的出参;4、如果没有前述三种等待点,则跳转至结束流程处结束流程执行前等待。其中,不论是无论同步还是异步调用,只要库方法调用返回失败,都必须生成调用过程的代码,并且将执行流程转向结束插件产生的代码(即结束流程)。
对于故障测试操作,任一故障模式均需要进行故障注入以及故障预期,其中,故障注入即测试用例脚本可以用该故障注入接口向被测系统的目标对象注入对应的故障模式,故障注入接口的实现通常采用软件仿真的方式模拟故障,例如,采用操作系统重启模拟节点下电等。故障预期则是配合监控库,监控被测系统在故障注入后产生故障预期,将该故障预期与预先设定业务KPI类指标或者系统状态类指标进行比较,即可确定被测系统是否存在异常。
对于业务KPI类指标,是从业务是否受损的角度定义的,测试用例调用业务KPI类故障预期接口判断当前业务是否正常。该接口从被测目标系统处获取业务类KPI指标,并判断业务是否正常。KPI指标类型和判断逻辑绑定到该故障模式,并内置到接口实现代码中。典型的业务KPI指标包括请求处理的错误率、时延和吞吐量等。该接口具体实现包括:
1、设定时间窗T1;
2、设当前时间为ct,在(ct,ct+T1]时间段内,以每t1一次的采样频率获取业务KPI指标的当前值,并记录到时序数据列表L;
3、完成最后一次采样后,对列表L采用通用的数值分析技术进行如下处理;
3a、统计分析,计算均值、极值和百分位数等,基于阈值判断是否存在业务异常;
3b、异常检测,检查KPI指标是否有大幅度波动,基于异常检测判断业务是否存在异常;
3c、趋势分析,采用回归分析等技术判断KPI指标是否存在趋势类变化,基于趋势判断业务是否存在异常。
可以看出,该接口的实现过程即被测系统在执行该包括该测试用例时,针对该被测系统出现该故障时,进行的检测过程。在该检测过程中,如果发现被测系统在发生该故障后,并未按照该故障预期产生对应的KPI指标变化或者执行相应的操作,则会判定被测系统出现功能异常,并返回该功能异常的结果,该结果指示需要开发者进行修改。
举例来说,第一功能实体和第二功能实体之间通过网络具有信息交互的过程,例如第一功能实体会向第二功能实体发送信息流,如网页内容(包括文字、图片和动画等)。若增加一个丢包故障,该故障会使得被测系统的丢包率为10%,此时,对该网页内容的完整度进行监控,若按照故障预期10%的丢包率对应到网页内容显示95%,而实际检测中,若通过检测多个周期内的网页内容显示数据,若网页内容显示仅为80%,远小于故障预期的95%,则此时,便认为被测系统并没有达到故障预期,功能异常,并返回结果。
对于系统状态类指标,是从系统状态和行为是否符合预期的角度定义的;调用系统状态类故障预期接口判断系统状态是否正常。该接口可以从被测系统处获取行为和状态数据,并判断是否符合预期。特别的,对于某些系统状态数据,如CPU占用等,可以直接访问测试装置中的测试监控模块获取,这些数据是测试装置通过安装到被测系统节点上的测试代理获取的。典型的系统状态类故障预期,包括系统是否产生故障相关的告警,主备冗余的系统是否在主机故障后切换到备机,等等。该接口具体实现如下:
1)设定时间窗T2;
2)设当前时间为ct,在ct+T2时间点获取系统状态信息,并按照预设逻辑判断系统状态及行为是否符合预期;
3)返回判断结果。
可以看出,该接口的实现过程即被测系统在执行该测试用例时,针对该被测系统出现该故障时,进行的检测过程。在该检测过程中,如果发现被测系统在发生该故障后,并未按照该故障预期产生对应的系统状态变化,则会判定被测系统出现功能异常,并返回该功能异常的结果,该结果指示需要开发者进行修改。
又举例来说,例如内存泄露故障,该故障的表现形式为在系统占用的内存资源基本固定的情况下,剩余内存越来越少;若按照故障预期,系统会在剩余内存减少至一定值时进行释放内存的操作。而若注入该内存泄露故障后,被测系统并未在剩余内存减少至一定值进行释放内存操作,而是超过该值或者一直不执行该释放内存操作,则会判定该被测系统初夏功能异常,并返回该功能异常的结果。
再举例来说,例如具有主备功能的节点,当注入一个故障使得主节点宕机,则会监测该节点是否在预设时长内从主节点切换至备节点;若按照故障预期,则需要在第一时长内产生该切换操作;而若是该被测系统未在第一时长内进行切换操作,或者一直不执行切换操作,则会判定该被测系统出现功能异常,并返回该功能异常的结果。
405、根据所述测试流程和所述测试方法生成所述目标测试用例。
在完成测试流程以及测试方法的调用后,便可以根据这些信息进行目标测试用例的生成。对于库方法测试操作,可以函数调用的方式调用测试库集合中对应的测试方法,并且根据调用次数生成指定次数的循环,以及还可以对调用方式进行确定,如同步调用还是异步调用。最后生成包含按照何种方式进行函数调用以及循环多少次的代码。
对于故障测试操作,每个测试用例的故障注入以及故障预期的代码按照如下方式生成,创建代码,以同步方式调用故障注入接口,注入故障。若接口返回失败,生成代码将流程转向结束单元,执行结束插件生成的代码。由于故障注入速度较快,因此可以采用同步调用的方式,调用故障注入接口。对于故障预期接口,业务KPI类的故障预期接口采用异步调用的方式调用。并且该异步调用必须在结构化流程的结束处等待,因此等待返回部分的代码由结束插件生成;系统状态类的故障预期接口也采用异步调用方式调用,同样的,该该异步调用必须在结构化流程的结束处等待,因此等待返回部分的代码由结束插件生成。
需要说明的是,对于故障测试操作,若调用故障注入接口或者故障预期接口时,出现调用失败,同样会按照库方法测试操作,生成调用过程的代码,并且将执行流程转向结束插件产生的代码。
需要说明的是,除了按照库方法测试操作生成的代码之外,还可以将描述文件中的定义的代码片段也加入到目标测试用例脚本中,但是在加入到目标测试用例脚本之前,需要对该代码片段进行语法检查以及一定的语义分析,完成之后,才会生成包含该代码片段的代码,该代码会出现在目标测试用例中。其中,关于语义分析,可以包括:检查代码片段中是否有变量和全局变量命名冲突,若是,测试脚本自动创建失败,返回错误;检查代码片段是否引用了不可识别的全局变量,若是,测试脚本自动创建失败,返回错误;检查代码片段是否引用了结构化流程前序单元中,某异步调用的测试库方法的出参等,若是,则需要生成代码等待该方法调用返回。
需要说明的是,创建测试用例的代码部分可包括:
创建以同步方式调用所述故障注入接口的第一代码;
创建调用所述被测系统对应所述故障模式的业务功能的第二代码;
创建以异步调用方式调用所述业务KPI类的故障预期接口的第三代码;和/或,
创建以异步调用方式调用所述系统状态类的故障预期接口第四代码;
创建通过调用监控库的监控接口监控所述故障模式的第五代码。
可以看出,生成所述目标测试用例可以包含三种情况,第一种仅包含业务KPI类的故障预期,则该目标测试用例可包括第一代码、第二代码、第三代码和第五代码。第二种是仅包含系统状态类的故障预期,则该目标测试用例可包括第一代码、第二代码、第四代码和第五代码。第三种是同时包含业务KPI类和系统状态类的故障预期,则该目标测试用例可包括第一代码、第二代码、第三代码、第四代码和第五代码。
对于结束插件,是整个结构化流程的最后一个单元,主要用于进行一些结束操作。结束插件生成一些清理代码,避免资源泄露。另外,如前文所述,结束插件要处理以下几种情况:
前序流程中存在测试方法的同步调用失败,则生成代码,返回整个测试用例执行失败,附带测试库调用失败的信息,包含测试方法名、入参和返回值。
前序流程存在未返回的测试库异步调用,则生成代码,判断返回码,若调用失败,返回整个测试用例执行失败,附带测试库调用失败的信息,包含测试方法名、入参和返回值;特别的,如前文所示,对于业务KPI类和系统状态类故障预期接口的调用,其返回值都在此处等待并处理。
若无测试库方法调用失败,结束插件生成代码,则测试用例执行返回成功。
需要说明的是,对于结束插件来说,可以设计不同的结束逻辑,一种可以是可以等待所有的前序流程,包括异步调用和同步调用等完成后,将生成测试用例过程中的返回的所有结果均进行采集,并返回测试用例生成失败的信息,该信息中包含前序流程的所有结果。另一种可以是只要有调用失败的结果跳转至该结束插件处,便返回测试用例生成失败的信息,并且该信息仅包含跳转至该结束插件处的调用失败的结果。对于这两种结束插件的逻辑,可以根据实际情况的不同而进行相应的设置,对于即将上线的被测系统,只要发现问题便立即生成测试用例生成失败的信息,以便于快速处理该问题;而若是要对系统进行全面测试的需求,则可以按照等待所有的前序流程,包括异步调用和同步调用等完成后,将生成测试用例过程中的返回的所有结果均进行采集,并返回测试用例生成失败的信息的方式,进行全面的检测。
举例来说,图5所示的结构化流程按照上述图4所示步骤401至步骤405进行处理后,便会生成如图7和图8所示的测试用例脚本,其中图7是本申请实施例的测试用例的处理方法生成的测试用例脚本示意图;图8是本申请实施例的测试用例的处理方法生成的测试用例脚本示意图。图7加上图8构成图5所示结构化流程的测试用例脚本。
上面对本申请时实施例的测试用例的处理方法进行了介绍,下面对本申请实施例的服务器进行介绍,请参阅图9,图9是本申请实施例的服务器的一个实施例图,其中,该服务器可包括:
收发模块901,用于接收总控制台发送的描述文件,所述描述文件用于描述一个或者一组测试用例的结构化流程;
处理模块902,用于根据所述描述文件确定目标测试用例的测试操作,以及所述测试操作的测试流程;
所述处理模块902还用于调用测试库集合中对应所述测试操作的测试方法,并根据所述测试流程和所述测试方法生成所述目标测试用例,所述测试库集合中存储有对应所述测试操作的测试方法。
其中,收发模块901实现图4中步骤401,而处理模块902能够实现图4中步骤402至步骤405,具体的收发模块901和处理模块902的功能可参见图4所示实施例,此处不再赘述。
可选的,所述测试库集合包括故障库、业务库和监控库,所述测试操作包括库方法测试操作,所述库方法测试操作包括故障测试操作,所述测试方法包括故障测试方法;所述故障测试操作对应所述故障测试方法,所述处理模块902具体用于:
根据所述描述文件确定故障模式,所述故障库中存储有不同的故障场景,每个故障场景对应至少一个故障模式;
根据所述故障模式从所述故障库中调用对应所述故障测试操作的故障测试方法,每个所述故障模式对应一种故障测试方法,所述故障库中存储的故障测试方法采用相同或者不同的计算机语言实现。
其中,处理模块902的功能可参见图4所示实施例,此处不再赘述。
可选的,每个所述故障模式包括具有故障注入能力的故障注入接口和提供故障预期判断的故障预期接口,所述故障注入接口用于为所述故障模式提供可复用的故障注入方法,所述故障预期接口用于为所述故障模式提供故障预期判断逻辑的故障预期判断方法。
其中,故障模式的具体说明可参见图4所示实施例,此处不再赘述。
可选的,所述故障库中对应所述故障模式设有指标,所述指标包括业务关键绩效指标KPI类指标和系统状态类指标,所述故障预期接口包括业务KPI类的故障预期接口和系统状态类的故障预期接口;所述业务KPI类的故障预期接口用于通过被测系统被注入所述故障时的业务受损值确定所述业务KPI类的故障预期,所述业务KPI类指标包括预设的业务受损阈值;所述系统状态类的故障预期接口用于通过判断系统状态和系统行为是否符合预设的系统状态和系统行为确定所述系统状态类的故障预期,所述系统状态类指标包括预设的系统状态或系统行为。
其中,关于指标的具体说明可参见图4所示实施例,此处不再赘述。
可选的,所述处理模块902具体用于:
创建以同步方式调用所述故障注入接口的第一代码;
创建调用所述被测系统对应所述故障模式的业务功能的第二代码;
创建以异步调用方式调用所述业务KPI类的故障预期接口的第三代码;和/或,
创建以异步调用方式调用所述系统状态类的故障预期接口第四代码;
创建通过调用监控库的监控接口监控所述故障模式的第五代码;
根据所述测试步骤和创建的所述第一代码、所述第二代码、和第五代码,以及所述第三代码段和/或第四代码段生成所述目标测试用例。
其中,处理模块902的具体说明可参见图4所示实施例,此处不再赘述。
可选的,所述处理模块902还用于:
若调用故障注入接口失败,则执行结束操作生成的代码,所述结束操作用于结束代码创建;或,
若以异步调用方式调用所述业务KPI类的故障预期接口或者所述系统状态类的故障预期接口,则所述结束操作生成等待异步调用返回的代码。
其中,处理模块902的具体说明可参见图4所示实施例,此处不再赘述。
可选的,所述处理模块902还用于:
执行所述目标测试用例。
其中,处理模块902的具体说明可参见图4所示实施例,此处不再赘述。
可选的,所述目标测试用例包括故障测试操作,所述处理模块902具体用于:
调用所述故障测试操作对应的故障模式的故障注入接口向所述被测系统注入所述故障模式;
在第一预设时间窗内每隔第一预设时长采集所述业务KPI指示的样本;
分析所述预设时间窗内采集的样本集合,生成所述故障模式业务KPI类的故障预期结果。
其中,处理模块902的具体说明可参见图4所示实施例,此处不再赘述。
可选的,所述处理模块902具体用于:
计算所述样本集合中样本的均值、极值和百分位数之中的至少一种,当所述均值、极值和百分位数之中的至少一种超出预设的均值阈值、极值阈值和百分位数阈值之中的至少一种时,确定所述业务异常,并生成故障预期结果;或,
分析所述样本的波动,当所述样本的波动幅度大于预设波动幅度,确定所述业务异常,并生成故障预期结果;或,
分析所述样本的变化趋势,当所述变化趋势超出预设的变化趋势时,确定所述业务异常,并生成故障预期结果。
其中,处理模块902的具体说明可参见图4所示实施例,此处不再赘述。
可选的,所述目标测试用例包括故障测试操作,所述处理模块902具体用于:
调用所述故障测试操作对应的故障模式的故障注入接口向被测系统注入所述故障模式;
在第一时刻采集所述系统状态信息,所述第一时刻为从当前时刻起经过第二预设时间窗的时刻;
当所述系统状态信息超出预设的系统状态及系统行为预期时,确定所述业务异常,并生成故障预期结果。
其中,处理模块902的具体说明可参见图4所示实施例,此处不再赘述。
可选的,所述测试操作包括库方法测试操作,所述处理模块902具体用于:
从所述描述文件的结构化流程中提取库方法测试操作、入参信息和出参信息;
通过函数调用的方式调用测试库集合中对应库方法测试操作的测试方法;
所述处理模块具体用于:
根据所述测试流程并将所述入参信息和所述出参信息作为所述调用函数的参数信息生成所述目标测试用例。
其中,处理模块902的具体说明可参见图4所示实施例,此处不再赘述。
可选的,所述处理模块902具体用于:
根据所述结构化流程确定所述库方法、所述库方法的循环次数、入参信息和出参信息;
所述处理模块具体用于:
根据所述库方法的循环次数生成对应所述循环次数的内部循环调用代码;
所述处理模块具体用于:
当确定所述调用为同步调用时,创建在当前线程中等待调用结果返回的代码;或,
当确定所述调用为异步调用时,根据所述异步调用中线程管理信息和信号处理信息生成用于异步调用的代码;
根据所述同步调用或所述异步调用生成的代码以及将所述入参信息和所述出参信息作为所述函数参数信息生成所述目标测试用例。
其中,处理模块902的具体说明可参见图4所示实施例,此处不再赘述。
可选的,所述处理模块902还用于:
从所述描述文件获取代码片段;
检测所述代码片段的语法,并对所述代码片段的语义进行分析;
所述处理模块具体用于:
根据所述测试流程、所述代码段和所述代码测试方法生成所述目标测试用例。
其中,处理模块902的具体说明可参见图4所示实施例,此处不再赘述。
可选的,所述处理模块902具体用于:
确定所述测试操作的测试流程的流向,并生成测试流程的代码,所述流向包括正向和反向。
其中,处理模块902的具体说明可参见图4所示实施例,此处不再赘述。
可选的,当所述测试操作的测试流程具有至少两个并列分支时,所述处理模块902具体用于:
确定所述测试操作的测试流程的每个分支的流向,并生成所述测试流程的每个分支的流向的代码。
其中,处理模块902的具体说明可参见图4所示实施例,此处不再赘述。
可选的,所述处理模块902还用于:
获取所述测试流程的流向的信息;
当所述测试流程的每个流向均扇入至同一汇聚的测试操作时,创建测试流程的代码。
其中,处理模块902的具体说明可参见图4所示实施例,此处不再赘述。
可选的,所述处理模块902还用于:
当所述调用测试库集合中对应所述测试操作的测试方法失败,或根据所述测试流程和所述测试方法生成所述目标测试用例失败时,返回测试用例生成失败信息,所述测试用例失生成败信息中包含所述测试方法调用失败的信息。
其中,处理模块902的具体说明可参见图4所示实施例,此处不再赘述。
上面对本申请实施例的服务器进行了介绍,下面对本申请实施例中服务器的结构进行描述,请参阅图10,图10是本申请实施例的服务器的一个实施例图,其中,服务器10可包括相连接的至少一个处理器1002、至少一个收发器1001以及存储器1003,本申请实施例涉及的服务器可以具有比图10所示出的更多或更少的部件,可以组合两个或更多个部件,或者可以具有不同的部件配置或设置,各个部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件或硬件和软件的组合实现。
具体的,对于图9所示的实施例来说,该处理器1002能实现图9所示实施例中的设备的处理模块902的功能,该收发器1101能实现图8所示实施例中的服务器的收发模块901的功能,存储器1103用于程序指令,通过执行该程序指令实现图4所示实施例的测试用例的处理方法。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。
所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的和范围。