CN113703914A

CN113703914A - Test method and test system

Info

Publication number: CN113703914A
Application number: CN202110903376.3A
Authority: CN
Inventors: 王梦达
Original assignee: Yangtze Memory Technologies Co Ltd
Current assignee: Yangtze Memory Technologies Co Ltd
Priority date: 2021-08-06
Filing date: 2021-08-06
Publication date: 2021-11-26
Anticipated expiration: 2041-08-06
Also published as: CN113703914B

Abstract

The embodiment of the application discloses a test method and a test system, relates to the technical field of tests, and can improve the test efficiency and reduce the test cost. The specific scheme is as follows: the test system comprises a server for running a plurality of virtual machines, each virtual machine corresponds to one or more physical interfaces, each physical interface is used for connecting a device to be tested, and each virtual machine is used for testing the device to be tested connected to the physical interface corresponding to the virtual machine, and the method comprises the following steps: the method comprises the steps that a server obtains indicating information used for indicating the server to test at least two devices to be tested, wherein the indicating information comprises physical interface information of the at least two devices to be tested; the server starts the virtual machines corresponding to the at least two devices to be tested based on the indication information; and the virtual machine executes the test script of the equipment to be tested corresponding to the virtual machine.

Description

Test method and test system

Technical Field

The embodiment of the application relates to the technical field of testing, in particular to a testing method and a testing system.

Background

With the development of computer technology, the requirements of users on the storage performance of the server are higher and higher, and in order to ensure the integrity and reliability of the functions of the storage device in the server, the performance of the storage device can be tested.

In order to save the test cost and improve the test efficiency, the server can test a plurality of storage devices at the same time. Fig. 1 is a multi-Solid State Disk (SSD) test system, as shown in fig. 1, the multi-SSD test system includes a server, a PCIe converter and 4 SSDs, where a peripheral component interconnect express (PCIe) converter Switch is used to convert one PCIe interface (PCIe × 16) of the server into 4 PCIe interfaces (PCIe × 4), the 4 PCIe interfaces are respectively connected to the 4 SSDs, and when the server tests the 4 SSDs at the same time, the server may execute test scripts of the 4 SSDs at the same time through a multi-process technology.

However, when multiple SSDs are tested simultaneously by using the multi-process technology, because the test scripts of the multiple SSDs run on the same operating system, if one SSD fails to test, the test of other SSDs may be affected, which may result in the test failure of all SSDs, even the operating system of the server being paralyzed, and the test efficiency is low.

Disclosure of Invention

The embodiment of the application provides a test method and a test system, when a device to be tested fails in test, an operating system of a server is not affected, and test efficiency can be improved.

In order to achieve the above purpose or other purposes, the embodiments of the present application adopt the following technical solutions:

in a first aspect of the embodiments of the present application, a test method is provided, where the test method is applied to a test system, the test system includes a server, the server runs multiple virtual machines, each virtual machine corresponds to one or more physical interfaces, each physical interface is used to connect one device to be tested, and each virtual machine running on the server is used to test the device to be tested connected to the physical interface corresponding to the virtual machine, and the method includes: firstly, a server acquires indication information for indicating to test at least two devices to be tested; the indication information includes physical interface information of at least two devices under test. Then, the server starts at least two virtual machines corresponding to the at least two devices to be tested based on the indication information. And finally, each virtual machine in the at least two virtual machines executes the test script of the equipment to be tested corresponding to the virtual machine.

Based on the scheme, when the server tests a plurality of devices to be tested, the test scripts of the plurality of devices to be tested can be executed on different virtual machines respectively. Because the respective operating systems are operated on different virtual machines, the test scripts of the devices to be tested can be operated on different operating systems, if one device to be tested fails in testing, the device to be tested in other virtual machines cannot be affected, the operating system of the server cannot be affected, and the testing efficiency can be improved.

Optionally, for each virtual machine, if one virtual machine corresponds to one physical interface, the test scripts of different devices to be tested may be executed on the different virtual machines, and if one device to be tested fails in testing, the test scripts do not affect other devices to be tested, the operating system of the server is not affected, and the test efficiency can be improved. And when one virtual machine corresponds to one physical interface, the device names of the devices to be tested connected to the physical interface corresponding to the virtual machine are uniform. It can be understood that, because the names of the devices to be tested connected to the physical interface corresponding to each virtual machine are uniform, the virtual machine may use the same test script when testing the same function for multiple devices to be tested. And even if the drive letter is changed when the equipment to be tested is subjected to power-down test, the test script of the equipment to be tested does not need to be modified, the development difficulty of the test script can be reduced, and the test cost is lower.

Optionally, after the server starts the virtual machines corresponding to the at least two devices to be tested, the server may send the test script information of the device to be tested corresponding to the virtual machine to each virtual machine.

In a possible implementation manner, before the virtual machine executes a test script of the device to be tested corresponding to the virtual machine, the method further includes: the virtual machine sends a starting test request for requesting to start executing the test script of the equipment to be tested corresponding to the virtual machine to a server; the server determines available resources of the server based on the starting test request; the method comprises the steps that when available resources of a server are larger than or equal to resources consumed by executing a test script of equipment to be tested, the server sends a test starting instruction to a virtual machine; the virtual machine receives a start test instruction.

Based on the scheme, before each virtual machine executes the corresponding test script, the server sends a test starting request to the server, and the server can indicate the virtual machines to start testing under the condition that the available resources of the server are enough, namely, each virtual machine starts testing under the condition that the available resources of the server are enough, so that the problems of abnormal test scripts, substandard test and the like caused by insufficient resources can be avoided.

In a possible implementation manner, the method further includes: under the condition that the virtual machine finishes executing the test script of the equipment to be tested corresponding to the virtual machine, the virtual machine sends a test finishing message to a server; the server closes the virtual machine based on the test complete message.

Based on the scheme, after the device to be tested is tested by the virtual machine, the server closes the virtual machine, so that resources can be saved, and the expenditure is reduced. And when testing the equipment to be tested connected on the physical interface corresponding to the virtual machine next time, the server starts the virtual machine again, and since the adaptation script is executed in the starting process of the virtual machine, the virtual machine can be associated with the equipment to be tested connected on the physical interface corresponding to the virtual machine after being started, so that the virtual machine can continue to test the equipment to be tested. That is to say, after the virtual machine finishes testing the device to be tested each time, the server closes the virtual machine, and when testing the device to be tested connected to the physical interface corresponding to the virtual machine next time, the server opens the virtual machine again, so that the virtual machine can be associated with the device to be tested, and the device to be tested is tested.

In a possible implementation manner, the method further includes: under the condition that the virtual machine fails in testing, the virtual machine sends a test failure message to a server; the server shuts down the virtual machine based on the test failure message.

Based on the scheme, after the virtual machine fails to be tested, the server closes the virtual machine, so that resources can be saved, and the expenditure is reduced. And when testing the equipment to be tested connected on the physical interface corresponding to the virtual machine next time, the server starts the virtual machine again, and since the adaptation script is executed in the starting process of the virtual machine, the virtual machine can be associated with the equipment to be tested connected on the physical interface corresponding to the virtual machine after being started, so that the virtual machine can continue to test the equipment to be tested. That is to say, after each test failure of the virtual machine, the server closes the virtual machine, and when the device to be tested connected to the physical interface corresponding to the virtual machine is tested next time, the server opens the virtual machine again, so that the virtual machine can be associated with the device to be tested, and the device to be tested is tested.

Optionally, the device to be tested connected to the physical interface corresponding to the next test of the virtual machine may be the same as the device to be tested of the previous test, for example, two tests of the virtual machine are performed on the same device to be tested under different drivers. The device to be tested connected to the physical interface corresponding to the next test of the virtual machine may also be different from the device to be tested in the previous test, for example, the two tests of the virtual machine are different devices to be tested connected to the same physical interface.

In a possible implementation manner, the test system further includes a BMC, and the server is coupled to the at least two devices under test through the BMC, and the method further includes: the method comprises the steps that a virtual machine sends a first request message to a device to be tested corresponding to the virtual machine through a BMC, wherein the first request message comprises an identifier of the device to be tested corresponding to the virtual machine, and the first request message is used for requesting management information of the device to be tested corresponding to the virtual machine; the virtual machine receives a first response message from the device to be tested through the BMC, wherein the first response message comprises management information of the device to be tested.

Based on the scheme, each virtual machine can request the management information of the to-be-tested device corresponding to the virtual machine through the BMC, the to-be-tested device can send the management information of the to-be-tested device to the virtual machine through the BMC, each virtual machine can acquire the management information of the to-be-tested device, and the test capability can be improved.

In a possible implementation manner, the test system further includes a BMC, and the server is coupled to the at least two devices under test through the BMC, where the method further includes: the method comprises the steps that a virtual machine sends power-on and power-off indication information used for indicating the BMC to control power-on or power-off of equipment to be tested corresponding to the virtual machine, wherein the power-on and power-off indication information comprises an identifier of the equipment to be tested corresponding to the virtual machine; and the BMC controls the power-on or power-off of the equipment to be tested based on the power-on and power-off indication information.

Based on the scheme, each virtual machine can send power management information to the BMC through the RPC interface so as to control the power-on and power-off of the equipment to be tested corresponding to the virtual machine, therefore, the power-on and power-off of each equipment to be tested can be independently controlled, and the testing capability is improved.

In a possible implementation manner, the test system further includes a BMC and a converter, the server is coupled to the at least two devices under test through the BMC, the converter includes a plurality of physical interfaces, the server is coupled to the at least two devices under test through the converter, and the converter is coupled to the BMC, and the method further includes: the virtual machine sends a second request message for requesting management information of the converter to the converter through the BMC; the converter sends a second response message to the virtual machine through the BMC, wherein the second response message comprises management information of the converter.

Based on the scheme, each virtual machine can request the management information of the converter through the BMC, and the converter can send the management information of the converter to the virtual machine through the BMC, so that each virtual machine can acquire the management information of the converter, and the test capability can be improved.

Optionally, the converter in this embodiment may be a PCIe Switch.

In a possible implementation manner, the test system further includes a converter, the converter includes a plurality of physical interfaces, and the server is coupled to the at least two devices under test through the converter, and the method further includes: the virtual machine sends an access request to the device to be tested corresponding to the virtual machine through the converter, wherein the access request comprises the identifier of the device to be tested corresponding to the virtual machine.

Optionally, the access request includes, but is not limited to, an IO command (IO command), an administrator command (admin command), and other functional commands.

Based on the scheme, each virtual machine can send an access request to the corresponding device to be tested through the converter, so that the plurality of devices to be tested can be connected through the converter and tested under the condition that the physical interface of the server does not support the connection of the plurality of devices to be tested.

In one possible implementation, the virtual machine includes a Docker or a Linux container LXC.

Based on the scheme, a plurality of dockers or a plurality of LXCs can be operated on the server, and each Docker or LXC is used for testing the device to be tested connected to one physical interface, so that when the server tests a plurality of devices to be tested, the test scripts of the devices to be tested can be respectively executed on different virtual machines. Because the respective operating systems run on the different virtual machines, the test scripts of the devices to be tested run on the different operating systems, if one device to be tested fails in testing, the device to be tested in other virtual machines cannot be affected, the operating system of the server cannot be affected, and the testing efficiency can be improved.

In a possible implementation manner, the device under test includes a storage device or a universal serial bus USB device. Optionally, the storage device may include a solid state disk SSD.

Based on the scheme, the server can test a plurality of storage devices or a plurality of USB devices, and when the server tests the plurality of storage devices or the plurality of USB devices, the test scripts of the plurality of storage devices or the plurality of USB devices can be executed on different virtual machines respectively, so if one storage device or one USB device fails to test, the device to be tested in other virtual machines cannot be influenced, the operating system of the server cannot be influenced, and the test efficiency can be improved.

In a second aspect of the embodiments of the present application, a test system is provided, where the test system includes a server, where the server runs multiple virtual machines, each virtual machine corresponds to one or more physical interfaces, each physical interface is used to connect one device to be tested, and each virtual machine is used to test the device to be tested connected to the physical interface corresponding to the virtual machine; the server is used for acquiring the indication information; the indication information is used for indicating the server to test at least two devices to be tested, and the indication information comprises physical interface information of the at least two devices to be tested; the server is also used for starting the virtual machines corresponding to the at least two devices to be tested based on the indication information; and the virtual machine is used for executing the test script of the equipment to be tested corresponding to the virtual machine.

Optionally, the server is further configured to send test script information of the device to be tested corresponding to the virtual machine.

In a possible implementation manner, the virtual machine is further configured to send a test start request for requesting to start executing a test script of the device to be tested corresponding to the virtual machine to a server; the server is also used for determining available resources of the server based on the starting test request; the server is also used for sending a test starting instruction to the virtual machine under the condition that the available resources of the server are more than or equal to the resources consumed by executing the test script of the equipment to be tested; and the virtual machine is also used for receiving the starting test instruction.

In a possible implementation manner, the virtual machine is further configured to send a test completion message to the server when the virtual machine completes execution of the test script of the device to be tested corresponding to the virtual machine; and the server is also used for closing the virtual machine based on the test completion message.

In a possible implementation manner, the virtual machine is further configured to send a test failure message to the server when the virtual machine fails in testing; and the server is also used for closing the virtual machine based on the test failure message.

In a possible implementation manner, the test system further includes a baseboard management controller BMC, and the server is coupled with the at least two devices to be tested through the BMC; the virtual machine is further configured to send a first request message to the device to be tested corresponding to the virtual machine through the BMC, where the first request message includes an identifier of the device to be tested corresponding to the virtual machine, and the first request message is used to request management information of the device to be tested corresponding to the virtual machine; the virtual machine is further used for receiving a first response message from the device to be tested through the BMC, wherein the first response message comprises management information of the device to be tested.

In a possible implementation manner, the test system further includes a baseboard management controller BMC, and the server is coupled with the at least two devices to be tested through the BMC; the virtual machine is further used for sending power-on and power-off indication information to the BMC, the power-on and power-off indication information comprises an identifier of the to-be-tested device corresponding to the virtual machine, and the power-on and power-off indication information is used for indicating the BMC to control the to-be-tested device corresponding to the virtual machine to be powered on or powered off; and the BMC is used for controlling the power-on or power-off of the equipment to be tested based on the power-on and power-off indication information.

In a possible implementation manner, the test system further includes a baseboard management controller BMC and a converter, the server is coupled with at least two devices to be tested through the BMC, the converter includes a plurality of physical interfaces, the server is coupled with the at least two devices to be tested through the converter, and the converter is coupled with the BMC; the virtual machine is also used for sending a second request message to the converter through the BMC, and the second request message is used for requesting the management information of the converter; and the converter is further used for sending a second response message to the virtual machine through the BMC, wherein the second response message comprises the management information of the converter.

In a possible implementation manner, the test system further includes a converter, the converter includes a plurality of physical interfaces, and the server is coupled to the at least two devices under test through the converter; the virtual machine is further configured to send an access request to the device to be tested corresponding to the virtual machine through the converter, where the access request includes an identifier of the device to be tested corresponding to the virtual machine.

In a possible implementation manner, the device under test includes a storage device or a universal serial bus USB device.

In a possible implementation manner, the storage device includes a solid state disk SSD.

The above second aspect and descriptions of effects of various implementation manners of the second aspect may refer to descriptions of corresponding effects of the first aspect, and are not described herein again.

In a third aspect of embodiments of the present application, a computer-readable storage medium is provided, where computer program code is stored, and when the computer program code runs on a processor, the processor is caused to obtain indication information, where the indication information is used to instruct a server to test at least two devices under test, and the indication information includes physical interface information of the at least two devices under test. And starting the virtual machines corresponding to the at least two devices to be tested based on the indication information.

In a fourth aspect of the embodiments of the present application, a computer program product is provided, where the computer program product stores computer software instructions executed by the processor, where the computer software instructions include instruction information for executing and acquiring, where the instruction information is used to instruct a server to test at least two devices to be tested, and the instruction information includes physical interface information of the at least two devices to be tested. And starting the virtual machines corresponding to the at least two devices to be tested based on the indication information.

Drawings

Fig. 1 is a schematic structural diagram of a multi-SSD test system according to an embodiment of the present application;

fig. 2 is a schematic structural diagram of a test system according to an embodiment of the present disclosure;

FIG. 3 is a system architecture diagram of a virtualization technique according to an embodiment of the present application;

FIG. 4 is a schematic structural diagram of another test system provided in the embodiments of the present application;

fig. 5 is a schematic flowchart of a testing method according to an embodiment of the present application;

FIG. 6 is a schematic flow chart of another testing method provided in the embodiments of the present application;

FIG. 7 is a schematic flow chart illustrating another testing method provided in the embodiments of the present application;

FIG. 8 is a schematic flow chart illustrating another testing method provided in the embodiments of the present application;

fig. 9 is a schematic flowchart of another testing method provided in the embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. In the present application, "at least one" means one or more, "a plurality" means two or more. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone, wherein A and B can be singular or plural. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. "at least one of the following" or similar expressions refer to any combination of these items, including any combination of the singular or plural items. For example, at least one (one) of a, b, or c, may represent: a, b, c, a and b, a and c, b and c, or a and b and c, wherein a, b and c can be single or multiple. In addition, for the convenience of clearly describing the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first", "second", and the like are used to distinguish the same items or similar items with basically the same functions and actions, and those skilled in the art can understand that the words "first", "second", and the like do not limit the quantity and execution order. For example, the "first" in the first request message and the "second" in the second request message in the embodiment of the present application are only used to distinguish different request messages. The descriptions of the first, second, etc. appearing in the embodiments of the present application are only for illustrating and differentiating the objects, and do not represent the order or the particular limitation of the number of the devices in the embodiments of the present application, and do not constitute any limitation to the embodiments of the present application.

It is noted that, in the present application, words such as "exemplary" or "for example" are used to mean exemplary, illustrative, or descriptive. Any embodiment or design described herein as "exemplary" or "e.g.," is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the word "exemplary" or "such as" is intended to present concepts related in a concrete fashion.

In order to solve the problem that when a plurality of devices to be tested are tested simultaneously in the prior art, if one device to be tested fails to test, the test of other devices to be tested is influenced, and even the operating system is paralyzed; and/or if the drive letter of a device to be tested is changed after the power-down test, the test script of the device to be tested needs to be correspondingly adjusted, so that the problems of higher development difficulty and higher test cost of the test script are caused; the embodiment of the application provides a test system, and the test system is through running a plurality of virtual machines on the server, and these a plurality of virtual machines are used for testing a plurality of equipment to be tested respectively, because the test script of a plurality of equipment to be tested carries out on the virtual machine of difference, therefore if an equipment to be tested test fails, can not cause the influence to the equipment to be tested of testing in other virtual machines, can not influence the operating system of server yet, can improve efficiency of software testing. And the test script is operated on different virtual machines, and the equipment name in each virtual machine is uniform, so that the test script of the equipment to be tested does not need to be modified even if the disk character of the equipment to be tested is changed during power-down test, the development difficulty of the test script can be reduced, and the test cost is low.

As shown in fig. 2, the test system includes a server 201, where the server runs a plurality of virtual machines 202, each virtual machine 202 corresponds to one or more physical interfaces, each physical interface is used to connect one device under test 203, and each virtual machine 202 is used to test the device under test 203 connected to the physical interface corresponding to the virtual machine 202.

A plurality of virtual machines 202 running on the server 201 may be created in advance, each virtual machine 202 corresponds to one or more physical interfaces, and each virtual machine 202 is configured to execute a test script of the device under test 203 connected to the physical interface corresponding to the virtual machine 202.

For example, if one virtual machine 202 corresponds to one physical interface, when the server 201 tests multiple devices under test 203, test scripts of the multiple devices under test 203 may be executed on different virtual machines 202, respectively. Because the respective operating systems are run on the different virtual machines 202, the test scripts of the multiple devices to be tested 203 are run on the different operating systems, and if one device to be tested 203 fails in testing, the testing of the other devices to be tested 203 is not affected, and the operating system of the server 201 is not affected.

For example, if one virtual machine 202 corresponds to multiple physical interfaces, when the server 201 tests multiple devices under test 203, test scripts of some devices under test 203 in the multiple devices under test 203 may be executed on the same virtual machine. If one device under test 203 fails to test, it will only affect the test of other devices under test 203 tested on the virtual machine 202, will not affect the devices under test tested in other virtual machines, and will not affect the operating system of the server 201.

The server 201 in the embodiment of the present application is created with a virtualization system, which may be any one virtualized system based on the following four types of virtualization technologies. These four types of virtualization technologies are full virtualization, para-virtualization, host OS virtualization, and container based virtualization, respectively. These four types of virtualization techniques are described below.

Full virtualization, also called hardware-assisted virtualization, is shown in fig. 3 (a), and is to add a hypervisor (hypervisor) between a Virtual Machine (VM) and a hardware resource, where the hypervisor may run directly on the hardware resource, and the hypervisor may also be referred to as a Virtual Machine Monitor (VMM). The virtual machine may include a guest operating system (guest OS), which is abbreviated as guest OS, and a user application (user APP), which runs on the guest OS, and may share hardware resources through the hypervisor, which may capture and process instructions issued by the guest OS. The advantage of full virtualization is that the guest OS is not subject to any modification, but the hypervisor needs to translate instructions issued by the guest OS into an instruction format that can be recognized by the processor, which is very heavy.

The para-virtualization is also called as para-virtualization, and as shown in fig. 3 (b), the para-virtualization modifies the guest OS on the basis of full virtualization, and adds a special Application Program Interface (API), which can optimize the instruction sent by the guest OS, that is, it does not need the hypervisor to consume resources for translation, so that the workload of the hypervisor becomes very small, and the overall performance is greatly improved.

Host operating system virtualization, also referred to as operating system layer virtualization, as shown in (c) of fig. 3, is to implement virtualization on the basis of a single operating system, the virtualization being directly provided by an operating system kernel, a plurality of virtualized machines that can share the host operating system kernel and underlying hardware resources, the plurality of virtualized machines can be managed by a hypervisor running on the host operating system (host OS), and each virtualized machine can include a guest OS without any modification and a user APP running on the guest OS. The host operating system virtualization has the advantages that the isolation of the guest operating system and the host operating system is realized, and the repeated installation of the host operating system can be effectively avoided.

Container-based virtualization, also called container-based operating system level virtualization, as shown in (d) of fig. 3, is that multiple mutually independent virtual execution environments can be created on top of a host operating system (host OS), one virtual execution environment can be called a container (container), multiple containers do not need a special system library to provide required function modules, but are implemented by a system kernel sharing the host OS, and each container can run a corresponding user APP. Container-based virtualization may also enable isolation of the virtual execution environment (i.e., container) from other APPs running directly on top of the host operating system. The essence of the container is a process running on a host operating system, and each container may perform resource control through a control group (Cgroup) and perform resource isolation through a namespace (namespace).

It should be noted that, for the related descriptions of Cgroup and namespace, and the related descriptions of resource control of the container by Cgroup and resource isolation by namespace, reference may be made to the description in the related art, and the embodiments of the present application are not set forth in detail herein.

The type of virtual machine 202 running on the server 201 may include, but is not limited to, a Docker or a Linux Container (LXC). The types of virtual machines 202 running on the server 201 may be the same or different. The specific type of the multiple virtual machines running on the server is not limited in the embodiments of the present application. Optionally, a plurality of virtual machines running on the server may share a part of the storage space, and the storage space is used for storing information such as test scripts and test results of a plurality of devices to be tested.

Optionally, the multiple physical interfaces corresponding to the multiple virtual machines 202 may be physical interfaces on the server 201 or physical interfaces on the converter. When the plurality of physical interfaces are physical interfaces on a converter, as shown in fig. 4, the test system may further include a converter 204, the converter 204 is coupled to the server 201, the converter 204 is configured to convert the physical interfaces on the server 201 into the plurality of physical interfaces, and the server 201 may be connected to the plurality of devices under test 203 through the converter 204. The physical interface on the server 201 and the physical interface on the converter 204 may be the same or different in interface type, and this is not limited in this embodiment of the application.

The device to be tested includes, but is not limited to, a storage device (e.g., a NAND storage system product), a Universal Serial Bus (USB) device, and other devices, the physical interface may be an interface such as a PCIe interface, a USB interface, and a converter may be a converter such as a PCIe Switch. In the following embodiments, the device to be tested is taken as an SSD, the physical interface is a PCIe interface, and the converter is a PCIe Switch.

For example, as shown in fig. 2, the server 201 may include multiple PCIe x 4 interfaces, each PCIe x 4 interface for connecting to one SSD. The server runs 4 virtual machines 202, each virtual machine 202 corresponds to a PCIe × 4 interface, the virtual machine 202 is configured to execute a test script of the SSD connected to the PCIe × 4 interface, and the test script may be set corresponding to one or more test cases of the SSD.

For another example, as shown in fig. 4, the server 201 may include a PCIe × 16 interface, the PCIe × 16 interface is connected to a converter 204 (e.g., PCIe Switch), the converter 204 is configured to convert the PCIe × 16 interface on the server 201 into 4 PCIe × 4 interfaces, and each PCIe × 4 interface is configured to connect to an SSD. The server 201 runs 4 virtual machines 202, each virtual machine 202 corresponds to a PCIe × 4 interface, and the virtual machine 202 is configured to execute a test script of an SSD connected to the PCIe × 4 interface.

For each virtual machine 202, if one virtual machine corresponds to one physical interface, the device names of the devices 203 to be tested connected to the physical interface corresponding to the virtual machine 202 are uniform. That is to say, no matter whether the device identifiers of the devices 203 to be tested connected to the physical interfaces corresponding to each virtual machine 202 are the same, the device names of the devices 203 to be tested connected to the physical interfaces in the virtual machine 202 are uniform.

For example, a server runs 4 virtual machines (e.g., virtual machine 1 to virtual machine 4), the server is connected with 4 SSDs (e.g., SSD1 to SSD4) through 4 physical interfaces (e.g., physical interface 1 to physical interface 4), and virtual machine 1 to virtual machine 4 are in one-to-one correspondence with physical interface 1 to physical interface 4, respectively. When the server tests SSD 1-SSD 4, virtual machine 1-virtual machine 4 respectively execute the test scripts of SSD 1-SSD 4, the device name of SSD1 in virtual machine 1 may be non-volatile memory (NVME) 0, the device name of SSD2 in virtual machine 2 may be NVME2, the device name of SSD3 in virtual machine 3 may be NVME3, and the device name of SSD4 in virtual machine 4 may be NVME 4. If the drive letter (i.e., the "device identification" mentioned above) changes to SSD5 after the SSD2 has been power down tested, the device name of SSD2 in virtual machine 2 is still NVME 2.

For another example, when the server tests another 4 SSDs (e.g., SSD6 to SSD9), SSD6 to SSD9 are connected to physical interface 1 to physical interface 4, respectively, the device name of SSD6 in virtual machine 1 is still NVME1, the device name of SSD7 in virtual machine 2 is still NVME2, the device name of SSD8 in virtual machine 3 is still NVME3, and the device name of SSD9 in virtual machine 4 is still NVME 4.

It can be understood that, in this embodiment of the present application, each virtual machine may correspond to one physical interface, and for the virtual machine, names of devices to be tested connected to the corresponding physical interfaces are uniform, so that when multiple devices to be tested are tested for the same function, the same test script may be used. And even if the drive letter is changed when the equipment to be tested is subjected to power-down test, the test script of the equipment to be tested does not need to be modified, the development difficulty of the test script can be reduced, and the test cost is lower.

Optionally, before each virtual machine 202 executes the test script of the device under test 203 corresponding to the virtual machine 202, the virtual machine 202 may send a start test request to the server 201, and the server 201 determines, based on the start test request sent by the virtual machine 202, whether available resources on the server 201 are greater than or equal to resources consumed by executing the test script of the device under test 203. In the case where the server 201 determines that the available resources of the server 201 are greater than or equal to the resources consumed by executing the test script of the device under test 203, the server 201 instructs the virtual machine 202 to start the test. That is to say, in the embodiment of the present application, before executing the corresponding test script, each virtual machine may request the server whether the test can be started, and only when the available resources of the server are sufficient, the test script is started to be executed, so that the problems of abnormal test script, substandard test and the like caused by insufficient resources can be avoided.

Optionally, the resource consumed by executing the test script of the device under test 203 may be a processor bandwidth that needs to be consumed and/or a memory bandwidth that needs to be consumed when the virtual machine 202 executes the test script. It should be noted that, only the resource consumed by executing the test script of the device under test 203 is the processor bandwidth and the memory bandwidth that need to be consumed as an example, in an actual application, the resource consumed by executing the test script of the device under test 203 may also be represented by parameters such as the occupied time and the occupied rate of the processor and/or the occupied size and the occupied rate of the memory, or the resource consumption may also include consumption of other hardware resources such as a network interface card and an input/output device, which is not specifically limited in this embodiment of the present application.

In an implementation manner, the start test request is used to indicate a resource consumed by executing a test script of the device under test 203, so that the server 201 can determine resource consumption of executing the test script of the device under test 203 according to the start test request and determine whether the available resource of the server 201 currently satisfies the resource consumption.

In another implementation manner, resource consumption corresponding to execution of the test script of the device under test 203 may be pre-stored in the server 201, so that the server 201 may determine, from the pre-stored resource consumption for executing the test script of the device under test 203, and determine whether the available resource of the server 201 currently satisfies the resource consumption.

As shown in fig. 2 or fig. 4, the test system may further include a Baseboard Management Controller (BMC) 205, wherein the server 201 is coupled to the plurality of devices under test 203 through the BMC205, and the BMC205 is coupled to the converter 204.

Illustratively, the server 201 may include a Remote Procedure Call (RPC) interface through which the server is connected with the BMC205 and a network line through which the plurality of virtual machines 202 running on the server 201 may send control commands to the BMC 205. The control commands may include, but are not limited to, power management commands, management interface messages, and the like. Optionally, each virtual machine 202 has its own virtual network device (e.g., a virtual network card), and the virtual machine 202 may communicate with the server 201 through the virtual network card or may directly access the BMC205 through the network.

Illustratively, the device under test 203 may include a Management Interface (MI). As shown in fig. 2 or fig. 4, the MI interface of the device under test 203 is connected to the BMC205 through a system management bus (SMBus). Each virtual machine 202 may send an MI message to an MI interface of a corresponding device under test through the BMC205 to request management information of the device under test. The management information of the device under test includes, but is not limited to, temperature, operation information, background information, and the like of the device under test.

As shown in fig. 4, the BMC205 and the converter 204 may be connected via a PCIe bus, and the virtual machine 202 may send a request message to the converter 204 via the BMC205 to request management information of the converter 204. The management information of the converter 204 includes, but is not limited to, the current bandwidth of the converter 204, signal information, eye pattern information, and the like.

As shown in fig. 4, the server 201 and the converter 204 may be connected by a PCIe bus, and the converter 204 and the device under test 203 may also be connected by a PCIe bus. The server 201 may be coupled to the multiple devices under test 203 through the converter 204, and each virtual machine 202 running on the server 201 may send functional commands such as an Input Output (IO) command, an administrator command (admin command), and the like to the corresponding device under test 203 through the converter 204.

As shown in fig. 4, the BMC205 may further be coupled to a power control end of a plurality of devices to be tested 203, each virtual machine 202 may send power-up and power-down indication information to the BMC205, and the BMC205 controls the device to be tested 203 corresponding to the virtual machine 202 to be powered up or powered down according to the power-up and power-down indication information of the virtual machine 202.

Optionally, after the virtual machine 202 finishes executing the test script of the device to be tested 203 connected to the physical interface corresponding to the virtual machine 202 (that is, after the virtual machine 202 finishes testing the device to be tested 203 connected to the corresponding physical interface), a test completion message may be sent to the server 201, and after the server 201 learns that the virtual machine 202 finishes testing, the virtual machine 202 may be closed, so as to save resources and reduce overhead. Moreover, when the device 203 to be tested connected to the physical interface corresponding to the virtual machine 202 is tested next time, the server 201 may start the virtual machine 202 again, and since the adaptation script is executed in the process of starting the virtual machine 202, the virtual machine 202 may be associated with the device 203 to be tested connected to the physical interface corresponding to the virtual machine 202 after being started, so that the virtual machine 202 may continue to test the device 203 to be tested connected to the physical interface corresponding to the virtual machine 202.

Optionally, if a bug occurs in the process of testing the device under test 203 by the virtual machine 202, causing a test failure, the virtual machine 202 may send a test failure message to the server 201, and the server 201 may close the virtual machine 202 based on the test failure message. Therefore, when the virtual machine 202 tests the device 203 to be tested connected to the physical interface corresponding to the virtual machine 202 next time, the server 201 may start the virtual machine 202 again, and since the adaptation script is executed in the starting process of the virtual machine 202, the virtual machine 202 may be associated with the device 203 to be tested connected to the physical interface corresponding to the virtual machine 202 after being started, so that the virtual machine 202 may continue to test the device 203 to be tested.

For example, the device under test 203 connected to the physical interface corresponding to the next test of the virtual machine 202 may be the same as the device under test 203 tested at the previous test, for example, two tests of the virtual machine 202 are performed on the same device under test 203 under different drivers. The device 203 to be tested connected to the physical interface corresponding to the next test of the virtual machine 202 may also be different from the device 203 to be tested in the previous test, for example, the two tests of the virtual machine 202 are to test different devices 203 to be tested connected to the same physical interface.

That is to say, in the test system provided in the embodiment of the present application, after the virtual machine has tested the device to be tested each time or the test fails, the server may close the virtual machine, and when the device to be tested connected to the physical interface corresponding to the virtual machine is tested next time, the server opens the virtual machine again, so that the virtual machine can be associated with the device to be tested, and the device to be tested is tested.

The following describes the test method provided by the embodiment of the present application with reference to fig. 2 and 4. The server in the following embodiments may be the server 201 in fig. 2 or fig. 4, the virtual machine in the following embodiments may be the virtual machine 202 in fig. 2 or fig. 4, the device under test in the following embodiments may be the device under test 203 in fig. 2 or fig. 4, the converter in the following embodiments may be the converter 204 in fig. 4, and the BMC in the following embodiments may be the BMC205 in fig. 2 or fig. 4.

As shown in fig. 5, a testing method provided for the embodiment of the present application is applied to a testing system, where the testing system includes a server, where the server runs multiple virtual machines, each virtual machine corresponds to one or multiple physical interfaces, each physical interface is used to connect to a device to be tested, and each virtual machine is used to test the device to be tested connected to the physical interface corresponding to the virtual machine, and the testing method includes the following steps:

s301, the server acquires indication information.

The indication information is used for indicating the server to test at least two devices to be tested, and the indication information comprises physical interface information of the at least two devices to be tested. Optionally, the physical interface information of each device to be tested may be a physical interface identifier of the device to be tested, and the physical interface may be an interface on a server or an interface on a converter coupled to the server.

Optionally, the indication information in step S301 may also be used to instruct the server to test at least two devices to be tested simultaneously. It should be noted that, in the embodiment of the present application, when the indication information indicates that the server simultaneously tests at least two devices to be tested, the test of the at least two devices to be tested may have a part of time periods overlapping, or the test time of a part of the devices to be tested in the at least two devices to be tested may not overlap, which is related to a specific situation of available resources of the server, and the following steps S305 to S308 may be specifically referred to. That is to say, in the embodiment of the present application, although the indication information may indicate the server to test multiple devices to be tested simultaneously, according to different conditions of available resources of the server, the test times of the multiple devices to be tested may completely overlap, a part of the time periods may overlap, and the test times of a part of the multiple devices to be tested may not completely overlap.

The test method provided by the embodiment of the application can be applied to a scene of testing a plurality of devices to be tested, the indication information is used for indicating that the number of the devices to be tested by the server is multiple, and the indication information indicates that the number of the devices to be tested by the server is less than or equal to the maximum number of the devices to be tested which can be tested by the test system. The maximum number of the devices to be tested which can be tested by the test system is the number of the physical interfaces included in the test system.

For example, taking the test system including 4 physical interfaces, namely PCIe interface 1 to PCIe interface 4 as an example, each PCIe interface is used to connect to one SSD, and the test system can test 4 SSDs at most. The indication information obtained by the server in step S301 is used to indicate that the number of SSDs tested by the server may be 2, or 3 or 4. If the PCIe interface 1 and the PCIe interface 2 in the test system are connected to one SSD respectively, the indication information obtained by the server may be used to indicate the server to test the two SSDs, where the indication information includes physical interface information of the two SSDs, which are the PCIe interface 1 and the PCIe interface 2 respectively.

For example, the server acquiring the indication information may include the server receiving the indication information input by the user. The embodiment of the present application is not limited to the specific manner in which the server obtains the indication information, and is only an exemplary illustration here.

Optionally, the indication information obtained by the server may further indicate that the server tests multiple devices to be tested under different drivers, and the test scripts of the multiple devices to be tested under different drivers may be different. For example, the indication information is for instructing the server to test the SSD1 and the SSD2 under drive a, the SSD1 and the SSD2 under drive B, and the test script for testing the SSD1 under drive a is different from the test script for testing the SSD1 under drive B. When the indication information is used to indicate the server to test the multiple devices under test under different drivers, the server may test the multiple devices under test under one driver first, and after the multiple devices under test under the driver are tested, test the multiple devices under test under another driver.

S302, the server starts the virtual machines corresponding to the at least two devices to be tested based on the indication information.

In this embodiment of the present application, one virtual machine may correspond to one physical interface, or may correspond to multiple physical interfaces, and the following embodiment takes an example in which one virtual machine corresponds to one physical interface as an example.

When one virtual machine corresponds to one physical interface, the server can determine the virtual machine corresponding to each piece of physical interface information based on the physical interface information of at least two pieces of equipment to be tested in the indication information, and start the corresponding virtual machine.

For example, the server runs the connectors 1 to 4, the plurality of physical interfaces include PCIe interfaces 1 to 4, the connectors 1 to 4 respectively correspond to the PCIe interfaces 1 to 4 one to one, the indication information is used to indicate the server to test two SSDs, the interface information of the two SSDs is, for example, PCIe interface 1 and PCIe interface 2, and the server respectively opens the connector 1 corresponding to the PCIe interface 1 and the connector 2 corresponding to the PCIe interface 2 based on the interface information (PCIe interface 1 and PCIe interface 2) of the two SSDs in the indication information.

Optionally, the adaptation script may be executed in the process of starting the virtual machine, so that the virtual machine may be associated with the device to be tested connected to the physical interface corresponding to the virtual machine after being started.

In the embodiment of the application, when the server tests the device to be tested each time, the virtual machine corresponding to the device to be tested can be started according to the physical interface information of the device to be tested, and after the virtual machine tests the device to be tested, the server can close the virtual machine. Therefore, on one hand, resources of the server can be saved, and overhead can be reduced, and on the other hand, when the device to be tested connected to the physical interface is tested next time, the server can start the virtual machine again, so that the virtual machine can be associated with the device to be tested, and the device to be tested is tested.

S303, optionally, the server sends the test script information of the device to be tested corresponding to the virtual machine.

For example, when at least two devices under test correspond to at least two virtual machines, the server may send, to each of the at least two virtual machines, test script information of the device under test corresponding to the virtual machine. The sending, by the server, the test script information of the device to be tested corresponding to the virtual machine may include: and the server sends the specific code of the test script of the device to be tested corresponding to each virtual machine, or the server sends the file name of the test script of the device to be tested corresponding to each virtual machine. The specific content of the test script information of the device to be tested is not limited in the embodiments of the present application, and the following embodiments take the test script information of the device to be tested as an example of a file name of the test script of the device to be tested.

For example, after the server opens the Container1 corresponding to PCIe interface 1 and the Container2 corresponding to PCIe interface 2, the server may send the file name of the test script of SSD1 to Container1 and send the file name of the test script of SSD2 to Container2, respectively.

And S304, the virtual machine executes the test script of the equipment to be tested corresponding to the virtual machine.

The executing, by the virtual machine, the test script of the device to be tested corresponding to the virtual machine may include: and the virtual machine executes the test script of the equipment to be tested corresponding to the virtual machine based on the test script information.

Optionally, a plurality of virtual machines running on the server may share a part of the storage space, and the storage space is used for storing information such as test scripts and test results of a plurality of devices to be tested. After the server sends the file name of the corresponding test script to each virtual machine, the virtual machine may execute the corresponding test script based on the file name of the test script.

For example, Container1 executes the test script of SSD1 based on the file name of the test script of SSD 1. Container2 executes the test script of SSD2 based on the file name of the test script of SSD 2.

As shown in fig. 2, in a case that the server includes a plurality of physical interfaces, the at least two devices to be tested may be connected to the at least two physical interfaces of the server, and in a process that the virtual machine executes a test script of the device to be tested corresponding to the virtual machine, the virtual machine may send an access request to the device to be tested connected to the corresponding physical interface. Optionally, the access request includes, but is not limited to, an IO command (IO command), an administrator command (admin command), and other functional commands.

As shown in fig. 4, in a case that the test system includes a converter, the converter includes a plurality of physical interfaces, the server may connect the at least two devices to be tested through the at least two physical interfaces on the converter, and in a process that the virtual machine executes a test script of the device to be tested corresponding to the virtual machine, the virtual machine may send an access request to the device to be tested corresponding to the virtual machine through the converter, where the access request includes an identifier of the device to be tested corresponding to the virtual machine.

Optionally, for each virtual machine, the device names of the devices to be tested connected to the physical interface corresponding to the virtual machine are uniform.

For example, whether the device to be tested connected to PCIe interface 1 is SSD1 or SSD5, the name of the device to be tested connected to PCIe interface 1 in Container1 is NVME 1. For another example, in the process that the Container1 executes the test script of the SSD1, if the SSD1 is to be subjected to the power-down test, the drive letter of the SSD1 after the power-down test may be changed, but for the Container1, no matter how many the drive letter of the SSD1 is changed, the device name of the SSD1 in the Container1 is always NVME1, so even if the drive letter of the SSD1 after the power-down test is changed, the test script of the SSD1 does not need to be modified, the development difficulty of the test script can be reduced, and the test cost is low.

It can be understood that, with the test method provided in the embodiment of the present application, when a server tests multiple devices to be tested, test scripts of the multiple devices to be tested may be executed on different virtual machines respectively. Because the respective operating systems run on the different virtual machines, the test scripts of the devices to be tested run on the different operating systems, if one device to be tested fails in testing, the device to be tested in other virtual machines cannot be affected, the operating system of the server cannot be affected, and the testing efficiency can be improved. In each virtual machine of the embodiment of the application, the names of the devices to be tested connected with the physical interfaces corresponding to the virtual machines are uniform, so that even if the drive letter of the device to be tested is changed after the power failure test, the test script of the device to be tested does not need to be changed, the development difficulty of the test script can be reduced, and the test cost is low.

Optionally, because the bandwidth and the processing capability of the server are limited, if a multi-process technology is adopted to test a plurality of SSDs simultaneously, resource preemption may occur, resulting in abnormal test and failing to reach the test target. In order to alleviate the problem that resource preemption may occur when a server tests multiple devices to be tested, which results in abnormal test, an embodiment of the present application further provides a test method, as shown in fig. 6, where the test method may further include the following steps S305 to S308 before the step S304. The virtual machines in steps S305 to S308 are corresponding to the at least two devices under test, and if the at least two devices under test correspond to multiple virtual machines, each of the multiple virtual machines may perform steps S305 to S308 before step S304.

S305, the virtual machine sends a test starting request to the server.

The test starting request is used for requesting to start executing the test script of the device to be tested corresponding to the virtual machine. That is, the start test request sent by the virtual machine to the server is used to request the server to start testing the device to be tested.

For example, after the Container1 receives the file name of the test script of the SSD1 sent by the server, it sends a test start request to the server before executing the test script of the SSD 1. After receiving the file name of the test script of the SSD2 sent by the server, the Container2 sends a start test request to the server before executing the test script of the SSD 2.

Optionally, the start test request sent by the virtual machine to the server may be used to instruct the virtual machine to execute the resources consumed by the corresponding test script.

Optionally, the resources consumed by the virtual machine to execute the corresponding test script may also be stored in the server in advance.

It can be understood that, in the embodiment of the present application, the device to be tested corresponding to the virtual machine refers to the device to be tested connected to the physical interface corresponding to the virtual machine, and the test script corresponding to the virtual machine refers to the test script of the device to be tested connected to the physical interface corresponding to the virtual machine.

S306, the server determines available resources of the server based on the starting test request.

The available resources of the server include processor bandwidth, memory bandwidth and other information which can indicate the consumption of hardware resources of the server. The specific parameters of the available resources of the server in the embodiments of the present application are not limited, and are only exemplary.

After receiving the starting test request from the virtual machine, the server can determine whether the available resources of the server are enough for the virtual machine to execute the test script. If the available resources of the server are greater than or equal to the resources consumed for executing the test script of the device under test, it is determined that the available resources of the server are sufficient for executing the test script of the device under test, and the step S307 is continued. And under the condition that the available resources of the server are less than the resources consumed by executing the test script of the device to be tested, determining that the available resources of the server are insufficient. In the case that the available resources of the server are insufficient, if the virtual machine executes the test script, the test exception will be caused, so the server may indicate that the virtual machine is in a waiting execution state, until the available resources on the server are sufficient, the server may further indicate the virtual machine to execute its corresponding test script.

For example, taking the currently available resource of the server as 30G, the resource consumed by the Container1 to execute the test script of the SSD1 as 20G, and the resource consumed by the Container2 to execute the test script of the SSD2 as 25G, after the Container1 sends the start test request to the server, the server determines that the available resource 30G is greater than the resource 20G consumed by the server to execute the test script of the SSD1, and the server sends the start test instruction to the Container1 and updates the available resource to 10G. After the Container2 sends the launch test request to the server, the server determines that its available resources 10G are less than the resources 25G consumed by executing the test scripts of SSD2, and the server may send a wait for execution instruction to the Container2 with the Container2 in a wait for execution state. After the Container1 executes the test script of the SSD1, the Container1 sends a test completion message to the server, the server updates the available resource to 30G, and the server determines that the available resource 30G is greater than the resource 25G consumed by executing the test script of the SSD2, so the server sends a start test instruction to the Container 2.

S307, under the condition that the available resources of the server are larger than or equal to the resources consumed by executing the test script of the device to be tested, the server sends a test starting instruction to the virtual machine.

The start test instruction is used for instructing the virtual machine to start executing the test script of the corresponding device to be tested.

S308, the virtual machine receives a starting test instruction.

And after the virtual machine receives the starting test instruction from the server, starting to execute the test script of the equipment to be tested corresponding to the virtual machine. That is, after the server instructs the virtual machine to start the test, the virtual machine starts to execute the corresponding test script based on the start test instruction.

Accordingly, the step S304 may include: and the virtual machine executes the test script of the equipment to be tested corresponding to the virtual machine based on the starting test instruction and the test script information.

It can be understood that, in the embodiment of the present application, specific information of available resources of the server is dynamically changed, and after receiving a start test request sent by a virtual machine, the server may determine whether current available resources of the server are sufficient according to resources that need to be consumed for executing a test script corresponding to the virtual machine, and instruct the virtual machine to execute the corresponding test script if the available resources of the server are sufficient, so as to ensure that hardware resources of each virtual machine when executing the corresponding test script are sufficient, and to avoid problems such as abnormal test script, substandard test, and the like caused by insufficient resources.

Optionally, in a case that the virtual machine completes execution of the test script of the device under test corresponding to the virtual machine, as shown in fig. 7, an embodiment of the present application further provides a test method, and after the above steps S301 to S308, the method may further include the following steps S309 to S310:

s309, under the condition that the virtual machine finishes executing the test script of the device to be tested corresponding to the virtual machine, the virtual machine sends a test finishing message to the server.

Optionally, if the indication information is used to indicate the server to test multiple devices to be tested under different drivers, the test completion message is used to indicate the virtual machine to complete executing the test script of the device to be tested corresponding to the virtual machine under a certain set of drivers. For example, when the virtual machine has executed a test script of the device under test corresponding to the virtual machine under a certain set of driving, the virtual machine may send a test completion message to the server.

And S310, the server closes the virtual machine based on the test completion message.

Optionally, the server may further update information of the currently available resource of the server based on the test completion message sent by the virtual machine.

According to the embodiment of the application, after the virtual machine tests the corresponding device to be tested, the test completion message is sent to the server, so that the server can close the virtual machine based on the test completion message, resources of the server can be saved, overhead is reduced, and the virtual machine can be started again by the server when the device to be tested connected to the physical interface corresponding to the virtual machine is tested next time, so that the virtual machine can be associated with the device to be tested, and the device to be tested is tested.

If the indication information in step S301 is used to instruct the server to test a plurality of devices under test simultaneously under different drivers, the above steps S302-S310 are performed during testing under each driver. For example, the indication information is used to instruct the server to simultaneously test SSD1 and SSD2 under drive a, SSD1 and SSD2 under drive B, the test script of SSD1 under drive a is test script 1, the test script of SSD2 under drive a is test script 2, the test script of SSD1 under drive B is test script 3, and the test script of SSD2 under drive B is test script 4. When the server runs the drive A, the server starts a Container1 corresponding to the SSD1 and a Container2 corresponding to the SSD2 based on the indication information, sends the file name of the test script 1 of the SSD1 to the Container1, sends the file name of the test script 2 of the SSD2 to the Container2, sends a test completion message to the server after the Container1 executes the test script 1 of the SSD1, closes the Container1, sends the test completion message to the server after the Container2 executes the test script 2 of the SSD2, and closes the Container 2. After the server determines that the SSD1 and the SSD2 are tested completely, the server further judges whether other drives need to be tested and determines that the drives B need to be tested, the server starts the Container1 corresponding to the SSD1 and the Container2 corresponding to the SSD2, sends the file name of the test script 3 of the SSD1 to the Container1, sends the file name of the test script 4 of the SSD2 to the Container2, sends a test completion message to the server after the Container1 completes executing the test script 3 of the SSD1, closes the Container1, sends the test completion message to the server after the Container2 completes executing the test script 4 of the SSD2, and closes the Container 2. The server further judges whether other drivers need to be tested or not, determines that other sub-processes do not exist, and determines that the test is finished.

Optionally, in the case that the virtual machine fails to be tested, an embodiment of the present application further provides a testing method, as shown in fig. 8, after the above steps S301 to S308, the method may further include the following steps S311 to S312:

s311, when the virtual machine fails in testing, the virtual machine sends a test failure message to the server.

Optionally, if the indication information is used to indicate the server to test the multiple devices to be tested simultaneously under different drivers, the test failure message is used to indicate that the virtual machine fails to test under a certain set of drivers.

And S312, the server closes the virtual machine based on the test failure message.

Optionally, if the indication information is used to indicate the server to test a plurality of devices to be tested under different drivers at the same time, and when a plurality of devices to be tested are tested under one driver at the same time, if one device to be tested fails to test, the virtual machine executing the test script of the device to be tested may notify the server of the test failure, the server may close the virtual machine, wait for completion of testing of other devices to be tested under the driver, switch the drivers, and test the plurality of devices to be tested under the switched driver at the same time.

According to the embodiment of the application, after the virtual machine fails to be tested, the test failure message is sent to the server, so that the server can close the virtual machine based on the test failure message, resources of the server can be saved, expenses can be reduced, and when the equipment to be tested connected to the physical interface corresponding to the virtual machine is tested next time, the virtual machine can be started again by the server, so that the virtual machine can be associated with the equipment to be tested, and the equipment to be tested is tested.

Optionally, with reference to fig. 4 and as shown in fig. 9, in a process that the virtual machine executes the test script of the device to be tested according to the embodiment of the present application, if the test case of the device to be tested includes a power down test, as shown in fig. 9, the method may further include the following steps S313 to S314 in addition to the steps S301 to S310. In the process of executing the test script of the device to be tested corresponding to the virtual machine, if the test case of the device to be tested includes acquiring the management information of the device to be tested, as shown in fig. 9, the method may further include the following steps S315 to S316 in addition to the steps S301 to S310. In the process of executing the test script of the device under test corresponding to the virtual machine, if the test case of the device under test includes acquiring the management information of the converter, as shown in fig. 9, the method may further include the following steps S317 to S318 in addition to the above steps S301 to S310.

S313, the virtual machine sends power-on and power-off indication information to the BMC.

The power-on and power-off indication information comprises an identifier of the device to be tested corresponding to the virtual machine, and the power-on and power-off indication information is used for indicating the BMC to control the power-on or power-off of the device to be tested corresponding to the virtual machine. Optionally, the identifier of the device under test may include, but is not limited to, physical interface information to which the device under test is connected.

For example, in the process that the Container1 tests the SSD1, if the SSD1 needs to be subjected to a power down test, the Container1 may send, to the BMC through the RPC interface, power up and power down indication information carrying the SSD1 identifier, where the power up and power down indication information is used for indicating the BMC to control the SSD1 to power down.

And S314, the BMC controls the power-on or power-off of the equipment to be tested based on the power-on and power-off indication information.

For example, after receiving the power-up/down indication information from the Container1, the BMC controls the SSD1 to power down according to the SSD1 flag carried in the power-up/down indication information.

As can be understood, because the test system in the embodiment of the application includes the BMC, the BMC is coupled with each device to be tested, and each virtual machine can send power management information to the BMC through the RPC interface to control the device to be tested corresponding to the virtual machine to power on and power off, it is possible to independently control each device to be tested to power on or power off, and the test capability is improved.

S315, the virtual machine sends a first request message to the device to be tested corresponding to the virtual machine through the BMC.

The first request message is used for requesting management information of the device to be tested corresponding to the virtual machine, and the first request message includes an identifier of the device to be tested corresponding to the virtual machine.

Optionally, the first request message includes, but is not limited to, an MI message. For example, Container1 sends an MI message carrying the identifier of SSD1 to the BMC via the RPC interface, and the BMC sends the MI message to SSD1 via the SMbus based on the identifier of SSD 1.

For example, the management message of the device under test includes, but is not limited to, the temperature of the device under test, the operation information of the device under test, the background information of the device under test, and the like. The specific content of the management information of the device under test is not limited in the embodiments of the present application, and is only an exemplary description here.

And S316, the device to be tested sends a first response message to the virtual machine through the BMC.

The first response message includes management information of the device under test. Optionally, the first response message further includes an identifier of the device to be tested corresponding to the virtual machine.

For example, the SSD1 sends a first response message to the BMC through the SMbus, where the first response message includes information such as the temperature, the running information, the background information, and the SSD1 identifier of the SSD1, and the BMC sends information such as the temperature, the running information, and the background information of the SSD1 to the Container1 based on the SSD1 identifier.

And S317, the virtual machine sends a second request message to the converter through the BMC.

The second request message is for requesting management information of the converter.

Illustratively, the management information of the converter includes, but is not limited to, the current bandwidth of the converter, signal information, eye pattern information, and the like. The specific content of the management information of the converter in the embodiments of the present application is not limited, and is only an exemplary description here.

And S318, the converter sends a second response message to the virtual machine through the BMC.

The second response message includes management information of the converter.

In the embodiment of the present application, the execution sequence of the above steps S313 to S314, S315 to S316, and S317 to S318 is not limited, and fig. 9 is only an exemplary illustration. For example, S315-S316 may be performed first, followed by S313-S314, and S317-S318. For another example, S317-S318 may be performed first, followed by S313-S314, and S315-S316. As another example, S313-S314, S315-S316, S317-S318 may be performed simultaneously.

According to the test method provided by the embodiment of the application, each virtual machine can send control commands such as MI information and power management to the BMC through the unified RPC interface, so that not only can the management information of the converter and each SSD be obtained, but also the power of each SSD can be independently controlled, and the test capability can be improved.

An embodiment of the present application further provides a computer-readable storage medium, where computer program codes are stored in the computer-readable storage medium, and when the processor executes the computer program codes, the electronic device executes the test method shown in any one of fig. 5 to 9.

The embodiment of the present application further provides a computer program product, which when running on a computer, causes the computer to execute the testing method shown in any one of fig. 5 to 9.

The steps of a method or algorithm described in connection with the disclosure herein may be embodied in hardware or in software instructions executed by a processor. The software instructions may be comprised of corresponding software modules that may be stored in Random Access Memory (RAM), flash memory, Erasable Programmable Read Only Memory (EPROM), Electrically Erasable Programmable Read Only Memory (EEPROM), registers, a hard disk, a removable disk, a compact disc read only memory (CD-ROM), or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. Of course, the storage medium may also be integral to the processor. The processor and the storage medium may reside in an ASIC. Additionally, the ASIC may reside in a core network interface device. Of course, the processor and the storage medium may reside as discrete components in a core network interface device.

Those skilled in the art will recognize that, in one or more of the examples described above, the functions described in this invention may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.

The above-mentioned embodiments, objects, technical solutions and advantages of the present invention are further described in detail, it should be understood that the above-mentioned embodiments are only exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made on the basis of the technical solutions of the present invention should be included in the scope of the present invention.

Claims

1. A testing method is applied to a testing system, the testing system comprises a server, a plurality of virtual machines run on the server, each virtual machine corresponds to one or more physical interfaces, each physical interface is used for connecting a device to be tested, and each virtual machine is used for testing the device to be tested connected to the physical interface corresponding to the virtual machine, and the method comprises the following steps:

the server acquires indication information, wherein the indication information is used for indicating the server to test at least two devices to be tested, and the indication information comprises physical interface information of the at least two devices to be tested;

the server starts the virtual machines corresponding to the at least two devices to be tested based on the indication information;

and the virtual machine executes the test script of the equipment to be tested corresponding to the virtual machine.

2. The method according to claim 1, wherein before the virtual machine executes the test script of the device under test corresponding to the virtual machine, the method further comprises:

the virtual machine sends a test starting request to the server, wherein the test starting request is used for requesting to start executing a test script of the equipment to be tested corresponding to the virtual machine;

the server determines available resources of the server based on the starting test request;

under the condition that the available resources of the server are greater than or equal to the resources consumed by executing the test script of the equipment to be tested, the server sends a test starting instruction to the virtual machine;

and the virtual machine receives the starting test instruction.

3. The method of testing of claim 1, further comprising:

under the condition that the virtual machine finishes executing the test script of the equipment to be tested corresponding to the virtual machine, the virtual machine sends a test finishing message to the server;

and the server closes the virtual machine based on the test completion message.

4. The method of testing of claim 1, further comprising:

under the condition that the virtual machine fails in testing, the virtual machine sends a test failure message to the server;

the server closes the virtual machine based on the test failure message.

5. The method of any of claims 1-4, wherein the test system further comprises a Baseboard Management Controller (BMC), and wherein the server is coupled to the at least two devices under test via the BMC, and wherein the method further comprises:

the virtual machine sends a first request message to the device to be tested corresponding to the virtual machine through the BMC, the first request message comprises an identifier of the device to be tested corresponding to the virtual machine, and the first request message is used for requesting management information of the device to be tested corresponding to the virtual machine;

the virtual machine receives a first response message from the device to be tested through the BMC, wherein the first response message comprises management information of the device to be tested.

6. The method of any of claims 1-4, wherein the test system further comprises a Baseboard Management Controller (BMC), and wherein the server is coupled to the at least two devices under test via the BMC, and wherein the method further comprises:

the virtual machine sends power-on and power-off indication information to the BMC, the power-on and power-off indication information comprises an identifier of the to-be-tested device corresponding to the virtual machine, and the power-on and power-off indication information is used for indicating the BMC to control the to-be-tested device corresponding to the virtual machine to be powered on or powered off;

and the BMC controls the power-on or power-off of the equipment to be tested based on the power-on and power-off indication information.

7. The method of any of claims 1-4, wherein the test system further comprises a Baseboard Management Controller (BMC) and a translator, wherein the server is coupled to the at least two devices under test via the BMC, wherein the translator comprises the plurality of physical interfaces, wherein the server is coupled to the at least two devices under test via the translator, wherein the translator is coupled to the BMC, and wherein the method further comprises:

the virtual machine sends a second request message to the converter through the BMC, wherein the second request message is used for requesting management information of the converter;

and the converter sends a second response message to the virtual machine through the BMC, wherein the second response message comprises the management information of the converter.

8. The method of any one of claims 1-4, wherein the test system further comprises a converter, the converter comprising the plurality of physical interfaces, the server coupled to the at least two devices under test through the converter, the method further comprising:

and the virtual machine sends an access request to the equipment to be tested corresponding to the virtual machine through the converter, wherein the access request comprises the identification of the equipment to be tested corresponding to the virtual machine.

9. The test method according to any one of claims 1-4, wherein the method further comprises:

and the server sends the test script information of the equipment to be tested corresponding to the virtual machine.

10. A testing method according to any one of claims 1-4, wherein the virtual machine comprises a Docker or Linux container.

11. The method of any one of claims 1-4, wherein the device under test comprises a memory device or a Universal Serial Bus (USB) device.

12. The method of claim 10, wherein the storage device comprises a Solid State Disk (SSD).

13. A test system is characterized in that the test system comprises a server, wherein a plurality of virtual machines run on the server, each virtual machine corresponds to one or more physical interfaces, each physical interface is used for connecting a device to be tested, and each virtual machine is used for testing the device to be tested connected to the physical interface corresponding to the virtual machine;

the server is used for acquiring indication information, wherein the indication information is used for indicating the server to test at least two devices to be tested, and the indication information comprises physical interface information of the at least two devices to be tested;

the server is further configured to start the virtual machines corresponding to the at least two devices to be tested based on the indication information;

and the virtual machine is used for executing the test script of the equipment to be tested corresponding to the virtual machine.

14. The test system of claim 13,

the virtual machine is further configured to send a test starting request to the server, where the test starting request is used to request to start executing a test script of the device to be tested corresponding to the virtual machine;

the server is further used for determining available resources of the server based on the starting test request;

the server is further used for sending a test starting instruction to the virtual machine under the condition that the available resources of the server are greater than or equal to the resources consumed by executing the test script of the device to be tested;

the virtual machine is further used for receiving the starting test instruction.

15. The test system of claim 13,

the virtual machine is further configured to send a test completion message to the server when the virtual machine completes execution of the test script of the device to be tested corresponding to the virtual machine;

the server is further configured to close the virtual machine based on the test completion message.

16. The test system of claim 13,

the virtual machine is further used for sending a test failure message to the server under the condition that the virtual machine fails in testing;

the server is further configured to close the virtual machine based on the test failure message.

17. The test system according to any of claims 13-16, wherein the test system further comprises a baseboard management controller, BMC, and the server is coupled to the at least two devices under test through the BMC;

the virtual machine is further configured to send a first request message to the device to be tested corresponding to the virtual machine through the BMC, where the first request message includes an identifier of the device to be tested corresponding to the virtual machine, and the first request message is used to request management information of the device to be tested corresponding to the virtual machine;

the virtual machine is further configured to receive a first response message from the device to be tested through the BMC, where the first response message includes management information of the device to be tested.

18. The test system according to any of claims 13-16, wherein the test system further comprises a baseboard management controller, BMC, and the server is coupled to the at least two devices under test through the BMC;

the virtual machine is further configured to send power-up and power-down indication information to the BMC, where the power-up and power-down indication information includes an identifier of the device to be tested corresponding to the virtual machine, and the power-up and power-down indication information is used to indicate the BMC to control the power-up or power-down of the device to be tested corresponding to the virtual machine;

and the BMC is used for controlling the power-on or power-off of the equipment to be tested based on the power-on and power-off indication information.

19. The test system according to any one of claims 13 to 16, further comprising a baseboard management controller, BMC, and a translator, wherein the server is coupled to the at least two devices under test via the BMC, the translator comprises the plurality of physical interfaces, wherein the server is coupled to the at least two devices under test via the translator, and the translator is coupled to the BMC;

the virtual machine is further configured to send a second request message to the converter through the BMC, where the second request message is used to request management information of the converter;

the converter is further configured to send a second response message to the virtual machine through the BMC, where the second response message includes management information of the converter.

20. The test system according to any one of claims 13-16, further comprising a converter comprising the plurality of physical interfaces, the server coupled with the at least two devices under test through the converter;

the virtual machine is further configured to send an access request to the device to be tested corresponding to the virtual machine through the converter, where the access request includes an identifier of the device to be tested corresponding to the virtual machine.

21. The method according to any one of claims 13 to 16, wherein the server is further configured to send, to the virtual machine, test script information of the device under test corresponding to the virtual machine.

22. The test system of any of claims 13-16, wherein the virtual machine comprises a Docker or Linux container.

23. The test system of any one of claims 13-16, wherein the device under test comprises a memory device or a Universal Serial Bus (USB) device.

24. The test system of claim 23, wherein the storage device comprises a Solid State Disk (SSD).

25. A computer, characterized in that the computer comprises a processor and a memory for storing a computer program; the processor is adapted to execute the computer program such that the computer performs the testing method of any of claims 1-12.

26. A computer-readable storage medium having stored therein computer instructions which, when executed on a computer, cause the computer to perform the testing method of any one of claims 1-12.