1.本技术涉及设备稳定性测试技术领域，特别是涉及一种设备稳定性测试方法、装置、计算机设备和存储介质。
背景技术：2.服务器稳定性测试方式为反复使服务器开关机，验证服务器的稳定性。目前通用服务器的稳定性测试工具大多直接安装在物理服务器上，对服务器进行稳定性测试前需要针对测试项目准备一套完整的测试工具，包括不限于测试软件、硬件驱动等。
3.服务器整机测试大多依赖pxe进行，各项测试需要根据服务器的差异进行调整，测试环境本身会存在各种软件冲突。而且最新的测试技术无法及时迭代优化。其中pxe为预启动执行环境(preboot execution environment，pxe)也被称为预执行环境，提供了一种使用网络接口(network interface)启动计算机的机制。这种机制让计算机的启动可以不依赖本地数据存储设备(如硬盘)或本地已安装的操作系统。
4.现有技术下，进行单机测试时，通常直接将测试工具放置在物理服务器上，需要手动配置各项测试工具，各种硬件驱动，再依次开启各种稳定性测试。在进行批量整机测试时，通常使用pxe引导方式开启测试。每进行一项新的测试需重新开机引导一次。
5.因此，现有技术进行单机测试需要重复进行测试工具的配置工作，测试工具版本不一致，获取工具的手段不统一。重点是无法及时更新测试工具，导致测试结果不同，影响稳定性测试的结果判断，降低测试工作的有效产出。而使用pxe进行批量测试的过程中，大量时间浪费在开机引导过程中，引导时长客观上是由物理机安装的设备数量决定的，整体开机时长在5-30分钟，且不仅启动引导一次，十分繁琐且效率低。
技术实现要素：6.基于此，有必要针对上述技术问题，提供一种能够通过容器微服务的形式，减小不必要的启动引导动作，节省时间，同时可以避免软件环境冲突问题的设备稳定性测试方法、装置、计算机设备和存储介质。
7.一方面，提供一种设备稳定性测试方法，所述方法包括：
8.按照预设测试项生成对应的微服务；
9.按照待测设备的类型构建多个逻辑测试角色，每一个逻辑测试角色对应一个或多个微服务；以及
10.识别待测设备对应的逻辑测试角色，根据识别出的逻辑测试角色调用对应的微服务对该待测设备进行测试。
11.在其中一个实施例中，所述按照预设测试项生成对应的微服务，包括步骤：
12.根据每一测试项的测试需求将测试需要的测试软件、硬件驱动以及自动化脚本放入容器；以及
13.将所述容器打包为镜像，再将打包好的镜像维护在镜像仓库中形成所述微服务。
14.在其中一个实施例中，在所述将所述容器打包为镜像之前还包括：
15.在所述容器中完成所述测试软件、所述硬件驱动以及所述自动化脚本的测试。
16.在其中一个实施例中，所述识别待测设备对应的逻辑测试角色，包括步骤：
17.实时检测是否存在待测设备的连接；当存在所述待测设备连接时，根据所述待测设备的类型确定其对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试。
18.在其中一个实施例中，所述根据所述待测设备的类型确定其对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试，包括步骤：
19.通过获取该待测设备的型号以确定其对应的逻辑测试角色，其中所述逻辑测试角色与所述待测设备的对应关系为一对多；
20.依据所述逻辑测试角色选择或确认需要进行的测试项，每一测试项关联一个微服务；以及
21.根据所述逻辑测试角色对应的所有测试项调用对应的微服务依次对所述待测设备进行测试。
22.在其中一个实施例中，在所述通过获取该待测设备的型号以确定其对应的逻辑测试角色之前，包括步骤：
23.在所述待测设备上安装操作系统与容器环境，将存储有所述微服务的镜像仓库拉取到所述待测设备的服务器上。
24.在其中一个实施例中，在对所述待测设备进行测试之后，还包括：
25.将测试数据实时回传数据库并存储；
26.识别测试中遇到的问题并修复；以及
27.维护更新所述微服务。
28.再一方面，本技术还提供了一种设备稳定性测试装置，所述装置包括：
29.微服务生成模块，用于按照预设测试项生成对应的微服务；
30.构建逻辑测试角色模块，用于按照待测设备的类型构建多个逻辑测试角色，每一个逻辑测试角色对应一个或多个微服务；
31.测试处理模块，用于识别待测设备对应的逻辑测试角色，并根据识别出的逻辑测试角色调用对应的微服务对该待测设备进行测试。
32.再一方面，本技术还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：
33.按照预设测试项生成对应的微服务；
34.按照待测设备的类型构建多个逻辑测试角色，每一个逻辑测试角色对应一个或多个微服务；以及
35.识别待测设备对应的逻辑测试角色，根据识别出的逻辑测试角色调用对应的微服务对该待测设备进行测试。
36.又一方面，本技术还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：
37.按照预设测试项生成对应的微服务；
38.按照待测设备的类型构建多个逻辑测试角色，每一个逻辑测试角色对应一个或多
个微服务；以及
39.识别待测设备对应的逻辑测试角色，根据识别出的逻辑测试角色调用对应的微服务对该待测设备进行测试。
40.上述设备稳定性测试方法、装置、计算机设备和存储介质，通过将测试需要的测试软件、硬件驱动以及自动化脚本作为测试环境打包进容器镜像内，来获得统一的测试环境，并能使用统一的测试工具；并结合测试管理系统使用逻辑测试角色对应的微服务自动进行稳定性测试，相对于手动配置测试环境，可以及时迭代测试环境，将实验室测试环境与产线测试环境拉通对齐，将实验室待测机与生产待测机统一纳管。这种测试方式因基于测试管理系统通过检测该待测设备的类型获取对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试，不需要重复启动动作，节省了时间，同时可以避免软件环境不同导致的测试工具冲突问题。
附图说明
41.图1为本技术一个实施例中设备稳定性测试方法的应用环境图；
42.图2为本技术实施例1提供的设备稳定性测试方法的流程图；
43.图3为本技术实施例1提供的形成微服务时的流程图；
44.图4为本技术实施例2提供的实现设备稳定性测试方法的原理图；
45.图5为本技术实施例2提供的调用对应的微服务进行测试步骤的流程示意图；
46.图6为本技术实施例3提供的利用人工方式实现设备稳定性测试方法的流程图；
47.图7为本技术实施例3提供的利用人工方式实现设备稳定性测试方法的迭代微服务原理图；
48.图8为本技术实施例3提供的设备稳定性测试方法的流程图；
49.图9为本技术实施例4提供的调用对应的微服务进行测试步骤的流程示意图；
50.图10为本技术一个实施例中设备稳定性测试装置的结构框图；
51.图11为本技术一个实施例中计算机设备的内部结构图。
具体实施方式
52.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。
53.本技术提供的设备稳定性测试方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络和电源分配单元与服务器104进行通信。服务器104作为测试管理系统用于测试设备稳定性，终端102作为待测设备被服务器104测试。在服务器104上通过容器技术封装测试工具进行终端102(待测设备)的稳定性测试，将需要的测试软件、硬件驱动以及自动化脚本打包封装在容器镜像内，再将镜像存储的仓库中，需要进行稳定性测试的人员将镜像加载到本地终端102的linux系统上，在容器内进行自动化的稳定性测试。其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
54.实施例1
55.具体的，如图2所示，在实施例1中，提供了一种设备稳定性测试方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤：
56.步骤s1、按照预设测试项生成对应的微服务。
57.具体地，微服务的形成方式是根据每一测试项的测试需求将测试需要的测试软件、硬件驱动以及自动化脚本放入容器；然后在所述容器中完成所述测试软件、所述硬件驱动以及所述自动化脚本的测试，测试完成后将所述容器打包为镜像(也称容器镜像)，再将打包好的镜像维护在镜像仓库中形成所述微服务。这样形成的用于与测试项匹配的微服务能够统一测试环境，并能使用统一的测试工具对不同的待测设备进行稳定性测试。
58.步骤s2、按照待测设备的类型构建多个逻辑测试角色，每一个逻辑测试角色对应一个或多个微服务。
59.其中将待测设备按其类型对应构建多个逻辑测试角色，可以通过逻辑测试角色将待测设备和一个或多个微服务相匹配，这样能够实现硬件待测设备通过软件设置的逻辑测试角色与微服务关联起来。
60.步骤s3、识别待测设备对应的逻辑测试角色，根据识别出的逻辑测试角色调用对应的微服务对该待测设备进行测试。
61.上述设备稳定性测试方法中，结合测试管理系统使用逻辑测试角色对应的微服务自动进行稳定性测试，相对于手动配置测试环境，可以及时迭代测试环境，将实验室测试环境与产线测试环境拉通对齐，将实验室待测机与生产待测机统一纳管。这种测试方式因基于测试管理系统通过检测该待测设备的类型获取对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试，不需要重复启动动作，节省了时间，同时可以避免软件环境不同导致的测试工具冲突问题。
62.请参阅图3，在本实施例中，在步骤s1中形成微服务时，所述按照预设测试项生成对应的微服务具体包括步骤：
63.步骤s11、根据每一测试项的测试需求将测试需要的测试软件、硬件驱动以及自动化脚本放入容器；
64.步骤s12、在所述容器中完成所述测试软件、所述硬件驱动以及所述自动化脚本的测试；以及
65.步骤s13、测试完成后，将所述容器打包为镜像，再将打包好的镜像维护在镜像仓库中形成所述微服务。
66.其中，容器为linux内一个特殊的进程，通过名称空间(namespace)、控制组(control groups)、切根(chroot)技术把资源、文件、设备、状态和配置划分到一个独立的空间。每个运行的容器都有自己的名称空间(namespace)，这是linux操作系统默认提供的api。控制组是linux内核提供的一种可以限制、记录、隔离进程组的物理资源机制。切根的意思就是改变一个程序运行时参考的根目录位置，让不同容器在不同的虚拟根目录下工作，从而相互不直接影响。镜像是文件，是一个只读的模板，一个独立的文件系统，里面包含运行容器所需的数据，可以用来创建新的容器。
67.其中，仓库(repository)是集中存放镜像文件的场所，仓库分为公开仓库和私有仓库。
68.可理解的是，本技术将每一测试项的测试需求将测试需要的测试软件、硬件驱动
以及自动化脚本放入容器后打包为镜像，再将打包好的镜像维护在镜像仓库中形成所述微服务，是为了获得统一的测试环境，并能使用统一的测试工具，其中测试工具是对物理服务器进行基准测试的软件、驱动等工具的集合。这样可以基于所述微服务形成利用统一的测试环境。
69.实施例2
70.在实施例2中，包含了实施例1的全部技术特征，其区别在于，在实施例2中进一步完善了步骤s3的内容。
71.在步骤s3中，所述识别待测设备对应的逻辑测试角色，包括步骤：实时检测是否存在待测设备的连接；当存在所述待测设备连接时，根据所述待测设备的类型确定其对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试。
72.在本实施例中，在步骤s3中，所述待测设备通过网络与电源分配单元连接至所述测试管理系统，所述测试管理系统获取该待测设备的型号以确定对应的逻辑测试角色。因此，可通过检测是否存在待测设备通过网络与电源分配单元连接至所述测试管理系统来获知是否存在待测设备连接至测试管理系统。
73.在本实施例中，请参阅图4，所述逻辑测试角色与所述待测设备(图中用待测机1、2、3、4...表示)的对应关系为一对多。也就是说，一个逻辑测试角色可以对应多台待测设备，这样就能避免同一型号的多个待测设备同时连接检测的冲突问题。
74.因此，如图5所示，在步骤s3中，所述根据所述待测设备的类型确定其对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试，具体包括以下步骤：
75.步骤s31、通过获取该待测设备的型号以确定其对应的逻辑测试角色，其中所述逻辑测试角色与所述待测设备的对应关系为一对多；
76.步骤s32、依据所述逻辑测试角色确认需要进行的测试项，每一测试项关联一个微服务；以及
77.步骤s33、根据所述逻辑测试角色对应的所有测试项调用对应的微服务依次对所述待测设备进行测试。
78.如图5所示，在一优选实施例中，在将待测设备连接至测试管理系统之前，亦即在所述通过获取该待测设备的型号以确定其对应的逻辑测试角色之前，包括步骤：
79.步骤s30、在所述待测设备上安装操作系统与容器环境，将存储有所述微服务的镜像仓库拉取到所述待测设备的服务器上。
80.如此，便可在同一个操作系统(os)与容器环境下实现不同机型的待测设备测试，实现了测试工具的统一，避免软件环境不同导致的测试工具冲突问题。
81.在本实施例中，将每一个测试项打包为一个微服务，然后结合操作系统(os)与容器环境一起安装在待测设备上，能够在服务器104(测试管理系统)和终端102(待测设备)上获得统一的测试环境。而后在测试管理系统内按照待测机器型号构建各种逻辑测试角色，每种逻辑测试角色对应一系列微服务，当待测设备连接至测试管理系统时，测试管理系统按照逻辑测试角色需要进行的测试项调用不同的微服务进行相关测试，不需要重复启动动作，节省了时间。
82.实施例3
83.在实施例3中，包含了实施例2的全部技术特征，其区别在于，在实施例3中进一步完善了步骤s3之后的维护更新容器镜像和迭代微服务等内容。
84.可理解的是，本技术利用人工方式也可实现上述设备稳定性测试方法的操作，具体请参阅图6，实现时主要包括以下几个步骤：
85.步骤s01、容器镜像维护人员根据需求将测试需要的测试软件、硬件驱动以及自动化脚本作为测试工具放入容器；
86.步骤s02、镜像维护人员在容器中手动测试各种测试工具，完成后将容器打包为镜像，将打包好的镜像维护在镜像仓库中，作为基础的微服务；
87.步骤s03、在测试管理系统中，根据待测机器型号定义一个逻辑测试角色，通过网络连接与电源分配单元(pdu)电源连接将逻辑测试角色与待测机器关联起来，逻辑测试角色与待测机器对应关系为一对多；
88.步骤s04、在测试管理系统中为逻辑测试角色分配多个测试用例的微服务；
89.步骤s05、逻辑测试角色按照提前排布的任务自动执行测试用例；
90.步骤s06、测试管理系统将测试数据实时回传数据库，以供后续分析；
91.步骤s07、测试人员将测试中遇到的问题反馈给镜像维护人员；
92.步骤s08、容器镜像维护人员修复问题后维护更新容器镜像，迭代微服务。
93.请参阅图7，为了更加清晰地表示出迭代微服务的流程，采用反馈箭头方式表示迭代更新路径。
94.因此，请参阅图8，同理，在对所述待测设备进行测试之后，还包括：
95.步骤s4、将测试数据实时回传数据库并存储；
96.步骤s5、识别测试中遇到的问题并修复；以及
97.步骤s6、维护更新所述微服务。
98.在本实施例中，相对于手动配置测试环境，可以及时迭代测试环境，将实验室测试环境与产线测试环境拉通对齐，将实验室待测机与生产待测机统一纳管。而且可根据回传的测试数据分析测试中遇到的问题，找出对应的解决方案，容器镜像维护人员修复问题后维护更新容器镜像，实现迭代微服务的操作，保证了及时维护更新测试环境。
99.实施例4
100.在实施例4中，包含了实施例3的全部技术特征，其区别在于，在实施例4中为了更便于测试人员的操作，提升可操作性，降低操作难度，减少对测试人员的技术能力要求，基于逻辑测试角色进一步设置了与逻辑测试角色关联的测试项为可编排模式。其中可编排模式包括选择所述逻辑测试角色相关的测试项，而不是系统自动确认所述逻辑测试角色相关的测试项。
101.如图9所示，在步骤s3中，所述根据所述待测设备的类型确定其对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试，具体包括以下步骤：
102.步骤s301、通过获取该待测设备的型号以确定其对应的逻辑测试角色，其中所述逻辑测试角色与所述待测设备的对应关系为一对多；
103.步骤s302、依据所述逻辑测试角色选择需要进行的测试项，每一测试项关联一个微服务；以及
104.步骤s303、根据所述逻辑测试角色对应的所有测试项调用对应的微服务依次对所述待测设备进行测试。
105.其中步骤s302中的依据所述逻辑测试角色选择需要进行的测试项，可理解为增加了一步编排测试项的操作窗口，更利于调整待测设备的测试内容，有利于实验室研发使用。而且编排测试项的操作窗口可对应选择需要进行的测试项，这样能够将测试项关联的微服务与待测设备相匹配在一起，实现根据实际需求增加或者减少测试项的操作，提升了调整待测设备的测试内容的便捷性，更便于测试人员的操作，降低了操作难度，减少对测试人员的技术能力要求。
106.如图9所示，在一优选实施例中，在将待测设备连接至测试管理系统之前，亦即在所述通过获取该待测设备的型号以确定其对应的逻辑测试角色之前，包括步骤：
107.步骤s300、在所述待测设备上安装操作系统与容器环境，将存储有所述微服务的镜像仓库拉取到所述待测设备的服务器上。
108.其中步骤s300可实现在同一个操作系统(os)与容器环境下实现不同机型的待测设备测试，实现了测试工具的统一，避免软件环境不同导致的测试工具冲突问题。将每一个测试项打包为一个微服务，然后结合操作系统(os)与容器环境一起安装在待测设备上，能够在服务器104(测试管理系统)和终端102(待测设备)上获得统一的测试环境。而后在测试管理系统内按照待测机器型号构建各种逻辑测试角色，每种逻辑测试角色对应一系列微服务，当待测设备连接至测试管理系统时，测试管理系统按照逻辑测试角色需要进行的测试项调用不同的微服务进行相关测试，不需要重复启动动作，节省了时间。
109.应该理解的是，虽然图2-9的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-9中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
110.在一个实施例中，如图10所示，提供了一种设备稳定性测试装置10，包括：微服务生成模块1、构建逻辑测试角色模块2和测试处理模块3。
111.所述微服务生成模块1用于按照预设测试项生成对应的微服务。
112.所述构建逻辑测试角色模块2用于按照待测设备的类型构建多个逻辑测试角色，每一个逻辑测试角色对应一个或多个微服务。
113.所述测试处理模块3用于识别待测设备对应的逻辑测试角色，并根据识别出的逻辑测试角色调用对应的微服务对该待测设备进行测试。
114.具体地，微服务生成模块1用于形成微服务的方式是：根据每一测试项的测试需求将测试需要的测试软件、硬件驱动以及自动化脚本放入容器；然后在所述容器中完成所述测试软件、所述硬件驱动以及所述自动化脚本的测试，测试完成后将所述容器打包为镜像(也称容器镜像)，再将打包好的镜像维护在镜像仓库中形成所述微服务。这样形成的用于与测试项匹配的微服务能够统一测试环境，并能使用统一的测试工具对不同的待测设备进行稳定性测试。
115.因此，所述微服务生成模块1用于按照预设测试项生成对应的微服务具体包括：根据每一测试项的测试需求将测试需要的测试软件、硬件驱动以及自动化脚本放入容器；在所述容器中完成所述测试软件、所述硬件驱动以及所述自动化脚本的测试；以及在测试完成后，将所述容器打包为镜像，再将打包好的镜像维护在镜像仓库中形成所述微服务。
116.可理解的是，所述微服务生成模块1用于将每一测试项的测试需求将测试需要的测试软件、硬件驱动以及自动化脚本放入容器后打包为镜像，再将打包好的镜像维护在镜像仓库中形成所述微服务，是为了获得统一的测试环境，并能使用统一的测试工具，其中测试工具是对物理服务器进行基准测试的软件、驱动等工具的集合。这样可以基于所述微服务形成利用统一的测试环境。
117.其中所述构建逻辑测试角色模块2用于将待测设备按其类型对应构建多个逻辑测试角色，可以通过逻辑测试角色将待测设备和一个或多个微服务相匹配，这样能够实现硬件待测设备通过软件设置的逻辑测试角色与微服务关联起来。
118.所述测试处理模块3用于识别待测设备对应的逻辑测试角色，结合逻辑测试角色对应的微服务自动进行稳定性测试，相对于手动配置测试环境，可以及时迭代测试环境，将实验室测试环境与产线测试环境拉通对齐，将实验室待测机与生产待测机统一纳管。这种测试方式因基于测试管理系统通过检测该待测设备的类型获取对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试，不需要重复启动动作，节省了时间，同时可以避免软件环境不同导致的测试工具冲突问题。
119.其中，所述测试处理模块3用于所述识别待测设备对应的逻辑测试角色，包括用于：实时检测是否存在待测设备的连接；当存在所述待测设备连接时，根据所述待测设备的类型确定其对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试。
120.在本实施例中，所述待测设备通过网络与电源分配单元连接至所述测试管理系统，所述测试处理模块3用于检测所述待测设备连接至所述测试管理系统的状态，并获取该待测设备的型号以确定对应的逻辑测试角色。因此，所述测试处理模块3可通过检测是否存在待测设备通过网络与电源分配单元连接至所述测试管理系统来获知是否存在待测设备连接至测试管理系统。
121.在本实施例中，请参阅图4，所述逻辑测试角色与所述待测设备(图中用待测机1、2、3、4...表示)的对应关系为一对多。也就是说，一个逻辑测试角色可以对应多台待测设备，这样就能避免同一型号的多个待测设备同时连接检测的冲突问题。
122.因此，所述测试处理模块3用于所述根据所述待测设备的类型确定其对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试，具体包括用于：通过获取该待测设备的型号以确定其对应的逻辑测试角色，其中所述逻辑测试角色与所述待测设备的对应关系为一对多；依据所述逻辑测试角色确认需要进行的测试项，每一测试项关联一个微服务；以及根据所述逻辑测试角色对应的所有测试项调用对应的微服务依次对所述待测设备进行测试。
123.在一优选实施例中，在将待测设备连接至测试管理系统之前，亦即在所述通过获取该待测设备的型号以确定其对应的逻辑测试角色之前，在所述待测设备上安装操作系统与容器环境，将存储有所述微服务的镜像仓库拉取到所述待测设备的服务器上。如此，便可
在同一个操作系统(os)与容器环境下实现不同机型的待测设备测试，实现了测试工具的统一，避免软件环境不同导致的测试工具冲突问题。
124.在本实施例中，请参阅统图1，将每一个测试项打包为一个微服务，然后结合操作系统(os)与容器环境一起安装在待测设备上，能够在服务器104(测试管理系统)和终端102(待测设备)上获得统一的测试环境。而后在测试管理系统内按照待测机器型号构建各种逻辑测试角色，每种逻辑测试角色对应一系列微服务，当待测设备连接至测试管理系统时，测试管理系统按照逻辑测试角色需要进行的测试项调用不同的微服务进行相关测试，不需要重复启动动作，节省了时间。
125.在一优选实施例中，如图10所示，所述设备稳定性测试装置10还包括：维护更新模块4。所述维护更新模块4用于将测试数据实时回传数据库并存储，识别测试中遇到的问题并修复，维护更新所述微服务。
126.在本实施例中，相对于手动配置测试环境，所述维护更新模块4可以及时迭代测试环境，将实验室测试环境与产线测试环境拉通对齐，将实验室待测机与生产待测机统一纳管。而且可根据回传的测试数据分析测试中遇到的问题，找出对应的解决方案，容器镜像维护人员修复问题后维护更新容器镜像，实现迭代微服务的操作，保证了及时维护更新测试环境。
127.在一优选实施例中，如图10所示，所述设备稳定性测试装置10中，所述测试处理模块3还包括关联逻辑测试角色模块31、选择测试项模块32和微服务测试执行模块33。
128.其中所述选择测试项模块32是基于逻辑测试角色进一步设置了与逻辑测试角色关联的测试项为可编排模式。可编排模式包括选择所述逻辑测试角色相关的测试项，而不是系统自动确认所述逻辑测试角色相关的测试项。
129.在所述测试处理模块3根据所述待测设备的类型确定其对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试时，关联逻辑测试角色模块31、选择测试项模块32和微服务测试执行模块33各自执行相关步骤。
130.所述关联逻辑测试角色模块31用于通过获取该待测设备的型号以确定其对应的逻辑测试角色，其中所述逻辑测试角色与所述待测设备的对应关系为一对多。
131.所述选择测试项模块32用于依据所述逻辑测试角色选择需要进行的测试项，每一测试项关联一个微服务。
132.所述微服务测试执行模块33用于根据所述逻辑测试角色对应的所有测试项调用对应的微服务依次对所述待测设备进行测试。
133.其中所述选择测试项模块32中依据所述逻辑测试角色选择需要进行的测试项，可理解为所述选择测试项模块32是编排测试项的操作窗口，更利于调整待测设备的测试内容，有利于实验室研发使用。而且编排测试项的操作窗口可对应选择需要进行的测试项，这样能够将测试项关联的微服务与待测设备相匹配在一起，实现根据实际需求增加或者减少测试项的操作，提升了调整待测设备的测试内容的便捷性，更便于测试人员的操作，降低了操作难度，减少对测试人员的技术能力要求。
134.关于设备稳定性测试装置10的具体限定可以参见上文中对于设备稳定性测试方法的限定，在此不再赘述。上述设备稳定性测试装置10中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理
器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
135.在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图11所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储设备稳定性测试数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种设备稳定性测试方法。
136.本领域技术人员可以理解，图11中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
137.在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，请参阅图2，处理器执行计算机程序时实现以下步骤s1-s3。
138.步骤s1、按照预设测试项生成对应的微服务。
139.具体地，微服务的形成方式是根据每一测试项的测试需求将测试需要的测试软件、硬件驱动以及自动化脚本放入容器；然后在所述容器中完成所述测试软件、所述硬件驱动以及所述自动化脚本的测试，测试完成后将所述容器打包为镜像(也称容器镜像)，再将打包好的镜像维护在镜像仓库中形成所述微服务。这样形成的用于与测试项匹配的微服务能够统一测试环境，并能使用统一的测试工具对不同的待测设备进行稳定性测试。
140.请参阅图3，在本实施例中，在步骤s1中形成微服务时，处理器执行计算机程序时实现所述按照预设测试项生成对应的微服务具体包括步骤：
141.步骤s11、根据每一测试项的测试需求将测试需要的测试软件、硬件驱动以及自动化脚本放入容器；
142.步骤s12、在所述容器中完成所述测试软件、所述硬件驱动以及所述自动化脚本的测试；以及
143.步骤s13、测试完成后，将所述容器打包为镜像，再将打包好的镜像维护在镜像仓库中形成所述微服务。
144.步骤s2、按照待测设备的类型构建多个逻辑测试角色，每一个逻辑测试角色对应一个或多个微服务。
145.其中将待测设备按其类型对应构建多个逻辑测试角色，可以通过逻辑测试角色将待测设备和一个或多个微服务相匹配，这样能够实现硬件待测设备通过软件设置的逻辑测试角色与微服务关联起来。
146.步骤s3、识别待测设备对应的逻辑测试角色，根据识别出的逻辑测试角色调用对应的微服务对该待测设备进行测试。
147.结合测试管理系统使用逻辑测试角色对应的微服务自动进行稳定性测试，相对于手动配置测试环境，可以及时迭代测试环境，将实验室测试环境与产线测试环境拉通对齐，将实验室待测机与生产待测机统一纳管。这种测试方式因基于测试管理系统通过检测该待
测设备的类型获取对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试，不需要重复启动动作，节省了时间，同时可以避免软件环境不同导致的测试工具冲突问题。
148.如图5所示，在处理器执行计算机程序时实现步骤s3时，具体包括以下步骤：
149.步骤s31、通过获取该待测设备的型号以确定其对应的逻辑测试角色，其中所述逻辑测试角色与所述待测设备的对应关系为一对多；
150.步骤s32、依据所述逻辑测试角色确认需要进行的测试项，每一测试项关联一个微服务；以及
151.步骤s33、根据所述逻辑测试角色对应的所有测试项调用对应的微服务依次对所述待测设备进行测试。
152.或者如图9所示，在处理器执行计算机程序时实现步骤s3时，具体包括以下步骤：
153.步骤s301、通过获取该待测设备的型号以确定其对应的逻辑测试角色，其中所述逻辑测试角色与所述待测设备的对应关系为一对多；
154.步骤s302、依据所述逻辑测试角色选择需要进行的测试项，每一测试项关联一个微服务；以及
155.步骤s303、根据所述逻辑测试角色对应的所有测试项调用对应的微服务依次对所述待测设备进行测试。
156.其中步骤s302中的依据所述逻辑测试角色选择需要进行的测试项，可理解为增加了一步编排测试项的操作窗口，更利于调整待测设备的测试内容，有利于实验室研发使用。而且编排测试项的操作窗口可对应选择需要进行的测试项，这样能够将测试项关联的微服务与待测设备相匹配在一起，实现根据实际需求增加或者减少测试项的操作，提升了调整待测设备的测试内容的便捷性，更便于测试人员的操作，降低了操作难度，减少对测试人员的技术能力要求。
157.在一优选实施例中，在将待测设备连接至测试管理系统之前，亦即在所述通过获取该待测设备的型号以确定其对应的逻辑测试角色之前，在所述待测设备上安装操作系统与容器环境，将存储有所述微服务的镜像仓库拉取到所述待测设备的服务器上。如此，便可在同一个操作系统(os)与容器环境下实现不同机型的待测设备测试，实现了测试工具的统一，避免软件环境不同导致的测试工具冲突问题。
158.在本实施例中，将每一个测试项打包为一个微服务，然后结合操作系统(os)与容器环境一起安装在待测设备上，能够在服务器104(测试管理系统)和终端102(待测设备)上获得统一的测试环境。而后在测试管理系统内按照待测机器型号构建各种逻辑测试角色，每种逻辑测试角色对应一系列微服务，当待测设备连接至测试管理系统时，测试管理系统按照逻辑测试角色需要进行的测试项调用不同的微服务进行相关测试，不需要重复启动动作，节省了时间。
159.在一个实施例中，请参阅图8，处理器执行计算机程序时还实现以下步骤：
160.步骤s4、将测试数据实时回传数据库并存储；
161.步骤s5、识别测试中遇到的问题并修复；以及
162.步骤s6、维护更新所述微服务。
163.在本实施例中，相对于手动配置测试环境，可以及时迭代测试环境，将实验室测试
环境与产线测试环境拉通对齐，将实验室待测机与生产待测机统一纳管。而且可根据回传的测试数据分析测试中遇到的问题，找出对应的解决方案，容器镜像维护人员修复问题后维护更新容器镜像，实现迭代微服务的操作，保证了及时维护更新测试环境。
164.在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，请参阅图2，计算机程序被处理器执行时实现以下步骤s1-s3。
165.步骤s1、按照预设测试项生成对应的微服务。
166.具体地，微服务的形成方式是根据每一测试项的测试需求将测试需要的测试软件、硬件驱动以及自动化脚本放入容器；然后在所述容器中完成所述测试软件、所述硬件驱动以及所述自动化脚本的测试，测试完成后将所述容器打包为镜像(也称容器镜像)，再将打包好的镜像维护在镜像仓库中形成所述微服务。这样形成的用于与测试项匹配的微服务能够统一测试环境，并能使用统一的测试工具对不同的待测设备进行稳定性测试。
167.请参阅图3，在本实施例中，在步骤s1中形成微服务时，计算机程序被处理器执行时实现所述按照预设测试项生成对应的微服务具体包括步骤：
168.步骤s11、根据每一测试项的测试需求将测试需要的测试软件、硬件驱动以及自动化脚本放入容器；
169.步骤s12、在所述容器中完成所述测试软件、所述硬件驱动以及所述自动化脚本的测试；以及
170.步骤s13、测试完成后，将所述容器打包为镜像，再将打包好的镜像维护在镜像仓库中形成所述微服务。
171.步骤s2、按照待测设备的类型构建多个逻辑测试角色，每一个逻辑测试角色对应一个或多个微服务。
172.其中将待测设备按其类型对应构建多个逻辑测试角色，可以通过逻辑测试角色将待测设备和一个或多个微服务相匹配，这样能够实现硬件待测设备通过软件设置的逻辑测试角色与微服务关联起来。
173.步骤s3、识别待测设备对应的逻辑测试角色，根据识别出的逻辑测试角色调用对应的微服务对该待测设备进行测试。
174.结合测试管理系统使用逻辑测试角色对应的微服务自动进行稳定性测试，相对于手动配置测试环境，可以及时迭代测试环境，将实验室测试环境与产线测试环境拉通对齐，将实验室待测机与生产待测机统一纳管。这种测试方式因基于测试管理系统通过检测该待测设备的类型获取对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试，不需要重复启动动作，节省了时间，同时可以避免软件环境不同导致的测试工具冲突问题。
175.如图,5所示，在计算机程序被处理器执行实现步骤s3时，具体包括以下步骤：
176.步骤s31、通过获取该待测设备的型号以确定其对应的逻辑测试角色，其中所述逻辑测试角色与所述待测设备的对应关系为一对多；
177.步骤s32、依据所述逻辑测试角色确认需要进行的测试项，每一测试项关联一个微服务；以及
178.步骤s33、根据所述逻辑测试角色对应的所有测试项调用对应的微服务依次对所述待测设备进行测试。
179.或者如图9所示，在计算机程序被处理器执行实现步骤s3时，具体包括以下步骤：
180.步骤s301、通过获取该待测设备的型号以确定其对应的逻辑测试角色，其中所述逻辑测试角色与所述待测设备的对应关系为一对多；
181.步骤s302、依据所述逻辑测试角色选择需要进行的测试项，每一测试项关联一个微服务；以及
182.步骤s303、根据所述逻辑测试角色对应的所有测试项调用对应的微服务依次对所述待测设备进行测试。
183.其中步骤s302中的依据所述逻辑测试角色选择需要进行的测试项，可理解为增加了一步编排测试项的操作窗口，更利于调整待测设备的测试内容，有利于实验室研发使用。而且编排测试项的操作窗口可对应选择需要进行的测试项，这样能够将测试项关联的微服务与待测设备相匹配在一起，实现根据实际需求增加或者减少测试项的操作，提升了调整待测设备的测试内容的便捷性，更便于测试人员的操作，降低了操作难度，减少对测试人员的技术能力要求。
184.在一优选实施例中，在将待测设备连接至测试管理系统之前，亦即在所述通过获取该待测设备的型号以确定其对应的逻辑测试角色之前，在所述待测设备上安装操作系统与容器环境，将存储有所述微服务的镜像仓库拉取到所述待测设备的服务器上。如此，便可在同一个操作系统(os)与容器环境下实现不同机型的待测设备测试，实现了测试工具的统一，避免软件环境不同导致的测试工具冲突问题。
185.在本实施例中，将每一个测试项打包为一个微服务，然后结合操作系统(os)与容器环境一起安装在待测设备上，能够在服务器104(测试管理系统)和终端102(待测设备)上获得统一的测试环境。而后在测试管理系统内按照待测机器型号构建各种逻辑测试角色，每种逻辑测试角色对应一系列微服务，当待测设备连接至测试管理系统时，测试管理系统按照逻辑测试角色需要进行的测试项调用不同的微服务进行相关测试，不需要重复启动动作，节省了时间。
186.在一个实施例中，请参阅图8，计算机程序被处理器执行时还实现以下步骤：
187.步骤s4、将测试数据实时回传数据库并存储；
188.步骤s5、识别测试中遇到的问题并修复；以及
189.步骤s6、维护更新所述微服务。
190.在本实施例中，相对于手动配置测试环境，可以及时迭代测试环境，将实验室测试环境与产线测试环境拉通对齐，将实验室待测机与生产待测机统一纳管。而且可根据回传的测试数据分析测试中遇到的问题，找出对应的解决方案，容器镜像维护人员修复问题后维护更新容器镜像，实现迭代微服务的操作，保证了及时维护更新测试环境。
191.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，
诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。
192.以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
193.以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术专利的保护范围应以所附权利要求为准。
技术特征：1.一种设备稳定性测试方法，其特征在于，包括步骤：按照预设测试项生成对应的微服务；按照待测设备的类型构建多个逻辑测试角色，每一个逻辑测试角色对应一个或多个微服务；以及识别待测设备对应的逻辑测试角色，根据识别出的逻辑测试角色调用对应的微服务对该待测设备进行测试。2.根据权利要求1所述的设备稳定性测试方法，其特征在于，所述按照预设测试项生成对应的微服务，包括步骤：根据每一测试项的测试需求将测试需要的测试软件、硬件驱动以及自动化脚本放入容器；以及将所述容器打包为镜像，再将打包好的镜像维护在镜像仓库中形成所述微服务。3.根据权利要求2所述的设备稳定性测试方法，其特征在于，在所述将所述容器打包为镜像之前还包括：在所述容器中完成所述测试软件、所述硬件驱动以及所述自动化脚本的测试。4.根据权利要求1所述的设备稳定性测试方法，其特征在于，所述识别待测设备对应的逻辑测试角色，包括步骤：实时检测是否存在待测设备的连接；当存在所述待测设备连接时，根据所述待测设备的类型确定其对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试。5.根据权利要求4所述的设备稳定性测试方法，其特征在于，所述根据所述待测设备的类型确定其对应的逻辑测试角色，并依据所述逻辑测试角色需要进行的测试项调用对应的微服务进行测试，包括步骤：通过获取该待测设备的型号以确定其对应的逻辑测试角色，其中所述逻辑测试角色与所述待测设备的对应关系为一对多；依据所述逻辑测试角色选择或确认需要进行的测试项，每一测试项关联一个微服务；以及根据所述逻辑测试角色对应的所有测试项调用对应的微服务依次对所述待测设备进行测试。6.根据权利要求5所述的设备稳定性测试方法，其特征在于，在所述通过获取该待测设备的型号以确定其对应的逻辑测试角色之前，包括步骤：在所述待测设备上安装操作系统与容器环境，将存储有所述微服务的镜像仓库拉取到所述待测设备的服务器上。7.根据权利要求5所述的设备稳定性测试方法，其特征在于，在对所述待测设备进行测试之后，还包括：将测试数据实时回传数据库并存储；识别测试中遇到的问题并修复；以及维护更新所述微服务。8.一种设备稳定性测试装置，其特征在于，所述装置包括：微服务生成模块，用于按照预设测试项生成对应的微服务；
构建逻辑测试角色模块，用于按照待测设备的类型构建多个逻辑测试角色，每一个逻辑测试角色对应一个或多个微服务；测试处理模块，用于识别待测设备对应的逻辑测试角色，并根据识别出的逻辑测试角色调用对应的微服务对该待测设备进行测试。9.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。
技术总结本申请涉及一种设备稳定性测试方法、装置、计算机设备和存储介质。所述方法包括：按照预设测试项生成对应的微服务；按照待测设备的类型构建多个逻辑测试角色，每一个逻辑测试角色对应一个或多个微服务；以及识别待测设备对应的逻辑测试角色，根据识别出的逻辑测试角色调用对应的微服务对该待测设备进行测试。采用本方法能够获得统一的测试环境，并能使用统一的测试工具，不需要重复启动动作，节省了时间，同时可以避免软件环境不同导致的测试工具冲突问题。突问题。突问题。
技术研发人员：张显恒
受保护的技术使用者：苏州浪潮智能科技有限公司
技术研发日：2022.07.22
技术公布日：2022/11/1
