掌桥专利:专业的专利平台
掌桥专利
首页

应用自动化测试方法、装置、设备、介质和程序产品

文献发布时间:2023-06-19 19:38:38


应用自动化测试方法、装置、设备、介质和程序产品

技术领域

本申请涉及金融科技领域或其他相关领域,尤其涉及一种应用自动化测试方法、装置、设备、介质和程序产品。

背景技术

界面(User Interface,UI)自动化测试工具主要通过操纵UI元素(如菜单、按钮、标志、输入框、目录、提示框等)来驱动系统事件,并检查系统的性能(通常是UI性能,如屏幕验证、UI元素大小和区域变化、文本和排序、易用条件和数据完整性等)作为验证点。

现有技术中,UI自动化测试大多是基于Selenium实现的,Selenium通过WebDriver与浏览器交互,通过自定义测试脚本实现Web测试。

但是,使用Selenium进行Web自动化测试,需要自行编写测试脚本执行,且在测试时必须使用浏览器驱动,使用的依赖性、复杂度偏高,测试的便捷性差,测试效率低。

发明内容

本申请提供一种应用自动化测试方法、装置、设备、介质和程序产品,用以解决目前界面自动化测试便捷性差,效率低的问题。

第一方面,本申请提供一种应用自动化测试方法,包括:

获取初始自动化测试脚本;

在所述初始自动化测试脚本中补充断言和测试数据,生成中间测试脚本,所述中间测试脚本包括测试数据和与所述测试数据对应的至少一组所述断言;

提取所述中间测试脚本中的测试数据和与所述测试数据对应的至少一组断言,得到测试数据文件;

将所述测试数据文件引入至当前测试脚本中,生成最终测试脚本;

调度所述最终测试脚本进行应用自动化测试。

第二方面,本申请提供一种应用自动化测试装置,包括:

初始脚本获取模块,用于获取初始自动化测试脚本;

中间脚本生成模块,用于在所述初始自动化测试脚本中补充断言和测试数据,生成中间测试脚本,所述中间测试脚本包括测试数据和与所述测试数据对应的至少一组所述断言;

测试数据提取模块,用于提取所述中间测试脚本中的测试数据和与所述测试数据对应的至少一组断言,得到测试数据文件;

最终脚本生成模块,用于将所述测试数据文件引入至当前测试脚本中,生成最终测试脚本;

测试模块,用于调度所述最终测试脚本进行应用自动化测试。

第三方面,本申请提供一种计算机设备,包括:处理器,以及与所述处理器通信连接的存储器;所述存储器存储计算机执行指令;所述处理器执行所述存储器存储的计算机执行指令,以实现如权利要求1-8中任一项所述的方法。

第四方面,本申请提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机指令,所述计算机指令被处理器执行时用于实现如上述的方法。

第五方面,本申请提供一种计算机程序产品,包括计算机指令,该计算机指令被处理器执行时实现上述的方法。

本申请提供的应用自动化测试方法、装置、设备、介质和程序产品,通过将测试数据与测试脚本分离,实现一个测试脚本对应多个测试数据,在需要进行测试时再将测试数据引入到测试脚本中,减少测试脚本的冗余度,提高测试的便捷性和测试效率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理。

图1为本申请实施例提供的应用自动化测试方法的场景示意图;

图2为本申请实施例提供的应用自动化测试方法的流程示意图;

图3为本申请实施例提供的最终测试脚本和测试数据文件的生成流程示意图;

图4为本申请实施例提供的基于playwright和ddt的自动化测试方法流程图;

图5为本申请实施例提供的应用自动化测试装置的结构示意图;

图6为本申请实施例提供的计算机设备的结构示意图。

通过上述附图,已示出本申请明确的实施例,后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围,而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

需要说明的是,本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等),均为经用户授权或者经过各方充分授权的信息和数据,并且相关数据的收集、使用和处理需要遵守相关法律法规和标准,并提供有相应的操作入口,供用户选择授权或者拒绝。

需要说明的是,本申请提供的应用自动化测试方法、装置、设备、介质和程序产品可用于金融科技领域,也可用于除金融科技领域之外的任意领域,本申请提供的应用自动化测试方法、装置、设备、介质和程序产品的应用领域不作限定。

在全球广域网(World Wide Web,Web)项目的测试中,用户界面(User Interface,UI)自动化测试是一个重要的测试项目,通过UI自动化测试可以提升测试效率,减少手动测试花费的时间,故而UI自动化测试工具是非常有必要开发的。目前UI自动化工具大多是基于selenium实现的,Selenium通过WebDriver与浏览器交互,通过自定义测试脚本实现Web测试。这种方式需要自行便携测试脚本执行,并且在测试时必须使用浏览器驱动,使用的依赖性、复杂度偏高。为了解决UI自动化测试过程中需要调动浏览器才能够进行测试的问题,现有技术又提供了一种通过Playwright代码录制功能生成测试案例代码,并在代码中手动增加断言代码并截图,以playwright无头模式运行编辑后的代码,实现执行测试用例时可以不调用浏览器。但是这种方式每次录制的代码仅能支持一种测试数据测试(即代码录制时人工输入的测试数据)使用,无法适用于一个测试用例,多个测试数据的场景。针对这种一个测试用例,多个测试数据的场景,现有技术又提供了一种web应用自动化测试方法,其通过pytest结合playwright测试方法,playwright录制代码,pytest管理代码,可以适用一个测试用例,多个测试数据的场景。但是随着测试数据增多,测试数据与代码无法单独管理,维护测试用例越来越繁琐,维护测试脚本成本变高。

针对上述问题,本申请实施例提供的应用自动化测试方法,可以将测试数据与测试脚本分离,实现一个测试脚本对应多个测试数据,在需要进行测试时再将测试数据引入到测试脚本中,减少测试脚本的冗余度,提高测试效率,降低自动化测试案例的维护成本,提高维护效率。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图,对本申请的实施例进行描述。

图1为本申请实施例提供的应用自动化测试方法的场景示意图,如图1所示,通过启动playwrigh代码录制命令获取初始自动化脚本,然后通过调成初始自动化测试脚本的脚本结构,补充断言和测试数据,生成中间测试脚本(即pytest测试脚本),在playwrigh和pytest自动化测试框架的基础上,再结合数据驱动框架和PyYAML,把测试数据从中抽离出来,在单独的yaml文件中进行管理,使得测试数据与测试脚本分离,实现一个测试脚本对应多个测试数据,避免一个测试脚本对应一个测试数据,降低测试脚本的冗余度。

示例性的,图2为本申请实施例提供的应用自动化测试方法的流程示意图,该方法可以应用于计算机设备,以计算机设备作为执行主体为例,如图2所示,该方法具体可以包括如下步骤:S201,获取初始自动化测试脚本。

在本实施例中,初始自动化测试脚本可以视为一个脚本框架,其脚本结构还需要做进一步的调整,例如还需要做进一步的代码补充等才可以进行后续的自动化测试。示例性的,初始自动化测试脚本应用于后续的web应用自动化测试。

其中,用户可在计算机设备登录客户端,选择要录制代码的初始自动化测试脚本,向后端发起代码录制命令,初始自动化测试脚本中可以包含测试应用信息,如系统地址信息。示例性的,可以通过playwright录制代码,获得初始自动化测试脚本。其中,playwright是一种自动化测试装置。

步骤S202,在初始自动化测试脚本中补充断言和测试数据,生成中间测试脚本,中间测试脚本包括测试数据和与测试数据对应的至少一组断言。

其中,断言是一种在程序中的一阶逻辑(如:一个结果为真或假的逻辑判断式),目的为了表示与验证软件开发者预期的结果——当程序执行到断言的位置时,对应的断言应该为真。若断言不为真时,程序会中止执行,并给出错误信息。测试数据是指一组输入和对应输出的组合,示例性的,以UI自动化测试为例,其测试数据包括有页面的样式风格、页面图片显示、页面文字显示等。

示例性的,中间测试脚本可以是pytest测试脚本,其中,pytest是python编程语言中的单元测试框架。其中,通过playwright录制代码,pytest管理代码,可以适用于一个测试用例对应多个测试数据的场景,减少测试脚本的冗余度。

步骤S203,提取中间测试脚本中的测试数据和与测试数据对应的至少一组断言,得到测试数据文件。

在本实施例中,可以利用ddt和PyYAML技术,提取测试数据和断言。其中,ddt是一种数据驱动框架,指在自动化测试中处理数据的方式。通常测试数据与功能环境分离,存储在功能函数的外部位置。在自动化测试运行时,数据驱动框架会读取数据源中的数据,把数据作为参数传递到功能函数中,并会根据数据的条数多次运行同一个功能函数。PyYAML是另一种标记语言(YAML Ain't Markup Language,YAML)的解析器和生成器。

其中,通过结合ddt(数据驱动框架)和PyYAML,把测试数据从中抽离出来,在单独的yaml文件中进行管理,使测试数据与测试脚本分离,实现一个测试脚本对应多个测试数据,减少测试脚本的冗余度,降低自动化测试案例的维护成本,提高维护效率,脚本与数据分离的方式也使得自动化案例的逻辑更加清晰,可读性和可维护性得到提升,让测试人员更容易掌握。

步骤S204,将测试数据文件引入至当前测试脚本中,生成最终测试脚本。步骤S205,调度最终测试脚本进行应用自动化测试。在本实施例中,可以通过pytest调度执行测试案例,并输出测试结果和测试报告。

本申请实施例通过将测试数据与测试脚本分离,实现一个测试脚本对应多个测试数据,在需要进行测试时再将测试数据引入到测试脚本中,减少测试脚本的冗余度,降低自动化测试案例的维护成本,提高维护效率。

在上述实施例的基础上,在另一些实施例中,上述步骤S201具体可以通过如下步骤实现:响应于代码录制命令,获取通过预设用户界面自动化测试工具的代码录制命令录制得到的代码,作为初始自动化测试脚本,预设用户界面自动化测试工具为playwright。

其中,playwright是一种自动化测试装置,支持各种计算机程序语言和不同类型的浏览器,可以接收浏览器的信号,而目前使用的selenium采用的是HTTP协议,只能客户端发起请求。

本申请实施例通过使用playwright代码录制功能录制代码,得到初始自动化测试脚本,可以不需要用户自行便携测试脚本执行,且可以以playwright的无头模式运行编辑后的脚本,在测试时也不需要再使用浏览器驱动,降低了测试过程中的依赖性和复杂度。

在上述实施例的基础上,在另一些实施例中,上述步骤S202具体可以通过如下步骤实现:在指定目录下创建文件名为预设样式的测试脚本文件,文件名中至少包括测试用例的标识;根据测试用例的测试场景和测试系统,创建以测试用例的标识为名称的类对象,并增加预设单元测试框架的类级别方法,预设单元测试框架为pytest;根据测试脚本文件、类对象和类级别方法,以初始自动化测试脚本为基础,补充断言和测试数据,得到中间测试脚本。

在本实施例中,可以在指定目录下创建TEST+项目ID+案例ID为文件名的测试脚本文件,然后根据测试用例场景和系统,创建以测试用例ID为名称的class对象,增加Pytest的setup_class、teardown_class方法,作为测试方法的前置处理和后置处理。然后以初始宗华测试脚本为基础,补充完善案例断言及相关数据,生成pytest测试脚本,作为中间测试脚本。

本申请实施例通过pytest测试脚本管理代码,可以实现每次录制的代码支持多种测试数据测试使用,可以适用于一个测试用例、多个测试数据的场景,便于对测试数据进行管理和维护,降低测试数据和测试脚本的维护成本。

在另一些实施例中,上述方法还可以包括如下步骤:将测试数据文件存储至预设标记语言文件,预设标记语言文件为yaml文件。

在本实施例中,可以将pytest测试脚本中的测试数据存放到yaml测试数据文件中,实现测试脚本与测试数据的分离。其中,yaml可以用来做以数据为中心的配置文件,其可读性高,易于理解,用来表达数据序列化的格式。

本申请实施例通过将测试数据文件存储至yaml文件,使得测试数据与测试脚本分离,实现一个测试脚本对应多个测试数据,减少测试脚本的冗余度,降低自动化测试案例的维护成本,提高维护效率,脚本与数据分离的方式也使得自动化案例的逻辑更加清晰,可读性和可维护性得到提升,让测试人员更容易掌握。

在上述实施例的基础上,在另一些实施例中,可以通过如下步骤实现测试数据文件的存储:获取中间测试脚本的测试用例名称和测试用例数据;根据用例名称和测试用例数据,将测试数据文件以键值对的形式存放至预设标记语言文件。

在本实施例中,可以“用例名称:测试案例数据”作为键值对的形式,将pytest测试脚本中的测试数据存放到yaml测试数据文件中。

示例性的,图3为本申请实施例提供的最终测试脚本和测试数据文件的生成流程示意图,如图3所示,其包括如下步骤:步骤S301,将Pytest测试脚本中的测试数据以“用例名称:测试案例数据”键值对的形式存放到yaml测试数据文件中。步骤S302,在pytest测试脚本中通过文件名自动获取yaml测试数据文件的详细路径。步骤S303,通过@file_data和详细路径的形式,将测试数据文件引入到当前测试脚本中。步骤S304,通过kwargs参数传递技术,将测试数据文件中的测试数据传至playwright脚本指定位置,生成最终测试脚本。步骤S305,获取yaml文件中每个用例名称出现的次数,作为后续对应测试脚本的执行次数。

示例性的,在另一些实施例方式中,继续参考上述图3,可以获取预设标记语言文件中每个测试用例名称出现的次数,作为该最终测试脚本的执行次数。通过直接获取每个测试用例名称出现的次数,可以间接的获取出脚本的执行次数,不需要再通过人工计数,可以有效提高测试效率。

本申请实施例通过在单独的yaml文件中管理测试数据,使测试数据与测试脚本分离,实现一个测试脚本对应多个测试数据,减少测试脚本的冗余度,降低自动化测试案例的维护成本,提高维护效率,脚本与数据分离的方式也使得自动化案例的逻辑更加清晰,可读性和可维护性得到提升,让测试人员更容易掌握。

在上述实施例的基础上,在另一些实施例中,上述步骤S204具体可以通过如下步骤实现:获取测试数据文件的文件名;根据文件名,自动获取测试数据文件在预设标记语言文件中的存储路径;根据存储路径,将测试数据文件引入至当前测试脚本;通过预设参数传递技术,将测试数据文件中的测试数据传至脚本指定位置,生成最终测试脚本。

继续参考上述图3,在本实施例中,可以在pytest测试脚本中利用os.path.dirname技术,通过文件名自动获取yaml测试数据文件的详细路径,通过在pytest测试脚本中利用os.path.dirname技术,通过文件名自动获取yaml测试数据文件的详细路径,然后通过@file_data+详细路径的形式,将测试数据文件引入当前测试脚本中;最后通过kwargs参数传递技术,将测试数据传至playwright脚本指定位置,生成最终测试脚本。

在本实施例中,os.path.dirname技术的作用是返回脚本的路径,示例性的,以测试数据文件的名称为“file_A”为例,其文件存储路径为“E:/read_file/file_A”,通过os.path.dirname技术可以返回路径“E:/read_file/”。

示例性的,以登录脚本实现账号登录为例,需要在脚本内写入要登录的账号和密码,但是该登录脚本只能登录一个账号,此时为了避免1000个账号需要构造1000个登录脚本的情况,此时就可以不在登录脚本中写入账号信息,而是让登录脚本访问yaml文件(其中存放了1000个账号信息),通过yaml文件传入不同的账号信息来实现不同的账号登录。在本实施例中,通过结合ddt(数据驱动框架)和PyYAML,使用@file_data+详细路径的形式就可以访问到yaml文件中存放的各个账号信息。

本申请实施例通过把测试数据从代码中抽离出来,在单独的yaml文件中进行管理,使测试数据与测试脚本分离,实现一个测试脚本对应多个测试数据,减少测试脚本的冗余度,降低自动化测试案例的维护成本,提高维护效率,脚本与数据分离的方式也使得自动化案例的逻辑更加清晰,可读性和可维护性得到提升,让测试人员更容易掌握。

在另一些实施例中,应用自动化测试包括文件上传功能测试,上述步骤S205具体可以通过如下步骤实现:在对应用进行文件上传功能测试时,在最终测试脚本中通过预设图形用户界面自动化工具传输待上传文件的传输文件路径,得到指定上传的文件,预设图形用户界面自动化工具为pyautogui;调用预设图形用户界面自动化工具传输指定上传的文件以进行文件上传功能的测试。

在本实施例中,对于文件上传功能的测试,由于playwright仅支持input方式(即在代码中输入的方式)的文件上传,因而非input方式文件上传无法按照上述步骤传输文件路径。为解决该问题,本实施例引入pyautogui技术,在测试脚本中通过pyautogui传输文件路径,得到指定上传的文件,并通过pyautogui的write方法和press(‘enter’)方法实现文件上传。

示例性的,图4为本申请实施例提供的基于playwright和ddt的自动化测试方法流程图,如图4所示,该方法包括如下步骤:步骤S401,通过playwright代码录制命令得到初始自动化测试脚本。步骤S402,调整初始自动化测试脚本结构,生成符合pytest框架的测试脚本。步骤S403,利用ddt和PyYAML技术,提取测试数据和断言,生成最终测试脚本、数据文件和每个脚本对应执行次数。步骤S404,通过pytest调度执行测试案例,输出测试结果及报告。

本申请实施例针对playwright不支持非input方式文件上传的问题,引入pyautogui技术解决,实现了测试数据的高效、快捷管理,降低代码维护成本,提高测试效率。

下述为本申请装置实施例,可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节,请参照本申请方法实施例。

图5为本申请实施例提供的应用自动化测试装置的结构示意图,该应用自动化测试装置可以集成在计算机设备中。如图5所示,该应用自动化测试装置500具体可以包括初始脚本获取模块510、中间脚本生成模块520、测试数据提取模块530、最终脚本生成模块540、测试模块550。

其中,初始脚本获取模块510用于获取初始自动化测试脚本。中间脚本生成模块520用于在初始自动化测试脚本中补充断言和测试数据,生成中间测试脚本,中间测试脚本包括测试数据和与测试数据对应的至少一组断言。测试数据提取模块530用于提取中间测试脚本中的测试数据和与测试数据对应的至少一组断言,得到测试数据文件。最终脚本生成模块540用于将测试数据文件引入至当前测试脚本中,生成最终测试脚本。测试模块550用于调度最终测试脚本进行应用自动化测试。

可选的,初始脚本获取模块具体可以用于:响应于代码录制命令,获取通过预设用户界面自动化测试工具的代码录制命令录制得到的代码,作为初始自动化测试脚本,预设用户界面自动化测试工具为playwright。

可选的,中间脚本生成模块具体可以用于:在指定目录下创建文件名为预设样式的测试脚本文件,文件名中至少包括测试用例的标识;根据测试用例的测试场景和测试系统,创建以测试用例的标识为名称的类对象,并增加预设单元测试框架的类级别方法,预设单元测试框架为pytest;根据测试脚本文件、类对象和类级别方法,以初始自动化测试脚本为基础,补充断言和测试数据,得到中间测试脚本。

可选的,还包括文件存储模块,用于将测试数据文件存储至预设标记语言文件,预设标记语言文件为yaml文件。

可选的,文件存储模块具体还可以用于:获取中间测试脚本的测试用例名称和测试用例数据;根据用例名称和测试用例数据,将测试数据文件以键值对的形式存放至预设标记语言文件。

可选的,最终脚本生成模块具体可以用于:获取测试数据文件的文件名;根据文件名,自动获取测试数据文件在预设标记语言文件中的存储路径;根据存储路径,将测试数据文件引入至当前测试脚本;通过预设参数传递技术,将测试数据文件中的测试数据传至脚本指定位置,生成最终测试脚本。

可选的,应用自动化测试包括文件上传功能测试,测试模块具体可以用于:在对应用进行文件上传功能测试时,在最终测试脚本中通过预设图形用户界面自动化工具传输待上传文件的传输文件路径,得到指定上传的文件,预设图形用户界面自动化工具为pyautogui;调用预设图形用户界面自动化工具传输指定上传的文件以进行文件上传功能的测试。

可选的,还包括执行次数获取模块,用于获取预设标记语言文件中每个测试用例名称出现的次数,作为该最终测试脚本的执行次数。

本申请实施例提供的装置,可用于执行上述实施例中的方法,其实现原理和技术效果类似,在此不再赘述。

需要说明的是,应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分,实际实现时可以全部或部分集成到一个物理实体上,也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现;也可以全部以硬件的形式实现;还可以部分模块通过处理元件调用软件的形式实现,部分模块通过硬件的形式实现。例如,测试模块可以为单独设立的处理元件,也可以集成在上述装置的某一个芯片中实现,此外,也可以以程序代码的形式存储于上述装置的存储器中,由上述装置的某一个处理元件调用并执行以上测试模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起,也可以独立实现。这里的处理元件可以是一种集成电路,具有信号的处理能力。在实现过程中,上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

图6为本申请实施例提供的计算机设备的结构示意图。如图6所示,该计算机设备600包括:至少一个处理器601、存储器602、总线603及通信接口604。其中:处理器、通信接口以及存储器通过总线完成相互间的通信。通信接口,用于与其它设备进行通信。该通信接口包括用于进行数据传输的通信接口以及用于进行人机交互的显示界面或者操作界面等。处理器,用于执行存储器存储的计算机执行指令,具体可以执行上述实施例中所描述的方法中的相关步骤。处理器可能是中央处理器,或者是特定集成电路(Application SpecificIntegrated Circuit,ASIC),或者是被配置成实施本发明实施例的一个或多个集成电路。电子设备包括的一个或多个处理器,可以是同一类型的处理器,如一个或多个CPU;也可以是不同类型的处理器,如一个或多个CPU以及一个或多个ASIC。存储器,用于存储计算机执行指令。存储器可能包含高速RAM存储器,也可能还包括非易失性存储器,例如至少一个磁盘存储器。

本实施例还提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机指令,当计算机设备的至少一个处理器执行该计算机指令时,计算机设备执行上述的各种实施方式提供的方法。

本实施例提供一种计算机程序产品,该程序产品包括计算机指令,该计算机指令存储在可读存储介质中。计算机设备的至少一个处理器可以从可读存储介质读取该计算机指令,至少一个处理器执行该计算机指令使得计算机设备实施上述的各种实施方式提供的方法。

本申请中,“至少一个”是指一个或者多个,“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B的情况,其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系;在公式中,字符“/”,表示前后关联对象是一种“相除”的关系。“以下至少一项(个)”或其类似表达,是指的这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a,b,或c中的至少一项(个),可以表示:a,b,c,a-b,a-c,b-c,或a-b-c,其中,a,b,c可以是单个,也可以是多个。

可以理解的是,在本申请实施例中涉及的各种数字编号仅为描述方便进行的区分,并不用来限制本申请的实施例的范围。在本申请的实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请的实施例的实施过程构成任何限定。

最后应说明的是:以上各实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述各实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

技术分类

06120115979838