本发明涉及通信
技术领域：
，尤其涉及一种电子装置、测试方法及存储介质。
背景技术：
：目前，apm(applicationperformancemonitor，应用性能相关的监测)产品及java应用业务越来越丰富，在技术人员对apm产品或java应用业务进行javaagent探针埋点开发时，需要进行服务版本测试。由于apm产品中的一个服务或者java应用业务对应的客户端jar包有几十个版本，此外，一个项目的应用拓扑一般包括很多服务，提供给每个服务对应的jar包又包含多个版本，如果对所有的覆盖全服务的版本都测试，无疑费时费力，工作量大且效率低。技术实现要素：本发明的目的在于提供一种电子装置、测试方法及存储介质，旨在提高测试效率。为实现上述目的，本发明提供一种电子装置，所述电子装置包括存储器及与所述存储器连接的处理器，所述存储器中存储有可在所述处理器上运行的测试系统，所述测试系统被所述处理器执行时实现如下步骤：版本归类步骤，在预先构建的jekins环境下，对每一服务类型的所有的服务版本进行版本归类；规则表建立步骤，在接收到全量版本覆盖测试指令时，利用典型抽取的方式抽取版本归类后的服务版本，基于所抽取的服务版本建立规则表；读取步骤，在建立jekinsapi服务后，基于该服务的服务类型读取所述规则表，以获取所述规则表中对应的版本信息；版本测试步骤，根据所获取的版本信息获取对应的代码分支，基于所获取的代码分支执行全量版本覆盖测试。优选地，所述对每一服务类型的所有的服务版本进行版本归类的步骤，具体包括：将属于同一个大版本的服务版本归为同一类，将属于同一类大版本中的小版本按照版本号的先后顺序进行排列。优选地，所述利用典型抽取的方式抽取版本归类后的服务版本，基于所抽取的服务版本建立规则表的步骤，具体包括：抽取属于同一类大版本中的服务版本的第一个小版本及最后一个小版本，并基于预定的抽取规则抽取第一个小版本与最后一个小版本之间的一个小版本；基于在属于同一类大版本的服务版本中所抽取的小版本建立规则表。优选地，所述根据所获取的版本信息获取对应的代码分支，基于所获取的代码分支执行全量版本覆盖测试的步骤，具体包括：分析代码库中是否已构建有所获取的版本信息对应的代码分支；若是，则拉取代码库中所获取的版本信息对应的代码分支；若否，则修改配置文件pom中的依赖版本信息，以基于修改后的配置文件pom重新编译所获取的版本信息对应的代码分支；调用jekins环境中的相关组件构建所述代码分支的版本打包任务，通过jekins插件将打包后的代码分支上传到ftp目录中，以在执行全量版本覆盖测试时从所述ftp目录中拉取代码分支进行测试。为实现上述目的，本发明还提供一种测试方法，所述测试方法包括：s1，在预先构建的jekins环境下，对每一服务类型的所有的服务版本进行版本归类；s2，在接收到全量版本覆盖测试指令时，利用典型抽取的方式抽取版本归类后的服务版本，基于所抽取的服务版本建立规则表；s3，在建立jekinsapi服务后，基于该服务的服务类型读取所述规则表，以获取所述规则表中对应的版本信息；s4，根据所获取的版本信息获取对应的代码分支，基于所获取的代码分支执行全量版本覆盖测试。优选地，所述对每一服务类型的所有的服务版本进行版本归类的步骤，具体包括：将属于同一个大版本的服务版本归为同一类，将属于同一类大版本中的小版本按照版本号的先后顺序进行排列。优选地，所述利用典型抽取的方式抽取版本归类后的服务版本，基于所抽取的服务版本建立规则表的步骤，具体包括：抽取属于同一类大版本中的服务版本的第一个小版本及最后一个小版本，并基于预定的抽取规则抽取第一个小版本与最后一个小版本之间的一个小版本；基于在属于同一类大版本的服务版本中所抽取的小版本建立规则表。优选地，所述预定的抽取规则包括：抽取位于所述第一个小版本与最后一个小版本之间转折性最大的一个小版本，或者，抽取位于所述第一个小版本与最后一个小版本之间预定的一个小版本。优选地，所述根据所获取的版本信息获取对应的代码分支，基于所获取的代码分支执行全量版本覆盖测试的步骤，具体包括：分析代码库中是否已构建有所获取的版本信息对应的代码分支；若是，则拉取代码库中所获取的版本信息对应的代码分支；若否，则修改配置文件pom中的依赖版本信息，以基于修改后的配置文件pom重新编译所获取的版本信息对应的代码分支；调用jekins环境中的相关组件构建所述代码分支的版本打包任务，通过jekins插件将打包后的代码分支上传到ftp目录中，以在执行全量版本覆盖测试时从所述ftp目录中拉取代码分支进行测试。本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有测试系统，所述测试系统被处理器执行时实现上述的测试方法的步骤。本发明的有益效果是：本发明对服务版本进行归类后，在接收到全量版本覆盖测试指令时，抽取归类后具有代表性的小部分服务版本建立规则表，基于该规则表获取对应的版本信息，最终获取版本信息对应的代码分支进行全量版本覆盖测试，本发明抽取具有代表性的小部分版本信息模拟全覆盖测试，省时省力，提高测试效率。附图说明图1为本发明电子装置一实施例的硬件架构的示意图；图2为本发明测试方法一实施例的流程示意图。具体实施方式为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。需要说明的是，在本发明中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本发明要求的保护范围之内。参阅图1所示，是本发明电子装置一实施例的硬件架构示意图，所述电子装置1是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备。所述电子装置1可以是计算机、也可以是单个网络服务器、多个网络服务器组成的服务器组或者基于云计算的由大量主机或者网络服务器构成的云，其中云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。在本实施例中，电子装置1可包括，但不仅限于，可通过系统总线相互通信连接的存储器11、处理器12、网络接口13，存储器11存储有可在处理器12上运行的测试系统。需要指出的是，图1仅示出了具有组件11-13的电子装置1，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。其中，存储器11包括内存及至少一种类型的可读存储介质。内存为电子装置1的运行提供缓存；可读存储介质可为如闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等的非易失性存储介质。在一些实施例中，可读存储介质可以是电子装置1的内部存储单元，例如该电子装置1的硬盘；在另一些实施例中，该非易失性存储介质也可以是电子装置1的外部存储设备，例如电子装置1上配备的插接式硬盘，智能存储卡(smartmediacard,smc)，安全数字(securedigital,sd)卡，闪存卡(flashcard)等。本实施例中，存储器11的可读存储介质通常用于存储安装电子装置1的操作系统和各类应用软件，例如本发明一实施例中的测试系统的程序代码等。此外，存储器11还可以用于暂时地存储已经输出或者将要输出的各类数据。所述处理器12在一些实施例中可以是中央处理器(centralprocessingunit，cpu)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器12通常用于控制所述电子装置1的总体操作，例如执行与其他设备进行数据交互或者通信相关的控制和处理等。本实施例中，所述处理器12用于运行所述存储器11中存储的程序代码或者处理数据，例如运行测试系统等。所述网络接口13可包括无线网络接口或有线网络接口，该网络接口13通常用于在所述电子装置1与其他电子设备之间建立通信连接。所述测试系统存储在存储器11中，包括至少一个存储在存储器11中的计算机可读指令，该至少一个计算机可读指令可被处理器器12执行，以实现本申请各实施例的方法；以及，该至少一个计算机可读指令依据其各部分所实现的功能不同，可被划为不同的逻辑模块。在一实施例中，上述测试系统被所述处理器12执行时实现如下步骤：版本归类步骤，在预先构建的jekins环境下，对每一服务类型的所有的服务版本进行版本归类；本实施例中，可预先构建可以自动化测试的jekins环境，对每一服务类型的所有的服务版本进行版本归类，该服务版本包括各个服务类型对应的所有jar包的版本，服务类型包括mysql服务、redis服务等。优选地，对服务版本进行版本归类包括：将属于同一个大版本的服务版本归为同一类，将属于同一类大版本中的小版本按照版本号的先后顺序进行排列。例如有大版本为：v1.xx、v2.xx、v3.xx，则将属于大版本v1的所有服务版本归为同一类，将属于大版本v2所有的服务版本归为同一类，将属于大版本v3所有的服务版本归为同一类，然后，对于同一类大版本下的小版本，例如大本版v1.xx下的所有小版本为：v1.0.1、v1.0.5、v1.0.3，则将小版本按照版本号的先后顺序进行排列、存储，排列后的小版本为v1.0.1、v1.0.3、v1.0.5。规则表建立步骤，在接收到全量版本覆盖测试指令时，利用典型抽取的方式抽取版本归类后的服务版本，基于所抽取的服务版本建立规则表；在进行全量版本覆盖测试时，即在接收到全量版本覆盖测试指令时，利用典型抽取的方式抽取版本归类后的服务版本。优选地，典型抽取的方式为抽取属于同一类大版本中的服务版本的第一个小版本及最后一个小版本，并基于预定的抽取规则抽取第一个小版本与最后一个小版本之间的一个小版本；基于在属于同一类大版本的服务版本中所抽取的小版本建立规则表。在一实施例中，典型抽取的方式为二分法的抽取方式，例如一服务版本的大版本为v1.x，大版本v1.x下的最小版本为v1.0.1、最大版本为v1.0.5、中间版本为v1.0.3，则对于大版本v1.x，抽取最小版本v1.0.1、最大版本v1.0.5及中间版本v1.0.3。在其他实施例中，典型抽取的方式为类似二分法的抽取方式，例如一服务版本的大版本为v1.x，大版本v1.x下的最小版本为v1.0.1、最大版本为v1.0.5，则对于大版本v1.x，抽取最小版本v1.0.1、最大版本v1.0.5及中间的任意一个版本，优选地，抽取中间转折性最大的小版本或者预定的小版本。其他的服务版本同样采用上述的抽取方式，此处不再一一举例说明。为了方便后续的测试，本实施例还将所抽取的服务版本建立规则表。在一实施例中，建立的规则表如下表1所示：idgroupidartifactidmin_versionmax_versionrandom_versionv2.0mysqlmysql-connector-javav2.0.14v2.0.14v3.0mysqlmysql-connector-javav3.0.8v3.1.14v5.0mysqlmysql-connector-javav5.0.2v5.1.42v5.1.21表1其中，规则表总共设定6个字段：id为大版本号，groupid及artifactid分别对应软件项目管理和综合工具maven的groupid及artifactid内容，min_version及max_version分别为大版本下的最小版本和最大版本，例如为大版本v3.0下的最小版本v3.0.8和最大版本v3.1.14。读取步骤，在建立jekinsapi服务后，基于该服务的服务类型读取所述规则表，以获取所述规则表中对应的版本信息；本实施例中，在建立jekinsapi服务后，若为该服务为mysql服务，则读取规则表中的mysql服务对应的版本信息，若为其他的服务，则读取得到其他的服务对应的版本信息，如上表1所示，读取得到的mysql服务的版本信息包括：mysql服务的大版本v2.0、v3.0及v5.0、每一大版本的groupid及artifactid、最小版本v2.0.14、v3.0.8及v5.0.2、最大版本v2.0.14、v3.1.14及v5.1.42、中间版本v5.1.21。版本测试步骤，根据所获取的版本信息获取对应的代码分支，基于所获取的代码分支执行全量版本覆盖测试。本实施例中，可以在代码库中预先创建了每一服务版本的代码分支，在获取版本信息后，可以根据版本信息获取代码库中对应的代码分支，例如分别获取大版本v3.0下的小版本v3.0.8及v3.1.14对应的代码分支，然后利用所获取的代码分支执行全量版本覆盖测试，或者通过重新编译版本信息对应的代码分支，基于该代码分支执行全量版本覆盖测试。与现有技术相比，本实施例对服务版本进行归类后，在接收到全量版本覆盖测试指令时，抽取归类后具有代表性的小部分服务版本建立规则表，基于该规则表获取对应的版本信息，最终获取版本信息对应的代码分支进行全量版本覆盖测试，本实施例抽取具有代表性的小部分版本信息模拟全覆盖测试，省时省力，测试效率高。在一优选的实施例中，在上述图1的实施例的基础上，所述根据所获取的版本信息获取对应的代码分支，基于所获取的代码分支执行全量版本覆盖测试的步骤，具体包括：分析代码库中是否已构建有所获取的版本信息对应的代码分支；若是，则拉取代码库中所获取的版本信息对应的代码分支；若否，则修改配置文件pom中的依赖版本信息，以基于修改后的配置文件pom重新编译所获取的版本信息对应的代码分支；调用jekins环境中的相关组件构建所述代码分支的版本打包任务，通过jekins插件将打包后的代码分支上传到ftp目录中，以在执行全量版本覆盖测试时从所述ftp目录中拉取代码分支进行测试。本实施例中，如果代码库中已经预先构建有所获取的版本信息对应的代码分支，则可以直接拉取代码库中对应的代码分支；如果代码库中没有预先构建所获取的版本信息对应的代码分支，则需要修改配置文件pom中的依赖版本信息，然后根据修改后的配置文件pom重新编译所获取的版本信息对应的代码分支。本实施例可以灵活地获取版本信息对应的代码分支，方便在执行全量版本覆盖测试时拉取代码分支进行测试，进一步提高测试的效率。如图2所示，图2为本发明测试方法一实施例的流程示意图，该测试方法包括以下步骤：步骤s1，在预先构建的jekins环境下，对每一服务类型的所有的服务版本进行版本归类；本实施例中，可预先构建可以自动化测试的jekins环境，对每一服务类型的所有的服务版本进行版本归类，该服务版本包括各个服务类型对应的所有jar包的版本，服务类型包括mysql服务、redis服务等。优选地，对服务版本进行版本归类包括：将属于同一个大版本的服务版本归为同一类，将属于同一类大版本中的小版本按照版本号的先后顺序进行排列。例如有大版本为：v1.xx、v2.xx、v3.xx，则将属于大版本v1的所有服务版本归为同一类，将属于大版本v2所有的服务版本归为同一类，将属于大版本v3所有的服务版本归为同一类，然后，对于同一类大版本下的小版本，例如大本版v1.xx下的所有小版本为：v1.0.1、v1.0.5、v1.0.3，则将小版本按照版本号的先后顺序进行排列、存储，排列后的小版本为v1.0.1、v1.0.3、v1.0.5。步骤s2，在接收到全量版本覆盖测试指令时，利用典型抽取的方式抽取版本归类后的服务版本，基于所抽取的服务版本建立规则表；在进行全量版本覆盖测试时，即在接收到全量版本覆盖测试指令时，利用典型抽取的方式抽取版本归类后的服务版本。优选地，典型抽取的方式为抽取属于同一类大版本中的服务版本的第一个小版本及最后一个小版本，并基于预定的抽取规则抽取第一个小版本与最后一个小版本之间的一个小版本；基于在属于同一类大版本的服务版本中所抽取的小版本建立规则表。在一实施例中，典型抽取的方式为二分法的抽取方式，例如一服务版本的大版本为v1.x，大版本v1.x下的最小版本为v1.0.1、最大版本为v1.0.5、中间版本为v1.0.3，则对于大版本v1.x，抽取最小版本v1.0.1、最大版本v1.0.5及中间版本v1.0.3。在其他实施例中，典型抽取的方式为类似二分法的抽取方式，例如一服务版本的大版本为v1.x，大版本v1.x下的最小版本为v1.0.1、最大版本为v1.0.5，则对于大版本v1.x，抽取最小版本v1.0.1、最大版本v1.0.5及中间的任意一个版本，优选地，抽取中间转折性最大的小版本或者预定的小版本。其他的服务版本同样采用上述的抽取方式，此处不再一一举例说明。为了方便后续的测试，本实施例还将所抽取的服务版本建立规则表。在一实施例中，建立的规则表如上述表1所示。其中，规则表总共设定6个字段：id为大版本号，groupid及artifactid分别对应软件项目管理和综合工具maven的groupid及artifactid内容，min_version及max_version分别为大版本下的最小版本和最大版本，例如为大版本v3.0下的最小版本v3.0.8和最大版本v3.1.14。步骤s3，在建立jekinsapi服务后，基于该服务的服务类型读取所述规则表，以获取所述规则表中对应的版本信息；本实施例中，在建立jekinsapi服务后，若为该服务为mysql服务，则读取规则表中的mysql服务对应的版本信息，若为其他的服务，则读取得到其他的服务对应的版本信息，如上表1所示，读取得到的mysql服务的版本信息包括：mysql服务的大版本v2.0、v3.0及v5.0、每一大版本的groupid及artifactid、最小版本v2.0.14、v3.0.8及v5.0.2、最大版本v2.0.14、v3.1.14及v5.1.42、中间版本v5.1.21。步骤s4，根据所获取的版本信息获取对应的代码分支，基于所获取的代码分支执行全量版本覆盖测试。本实施例中，可以在代码库中预先创建了每一服务版本的代码分支，在获取版本信息后，可以根据版本信息获取代码库中对应的代码分支，例如分别获取大版本v3.0下的小版本v3.0.8及v3.1.14对应的代码分支，然后利用所获取的代码分支执行全量版本覆盖测试，或者通过重新编译版本信息对应的代码分支，基于该代码分支执行全量版本覆盖测试。与现有技术相比，本实施例对服务版本进行归类后，在接收到全量版本覆盖测试指令时，抽取归类后具有代表性的小部分服务版本建立规则表，基于该规则表获取对应的版本信息，最终获取版本信息对应的代码分支进行全量版本覆盖测试，本实施例抽取具有代表性的小部分版本信息模拟全覆盖测试，省时省力，测试效率高。在一优选的实施例中，在上述图2的实施例的基础上，所述根据所获取的版本信息获取对应的代码分支，基于所获取的代码分支执行全量版本覆盖测试的步骤，具体包括：分析代码库中是否已构建有所获取的版本信息对应的代码分支；若是，则拉取代码库中所获取的版本信息对应的代码分支；若否，则修改配置文件pom中的依赖版本信息，以基于修改后的配置文件pom重新编译所获取的版本信息对应的代码分支；调用jekins环境中的相关组件构建所述代码分支的版本打包任务，通过jekins插件将打包后的代码分支上传到ftp目录中，以在执行全量版本覆盖测试时从所述ftp目录中拉取代码分支进行测试。本实施例中，如果代码库中已经预先构建有所获取的版本信息对应的代码分支，则可以直接拉取代码库中对应的代码分支；如果代码库中没有预先构建所获取的版本信息对应的代码分支，则需要修改配置文件pom中的依赖版本信息，然后根据修改后的配置文件pom重新编译所获取的版本信息对应的代码分支。本实施例可以灵活地获取版本信息对应的代码分支，方便在执行全量版本覆盖测试时拉取代码分支进行测试，进一步提高测试的效率。本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有测试系统，所述测试系统被处理器执行时实现上述的测试方法的步骤。上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的
技术领域：
，均同理包括在本发明的专利保护范围内。当前第1页12