Test method, device and equipment and computer readable storage medium

Abstract

The invention discloses a test method, device and equipment and a computer readable storage medium, and is applied to the technical field of redundant array of disk, and the test method comprises the following steps: determining a to-be-tested redundant array of disk firmware code, a to-be-executed test case and a virtual environment type corresponding to the to-be-executed test case; creating a virtual device based on the virtual environment type; the virtual device is a device for driving a redundant array of disk firmware code to be tested; and testing the to-be-tested redundant array of disk firmware code based on the virtual device and the to-be-executed test case. Compared with the current manual test, the method has the advantages that the virtual equipment is created based on the virtual environment type, and the virtual equipment is equipment for driving the to-be-tested redundant array firmware code, so that the virtual equipment and the to-be-tested redundant array firmware code can form a virtual redundant array card; therefore, automatic testing is directly carried out on the redundant array of disks based on the test case, and the testing efficiency of the redundant array of disks without real objects can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of disk array redundancy technology, and particularly to a test method, device, equipment and computer-readable storage medium. Background Art

[0002] A RAID (Redundant Array of Independent Disks) card is a device used to manage multiple hard disk drives, and is an important tool for realizing data redundancy and performance optimization, and is applicable to various application scenarios. In the early stage of the development phase of the RAID card, due to the lack of physical objects, it is necessary to rely on simulation tools and early prototype designs for manual testing, which requires a large amount of manpower and time investment, resulting in low test efficiency.

[0003] Therefore, how to improve the test efficiency of the RAID card in the development phase is a technical problem that needs to be urgently solved by those skilled in the art. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a test method, device, equipment and computer-readable storage medium, which solves the problem of low test efficiency of the RAID card in the development phase in the prior art.

[0005] To solve the above technical problems, the present invention provides a test method, including:

[0006] Determine the disk array redundancy firmware code to be tested and the test cases to be executed, as well as the virtual environment type corresponding to the test cases to be executed;

[0007] Create a virtual device based on the virtual environment type; wherein, the virtual device is a device that drives the disk array redundancy firmware code to be tested;

[0008] Test the disk array redundancy firmware code to be tested based on the virtual device and the test cases to be executed.

[0009] In some embodiments, determining the disk array redundancy firmware code to be tested and the test cases to be executed, as well as the virtual environment type corresponding to the test cases to be executed, includes:

[0010] Obtain the test plan information sent by the continuous integration tool; wherein, the continuous integration tool is a tool that automatically generates test plan information based on the automatically updated disk array redundancy firmware code;

[0011] Parse the test plan information to obtain the disk array redundancy firmware code to be tested and the test cases to be executed, as well as the virtual environment type corresponding to the test cases to be executed.

[0012] In some embodiments, obtaining test plan information sent by a continuous integration tool, including:

[0013] Obtaining the test plan information sent by the continuous integration tool through an interface based on the Message Queuing Telemetry Transport (MQTT) protocol; wherein, the interface based on the MQTT protocol is used to integrate the continuous integration tool with the virtual device.

[0014] In some embodiments, after determining the disk redundant array firmware code to be tested, the test cases to be executed, and the type of virtual environment corresponding to the test cases to be executed, it further includes:

[0015] Updating a test plan table in the database based on the disk redundant array firmware code to be tested; wherein, the test plan table is used to store the disk redundant array firmware code for testing;

[0016] Updating a test case table in the database based on the test cases to be executed; wherein, the test case table is used to store the executed test cases and the test cases to be executed;

[0017] Correspondingly, testing the disk redundant array firmware code to be tested based on the virtual device and the test cases to be executed includes:

[0018] Determining all the test cases to be executed existing in the database, and the type of virtual environment corresponding to each test case to be executed;

[0019] Determining whether there is an idle virtual device corresponding to the type of virtual environment;

[0020] When there is no corresponding idle virtual device, creating corresponding virtual devices based on the type of virtual environment corresponding to each test case to be executed;

[0021] Testing the disk redundant array firmware code to be tested based on all the test cases to be executed in the database and the corresponding virtual devices.

[0022] In some embodiments, testing the disk redundant array firmware code to be tested based on the virtual device and the test cases to be executed includes:

[0023] When there are a preset number of test cases to be executed, creating a preset number of virtual devices based on the type of virtual environment corresponding to each test case to be executed; wherein, the preset number is greater than 1;

[0024] Simultaneously testing the corresponding disk redundant array firmware code to be tested based on the preset number of test cases to be executed and the preset number of virtual devices.

[0025] In some embodiments, when there are a preset number of test cases to be executed, creating a preset number of virtual devices based on the virtual environment type corresponding to each test case to be executed, includes:

[0026] Using the virtual environment resource pool to create the preset number of virtual devices based on the virtual environment type corresponding to each test case to be executed.

[0027] In some embodiments, after creating a virtual environment based on the virtual environment type, and testing the firmware code of the disk redundant array to be tested based on the virtual environment and the test case to be executed, further includes:

[0028] Returning the test result and the execution status of the test case to the visualization display device for visualization display based on the visualization display device.

[0029] An embodiment of the present invention further provides a test device, including:

[0030] A virtual environment type determination module, configured to determine the firmware code of the disk redundant array to be tested and the test cases to be executed, and the virtual environment type corresponding to the test cases to be executed;

[0031] A virtual device creation module, configured to create a virtual device based on the virtual environment type; wherein, the virtual device is a device for driving the firmware code of the disk redundant array to be tested;

[0032] A test module, configured to test the firmware code of the disk redundant array to be tested based on the virtual device and the test case to be executed.

[0033] An embodiment of the present invention further provides a test device, including:

[0034] A memory, configured to store a computer program;

[0035] A processor, configured to execute the computer program to implement the steps of the above test method.

[0036] An embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the above test method are implemented.

[0037] The present invention further provides a computer program product, including computer program / instructions, and when the computer program / instructions are executed by a processor, the steps of the above test method are implemented.

[0038] To solve the above technical problems, an embodiment of the present invention provides a test method, which may include: determining the firmware code of the disk redundant array to be tested and the test case to be executed, as well as the type of virtual environment corresponding to the test case to be executed; creating a virtual device based on the type of virtual environment; wherein, the virtual device is a device for driving the firmware code of the disk redundant array to be tested; testing the firmware code of the disk redundant array to be tested based on the virtual device and the test case to be executed.

[0039] As can be seen from the above technical solution, the beneficial effect of the present invention is that: compared with the current manual testing, the present invention can create a virtual device based on the type of virtual environment. Since the virtual device is a device for driving the firmware code of the disk redundant array to be tested, it is equivalent to that the virtual device and the firmware code of the disk redundant array to be tested can form a virtual redundant array card, so as to directly perform automated testing on the redundant array card based on the test case, thus improving the testing efficiency of the RAID card without physical objects. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] To more clearly illustrate the embodiments of the present invention, the following will briefly introduce the drawings required in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0041] Figure 1 It is a flowchart of a test method provided by an embodiment of the present invention;

[0042] Figure 2 It is a schematic diagram of communication between a continuous integration tool and a virtual environment device provided by an embodiment of the present invention;

[0043] Figure 3 It is a flow example diagram of a test method provided by an embodiment of the present invention;

[0044] Figure 4 It is an automated test system provided by an embodiment of the present invention;

[0045] Figure 5 It is a schematic diagram of testing by an automated management platform provided by an embodiment of the present invention;

[0046] Figure 6 It is a schematic diagram of querying status provided by an embodiment of the present invention;

[0047] Figure 7 It is a schematic diagram of process nodes of an automated test provided by an embodiment of the present invention;

[0048] Figure 8 It is a schematic diagram of the structural framework of a test device provided by an embodiment of the present invention;

[0049] Figure 9 This is a schematic structural framework diagram of a test device provided by an embodiment of the present invention. Detailed implementation manners

[0050] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present invention.

[0051] The terms "including" and "having" in the specification of the present invention and the above accompanying drawings, as well as any variations related to "including" and "having", are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but may include steps or units that are not listed.

[0052] During the description of the embodiments of the present invention, some nouns or terms are applicable to the following explanations:

[0053] RAID: Redundant Array of Independent Disks, an array with redundancy composed of independent disks, which combines many independent disks into a disk group with a huge capacity, and uses the additive effect generated by individual disks to provide data to improve the performance of the entire disk system. Using this technology, data is cut into many segments and stored on each hard disk respectively.

[0054] VP: The Virtual Prototyping environment usually refers to a virtual prototype or simulation environment used to test and verify the behavior and performance of the RAID system. The virtual prototype consists of an abstract software simulation model of the SoC and a hardware system. Developers can use an equivalent software model to replace the hardware, so as to carry out software development earlier.

[0055] Mosquitto: An open-source MQTT (Message Queuing Telemetry Transport) message broker, which is a "lightweight" communication protocol based on the publish / subscribe mode and is designed for low-bandwidth, high-latency or unreliable network environments.

[0056] In order to enable those skilled in the art of this technology to better understand the solution of the present invention, the present invention will be further described in detail below in conjunction with the accompanying drawings and specific implementation manners.

[0057] Next, a test method provided by an embodiment of the present invention will be introduced in detail. Figure 1 The flowchart of a test method provided by an embodiment of the present invention, the method may include:

[0058] S101, determine the firmware code of the disk redundant array to be tested, the test case to be executed, and the type of virtual environment corresponding to the test case to be executed.

[0059] The execution subject of this embodiment is an electronic device. The electronic device in this embodiment may be a computer, an automated management platform, etc. The firmware code of the disk redundant array to be tested in this embodiment is the code of the RAID card in the development stage. The test case to be executed in this embodiment is a test case for testing the disk redundant array to be tested. A test case is a set of test inputs, execution conditions, and expected results designed for a specific purpose, used to verify whether the software meets specific test objectives (such as functional requirements, performance requirements, etc.). It is the basic unit used to test whether the software meets the design requirements and user requirements in the software testing process. In RAID card development, the VP (Virtual Prototype) environment is a simulation platform that simulates the hardware behavior and interface protocol through software. The type of virtual environment in this embodiment can be divided based on the form of the disk. For example, there can be various forms such as 8 disks, 16 disks, 32 disks, etc. There can be other different VP types according to the test requirements of different projects. Or it can also be based on different versions; or based on the performance supported by the VP. Therefore, the VP type can have different operating systems, different numbers of cores, and VP devices that can simulate different numbers of hard disks in RAID card testing, etc.

[0060] It should be further noted that based on any of the above embodiments, in order to improve the efficiency of automated testing, the above determination of the firmware code of the disk redundant array to be tested, the test case to be executed, and the type of virtual environment corresponding to the test case to be executed may include:

[0061] S1: Obtain the test plan information sent by the continuous integration tool; wherein, the continuous integration tool is a tool that automatically generates test plan information based on the automatically updated firmware code of the disk redundant array.

[0062] The continuous integration tool in this embodiment is Jenkins. There can be multiple build tasks on Jenkins, and different tasks can be identified by different user names. It can be understood that since the virtual environment (VP environment) is a virtual test environment dynamically allocated and released by the host, the VP environment will be deleted after the test is completed or the test execution fails. Therefore, the VP environment is continuously allocated and released. However, the build tasks of Jenkins usually rely on static resource configurations and cannot configure the VP environment as a slave node like conventional operations. It is impossible to achieve automated testing by operating the VP node, and Jenkins lacks API interfaces or plugin support for direct integration with the VP environment. Therefore, we need to develop a custom solution to achieve the integration of VP and Jenkins. The present invention has developed a custom communication (for example, protocols such as Mosquitto, WebSockets, Redis Pub / Sub, AMQP, etc.) API interface for realizing communication between Jenkins and the VP environment, as follows Figure 2 shown Figure 2 is a schematic diagram of communication between a continuous integration tool and a virtual environment device provided by an embodiment of the present invention. From Figure 2 it can be seen that the main functions implemented by this interface are: using the Mosquitto communication protocol, sending test plan information such as the test user name, test case group, and VP environment version required for testing to the automated management platform, thereby connecting the communication from Jenkins to the automated management platform (the platform for testing based on test cases). After triggering an automated build from the Jenkins side, this interface will be called to send the test plan information to the automated management platform. The Mosquitto communication protocol between Jenkins and the automated management platform is as follows: An automated test request template (message packet):

[0063] Topic: "CaseRequest"

[0064] {

[0065] "user": "autotester", / / The user name for pulling up the VP

[0066] "devInfo": { / / Device type

[0067] "type": "VP", / / The device type is VP

[0068] "os": "****", / / VP type

[0069] "firmware": "****", / / Firmware version information

[0070] }

[0071] "testCaseInfo": [ / / Test case

[0072] {

[0073] "CaseNo": "caseNo1", / / Test case number

[0074] "CaseName": "*****1.py" / / Test case name

[0075] },

[0076] {

[0077] "CaseNo": "caseNo2",

[0078] "caseName": "*****2.py",

[0079] },

[0080] { ....

[0082] },

[0083] "CaseNo": "caseNoN",

[0084] "caseName": "*****N.py",

[0085] ,

[0086] “executeParams”:{

[0087] “timeout”:3600, / / Test case execution timeout

[0088] “failed_retry_times”:0 / / Retry times after test case execution fails

[0089] }

[0090] }

[0091] This message is sent to the automated management platform after the Jenkins platform triggers a build task. The message can include: autotester (the username for pulling up the VP), devinfo (device type, VP type, firmware version information), testCaseInfo (test case number and test name), executeParams (test case execution timeout, number of retries after test case execution failure), etc. The firmware version information is the version built from the development code (disk redundant array firmware code) to be tested, and the pulled-up VP device will include the firmware version.

[0092] S2: Parse the test plan information to obtain the disk redundant array firmware code to be tested, the test cases to be executed, and the virtual environment type corresponding to the test cases to be executed.

[0093] In this embodiment, the continuous integration tool can automatically generate test plan information based on the updated disk redundant array firmware code, so that the disk redundant array firmware code to be tested, the test cases to be executed, and the virtual environment type corresponding to the test cases to be executed can be obtained from the test plan information, thereby realizing the test. Since the test plan information can be automatically distributed, the efficiency of automatic testing can be improved.

[0094] It should be further noted that the above-mentioned obtaining the test plan information sent by the continuous integration tool can include: obtaining the test plan information sent by the continuous integration tool based on the interface of the Message Queuing Telemetry Transport protocol; wherein, the interface based on the Message Queuing Telemetry Transport protocol is used to integrate the continuous integration tool with the virtual device. The interface based on the Message Queuing Telemetry Transport protocol (Mosquitto) in this embodiment realizes message intercommunication between Jenkins and the automated management platform. Test cases and VP environment information (VP type) required for testing are sent to the automated management platform through the Jenkins platform for test case execution, and the automated management platform can return the test execution results to the Jenkins platform to realize the display of the interface. Mosquitto communication is a communication method between the client and the server. It is an open-source MQTT (Message Queuing Telemetry Transport) protocol proxy server, and its communication method is based on the publish / subscribe model of the client-server. This communication mode is widely used in the Internet of Things (IoT), edge computing, and distributed systems, and its core advantages are mainly reflected in low protocol overhead and low power consumption.

[0095] It should be further noted that in order to improve the accuracy of the test, after determining the disk redundant array firmware code to be tested, the test cases to be executed, and the virtual environment type corresponding to the test cases to be executed, the following may also be included:

[0096] Step 1: Update the test plan table in the database based on the disk redundant array firmware code to be tested; wherein, the test plan table is used to store the disk redundant array firmware codes for testing.

[0097] The test plan table in this embodiment is used to store the disk redundant array firmware codes for testing, so as to distinguish the tested disk redundant array firmware codes from the untested ones, thereby accurately testing the disk redundant array firmware code to be tested.

[0098] Step 2: Update the test case table in the database based on the test cases to be executed; wherein, the test case table is used to store the executed test cases and the test cases to be executed.

[0099] The test case table in this embodiment is used to accurately distinguish the test cases to be executed and prevent the reuse of the same test case to be executed.

[0100] Correspondingly, testing the disk redundant array firmware code to be tested based on the virtual device and the test cases to be executed may include:

[0101] Step 3: Determine all the test cases to be executed existing in the database and the corresponding virtual environment types for each test case to be executed.

[0102] In this embodiment, each test case to be executed is corresponded with the virtual environment type, so that based on the corresponding relationship, the required virtual device can be accurately generated for each test case to be executed.

[0103] Step 4: Determine whether there is an idle virtual device corresponding to the virtual environment type.

[0104] The reason for this embodiment to determine whether there is an idle virtual device corresponding to the virtual environment type is that in multiple tasks, after the previously created virtual device successfully executes the test task, it can be reused, and there is no need to recreate the virtual device at this time.

[0105] Step 5: When there is no corresponding idle virtual device, create the corresponding virtual device based on the virtual environment type corresponding to each test case to be executed.

[0106] In this embodiment, only the non-existing virtual devices will be created, and there is no need to recreate them when they exist.

[0107] Step 6: Test the disk redundant array firmware code to be tested based on all the test cases to be executed in the database and the corresponding virtual devices.

[0108] When Mosquitto communicates, in this embodiment, after receiving a Mosquitto message, it is parsed and written into the test plan table and test case table in the database. The status of the test cases can be continuously monitored. When it is found that a test case to be executed is written into the database, the scheduling process will be triggered to find the corresponding idle virtual device. After finding the test case and the corresponding virtual device, the subsequent automated testing work will be carried out. Therefore, this embodiment can accurately determine the test cases to be executed based on the test case table in the database, so as to accurately test the firmware code of the disk redundancy array to be tested.

[0109] S102, create a virtual device based on the virtual environment type; wherein, the virtual device is a device that drives the firmware code of the disk redundancy array to be tested.

[0110] In this embodiment, creating a virtual device based on the virtual environment type means pulling up the corresponding virtual device according to the virtual environment type required by the test case to be executed and the version of the firmware code of the disk redundancy array to be tested as required.

[0111] S103, test the firmware code of the disk redundancy array to be tested based on the virtual device and the test case to be executed.

[0112] In this embodiment, the virtual device and the firmware code of the disk redundancy array to be tested can be regarded as a "physical" disk redundancy array code, so as to test the "physical" disk redundancy array code based on the test case to be executed.

[0113] It should be further noted that, based on any of the above embodiments, in order to improve the test efficiency, the above-mentioned testing of the firmware code of the disk redundancy array to be tested based on the virtual device and the test case to be executed may include:

[0114] S1031, when there are a preset number of test cases to be executed, create a preset number of virtual devices based on the virtual environment type corresponding to each test case to be executed; wherein, the preset number is greater than 1.

[0115] This embodiment can create multiple virtual devices at the same time, improving the creation efficiency of the virtual devices.

[0116] S1032, based on the preset number of test cases to be executed and the preset number of virtual devices, simultaneously test the corresponding firmware code of the disk redundancy array to be tested.

[0117] This embodiment can simultaneously test the firmware codes of multiple disk redundancy arrays to be tested based on multiple virtual devices, so the test efficiency can be improved.

[0118] It should be further noted that, based on any of the above embodiments, when there are a preset number of test cases to be executed, creating a preset number of virtual devices based on the virtual environment type corresponding to each test case to be executed may include: using a virtual environment resource pool to create a preset number of virtual devices based on the virtual environment type corresponding to each test case to be executed. The embodiments of the present invention consider that a large number of test cases are issued simultaneously in automated testing. To achieve rapid testing, it is necessary to flexibly launch multiple VP devices to execute batch test cases. However, different test plans issued during the testing process may require different VP types and the firmware versions to be tested may also be different. This requires launching the corresponding VP devices according to the VP types and firmware versions required by the test cases. According to the RAID card test requirements, the VP types can have various forms such as 8-disk, 16-disk, 32-disk, etc., and there may be other different VP types according to the test requirements of different projects. The firmware version (the firmware code of the disk redundancy array to be tested) is the software code to be tested, and different new versions are built every day. Therefore, the firmware version needs to be continuously updated during testing. So, the VP to be launched needs to support creating VP devices with different firmware versions. To solve these problems, the embodiments of the present invention can use multiple servers to create a VP resource pool and design a VP automated scheduling process, which can create the corresponding VP devices according to the VP types and firmware versions required by the test cases. After a large number of test cases to be executed are issued, the resource pool can create multiple VP devices for simultaneous case testing, which greatly saves the testing time and can complete the testing work in a short time, and the testing efficiency is greatly improved.

[0119] It should be further noted that, based on any of the above embodiments, in order to improve the user experience, after creating a virtual environment based on the virtual environment type, testing the disk redundant array firmware code to be tested based on the virtual environment and the test cases to be executed, the following steps may further be included: returning the test results and the execution status of the test cases to a visualization display device for visualization display based on the visualization display device. It can be understood that this embodiment takes into account the need to monitor and return the test results of the test cases. In order to view the progress of the execution of the test cases in real time and ensure that the test status can be immediately feedback during the construction and deployment process, the specific method may be as follows: during the automated test process, the execution status of the test cases will be immediately updated in the database record, monitor and query the execution status of the test cases in the test plan based on a query script, and display the query status on the Jenkins interface. In addition, in order for developers and testers to quickly view the test results, the accurate path of the test log will be recorded in the query results, including the test log and the UART log (serial communication log) of the VP environment. The communication mechanism between the query script on Jenkins and the automated management platform may be Mosquitto communication. The query script can continuously monitor and periodically send query requests to query the execution status of the test cases in the test plan. After receiving the query message, the automated management platform will retrieve the execution status of the test cases to be queried from the database, and return the query results to Jenkins and display them on the interface.

[0120] It should be further noted that, in order to improve the performance of the disk redundant array, the above testing of the disk redundant array firmware code to be tested based on the virtual device and the test cases to be executed may include: determining a plurality of test cases to be executed corresponding to the disk redundant array firmware code to be tested; wherein, the configuration parameters of each test case to be executed are different; testing the disk redundant array firmware code to be tested based on each test case to be executed, generating a log file corresponding to each test case to be executed, and determining the advantages and disadvantages of the test cases corresponding to different configuration parameters under different performance scenarios according to the test results corresponding to different test cases in the log file, and selecting the optimal test case therefrom. And matching the optimal configuration parameter corresponding to the optimal test case, so as to configure the subsequent disk redundant array based on the optimal configuration parameter. The method based on the embodiment of the present invention can timely discover the disk redundant array that cannot reach the performance scenario, so that it can be discovered and modified early, thereby reducing the cost and time of the entire project.

[0121] A testing method provided by an embodiment of the present invention may include: S101, determining the firmware code of the disk redundant array to be tested, the test case to be executed, and the type of virtual environment corresponding to the test case to be executed; S102, creating a virtual device based on the type of virtual environment; wherein, the virtual device is a device that drives the firmware code of the disk redundant array to be tested; S103, testing the firmware code of the disk redundant array to be tested based on the virtual device and the test case to be executed. Compared with the current manual testing, the present invention can create a virtual device based on the type of virtual environment. Since the virtual device is a device that drives the firmware code of the disk redundant array to be tested, it is equivalent to that the virtual device and the firmware code of the disk redundant array to be tested can form a virtual disk redundant array card, so as to directly perform automated testing on the disk redundant array card (RAID card) based on the test case, thus improving the testing efficiency of the RAID card without physical objects.

[0122] In the early stage of the development of the RAID card, the lack of physical testing will bring many difficulties, including challenges in aspects such as function verification, performance evaluation, fault recovery, and debugging. To overcome these difficulties, the development team may need to rely on simulation tools, virtual environments, and early prototype designs, and make full use of the convenience of automated testing to improve the testing efficiency to ensure the quality and reliability of the final product. Based on solving this problem, an automated testing solution for the RAID card is proposed, which combines the VP virtual environment with Jenkins to realize the automatic operation of VP tests in the continuous integration / continuous delivery (CI / CD) process, and can flexibly select to launch different types and different firmware version VP environments, launch multiple VP virtual environments simultaneously according to the test needs to achieve mass testing, thereby improving the testing efficiency, and can monitor the test progress and status in real time and accurately record the test logs.

[0123] For the present invention to be more easily understood, please specifically refer to Figure 3 , Figure 3 which is a flow example diagram of a testing method provided by an embodiment of the present invention, and may specifically include:

[0124] S301, obtaining a target interface based on Mosquitto (message broker) communication; the target interface is used to send the test user name, test case group, and test plan information of the VP (virtual) environment required for the test to the automated management platform.

[0125] For ease of understanding, please refer to Figure 4 , Figure 4An automated test system provided by an embodiment of the present invention. For realizing the integration of VP and Jenkins, the automated test system can be designed into three parts. The first part is the DevOps development and operation integration platform (Jenkins), which is responsible for automated construction and providing visual display. In this article, it is the Jenkins platform. The second part is the test management platform (automated management platform), which includes modules such as test case management, test equipment management, test case and virtual device scheduling, and test process monitoring. The third part is the automated test framework, which runs on the environment to be tested to execute test cases, and docks with the automated management platform upward, responsible for the execution of specific test cases. Through such a three-layer structure, the automated test of the VP environment can be realized. On the Jenkins platform, the test cases can be automatically triggered to be sent for execution and the test results can be displayed. The automated system of the present invention integrates the processes of development, testing, release, and deployment, realizes the full automation of the development and testing process, requires no manual intervention, realizes high automation and efficient delivery, and greatly improves the R & D efficiency.

[0126] S302. Implement communication between Jenkins (continuous integration tool) and the automated management platform based on the target interface.

[0127] The automated management platform in this embodiment is used to implement the steps of the above test method.

[0128] S303. Jenkins automatically constructs test plan information and calls the target interface to send the test plan information to the automated management platform.

[0129] S304. When the automated management platform receives the trigger of automated construction from the Jenkins side, it calls the target interface to receive the test plan information, parses the test plan information, and obtains the firmware code of the disk redundant array to be tested and the test cases to be executed.

[0130] For easy understanding, please refer to Figure 5 , Figure 5 which is a schematic diagram of testing by an automated management platform provided by an embodiment of the present invention. As can be seen from Figure 5 , after a large number of test cases are sent down, the resource pool can create multiple VP environments to simultaneously test the test cases, which greatly saves the test time, can complete the test work in a short time, and the test efficiency is greatly improved. The scheduling performed by the automated management platform is as follows: monitor and query the test cases to be executed, query whether there are VP devices of the required type and firmware version in the device table of the virtual device, and based on the corresponding VP devices queried, call the automated test framework to execute the test cases. When not queried, create VP devices based on the device creation message.

[0131] S305, the automated management platform writes the parsed disk redundant array firmware code to be tested and test cases into the test plan table and test case table in the database respectively.

[0132] S306, the automated management platform monitors the status of test cases in the test case table. When it finds that a to-be-executed test case is written into the database, it will trigger a scheduling process to find the corresponding idle virtual device.

[0133] S307, the automated management platform uses the virtual resource pool created by multiple servers to create corresponding virtual devices according to the virtual environment type required by the to-be-executed test case and the version of the disk redundant array firmware code to be tested.

[0134] S308, the automated management platform uses an automated test framework to perform automated testing based on the disk redundant array firmware code to be tested corresponding to the to-be-executed test case and the corresponding virtual device, and obtains test results.

[0135] S309, the automated management platform updates the execution status of each test case to the database.

[0136] S310, the query script on the Jenkins side will monitor and query the execution status of test cases in the test plan, and record the path of the test log in the query result.

[0137] Please refer to Figure 6 , Figure 6 which is a schematic diagram of querying status provided by an embodiment of the present invention. As can be seen from Figure 6 , the automated result monitoring and query module on the Jenkins side is used to send a query to the status of all test cases in the test plan. The status of the test cases includes executed and to-be-executed; the automated management platform is used to determine the test case status by reading the test plan table and test case table in the database based on a query command (instruction). At this time, the automated result monitoring and query module visually displays the query result returned by the automated management platform.

[0138] For easy understanding, please refer to Figure 7 , Figure 7A schematic diagram of the process nodes for automated testing provided by an embodiment of the present invention may include: Step 1: After Jenkins triggers a build, it will call the target API interface to send down the test plan information, and send the test plan information including test cases and virtual environment information to the automated management platform through the target API interface; the target API interface communicates based on the Mosquitto method. Step 2: The automated management platform receives the test plan information and parses it into the test case table and test plan table in the database. Step 3: After the test cases are written into the database, the test case scheduling script will monitor the test cases to be executed and find the corresponding VP devices required for the test cases to be executed. Step 4: After the test cases and VP devices are matched, the automated test framework will be called to execute the case test. If there is no VP device, a VP device needs to be created. When the test based on the VP device fails, the VP device needs to be deleted. Step 5: After the test cases are executed, the test results, test case status, and VP device information will be updated to the database. Step 6: After testing based on the test cases and VP devices, it will continue to monitor the test cases to be executed and the idle VP devices. Step 7: During the test, the test plan query script will continuously monitor the test execution progress and provide real-time feedback on the case execution progress and status. Step 8: Return the test results. Step 9: Write the test results into the database, which can generate an accurate log path for testers to view the test case execution results after the test is completed; Step 10: Query the test case execution progress and status.

[0139] The beneficial effects of the embodiments of the present invention may include:

[0140] (1) Combining the continuous integration function of Jenkins with the VP environment to create an automated pipeline that can automatically generate and update the VP virtual platform during each build, reducing manual intervention. (2) Support for creating multiple VP environments simultaneously, dynamically allocating different types and versions of VP environment resources according to test requirements for simultaneous testing of multiple test cases, improving test efficiency. (3) Through Jenkins, real-time monitoring and feedback of the VP test environment are achieved, automatically collecting VP test results, generating test reports, promptly discovering and solving potential problems, helping developers quickly locate problems, and shortening the development cycle.

[0141] The test device provided by the embodiments of the present invention will be introduced below. The test device described below can be correspondingly referred to the test method described above.

[0142] Figure 8 A schematic diagram of the structural framework of a test device provided by an embodiment of the present invention may include:

[0143] A virtual environment type determination module 100 is configured to determine a disk redundant array firmware code to be tested, a test case to be executed, and a virtual environment type corresponding to the test case to be executed;

[0144] A virtual device creation module 200 is configured to create a virtual device based on the virtual environment type; wherein, the virtual device is a device for driving the disk redundant array firmware code to be tested;

[0145] A test module 300 is configured to test the disk redundant array firmware code to be tested based on the virtual device and the test case to be executed.

[0146] Further, based on any of the above embodiments, the virtual environment type determination module 100 may include:

[0147] A test plan information generation unit is configured to obtain test plan information sent by a continuous integration tool; wherein, the continuous integration tool is a tool for automatically generating test plan information based on an automatically updated disk redundant array firmware code;

[0148] An analysis unit is configured to analyze the test plan information to obtain the disk redundant array firmware code to be tested, the test case to be executed, and the virtual environment type corresponding to the test case to be executed.

[0149] Further, based on any of the above embodiments, the above test plan information generation unit may include:

[0150] A test plan information acquisition subunit is configured to obtain the test plan information sent by the continuous integration tool based on an interface of the Message Queuing Telemetry Transport protocol; wherein, the interface based on the Message Queuing Telemetry Transport protocol is used for integrating the continuous integration tool with the virtual device.

[0151] Further, based on any of the above embodiments, the above test device may further include:

[0152] A test plan table update module is configured to update a test plan table in a database based on the disk redundant array firmware code to be tested; wherein, the test plan table is used to store disk redundant array firmware codes for testing;

[0153] A test case table update module is configured to update a test case table in the database based on the test case to be executed; wherein, the test case table is used to store executed test cases and test cases to be executed;

[0154] Correspondingly, the test module 300 may include:

[0155] A virtual environment type determination unit for determining all test cases to be executed existing in the database and the virtual environment type corresponding to each test case to be executed;

[0156] A virtual device determination unit for determining whether there is an idle virtual device corresponding to the virtual environment type;

[0157] A virtual device creation unit for creating corresponding virtual devices based on the virtual environment type corresponding to each test case to be executed when there is no corresponding idle virtual device;

[0158] A test unit for testing the firmware code of the disk redundant array to be tested based on all the test cases to be executed in the database and the corresponding virtual devices.

[0159] Further, based on any of the above embodiments, the test module 300 may include:

[0160] A virtual device creation unit for creating a preset number of virtual devices based on the virtual environment type corresponding to each test case to be executed when there is a preset number of test cases to be executed; wherein, the preset number is greater than 1;

[0161] A simultaneous test unit for simultaneously testing the firmware code of the disk redundant array to be tested based on the preset number of test cases to be executed and the preset number of virtual devices.

[0162] Further, based on the above embodiments, the virtual device creation unit may include:

[0163] A virtual device creation unit based on a resource pool for creating the preset number of virtual devices by using a virtual environment resource pool based on the virtual environment type corresponding to each test case to be executed.

[0164] Further, based on any of the above embodiments, the above test device may further include:

[0165] A visualization display module for returning the test results and the execution status of the test cases to a visualization display device for visualization display based on the visualization display device.

[0166] It should be noted that the order of the modules and units in the above test device can be changed before and after without affecting the logic.

[0167] Figure 8 For the description of the features in the corresponding embodiments, reference may be made to Figure 8 the relevant descriptions of the corresponding embodiments, which will not be elaborated here one by one.

[0168] A test device provided by an embodiment of the present invention may include: a virtual environment type determination module 100, configured to determine a disk redundant array firmware code to be tested and a test case to be executed, and a virtual environment type corresponding to the test case to be executed; a virtual device creation module 200, configured to create a virtual device based on the virtual environment type; wherein the virtual device is a device for driving the disk redundant array firmware code to be tested; a test module 300, configured to test the disk redundant array firmware code to be tested based on the virtual device and the test case to be executed. Compared with the current manual testing, the present invention can create a virtual device based on the virtual environment type. Since the virtual device is a device for driving the redundant array code to be tested, it is equivalent that the virtual device and the redundant array code to be tested can form a virtual redundant array card, so as to directly perform automated testing on the redundant array card based on the test case, and thus the testing efficiency of the RAID card without physical objects can be improved.

[0169] A test device provided by an embodiment of the present invention will be introduced below. The test device described below can be correspondingly referred to the test method described above.

[0170] Figure 9 It is a schematic structural framework diagram of a test device provided by an embodiment of the present invention, as Figure 9 shown, the test device includes: a memory 60, configured to store a computer program;

[0171] a processor 61, configured to implement the steps of the test method in the above embodiment when executing the computer program.

[0172] The test device provided in this embodiment may include, but is not limited to, a smart phone, a tablet computer, a laptop computer, or a desktop computer, etc.

[0173] Among them, the processor 61 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 61 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the wake state, also known as the central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 61 may be integrated with a graphics processing unit (GPU), and the GPU is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 61 may further include an artificial intelligence (AI) processor, and the AI processor is used to process computational operations related to machine learning.

[0174] The memory 60 may include one or more computer-readable storage media, and the computer-readable storage media may be non-transitory. The memory 60 may further include high-speed random access memory and non-volatile memory, such as one or more disk storage devices and flash storage devices. In this embodiment, the memory 60 is at least used to store the following computer program 601. After the computer program is loaded and executed by the processor 61, it can implement the relevant steps of the test method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may further include an operating system 602 and data 603, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 602 may include Windows, Unix, Linux, etc. The data 603 may include, but is not limited to, data required for the test method.

[0175] In some embodiments, the test device may further include a display screen 62, an input / output interface 63, a communication interface 64, a power supply 65, and a communication bus 66.

[0176] Those skilled in the art can understand that Figure 9 the structure shown in

[0177] It can be understood that if the test method in the above embodiments is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the current technology, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memories (ROM), random access memories (RAM), electrically erasable programmable ROMs, registers, hard disks, removable disks, CD-ROMs, magnetic disks, or optical discs.

[0178] Based on this, the embodiments of the present invention further provide a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the test method as described above.

[0179] The above has introduced in detail a test method provided by the embodiments of the present invention. The various embodiments in the specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The same or similar parts among the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method part.

[0180] Those skilled in the art can further realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed in this article can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0181] The above has introduced in detail a test method, device, equipment, and computer-readable storage medium provided by the present invention. Specific examples are used in this article to elaborate on the principles and implementation manners of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention. It should be noted that for those of ordinary skill in the art in this technical field, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the protection scope of the claims of the present invention.

Claims

1. A testing method, characterized in that: include: Determining the redundant array of disks firmware code to be tested and the test cases to be executed, and the virtual environment type corresponding to the test cases to be executed; Creating a virtual device based on the virtual environment type; wherein the virtual device is a device that drives the firmware code of the redundant array of disks to be tested; The redundant array of disks firmware code to be tested is tested based on the virtual device and the test case to be executed.

2. The testing method according to claim 1, characterized in that: Determining the redundant array of disks firmware code to be tested and the test case to be executed, and the virtual environment type corresponding to the test case to be executed, including: Acquire test plan information sent by a continuous integration tool; wherein the continuous integration tool is a tool for automatically generating test plan information based on automatically updated redundant array of disks firmware code; The test plan information is parsed to obtain the redundant array of disks firmware code to be tested and the test case to be executed, as well as the virtual environment type corresponding to the test case to be executed.

3. The testing method according to claim 2, characterized in that: Get the test plan information sent by the continuous integration tool, including: The test plan information is obtained by using an interface of the continuous integration tool based on a message queue telemetry transmission protocol, wherein the interface based on a message queue telemetry transmission protocol is used to integrate the continuous integration tool with the virtual device.

4. The testing method according to claim 1, characterized in that: After determining the redundant array of disks firmware code to be tested and the test case to be executed, and the virtual environment type corresponding to the test case to be executed, the method further includes: Based on the redundant array of disks firmware code to be tested, the test schedule in the database is updated; wherein the test schedule is used to store the redundant array of disks firmware code to be tested; Based on the test cases to be executed, the test case table in the database is updated; wherein the test case table is used to store executed test cases and test cases to be executed; Accordingly, testing the redundant array of disks firmware code to be tested based on the virtual device and the test case to be executed includes: Determine all the test cases to be executed in the database, and the virtual environment type corresponding to each test case to be executed; Determining whether there is an idle virtual device corresponding to the virtual environment type; When there is no corresponding idle virtual device, create a corresponding virtual device based on the virtual environment type corresponding to each test case to be executed; The redundant array of disks firmware code to be tested is tested based on all the test cases to be executed and the corresponding virtual devices in the database.

5. The testing method according to any one of claims 1 to 4, characterized in that: Testing the redundant array of disks firmware code to be tested based on the virtual device and the test case to be executed includes: When there are a preset number of test cases to be executed, creating a preset number of virtual devices based on the virtual environment type corresponding to each test case to be executed; wherein the preset number is greater than 1; Based on the preset number of test cases to be executed and the preset number of virtual devices, the corresponding redundant array of disks firmware codes to be tested are tested simultaneously.

6. The testing method according to claim 5, characterized in that: When there are a preset number of test cases to be executed, a preset number of virtual devices are created based on the virtual environment type corresponding to each test case to be executed, including: The virtual environment resource pool is utilized to create the preset number of virtual devices based on the virtual environment type corresponding to each test case to be executed.

7. The testing method according to claim 1, characterized in that: After creating a virtual environment based on the virtual environment type and testing the redundant array of disks firmware code to be tested based on the virtual environment and the test case to be executed, the method further includes: The test results and the test case execution status are returned to the visualization display device for visualization display based on the visualization display device.

8. A testing device, characterized in that: include: A virtual environment type determination module, used to determine the redundant array of disks firmware code to be tested and the test case to be executed, and the virtual environment type corresponding to the test case to be executed; A virtual device creation module, used to create a virtual device based on the virtual environment type; wherein the virtual device is a device that drives the firmware code of the redundant array of disks to be tested; A testing module is used to test the redundant array of disks firmware code to be tested based on the virtual device and the test case to be executed.

9. A testing device, characterized in that: include: Memory for storing computer programs; A processor, configured to execute the computer program to implement the steps of the testing method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the testing method according to any one of claims 1 to 7 are implemented.

Images