Method and system for automatically testing compatibility of operating system based on domestic Feiteng

Abstract

The application relates to the field of software testing and discloses an operating system compatibility automatic testing method and system based on a domestic Feiteng, which comprises the following steps: integrating a special test environment of a to-be-tested operating system to construct an automatic test suite of the to-be-tested operating system; testing the to-be-tested operating system to obtain a test result and collecting a heterogeneous event stream of the to-be-tested operating system in the testing process; when the test result is a test failure, integrating a failure event set of the to-be-tested operating system, identifying an upstream causal influence chain of the failure event set, calculating an abnormal mode matching degree of the failure event set and a preset root cause mode library, and generating a root cause probability distribution graph of the to-be-tested operating system; and outputting an automatic test report of the to-be-tested operating system. The application can improve the comprehensiveness and accuracy of automatic testing.

Description

Technical Field

[0001] This invention relates to an automated testing method and system for operating system compatibility based on the domestically developed Phytium platform, belonging to the field of software testing. Background Technology

[0002] Automated testing is a branch of software testing that involves using specific tools and software to execute predefined test cases to verify the functionality and performance of a software application. Automated testing allows for testing more functional paths and boundary conditions, thereby improving test coverage and reducing potential defects.

[0003] Traditional automated testing methods only focus on whether the test passes or fails, and their reports only present the results. They treat root cause analysis of failures as an independent, offline task after the test is executed. Because this approach only collects and presents raw logs and does not build a unified time-series view of heterogeneous event streams, it lacks automated and systematic cross-layer data correlation analysis capabilities and cannot generate a complete test failure root cause analysis report, thus affecting testing efficiency. Summary of the Invention

[0004] This invention provides an automated testing method and system for operating system compatibility based on the domestic Phytium platform, with the main purpose of improving the comprehensiveness and accuracy of automated testing.

[0005] To achieve the above objectives, the present invention provides an automated compatibility testing method for operating systems based on the domestically developed Phytium platform, comprising: Based on the domestic Phytium platform, a dedicated test environment for the operating system under test is integrated to build an automated test suite for the operating system under test; Based on the automated testing suite, the operating system under test is tested, the test results are obtained, and the heterogeneous event stream of the operating system under test during the test process is collected. When the test result is a test failure, based on the heterogeneous event stream, the failure event set of the operating system under test is integrated, the upstream causal influence chain of the failure event set is identified, and the abnormal pattern matching degree between the failure event set and the preset root cause pattern library is calculated. Based on the abnormal pattern matching degree, the root cause probability distribution map of the operating system under test is generated. Based on the root cause probability distribution map, an automated test report for the operating system under test is output.

[0006] Optionally, the automated test suite for building the operating system under test includes: In the dedicated test environment of the operating system under test, the hardware characteristics and compatibility requirements of the operating system under test are extracted to generate a layered test requirement matrix for the operating system under test. Based on the layered test requirement matrix, an automated test module and test management framework for the operating system under test are constructed to integrate the automated test suite for the operating system under test.

[0007] Optionally, the automated testing module includes a hardware abstraction layer verification module, a firmware and boot layer testing module, a kernel driver compatibility testing module, and a system-level functional and stress testing module.

[0008] Optionally, the dedicated test environment based on the domestic Phytium platform and integrating the operating system under test includes: Based on the domestic Phytium platform, test nodes and debugging interfaces for the operating system under test are configured; Obtain the kernel source code of the operating system under test to determine the kernel configuration options of the operating system under test; Integrate the microcode binary file corresponding to the domestic Phytium platform to construct a full-stack monitoring probe for the operating system under test; A dedicated test environment for the operating system under test is constructed based on the test node, the debugging interface, the kernel configuration options, the microcode binary file, and the full-stack monitoring probe.

[0009] Optionally, the step of testing the operating system under test based on the automated testing suite to obtain test results includes: Define the testing objectives for the operating system under test, and load the specific test cases of the automated test suite; The test parameters of the operating system under test are determined. Based on the specific test cases and the test parameters, the execution instructions of the operating system under test are generated to perform multi-dimensional test driving on the operating system under test and obtain test results.

[0010] Optionally, the step of collecting the heterogeneous event stream of the operating system under test during the testing process includes: Based on the full-stack monitoring probe of the operating system under test, the internal dynamic behavior of the operating system under test is captured during the test process; Obtain the kernel logs and key business points of the operating system under test during the testing process; Based on the internal dynamic behavior, the kernel logs, and the key business points, integrate the heterogeneous event streams of the operating system under test.

[0011] Optionally, identifying the upstream causal chain of the set of failure events includes: Locate the set of failure events to characterize the termination events of test failure, and determine the backtracking time window of the termination events; By concatenating the discrete events within the backtracking time window, an event correlation graph is obtained; Based on the event association graph, abnormal nodes in the discrete events are marked to extract the causal path of the set of failed events; Based on the causal path, an upstream causal influence chain for the set of failure events is generated.

[0012] Optionally, calculating the anomaly pattern matching degree between the set of failure events and the preset root cause pattern library includes: Based on the upstream causal chain of the set of failure events, extract the event feature sequence of the set of failure events and extract the pattern feature sequence of the root cause pattern library. Based on the event feature sequence and the pattern feature sequence, calculate the structural similarity and state similarity between the failure event set and the root cause pattern library; Based on the structural similarity and the state similarity, the abnormal pattern matching degree between the set of failure events and the root cause pattern library is determined.

[0013] Optionally, generating the root cause probability distribution map of the operating system under test based on the abnormal pattern matching degree includes: Define the base occurrence probability of the operating system under test, and calculate the final root cause probability of the operating system under test by combining the base occurrence probability and the anomaly pattern matching degree. Based on the final root cause probability, a root cause probability distribution map of the operating system under test is generated.

[0014] To address the aforementioned problems, this invention also provides an automated operating system compatibility testing system based on the domestically developed Phytium platform, the system comprising: The test suite generation module is used to integrate a dedicated test environment for the operating system under test based on the domestic Phytium platform, so as to build an automated test suite for the operating system under test. The heterogeneous event acquisition module is used to test the operating system under test based on the automated test suite, obtain test results, and acquire the heterogeneous event stream of the operating system under test during the test process. The probability distribution analysis module is used to integrate the set of failure events of the operating system under test based on the heterogeneous event stream when the test result is a test failure, identify the upstream causal influence chain of the set of failure events, calculate the abnormal pattern matching degree between the set of failure events and the preset root cause pattern library, and generate the root cause probability distribution map of the operating system under test based on the abnormal pattern matching degree. The test report generation module is used to output an automated test report of the operating system under test based on the root cause probability distribution map.

[0015] Compared to the problems described in the background technology, this invention constructs a dedicated testing environment and automated testing suite on the domestic Phytium platform. This enables automated execution and heterogeneous event stream collection of the operating system under test, eliminating the uncertainty of manual testing and ensuring the adaptability of the testing environment. When a test fails, the system can automatically integrate the set of failure events and identify the upstream causal chain. Combining this with a root cause pattern library, it calculates structural and state similarity, thereby quantifying the anomaly pattern matching degree and generating a root cause probability distribution map. This effectively integrates historical prior probabilities with real-time anomaly evidence, solving the problems of inaccurate localization and blindness caused by traditional log analysis alone. The automated test report generated based on this can quickly pinpoint the true root cause with high confidence, significantly shortening fault analysis time and reducing reliance on the personal experience of maintenance personnel. Finally, this invention achieves standardization and datafication of fault diagnosis, providing clear quantitative basis for subsequent fault repair and helping to accumulate test data to optimize resource allocation and the root cause pattern library, thereby continuously improving the testing quality and R&D iteration efficiency of domestic operating systems. Therefore, this invention can improve the comprehensiveness and accuracy of automated testing. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating an automated compatibility testing method for an operating system based on the domestic Phytium platform, provided in an embodiment of the present invention. Figure 2 A flowchart illustrating the multimodal hardware data fusion process for implementing the automated operating system compatibility testing method based on the domestic Phytium platform, as provided in an embodiment of the present invention. Figure 3 This is a system architecture diagram of a traditional scheme for implementing the automated operating system compatibility testing method based on the domestic Phytium, according to an embodiment of the present invention. Figure 4 This is a schematic diagram of the modules for implementing the automated operating system compatibility testing method based on the domestic Phytium system, according to an embodiment of the present invention. Figure 5 A schematic diagram of a computer device for an automated operating system compatibility testing method based on the domestic Phytium system provided in an embodiment of the present invention; The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0017] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0018] This application provides an automated testing method for operating system compatibility based on the domestically developed Phytium platform. The executing entity of this automated testing method includes, but is not limited to, at least one electronic device that can be configured to execute the method provided in this application, such as a server or a terminal. In other words, the automated testing method for operating system compatibility based on Phytium can be executed by software or hardware installed on a terminal device or a server device. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster.

[0019] Reference Figure 1 The diagram shown is a flowchart illustrating an automated operating system compatibility testing method based on the domestically developed Phytium platform, according to an embodiment of the present invention. In this embodiment, the automated operating system compatibility testing method based on the domestically developed Phytium platform includes: See Figure 2 The diagram shown is a flowchart illustrating the multimodal hardware data fusion process for implementing the automated compatibility testing method for the domestically developed Phytium operating system, according to an embodiment of the present invention. Figure 2In this context, FPGA-BASED HARDWARE DATAFUSION PROCESS refers to the hardware data fusion process based on FPGA; LIDAR refers to LiDAR; RADAR refers to radar; CAMERA refers to camera; IMU refers to inertial measurement unit; TIME SYNCHRONIZATION refers to time synchronization; GPS / PTP refers to Global Positioning System / Precise Time Protocol; SPATIAL ALIGNMENT & CALIBRATION refers to spatial alignment and calibration; Matrix Transform refers to matrix transformation; COORDINATE TRANSFORMATION refers to coordinate transformation; Ego to World refers to the transformation from the vehicle coordinate system to the world coordinate system; Quaternion / Euler refers to quaternions / Euler angles; FEATURE EXTRACTION refers to feature extraction; Edge, Point Cloud refers to edges and point clouds; DSP Blocks refers to DSP blocks; PRE-FUSION PROCESSING refers to pre-fusion processing; Filtering, Normalization refers to filtering and normalization; BRAMBuffers refers to block random access memory cache; AXI Interconnect refers to advanced scalable interface interconnect; and AIINFERENCE refers to... ENGINE represents the artificial intelligence inference engine; CNN / RNN Accelerator represents the convolutional neural network / recurrent neural network accelerator; DATA FORMAT represents the data format; Radar represents radar; Accel / Gyro, FP32 represents accelerometer / gyroscope, 32-bit floating-point number; DATA FORMAT SPECS represents the data format specification; LiDAR (XYZI, FP32) represents LiDAR (XYZI, FP32); Radar (Range-Doppler, Int16) represents radar (range-Doppler, 16-bit signed integer); Camera (RGB, uint8) represents camera (red, green, and blue channels, 8-bit unsigned integer); IMU (Accel / Gyro, FP32) represents IMU (accelerometer / gyroscope, FP32); PROCESSING LATENCY ANNOTATIONS represents processing latency annotations; Time Sync (<2μs) represents time synchronization (<2μs); Spatial Align (<10μs) indicates spatial alignment (<10μs), Feature Extr.(<50μs) indicates feature extraction (<50μs), Pre-Fusion (<20μs) indicates pre-fusion (<20μs), Total Data Fusion Path (<100μs) indicates the total data fusion path (<100μs), PCIe ssBuffers indicates PCIe slave cache, PCIe Gen4 indicates fourth-generation peripheral interconnect fast channel, and the following are the corresponding values. Figure 2 The implementation process shown is as follows: The LiDAR, camera, radar, and inertial measurement unit input raw data to the Field Programmable Gate Array (FPGA); the FPGA sequentially runs a time synchronization module, a spatial alignment and calibration module, a coordinate transformation module, a feature extraction module, and a pre-fusion processing module within its programmable logic unit. The time synchronization module is used for timestamp alignment; the spatial alignment and calibration module and the coordinate transformation module are used for coordinate system transformation; the feature extraction module is used for feature extraction; and the pre-fusion processing module is used for unifying bit width and memory layout. The FPGA stores the pre-fused data in its on-chip BRAM cache; the FPGA sends the pre-fused data to the PCIe Gen4 interface via AXI interconnect; the PCIe Gen4 interface encapsulates the pre-fused data into fixed-length TLP packets using a distributed-aggregate DMA method and writes them directly to the input cache of the AI ​​inference engine to complete extremely low-latency hardware data transmission.

[0020] See Figure 3 The diagram shown is a system architecture diagram of a traditional scheme for implementing the automated compatibility testing method for the domestically developed Phytium operating system, according to an embodiment of the present invention. Figure 3In this context, TECHNICAL SYSTEM ARCHITECTURE represents the technical system architecture; MULTI-MODAL ENVIRONMENTAL PERCEPTION FUSION PROCESSOR FORAUTONOMOUS VEHICLES represents the autonomous driving multimodal environmental perception fusion processor; SENSOR INPUTINTERFACES represents sensor input interfaces; HIGH-SPEED DATA BUS represents high-speed data bus; FPGA represents Field Programmable Gate Array; PREPROCESSING represents preprocessing; UNIT represents a unit; Raw Data Ingestion represents raw data ingestion; Point Cloud Filtering represents point cloud filtering; Image De-warping represents image distortion correction; Signal Conditioning represents signal conditioning; SHARED MEMORY POOLS represents shared memory pools; DDR4 represents fourth-generation double data rate synchronous dynamic random access memory; LPDDRS represents low-power double data rate synchronous dynamic random access memory; AI SOC INFERENCE ENGINE represents the artificial intelligence system-on-chip inference engine; TransformerCore represents the transformer core; DSP represents the digital signal processor; and CPU represents the CPU. Cluster refers to the central processing unit cluster, REAL-TIME FUSION ALGORITHMS refers to real-time fusion algorithms, Kalman Filter refers to the Kalman filter, Occupancy Grid refers to the occupancy grid, Object Tracking refers to target tracking, Sensor Fusion Logic refers to the sensor fusion logic, and PERCEPTION OUTPUT refers to the sensing output. The following is a description of... Figure 3 The implementation process shown is as follows: LiDAR, camera, radar, and IMU input raw data to the Field-Programmable Gate Array (FPGA) through sensor input interfaces; the FPGA sequentially performs signal conditioning, image distortion correction, and point cloud filtering within its preprocessing unit to obtain preprocessed sensor data; the FPGA stores the preprocessed data in a shared storage pool (DDR4 / LPDDR5) and simultaneously sends it to the AI ​​SOC inference engine; the AI ​​SOC inference engine runs a CNN / Transformer accelerator to extract features and infer from the preprocessed data, obtaining perception results such as target lists and drivable areas; the FPGA's CPU cluster runs a real-time fusion algorithm to fuse and track the inference results, ultimately outputting the perception results. Finally, it should be noted that... Figure 3The process shown is not the process of this invention, but a traditional data fusion process, used for comparison with this invention. Figure 3 The proposed solution relies on external storage and operating system scheduling, resulting in higher end-to-end latency compared to this invention. It is only used for comparison with this invention to highlight the contribution of this invention in addressing the latency bottleneck.

[0021] S1. Based on the domestic Phytium platform, a dedicated test environment for the operating system under test is integrated to construct an automated test suite for the operating system under test.

[0022] This invention, through a dedicated testing environment integrating the operating system under test based on the domestic Phytium platform, ensures the authenticity and consistency of the testing environment. This guarantees that all testing activities accurately reflect the domestically produced hardware foundation, effectively isolates external variable interference, and clearly limits the cause of failure to the interaction between the Phytium platform and the operating system. The dedicated testing environment refers to an integrated hardware and software testing platform specifically designed, built, and configured to complete deep compatibility verification between the domestic Phytium platform and the operating system under test.

[0023] As an embodiment of the present invention, the dedicated test environment based on the domestic Phytium platform and integrating the operating system under test includes: Based on the domestic Phytium platform, test nodes and debugging interfaces for the operating system under test are configured; Obtain the kernel source code of the operating system under test to determine the kernel configuration options of the operating system under test; Integrate the microcode binary file corresponding to the domestic Phytium platform to construct a full-stack monitoring probe for the operating system under test; A dedicated test environment for the operating system under test is constructed based on the test node, the debugging interface, the kernel configuration options, the microcode binary file, and the full-stack monitoring probe.

[0024] The test node refers to a virtualized instance built on the domestic Phytium processor architecture, running the operating system under test (OS). It possesses independent data processing, memory management, and I / O control capabilities, and is used to actually host and execute test cases in the automated test suite. The debug interface refers to the hardware-firmware communication channel deployed at the Phytium platform's underlying layer, including a JTAG / UART serial port interface for low-level debugging and hardware status capture, and a baseboard management controller interface for out-of-band management. The kernel source code refers to the core program code of the OS under test, containing the implementation logic of drivers, scheduling algorithms, and system call interfaces for managing Phytium processor hardware resources. It is crucial for analyzing system behavior, implanting monitoring mechanisms, and locating microcode-OS interaction issues. The kernel configuration options refer to the function switch parameters selected during the compilation of the OS kernel under test, used to enable or disable specific kernel features, including key debugging and monitoring functions such as hardware error reporting, performance monitoring unit access, dynamic microcode loading, and kernel crash dump support. The microcode binary file refers to the firmware data file provided by the Phytium chip manufacturer, containing defect fix patches and instruction behavior fine-tuning logic for specific hardware versions. The full-stack monitoring probe refers to a software and firmware co-component consisting of a user-mode acquisition program, a kernel-mode tracing module, and a low-level driver that directly reads hardware registers.

[0025] Optionally, the kernel configuration options of the operating system under test can be determined by matching the feature fingerprint of the Phytium platform device tree.

[0026] Optionally, the dedicated test environment for the operating system under test can be constructed using digital twin technology.

[0027] This invention, through the construction of an automated test suite for the operating system under test, achieves deep coverage of microcode and kernel interaction, filling the gap in traditional testing that cannot cover the blind spots between the hardware firmware layer and the operating system kernel layer. It enables automatic startup, execution monitoring, and log collection for compatibility testing of the domestic Phytium platform operating system, significantly shortening the testing cycle. The automated test suite refers to a complete set of executable test cases, supporting tools, data, and scripts specifically designed, organized, and packaged to verify the compatibility, functionality, performance, and stability between the domestic Phytium platform and the operating system under test.

[0028] As an embodiment of the present invention, the construction of the automated test suite for the operating system under test includes: In the dedicated test environment of the operating system under test, the hardware characteristics and compatibility requirements of the operating system under test are extracted to generate a layered test requirement matrix for the operating system under test. Based on the layered test requirement matrix, an automated test module and test management framework for the operating system under test are constructed to integrate the automated test suite for the operating system under test.

[0029] The hardware characteristics refer to the underlying physical and logical configuration information directly related to the operation and compatibility of the operating system, obtained directly from the domestic Phytium platform on which the dedicated testing environment is based, through software tools or firmware interfaces, and are directly detected, read, or parsed. This includes processor core characteristics, platform architecture information, peripheral device information, firmware exposure interfaces, and hardware monitoring capabilities. The compatibility requirements refer to the functional, performance, and reliability requirements that the operating system under test must meet at the software and hardware interface level to achieve its designed functions and predetermined performance and stability indicators on the Phytium platform, such as functional correctness requirements, performance compliance requirements, and stability and reliability requirements. The layered test requirement matrix is ​​a two-dimensional mapping table that systematically and structurally associates the hardware characteristics with the compatibility requirements. The automated test module refers to a set of logical execution units independently encapsulated for specific test dimensions, generated based on the layered test requirement matrix. The test management framework is a software infrastructure platform used to organize, schedule, and execute the automated test modules, and to collect, analyze, and report test results.

[0030] Optionally, the hardware characteristics can be extracted through a dedicated kernel module, UEFI Shell application, or privileged user-space program, and the compatibility requirements can be extracted through semantic analysis of requirements documents, design specifications, and industry standards.

[0031] Optionally, the test management framework can be constructed using a test case generation method based on multidimensional matrix mapping.

[0032] Optionally, the automated testing module includes a hardware abstraction layer verification module, a firmware and boot layer testing module, a kernel driver compatibility testing module, and a system-level functional and stress testing module.

[0033] The hardware abstraction layer verification module is a program unit that directly accesses and verifies the original hardware interfaces of the Phytium processor and core chipset. Its purpose is to bypass the operating system driver, verify whether the hardware's functionality and register-level interfaces conform to design specifications, and provide a reliable hardware foundation for upper-layer software. The firmware and boot layer testing module is a program unit that verifies the firmware interface connecting the hardware and the operating system, as well as the operating system boot process. Its core function is to ensure that the services provided by the firmware conform to standards and that the operating system can correctly utilize these services to complete initialization. The kernel driver compatibility testing module is a test program unit specifically designed to verify whether the operating system kernel and its device drivers are correctly adapted and run stably on the Phytium platform. The system-level functional and stress testing module is a test program unit that simulates real or extreme loads under a complete operating system operating environment to comprehensively verify the overall functionality, performance, reliability, and resource management capabilities of the system.

[0034] S2. Based on the automated test suite, test the operating system under test, obtain test results, and collect the heterogeneous event stream of the operating system under test during the test process.

[0035] This invention, through the automated testing suite, tests the operating system under test. The test results confirm the compatibility between the operating system under test and the Phytium processor microcode version, and verify the system's stability and data consistency during dynamic microcode loading and updating. The test results refer to the comprehensive data set covering software behavior and hardware status generated and output by the system after executing the automated testing suite in the dedicated testing environment.

[0036] As an embodiment of the present invention, the step of testing the operating system under test based on the automated testing suite and obtaining test results includes: Define the testing objectives for the operating system under test, and load the specific test cases of the automated test suite; The test parameters of the operating system under test are determined. Based on the specific test cases and the test parameters, the execution instructions of the operating system under test are generated to perform multi-dimensional test driving on the operating system under test and obtain test results.

[0037] The test objectives refer to the verification dimensions set for the operational quality and functional integrity of the operating system under test on the Phytium hardware platform, such as functional correctness, architectural compatibility, and performance indicators. The specific test cases refer to standardized test scripts written to achieve the test objectives, containing specific operation steps, input data, and expected results. The test parameters refer to configuration variables set to control the test environment, constrain resource consumption, and simulate specific operating scenarios when executing specific test cases. The execution instructions refer to the sequence of control commands generated by the automated test suite based on the specific test cases and test parameters, which can be directly applied to the operating system under test.

[0038] Optionally, the specific test cases can be determined using metadata retrieval techniques, such as graph databases or key-value indexes.

[0039] Optionally, the execution instructions can be generated using dynamic code generation and template rendering technologies, such as Jinja2, Freemarker, or String Template.

[0040] This invention provides multi-dimensional data support for subsequent root cause analysis by collecting heterogeneous event streams of the operating system under test during the testing process, including software logic, kernel behavior, and hardware metrics. The heterogeneous event stream refers to an ordered data set formed by aligning the timestamps of multi-source, multi-type, and multi-level data generated by the operating system under test during the testing process.

[0041] As an embodiment of the present invention, the step of collecting the heterogeneous event stream of the operating system under test during the testing process includes: Based on the full-stack monitoring probe of the operating system under test, the internal dynamic behavior of the operating system under test is captured during the test process; Obtain the kernel logs and key business points of the operating system under test during the testing process; Based on the internal dynamic behavior, the kernel logs, and the key business points, integrate the heterogeneous event streams of the operating system under test.

[0042] The internal dynamic behavior refers to the operational trajectory and state changes of the kernel subsystem of the operating system under test at a micro-timescale, including process scheduling context switching, interrupt handling process, system call execution path, kernel function call stack, lock contention and waiting time, memory allocation and reclamation operations, and network protocol stack packet processing. The kernel log refers to the runtime recording information output by the core components of the operating system kernel, covering kernel startup information, hardware driver loading status, kernel warnings and error reports, hardware exception interrupt records, and kernel debugging output. The key business points refer to the timestamped program state markers actively recorded by the test case at specific business logic nodes during user-space program execution, including start and end markers for functional module execution, input parameters and return values ​​of key functions, intermediate states of transaction processing, and assertion information indicating successful business logic.

[0043] Optionally, the internal dynamic behavior can be obtained through kernel dynamic tracing and instrumentation techniques, such as Extended Berkeley Packet Filter, Kprobes / Kretprobes, Function Tracer, etc.

[0044] Optionally, the heterogeneous event stream can be obtained through multi-source heterogeneous data integration and fusion technologies, such as data-level fusion, decision-level fusion, and feature-level fusion.

[0045] S3. When the test result is a test failure, based on the heterogeneous event stream, integrate the failure event set of the operating system under test, identify the upstream causal influence chain of the failure event set, calculate the abnormal pattern matching degree between the failure event set and the preset root cause pattern library, and generate the root cause probability distribution map of the operating system under test based on the abnormal pattern matching degree.

[0046] This invention, when the test result is a test failure, integrates the failure event set of the operating system under test based on the heterogeneous event stream to eliminate background events that indicate normal operation and filter out key data segments directly related to the failure. The failure event set refers to a subset of events selected from the heterogeneous event stream based on the time node of the test failure, which have a direct or potential causal relationship with the failure result. This includes key trigger events, abnormal state snapshots, error response events, and causal preceding events.

[0047] Optionally, the set of failure events can be integrated using clustering algorithms, such as the K-Means algorithm, the K-Medoids algorithm, etc.

[0048] This invention, through identifying the upstream causal chain of the failure event set, can exclude irrelevant derivative events and pinpoint the source event causing the failure. The upstream causal chain refers to an ordered sequence of events with logical causal relationships, constructed by tracing back along the timeline from the final failed system state within the time window of the test failure of the operating system under test.

[0049] As an embodiment of the present invention, identifying the upstream causal chain of the set of failure events includes: Locate the set of failure events to characterize the termination events of test failure, and determine the backtracking time window of the termination events; By concatenating the discrete events within the backtracking time window, an event correlation graph is obtained; Based on the event association graph, abnormal nodes in the discrete events are marked to extract the causal path of the set of failed events; Based on the causal path, an upstream causal influence chain for the set of failure events is generated.

[0050] The terminology defined as follows: The termination event refers to a critical event that directly indicates an abnormal system state or interrupted business process at the moment of test failure, such as an operating system kernel crash, the throwing of a fatal error signal, a test case assertion failure, or a specific system call returning an error code. The backtracking time window refers to a time interval set backward from the occurrence of the termination event, covering the entire process of a fault from its inception to its outbreak. The discrete events refer to fragments of original runtime records collected independently by the full-stack monitoring probe from kernel mode, user mode, and hardware layer within the backtracking time window, which have not yet established logical connections, such as a single system call, a log print, or a function call record. The event correlation graph is a topological network diagram reflecting the internal interaction structure and flow relationships of the system, constructed by connecting the discrete events based on a shared execution context, resource dependencies, and chronological order. The abnormal node refers to a critical event point in the event correlation graph that, after being determined by abnormal propagation rules, exhibits characteristics deviating from the expected operating state, including the first generation of an error code, illegal memory access, resource deadlock contention, and abnormal out-of-bounds occurrences of critical parameters. The causal path refers to the logically related and complete ordered sequence of events that starts from the root cause triggering point in the abnormal node, passes through intermediate state transmission nodes, and finally converges to the termination event in the event association graph.

[0051] Optionally, the backtracking time window can be determined using a sliding window technique.

[0052] Optionally, the event association map can be obtained through multi-dimensional feature association, such as PID / TID, MemoryAddress, FD, etc.

[0053] Optionally, abnormal nodes in the discrete events can be identified using anomaly detection techniques, such as ErrorCode Check and Null Pointer Dereference.

[0054] Optionally, the causal path can be determined by a path search algorithm, such as depth-first search or breadth-first search.

[0055] This invention, through calculating the anomaly pattern matching degree between the set of failure events and a preset root cause pattern library, transforms qualitative fault characteristics into quantitative similarity indicators based on the anomaly pattern matching degree, thereby improving the accuracy and reliability of automated root cause localization. The preset root cause pattern library refers to a pre-built and stored expert knowledge base containing various historically known fault characteristics and their corresponding root cause classifications. The anomaly pattern matching degree is a quantitative numerical indicator used to measure the degree of similarity between the features extracted from the set of failure events and the standard patterns in the preset root cause pattern library.

[0056] As an embodiment of the present invention, calculating the abnormal pattern matching degree between the set of failure events and the preset root cause pattern library includes: Based on the upstream causal chain of the set of failure events, extract the event feature sequence of the set of failure events and extract the pattern feature sequence of the root cause pattern library. Based on the event feature sequence and the pattern feature sequence, calculate the structural similarity and state similarity between the failure event set and the root cause pattern library; Based on the structural similarity and the state similarity, the abnormal pattern matching degree between the set of failure events and the root cause pattern library is determined.

[0057] The event feature sequence refers to an ordered set of key feature data extracted from the upstream causal chain of the failed event set according to the chronological order of causal triggering. This sequence includes not only the order in which events occur, but also the system state parameters corresponding to the event nodes, the event type, and the topological connections between nodes, used to fully characterize the propagation path and evolution process of anomalies in the system. The pattern feature sequence refers to an ordered set of feature data extracted from a predefined root cause pattern library according to a predetermined causal logical order, used to describe the typical evolution path of a specific known root cause. This sequence represents the standard characteristic trajectory of the root cause in historical data or expert experience, serving as a reference benchmark for determining whether the current failed event belongs to this type of root cause. The structural similarity is an index used to measure the consistency between the topological structure of the upstream causal chain of the failed event set and the structure of the standard path in the root cause pattern library. The state similarity is an index used to measure the numerical deviation between the real-time system state parameters recorded in the failed event set and the standard state parameters defined in the root cause pattern library at the corresponding causal path nodes.

[0058] As another implementation, the structural similarity and the state similarity are calculated using the following formula: ; ; in, Indicates structural similarity. Indicates state similarity, Indicates the upstream causal chain, The standard pattern chain representing the root cause pattern library, This indicates the number of key nodes that match between the upstream causal chain and the standard pattern chain. Represents the maximum value function. Indicates An exponential function with base 0. Represents the position sensitivity coefficient. Indicates the first The relative position of each matching point on the upstream causal chain. Indicates the first The relative positions of each matching point on the standard pattern chain Indicates the first event in the event feature sequence. Event text features of each matching point Indicates the first element in the pattern feature sequence Pattern text features of matching points This represents a text similarity function. Weight coefficients representing the similarity of text features. Indicates the first event in the event feature sequence. The event numerical features of each matching point Indicates the first element in the pattern feature sequence Numerical features of the pattern at each matching point Indicates the first The maximum value of the numerical features of each matching point. Weighting coefficients representing the similarity of numerical features.

[0059] It needs to be explained that in this application, the formula... The position sensitivity coefficient is denoted by [0.1, 1] and is obtained through cross-validation. The larger the position sensitivity coefficient, the heavier the penalty for inconsistencies in the order of events. The weighting coefficients represent the text feature similarity and range from (0,1). The weight coefficient representing the similarity of numerical features takes values ​​in the range (0,1) and satisfies the following conditions: .

[0060] This invention, through generating a root cause probability distribution map of the operating system under test based on the abnormal pattern matching degree, can transform ambiguous fault phenomena into quantifiable probability distributions. It can then filter out the candidates with the highest probabilities from multidimensional potential root causes and aggregate similar historical fault cases to aid in root cause inference. Specifically, the root cause probability distribution map is a visual chart generated by using all potential root causes of the current fault in the operating system under test as dimensions and the probability of each root cause occurring as a numerical value.

[0061] As an embodiment of the present invention, generating the root cause probability distribution map of the operating system under test based on the abnormal pattern matching degree includes: Define the base occurrence probability of the operating system under test, and calculate the final root cause probability of the operating system under test by combining the base occurrence probability and the anomaly pattern matching degree. Based on the final root cause probability, a root cause probability distribution map of the operating system under test is generated.

[0062] The basic occurrence probability refers to the likelihood of each potential root cause occurring, determined solely based on historical fault statistics and system architecture characteristics of the operating system under test, before any specific real-time anomaly data is observed. The final root cause probability refers to the most accurate attribution probability for the current specific fault event, calculated using Bayesian inference or a weighted fusion algorithm after comprehensively considering the basic occurrence probability of the operating system under test and the matching degree of the currently detected anomaly pattern.

[0063] Optionally, the basic occurrence probability of the operating system under test can be defined using a Bayesian inference method.

[0064] S4. Based on the root cause probability distribution map, output an automated test report for the operating system under test.

[0065] This invention, through its embodiment, outputs an automated test report of the operating system under test based on the root cause probability distribution map, which can improve the accuracy of fault location, standardize diagnostic processing, and provide quantitative maintenance basis. The automated test report is a formal document automatically generated based on the calculated final root cause probability, used to record and display the fault diagnosis results of the operating system under test in abnormal states, including root cause location results, probability data, basis analysis, and anomaly details.

[0066] like Figure 4 The diagram shown is a functional block diagram of the automated operating system compatibility testing system based on the domestic Phytium platform of this invention.

[0067] The automated operating system compatibility testing system 400 based on the domestic Phytium platform described in this invention can be installed in electronic devices. According to its functions, the automated operating system compatibility testing system based on the domestic Phytium platform includes a test suite generation module 401, a heterogeneous event acquisition module 402, a probability distribution analysis module 403, and a test report generation module 404. The module described in this invention can also be called a unit, which refers to a series of computer program segments that can be executed by the processor of an electronic device and can perform a fixed function, and which are stored in the memory of the electronic device.

[0068] In this embodiment of the invention, the functions of each module / unit are as follows: The test suite generation module 401 is used to integrate a dedicated test environment for the operating system under test based on the domestic Phytium platform, so as to build an automated test suite for the operating system under test. The heterogeneous event acquisition module 402 is used to test the operating system under test based on the automated test suite, obtain test results, and acquire the heterogeneous event stream of the operating system under test during the test process. The probability distribution analysis module 403 is used to integrate the set of failure events of the operating system under test based on the heterogeneous event stream when the test result is a test failure, identify the upstream causal influence chain of the set of failure events, calculate the abnormal pattern matching degree of the set of failure events and the preset root cause pattern library, and generate the root cause probability distribution map of the operating system under test based on the abnormal pattern matching degree. The test report generation module 404 is used to output an automated test report of the operating system under test based on the root cause probability distribution map.

[0069] In detail, the modules in the automated operating system compatibility testing system 400 based on the domestic Phytium platform described in this embodiment of the invention adopt the same methods as described above when in use. Figure 1 The method used here is the same as the automated compatibility testing method for the domestic Phytium operating system described in the previous article, and can produce the same technical effect, so it will not be repeated here.

[0070] In one embodiment, a computer device is provided, which may be a server or a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements functions or steps on the server or client side of an automated testing method for operating system compatibility based on domestic Phytium.

[0071] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: The test suite generation module is used to integrate a dedicated test environment for the operating system under test based on the domestic Phytium platform, so as to build an automated test suite for the operating system under test. The heterogeneous event acquisition module is used to test the operating system under test based on the automated test suite, obtain test results, and acquire the heterogeneous event stream of the operating system under test during the test process. The probability distribution analysis module is used to integrate the set of failure events of the operating system under test based on the heterogeneous event stream when the test result is a test failure, identify the upstream causal influence chain of the set of failure events, calculate the abnormal pattern matching degree between the set of failure events and the preset root cause pattern library, and generate the root cause probability distribution map of the operating system under test based on the abnormal pattern matching degree. The test report generation module is used to output an automated test report of the operating system under test based on the root cause probability distribution map.

[0072] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: The test suite generation module is used to integrate a dedicated test environment for the operating system under test based on the domestic Phytium platform, so as to build an automated test suite for the operating system under test. The heterogeneous event acquisition module is used to test the operating system under test based on the automated test suite, obtain test results, and acquire the heterogeneous event stream of the operating system under test during the test process. The probability distribution analysis module is used to integrate the set of failure events of the operating system under test based on the heterogeneous event stream when the test result is a test failure, identify the upstream causal influence chain of the set of failure events, calculate the abnormal pattern matching degree between the set of failure events and the preset root cause pattern library, and generate the root cause probability distribution map of the operating system under test based on the abnormal pattern matching degree. The test report generation module is used to output an automated test report of the operating system under test based on the root cause probability distribution map.

[0073] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0074] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0075] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0076] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0077] Finally, it should be noted that in the above embodiments, each embodiment can be combined with each other or independent. Deleting any one of them will not affect the technical implementation of other embodiments. The above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. An automated testing method for operating system compatibility based on the domestically developed Phytium operating system, characterized in that, The method includes: Based on the domestic Phytium platform, a dedicated test environment for the operating system under test is integrated to build an automated test suite for the operating system under test; Based on the automated testing suite, the operating system under test is tested, the test results are obtained, and the heterogeneous event stream of the operating system under test during the test process is collected. When the test result is a test failure, based on the heterogeneous event stream, the failure event set of the operating system under test is integrated, the upstream causal influence chain of the failure event set is identified, and the abnormal pattern matching degree between the failure event set and the preset root cause pattern library is calculated. Based on the abnormal pattern matching degree, the root cause probability distribution map of the operating system under test is generated. Based on the root cause probability distribution map, an automated test report for the operating system under test is output.

2. The automated compatibility testing method for the operating system based on the domestic Phytium as described in claim 1, characterized in that, The automated test suite for building the operating system under test includes: In the dedicated test environment of the operating system under test, the hardware characteristics and compatibility requirements of the operating system under test are extracted to generate a layered test requirement matrix for the operating system under test. Based on the layered test requirement matrix, an automated test module and test management framework for the operating system under test are constructed to integrate the automated test suite for the operating system under test.

3. The automated compatibility testing method for the operating system based on the domestic Phytium as described in claim 2, characterized in that, The automated testing module includes a hardware abstraction layer verification module, a firmware and boot layer testing module, a kernel driver compatibility testing module, and a system-level functional and stress testing module.

4. The automated compatibility testing method for the operating system based on the domestic Phytium as described in claim 1, characterized in that, The dedicated test environment, based on the domestic Phytium platform and integrating the operating system under test, includes: Based on the domestic Phytium platform, test nodes and debugging interfaces for the operating system under test are configured; Obtain the kernel source code of the operating system under test to determine the kernel configuration options of the operating system under test; Integrate the microcode binary file corresponding to the domestic Phytium platform to construct a full-stack monitoring probe for the operating system under test; A dedicated test environment for the operating system under test is constructed based on the test node, the debugging interface, the kernel configuration options, the microcode binary file, and the full-stack monitoring probe.

5. The automated compatibility testing method for the operating system based on the domestic Phytium as described in claim 1, characterized in that, The automated testing suite is used to test the operating system under test, and the test results are obtained, including: Define the testing objectives for the operating system under test, and load the specific test cases of the automated test suite; The test parameters of the operating system under test are determined. Based on the specific test cases and the test parameters, the execution instructions of the operating system under test are generated to perform multi-dimensional test driving on the operating system under test and obtain test results.

6. The automated compatibility testing method for the operating system based on the domestic Phytium as described in claim 1, characterized in that, The process of collecting heterogeneous event streams of the operating system under test during the testing process includes: Based on the full-stack monitoring probe of the operating system under test, the internal dynamic behavior of the operating system under test is captured during the test process; Obtain the kernel logs and key business points of the operating system under test during the testing process; Based on the internal dynamic behavior, the kernel logs, and the key business points, integrate the heterogeneous event streams of the operating system under test.

7. The automated operating system compatibility testing method based on the domestic Phytium as described in claim 1, characterized in that, The identification of the upstream causal chain of the set of failure events includes: Locate the set of failure events to characterize the termination events of test failure, and determine the backtracking time window of the termination events; By concatenating the discrete events within the backtracking time window, an event correlation graph is obtained; Based on the event association graph, abnormal nodes in the discrete events are marked to extract the causal path of the set of failed events; Based on the causal path, an upstream causal influence chain for the set of failure events is generated.

8. The automated compatibility testing method for the operating system based on the domestic Phytium as described in claim 1, characterized in that, The calculation of the anomaly pattern matching degree between the set of failure events and the preset root cause pattern library includes: Based on the upstream causal chain of the set of failure events, extract the event feature sequence of the set of failure events and extract the pattern feature sequence of the root cause pattern library. Based on the event feature sequence and the pattern feature sequence, calculate the structural similarity and state similarity between the failure event set and the root cause pattern library; Based on the structural similarity and the state similarity, the abnormal pattern matching degree between the set of failure events and the root cause pattern library is determined.

9. The automated operating system compatibility testing method based on the domestic Phytium as described in claim 1, characterized in that, The step of generating a root cause probability distribution map of the operating system under test based on the abnormal pattern matching degree includes: Define the base occurrence probability of the operating system under test, and calculate the final root cause probability of the operating system under test by combining the base occurrence probability and the anomaly pattern matching degree. Based on the final root cause probability, a root cause probability distribution map of the operating system under test is generated.

10. An automated operating system compatibility testing system based on the domestically developed Phytium platform, characterized in that: The system includes: The test suite generation module is used to integrate a dedicated test environment for the operating system under test based on the domestic Phytium platform, so as to build an automated test suite for the operating system under test. The heterogeneous event acquisition module is used to test the operating system under test based on the automated test suite, obtain test results, and acquire the heterogeneous event stream of the operating system under test during the test process. The probability distribution analysis module is used to integrate the set of failure events of the operating system under test based on the heterogeneous event stream when the test result is a test failure, identify the upstream causal influence chain of the set of failure events, calculate the abnormal pattern matching degree between the set of failure events and the preset root cause pattern library, and generate the root cause probability distribution map of the operating system under test based on the abnormal pattern matching degree. The test report generation module is used to output an automated test report of the operating system under test based on the root cause probability distribution map.

Images