A method, device and medium for automatically testing a raid card

Abstract

This invention discloses an automated testing method, device, and medium for RAID cards, relating to the field of RAID testing technology. The method includes: responding to a received test task, performing at least one configuration operation on the RAID card in the device under test, wherein the configuration operation changes the hardware configuration state of the RAID card, and during the execution of the configuration operation, pushing the corresponding inverse operation and its parameters onto the inverse operation stack; performing a stress test on the RAID card after the configuration operation is executed, and obtaining the test result; determining whether the test result is a pass; if the test result is a pass, popping the inverse operation from the inverse operation stack in a last-in-first-out order and executing it to restore the RAID card's hardware configuration to its state before the configuration operation; if the test result is a failure, retaining the current hardware configuration state of the RAID card and the test environment, thereby simultaneously addressing the needs of efficient environmental recovery for batch automated testing and the need for integrity protection of the fault environment in abnormal scenarios.

Description

Technical Field

[0001] This invention relates to the field of RAID testing technology, and in particular to an automated testing method, equipment and medium for RAID cards. Background Technology

[0002] In existing technologies, within the field of server hardware testing, RAID cards, as core components connecting the motherboard and storage hard drives, require rigorous hardware integrity verification to ensure data storage reliability. A typical RAID card testing process involves a series of operations that alter the hardware configuration, such as creating different RAID level volumes, writing partition tables, formatting file systems, and mounting and writing test data to verify the RAID card's functionality and stability under various scenarios. These operations inevitably change the metadata in the RAID card firmware, the hard drive partition tables, and the data content on the storage media, causing the test environment to change from an initially clean state to a contaminated one.

[0003] Furthermore, in actual testing, especially in scenarios involving multiple rounds of repeated verification or anomaly injection testing of the same batch of RAID cards, the problem of test environment contamination becomes particularly prominent. After each test, residual RAID configuration information, metadata, and written test files directly affect the initialization process of the next round of testing, potentially causing subsequent test cases to fail to correctly identify the initial hardware state, or even leading to configuration conflicts or misjudgments, severely hindering the continuity and repeatability of testing.

[0004] Currently, most existing processing methods rely on manual intervention by testers, who manually execute command-line tools or reset operations to clean up these residual data one by one. However, manual cleaning is not only inefficient and time-consuming, but also prone to incomplete cleaning or accidental deletion of useful information due to operational errors, which cannot meet the requirements of rapid and clean environment restoration for batch automated testing. Furthermore, some automated testing solutions attempt to use a crude global reset method for recovery after the test, but this method cannot distinguish between the normal environmental recovery requirements after the test passes and the need to preserve the fault scene for in-depth analysis after the test fails. Often, once the test fails, critical fault scene data is also erased, losing the opportunity to reproduce and locate the problem. Summary of the Invention

[0005] This invention provides an automated testing method, device, and medium for RAID cards, aiming to solve the technical problem of providing an effective solution for achieving accurate restoration of the test environment and intelligent protection of the fault scene in automated testing of RAID cards.

[0006] In a first aspect, the present invention provides an automated testing method for RAID cards, comprising: In response to a received test task, at least one configuration operation is performed on the RAID card in the device under test, wherein the configuration operation changes the hardware configuration state of the RAID card, and when the configuration operation is performed, the inverse operation corresponding to the configuration operation and the parameters of the inverse operation are pushed onto the inverse operation stack. Perform a stress test on the RAID card after executing the configuration operation, and obtain the test results; Determine whether the test result is passed; If the test result is passed, the reverse operation is popped from the reverse operation stack in the last-in-first-out order and executed to restore the hardware configuration of the RAID card to the state before the configuration operation was executed; If the test result is a failure, the current hardware configuration status of the RAID card and the test environment will be retained.

[0007] Optionally, before performing at least one configuration operation on the RAID card in the device under test, the method further includes: The hardware integrity of the RAID card is verified, and the hardware integrity verification result is obtained. Determine whether the hardware integrity verification result is passed; If the hardware integrity verification result is passed, then the configuration operation is executed; If the hardware integrity verification result is a failure, the device under test will be marked as having a hardware abnormal state, and the hardware integrity verification failure information will be reported.

[0008] Optionally, the hardware integrity verification of the RAID card includes a hard drive connectivity check, which includes: Perform an in-band scan to obtain the first information of the physical disk connected to the RAID card; The second information of the physical disk connected to the RAID card is obtained through the out-of-band interface of the baseboard management controller; Cross-compare the first information with the second information; If the first information matches the second information, then the connectivity is determined to be normal; If the first information does not match the second information, then the connectivity is determined to be abnormal.

[0009] Optionally, the configuration operation includes: Obtain the number of physical disks connected to the RAID card; The RAID level is automatically selected and a RAID volume is created based on the quantity. If the quantity is greater than or equal to 3, a RAID 5 volume is created; if the quantity is equal to 2, a RAID 1 volume is created; and if the quantity is equal to 1, a RAID 0 volume is created. The reverse operation of deleting the RAID volume and the identifier of the RAID volume are pushed onto the reverse operation stack as parameters.

[0010] Optionally, the stress test performed on the RAID card after the configuration operation includes: The pre-boot execution environment PXE network boot is configured through the baseboard management controller, enabling the device under test to boot into a diskless test environment in the memory file system; In the diskless test environment, the fio tool is used to directly perform random read and write operations on the RAID volume created by the configuration operation to generate test data that is written to the physical disk; During the random read / write operation, an exception injection operation is performed, which includes simulating a hard disk hot-plug operation or simulating a power failure operation, and the inverse operation corresponding to the exception injection operation is pushed onto the inverse operation stack.

[0011] Optionally, popping the inverse operation from the inverse operation stack and executing it in a last-in-first-out (LIFO) order includes: Pop the current inverse operation from the inverse operation stack and execute it; If the current inverse operation is executed successfully, the next inverse operation will be popped and executed until the inverse operation stack is empty. If the current inverse operation fails, the failed step is recorded and the remaining inverse operations are stopped, and an environment recovery anomaly is reported.

[0012] Optionally, after obtaining the test results, the following may also be included: The configuration information, event logs, system logs, and test execution results of the RAID card are collected and uploaded to the production test data collection and statistical analysis platform. If the test result is a failure, the device under test will be marked as awaiting manual analysis, and the test result and fault log will be uploaded to the production test data collection and statistical analysis platform.

[0013] Optionally, the method is executed by a baseboard management controller, which simultaneously sends instructions to multiple devices under test via the IPMI protocol or the Redfish protocol to execute the RAID card automated testing method in parallel on each of the devices under test.

[0014] Secondly, the present invention also provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0015] Thirdly, the present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0016] This invention provides an automated testing method, device, and medium for RAID cards. The method includes: responding to a received test task, performing at least one configuration operation on the RAID card in the device under test, wherein the configuration operation changes the hardware configuration state of the RAID card, and during the execution of the configuration operation, pushing the corresponding inverse operation and its parameters onto an inverse operation stack; performing a stress test on the RAID card after the configuration operation is executed, and obtaining a test result; determining whether the test result is a pass; if the test result is a pass, popping the inverse operation from the inverse operation stack in a last-in-first-out (LIFO) order and executing it to restore the hardware configuration of the RAID card to its state before the configuration operation was executed; if the test result is a failure, retaining the current hardware configuration state of the RAID card and the test environment. This invention constructs a traceable configuration change record chain by dynamically pushing the inverse operation and its parameters corresponding to each configuration operation onto the inverse operation stack during the test configuration phase. After the stress test, differentiated processing is performed based on the test results. If the test passes, the RAID card is popped from the reverse operation stack in a last-in-first-out order and the reverse operation is executed, automatically rolling back all configuration changes. This accurately restores the RAID card's hardware configuration to its initial state before the test, eliminating the need for manual cleanup of residual RAID volumes, partition tables, and metadata, and ensuring the continuity and repeatability of multiple rounds of testing. If the test fails, the rollback operation is skipped, and the current RAID configuration, firmware logs, and system runtime environment are fully preserved. This retains first-hand data for fault analysis and avoids the drawback of traditional reset solutions that erase fault evidence when the test fails. Thus, it simultaneously addresses the need for efficient environment recovery in batch automated testing and the need for integrity protection of the fault scene in abnormal scenarios. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1A flowchart illustrating an automated testing method for a RAID card provided in an embodiment of the present invention; Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0021] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0022] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if [the described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [the described condition or event] is detected," or "in response to detection of [the described condition or event]."

[0024] Please see Figure 1 This invention provides an automated testing method for RAID cards. Based on the inverse operation stack mechanism, it achieves accurate restoration of the automated testing environment and intelligent protection of the fault scene for RAID cards. This solves the problems of low efficiency and inability to preserve the fault scene caused by relying on manual cleaning or rough reset in existing testing solutions. Specifically, the method includes the following steps: S1, in response to the received test task, perform at least one configuration operation on the RAID card in the device under test, wherein the configuration operation changes the hardware configuration state of the RAID card, and when performing the configuration operation, push the inverse operation corresponding to the configuration operation and the parameters of the inverse operation onto the inverse operation stack.

[0025] In practice, in response to a received test task, at least one configuration operation is performed on the RAID card in the device under test (DUT). This configuration operation changes the hardware configuration state of the RAID card. During the execution of the configuration operation, the corresponding inverse operation and its parameters are pushed onto the inverse operation stack. The production test execution platform, as the central control node of the test process, is responsible for managing test task templates and test cases. After configuring the required parameters for this test on the platform, engineers distribute the automated task to the BMC via the test scheduler. BMC stands for Baseboard Management Controller, a management chip that operates independently of the server's main processor. It can remotely perform operations such as power-on / off, firmware upgrades, and hardware diagnostics on the server via a network. After receiving the task, the BMC sends instructions to the DUT via the IPMI or Redfish protocol to perform a power-on operation. IPMI stands for Intelligent Platform Management Interface, a standardized out-of-band server management protocol.

[0026] Furthermore, after the device under test (DUT) powers on, the automated test script begins executing configuration operations. These configuration operations refer to any operation that changes the hardware configuration state of the RAID card or hard drive, such as creating a RAID volume, writing to a partition table, formatting a file system, or mounting and writing a test file. While the script executes each configuration operation, the system automatically calculates and generates the corresponding inverse operation, pushing the inverse operation and its required parameters as a record entry onto the top of the inverse operation stack. The inverse operation is an operation that completely undoes the state change caused by the corresponding configuration operation. For example, the inverse operation of creating a RAID volume is to delete the RAID volume; the inverse operation of writing to a partition table is to clear the partition table signature; the inverse operation of formatting a file system is to clear the file system's superblock and node table; and the inverse operation of writing a test file is to unmount the mount point and delete the test file path.

[0027] Furthermore, the inverse operation stack is a stack data structure with a last-in-first-out (LIFO) access order, where the inverse operation corresponding to the later-executed operation is popped and executed first. The stack can be stored in the memory of the device under test or in a temporary file to ensure its persistence after the operating system restarts or power failures.

[0028] In some preferred embodiments, before performing at least one configuration operation on the RAID card in the device under test, the method further includes: performing hardware integrity verification on the RAID card to obtain a hardware integrity verification result; determining whether the hardware integrity verification result is passed; if the hardware integrity verification result is passed, then performing the configuration operation; if the hardware integrity verification result is failed, then marking the device under test as having a hardware abnormal state and reporting hardware integrity verification failure information.

[0029] In practice, before performing at least one configuration operation on the RAID card in the device under test, a hardware integrity verification is performed on the RAID card to obtain the hardware integrity verification result. The purpose of hardware integrity verification is to confirm whether the PCIe connection between the RAID card and the motherboard is intact and whether the firmware on the card can be correctly recognized and initialized by the system before performing any operation that would change the configuration state of the RAID card. It should be noted that PCIe is an abbreviation for Peripheral Component Interconnect Express, which is the standard bus interface in servers that connects high-speed peripherals such as RAID cards to the main processor. The hardware integrity verification includes the following aspects.

[0030] First, there's the RAID card device identification check. The automated test script executes the `lspci -d` command, where the `-d` parameter is followed by the Vendor ID (VID) and Device ID (DID), pre-configured by engineers on the production test platform. VID is a unique number assigned to each hardware manufacturer by the PCI Special Interest Group (SPIC). DID is a unique number assigned by the manufacturer to its specific product model. If the command returns a non-empty result, it indicates that the system device tree has successfully enumerated a RAID card device matching the expected VID and DID, and the identification is considered normal. If it returns an empty result, it indicates that the system failed to detect the expected RAID card model. Possible reasons include the card not being correctly inserted into the slot, a hardware failure preventing power-on initialization, or incorrect components on the card causing a mismatch between the VID or DID and the expected value; in this case, the identification is considered abnormal.

[0031] Further, the PCIe link negotiation status is checked. The script executes the `lspci -s` command, where the `-s` parameter is followed by the RAID card's bus number, device number, and function number, i.e., BDF information. BDF is an abbreviation for Bus / Device / Function, a combination of bus number, device number, and function number used to uniquely address a device function in the PCIe bus topology. The `LnkSta` field, representing the current link negotiation status, is extracted from the command output. It checks whether the current negotiation rate and link bandwidth meet the expected specifications, such as PCIe 3.0 x8 or PCIe 4.0 x8. Simultaneously, the `LnkCap` field, representing the maximum supported capacity of the link, is extracted to obtain the physical upper limit of the card and slot. If `LnkSta` meets the expected specifications, the link status is considered normal. If `LnkSta` does not meet the expected specifications, but `LnkCap` shows that the maximum supported capacity of the device or slot is higher than the current negotiation result, the link is considered degraded. Possible causes include insufficient PCIe signal integrity, oxidation or physical damage to the slot or gold fingers causing unstable high-speed signal negotiation, and poor connector contact. If LnkSta displays a link status of not negotiated at all or consistently at the lowest rate, it is considered a link anomaly.

[0032] Further, the script checks for RAID card power-on self-test (POST) anomalies. The script accesses the BMC's system event log, SEL. SEL is a storage area where the BMC records various events and alarms that occur during server hardware operation. The script filters and searches the SEL log using keywords such as RAID, PCIe, error, and fail. If a power-on failure alarm or link error event related to the RAID card is found, it is considered a power-on anomaly. Simultaneously, the script checks the device under test's power-on self-test (POST) process. POST is an initialization test performed by the server firmware after power-on. The script obtains the POST process output information through serial port redirection or the BMC console log, checking for reports of RAID card initialization failures or RAID optional read-only memory (RAID ROM) checksum errors.

[0033] Furthermore, hardware integrity verification also includes a hard drive connectivity check, which is performed after the aforementioned device identification check, link negotiation check, and power-on self-test check. The specific implementation of the hard drive connectivity check will be described in detail in Example 3; here, it is only explained as a component of hardware integrity verification. It involves acquiring first information about the physical disk through in-band scanning and second information about the physical disk through the BMC out-of-band interface, and cross-referencing the two sets of information to verify whether the communication link between the RAID card and the physical disk is complete and unobstructed. After the hard drive connectivity check is completed, a result indicating normal or abnormal connectivity is generated.

[0034] Furthermore, by combining the results of all the above checks, an overall hardware integrity verification result is generated. The hardware integrity verification result is considered passed only if the device identification check, link negotiation check, power-on self-test check, and hard disk connectivity check are all deemed normal; otherwise, the result is considered a failure.

[0035] Further, determine whether the hardware integrity verification result is passed. The automated test script obtains the hardware integrity verification result generated in the previous step and checks whether its value indicates a pass status where all checks are normal or a failure status where at least one check has an anomaly.

[0036] Furthermore, if the hardware integrity verification result is passed, the configuration operation is executed. When the hardware integrity verification is passed, it indicates that the RAID card has no abnormalities in device identification, link negotiation, power-on self-test, and hard drive connectivity, and has all the physical foundation and firmware operating conditions to receive configuration operation commands. At this time, the test process continues to advance, entering the configuration operation and subsequent stress test stages described in the above embodiments. Since hardware integrity is the physical prerequisite for performing all upper-layer functional tests, only the device under test that passes this verification will be allowed to enter the subsequent test process, thereby filtering out devices under test with potential basic hardware vulnerabilities at the source of the test link.

[0037] Furthermore, if the hardware integrity verification fails, the device under test is marked as being in a hardware abnormal state, and a hardware integrity verification failure message is reported. When hardware integrity verification fails, it indicates that the RAID card has a physical defect in at least one aspect: device identification, link negotiation, power-on self-test, or hard drive connectivity. Continuing to perform configuration operations and stress tests at this time is meaningless and may even generate a large amount of noisy data that interferes with subsequent analysis due to the unstable underlying hardware, or even cause secondary damage due to repeated operations on the faulty hardware. The system marks the device under test as being in a hardware abnormal state, generates a verification failure report containing specific abnormality checks and details, and removes the device from the current test queue. The verification failure message is reported to the production test execution platform, reminding maintenance personnel to perform hardware troubleshooting, such as reseating the RAID card to rule out poor contact, replacing suspicious signal cables, or replacing the faulty card.

[0038] This embodiment adds a systematic hardware integrity verification step before the configuration operation phase, covering four aspects: PCIe device identification and detection, comparison verification of link negotiation rate and maximum capacity, SEL log and POST process power-on self-test anomaly checks, and hard drive connectivity checks. This constitutes a complete pre-check system for the RAID card's physical connection from the motherboard to the back-end hard drive communication link. The gating mechanism, which only opens the configuration operation entry point after all checks have passed verification, effectively avoids invalid testing and misjudgments caused by directly entering the RAID configuration and stress testing phase in cases of hardware connection abnormalities, insufficient signal quality, device initialization failure, or storage link interruption. Furthermore, when verification fails, the test process is terminated promptly, and detailed failure information including specific abnormal checks is reported, ensuring that test resources are not wasted on devices under test with physical layer defects, thus optimizing the overall test pipeline throughput efficiency. This verification strategy, which decouples hardware layer connection checks from upper-layer functional tests, significantly improves the accuracy of problem localization, allowing for a clear distinction between hardware and software faults.

[0039] In some preferred embodiments, the hardware integrity verification of the RAID card includes a hard disk connectivity check, which includes: performing an in-band scan to obtain first information about the physical disk connected to the RAID card; obtaining second information about the physical disk connected to the RAID card through the out-of-band interface of the baseboard management controller; cross-comparing the first information with the second information; if the first information matches the second information, the connectivity is determined to be normal; if the first information does not match the second information, the connectivity is determined to be abnormal.

[0040] In this implementation, the hard drive connectivity check is detailed in this example. This example addresses the problem that traditional RAID card connectivity checks only verify connectivity from a single perspective, failing to detect unidirectional connectivity illusions caused by backplane link, SAS extender, or management channel failures. It should be noted that SAS is an abbreviation for Serial Attached SCSI, a common high-speed serial bus standard used in servers to connect RAID cards and hard drives. The specific implementation method is as follows.

[0041] The hard drive connectivity check first includes performing an in-band scan to obtain the first information of the physical disks connected to the RAID card. The in-band scan refers to directly accessing the RAID card firmware interface through the device driver and command-line tools within the operating system after the operating system or test kernel of the device under test has started, to obtain the list of physical disks currently managed by the RAID card. Taking Broadcom or Microchip series RAID cards as an example, a dedicated command-line management tool provided by the RAID card manufacturer, such as Storcli or Perccli, is used to execute the physical disk scan command. The tool establishes an in-band communication channel through the RAID card device driver in the operating system kernel and sends a physical disk query request to the RAID card firmware. After receiving the request, the RAID card firmware issues SCSI query commands to each physical disk through the SAS link between itself and the hard drive backplane. SCSI stands for Small Computer System Interface, which collects information such as the model, serial number, firmware version, capacity, and current operating status of each physical disk, and returns the query results to the management tool. Further, the management tool parses the returned data and summarizes it into the first information. The first information reflects the communication status of the complete in-band path from the operating system's main processor through the RAID card to the physical disks.

[0042] Furthermore, the hard drive connectivity check secondly includes obtaining second information about the physical disks connected to the RAID card through the out-of-band interface of the baseboard management controller (BMC). The out-of-band interface refers to the mechanism by which the BMC obtains hardware information through a management channel independent of the main processor and operating system. When the hardware platform of the device under test supports direct communication between the BMC and the RAID card via I2C or SMBus, or when the BMC itself integrates SAS extender management functions and can directly access the management interface of the hard drive backplane, the BMC can initiate query requests to the RAID card or hard drive backplane through these out-of-band channels. I2C is an abbreviation for Inter-Integrated Circuit, a low-speed serial communication bus within the board. SMBus is an abbreviation for System Management Bus, a communication bus standard derived from I2C for system management. After obtaining the hard drive information, the BMC performs protocol parsing and data formatting to form second information with a comparable structure to the first information. The second information reflects the communication status of the out-of-band path from the BMC to the RAID card or hard drive backplane through an independent management channel. Since out-of-band paths and in-band paths are independent of each other in terms of physical wiring and communication protocols, there is no mutual interference between them.

[0043] Furthermore, the hard drive connectivity check then includes cross-checking the first information with the second information. The comparison scope includes the physical disk's serial number, physical disk identifier, model string, and number of physical disks. If all communication links between the RAID card, backplane, and hard drives are functioning normally, the physical disk information obtained through the two independent in-band and out-of-band channels should be completely consistent in comparable dimensions such as serial number and quantity. If a channel or connection segment malfunctions, the two sets of information will show inconsistencies in these dimensions, which will be detected by the cross-check.

[0044] Furthermore, if the first information matches the second information, connectivity is determined to be normal. When the physical disk list obtained from the in-band scan and the physical disk list obtained from the out-of-band interface are completely consistent across all comparison dimensions, it indicates that the communication links between the RAID card and the backplane, as well as between each physical disk, are unobstructed from both the main processor side and the BMC side, and there are no local link interruptions caused by connector contact problems, cable breaks, or abnormalities in a certain port of the backplane SAS expander. The result of determining normal connectivity will serve as one of the inputs to the overall hardware integrity verification, and together with the results of other checks, will determine the final conclusion of the hardware integrity verification.

[0045] Furthermore, if the first information and the second information do not match, a connectivity anomaly is determined. When the two sets of information are inconsistent in any comparison dimension—for example, a physical disk can be scanned in-band but not out-of-band, or the serial numbers of physical disks in the same slot do not match in the two sets of information—it indicates a fault in the communication link between the RAID card and the physical disk. The specific location of the fault may be in the SAS cable connecting the RAID card to the backplane, the SAS expander chip itself on the backplane, the connector between the backplane and the specific disk slot, or the interface circuit of the physical disk itself. The result of the connectivity anomaly determination will be used as one of the inputs to the overall hardware integrity verification, leading to a final hardware integrity verification failure.

[0046] It should be noted that the out-of-band checks described above rely on the I2C or SMBus management channel between the BMC and the RAID card, or the SAS extender management function integrated into the BMC itself. When the hardware platform of the device under test meets the above conditions, the system performs in-band and out-of-band interactive verification to obtain a high-confidence result with double confirmation. Furthermore, when the hardware platform does not support the out-of-band check function, the system automatically downgrades to performing only the in-band check, and clearly notes in the test report that the out-of-band check was not performed and the confidence level of the result is limited, to ensure that the test process is not interrupted due to differences in hardware platforms.

[0047] This embodiment establishes a verification mechanism that simultaneously acquires physical disk information through in-band scanning and out-of-band interface cross-comparison, by setting up an independent hard drive connectivity check in the hardware integrity verification process. This achieves dual-perspective integrity verification of the communication link between the RAID card and the hard drive. Since the in-band channel relies on the main processor, operating system driver stack, and PCIe bus, while the out-of-band channel relies on the BMC and its independent I2C or SMBus bus, the two paths are completely independent in terms of physical cabling and protocol stack. The simultaneous matching of the two sets of information constitutes a strong confidence verification of the link integrity, effectively avoiding the one-way connectivity illusion and missed detections that may occur from relying on a single perspective. Furthermore, when the information of the two paths is inconsistent, the cross-comparison results can accurately locate the faulty segment of the communication link between the RAID card and the backplane or hard drive. Compared with traditional solutions that rely solely on in-band tool scanning, this significantly improves the accuracy of fault location and diagnostic efficiency. In addition, automatic degradation processing logic is added for cases where the hardware platform does not support out-of-band checks, making this solution highly adaptable to various hardware platforms and preventing test process interruptions due to the absence of specific management channels.

[0048] In some preferred embodiments, the configuration operation includes: obtaining the number of physical disks connected to the RAID card; automatically selecting the RAID level and creating a RAID volume based on the number, wherein if the number is greater than or equal to 3, a RAID 5 volume is created; if the number is equal to 2, a RAID 1 volume is created; if the number is equal to 1, a RAID 0 volume is created; and pushing the reverse operation of deleting the RAID volume and the identifier of the RAID volume as parameters onto the reverse operation stack.

[0049] In its implementation, this embodiment addresses the problem in traditional RAID card testing where manual selection of RAID levels based on the number of hard drives is required, leading to insufficient test script versatility and difficulty in efficiently adapting to devices under test with different hard drive configurations. The specific implementation method is as follows.

[0050] First, the number of physical disks connected to the RAID card is obtained. When performing configuration operations, the automated test script first queries the current physical disk topology information using the command-line management tool provided by the RAID card manufacturer. The `storcli` tool is used to send a physical disk list query command to the RAID card firmware, which returns a detailed list of all physical disks it manages. The script parses the Physical Drive related entries in the output, filters out physical disks that are currently unconfigured or available for configuration, and counts their total number. This number is an integer greater than or equal to 1, representing the total number of independent disk resources available for creating a RAID volume.

[0051] Furthermore, the script automatically selects the RAID level and creates a RAID volume based on the stated quantity. The script incorporates automatic RAID level decision logic based on the number of physical disks. This logic is designed to maximize available storage capacity while maintaining data redundancy protection. If the quantity is greater than or equal to 3, a RAID 5 volume is created. RAID 5 uses distributed parity checking, interleaving parity data with user data across all member disks. While providing single-disk fault tolerance, its storage space utilization rate is the total number of member disks minus one divided by the total number of member disks, offering high space efficiency and economy for large-capacity configurations. If the quantity is equal to 2, a RAID 1 volume is created. RAID 1 uses disk mirroring to completely replicate user data across two disks. Data remains intact and available even if one disk fails, offering the strongest fault tolerance but the lowest storage utilization rate of 50%. If the quantity is equal to 1, a RAID 0 volume is created. RAID 0 uses striping to write data in fixed-size stripe units to different sectors of a single disk. It does not provide data redundancy protection but has the highest read / write throughput. After the RAID level is selected, the script calls the volume creation command of the RAID card management tool, passing the selected RAID level and the corresponding list of physical disk identifiers as parameters. Upon receiving the command, the RAID card firmware assigns a virtual disk identifier, initializes parity or mirroring relationships, and constructs a logical volume mapping table to complete the creation of the virtual disk. After creation, the script performs quick initialization and verifies that the virtual disk status is Optimal, meaning the RAID volume is in a fully functional state.

[0052] Furthermore, the reverse operation for deleting the RAID volume and the RAID volume identifier are pushed onto the reverse operation stack as parameters. During the RAID volume creation operation, the non-volatile configuration area of ​​the RAID card firmware is written, causing irreversible changes to the RAID card metadata and the mapping relationship between the virtual disk and the physical disk. To accurately undo this creation operation during the environment recovery phase after testing, the script generates a corresponding reverse operation record while executing the volume creation operation. This reverse operation is for deleting the RAID volume, and the execution parameters include the virtual disk identifier of the newly created volume. The virtual disk identifier is a unique numerical number assigned by the RAID card firmware to each created RAID volume, and it is unique throughout the entire lifecycle of the RAID card, used to accurately locate the target volume in subsequent management operations. This reverse operation record and its parameters are encapsulated into a stack entry and pushed onto the top of the reverse operation stack. If subsequent configuration operations such as partitioning, formatting, or writing test files are required after creating the RAID volume, each step also generates a corresponding reverse operation according to the above mechanism and pushes it onto the stack, thus forming a complete, reverse-traceable chain of configuration changes.

[0053] This embodiment introduces automatic RAID level selection logic based on the number of physical disks during the configuration operation. This allows the same test script to adapt to devices under test with different hard drive configurations, enabling the reasonable creation of RAID volumes without manual judgment or intervention. For devices with a sufficient number of disks, RAID 5 is automatically adopted to maximize storage space utilization while ensuring data redundancy protection. For dual-disk and single-disk configurations, RAID 1 and RAID 0 are downgraded respectively, achieving intelligent matching between configuration strategies and hardware resources. This improves the versatility and deployment efficiency of the test script under different hardware configurations. Furthermore, when creating a RAID volume, deleting the volume is automatically pushed onto the reverse operation stack along with the volume's unique virtual disk identifier as a reverse operation. This ensures that the specific volume created can be accurately undone during subsequent environment recovery, giving the recovery operation precise volume-level object control capabilities and avoiding impact on other storage resources not currently being tested.

[0054] S2, Perform a stress test on the RAID card after executing the configuration operation, and obtain the test results.

[0055] In practice, a stress test is performed on the RAID card after the configuration operation is executed, and the test results are obtained. After completing all configuration operations and pushing the corresponding inverse operations onto the inverse operation stack, the automated test script begins to perform a stress test on the RAID card. The purpose of the stress test is to verify the read and write stability and reliability of the RAID card under continuous high load conditions. The fio tool is used to perform continuous random read and write operations on the created RAID virtual disk. It should be noted that fio is an open-source input / output load generation and performance testing tool, short for Flexible I / O Tester, which can simulate various read and write modes and collect performance indicators such as IOPS, latency, and bandwidth in real time. IOPS is an abbreviation for Input / Output Operations Per Second, which is one of the core indicators for measuring the performance of storage devices. The test parameters include random read and write with a block size of 4 KB, a mixed load of 70% read and 30% write, a queue depth of 32, and 4 parallel jobs. The test duration can be flexibly set according to the test scenario, 1800 s in the production line fast mode and 86400 s in the R&D verification mode. During the test, the script continuously monitors input / output error events, timeout events, and whether RAID card-related error alarms appear in the system log.

[0056] Furthermore, after the test, a comprehensive test result is obtained, which includes both pass and fail statuses. The pass criteria include no input / output errors or timeouts during the test, actual IOPS not less than 80% of the baseline value, and no RAID card error events in the system log. The baseline value can be determined in two ways: one is 90% of the average IOPS value measured under standard test conditions using the same platform, the same hard drive, and the same fio parameters for the same RAID card model; the other is a fixed threshold pre-configured by engineers on the production test execution platform to accommodate performance benchmark differences between different test batches.

[0057] In some preferred embodiments, stress testing the RAID card after performing the configuration operation includes: setting a pre-boot execution environment PXE network boot via the baseboard management controller to boot the device under test into a diskless test environment in a memory file system; in the diskless test environment, using the fio tool to directly perform random read / write operations on the RAID volume created by the configuration operation to generate test data written to the physical disk; during the random read / write operation, performing an anomaly injection operation, the anomaly injection operation including simulating hard drive hot-plugging operation or simulating power failure operation, and pushing the inverse operation corresponding to the anomaly injection operation onto the inverse operation stack.

[0058] In its implementation, this embodiment addresses the problem in traditional testing where the operating system resides on the target hard drive, preventing stress testing from generating realistic physical disk-based stress without contaminating the target disk. It achieves physical isolation between the testing environment and the target through diskless booting technology, and further adds anomaly injection operations to cover verification requirements for fault scenarios. The specific implementation method is as follows.

[0059] First, the preboot execution environment (PXE) is configured via the baseboard management controller (BMC) to boot the device under test (DUT) into a diskless test environment within a memory file system. PXE is a standardized network boot mechanism that downloads and boots an operating system image from a remote server via a local area network. Before performing stress testing on the DUT, the BMC sends boot configuration commands to the DUT's BIOS or Unified Extensible Firmware Interface (UESI) via the IPMI or Redfish protocol, switching the boot method from local hard drive boot to PXE network boot. BIOS stands for Basic Input Output System, and it's the program in the motherboard firmware responsible for hardware initialization and operating system booting.

[0060] Furthermore, after the device under test (DUT) is powered on, it initiates a Dynamic Host Configuration Protocol (DHCP) request to the PXE server on the local area network according to the PXE boot process to obtain the network address and boot server information. Then, it downloads a simplified version of the operating system kernel and a test-specific root file system image from the PXE server. This image is fully loaded into the DUT's memory, mounted as the root file system in a memory file system manner, and the test process runs. The diskless test environment refers to the operating system kernel and all its components, test scripts, and temporary files all running and stored in the memory file system. The local hard drive exists only as the target device for testing and does not participate in any data access operations of the operating system itself.

[0061] Furthermore, in the diskless test environment, the fio tool is used to directly perform random read and write operations on the RAID volume created by the configuration operation to generate test data written to the physical disk. After the device under test boots into the diskless environment, the automated test script is automatically loaded and run. Based on the virtual disk identifier of the RAID volume created in the above embodiment, the script locates the corresponding RAID volume block device node in the operating system's block device directory, which serves as the target input / output device path for the fio tool. The fio tool uses this device path as the read / write target and performs random read and write operations according to a preset test parameter template. The test parameters include a 4 KB block size, a mixed read / write mode of 70% read and 30% write, a queue depth of 32, and 4 parallel jobs. Since all read and write requests issued by the fio tool are passed to the RAID card driver via the operating system block layer and SCSI middle layer, and then the RAID card firmware performs corresponding striping mapping or mirroring according to the RAID level, the requests are then sent to each physical disk via the SAS link to perform actual media read and write operations. Therefore, the test data is actually written to the physical disk media, generating actual read and write loads and mechanical seek or flash programming operations. The resulting input / output pressure is completely equivalent to real business read and write operations in a disk-based environment. After the test is completed, the written test data remains in the data area of ​​the physical disk.

[0062] Furthermore, during the random read / write operation, an anomaly injection operation is performed. This anomaly injection operation includes simulating a hard drive hot-plugging operation or a power outage, and the inverse operation corresponding to the anomaly injection operation is pushed onto the inverse operation stack. To verify the fault-tolerance behavior and data consistency protection mechanism of the RAID card in the face of real hardware failure scenarios, the script triggers the anomaly injection operation during the background execution of random read / write operations by the fio tool. Further, the specific implementation of simulating a hard drive hot-plugging operation is as follows: the BMC sends a separate power control command for a specific drive bay to the hard drive power management chip on the backplane through its management channel with the hard drive backplane, cutting off the power supply to the physical drive in that bay to simulate a scenario where the hard drive is accidentally hot-plugged out. Further, after waiting for a preset observation period, a command to restore power to the drive bay is sent to the backplane, simulating the hard drive being reinserted. During the power outage, the RAID card firmware will detect the offline event of the drive and trigger degradation processing logic. Furthermore, the specific implementation of the simulated power outage operation is as follows: the BMC controls the overall power management module to instantly cut off all power rails of the entire machine and then restore power to simulate an unexpected abnormal power failure scenario, verifying the power failure protection mechanism of the RAID card's metadata and logs. For each abnormal injection operation executed, the script also generates a corresponding reverse operation record and pushes it onto the reverse operation stack. For example, the reverse operation of simulating disk removal is to confirm the restoration of power to the disk, trigger the RAID card reconstruction process, and wait for the reconstruction to complete; the reverse operation of simulating a power outage is to confirm that the device has been normally restored to power and returned to an operable state. By including abnormal injection operations within the management scope of the reverse operation stack, it is ensured that even after performing abnormal tests, the environment recovery mechanism can still fully cover all types of state changes.

[0063] This embodiment utilizes a diskless testing environment implemented through PXE network booting. The operating system kernel and test scripts are completely loaded into a memory file system, achieving complete physical isolation between the operating system and the target physical disk. This isolation mechanism eliminates interference with test results caused by the operating system's background log writing, cache refreshing, and file system metadata updates, ensuring that all read / write pressure generated by the fio tool is purely test load, making the analysis and evaluation of test performance data more accurate and reliable. Furthermore, since the operating system does not write any persistent data to the hard drive, only the test files explicitly written by the fio tool need to be cleared after the test to restore the hard drive to a clean state, significantly reducing the scope of data that needs to be cleaned during environment recovery and improving recovery efficiency. Introducing simulated hard drive hot-swapping and simulated power outages during continuous stress testing verifies the fault-tolerance behavior of the RAID card and its power-loss data consistency protection capabilities in the face of real physical failure scenarios. Incorporating these anomaly injection operations into the reverse operation stack management system ensures that environment recovery after anomaly testing has the same level of automation as normal testing.

[0064] S3, determine whether the test result is passed.

[0065] In practice, the test result is determined to be either pass or fail. After the stress test is completed, the automated test script reads the final status value of the test result and compares it with the preset pass conditions. This is a two-branch decision logic, which determines the subsequent execution path based on the decision result. The pass conditions, as mentioned above, cover three dimensions: no errors, performance meets the target, and no log anomalies. All three conditions must be met simultaneously for the test to be considered pass.

[0066] S4. If the test result is passed, the reverse operation is popped from the reverse operation stack in the last-in-first-out order and executed to restore the hardware configuration of the RAID card to the state before the configuration operation was executed.

[0067] In practice, if the test result is passed, the reverse operation is popped from the reverse operation stack in a last-in-first-out (LIFO) order and executed to restore the RAID card's hardware configuration to the state before the configuration operation was performed. When the stress test result is passed, it indicates that this round of testing has been completed normally, and the RAID card hardware and functions have been verified as qualified. At this time, the environment of the device under test needs to be restored to a clean state before the test so that the device can be immediately put into use in the next round of testing or reassigned to other test tasks.

[0068] Specifically, the system pops reverse operation records one by one from the top of the reverse operation stack. Since the reverse operation stack uses a last-in-first-out (LIFO) logic, the first to be popped is the reverse operation corresponding to the last operation executed during the test; that is, the most recently occurring state change is revoked first. Each reverse operation is executed immediately after being popped. For example, popping a RAID volume deletion entry calls the RAID card management tool to send a command to the RAID card firmware to delete the specified virtual disk; popping a partition table clear entry writes empty partition table data to the corresponding block device, overwriting the original partition table structure. When all reverse operations in the stack have been executed and the stack is empty, the RAID card hardware configuration of the device under test has been completely restored to a clean state before any configuration operations were performed, and the device can be immediately released for the next round of testing.

[0069] In some preferred embodiments, popping and executing the reverse operation from the reverse operation stack in a last-in-first-out (LIFO) order includes: popping the current reverse operation from the reverse operation stack and executing it; if the current reverse operation is executed successfully, then popping and executing the next reverse operation until the reverse operation stack is empty; if the current reverse operation fails, then recording the failure step and stopping the execution of the remaining reverse operations, and reporting an environment recovery anomaly.

[0070] In practice, the current reverse operation is popped from the reverse operation stack and executed. Once the test result is deemed passed, the system initiates the environment recovery process, starting by popping and executing reverse operations one by one from the reverse operation stack. Since the reverse operation stack operates on a last-in-first-out (LIFO) order, the system first pops a reverse operation record from the top of the stack. This record contains the operation type identifier and all parameters required for the operation's execution. The system then locates the corresponding reverse operation execution processing function based on the operation type identifier, passes the parameters to the function, and calls it for execution. For example, when popping a RAID volume deletion entry, the processing function calls the RAID card management tool to send a command to the RAID card firmware to delete the specified virtual disk, waits for the firmware to complete the volume deletion operation, and returns an execution result status code.

[0071] Furthermore, if the current reverse operation is successful, the system continues to pop and execute the next reverse operation until the reverse operation stack is empty. After each reverse operation is completed, the system checks the return status code of the operation. If the return status code indicates that the operation has been successfully completed, it means that the configuration change has been accurately revoked, and the corresponding RAID card configuration area or hard disk partition area has been restored to the state before the operation was executed. At this time, the system continues to pop the next reverse operation record from the top of the stack and repeats the above execution and status check process. This loop continues, and the depth of the stack gradually decreases until there are no remaining entries in the reverse operation stack, that is, the stack is completely empty. An empty stack indicates that all configuration changes generated during the test have been successfully rolled back one by one in the reverse order of execution, and the RAID card hardware configuration state and hard disk partition table state of the device under test have been completely restored to the initial clean state before any configuration operation was performed.

[0072] Furthermore, if the current reverse operation fails, the failed steps are recorded, the remaining reverse operations are stopped, and an environment recovery anomaly is reported. When the return status code of a reverse operation indicates that the operation failed, it means that the RAID card configuration or hard disk partition status targeted by the reverse operation may have experienced unexpected anomalies, or the RAID card firmware has entered a locked state during testing that does not allow deletion operations. If the remaining reverse operations are continued to be popped from the stack at this time, since these reverse operations may depend on the prerequisites for correct execution after the completion of the preceding reverse operations, rash execution may lead to a more chaotic environment or unrecoverable configuration conflicts. Therefore, the system adopts an immediate abort strategy, stopping the popping of any subsequent reverse operation entries from the reverse operation stack, while the remaining entries in the stack are retained as is. The system records detailed diagnostic information such as the type of the failed reverse operation, execution parameters, return status code at the time of failure, and current timestamp, generates an environment recovery anomaly report, and reports it to the production test execution platform. The platform updates the recovery status of the device to "environment recovery anomaly" in the monitoring interface and highlights it visually. After receiving an anomaly notification, maintenance personnel can manually inspect and analyze the device through the platform's BMC Web interface or SSH remote login channel. After confirming the actual status of the current environment, they can decide whether to manually complete the remaining recovery operations or reconfigure the test environment.

[0073] This embodiment adds sequential execution of abnormal state detection and interrupt control logic to the automatic rollback mechanism of the reverse operation stack. This enables the originally mechanical rollback process to perceive abnormal situations in real time and react safely. When a reverse operation fails, the system immediately suspends all subsequent rollback steps and reports detailed failure information. This avoids the risk of unpredictable states and escalated configuration conflicts that may result from blindly continuing to execute remaining reverse operations when environmental preconditions have been compromised. The impact of a single recovery failure is strictly controlled to the smallest granularity. Furthermore, entries in the stack that have not yet been executed at the time of failure are preserved, providing maintenance personnel with a complete history of environmental changes. Combined with the specific information of the failed reverse operation, the entire operation trajectory from the initial state to the current abnormal state can be quickly reconstructed, providing sufficient tracing evidence for root cause analysis.

[0074] S5. If the test result is a failure, the current hardware configuration status of the RAID card and the test environment are retained.

[0075] In practice, if the test fails, the current hardware configuration of the RAID card and the test environment are preserved. When the stress test fails, it indicates an anomaly occurred during the test, suggesting a potential hardware defect or firmware issue with the RAID card. Continuing with environment recovery at this point would erase all fault data used to locate the root cause, including the RAID card's current volume configuration, event and operation logs in the firmware, SCSI and RAID-related logs in the system kernel's ring buffer, and performance data records generated by the fio tool. This would prevent the reproduction of the hardware state and environmental conditions at the time of the failure during subsequent manual analysis. Therefore, the system skips the reverse operation stack rollback step, leaving the already pushed items on the reverse operation stack unchanged, thus fully preserving the current RAID card's hardware configuration and all intermediate test data. Furthermore, the system marks the device under test as awaiting manual analysis and displays its status with a prominent anomaly indicator on the production test execution platform's monitoring interface. This allows maintenance personnel to remotely operate and deeply debug the abnormal device via the BMC's web interface, SSH remote login, or Web KVM function until the cause of the failure is confirmed, at which point the maintenance personnel manually trigger environment recovery.

[0076] This embodiment establishes a reverse operation stack mechanism to synchronously record the reverse operation and parameters of each step during the test configuration process. After the test, differentiated processing is performed based on the success or failure of the test results, achieving intelligent management and precise recovery of the test environment in automated RAID card testing. When the test passes, the reverse operation stack automatically rolls back all configuration changes in a last-in-first-out manner, restoring the device under test to its initial clean state for direct reuse in the next round of testing. No manual intervention is required to clean up residual RAID configuration and partition table data, significantly improving the continuity and automation of multiple rounds of repeated testing. Furthermore, when the test fails, the system skips the environment recovery step to fully retain the RAID card hardware configuration status, firmware logs, and system logs at the time of the failure, providing complete data support for subsequent root cause analysis and avoiding the drawback of traditional global reset schemes that destroy fault evidence upon test failure. This result-aware differentiated processing strategy simultaneously addresses the need for efficient recovery of the automated test environment and the need for fault location in abnormal scenarios, achieving an organic unity between testing efficiency and problem tracking capabilities.

[0077] In some preferred embodiments, after obtaining the test results, the method further includes: collecting the configuration information, event logs, system logs, and test execution results of the RAID card, and uploading them to the production test data collection and statistical analysis platform; if the test result is a failure, the device under test is marked as awaiting manual analysis, and the test results and fault logs are uploaded to the production test data collection and statistical analysis platform.

[0078] In practice, this embodiment addresses the problem in traditional testing schemes where log data is scattered and stored locally on each device under test, leading to difficulties in collection and aggregation, and the inability to conduct centralized cross-device statistical analysis and anomaly tracking responses. The specific implementation method is as follows.

[0079] After obtaining the test results, the configuration information, event logs, system logs, and test execution results of the RAID card are collected and uploaded to the production test data collection and statistical analysis platform. Regardless of whether the test result is pass or fail, the automated test script performs a set of standard data collection and uploading actions after the test process is completed. The collected data includes the RAID card's current complete firmware configuration information, namely, all virtual disk configuration details, physical disk topology relationships, RAID level allocation, and firmware version number stored in the current firmware. It also includes the RAID card's internal event logs and terminal logs. The event logs record all hardware events, state transitions, and alarm information that occur during the RAID card's operation, while the terminal logs record all input commands and output responses when interacting with the RAID card through command-line management tools, facilitating playback analysis. Furthermore, it also includes the parts of the operating system's system log related to the RAID subsystem and SCSI subsystem. SCSI is an abbreviation for Small Computer System Interface, which is a standard command set for communication between the operating system and storage devices. Furthermore, it also includes complete execution result details for this test case, covering the pass or failure status of each step, the comparison results of the specific values ​​of each check item with preset thresholds, and the timestamp information of each step's execution. All the above data is packaged into a structured log archive file and uploaded to the production test data collection and statistical analysis platform through a secure network channel. This platform has the capability for large-scale unified data storage and intelligent analysis, and can perform summary statistics, trend analysis, and anomaly pattern mining on test data across batches and models.

[0080] Furthermore, if the test result is a failure, the device under test is marked as awaiting manual analysis, and the test result and fault log are uploaded to the production test data collection and statistical analysis platform. Based on the general log collection and upload, for devices under test with failed test results, the system performs additional marking and enhanced fault data reporting operations. The system updates the status field of the current device under test in the platform's device management database to await manual analysis. This status is highlighted in a specific color or with a flashing icon in the platform's real-time monitoring interface to distinguish it from devices under testing and normal devices that have passed the test. Furthermore, the summary information of the failed test result, key error content from the fault log, and the regularly collected log archive files are packaged and uploaded together to ensure that the platform can receive complete fault context data immediately after a fault occurs, providing sufficient data support for maintenance personnel to remotely predict faults and prioritize maintenance. Furthermore, after maintenance personnel complete the fault analysis and manually trigger environment recovery through the platform interface, the device's marked status is reset to assignable.

[0081] This embodiment achieves centralized storage and end-to-end traceability management of test logs by uniformly collecting and uploading logs after each test. Data such as RAID card configuration information, event logs, system logs, and test results, originally scattered across the individual devices under test (DUTs), are aggregated onto a production test data collection and statistical analysis platform. The platform's big data intelligent analysis capabilities enable horizontal comparison and trend analysis of test data across batches, providing quantitative data support for continuous improvement of RAID card firmware quality and dynamic monitoring of production yield. Furthermore, when a test result is a failure, the DUT is automatically marked as requiring manual analysis, and the fault log is uploaded synchronously. This allows maintenance personnel to immediately identify abnormal devices and obtain complete fault context information on the platform's unified monitoring interface, eliminating the need to manually collect and piece together scattered log fragments from each DUT, significantly shortening the average response time from fault occurrence to maintenance personnel intervention.

[0082] In some preferred embodiments, the method is executed by a baseboard management controller, which simultaneously issues instructions to multiple devices under test via the IPMI protocol or the Redfish protocol to execute the above-described automated RAID card testing method in parallel on each of the devices under test.

[0083] In its specific implementation, this embodiment addresses the problem in traditional RAID card testing where a single controller can only serially control a single device under test, resulting in long batch testing cycles and low test coverage for each batch of devices. It achieves large-scale synchronous testing of multiple devices under test through the multi-device parallel scheduling capability of the baseboard management controller. The specific implementation method is as follows.

[0084] The method is executed by the Baseboard Management Controller (BMC), which simultaneously issues commands to multiple (e.g., 10) Devices under Test (DUTs) via the IPMI or Redfish protocol to execute the aforementioned automated RAID card testing method in parallel on each DUT. As the core control node of the entire automated testing system, the BMC's firmware is designed to manage multiple DUTs simultaneously. The BMC establishes independent IPMI or Redfish management sessions with each DUT through its multiple network management interfaces. Each session maintains the context state and control channel of the device, and the sessions are decoupled from each other. The IPMI protocol is an out-of-band management standard based on the User Datagram Protocol (UDP) and Remote Management Control Protocol (RMCP), providing basic power-on / off control, sensor reading, and log acquisition operations.

[0085] Furthermore, the Redfish protocol is a modern management interface based on a representational state transition architecture. It uses the Hypertext Transfer Protocol (HTTP) and JSON data format for information exchange. JSON stands for JavaScript Object Notation, a lightweight text-based data exchange format. Compared to IPMI, the Redfish protocol offers better firewall friendliness and scalability, and supports richer data models and operational semantics.

[0086] Furthermore, BMC independently issues commands to each device under test (DUT) via the aforementioned two protocols. Upon receiving the command, each DUT independently begins executing all test steps, including hardware integrity verification, automatic RAID level selection and volume creation, fio stress testing and anomaly injection in a diskless boot environment, test result judgment, environment recovery based on the reverse operation stack, and log collection and uploading. Because BMC communicates with each DUT through independent sessions, the test progress of each DUT is independent and does not block others; anomalies or delays in one device will not affect the normal testing progress of other devices. BMC periodically polls the execution status of each device and summarizes and reports the polling results to the production test execution platform. The platform simultaneously displays the real-time test status, current execution steps, and completed test results of all managed DUTs in a matrix view or list view on its monitoring interface, enabling operations personnel to have a global situational awareness of all DUTs on a single interface.

[0087] This embodiment uses the Baseboard Management Controller (BMC) as a centralized control node, establishing independent management sessions with multiple devices under test (DUTs) using the IPMI and Redfish protocols, and simultaneously issuing test commands in parallel. This enables large-scale synchronous scheduling of multiple DUTs by a single BMC controller. Compared to traditional serial testing methods that can only test one or two devices sequentially at a time, this parallel architecture significantly increases the number of devices that can be tested within the same time window, resulting in a substantial improvement in device sampling coverage. Furthermore, because the BMC and each DUT use session-level isolated independent control channels, the test execution of each device is independent of the others. Hardware failures or network latency in one device will not block the test process of other devices, effectively ensuring the overall throughput efficiency of the test pipeline. By deploying the complete automated testing process described in the above embodiments, which includes hardware integrity verification, automatic RAID configuration, diskless stress testing, reverse operation stack environment recovery, and centralized log uploading, on this parallel scheduling architecture, a leap in capability from single-machine automated testing to large-scale cluster parallel automated testing is achieved. This enables batch testing during the mass production and incoming material inspection stages of RAID cards to achieve sufficient coverage and reliable quality assurance within a limited time window.

[0088] Please see Figure 2 , Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a terminal or a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0089] The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0090] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, it causes the processor 502 to execute an automated testing method for a RAID card.

[0091] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0092] The internal memory 504 provides an environment for the operation of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute an automated testing method for a RAID card.

[0093] The network interface 505 is used for network communication with other devices. Those skilled in the art will understand that the above structure is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. A specific computer device 500 may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements.

[0094] The processor 502 is used to run a computer program 5032 stored in a memory to implement the steps of an automated RAID card testing method provided in any of the above embodiments.

[0095] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), but it may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0096] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0097] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program. When executed by a processor, the computer program causes the processor to perform the steps of the automated testing method for a RAID card provided in any of the above embodiments.

[0098] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.

[0099] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software 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 implementations should not be considered beyond the scope of this invention.

[0100] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0101] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0102] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0103] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0104] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, this invention is also intended to include these modifications and variations as long as they fall within the scope of the claims and their equivalents.

[0105] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for automated testing of a RAID card, the method comprising: include: In response to a received test task, at least one configuration operation is performed on the RAID card in the device under test, wherein the configuration operation changes the hardware configuration state of the RAID card, and when the configuration operation is performed, the inverse operation corresponding to the configuration operation and the parameters of the inverse operation are pushed onto the inverse operation stack. Perform a stress test on the RAID card after executing the configuration operation, and obtain the test results; Determine whether the test result is passed; If the test result is passed, the reverse operation is popped from the reverse operation stack in the last-in-first-out order and executed to restore the hardware configuration of the RAID card to the state before the configuration operation was executed; If the test result is a failure, the current hardware configuration status of the RAID card and the test environment will be retained.

2. The method of claim 1, wherein, Before performing at least one configuration operation on the RAID card in the device under test, the method further includes: The hardware integrity of the RAID card is verified, and the hardware integrity verification result is obtained. Determine whether the hardware integrity verification result is passed; If the hardware integrity verification result is passed, then the configuration operation is executed; If the hardware integrity verification result is a failure, the device under test will be marked as having a hardware abnormal state, and the hardware integrity verification failure information will be reported.

3. The method of claim 2, wherein, The hardware integrity verification of the RAID card includes a hard drive connectivity check, which includes: Perform an in-band scan to obtain the first information of the physical disk connected to the RAID card; The second information of the physical disk connected to the RAID card is obtained through the out-of-band interface of the baseboard management controller; Cross-compare the first information with the second information; If the first information matches the second information, then the connectivity is determined to be normal; If the first information does not match the second information, then the connectivity is determined to be abnormal.

4. The method of claim 1, wherein, The configuration operations include: Obtain the number of physical disks connected to the RAID card; The RAID level is automatically selected and a RAID volume is created based on the quantity. If the quantity is greater than or equal to 3, a RAID 5 volume is created; if the quantity is equal to 2, a RAID 1 volume is created; and if the quantity is equal to 1, a RAID 0 volume is created. The reverse operation of deleting the RAID volume and the identifier of the RAID volume are pushed onto the reverse operation stack as parameters.

5. The method of claim 4, wherein, The stress test performed on the RAID card after the configuration operation includes: The pre-boot execution environment PXE network boot is configured through the baseboard management controller, enabling the device under test to boot into a diskless test environment in the memory file system; In the diskless test environment, the fio tool is used to directly perform random read and write operations on the RAID volume created by the configuration operation to generate test data that is written to the physical disk; During the random read / write operation, an exception injection operation is performed, which includes simulating a hard disk hot-plug operation or simulating a power failure operation, and the inverse operation corresponding to the exception injection operation is pushed onto the inverse operation stack.

6. The method of claim 1, wherein, The step of popping the reverse operation from the reverse operation stack and executing it in a last-in-first-out (LIFO) order includes: Pop the current inverse operation from the inverse operation stack and execute it; If the current inverse operation is executed successfully, the next inverse operation will be popped and executed until the inverse operation stack is empty. If the current inverse operation fails, the failed step is recorded and the remaining inverse operations are stopped, and an environment recovery anomaly is reported.

7. The method of claim 1, wherein, After obtaining the test results, the following is also included: The configuration information, event logs, system logs, and test execution results of the RAID card are collected and uploaded to the production test data collection and statistical analysis platform. If the test result is a failure, the device under test will be marked as awaiting manual analysis, and the test result and fault log will be uploaded to the production test data collection and statistical analysis platform.

8. The RAID card automated testing method of any of claims 1-7, wherein, The method is executed by a baseboard management controller, which simultaneously sends instructions to multiple devices under test via the IPMI protocol or the Redfish protocol to execute the RAID card automated testing method as described in any one of claims 1 to 7 in parallel on each of the devices under test.

9. A computer device, comprising: The computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-8.

Images