服务器的控制方法、控制端服务器和电子设备与流程

1.本技术实施例涉及服务器测试领域，具体而言，涉及一种服务器的控制方法、控制端服务器、计算机可读存储介质和电子设备。


背景技术：

2.当前服务器系统保留了uefi(unified extensible firmware interface，统一可扩展固件接口，简称uefi)和legacy(保留系统)两种启动模式，legacy和uefi是指计算机主板上存储固件的不同方式，可通过修改bios(basic input output system，基本输入输出系统，简称bios)选项进行模式切换。这两种服务器启动模式，都是服务器bios测试的重要测试模块。在对服务器进行测试时需要将两种模式进行切换，在uefi模式和legacy模式进行切换时，可能会出现访问磁盘出错等原因概率性进入紧急模式等情况，无法正常进入服务器的操作系统。
3.图1示出了现有技术中服务器测试方法的流程图，采取手动测试或半自动化测试的方式：测试服务开始，准备好待测服务器，判断当前测试任务所需启动模式为uefi或legacy，在uefi的情况下，bios切换为uefi模式，在legacy的情况下，bios切换为legacy模式；在切换模式之后，重启待测试服务器；切换成功，进入操作系统os(operation system)1(uefi)或者操作系统os(operation system)2(legacy)，继续测试；切换失败，进入紧急模式，测试任务失败。在服务器进入紧急模式的情况下，需要人工手动查找原因并进行相应的处理，存在人力的浪费以及测试效率较低等缺点。
4.因此，需要一种解决现有技术中人工处理模式切换错误造成的效率低的方法。


技术实现要素：

5.本技术实施例提供了一种服务器的控制方法、控制端服务器、计算机可读存储介质和电子设备，以至少解决相关技术中人工处理模式切换错误时效率低的问题。
6.根据本技术的一个实施例，提供了一种服务器的控制方法，包括：在测试端服务器进入紧急模式的情况下，控制端服务器接收监测工具发送的当前错误信息，其中，所述紧急模式表示所述测试端服务器的启动模式修改失败，所述当前错误信息为表征所述测试端服务器当前进入所述紧急模式的信息；所述控制端服务器根据所述当前错误信息确定当前错误原因，并获取所述当前错误原因对应的当前解决方案脚本；所述控制端服务器执行所述当前解决方案脚本，以控制所述测试端服务器退出所述紧急模式，其中，所述当前错误原因和所述当前解决方案脚本一一对应。
7.在一个示例性实施例中，在控制端服务器接收监测工具发送的当前错误信息之前，还包括：所述控制端服务器获取目标测试程序，确定所述目标测试程序中的目标启动模式，其中，所述目标测试程序用于对所述测试端服务器的所述目标启动模式进行测试；所述控制端服务器将所述测试端服务器的当前启动模式修改为所述目标启动模式；所述控制端服务器执行所述目标测试程序，以对所述测试端服务器的目标启动模式进行测试。
8.在一个示例性实施例中，在控制端服务器接收监测工具发送的当前错误信息之前，还包括：在所述控制端服务器执行所述目标测试程序的情况下，开启所述监测工具，以使所述监测工具在监测到所述当前错误信息的情况下，确定所述测试端服务器进入所述紧急模式，并将所述当前错误信息发送至所述控制端服务器，其中，所述当前错误信息是所述监测工具从所述测试端服务器的日志文件中的服务器状态信息为所述紧急模式的情况下获取的，所述服务器状态信息表示所述测试端服务器的当前状态，包括正常模式和所述紧急模式。
9.在一个示例性实施例中，在所述控制端服务器将所述测试端服务器的当前启动模式修改为所述目标启动模式之后，还包括：所述控制端服务器控制所述测试端服务器重新启动。
10.在一个示例性实施例中，所述控制端服务器获取所述当前错误原因对应的当前解决方案脚本，包括：所述控制端服务器获取包括历史错误原因与对应的历史解决方案脚本的映射文件；所述控制端服务器确定与所述当前错误原因相同的所述历史错误原因为目标历史错误原因，并根据所述映射文件确定与所述目标历史错误原因对应的所述历史解决方案脚本为所述当前错误原因对应的所述当前解决方案脚本。
11.在一个示例性实施例中，所述方法还包括：所述控制端服务器获取导致所述紧急模式出现的多个历史错误原因与每个所述历史错误原因对应的每个历史解决方案脚本，得到多个所述历史解决方案脚本；所述控制端服务器将包括所述历史错误原因与对应的所述历史解决方案脚本的映射文件存储至目标存储单元，其中，所述历史错误原因与所述历史解决方案脚本一一对应。
12.在一个示例性实施例中，在控制端服务器接收监测工具发送的当前错误信息之后，还包括：所述控制端服务器对所述测试端服务器进入所述紧急模式情况下的界面进行控制。
13.根据本技术的另一个实施例，提供了一种服务器的控制方法，包括：在测试端服务器的启动模式修改失败的情况下，所述测试端服务器进入紧急模式并输出当前错误信息，监测工具将监测到的所述当前错误信息发送至控制端服务器，其中，所述紧急模式表示所述测试端服务器的所述启动模式修改失败，所述当前错误信息为表征所述测试端服务器当前进入所述紧急模式的信息；所述控制端服务器接收所述监测工具发送的所述当前错误信息，根据所述当前错误信息确定当前错误原因，获取所述当前错误原因对应的当前解决方案脚本，并执行所述当前解决方案脚本，以控制所述测试端服务器退出所述紧急模式，其中，所述当前错误原因和所述当前解决方案脚本一一对应。
14.根据本技术的再一个实施例，还提供了一种控制端服务器，包括：在测试端服务器进入紧急模式的情况下，控制端服务器接收监测工具发送的当前错误信息，其中，所述紧急模式表示所述测试端服务器的启动模式修改失败，所述当前错误信息为表征所述测试端服务器当前进入所述紧急模式的信息；所述控制端服务器根据所述当前错误信息确定当前错误原因，并获取所述当前错误原因对应的当前解决方案脚本；所述控制端服务器执行所述当前解决方案脚本，以控制所述测试端服务器退出所述紧急模式，其中，所述当前错误原因和所述当前解决方案脚本一一对应。
15.根据本技术的又一个实施例，还提供了一种计算机可读存储介质，所述计算机可
读存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一种方法实施例中的步骤。
16.根据本技术的又一个实施例，还提供了一种电子设备，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一种方法实施例中的步骤。
17.通过本技术，控制端服务器通过监测工具，自动监测测试端服务器是否进入紧急模式，在测试端服务器进入紧急模式的情况下，监测工具将监测到的当前错误信息发送至控制端服务器，控制端服务器接收当前错误信息，根据当前错误信息确定当前错误原因并查找与当前错误原因对应的当前解决方案脚本，执行解决方案脚本，使测试端服务器退出紧急模式。与现有技术中，在测试端服务器进入紧急模式的情况下，需要人工根据当前错误原因查找解决方案以使测试端退出紧急模式的方法相比，本技术无需人工参与即可自动根据当前错误原因确定对应的解决方案脚本并执行，因此，可以解决现有技术中人工处理服务器的紧急模式效率低问题，避免因服务器进入紧急模式而耽误测试进程的问题，提高了服务器的测试效率。
附图说明
18.图1是现有技术中一种服务器的测试方法的流程图；
19.图2是根据本技术实施例的一种服务器的控制方法的移动终端的硬件结构框图；
20.图3是根据本技术实施例的一种服务器的控制方法的流程图；
21.图4是根据本技术实施例的一种具体的服务器的控制方法的流程图；
22.图5是根据本技术实施例的一种控制端服务器的结构框图。
23.其中，上述附图包括以下附图标记：
24.102、处理器；104、存储器；106、传输设备；108、输入输出设备。
具体实施方式
25.下文中将参考附图并结合实施例来详细说明本技术的实施例。
26.需要说明的是，本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
27.本技术实施例中所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在移动终端上为例，图2是本技术实施例的一种服务器的控制方法的移动终端的硬件结构框图。如图2所示，移动终端可以包括一个或多个(图2中仅示出一个)处理器102(处理器102可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)和用于存储数据的存储器104，其中，上述移动终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图2所示的结构仅为示意，其并不对上述移动终端的结构造成限定。例如，移动终端还可包括比图2中所示更多或者更少的组件，或者具有与图2所示不同的配置。
28.存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本技术实施例中的服务器的控制方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可
包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至移动终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
29.传输设备106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终端的通信供应商提供的无线网络。在一个实例中，传输设备106包括一个网络适配器(network interface controller，简称为nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输设备106可以为射频(radio frequency，简称为rf)模块，其用于通过无线方式与互联网进行通讯。
30.为了便于描述，以下对本技术涉及的名词进行解释：
31.em：emergency mode，紧急模式；
32.hdd：hard disk，硬盘；
33.uefi：unified extensible firmware interface，统一可扩展固件接口；
34.bios：basic input output system，基本输入输出系统。
35.在本实施例中提供了一种运行于上述移动终端的服务器的控制方法，图3是根据本技术实施例的一种服务器的控制方法的流程图，如图3所示，该流程包括如下步骤：
36.步骤s302，在测试端服务器进入紧急模式的情况下，控制端服务器接收监测工具发送的当前错误信息，其中，上述紧急模式表示上述测试端服务器的启动模式修改失败，上述当前错误信息为表征上述测试端服务器当前进入上述紧急模式的信息；
37.具体地，控制端服务器与测试端服务器通过远程连接来对测试端服务器进行测试，测试端服务器同时配备uefi(unified extensible firmware interface，统一可扩展固件接口)和legacy(传统)模式下安装的两种操作系统，操作系统为ip(internet protocol address)地址可以连接的开机状态；控制端服务器完成测试脚本、监测工具等部署，控制端服务器和测试端服务器处于可以连接的开机状态，可对测试端服务器ssh(secure shell，远程连接服务)连接控制。即测试端服务器的启动模式有uefi模式和legacy模式，legacy和uefi是指计算机主板上存储固件的不同方式，它们都是系统启动的基本要素。legacy基于bios(基本输入输出系统)技术，而uefi则是新一代替代品，它支持更多功能和更高效的启动系统。因此，在服务器的测试过程中，两种启动模式都需要进行测试，因此，在测试完一种模式之后，需要将服务器的启动模式切换为另一种模式，必然会存在切换失败的情况，例如：会出现远端访问磁盘出错或系统switch-root(切换路径)失败等原因概率性进入紧急模式等情况，这种情况下测试端服务器会出报错信息，测试端服务器的日志文件也会记录此次紧急模式以及相关的错误信息，控制端服务器通过监测工具对测试端服务器进行监测，当监测到当前错误信息的情况下，将当前错误信息发送至控制端服务器，控制端服务器接收监测工具发送的当前错误信息。这样可以使控制端服务器接收当前错误信息并进一步根据当前错误信息对测试端服务器进行处理。虽然上述legacy技术目前已经逐渐被uefi所取代，但在某些应用场景下，legacy技术仍然有其不可替代的优势。legacy systems(保留系统)也提供了一些不可替代的服务。而建立新的客户机服务器(uefi)系统以替代现存的保留系统(legacy systems)是一种耗资巨大的举动，所以目前存在继续保留现用系统的趋势。因此，当前服务器系统保留了uefi和legacy两种启动模式，可
通过修改服务器的bios选项进行两种模式之间的切换。因此，这两种服务器启动模式，都是服务器bios测试的重要测试模块。
38.步骤s304，上述控制端服务器根据上述当前错误信息确定当前错误原因，并获取上述当前错误原因对应的当前解决方案脚本；
39.具体地，在接收到监测工具发送的当前错误信息之后，控制端服务器确定对应的当前错误原因，并查找对应的解决方案脚本。具体实现过程中，控制端服务器的相关存储单元存储了历史错误信息对应的历史错误原因和历史解决方案脚本，通过检索与查找相关存储单元中的历史信息，从而确定与当前错误信息对应的当前错误原因和解决方案脚本。
40.步骤s306，上述控制端服务器执行上述当前解决方案脚本，以控制上述测试端服务器退出上述紧急模式，其中，上述当前错误原因和上述当前解决方案脚本一一对应。
41.具体地，为了解决测试端服务器进入紧急模式的问题，控制端服务器执行获取到的与当前错误信息对应的当前解决方案脚本，以使测试端服务器退出紧急模式，启动进入正常的操作系统，进行后续的服务器测试步骤。
42.通过上述步骤，控制端服务器通过监测工具，自动监测测试端服务器是否进入紧急模式，在测试端服务器进入紧急模式的情况下，监测工具将监测到的当前错误信息发送至控制端服务器，控制端服务器接收当前错误信息，根据当前错误信息确定当前错误原因并查找与当前错误原因对应的当前解决方案脚本，执行解决方案脚本，使测试端服务器退出紧急模式。与现有技术中，在测试端服务器进入紧急模式的情况下，需要人工根据当前错误原因查找解决方案以使测试端退出紧急模式的方法相比，本技术无需人工参与即可自动根据当前错误原因确定对应的解决方案脚本并执行，因此，解决了现有技术中人工处理服务器的紧急模式效率低问题，避免因服务器进入紧急模式而耽误测试进程的问题，提高了服务器的测试效率。
43.其中，上述步骤的执行主体可以为服务器、终端等，但不限于此。
44.在一个示例性实施例中，在控制端服务器接收监测工具发送的当前错误信息之前，还包括：上述控制端服务器获取目标测试程序，确定上述目标测试程序中的目标启动模式，其中，上述目标测试程序用于对上述测试端服务器的上述目标启动模式进行测试；上述控制端服务器将上述测试端服务器的当前启动模式修改为上述目标启动模式；上述控制端服务器执行上述目标测试程序，以对上述测试端服务器的目标启动模式进行测试。该方法中控制端服务器根据目标测试程序中的目标启动模式将测试端服务器的启动模式进行对应修改，这样可以使控制端服务器执行目标测试程序，以按照目标测试程序中的目标启动模式对测试端服务器进行测试。
45.具体实现过程中，当测试人员开始执行测试，控制端服务器开始按测试序列执行目标测试程序。在执行目标测试程序的过程时，调用启动监测工具，并通过ssh服务对待测服务器进行控制测试。测试控制端服务器与测试端服务器之间的通信以及控制是否能够正常进行。之后根据目标测试程序中要求的测试模式即目标启动模式修改测试端服务器的bios选项为目标启动模式，完成修改后需重启测试端服务器使修改的bios选项生效，完成启动模式的切换，以对切换之后的启动模式进行测试。例如：测试端服务器的当前启动模式为uefi模式，目标测试程序中的目标启动模式为legacy模式，即目标测试程序是对legacy模式进行测试的，此时将测试端服务器的uefi模式修改为legacy模式，这一修改过程可以
调用服务器系统的自动修改工具进行修改，这样可以根据目标测试程序中的需求测试模式即目标启动模式对测试端服务器的启动模式进行自动修改，使目标测试程序中的启动模式和测试端服务器的启动模式一致，避免启动模式不一致造成的测试失败，同时也避免了人工参与修改启动模式，提高了整个测试过程的效率。
46.为了使控制端服务器监测测试端服务器是否进入紧急模式，在一个示例性实施例中，在控制端服务器接收监测工具发送的当前错误信息之前，还包括：在上述控制端服务器执行上述目标测试程序的情况下，开启上述监测工具，以使上述监测工具在监测到上述当前错误信息的情况下，确定上述测试端服务器进入上述紧急模式，并将上述当前错误信息发送至上述控制端服务器，其中，上述当前错误信息是上述监测工具从上述测试端服务器的日志文件中的服务器状态信息为上述紧急模式的情况下获取的，上述服务器状态信息表示上述测试端服务器的当前状态，包括正常模式和上述紧急模式。该方法通过开启控制端服务器的监测工具来监测测试端服务器的状态信息，这样可以使控制端服务器自动监测测试端服务器，避免了需要人工来确定测试端服务器是否进入紧急模式而浪费人力的问题，节省人力的同时，提高了测试过程的效率。
47.具体地，控制端服务器中部署了监测工具，在控制端服务器开始执行目标测试程序时，同时开启监测工具，监测工具会监测待测服务器的sol(sol journal，日志记录平台)来实时判断测试端服务器的状态，如此时测试端服务器成功进入操作系统则继续测试，表明此时服务器状态信息为正常模式，如果进入紧急模式，监测工具将错误信息反馈(发送)至控制端服务器，比如，测试端服务器因switch-root(路径查找)失败导致进入的紧急模式，测试端服务器的日志中出现“failed to start switch root”，监测工具将“failed to start switch root”作为当前错误信息发送至控制端服务器。
48.在一个示例性实施例中，在上述控制端服务器将上述测试端服务器的当前启动模式修改为上述目标启动模式之后，还包括：上述控制端服务器控制上述测试端服务器重新启动。该方法在修改测试端服务器的启动模式之后，将测试端服务器进行重启，这样可以使测试端服务器的启动模式更新为目标启动模式，以使后续控制端服务器执行目标测试程序，对测试端服务器的目标启动模式进行测试。
49.在具体实现过程中，服务器(包括控制端服务器和测试端服务器)中的设置更改之后，需要进行重启，以使服务器能够及时更新相关配置。比如：当前启动模式为uefi模式，则测试段服务器中的相关配置都为uefi模式的配置，在控制端服务器将启动模式修改为目标启动模式legacy之后，重启测试端服务器，重启之后，监测工具监测到日志信息为进入操作系统，则表明修改成功；若重启之后，监测工具监测到日志信息为紧急模式，则表明修改不成功，此时监测工具将当前错误信息发送至控制端服务器。
50.为了使控制端服务器能够根据当前错误信息解决测试端服务器紧急模式的问题，在一个示例性实施例中，上述控制端服务器获取上述当前错误原因对应的当前解决方案脚本，包括：上述控制端服务器获取包括历史错误原因与对应的历史解决方案脚本的映射文件；上述控制端服务器确定与上述当前错误原因相同的上述历史错误原因为目标历史错误原因，并根据上述映射文件确定与上述目标历史错误原因对应的上述历史解决方案脚本为上述当前错误原因对应的上述当前解决方案脚本。该方法获取历史错误原因和解决方案脚本的映射文件，通过查找历史错误原因，找到与当前错误原因相同的历史错误原因，从而确
定与历史错误原因对应的历史解决方案脚本为当前解决方案脚本，这样可以通过历史数据库确定当前错误信息对应的解决方案脚本，而无需人工查找或者重新编写当前历史错误信息对应的解决方案脚本，在提高解决问题的效率的同时，节省人力。
51.具体地，控制端服务器在执行目标测试程序之前，存储了历史错误原因与对应的历史解决方案脚本的映射文件，例如：因为系统“switch-root”失败导致进入的紧急模式，即当前错误信息为“switch-root”，则在映射文件中可查询到进入紧急模式的原因为系统“switch-root”失败导致，并查询到针对该错误原因对应解决方案脚本a，控制端服务器调用解决方案脚本a，通过修改测试端服务器的配置文件等手段使得测试端服务器恢复正常，问题解决，测试端服务器正常启动，进入操作系统，控制端服务器重新通过远程连接服务连接测试端服务器的地址，完成剩余的测试任务。
52.在一个示例性实施例中，上述方法还包括：上述控制端服务器获取导致上述紧急模式出现的多个历史错误原因与每个上述历史错误原因对应的每个历史解决方案脚本，得到多个上述历史解决方案脚本；上述控制端服务器将包括上述历史错误原因与对应的上述历史解决方案脚本的映射文件存储至目标存储单元，其中，上述历史错误原因与上述历史解决方案脚本一一对应。该方法在执行目标测试文件之前首先将包括历史错误原因和历史解决方案脚本的映射文件存储至目标单元，这样相当于建立一个历史数据库，在出现当前错误信息的情况下，将当前错误信息与历史数据库进行比对，从而能够确定当前错误信息对应的解决方案脚本，以更好地解决当前错误信息。
53.具体实现过程中，控制端服务器在执行目标测试脚本之前，测试人员收集进入紧急模式的多种原因、复现并制定对应解决方案，根据解决方案开发自动化处理脚本即解决方案脚本，并将紧急模式出现的多种原因和解决方案脚本进行映射文件存储，将映射文件和自动化处理脚本部署到控制端服务器的特定路径即目标存储单元下，以使后续控制端服务器在接收到监测工具发送的当前错误信息的情况下，能够根据目标存储单元中的历史数据确定当前解决方案脚本。
54.为了使控制端服务器更加方便地控制测试端服务器，在一个示例性实施例中，在控制端服务器接收监测工具发送的当前错误信息之后，还包括：上述控制端服务器对上述测试端服务器进入上述紧急模式情况下的界面进行控制。该方法对测试端服务器的紧急模式界面进行远程控制，这样可以更加方便地控制测试端服务器，以使测试端服务器能够调用当前解决方案脚本来解决测试端服务器的紧急模式的问题。
55.具体地，在控制端服务器执行目标测试脚本之前，还需要部署远程控制界面，比如：gui界面控制工具，使测试端服务器的紧急模式界面在控制端服务器上进行可视化呈现，在控制端服务器确定当前错误信息对应的解决方案脚本之后，通过远程控制界面执行解决方案脚本，以实现远程控制与解决测试端服务器的目的，使测试端服务器退出紧急模式，进入操作系统，进行后续的测试步骤。
56.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算
机，服务器，或者网络设备等)执行本技术各个实施例上述的方法。
57.在本实施例中还提供了一种服务器的控制方法，包括：在测试端服务器的启动模式修改失败的情况下，上述测试端服务器进入紧急模式并输出当前错误信息，监测工具将监测到的上述当前错误信息发送至控制端服务器，其中，上述紧急模式表示上述测试端服务器的上述启动模式修改失败，上述当前错误信息为表征上述测试端服务器当前进入上述紧急模式的信息；上述控制端服务器接收上述监测工具发送的上述当前错误信息，根据上述当前错误信息确定当前错误原因，获取上述当前错误原因对应的当前解决方案脚本，并执行上述当前解决方案脚本，以控制上述测试端服务器退出上述紧急模式，其中，上述当前错误原因和上述当前解决方案脚本一一对应。
58.具体地，控制端服务器与测试端服务器通过远程连接来对测试端服务器进行测试，测试端服务器同时配备uefi(unified extensible firmware interface，统一可扩展固件接口)和legacy(传统)模式下安装的两种操作系统，操作系统为ip(internet protocol address)地址可以连接的开机状态；控制端服务器完成测试脚本、监测工具等部署，控制端服务器和测试端服务器处于可以连接的开机状态，可对测试端服务器ssh(secure shell，远程连接服务)连接控制。即测试端服务器的启动模式有uefi模式和legacy模式，legacy和uefi是指计算机主板上存储固件的不同方式，它们都是系统启动的基本要素。legacy基于bios(基本输入输出系统)技术，而uefi则是新一代替代品，它支持更多功能和更高效的启动系统。因此，在服务器的测试过程中，两种启动模式都需要进行测试，因此，在测试完一种模式之后，需要将服务器的启动模式切换为另一种模式，必然会存在切换失败的情况，例如：会出现远端访问磁盘出错或系统switch-root(切换路径)失败等原因概率性进入紧急模式等情况，这种情况下测试端服务器会出报错信息，测试端服务器的日志文件也会记录此次紧急模式以及相关的错误信息，控制端服务器通过监测工具对测试端服务器进行监测，当监测到当前错误信息的情况下，将当前错误信息发送至控制端服务器，控制端服务器接收监测工具发送的当前错误信息。这样可以使控制端服务器接收当前错误信息并进一步根据当前错误信息对测试端服务器进行处理。虽然上述legacy技术目前已经逐渐被uefi所取代，但在某些应用场景下，legacy技术仍然有其不可替代的优势。legacy systems(保留系统)也提供了一些不可替代的服务。而建立新的客户机服务器(uefi)系统以替代现存的保留系统(legacy systems)是一种耗资巨大的举动，所以目前存在继续保留现用系统的趋势。因此，当前服务器系统保留了uefi和legacy两种启动模式，可通过修改服务器的bios选项进行两种模式之间的切换。因此，这两种服务器启动模式，都是服务器bios测试的重要测试模块。
59.为了使得本领域技术人员能够更加清楚地了解本技术的技术方案，以下将结合具体的实施例对本技术的谐波阻抗的确定方法的实现过程进行详细说明。
60.本实施例涉及一种具体的服务器的控制方法的流程图，如图4所示，包括如下步骤：
61.步骤s1：测试任务开始，待测服务器(测试端服务器)为同时配备有uefi和legacy两种模式下的linux操作系统，且系统为ip地址可以连接的开机状态；
62.步骤s2：控制端服务器完成目标测试脚本(目标测试程序)、监测工具及gui界面控制工具的部署，启动智能监测工具(监测工具)；
63.步骤s3：待测服务器(测试端服务器)判断当前测试任务(目标测试程序)所需启动模式(目标启动模式)，切换bios模式(uefi/legacy)即将当前启动模式修改为目标启动模式，重启；
64.步骤s4：待测服务器(测试端服务器)进入os(操作系统)，继续测试(执行目标测试程序)；
65.步骤s5：待测服务器(测试端服务器)进入紧急模式，智能监测工具(监测工具)监测到服务器进入到紧急模式，并将当前错误信息发送至控制端服务器，控制端服务器通过gui界面控制工具控制待测服务器(测试端服务器)；
66.步骤s6：控制端服务器操作紧急模式界面信息并进行界面交互，根据交互信息判断问题原因并解决，即控制端服务器根据当前错误信息确定解决方案脚本，并通过gui界面控制工具执行解决方案脚本；
67.步骤s7：控制端服务器控制待测服务器(测试端服务器)退出紧急模式，成功进入os(操作系统)，继续测试(继续执行目标测试脚本)。
68.在本实施例中还提供了一种控制端服务器，用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
69.图5是根据本技术实施例的一种控制端服务器的结构框图，如图5所示，上述控制端服务器22用于：
70.在测试端服务器进入紧急模式的情况下，控制端服务器22接收监测工具发送的当前错误信息，其中，上述紧急模式表示上述测试端服务器的启动模式修改失败，上述当前错误信息为表征上述测试端服务器当前进入上述紧急模式的信息；
71.具体地，控制端服务器与测试端服务器通过远程连接来对测试端服务器进行测试，测试端服务器同时配备uefi(unified extensible firmware interface，统一可扩展固件接口)和legacy(传统)模式下安装的两种操作系统，操作系统为ip(internet protocol address)地址可以连接的开机状态；控制端服务器完成测试脚本、监测工具等部署，控制端服务器和测试端服务器处于可以连接的开机状态，可对测试端服务器ssh(secure shell，远程连接服务)连接控制。即测试端服务器的启动模式有uefi模式和legacy模式，legacy和uefi是指计算机主板上存储固件的不同方式，它们都是系统启动的基本要素。legacy基于bios(基本输入输出系统)技术，而uefi则是新一代替代品，它支持更多功能和更高效的启动系统。因此，在服务器的测试过程中，两种启动模式都需要进行测试，因此，在测试完一种模式之后，需要将服务器的启动模式切换为另一种模式，必然会存在切换失败的情况，例如：会出现远端访问磁盘出错或系统switch-root(切换路径)失败等原因概率性进入紧急模式等情况，这种情况下测试端服务器会出报错信息，测试端服务器的日志文件也会记录此次紧急模式以及相关的错误信息，控制端服务器通过监测工具对测试端服务器进行监测，当监测到当前错误信息的情况下，将当前错误信息发送至控制端服务器，控制端服务器接收监测工具发送的当前错误信息。这样可以使控制端服务器接收当前错误信息并进一步根据当前错误信息对测试端服务器进行处理。虽然上述legacy技术目前已经逐渐被uefi所取代，但在某些应用场景下，legacy技术仍然有其不可替代的优势。
legacy systems(保留系统)也提供了一些不可替代的服务。而建立新的客户机服务器(uefi)系统以替代现存的保留系统(legacy systems)是一种耗资巨大的举动，所以目前存在继续保留现用系统的趋势。因此，当前服务器系统保留了uefi和legacy两种启动模式，可通过修改服务器的bios选项进行两种模式之间的切换。因此，这两种服务器启动模式，都是服务器bios测试的重要测试模块。
72.上述控制端服务器22根据上述当前错误信息确定当前错误原因，并获取上述当前错误原因对应的当前解决方案脚本；
73.具体地，在接收到监测工具发送的当前错误信息之后，控制端服务器确定对应的当前错误原因，并查找对应的解决方案脚本。具体实现过程中，控制端服务器的相关存储单元存储了历史错误信息对应的历史错误原因和历史解决方案脚本，通过检索与查找相关存储单元中的历史信息，从而确定与当前错误信息对应的当前错误原因和解决方案脚本。
74.上述控制端服务器22执行上述当前解决方案脚本，以控制上述测试端服务器退出上述紧急模式，其中，上述当前错误原因和上述当前解决方案脚本一一对应。
75.具体地，为了解决测试端服务器进入紧急模式的问题，控制端服务器执行获取到的与当前错误信息对应的当前解决方案脚本，以使测试端服务器退出紧急模式，启动进入正常的操作系统，进行后续的服务器测试步骤。
76.通过上述步骤，控制端服务器通过监测工具，自动监测测试端服务器是否进入紧急模式，在测试端服务器进入紧急模式的情况下，监测工具将监测到的当前错误信息发送至控制端服务器，控制端服务器接收当前错误信息，根据当前错误信息确定当前错误原因并查找与当前错误原因对应的当前解决方案脚本，执行解决方案脚本，使测试端服务器退出紧急模式。与现有技术中，在测试端服务器进入紧急模式的情况下，需要人工根据当前错误原因查找解决方案以使测试端退出紧急模式的方法相比，本技术无需人工参与即可自动根据当前错误原因确定对应的解决方案脚本并执行，因此，解决了现有技术中人工处理服务器的紧急模式效率低问题，避免因服务器进入紧急模式而耽误测试进程的问题，提高了服务器的测试效率。
77.在一个示例性实施例中，上述控制端服务器还包括确定模块、修改模块和执行模块，其中，确定模块用于获取目标测试程序，确定上述目标测试程序中的目标启动模式，其中，上述目标测试程序用于对上述测试端服务器的上述目标启动模式进行测试；修改模块用于将上述测试端服务器的当前启动模式修改为上述目标启动模式；执行模块用于执行上述目标测试程序，以对上述测试端服务器的目标启动模式进行测试。该方法中控制端服务器根据目标测试程序中的目标启动模式将测试端服务器的启动模式进行对应修改，这样可以使控制端服务器执行目标测试程序，以按照目标测试程序中的目标启动模式对测试端服务器进行测试。
78.具体实现过程中，当测试人员开始执行测试，控制端服务器开始按测试序列执行目标测试程序。在执行目标测试程序的过程时，调用启动监测工具，并通过ssh服务对待测服务器进行控制测试。测试控制端服务器与测试端服务器之间的通信以及控制是否能够正常进行。之后根据目标测试程序中要求的测试模式即目标启动模式修改测试端服务器的bios选项为目标启动模式，完成修改后需重启测试端服务器使修改的bios选项生效，完成启动模式的切换，以对切换之后的启动模式进行测试。例如：测试端服务器的当前启动模式
为uefi模式，目标测试程序中的目标启动模式为legacy模式，即目标测试程序是对legacy模式进行测试的，此时将测试端服务器的uefi模式修改为legacy模式，这一修改过程可以调用服务器系统的自动修改工具进行修改，这样可以根据目标测试程序中的需求测试模式即目标启动模式对测试端服务器的启动模式进行自动修改，使目标测试程序中的启动模式和测试端服务器的启动模式一致，避免启动模式不一致造成的测试失败，同时也避免了人工参与修改启动模式，提高了整个测试过程的效率。
79.为了使控制端服务器监测测试端服务器是否进入紧急模式，在一个示例性实施例中，上述控制端服务器还包括开启模块，用于在上述控制端服务器执行上述目标测试程序的情况下，开启上述监测工具，以使上述监测工具在监测到上述当前错误信息的情况下，确定上述测试端服务器进入上述紧急模式，并将上述当前错误信息发送至上述控制端服务器，其中，上述当前错误信息是上述监测工具从上述测试端服务器的日志文件中的服务器状态信息为上述紧急模式的情况下获取的，上述服务器状态信息表示上述测试端服务器的当前状态，包括正常模式和上述紧急模式。该方法通过开启控制端服务器的监测工具来监测测试端服务器的状态信息，这样可以使控制端服务器自动监测测试端服务器，避免了需要人工来确定测试端服务器是否进入紧急模式而浪费人力的问题，节省人力的同时，提高了测试过程的效率。
80.具体地，控制端服务器中部署了监测工具，在控制端服务器开始执行目标测试程序时，同时开启监测工具，监测工具会监测待测服务器的sol(sol journal，日志记录平台)来实时判断测试端服务器的状态，如此时测试端服务器成功进入操作系统则继续测试，表明此时服务器状态信息为正常模式，如果进入紧急模式，监测工具将错误信息反馈(发送)至控制端服务器，比如，测试端服务器因switch-root(路径查找)失败导致进入的紧急模式，测试端服务器的日志中出现“failed to start switch root”，监测工具将“failed to start switch root”作为当前错误信息发送至控制端服务器。
81.在一个示例性实施例中，上述控制端服务器还包括启动模块，用于控制上述测试端服务器重新启动。该方法在修改测试端服务器的启动模式之后，将测试端服务器进行重启，这样可以使测试端服务器的启动模式更新为目标启动模式，以使后续控制端服务器执行目标测试程序，对测试端服务器的目标启动模式进行测试。
82.在具体实现过程中，服务器(包括控制端服务器和测试端服务器)中的设置更改之后，需要进行重启，以使服务器能够及时更新相关配置。比如：当前启动模式为uefi模式，则测试段服务器中的相关配置都为uefi模式的配置，在控制端服务器将启动模式修改为目标启动模式legacy之后，重启测试端服务器，重启之后，监测工具监测到日志信息为进入操作系统，则表明修改成功；若重启之后，监测工具监测到日志信息为紧急模式，则表明修改不成功，此时监测工具将当前错误信息发送至控制端服务器。
83.为了使控制端服务器能够根据当前错误信息解决测试端服务器紧急模式的问题，在一个示例性实施例中，获取模块包括第一获取子模块和确定子模块，其中，第一获取子模块用于获取包括历史错误原因与对应的历史解决方案脚本的映射文件；确定子模块用于确定与上述当前错误原因相同的上述历史错误原因为目标历史错误原因，并根据上述映射文件确定与上述目标历史错误原因对应的上述历史解决方案脚本为上述当前错误原因对应的上述当前解决方案脚本。该方法获取历史错误原因和解决方案脚本的映射文件，通过查
找历史错误原因，找到与当前错误原因相同的历史错误原因，从而确定与历史错误原因对应的历史解决方案脚本为当前解决方案脚本，这样可以通过历史数据库确定当前错误信息对应的解决方案脚本，而无需人工查找或者重新编写当前历史错误信息对应的解决方案脚本，在提高解决问题的效率的同时，节省人力。
84.具体地，控制端服务器在执行目标测试程序之前，存储了历史错误原因与对应的历史解决方案脚本的映射文件，例如：因为系统“switch-root”失败导致进入的紧急模式，即当前错误信息为“switch-root”，则在映射文件中可查询到进入紧急模式的原因为系统“switch-root”失败导致，并查询到针对该错误原因对应解决方案脚本a，控制端服务器调用解决方案脚本a，通过修改测试端服务器的配置文件等手段使得测试端服务器恢复正常，问题解决，测试端服务器正常启动，进入操作系统，控制端服务器重新通过远程连接服务连接测试端服务器的地址，完成剩余的测试任务。
85.在一个示例性实施例中，获取模块还包括第二获取子模块和存储子模块，其中，第二获取子模块用于上述控制端服务器获取导致上述紧急模式出现的多个历史错误原因与每个上述历史错误原因对应的每个历史解决方案脚本，得到多个上述历史解决方案脚本；存储子模块用于上述控制端服务器将包括上述历史错误原因与对应的上述历史解决方案脚本的映射文件存储至目标存储单元，其中，上述历史错误原因与上述历史解决方案脚本一一对应。该方法在执行目标测试文件之前首先将包括历史错误原因和历史解决方案脚本的映射文件存储至目标单元，这样相当于建立一个历史数据库，在出现当前错误信息的情况下，将当前错误信息与历史数据库进行比对，从而能够确定当前错误信息对应的解决方案脚本，以更好地解决当前错误信息。
86.具体实现过程中，控制端服务器在执行目标测试脚本之前，测试人员收集进入紧急模式的多种原因、复现并制定对应解决方案，根据解决方案开发自动化处理脚本即解决方案脚本，并将紧急模式出现的多种原因和解决方案脚本进行映射文件存储，将映射文件和自动化处理脚本部署到控制端服务器的特定路径即目标存储单元下，以使后续控制端服务器在接收到监测工具发送的当前错误信息的情况下，能够根据目标存储单元中的历史数据确定当前解决方案脚本。
87.为了使控制端服务器更加方便地控制测试端服务器，上述控制端服务器还包括控制模块，用于对上述测试端服务器进入上述紧急模式情况下的界面进行控制。该方法对测试端服务器的紧急模式界面进行远程控制，这样可以更加方便地控制测试端服务器，以使测试端服务器能够调用当前解决方案脚本来解决测试端服务器的紧急模式的问题。
88.具体地，在控制端服务器执行目标测试脚本之前，还需要部署远程控制界面，比如：gui界面控制工具，使测试端服务器的紧急模式界面在控制端服务器上进行可视化呈现，在控制端服务器确定当前错误信息对应的解决方案脚本之后，通过远程控制界面执行解决方案脚本，以实现远程控制与解决测试端服务器的目的，使测试端服务器退出紧急模式，进入操作系统，进行后续的测试步骤。
89.需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。
90.本技术的实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存
储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一种方法实施例中的步骤。
91.在一个示例性实施例中，上述计算机可读存储介质可以包括但不限于：u盘、只读存储器(read-only memory，简称为rom)、随机存取存储器(random access memory，简称为ram)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
92.本技术的实施例还提供了一种电子设备，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一种方法实施例中的步骤。
93.在一个示例性实施例中，上述电子设备还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。
94.本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例，本实施例在此不再赘述。
95.显然，本领域的技术人员应该明白，上述的本技术的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本技术不限制于任何特定的硬件和软件结合。
96.以上所述仅为本技术的优选实施例而已，并不用于限制本技术，对于本领域的技术人员来说，本技术可以有各种更改和变化。凡在本技术的原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。

技术特征：
1.一种服务器的控制方法，其特征在于，包括：在测试端服务器进入紧急模式的情况下，控制端服务器接收监测工具发送的当前错误信息，其中，所述紧急模式表示所述测试端服务器的启动模式修改失败，所述当前错误信息为表征所述测试端服务器当前进入所述紧急模式的信息；所述控制端服务器根据所述当前错误信息确定当前错误原因，并获取所述当前错误原因对应的当前解决方案脚本；所述控制端服务器执行所述当前解决方案脚本，以控制所述测试端服务器退出所述紧急模式，其中，所述当前错误原因和所述当前解决方案脚本一一对应。2.根据权利要求1所述的方法，其特征在于，在控制端服务器接收监测工具发送的当前错误信息之前，还包括：所述控制端服务器获取目标测试程序，确定所述目标测试程序中的目标启动模式，其中，所述目标测试程序用于对所述测试端服务器的所述目标启动模式进行测试；所述控制端服务器将所述测试端服务器的当前启动模式修改为所述目标启动模式；所述控制端服务器执行所述目标测试程序，以对所述测试端服务器的目标启动模式进行测试。3.根据权利要求2所述的方法，其特征在于，在控制端服务器接收监测工具发送的当前错误信息之前，还包括：在所述控制端服务器执行所述目标测试程序的情况下，开启所述监测工具，以使所述监测工具在监测到所述当前错误信息的情况下，确定所述测试端服务器进入所述紧急模式，并将所述当前错误信息发送至所述控制端服务器，其中，所述当前错误信息是所述监测工具从所述测试端服务器的日志文件中的服务器状态信息为所述紧急模式的情况下获取的，所述服务器状态信息表示所述测试端服务器的当前状态，包括正常模式和所述紧急模式。4.根据权利要求2所述的方法，其特征在于，在所述控制端服务器将所述测试端服务器的当前启动模式修改为所述目标启动模式之后，还包括：所述控制端服务器控制所述测试端服务器重新启动。5.根据权利要求1所述的方法，其特征在于，所述控制端服务器获取所述当前错误原因对应的当前解决方案脚本，包括：所述控制端服务器获取包括历史错误原因与对应的历史解决方案脚本的映射文件；所述控制端服务器确定与所述当前错误原因相同的所述历史错误原因为目标历史错误原因，并根据所述映射文件确定与所述目标历史错误原因对应的所述历史解决方案脚本为所述当前错误原因对应的所述当前解决方案脚本。6.根据权利要求5所述的方法，其特征在于，所述方法还包括：所述控制端服务器获取导致所述紧急模式出现的多个历史错误原因与每个所述历史错误原因对应的每个历史解决方案脚本，得到多个所述历史解决方案脚本；所述控制端服务器将包括所述历史错误原因与对应的所述历史解决方案脚本的映射文件存储至目标存储单元，其中，所述历史错误原因与所述历史解决方案脚本一一对应。7.根据权利要求1所述的方法，其特征在于，在控制端服务器接收监测工具发送的当前错误信息之后，还包括：
所述控制端服务器对所述测试端服务器进入所述紧急模式情况下的界面进行控制。8.一种服务器的控制方法，其特征在于，包括：在测试端服务器的启动模式修改失败的情况下，所述测试端服务器进入紧急模式并输出当前错误信息，监测工具将监测到的所述当前错误信息发送至控制端服务器，其中，所述紧急模式表示所述测试端服务器的所述启动模式修改失败，所述当前错误信息为表征所述测试端服务器当前进入所述紧急模式的信息；所述控制端服务器接收所述监测工具发送的所述当前错误信息，根据所述当前错误信息确定当前错误原因，获取所述当前错误原因对应的当前解决方案脚本，并执行所述当前解决方案脚本，以控制所述测试端服务器退出所述紧急模式，其中，所述当前错误原因和所述当前解决方案脚本一一对应。9.一种控制端服务器，其特征在于，包括：在测试端服务器进入紧急模式的情况下，控制端服务器接收监测工具发送的当前错误信息，其中，所述紧急模式表示所述测试端服务器的启动模式修改失败，所述当前错误信息为表征所述测试端服务器当前进入所述紧急模式的信息；所述控制端服务器根据所述当前错误信息确定当前错误原因，并获取所述当前错误原因对应的当前解决方案脚本；所述控制端服务器执行所述当前解决方案脚本，以控制所述测试端服务器退出所述紧急模式，其中，所述当前错误原因和所述当前解决方案脚本一一对应。10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被处理器执行时实现所述权利要求1至8任一项中所述的方法的步骤。11.一种电子设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现所述权利要求1至8任一项中所述的方法的步骤。

技术总结
本申请实施例提供了一种服务器的控制方法、控制端服务器和电子设备，其中，该方法包括：在测试端服务器进入紧急模式的情况下，控制端服务器接收监测工具发送的当前错误信息，其中，紧急模式表示测试端服务器的启动模式修改失败，当前错误信息为表征测试端服务器当前进入紧急模式的信息；控制端服务器根据当前错误信息确定当前错误原因，并获取当前错误原因对应的当前解决方案脚本；控制端服务器执行当前解决方案脚本，以控制测试端服务器退出紧急模式，其中，当前错误原因和当前解决方案脚本一一对应。通过本申请，解决了人工处理服务器的紧急模式效率低的问题。的紧急模式效率低的问题。的紧急模式效率低的问题。


技术研发人员：刘云霞
受保护的技术使用者：苏州浪潮智能科技有限公司
技术研发日：2023.06.30
技术公布日：2023/10/7