SoC array server topology collaborative batch test closed-loop system and method

Abstract

The invention provides a batch test closed-loop system and method for SoC array server topology collaboration, belongs to the technical field of SoC array server production test, and aims to solve the problems that in a traditional SoC array server test, operation is needed one by one, batch test is difficult, abnormity is not recorded, and machine type adaptation is prone to errors. According to the scheme, a batch test closed-loop system comprising eight modules including a front-end interaction module, a server management module and a task scheduling engine module is constructed, server information is obtained and configured in batches through the server management module, resource conflicts and fault diffusion are dynamically processed through the task scheduling engine, a test execution module asynchronously executes a customizable test plan, and the test efficiency is improved. The topology verification module verifies configuration in a cross-device mode, the exception processing module accurately processes exceptions, and the report generation and data archiving module completes result output and storage. According to the system, full-process collaborative control of the test is realized, the test systematicness and adaptability are improved, the server test reliability is guaranteed, and manual operation and configuration errors are reduced.

Description

Technical Field

[0001] This invention relates to the field of SoC array server production testing technology, specifically to a closed-loop system and method for batch testing of SoC array server topology collaboration. Background Technology

[0002] There are several pain points in the production testing of SoC array servers: First, testing multiple servers requires logging into the BMC control page for each one, making batch management impossible, and only one test task can be executed at a time, resulting in repetitive and inefficient operations; Second, although attempts have been made to automate the process through scripts, the scripts cannot handle abnormal situations during testing, and there are no records or reports after an anomaly, requiring manual login to the BMC to view the results; Third, each server requires importing scripts separately, making batch testing difficult; Fourth, the testing procedures and configurations for different server models need to be manually adjusted, and frequent modifications can easily lead to configuration errors, causing delays in delivery time and preventing the completion of production and delivery as planned.

[0003] To address this, a closed-loop system and method for batch testing of SoC array server topology collaboration is proposed. Summary of the Invention

[0004] The present invention aims to solve the problems mentioned in the background art by providing a closed-loop system and method for batch testing of SoC array server topology collaboration.

[0005] The specific technical solution is as follows: A batch testing closed-loop system for SoC array server topology collaboration includes a front-end interaction module, a server management module, a task scheduling engine, a test execution module, a topology verification module, an exception handling module, a report generation module, and a data archiving module. The front-end interaction module is connected to the server management module, the task scheduling engine, and the report generation module respectively, and is used to receive user operation instructions and display server test-related information. The server management module is connected to the task scheduling engine and the topology verification module respectively, and is used to obtain SoC array server information in batches and perform basic configuration. The task scheduling engine is connected to the test execution module and the exception handling module respectively, and is used for resource scheduling and queue management of test tasks; The test execution module is communicatively connected to the topology verification module and the report generation module, and is used to execute various test items of the SoC array server according to the test plan; The topology verification module is communicatively connected to the report generation module and is used to perform cross-device configuration verification and hardware status detection on the SoC array server. The exception handling module is communicatively connected to the report generation module and is used to handle exceptions during the testing process and record exception information. The report generation module is connected to the data archiving module and is used to generate test reports and trigger data archiving operations.

[0006] The aforementioned closed-loop system for batch testing of SoC array server topology collaboration includes a server management module comprising an information acquisition unit, a configuration execution unit, and a model adaptation unit. The information acquisition unit is used to add SoC array servers in batches and acquire their SN, MAC address, hardware configuration, and network information. The configuration execution unit is used to perform batch IP settings, test environment installation and uninstallation, power control, and factory reset on multiple SoC array servers. The model adaptation unit is used to generate corresponding test call strategies based on the SoC array server model.

[0007] The aforementioned closed-loop system for batch testing of SoC array server topology collaboration includes a task scheduling engine comprising a resource awareness unit, a fault suppression unit, and an elastic scheduling unit. The resource awareness unit identifies hardware resource conflicts in concurrent test tasks and dynamically adjusts the test queue order to stagger the execution of conflicting test items. The fault suppression unit freezes associated test items on other servers with the same physical node and triggers cross-machine log correlation analysis when a test on a certain SoC array server fails. The elastic scheduling unit adjusts the execution priority of test tasks based on the test task load and server cluster power consumption status.

[0008] The aforementioned closed-loop batch testing system for SoC array server topology collaboration includes a test execution module comprising a plan creation unit, a task execution unit, and a task control unit. The plan creation unit allows users to select commonly used test processes or customize test processes, where test processes can freely combine test items, set the number of tests, and the test execution time. The task execution unit executes the test plan asynchronously using a queue, progressively calling the test methods of the SoC array server. The task control unit allows users to cancel, delete, or continue executing test tasks.

[0009] The aforementioned closed-loop system for batch testing of SoC array server topology collaboration includes a topology verification module comprising a conflict detection unit, a remnant cleanup unit, and a power supply testing unit. The conflict detection unit analyzes the physical connections of SoC array servers in the same batch using a topology map, verifying the uniqueness of the SN and MAC addresses within the subnet and the correctness of the IP configuration. The remnant cleanup unit uses a signature comparison algorithm to scan the storage media of the SoC array servers and, combined with a preset secure hash library, removes residual data from the test environment. The power supply testing unit simulates mains power fluctuation scenarios, detects the response latency and recovery stability of the server power module, and generates a power quality score.

[0010] The aforementioned closed-loop system for batch testing of SoC array server topology collaboration includes an anomaly handling module comprising a retry control unit, a specification adjustment unit, and a defect marking unit. The retry control unit sets the corresponding number of retries based on the test error type. After the first test fails, the specification adjustment unit reduces the test load specification for a second test. When the degradation test passes, the defect marking unit marks the SoC array server as having a critical state defect and synchronizes this information to the report generation module.

[0011] The aforementioned closed-loop system for batch testing of SoC array server topology collaboration includes a report generation module comprising a log recording unit, a format export unit, and an email sending unit. The log recording unit records all information and exception details during the testing process. The format export unit supports exporting test reports to Word or PDF formats. The email sending unit can send test reports to a specified email address.

[0012] The aforementioned closed-loop system for batch testing of SoC array server topology collaboration includes a data archiving module comprising a data uploading unit and a storage unit. The data uploading unit automatically uploads the server's shipment data after the SoC array server passes testing and final inspection. The storage unit is used for long-term storage of test reports, inspection records, and server shipment data.

[0013] This invention also provides a batch testing method for SoC array server topology collaboration based on the above-mentioned SoC array server topology collaboration closed-loop system, comprising the following steps: Step 1: Send instructions to the server management module through the front-end interaction module to import the IP information of the SoC array server in batches and obtain detailed server data. The server management module generates a test call strategy based on the server model. Step 2: Create a test plan in the task scheduling engine through the front-end interaction module, select the target SoC array server and test process, and set the test parameters; Step 3: The task scheduling engine performs resource conflict analysis on the test plan, allocates test tasks to the corresponding task queues, and triggers the test execution module; Step 4: The test execution module calls the test method of the SoC array server according to the test plan, and the exception handling module monitors the test process in real time and handles exceptions. Step 5: After the test is completed, the topology verification module performs cross-device configuration verification and hardware status detection on the SoC array server; Step 6: The report generation module generates a test report based on the test data and verification results, which can be exported or sent via email; Step 7: After the SoC array server passes all tests, the data archiving module automatically uploads and stores the server's test report and shipping data.

[0014] The aforementioned SoC array server topology collaborative batch testing method, in step 2, employs a two-parameter driven logic to formulate the test plan during test plan creation. The first parameter is the machine model feature code; the system matches the corresponding test template based on the number of CPU cores, GPU model, and number of network cards of the SoC array server. The second parameter is a dynamic load threshold; the system monitors the power consumption and heat dissipation status of the server cluster in real time. When the total power consumption of the rack approaches the critical value, high-load test items are delayed, and low-load test items are executed first. The present invention has the following beneficial effects: 1. Solve the problem of low efficiency in traditional batch testing: Through batch configuration of the server management module (no need to import scripts and log in to BMC for each machine) and concurrent processing of the task scheduling engine (multiple test plans are executed asynchronously), the repetitive manual operations in the traditional solution are avoided, and the various test links are integrated into a closed loop, improving the systematicness and continuity of SoC array server testing.

[0015] 2. Preventing the spread of test failures and configuration risks: When a single server fails to test, the fault suppression unit of the task scheduling engine can freeze the associated test items of other servers on the same physical node to prevent common hardware defects from causing batch test failures; the cross-device configuration check of the topology verification module (such as MAC conflict verification within the subnet) avoids cross-device configuration errors missed in traditional single-machine checks, ensuring stable operation of the server after it leaves the factory.

[0016] 3. Enhance testing flexibility and result accuracy: Supports custom test processes and task interventions (cancel or continue testing) to adapt to different testing scenarios; the degradation test (not simple retry) of the exception handling module can accurately identify critical state defects of the equipment, avoiding misjudgments caused by only judging "on / off" in traditional solutions, making test results more comprehensive and providing a reliable basis for shipment judgment.

[0017] 4. Optimize test management and traceability capabilities: The report generation module records all test information and anomaly details, solving the problem of scattered and difficult-to-search logs in traditional script testing; the long-term storage function of the data archiving module forms a complete test data archive, which facilitates subsequent traceability of product quality, analysis of root causes of problems, and provides data support for production process optimization.

[0018] 5. Enhanced multi-model compatibility and load stability: Test templates are automatically matched based on "model feature codes", eliminating the need for manual adjustment of test processes for different server models and improving model compatibility; "Dynamic load threshold" adjusts task priority according to cluster power consumption, avoiding rack power consumption exceeding critical values ​​due to concentrated execution of high-load test items, and ensuring test process stability. Attached Figure Description

[0019] Figure 1 The flowchart illustrates the workflow of a batch testing closed-loop system for SoC array server topology collaboration provided in this embodiment of the invention. Detailed Implementation

[0020] The technical solution of the present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0021] The accompanying drawings are for illustrative purposes only and are schematic diagrams, not actual images. They should not be construed as limiting the scope of this application. To better illustrate the embodiments of the present invention, some parts in the drawings may be omitted, enlarged, or reduced, and do not represent the actual dimensions of the product. It is understandable to those skilled in the art that some well-known structures and their descriptions may be omitted in the drawings.

[0022] In the accompanying drawings of the embodiments of the present invention, the same or similar reference numerals correspond to the same or similar components. In the description of the present invention, it should be understood that if terms such as "upper," "lower," "left," "right," "inner," and "outer" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, the terms used to describe positional relationships in the drawings are only for illustrative purposes and should not be construed as limiting the present application. For those skilled in the art, the specific meaning of the above terms can be understood according to the specific circumstances.

[0023] In the description of this invention, unless otherwise explicitly specified and limited, the term "connection" or similar designation indicating a connection between components should be interpreted broadly. For example, it can refer to a fixed connection, a detachable connection, or an integral part; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can refer to the internal communication between two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0024] Example 1 The SoC array server topology collaborative batch testing closed-loop system provided in this embodiment, such as Figure 1 As shown, it includes: front-end interaction module, server management module, task scheduling engine, test execution module, topology verification module, exception handling module, report generation module, and data archiving module; The front-end interaction module communicates with the server management module, task scheduling engine, and report generation module to receive user operation commands and display server test-related information. The server management module communicates with the task scheduling engine and the topology verification module respectively, and is used to obtain SoC array server information in batches and perform basic configuration. The task scheduling engine communicates with the test execution module and the exception handling module respectively, and is used for resource scheduling and queue management of test tasks; The test execution module is connected to the topology verification module and the report generation module respectively, and is used to execute various test items of the SoC array server according to the test plan; The topology verification module communicates with the report generation module to perform cross-device configuration verification and hardware status detection on the SoC array server. The exception handling module communicates with the report generation module to handle exceptions during the testing process and record exception information; The report generation module communicates with the data archiving module to generate test reports and trigger data archiving operations.

[0025] The system architecture constructed by this solution integrates all aspects of SoC array server testing into a closed loop by clearly defining the functions and communication connections of eight modules, including front-end interaction, server management, and task scheduling engine. On the one hand, it achieves full-process collaborative management from server addition and test execution to report archiving, eliminating the need for individual operation on a single server and solving the problems of repeated logins and process breaks in traditional solutions when testing multiple servers. On the other hand, the communication connections between modules ensure the real-time flow of test information. For example, anomaly information can be synchronized to the report generation module, and topology verification results can support report generation, avoiding the shortcomings of traditional script testing where anomalies are not recorded and results need to be manually queried. Overall, it improves the systematicness and consistency of SoC array server testing.

[0026] Specifically, in this embodiment, the server management module includes an information acquisition unit, a configuration execution unit, and a model adaptation unit; the information acquisition unit is used to add SoC array servers in batches and acquire the server's SN, MAC, hardware configuration, and network information; the configuration execution unit is used to perform batch IP settings, test environment installation and uninstallation, power control, and factory settings restoration for multiple SoC array servers; the model adaptation unit is used to generate corresponding test call strategies based on the model of the SoC array server.

[0027] The server management module is designed with three units: information acquisition, configuration execution, and model adaptation. First, the information acquisition unit acquires server information such as SN and MAC addresses in batches, eliminating the need for manual entry for each server and reducing the workload and error rate of information collection. Second, the configuration execution unit performs operations such as batch IP setting and test environment installation, avoiding the repetitive operations of importing scripts and configuring each server individually in traditional solutions, thus improving the efficiency of basic configuration. Third, the model adaptation unit generates corresponding test call strategies based on the server model, solving the problem of manually adjusting test processes and configurations for different models in traditional solutions, enhancing the system's adaptability to different SoC array server models, and reducing test errors caused by improper model adaptation.

[0028] Specifically, in this embodiment, the task scheduling engine includes a resource awareness unit, a fault suppression unit, and an elastic scheduling unit. The resource awareness unit is used to identify hardware resource conflicts in concurrent test tasks and dynamically adjust the test queue order to execute conflicting test items at off-peak times. The fault suppression unit is used to freeze associated test items of other servers on the same physical node and trigger cross-machine log correlation analysis when a test of a certain SoC array server fails. The elastic scheduling unit is used to adjust the execution priority of test tasks according to the test task load and the power consumption status of the server cluster.

[0029] The task scheduling engine's three units function in three aspects: resource utilization, fault control, and load adaptation. The resource awareness unit identifies resource conflicts and adjusts queues for staggered execution, avoiding test lag or failure caused by hardware resource contention (such as storage bandwidth and network resources) in traditional concurrent testing, thus improving resource utilization. The fault suppression unit freezes related test items on the same node and analyzes cross-machine logs when a single server test fails, preventing common hardware defects from causing batch test failures. It also quickly locates rack-level problems (such as blocked heat dissipation airflow), solving the problems of fault propagation and difficulty in finding the root cause in traditional solutions. The elastic scheduling unit adjusts task priorities based on load and power consumption, avoiding cluster power consumption exceeding critical values ​​caused by concentrated execution of high-load test items, and ensuring stable operation of the testing process.

[0030] Specifically, in this embodiment, the test execution module includes a plan creation unit, a task execution unit, and a task control unit. The plan creation unit allows users to select commonly used test processes or customize test processes, where test processes can freely combine test items, set the number of tests, and set the test execution time. The task execution unit executes the test plan in an asynchronous queue manner, gradually calling the test methods of the SoC array server. The task control unit allows users to cancel, delete, or continue the execution of test tasks.

[0031] The test execution module is designed to address the issues of poor flexibility and low execution efficiency in traditional testing: the plan creation unit supports common and custom test processes, and allows for the combination of test items, setting the number of times and time to meet the needs of different testing scenarios without having to rewrite scripts due to changes in test requirements; the task execution unit uses asynchronous queue execution to achieve parallel processing of multiple test plans, breaking the limitation of traditional solutions that can only execute one task at a time and improving test throughput; the task control unit supports task cancellation, deletion, or continuation, allowing testers to adjust the test process according to the actual situation, avoiding the problem of inflexible intervention after task start in traditional solutions, and enhancing the controllability of the testing process.

[0032] Specifically, in this embodiment, the topology verification module includes a conflict detection unit, a remnant cleanup unit, and a power supply testing unit. The conflict detection unit analyzes the physical connection relationship of SoC array servers in the same batch through a topology diagram, and verifies the uniqueness of the SN and MAC within the subnet and the correctness of the IP configuration. The remnant cleanup unit uses a signature comparison algorithm to scan the storage medium of the SoC array server and combines it with a preset secure hash library to clear residual data in the test environment. The power supply testing unit simulates a mains power fluctuation scenario, detects the response delay and recovery stability of the server power module, and generates a power quality score.

[0033] The topology verification module utilizes conflict detection, remnant cleanup, and power testing units. Firstly, the conflict detection unit analyzes cross-device connections using a topology diagram, verifying the uniqueness of SN / MAC / IP addresses. This not only checks individual machine information but also covers interconnected devices, preventing subsequent malfunctions caused by missed cross-device configuration conflicts (such as duplicate MAC addresses within a subnet) in traditional single-machine checks. Secondly, the remnant cleanup unit uses signature comparison and a secure hash library to remove residual data, resolving the issue of residual temporary scripts and log caches on boards after traditional testing, ensuring clean storage media at the time of server shipment. Thirdly, the power testing unit simulates mains power fluctuations to test power stability, overcoming the shortcomings of traditional testing that only checks whether the power supply is functioning correctly. This allows for the early detection of potential power supply problems in complex power environments, improving server quality at the time of shipment.

[0034] Specifically, in this embodiment, the exception handling module includes a retry control unit, a specification adjustment unit, and a defect marking unit; the retry control unit sets the corresponding number of retries according to the test error type; after the first test fails, the specification adjustment unit reduces the test load specification for a second test; when the degradation test passes, the defect marking unit marks that the SoC array server has a critical state defect and synchronizes the information to the report generation module.

[0035] The three units of the anomaly handling module optimize the inefficiency and crudeness of traditional anomaly handling: the retry control unit sets the number of retries according to the error type, eliminating the need for manual triggering of retries and reducing human intervention; the specification adjustment unit reduces the load for a second test after the first test fails, instead of simply repeating the operation, which can avoid misjudgment caused by the error of a single high-load test and more accurately identify the equipment status; the defect marking unit marks critical state defects and synchronizes them to the report, solving the problem of traditional solutions only judging the continuity of the test and omitting critical state equipment, making the test results more comprehensive and providing a more accurate basis for subsequent shipment judgment.

[0036] Specifically, in this embodiment, the report generation module includes a log recording unit, a format export unit, and an email sending unit; the log recording unit records all information and exception details during the testing process; the format export unit supports exporting the test report to Word or PDF format; and the email sending unit can send the test report to a specified email address.

[0037] The report generation module features logging, format export, and email sending functions. First, the logging unit records all test information and anomaly details, providing a complete basis for subsequent tracing of the test process and analysis of problems, avoiding the problems of fragmented and difficult-to-search logs in traditional solutions. Second, the format export unit supports Word and PDF formats to meet the archiving and viewing needs of different scenarios, eliminating the need for manual data processing to generate reports. Third, the email sending unit directly sends reports to a designated email address, eliminating the step of manual report delivery, improving report circulation efficiency, and ensuring that relevant personnel receive test results in a timely manner.

[0038] Specifically, in this embodiment, the data archiving module includes a data uploading unit and a storage unit; the data uploading unit automatically uploads the server's shipment data after the SoC array server passes testing and final inspection; the storage unit is used for long-term storage of test reports, inspection records, and server shipment data.

[0039] The data archiving module addresses the problems of chaotic and easily lost traditional test data management: the data upload unit automatically uploads shipment data after the server passes the test, eliminating the need for manual uploads and preventing data loss due to human error; the storage unit stores test reports, test records, and shipment data long-term, forming a complete test data archive. This facilitates subsequent retrieval of historical test records and tracing of product quality issues, while also providing data support for subsequent production optimization, thus improving the standardization and usability of test data management.

[0040] Example 2 This embodiment provides a batch testing method for SoC array server topology collaboration based on the SoC array server topology collaboration closed-loop system in Embodiment 1, such as... Figure 1 As shown, it includes the following steps: Step 1: Send instructions to the server management module through the front-end interaction module to import the IP information of the SoC array server in batches and obtain detailed server data. The server management module generates a test call strategy based on the server model. Step 2: Create a test plan in the task scheduling engine through the front-end interaction module, select the target SoC array server and test process, and set the test parameters; Step 3: The task scheduling engine performs resource conflict analysis on the test plan, allocates test tasks to the corresponding task queues, and triggers the test execution module; Step 4: The test execution module calls the test method of the SoC array server according to the test plan, and the exception handling module monitors the test process in real time and handles exceptions. Step 5: After the test is completed, the topology verification module performs cross-device configuration verification and hardware status detection on the SoC array server; Step 6: The report generation module generates a test report based on the test data and verification results, which can be exported or sent via email; Step 7: After the SoC array server passes all tests, the data archiving module automatically uploads and stores the server's test report and shipping data.

[0041] This testing method revolves around the process of "importing to the server - creating a plan - scheduling tasks - executing tests - topology verification - generating reports - data archiving". First, it connects each step to form a complete closed loop, covering the entire process from adding data from the server to the archive, avoiding the problems of disconnected steps and manual coordination required in traditional testing. Second, through steps such as batch importing servers and batch executing tests, it enables synchronous testing of multiple SoC array servers, reducing manual operations. Third, it monitors and handles anomalies in real time during the testing process, ensuring timely response to problems and preventing them from escalating. Overall, it makes the SoC array server testing process more standardized and more automated, reducing process deviations and errors caused by manual operations.

[0042] Specifically, in this embodiment, when creating a test plan in step 2, a dual-parameter driven logic is used to formulate a test scheme; the first parameter is the model feature code, and the system matches the corresponding test template according to the number of CPU cores, GPU model and number of network cards of the SoC array server; the second parameter is the dynamic load threshold, and the system monitors the power consumption and heat dissipation status of the server cluster in real time. When the total power consumption of the rack is close to the critical value, the high load test items are delayed and the low load test items are executed first.

[0043] The dual-parameter driven test plan development logic in this solution has two main aspects. First, the machine model feature code matches the test template based on the number of CPU cores, GPU model, etc., ensuring that servers with different hardware configurations can execute the corresponding necessary test items (such as GPU model memory aging test), avoiding test omissions or redundant tests caused by test items not matching the machine model in traditional solutions. Second, the dynamic load threshold adjusts the test priority based on the cluster power consumption and heat dissipation status, delaying high-load test items and prioritizing low-load tasks, avoiding test interruptions or equipment damage caused by the total power consumption of the rack approaching the critical value, ensuring the stability and security of the test process, while making the allocation of test resources more reasonable and improving the overall efficiency of the test.

[0044] In summary, the batch testing closed-loop system and method for SoC array server topology collaboration provided in this embodiment has the following advantages: 1. Solve the problem of low efficiency in traditional batch testing: Through batch configuration of the server management module (no need to import scripts and log in to BMC for each machine) and concurrent processing of the task scheduling engine (multiple test plans are executed asynchronously), the repetitive manual operations in the traditional solution are avoided, and the various test links are integrated into a closed loop, improving the systematicness and continuity of SoC array server testing.

[0045] 2. Preventing the spread of test failures and configuration risks: When a single server fails to test, the fault suppression unit of the task scheduling engine can freeze the associated test items of other servers on the same physical node to prevent common hardware defects from causing batch test failures; the cross-device configuration check of the topology verification module (such as MAC conflict verification within the subnet) avoids cross-device configuration errors missed in traditional single-machine checks, ensuring stable operation of the server after it leaves the factory.

[0046] 3. Enhance testing flexibility and result accuracy: Supports custom test processes and task interventions (cancel or continue testing) to adapt to different testing scenarios; the degradation test (not simple retry) of the exception handling module can accurately identify critical state defects of the equipment, avoiding misjudgments caused by only judging "on / off" in traditional solutions, making test results more comprehensive and providing a reliable basis for shipment judgment.

[0047] 4. Optimize test management and traceability capabilities: The report generation module records all test information and anomaly details, solving the problem of scattered and difficult-to-search logs in traditional script testing; the long-term storage function of the data archiving module forms a complete test data archive, which facilitates subsequent traceability of product quality, analysis of root causes of problems, and provides data support for production process optimization.

[0048] 5. Enhanced multi-model compatibility and load stability: Test templates are automatically matched based on "model feature codes", eliminating the need for manual adjustment of test processes for different server models and improving model compatibility; "Dynamic load threshold" adjusts task priority according to cluster power consumption, avoiding rack power consumption exceeding critical values ​​due to concentrated execution of high-load test items, and ensuring test process stability.

[0049] Working principle (I) System Architecture Collaboration Principle This system constructs a closed-loop testing system through the coordinated operation of eight modules: front-end interaction module, server management module, task scheduling engine, test execution module, topology verification module, exception handling module, report generation module, and data archiving module. 1. Command and Information Flow: The front-end interaction module serves as the user operation entry point, receiving user commands and transmitting them to the server management module and task scheduling engine, while displaying information such as test progress and results; the modules achieve real-time information synchronization through communication connections, such as the exception handling module synchronizing exception information to the report generation module, and the topology verification module using verification results to support report generation.

[0050] 2. Core module function linkage: 2.1 The server management module first obtains information such as server SN, MAC, and hardware configuration in batches, completes basic configurations such as IP settings and test environment installation, and then generates corresponding test strategies according to the machine model to lay the foundation for subsequent testing; 2.2 After receiving the test plan, the task scheduling engine identifies hardware resource conflicts (such as storage bandwidth contention) through the resource awareness unit and adjusts the queue for staggered execution. If a single server fails to test, the fault suppression unit freezes the test items associated with the same node and analyzes the cross-machine logs to prevent the fault from spreading. The elastic scheduling unit adjusts the task priority according to the cluster power consumption to avoid instability caused by high load. 2.3 The test execution module executes tests asynchronously according to the plan, and the exception handling module monitors in real time. When an exception is encountered, it retryes or reduces the load for a second test according to the error type and marks the critical state defect. 2.4 After the test is completed, the topology verification module analyzes the cross-device connection relationship through the topology diagram, verifies configuration conflicts, cleans up residual data, and tests power stability; the report generation module integrates the test data and verification results to generate a report, and finally triggers the data archiving module to store the data.

[0051] (II) Closed-loop principle of testing methods Based on the above system, the testing method forms a closed loop through a seven-step process and incorporates two-parameter driven logic: 1. Server initialization: Batch import IPs and obtain server data, and match the machine model testing strategy; 2. Plan Creation: Based on "machine model feature code" (matching test templates according to CPU core count, GPU model, etc.) and "dynamic load threshold" (adjusting task priority according to cluster power consumption), create custom or commonly used test plans; 3. Task scheduling: Analyze resource conflicts, allocate task queues, and trigger tests; 4. Test execution: Tests are executed asynchronously, and exceptions are handled in real time; 5. Topology verification: Cross-device configuration verification and hardware detection; 6. Report Generation: Export or send a report containing the full logs; 7. Data archiving: After passing the test, the data is automatically uploaded and stored, completing the closed loop.

[0052] How to use 1. Batch server initialization: Users input the IPs of multiple SoC array servers through the front-end interactive module, triggering the server management module to batch obtain the SN, MAC, hardware configuration and network information of each server; at the same time, the system automatically completes batch IP settings, test environment installation (or uninstallation), power control (such as power on, power off) and factory settings restoration, and automatically matches the corresponding test call strategy according to the server model.

[0053] 2. Test Plan Customization and Launch: Users select "Common Test Processes" (such as preset processes including barebone system testing and GPU aging tests) or "Custom Test Processes" (freely combine test items, set the number of tests and execution time) on the front end; the system automatically matches the appropriate test template based on the "model feature code" (such as automatically loading the video memory aging test for GPU models) and presets the load adaptation rules according to the "dynamic load threshold"; after confirmation, users launch the test plan through the front end.

[0054] 3. Testing process monitoring and intervention: After the test starts, the task scheduling engine automatically handles resource conflicts (such as off-peak execution of disk life test and network aging test), and the test execution module executes the test in an asynchronous queue manner. Users can view the test progress through the front end. If adjustments are needed, they can cancel, delete or continue the test task through the task control unit. If an abnormality occurs, the system will automatically retry or reduce the load for a second test without manual intervention, and mark the critical state defect.

[0055] 4. Cross-device verification and report acquisition: After the test is completed, the topology verification module runs automatically—checking the uniqueness of SN and MAC within the subnet, the correctness of IP configuration, scanning and cleaning up residual test data (such as temporary scripts and log cache) in the storage medium, and simulating mains power fluctuations to test power stability; after verification, the report generation module generates a report containing the full test log (including anomaly details), which users can choose to export as Word or PDF format, or set an email address to have the system automatically send the report.

[0056] 5. Test Data Archiving: After the server passes all tests and verifications, the data archiving module automatically uploads the server's test report, inspection records, and shipment data. The storage unit saves this data long-term, making it easy to query historical records or trace product quality issues later.

[0057] The above are merely preferred embodiments of the present invention and are not intended to limit the implementation methods and protection scope of the present invention. Those skilled in the art should recognize that any equivalent substitutions and obvious changes made based on the description and illustrations of the present invention should be included within the protection scope of the present invention.

Claims

1. A batch testing closed-loop system for SoC array server topology collaboration, characterized in that, include: The module includes a front-end interaction module, a server management module, a task scheduling engine, a test execution module, a topology verification module, an exception handling module, a report generation module, and a data archiving module. The front-end interaction module is connected to the server management module, the task scheduling engine, and the report generation module respectively, and is used to receive user operation instructions and display server test-related information. The server management module is connected to the task scheduling engine and the topology verification module respectively, and is used to obtain SoC array server information in batches and perform basic configuration. The task scheduling engine is connected to the test execution module and the exception handling module respectively, and is used for resource scheduling and queue management of test tasks; The test execution module is communicatively connected to the topology verification module and the report generation module, and is used to execute various test items of the SoC array server according to the test plan; The topology verification module is communicatively connected to the report generation module and is used to perform cross-device configuration verification and hardware status detection on the SoC array server. The exception handling module is communicatively connected to the report generation module and is used to handle exceptions during the testing process and record exception information. The report generation module is connected to the data archiving module and is used to generate test reports and trigger data archiving operations.

2. The batch testing closed-loop system for SoC array server topology collaboration according to claim 1, characterized in that, The server management module includes an information acquisition unit, a configuration execution unit, and a model adaptation unit. The information acquisition unit is used to add SoC array servers in batches and acquire the server's SN, MAC, hardware configuration, and network information. The configuration execution unit is used to perform batch IP settings, test environment installation and uninstallation, power control, and factory reset on multiple SoC array servers. The model adaptation unit is used to generate corresponding test call strategies based on the model of the SoC array server.

3. The batch testing closed-loop system for SoC array server topology collaboration according to claim 1, characterized in that, The task scheduling engine includes a resource awareness unit, a fault suppression unit, and an elastic scheduling unit; the resource awareness unit is used to identify hardware resource conflicts in concurrent test tasks and dynamically adjust the test queue order to execute conflicting test items at off-peak times. The fault suppression unit is used to freeze the associated test items of other servers on the same physical node and trigger cross-machine log correlation analysis when a test of a certain SoC array server fails; the elastic scheduling unit is used to adjust the execution priority of test tasks according to the test task load and the power consumption status of the server cluster.

4. The batch testing closed-loop system for SoC array server topology collaboration according to claim 1, characterized in that, The test execution module includes a plan creation unit, a task execution unit, and a task control unit. The plan creation unit allows users to select commonly used test processes or customize test processes, where test processes can freely combine test items, set the number of tests, and set the test execution time. The task execution unit executes the test plan asynchronously using a queue, progressively calling the test methods of the SoC array server; the task control unit supports users in canceling, deleting, or continuing the execution of test tasks.

5. The batch testing closed-loop system for SoC array server topology collaboration according to claim 1, characterized in that, The topology verification module includes a conflict detection unit, a remnant cleanup unit, and a power supply testing unit. The conflict detection unit analyzes the physical connection relationships of SoC array servers in the same batch through topology map analysis, and verifies the uniqueness of SN and MAC within the subnet and the correctness of IP configuration. The remnant cleanup unit uses a signature comparison algorithm to scan the storage media of the SoC array server and combines it with a preset secure hash library to clear residual data in the test environment. The power supply testing unit simulates mains power fluctuation scenarios, detects the response latency and recovery stability of the server power module, and generates a power quality score.

6. The batch testing closed-loop system for SoC array server topology collaboration according to claim 1, characterized in that, The exception handling module includes a retry control unit, a specification adjustment unit, and a defect marking unit. The retry control unit sets the corresponding number of retries according to the test error type. After the first test fails, the specification adjustment unit reduces the test load specification and performs a second test. When the degradation test passes, the defect marking unit marks the SoC array server as having a critical state defect and synchronizes the information to the report generation module.

7. The batch testing closed-loop system for SoC array server topology collaboration according to claim 1, characterized in that, The report generation module includes a log recording unit, a format export unit, and an email sending unit; the log recording unit records all information and exception details during the test process; the format export unit supports exporting the test report to Word or PDF format; and the email sending unit can send the test report to a specified email address.

8. The batch testing closed-loop system for SoC array server topology collaboration according to claim 1, characterized in that, The data archiving module includes a data uploading unit and a storage unit; the data uploading unit automatically uploads the server's shipment data after the SoC array server passes testing and final inspection; the storage unit is used for long-term storage of test reports, inspection records, and server shipment data.

9. A batch testing method for SoC array server topology collaboration based on a batch testing closed-loop system of SoC array server topology collaboration according to any one of claims 1-8, characterized in that, Includes the following steps: Step 1: Send instructions to the server management module through the front-end interaction module to import the IP information of the SoC array server in batches and obtain detailed server data. The server management module generates a test call strategy based on the server model. Step 2: Create a test plan in the task scheduling engine through the front-end interaction module, select the target SoC array server and test process, and set the test parameters; Step 3: The task scheduling engine performs resource conflict analysis on the test plan, allocates test tasks to the corresponding task queues, and triggers the test execution module; Step 4: The test execution module calls the test method of the SoC array server according to the test plan, and the exception handling module monitors the test process in real time and handles exceptions. Step 5: After the test is completed, the topology verification module performs cross-device configuration verification and hardware status detection on the SoC array server; Step 6: The report generation module generates a test report based on the test data and verification results, which can be exported or sent via email; Step 7: After the SoC array server passes all tests, the data archiving module automatically uploads and stores the server's test report and shipping data.

10. The SoC array server topology collaborative batch testing method according to claim 9, characterized in that, In step 2, when creating the test plan, a two-parameter driven logic is used to formulate the test scheme. The first parameter is the model feature code. The system matches the corresponding test template according to the number of CPU cores, GPU model and number of network cards of the SoC array server. The second parameter is the dynamic load threshold. The system monitors the power consumption and heat dissipation status of the server cluster in real time. When the total power consumption of the rack is close to the critical value, the high load test items are delayed and the low load test items are executed first.

Images