BMC (Baseboard Management Controller) automatic testing method and equipment based on large model and medium

Abstract

The invention provides a BMC automatic testing method and device based on a large model and a medium. The method comprises the following steps: acquiring multi-dimensional operation data of a baseboard management controller (BMC); inputting the multi-dimensional operation data into the trained BMC special test large model, and generating a software and hardware integrated linkage test case adaptive to a hardware link topological structure; wherein the BMC special test large model is used for performing semantic analysis and feature extraction on the multi-dimensional operation data, identifying full hardware links managed by the BMC and management protocol types corresponding to the hardware links, and adaptively generating software and hardware integrated linkage test cases for the BMC; and based on the software and hardware integrated linkage test case, carrying out joint automatic testing of a hardware link and a management protocol on the BMC. The method and the device are used for achieving the effects of improving the compatibility of the test cases, reducing the maintenance cost and improving the test efficiency.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to an automated testing method, device and medium for BMC based on a large model. Background Technology

[0002] Complex information systems such as servers, switches, and industrial control equipment all rely on Baseboard Management Controllers (BMCs) for hardware-level status monitoring, fault diagnosis, and remote maintenance. As the core hardware management unit, the BMC interconnects with components such as the CPU, memory, and power supply through various hardware links (e.g., I2C, PCIe, LPC). Based on standardized protocols such as the Intelligent Platform Management Interface (IPMI) and Redfish, it provides a unified management interface to the upper-level management system. The stability of the BMC's operation determines the reliability of the entire system.

[0003] Currently, BMC testing mainly consists of two parts: hardware link testing and management protocol testing. In related technologies, testers or testing tools write independent hardware link test cases and management protocol test cases respectively, and then perform automated BMC testing based on these pre-defined test cases.

[0004] The above technologies suffer from poor test case compatibility, high maintenance costs, and low testing efficiency, making it difficult to meet the testing needs in the context of rapid iterative upgrades of the BMC hardware link. Summary of the Invention

[0005] This application provides a BMC automated testing method, equipment, and medium based on a large model, which aims to improve test case compatibility, reduce maintenance costs, and increase testing efficiency.

[0006] Firstly, this application provides an automated BMC testing method based on a large model, including:

[0007] Obtain multidimensional operational data of BMC;

[0008] Multidimensional operational data is input into a pre-trained BMC-specific test model to generate integrated hardware and software test cases adapted to the hardware link topology. The BMC-specific test model is used to perform semantic parsing and feature extraction on the multidimensional operational data, identify all hardware links managed by BMC and the management protocol type corresponding to each hardware link, and adaptively generate integrated hardware and software test cases for BMC. The BMC-specific test model is a domain-specific model obtained by deeply fine-tuning the general model based on the BMC vertical domain knowledge base.

[0009] Based on integrated hardware and software test cases, joint automated testing of hardware links and management protocols is performed on BMC.

[0010] In one possible implementation, the multidimensional operational data includes link layer data reflecting the physical hardware links, topology description data reflecting device configuration, and management protocol interaction data. The BMC-specific test model is specifically used for:

[0011] Parse the link layer data to identify all hardware links managed by the BMC;

[0012] Based on the physical layer characteristics and link layer protocol characteristics of each hardware link, all hardware links are classified and identified to obtain multiple classified hardware links.

[0013] Semantic understanding is performed on the topology description data, and the hierarchical topology relationship between hardware components is reconstructed by combining multiple classified hardware links.

[0014] Extract the link feature parameters of each hardware link from the multiple classified hardware links. The link feature parameters include at least one of the following: topology parameters, transmission characteristic parameters, and operating status parameters.

[0015] The protocol format of the management protocol interaction data is identified, and the corresponding management protocol type is dynamically matched for each hardware link based on the identified protocol feature fields and link feature parameters.

[0016] Based on the classified multiple hardware links, hierarchical topology relationships, and management protocol types, adaptively generate integrated hardware and software test cases that adapt to the hardware link topology.

[0017] In one possible implementation, based on the classified multiple hardware links, hierarchical topology relationships, and management protocol types, adaptive hardware-software integrated test cases adapted to the hardware link topology are generated, including:

[0018] Based on the classified hardware links, hierarchical topology relationships and management protocol types, test case logic for the linkage between hardware links and management protocols is automatically generated.

[0019] Load the configured BMC-specific testing framework and target programming language to transform test case logic into executable automated test code;

[0020] Use automated test code as integrated hardware and software test cases.

[0021] In one possible implementation, the BMC automated testing method based on large models also includes:

[0022] Obtain the test results of the joint automated test, including hardware link status data, management protocol response data, abnormal event logs and test execution records;

[0023] The test results are input into the BMC special test model. The BMC special test model performs semantic analysis and trend judgment on the test results and generates a test report. The test report includes hardware link operation status assessment, protocol compatibility analysis and optimization suggestions.

[0024] Update the BMC vertical domain knowledge base based on test results and test reports;

[0025] Based on the updated BMC vertical domain knowledge base, the BMC-specific test model was fine-tuned.

[0026] We updated the integrated hardware and software test cases using the finely tuned BMC-specific test model.

[0027] In one possible implementation, based on integrated hardware and software test cases, joint automated testing of the BMC's hardware link and management protocol is performed, including:

[0028] Based on integrated hardware and software test cases, execute a full hardware link and protocol linkage test process;

[0029] During test execution, for the currently executing target test case, the hardware link status data and management protocol response data corresponding to the target test case are acquired synchronously.

[0030] Perform consistency verification on the hardware link status data and management protocol response data corresponding to the target test case, and generate consistency verification results. The consistency verification includes at least one of numerical consistency verification, status consistency verification and event consistency verification.

[0031] Based on the consistency verification results, test results are generated for the target test cases.

[0032] In one possible implementation, based on the consistency verification results, test results for the target test cases are generated, including:

[0033] If the consistency check result indicates that the check failed, the abnormal context information corresponding to the consistency check result is input into the BMC special test model. The BMC special test model intelligently classifies the abnormality type of the abnormal context information based on the built-in fault mode knowledge base to distinguish between intermittent environmental anomalies and deterministic hardware failures. If the abnormality type is an intermittent environmental anomaly, a retesting strategy is executed, and the test result of the target test case is determined based on the retesting result. If the abnormality type is a deterministic hardware failure, the test result of the target test case is determined to be a test failure.

[0034] If the consistency check result indicates that all check items have passed the check, the test result of the target test case is determined to be a successful test.

[0035] In one possible implementation, the BMC automated testing method based on a large model further includes:

[0036] Obtain the real-time status of the test environment corresponding to BMC;

[0037] Adjust the consistency verification rules based on the real-time status.

[0038] Secondly, this application provides an automated BMC testing device based on a large model, comprising:

[0039] The acquisition module is used to acquire multidimensional operational data of the BMC;

[0040] The processing module is used to input multi-dimensional runtime data into the trained BMC-specific test model to generate integrated hardware and software test cases adapted to the hardware link topology. The BMC-specific test model is used to perform semantic parsing and feature extraction on the multi-dimensional runtime data, identify all hardware links managed by BMC and the management protocol type corresponding to each hardware link, and adaptively generate integrated hardware and software test cases for BMC. The BMC-specific test model is a domain-specific model obtained by deeply fine-tuning the general model based on the BMC vertical domain knowledge base.

[0041] The testing module is used to perform joint automated testing of the hardware link and management protocol of BMC based on integrated hardware and software test cases.

[0042] In one possible implementation, the processing module is specifically used for: parsing link layer data to identify all hardware links managed by the BMC; classifying and identifying all hardware links according to their physical layer characteristics and link layer protocol characteristics to obtain multiple classified hardware links; performing semantic understanding on topology description data and reconstructing the hierarchical topology relationship between hardware components by combining the classified hardware links; extracting link feature parameters for each hardware link from the classified hardware links, where the link feature parameters include at least one of topology parameters, transmission characteristic parameters, and operating status parameters; identifying the protocol format of management protocol interaction data and dynamically matching the corresponding management protocol type for each hardware link based on the identified protocol feature fields and link feature parameters; and adaptively generating integrated hardware and software linkage test cases adapted to the hardware link topology based on the classified hardware links, hierarchical topology relationship, and management protocol type.

[0043] In one possible implementation, the processing module is further configured to: automatically generate test case logic for the linkage between hardware links and management protocols based on the classified multiple hardware links, hierarchical topology relationships and management protocol types; load the set BMC-specific test framework and target programming language to convert the test case logic into executable automated test code; and use the automated test code as integrated hardware and software linkage test cases.

[0044] In one possible implementation, the processing module is further configured to: acquire test results from joint automated testing, including hardware link status data, management protocol response data, exception event logs, and test execution records; input the test results into the BMC-specific test model, perform semantic analysis and trend judgment on the test results through the BMC-specific test model, and generate a test report, including hardware link operation status assessment, protocol compatibility analysis, and optimization suggestions; update the BMC vertical domain knowledge base based on the test results and test report; fine-tune the BMC-specific test model based on the updated BMC vertical domain knowledge base; and update the integrated hardware and software test cases using the fine-tuned BMC-specific test model.

[0045] In one possible implementation, the testing module is specifically used to: execute a full hardware link and protocol linkage test process based on integrated hardware and software test cases; during test execution, for the currently executed target test case, synchronously acquire the hardware link status data and management protocol response data corresponding to the target test case; perform consistency verification on the hardware link status data and management protocol response data corresponding to the target test case, and generate a consistency verification result, wherein the consistency verification includes at least one of numerical consistency verification, status consistency verification, and event consistency verification; and generate test results for the target test case based on the consistency verification result.

[0046] In one possible implementation, the testing module is further configured to: input the exception context information corresponding to the consistency verification result into the BMC-specific testing model when the consistency verification result indicates that a verification has failed; the BMC-specific testing model intelligently classifies the exception type of the exception context information based on its built-in fault mode knowledge base to distinguish between intermittent environmental anomalies and deterministic hardware failures; if the exception type is an intermittent environmental anomaly, a retesting strategy is executed, and the test result of the target test case is determined based on the retesting result; if the exception type is a deterministic hardware failure, the test result of the target test case is determined to be a test failure; if the consistency verification result indicates that all verification items have passed, the test result of the target test case is determined to be a test pass.

[0047] In one possible implementation, the BMC automated testing device based on a large model further includes an adjustment module, which is used to: obtain the real-time status of the test environment corresponding to the BMC; and adjust the verification rules of the consistency check according to the real-time status.

[0048] Thirdly, this application provides an electronic device, including: a memory and a processor;

[0049] The memory stores the instructions that the computer executes;

[0050] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0051] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible embodiments of the first aspect.

[0052] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0053] This application provides a BMC automated testing method, equipment, and medium based on a large model, comprising: acquiring multi-dimensional operational data of the BMC; inputting the multi-dimensional operational data into a trained BMC-specific test large model to generate integrated hardware and software test cases adapted to the hardware link topology; wherein, the BMC-specific test large model is used to perform semantic parsing and feature extraction on the multi-dimensional operational data, identify all hardware links managed by the BMC and the management protocol type corresponding to each hardware link, and adaptively generate integrated hardware and software test cases for the BMC; the BMC-specific test large model is a domain-specific model obtained by deeply fine-tuning a general large model based on a BMC vertical domain knowledge base; and performing joint automated testing of hardware links and management protocols on the BMC based on the integrated hardware and software test cases. In this process, the general large model is fine-tuned through the vertical domain knowledge base, enabling the BMC-specific test large model to have full-domain adaptability to multiple types of scalable BMC hardware links. Furthermore, the BMC-specific test large model automatically identifies and adapts to multiple types of hardware links, dynamically expands test cases, eliminates the need for manual reconstruction of the test framework, significantly reduces test case maintenance costs, and improves compatibility with different hardware links. Secondly, by integrating hardware and software testing, the hardware link status and management protocol response are verified simultaneously, resolving the issue of fragmented testing between the hardware link and management protocol. This ensures the testing process covers hardware-software collaboration scenarios, accurately locates hardware-software coupling faults, reduces the risk of misjudgment, and thus improves the accuracy of test results. Furthermore, combined with a fully automated testing mechanism, from automatic hardware link identification and adaptive test case generation to the execution of integrated tests, no manual intervention is required, improving testing efficiency. This application is applicable to diverse BMC testing scenarios such as servers and industrial control equipment, and can meet the testing needs in the context of rapid iteration and upgrades of BMC hardware links. Attached Figure Description

[0054] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0055] Figure 1 A schematic diagram illustrating a scenario for the BMC automated testing method based on a large model provided in this application embodiment;

[0056] Figure 2 A flowchart illustrating the BMC automated testing method based on a large model provided in this application embodiment. Figure 1 ;

[0057] Figure 3 A flowchart illustrating the BMC automated testing method based on a large model provided in this application embodiment. Figure 2 ;

[0058] Figure 4A flowchart illustrating the BMC automated testing method based on a large model provided in this application embodiment. Figure 3 ;

[0059] Figure 5 A schematic diagram of the structure of the BMC automated testing device based on a large model provided in this application embodiment. Figure 1 ;

[0060] Figure 6 A schematic diagram of the structure of the BMC automated testing device based on a large model provided in this application embodiment. Figure 2 ;

[0061] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0062] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0063] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0064] The terms “first,” “second,” etc., used in the specification and claims of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, products, or apparatus.

[0065] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0066] In related technologies, testers manually write test scripts based on hardware design documents, designing test cases for single hardware links (such as I2C) and fixed protocols (such as IPMI). This approach requires manual maintenance of numerous scripts, resulting in incomplete test coverage and difficulty adapting to new hardware links (such as PCIe 5.0). It also suffers from poor test case compatibility, low testing efficiency, and high maintenance costs. Furthermore, this approach often involves a disconnect between hardware link testing and protocol testing, affecting the accuracy of fault location, especially for hardware-software coupled faults, which are prone to missed tests or misdiagnosis. Additionally, while some testing tools may support hardware link scanning and protocol parsing, the testing process is rigid, requiring preset hardware link types (e.g., only supporting PCIe), making it unable to adapt to new hardware link expansions. Moreover, test case generation relies on fixed templates, lacking adaptability to dynamic changes in hardware topology, leading to insufficient test scenario coverage and impacting testing efficiency.

[0067] To address the problems existing in the aforementioned technologies, this application provides a BMC automated testing solution based on a large model. This solution introduces a domain-specific model, deeply fine-tuned based on a BMC vertical domain knowledge base. Leveraging the model's global adaptability to various types of scalable BMC hardware links, test cases are dynamically expanded based on the current BMC hardware link topology. This reduces test case maintenance costs, improves compatibility with different hardware links, and enhances testing efficiency. Furthermore, through integrated hardware and software testing, the hardware link status and management protocol responses are simultaneously verified, ensuring the testing process covers hardware and software collaboration scenarios, thereby improving the accuracy of test results.

[0068] First, the application scenarios of this application will be introduced.

[0069] This application applies to full-domain testing scenarios of hardware links in BMCs of servers, switches, industrial control equipment, and embedded systems. It includes automatic identification and signal acquisition of various types of hardware links managed by the BMC, such as I2C, SMBus, PCIe, and NVMe; collaborative testing of management protocols such as Redfish and IPMI with hardware links, covering scenarios such as connectivity, stress, and fault tolerance; intelligent analysis and closed-loop optimization of test results, adapting to hardware link expansion needs (such as adding NVMe storage devices).

[0070] Figure 1A schematic diagram of a scenario for the BMC automated testing method based on a large model provided in this application embodiment, such as... Figure 1 As shown, the test device 11 establishes a communication connection with the BMC 12 under test through a network interface. The test device 11 acquires multi-dimensional operational data of the BMC 12. The test device 11 is equipped with a large-scale BMC-specific test model. The test device 11 performs semantic parsing and feature extraction on the multi-dimensional operational data through the large-scale BMC-specific test model, and then adaptively generates integrated hardware and software test cases for the BMC 12. Based on the test cases, the test device 11 performs joint automated testing of the hardware link and management protocol of the BMC 12.

[0071] It should be noted that, Figure 1 The application scenarios shown are for illustrative purposes only. There is no limit to the number of test devices 11; the specific number should be set according to actual needs.

[0072] in addition, Figure 1 The test device 11 is only an example of a computer, but it can also be used for wearable devices, laptops, desktop computers, workbenches, personal digital assistants, servers, blade servers, server clusters, and so on.

[0073] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0074] Figure 2 A flowchart illustrating the BMC automated testing method based on a large model provided in this application embodiment. Figure 1 The execution subject of this embodiment is Figure 1 Test equipment 11 in the middle.

[0075] like Figure 2 As shown, the BMC automated testing method based on a large model includes:

[0076] S201. Obtain multi-dimensional operational data of BMC.

[0077] A BMC (Browser Controller) is a dedicated microcontroller primarily deployed in complex information systems such as servers, switches, or industrial control equipment. Its main function is to monitor, manage, and diagnose system hardware. The BMC interconnects with key components in the system, such as the CPU, memory, and power supply, through various hardware links, and provides a unified management interface to the upper-level management system to ensure the stable operation of the entire system. For example, a BMC is a dedicated microcontroller integrated on a server motherboard, responsible for monitoring the system's physical status, such as temperature, voltage, fan speed, and power supply status, and supporting remote management and fault diagnosis.

[0078] In this embodiment, multidimensional operational data can be understood as a multidimensional raw data set (i.e., full-domain operational data) that can reflect the status of the hardware system managed by the BMC. Using multidimensional operational data ensures that the model can fully analyze the adaptation relationship between the hardware link and the management protocol.

[0079] For example, the test device 11 establishes a communication connection with the BMC under test and actively collects the full-domain operation data of the hardware system managed by the BMC under test. For example, it sends probe commands to the BMC through a standardized management protocol to obtain link layer data reflecting the physical connection relationship of the hardware (such as bus type, device address, communication rate and register mapping information of each hardware link, etc.), topology description data reflecting the component configuration and hierarchical relationship (such as type identifier of hardware component, parent and child mounting relationship and physical location information), and management protocol interaction data reflecting the interaction behavior between the BMC and the management system (such as protocol request and response messages, protocol version information and event log records, etc.).

[0080] The acquired multidimensional runtime data is temporarily stored in memory in a structured or semi-structured format.

[0081] S202. Input the multi-dimensional runtime data into the trained BMC-specific test model to generate integrated hardware and software test cases adapted to the hardware link topology. The BMC-specific test model is used to perform semantic parsing and feature extraction on the multi-dimensional runtime data, identify all hardware links managed by the BMC and the management protocol type corresponding to each hardware link, and adaptively generate integrated hardware and software test cases for the BMC.

[0082] Among them, the BMC special test model is a domain-specific model obtained by deeply fine-tuning the general model based on the BMC vertical domain knowledge base.

[0083] Hardware links can be viewed as physical connection channels between the BMC and hardware components for communication, including but not limited to bus links based on the I2C protocol, bus links based on the SMBus protocol, high-speed data links based on the PCIe protocol, and storage links based on the NVMe protocol.

[0084] Management protocols can be viewed as the communication specifications followed by the interaction between the BMC and the upper-level management system or test equipment, including but not limited to the IPMI protocol, the Redfish extensible firmware interface protocol, the Management Component Transport Protocol (MCTP), and the Network Controller Sideband Interface (NC-SI) protocol.

[0085] It should be understood that general-purpose large-scale models typically include AI models trained on large-scale text, not limited to architectures like GPT and BERT. They possess basic natural language processing capabilities and can perform tasks such as text analysis and code generation in general scenarios. However, general-purpose large-scale models are mainly applicable to pure software scenarios and lack the ability to understand hardware links. They cannot parse hardware layer features such as I2C bus addresses, PCIe configuration space, and sensor register mappings, nor can they understand protocol rules specific to the BMC vertical domain, such as the original command format of the IPMI protocol and the Redfish resource model. Therefore, if general-purpose large-scale models are used directly for BMC testing, the generated test cases often remain at a general level, unable to be deeply coupled with specific hardware links, and unable to achieve linkage testing between hardware links and protocols such as Redfish and IPMI, resulting in poor practicality.

[0086] In this embodiment, a BMC-specific test model is obtained by deeply fine-tuning the general model using a BMC vertical domain knowledge base. The BMC vertical domain knowledge base can be understood as a set of BMC-specific knowledge formed after preprocessing (such as data cleaning and normalization), including hardware link characteristic parameters (such as I2C bus address mapping, PCIe link rate specifications, and sensor register definitions), management protocol rule definitions (such as IPMI command sets, Redfish Schema definitions, and MCTP protocol specifications), and historical test data (such as SEL event logs, test case libraries, and fault modes). Through fine-tuning training using vertical domain knowledge, this BMC-specific test model possesses hardware link signal parsing capabilities, management protocol semantic understanding capabilities, fault diagnosis reasoning capabilities, and the ability to adaptively generate integrated hardware and software test cases.

[0087] For example, the BMC-specific test model first performs semantic parsing on multi-dimensional operational data to extract hardware link type identifiers, bus topology relationships, and device configuration parameters. Then, based on its learned hardware link characteristic knowledge, the BMC-specific test model automatically identifies all hardware links managed by the BMC under test, including the bus type, device address, communication rate, and register mapping relationships for each link. Simultaneously, based on the device type and communication characteristics of each hardware link, and combined with its learned protocol rule knowledge, the BMC-specific test model dynamically matches the corresponding native management protocol type for each hardware link, including IPMI, Redfish, MCTP, or NC-SI protocols. On this basis, the BMC-specific test model, based on the identified hardware links and their matching management protocols, abandons preset fixed test templates and adaptively generates integrated hardware and software test cases deeply coupled with the current hardware topology. For instance, when adding an NVMe storage device to a server motherboard, the BMC-specific test model can identify its link characteristics without manual intervention and automatically generate test cases for the newly added hardware link. The generated test cases cover hardware link test items and associated management protocol test items, which can simultaneously verify the correctness of the hardware physical layer state and the compliance of the BMC software layer response, thereby achieving complete coverage of hardware and software collaboration scenarios.

[0088] S203. Based on integrated hardware and software test cases, perform joint automated testing of the hardware link and management protocol of BMC.

[0089] For example, the test device 11 sequentially executes each test item in the test case set, applying test stimuli to the BMC and its managed hardware links according to the test step sequence defined in the test item. It simultaneously collects hardware link status data and management protocol response data during the test, performs consistency verification on these two types of data, and determines whether the test execution passes based on the verification result. After the test is completed, the test device 11 can also archive and store the test results and related data for subsequent analysis and model optimization.

[0090] In this embodiment, the general large model is fine-tuned using a vertical domain knowledge base, enabling the BMC-specific test model to have full-domain adaptability to multiple types of scalable BMC hardware links. Furthermore, the BMC-specific test model automatically identifies and adapts to multiple types of hardware links, dynamically expanding test cases without requiring manual reconstruction of the test framework, significantly reducing test case maintenance costs and improving compatibility with different hardware links. Secondly, through integrated hardware and software testing, the hardware link status and management protocol response are simultaneously verified, ensuring the test process covers hardware and software collaboration scenarios, accurately locating hardware and software coupling faults, reducing the risk of misjudgment, and thus improving the accuracy of test results. In addition, combined with a fully automated testing mechanism, from automatic hardware link identification and adaptive test case generation to integrated test execution, no manual intervention is required, improving testing efficiency.

[0091] In some embodiments, multidimensional operational data includes link layer data reflecting the physical hardware links, topology description data reflecting device configuration, and management protocol interaction data.

[0092] Among them, link layer data is used to parse the physical characteristics of hardware links, topology description data is used to reconstruct the mounting relationships of hardware components, and management protocol interaction data is used to extract protocol rules.

[0093] like Figure 3 A flowchart illustrating the BMC automated testing method based on a large model provided in this application embodiment. Figure 2 As shown, the BMC-specific test model is specifically used for:

[0094] S301. Parse the link layer data to identify all hardware links managed by the BMC.

[0095] For example, the link layer data includes a list of slave devices obtained by scanning the I2C bus via IPMI commands, device identification information obtained by reading from the PCIe configuration space, and storage device information obtained via the NVMe Admin Command. The BMC-specific test model performs semantic parsing on the above link layer data. It extracts the bus number and the address of the mounted slave device from the I2C bus scan results, identifies the sensor type based on the device address range (e.g., devices in the address range of 0x30 to 0x3F are identified as voltage sensors, and devices in the address range of 0x40 to 0x4F are identified as temperature sensors); it reads the Vendor ID and Device ID fields of each device from the PCIe configuration space data to identify the PCIe device type (e.g., Vendor ID 0x8086 corresponds to an Intel device, and Device ID 0x2020 corresponds to an NVMe controller); and it extracts hard drive health status, temperature, and capacity parameters from the NVMe Admin Command response. Through comprehensive analysis of the above link layer data, the BMC special test big model identifies a complete list of hardware links managed by BMC, including the bus type, device address, device category and communication rate of each link.

[0096] S302. Based on the physical layer characteristics and link layer protocol characteristics of each hardware link, classify and identify all hardware links to obtain multiple classified hardware links.

[0097] This step involves categorizing the identified hardware links to facilitate more refined processing and test case generation in the future.

[0098] For example, the BMC special test large model analyzes the physical layer characteristics of each hardware link, including signal level standards, drive capabilities, and physical connection methods, distinguishing between I2C bus and SMBus bus; it analyzes the link layer protocol characteristics of each hardware link, including data frame format, addressing mode, and flow control mechanism, distinguishing between PCIe link and NVMe link; based on bus type and protocol characteristics, all identified hardware links are classified into categories such as I2C sensor link, SMBus management link, PCIe device link, and NVMe storage link.

[0099] Optionally, for each hardware link, the BMC-specific test model further identifies its master-slave relationship. For example, in the I2C bus, the BMC acts as the master controller and the sensor acts as the slave device; in the PCIe link, the Root Complex acts as the root node and the Endpoint device acts as the end node.

[0100] S303. Perform semantic understanding on the topology description data, and reconstruct the hierarchical topology relationship between hardware components by combining multiple classified hardware links.

[0101] This step constructs a complete, hierarchical hardware topology by associating abstract configuration information with the actual identified hardware links.

[0102] For example, natural language processing or structured data parsing is performed on topology description data (such as device tree files and SMBIOS tables) to extract information such as the name, model, connection port, and parent-child relationships of hardware components. This information is then matched with the categorized hardware links. Alternatively, the BMC-specific test model utilizes graph neural networks to model the topology description data, treating hardware components as nodes and connections as edges. By combining this with the actual connection information parsed from the link layer data, the initial topology graph is corrected and improved. Through the above processing, a complete hierarchical topology relationship containing parent-child relationships, mounting relationships, master-slave relationships, and data flow directions is finally output.

[0103] S304. Extract the link feature parameters of each hardware link from the multiple hardware links after classification. The link feature parameters include at least one of the following: topology parameters, transmission characteristic parameters, and operating status parameters.

[0104] The purpose of this step is to provide detailed attribute descriptions for each specific hardware link, thereby providing a basis for subsequent management protocol matching and test case generation.

[0105] For example, the BMC special test large model can extract link characteristic parameters from the link layer data parsing results and topology description data. Topology parameters may include the starting device, ending device, connection port, bus ID, device address, etc.; transmission characteristic parameters may include the maximum transmission rate, data bit width, timing requirements, error rate, etc.; and operating status parameters may include the current bandwidth usage, error count, power status, temperature, etc.

[0106] S305. The protocol format of the management protocol interaction data is identified, and the corresponding management protocol type is dynamically matched for each hardware link based on the identified protocol feature fields and link feature parameters.

[0107] This step essentially determines which management protocol should be used for communication and control of each hardware link, ensuring that test cases can interact with the hardware using the correct management protocol.

[0108] For example, the BMC-specific test model can perform deep packet inspection on management protocol interaction data to identify the protocol type (such as IPMI, Redfish, SMBus, PMBus, etc.) and key fields (such as command words, function codes, data lengths, and checksums). Then, it combines this with the link characteristic parameters from step S304 for matching, thereby dynamically matching the corresponding management protocol type for each hardware link. For example, it matches the IPMI protocol to a sensor link on the I2C bus, the Redfish protocol to a device supporting Redfish, and the MCTP protocol to a device supporting MCTP over PCIe. Finally, the BMC-specific test model establishes a mapping relationship between link identifier, device type, physical address, and management protocol type for each hardware link.

[0109] Alternatively, the BMC-specific test model can utilize a sequence model based on the Transformer architecture to learn from the management protocol interaction data, automatically identify protocol types and feature fields, and learn the correlation between link feature parameters and protocol types to achieve dynamic matching.

[0110] S306. Based on the classified multiple hardware links, hierarchical topology relationships and management protocol types, adaptively generate integrated hardware and software linkage test cases that adapt to the hardware link topology.

[0111] For example, test case logic can be automatically constructed using template generation or rule-based reasoning. Alternatively, the BMC-specific test model can utilize reinforcement learning or genetic algorithms to search and combine existing test case libraries, or generate new test cases from scratch.

[0112] The BMC specialized testing model outputs the generated test cases in a structured format. Each test case includes a test case identifier, test objective, preconditions, test step sequence, expected result, associated hardware link identifier, and associated management protocol type.

[0113] This application embodiment provides a comprehensive and structured input for the BMC-specific test model by clearly defining the specific composition of multi-dimensional operational data. The BMC-specific test model then performs refined data processing and information integration on the multi-dimensional operational data, thereby accurately identifying the hardware links managed by the BMC, accurately reconstructing the hardware topology, and dynamically matching the correct management protocol for each hardware link. The resulting adaptively generated integrated hardware and software test cases not only cover the physical connections of the hardware but also accurately simulate the interactive behavior of the management protocol, significantly improving the accuracy, coverage, and diagnostic capabilities for complex hardware and software linkage faults.

[0114] It should be understood that if the generated test cases are only in the form of logical descriptions, they lack direct executability and require manual intervention to be converted into code, which leads to reduced testing efficiency, increased maintenance costs, and difficulty in quickly responding to changes in hardware links.

[0115] Furthermore, in some embodiments, based on the classified multiple hardware links, hierarchical topology relationships, and management protocol types, adaptive hardware-software integrated test cases adapted to the hardware link topology are generated, including:

[0116] Step 1.1: Based on the classified hardware links, hierarchical topology relationships and management protocol types, automatically generate test case logic for the linkage between hardware links and management protocols.

[0117] For example, the BMC-specific test model generates structured test case descriptions based on the identified specific hardware link characteristics. These descriptions include test objectives, preconditions, test step sequences, expected result judgment rules, and post-cleanup operations. For instance, for an identified temperature sensor link on the I2C bus, the test case logic generated by the model includes: the test objective is to verify the accuracy of the temperature sensor readings and the consistency of the BMC's reporting via the IPMI protocol; the preconditions are that the BMC is operating normally and the sensor link communication is normal; the test steps include triggering a temperature change, reading the actual value from the hardware sensor, obtaining the BMC's reported value via IPMI commands, and comparing the differences; the expected result is that the difference is within the allowable error range; and the post-cleanup is to restore the sensor to normal operating status.

[0118] Step 1.2: Load the configured BMC-specific testing framework and target programming language to convert the test case logic into executable automated test code.

[0119] The BMC-specific testing framework is a pre-packaged code library containing commonly used BMC testing functions, such as the IPMITool wrapper library, Redfish API client library, PCIe configuration space access library, and sensor data acquisition library. These libraries provide standardized API interfaces for test code to call. The target programming language can be pre-set according to the test execution environment configuration, including languages ​​such as Python, Shell, or Go.

[0120] For example, the BMC-specific test model loads a BMC-specific test framework and a preset target programming language that match the current test environment, automatically converting the above test case logic into executable automated test code.

[0121] Step 1.3: Use the automated test code as integrated hardware and software test cases.

[0122] Through the above process, the BMC specialized testing model achieves end-to-end transformation from test case logic described in natural language to executable automated test code, without requiring manual intervention to write or rewrite code. The generated automated test code is encapsulated as an independent test module and output as a hardware-software integrated test case to the test execution engine for execution in subsequent step S203.

[0123] This embodiment significantly reduces the development and maintenance costs of test scripts by automatically converting large models into code, while ensuring a high degree of consistency between the generated code and the test case logic. This avoids test deviations caused by human coding errors and further improves the efficiency and reliability of BMC automated testing.

[0124] In some embodiments, the BMC automated testing method based on large models further includes:

[0125] Step 2.1: Obtain the test results of the joint automated test. The test results include hardware link status data, management protocol response data, abnormal event logs, and test execution records.

[0126] The hardware link status data reflects the real-time physical status of each hardware link during the test, including sensor readings, bus communication quality, link connectivity, and signal integrity metrics. The management protocol response data includes request messages sent to the BMC via protocol commands and response messages received during the test, including protocol version, response time, returned data, and error codes. The exception event log includes all exception events that occur during the test, including event occurrence time, exception type, error description, and associated test cases. The test execution record includes a list of executed test cases, the execution time of each test case, and the execution results.

[0127] For example, test results of joint automated tests can be automatically captured through the built-in logging module of the testing framework, or test results of joint automated tests can be obtained through real-time data interaction with the BMC interface.

[0128] Step 2.2: Input the test results into the BMC special test model. The BMC special test model performs semantic analysis and trend judgment on the test results and generates a test report. The test report includes hardware link operation status assessment, protocol compatibility analysis and optimization suggestions.

[0129] Understandably, this step utilizes the powerful semantic understanding and reasoning capabilities of the BMC-specific test model to perform in-depth processing and interpretation of the test results.

[0130] For example, by analyzing hardware link status data, the operational characteristics of each hardware link during the testing process can be identified, including link stability indicators, frequency of anomalies, and trends in status changes, thus forming a hardware link operational status assessment. For instance, the model can determine whether there are intermittent communication interruptions on the bus by analyzing the sensor reading change curves on the I2C bus; and assess link transmission quality by analyzing the error counter changes of the PCIe link.

[0131] Secondly, the model performs protocol compatibility analysis on the management protocol response data. By parsing the returned data, error codes, and response times in the protocol response messages, the model evaluates the interaction compliance between each hardware link and its matching management protocol. For example, the model analyzes whether the protocol response is consistent with the actual state of the hardware link, whether the protocol processing time is within the expected range, whether the error codes match abnormal scenarios, and identifies protocol compatibility issues or BMC firmware implementation defects. For instance, if in a test the actual reading of the hardware sensor is 80℃, but the BMC returns a reading of 0℃ via the IPMI protocol, the model determines that there is an anomaly in protocol compatibility and marks possible data acquisition or protocol parsing errors.

[0132] Finally, based on the above analysis and its built-in fault mode knowledge base, the model outputs optimization suggestions for the current test results. These suggestions are not limited to hardware configuration optimization, protocol parameter adjustment, and test strategy optimization. For example, if the model detects frequent communication timeouts on an I2C bus, it may suggest checking the slave device address configuration or bus load; if the model detects a persistently high response time for a Redfish resource, it may suggest optimizing the resource query logic in the BMC firmware.

[0133] Step 2.3: Update the BMC vertical domain knowledge base based on the test results and test report.

[0134] For example, the test results are structured to extract newly added hardware link characteristic parameters, such as newly discovered sensor types, newly identified bus topology relationships, and newly emerging communication rate specifications, and these are incorporated into the hardware characteristic parameter library of the BMC vertical domain knowledge base. Secondly, newly discovered protocol interaction modes, newly emerging error codes, and corresponding handling solutions are updated to the management protocol rule library of the BMC vertical domain knowledge base. Thirdly, valid fault cases confirmed in the test report, along with their root cause analysis and optimization suggestions, are recorded as typical cases in the fault mode library of the BMC vertical domain knowledge base. For instance, if a specific fault mode of a new type of temperature sensor is discovered in this test (such as a specific register address returning an error value at high temperatures), this fault mode and its characteristics will be structured and stored in the BMC vertical domain knowledge base for reference in subsequent tests. Through these updates, the BMC vertical domain knowledge base continuously accumulates new hardware link characteristics, management protocol interaction rules, and fault diagnosis experience, and its knowledge coverage expands continuously with testing practice.

[0135] Step 2.4: Based on the updated BMC vertical domain knowledge base, fine-tune the BMC-specific test model.

[0136] For example, based on the updated BMC vertical domain knowledge base, the currently used BMC-specific test model is incrementally fine-tuned, enabling the model to continuously learn new knowledge and enhance its ability to identify new hardware links and diagnose new fault modes.

[0137] It should be understood that the purpose of fine-tuning is to enable the large model to perform semantic analysis and trend judgment more accurately, and to generate more precise test cases and optimization suggestions, thereby enhancing its generalization ability in the ever-changing BMC testing environment.

[0138] Step 2.5: Use the finely tuned BMC special test model to update the integrated hardware and software test cases.

[0139] For example, the historical test case set in the current test case library is input into the fine-tuned BMC-specific test model, and the model performs the following iterative update operations:

[0140] Based on its enhanced hardware link cognition and protocol rule understanding capabilities, the model performs quality assessment on each historical test case. The assessment dimensions include, for example, the degree of matching between the test case and the current hardware link topology and the completeness of the test scenario coverage.

[0141] For coverage blind spots and newly added hardware features identified during the evaluation, supplementary test cases are generated. For example, if the BMC vertical domain knowledge base adds feature parameters of the CXL memory extension link, the fine-tuned BMC specialized test model can generate connectivity tests, bandwidth stress tests, and hot-plug test cases for that hardware link; if the BMC specialized test model identifies a protocol compatibility issue in the test report analysis in step 2.2, it can generate specialized verification test cases for that protocol scenario.

[0142] The retained historical test cases and newly generated supplementary test cases are integrated and optimized. The dependencies and execution order between test cases are analyzed to eliminate redundancy and duplication. Test cases that can be executed in parallel are grouped to optimize the overall efficiency of test execution. At the same time, based on the failure detection rate and execution cost of each test case in historical test data, the test cases are prioritized and high-value test cases are executed first to ensure the highest failure detection rate within the limited test time.

[0143] In this embodiment, a closed-loop iterative optimization mechanism enables the BMC-specific test model to continuously adapt to hardware link expansion requirements, thereby improving the synchronization between the test case set and the actual operating environment and technology iteration of BMC. This greatly improves the adaptability and effectiveness of test cases, reduces manual maintenance costs, and significantly enhances the intelligence level and test quality of the entire BMC automated testing system.

[0144] Furthermore, Figure 4 A flowchart illustrating the BMC automated testing method based on a large model provided in this application embodiment. Figure 3 .

[0145] like Figure 4 As shown, based on integrated hardware and software test cases, joint automated testing of the BMC's hardware link and management protocol is performed, specifically including:

[0146] S401. Based on integrated hardware and software test cases, execute a full hardware link and protocol linkage test process.

[0147] S402. During test execution, for the currently executed target test case, synchronously acquire the hardware link status data and management protocol response data corresponding to the target test case.

[0148] For example, within the same time window during the execution of the target test case, hardware link status data and management protocol interaction data (i.e., management protocol response data) related to the target test case are collected in parallel. The hardware link status data reflects underlying information such as physical connections and device operating modes; the management protocol response data reflects the feedback from the BMC after performing management operations on the hardware through the protocol.

[0149] S403. Perform consistency verification on the hardware link status data and management protocol response data corresponding to the target test case, and generate consistency verification results. The consistency verification includes at least one of numerical consistency verification, status consistency verification and event consistency verification.

[0150] Numerical consistency verification compares the values ​​reported in the management protocol response data (such as temperature and voltage) with the values ​​actually read by the hardware sensors, using preset thresholds or ranges, to determine if they are within the allowable error range. State consistency verification verifies, by defining a state machine model, whether the actual state of the hardware link (such as online or offline, normal or faulty) matches the state reported by the management protocol (such as enabled or disabled, healthy or alarm). Event consistency verification analyzes protocol interaction logs and hardware event logs to confirm whether events triggered by the management protocol (such as power switching or firmware updates) have generated corresponding event records on the hardware side, and whether the event timestamps and content match.

[0151] For example, this target test case involves sending a command to the BMC via the IPMI protocol to set the fan speed to a target value (e.g., 50% of the maximum speed). While the BMC receives and processes this command, the test system simultaneously acquires two types of data: first, the actual fan speed monitored in real-time by hardware sensors (hardware link status data); and second, the IPMI response message returned from the BMC, which includes the fan speed reported by the BMC and the command execution status (management protocol response data). The test system then performs consistency checks on these two types of data. For example, it performs a numerical consistency check, comparing the actual speed with the speed reported by the BMC to see if they are within the allowable error range and comparing them with the target setting value; it performs a status consistency check, confirming whether the actual operating status of the fan (e.g., "running") is consistent with the status reported by the BMC; and it performs an event consistency check, checking whether there are event records in the BMC's event log related to this fan speed setting operation.

[0152] S404. Based on the consistency verification results, generate test results for the target test cases.

[0153] For example, based on the output of the consistency check, it is determined whether the currently executed target test case passes. Specifically, if all check items pass, the target test case passes; if any check fails, the target test case fails.

[0154] In this embodiment of the application, a software and hardware data consistency verification mechanism is used to ensure that the test results can accurately reflect the collaborative state of the hardware link and management protocol, effectively identify inconsistencies in software and hardware interaction, and significantly improve the reliability of test results and the accuracy of fault location.

[0155] In some embodiments, test results for the target test cases are generated based on the consistency verification results, including:

[0156] S404-1. If the consistency check result indicates that the check failed, the abnormal context information corresponding to the consistency check result is input into the BMC special test model. The BMC special test model intelligently classifies the abnormal type of the abnormal context information based on the built-in fault mode knowledge base to distinguish between intermittent environmental abnormalities and deterministic hardware failures. If the abnormal type is an intermittent environmental abnormality, a retest strategy is executed, and the test result of the target test case is determined based on the retest result. If the abnormal type is a deterministic hardware failure, the test result of the target test case is determined to be a test failure.

[0157] The phrase "when the consistency check result indicates that a check has failed" refers to the situation where, after performing consistency checks on the BMC's hardware link status data and management protocol response data, at least one check rule fails. The exception context information includes, but is not limited to: the specific content of the failed check item, the hardware link status data and management protocol response data at the time of the check failure, the test case execution log, the BMC's system log, environmental sensor data (such as temperature and voltage), and test environment configuration information.

[0158] Exception context information can be encapsulated in structured data formats (such as JSON, XML) or unstructured text and passed to the BMC special test model via API interface or message queue.

[0159] The fault mode knowledge base pre-stores a large number of known characteristic patterns of intermittent environmental anomalies and deterministic hardware failures. Through comparison and reasoning, the BMC-specific test model can accurately classify current abnormal events as either intermittent environmental anomalies or deterministic hardware failures.

[0160] For example, when the BMC-specific test model determines that an anomaly is environmentally intermittent, it indicates that the problem may not be a defect in the BMC itself, but rather a temporary issue caused by external factors. In this case, a retesting strategy is implemented to verify whether the anomaly will recur. Retesting strategies may include: immediately re-executing the target test case once or multiple times; re-executing after a certain delay; or re-executing after adjusting some test environment parameters (such as network bandwidth and power load). The retesting result can be determined based on the pass rate. For example, if the retest is successful, the original test case result can be corrected to pass; if the retest still fails, it is escalated to a deterministic hardware failure.

[0161] S404-2. If the consistency check result indicates that all check items have passed the check, the test result of the target test case is determined to be a test pass.

[0162] In this embodiment, an intelligent anomaly handling mechanism can accurately distinguish between occasional environmental anomalies and deterministic hardware failures, avoiding misjudgments and invalid retests caused by temporary environmental fluctuations, effectively reducing unnecessary damage to hardware, while ensuring that real faults are accurately identified and recorded, significantly improving the accuracy of test results and the robustness of test execution.

[0163] In some embodiments, the BMC automated testing method based on a large model further includes: obtaining the real-time status of the test environment corresponding to the BMC; and adjusting the consistency verification rules according to the real-time status.

[0164] For example, various sensors and monitoring interfaces deployed in the test environment are used to collect real-time status data from multiple dimensions of the test environment. The real-time status of the test environment includes, but is not limited to: network communication status, such as obtaining network latency, packet loss rate, and connection stability indicators between the test device and the BMC under test through ICMP protocol or TCP connection testing; power supply status, such as obtaining the input voltage, current, and power ripple parameters of the BMC under test through the power management module; temperature and humidity conditions, such as obtaining temperature and humidity data of the test room through environmental sensors; and load status, such as monitoring the CPU utilization, memory usage, and I / O load of the host corresponding to the BMC under test.

[0165] The essence of this embodiment is to dynamically modify or select the standard or threshold used for consistency verification based on the acquired real-time status to adapt to the current environmental conditions, thereby avoiding misjudgments caused by environmental changes. For example, a set of verification rules can be preset, containing sets of verification rules for different environmental states (such as high temperature, high load, network instability, etc.). When the real-time status matches a certain environmental condition, the test system automatically switches to the corresponding set of verification rules. Alternatively, an adaptive algorithm can be used to dynamically calculate the verification threshold based on real-time status data. For example, when the ambient temperature rises, the deviation range between hardware link status data and management protocol response data can be appropriately expanded. Furthermore, a machine learning model can be used to train historical test data and environmental data to learn the mapping relationship between environmental states and verification rules, thereby predicting and generating the optimal verification rules under new real-time conditions.

[0166] The embodiments of this application can effectively cope with the complexity and dynamism of the test environment, avoiding misjudgments or missed detections that may be caused by fixed verification rules when environmental conditions change, and significantly improving the accuracy and reliability of test results. Especially when performing joint automated testing of hardware links and management protocols, this dynamic adaptability ensures that the test system can more realistically evaluate the performance and stability of the BMC under various actual operating conditions, thereby improving the accuracy of fault location and the robustness of testing.

[0167] Figure 5 A schematic diagram of the structure of the BMC automated testing device based on a large model provided in this application embodiment. Figure 1 ,like Figure 5 As shown, the BMC automated testing device based on a large model provided in this embodiment includes: an acquisition module 51, a processing module 52, and a testing module 53. Wherein:

[0168] Module 51 is used to acquire multidimensional operational data of the BMC;

[0169] Processing module 52 is used to input multi-dimensional runtime data into the trained BMC-specific test model to generate integrated hardware and software test cases adapted to the hardware link topology. The BMC-specific test model is used to perform semantic parsing and feature extraction on the multi-dimensional runtime data, identify all hardware links managed by BMC and the management protocol type corresponding to each hardware link, and adaptively generate integrated hardware and software test cases for BMC. The BMC-specific test model is a domain-specific model obtained by deep fine-tuning the general model based on the BMC vertical domain knowledge base.

[0170] Test module 53 is used to perform joint automated testing of the hardware link and management protocol of BMC based on integrated hardware and software test cases.

[0171] In one possible implementation, the processing module 52 is specifically used for: parsing the link layer data to identify all hardware links managed by the BMC; classifying and identifying all hardware links according to the physical layer characteristics and link layer protocol characteristics of each hardware link to obtain multiple classified hardware links; performing semantic understanding on the topology description data and reconstructing the hierarchical topology relationship between hardware components by combining the multiple classified hardware links; extracting the link feature parameters of each hardware link from the multiple classified hardware links, the link feature parameters including at least one of topology parameters, transmission characteristic parameters, and operating status parameters; identifying the protocol format of the management protocol interaction data, and dynamically matching the corresponding management protocol type for each hardware link according to the identified protocol feature fields and link feature parameters; and adaptively generating integrated hardware and software linkage test cases adapted to the hardware link topology based on the multiple classified hardware links, hierarchical topology relationship, and management protocol type.

[0172] In one possible implementation, the processing module 52 is further configured to: automatically generate test case logic for the linkage between hardware links and management protocols based on the classified multiple hardware links, hierarchical topology relationships and management protocol types; load the set BMC-specific test framework and target programming language to convert the test case logic into executable automated test code; and use the automated test code as integrated hardware and software linkage test cases.

[0173] In one possible implementation, the processing module 52 is further configured to: acquire test results from joint automated testing, including hardware link status data, management protocol response data, exception event logs, and test execution records; input the test results into the BMC-specific test model, perform semantic analysis and trend judgment on the test results through the BMC-specific test model, and generate a test report, including hardware link operation status assessment, protocol compatibility analysis, and optimization suggestions; update the BMC vertical domain knowledge base based on the test results and test report; fine-tune the BMC-specific test model based on the updated BMC vertical domain knowledge base; and update the integrated hardware and software test cases using the fine-tuned BMC-specific test model.

[0174] In one possible implementation, the test module 53 is specifically used to: execute a full hardware link and protocol linkage test process based on integrated hardware and software test cases; during the test execution, for the currently executed target test case, synchronously acquire the hardware link status data and management protocol response data corresponding to the target test case; perform consistency verification on the hardware link status data and management protocol response data corresponding to the target test case, and generate a consistency verification result, wherein the consistency verification includes at least one of numerical consistency verification, status consistency verification and event consistency verification; and generate test results for the target test case based on the consistency verification result.

[0175] In one possible implementation, the testing module 53 is further configured to: input the abnormal context information corresponding to the consistency verification result into the BMC special testing model when the consistency verification result indicates that a verification has failed; the BMC special testing model intelligently classifies the abnormal type of the abnormal context information based on the built-in fault mode knowledge base to distinguish between intermittent environmental abnormalities and deterministic hardware failures; if the abnormal type is an intermittent environmental abnormality, a retesting strategy is executed, and the test result of the target test case is determined based on the retesting result; if the abnormal type is a deterministic hardware failure, the test result of the target test case is determined to be a test failure; if the consistency verification result indicates that all verification items have passed, the test result of the target test case is determined to be a test pass.

[0176] like Figure 6As shown, in one possible implementation, the BMC automated testing device 50 based on the large model further includes an adjustment module 54, which is used to: obtain the real-time status of the test environment corresponding to the BMC; and adjust the verification rules of the consistency check according to the real-time status.

[0177] The BMC automated testing device based on a large model provided in this embodiment can execute the methods provided in the above-described method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0178] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7 As shown, the electronic device 70 provided in this embodiment (the electronic device 70 is...) Figure 1 The test device 11) includes at least one processor 701 and a memory 702. Optionally, the electronic device 70 also includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus 704.

[0179] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to perform the above-described method.

[0180] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0181] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0182] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0183] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0184] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0185] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0186] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0187] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0188] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0189] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0190] In addition, the functional units in the various embodiments of the present 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.

[0191] If a function is implemented as 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 this invention, or the part that contributes to the prior art, or a 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, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0192] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0193] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. An automated BMC testing method based on a large model, characterized in that, include: Acquire multi-dimensional operational data from the Baseboard Management Controller (BMC); The multidimensional operational data is input into the trained BMC-specific test model to generate integrated hardware and software test cases adapted to the hardware link topology. The BMC-specific test model is used to perform semantic parsing and feature extraction on the multidimensional operational data, identify all hardware links managed by the BMC and the management protocol type corresponding to each hardware link, and adaptively generate integrated hardware and software test cases for the BMC. The BMC-specific test model is a domain-specific model obtained by deep fine-tuning the general model based on the BMC vertical domain knowledge base. Based on the aforementioned integrated hardware and software test cases, joint automated testing of the hardware link and management protocol is performed on the BMC.

2. The BMC automated testing method based on a large model according to claim 1, characterized in that, The multi-dimensional operational data includes link layer data reflecting the physical hardware link, topology description data reflecting the device configuration, and management protocol interaction data. The BMC-specific test model is specifically used for: The link layer data is parsed to identify all hardware links managed by the BMC; Based on the physical layer characteristics and link layer protocol characteristics of each hardware link, the entire set of hardware links is classified and identified to obtain multiple classified hardware links. Semantic understanding is performed on the topology description data, and the hierarchical topology relationship between hardware components is reconstructed by combining the classified hardware links. Extract the link feature parameters of each hardware link from the multiple hardware links after classification. The link feature parameters include at least one of topology parameters, transmission characteristic parameters, and operating status parameters. The management protocol interaction data is identified by protocol format, and the corresponding management protocol type is dynamically matched for each hardware link based on the identified protocol feature fields and the link feature parameters. Based on the classified hardware links, the hierarchical topology, and the management protocol type, adaptive hardware and software integrated test cases are generated to match the hardware link topology.

3. The BMC automated testing method based on a large model according to claim 2, characterized in that, The process of adaptively generating integrated hardware and software test cases that adapt to the hardware link topology based on the classified hardware links, the hierarchical topology, and the management protocol type includes: Based on the classified hardware links, the hierarchical topology, and the management protocol type, test case logic for the linkage between hardware links and management protocols is automatically generated. Load the configured BMC-specific testing framework and target programming language, and transform the test case logic into executable automated test code; The automated test code is used as the integrated hardware and software test case.

4. The automated BMC testing method based on a large model according to any one of claims 1 to 3, characterized in that, Also includes: Obtain the test results of the joint automated test, which include hardware link status data, management protocol response data, abnormal event logs, and test execution records; The test results are input into the BMC-specific test model. The BMC-specific test model performs semantic analysis and trend judgment on the test results to generate a test report. The test report includes hardware link operation status assessment, protocol compatibility analysis and optimization suggestions. Update the BMC vertical domain knowledge base based on the test results and the test report; Based on the updated BMC vertical domain knowledge base, the BMC-specific test model was fine-tuned. The hardware and software integrated test cases were updated using the finely tuned BMC-specific test model.

5. The automated BMC testing method based on a large model according to any one of claims 1 to 3, characterized in that, The joint automated testing of the BMC based on the integrated hardware and software test cases includes: Based on the aforementioned integrated hardware and software test cases, a full hardware link and protocol linkage test process is executed. During test execution, for the currently executing target test case, the hardware link status data and management protocol response data corresponding to the execution of the target test case are simultaneously acquired; The hardware link status data and management protocol response data corresponding to the target test case are subjected to consistency verification, and a consistency verification result is generated. The consistency verification includes at least one of numerical consistency verification, status consistency verification and event consistency verification. Based on the consistency verification results, test results are generated for the target test case.

6. The BMC automated testing method based on a large model according to claim 5, characterized in that, The step of generating test results for the target test case based on the consistency verification result includes: If the consistency check result indicates that a check has failed, the abnormal context information corresponding to the consistency check result is input into the BMC-specific test model. The BMC-specific test model intelligently classifies the abnormal type of the abnormal context information based on its built-in fault mode knowledge base to distinguish between intermittent environmental anomalies and deterministic hardware failures. If the abnormal type is an intermittent environmental anomaly, a retesting strategy is executed, and the test result of the target test case is determined based on the retesting result. If the abnormal type is a deterministic hardware failure, the test result of the target test case is determined to be a test failure. If the consistency check result indicates that all check items have passed the check, the test result of the target test case is determined to be a successful test.

7. The automated BMC testing method based on a large model according to claim 5, characterized in that, Also includes: Obtain the real-time status of the test environment corresponding to the BMC; Adjust the consistency verification rules based on the real-time status.

8. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the BMC automated testing method based on a large model as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed, are used to implement the BMC automated testing method based on a large model as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, It includes a computer program that, when executed, implements the BMC automated testing method based on a large model as described in any one of claims 1 to 7.

Images