Hardware and system compatibility detection method, device, equipment, medium and product

Abstract

This application discloses a hardware and system compatibility testing method, apparatus, device, medium, and product, relating to the field of hardware and system testing. The method includes: obtaining a device configuration file and a system testing configuration file; establishing an encrypted SSH connection with the target testing device based on the SSH connection parameters of the device configuration file; loading the corresponding system testing configuration file based on the device model in the device configuration file, and deeply merging the device configuration file and the system testing configuration file to generate a complete testing configuration; executing testing items and capturing the command exit status code, standard output stream, and standard error stream of each testing item during execution, and determining the success or failure of the testing results based on the judgment rules in the complete testing configuration; collecting the judgment results, execution time, and detailed logs of all testing items, and generating a visual testing report. This application improves the efficiency and flexibility of hardware and system adaptation.

Description

Technical Field

[0001] This application relates to the field of hardware and system testing, and in particular to a method, apparatus, equipment, medium, and product for testing the compatibility of hardware and systems. Background Technology

[0002] In the process of hardware selection and system adaptation, hardware and system compatibility testing is a crucial step in ensuring stable system operation. Currently, the industry mainly uses three types of testing methods to achieve this process: first, manual item-by-item testing, where technicians manually check hardware configuration parameters according to requirements documents to verify the compatibility of hardware and system one by one; second, simple script testing, which uses scripts with fixed logic to perform basic testing tasks; and third, testing using third-party testing tools. All three methods suffer from low efficiency and poor flexibility. Therefore, there is an urgent need to provide a hardware and system compatibility testing method that can improve testing efficiency and flexibility. Summary of the Invention

[0003] In view of the above-mentioned defects or deficiencies in the related technologies, the purpose of this application is to provide a hardware and system compatibility testing method, apparatus, equipment, medium and product, which can improve the adaptation efficiency and flexibility of hardware and systems.

[0004] To achieve the above objectives, this application provides the following solution:

[0005] Firstly, this application provides a hardware and system compatibility testing method, comprising: obtaining a device configuration file and a system testing configuration file, wherein the device configuration file includes SSH connection parameters of the target testing device, the device model, and a list of test cases to be executed, and the system testing configuration file is a test file pre-configured according to the operating system and hardware architecture of the target testing device; establishing an encrypted SSH connection with the target testing device using an encryption protocol based on the SSH connection parameters of the device configuration file; loading the corresponding system testing configuration file based on the device model in the device configuration file, and deeply merging the device configuration file and the system testing configuration file to generate a complete testing configuration; executing preset categories of testing items in a preset order, and capturing the command exit status code, standard output stream, and standard error stream of each testing item during execution, and determining the success or failure of the testing results based on the judgment rules in the complete testing configuration to obtain a judgment result; collecting the judgment results, execution time, and detailed logs of all testing items, and generating a visual testing report.

[0006] Optionally, both the device configuration file and the system detection configuration file are in YAML format; the system detection configuration file includes ubuntu_x86.yml, ubuntu_arm.yml, openeuler_x86.yml, openeuler_arm.yml and openwrt_arm.yml.

[0007] Optionally, the step of deeply merging the device configuration file and the system detection configuration file to generate a complete detection configuration includes: merging the connection information and basic device parameters of the device configuration file with the detection items, detection command templates, and judgment rules of the system detection configuration file through a configuration merging algorithm to generate the complete detection configuration.

[0008] Optionally, the preset categories of detection items include third-party software detection, network function detection, system configuration detection, network card function detection, and kernel configuration detection. The step of executing the preset categories of detection items in a preset order, and capturing the command exit status code, standard output stream, and standard error stream for each detection item during execution, includes: verifying whether the target device has installed the third-party tools required for hardware and system compatibility based on the required_commands list of the complete detection configuration, to obtain a first judgment result; verifying the integrity of the target device's bridging, network namespace, and virtual network device functions based on the network virtualization function parameters of the complete detection configuration, to obtain a second judgment result; verifying whether the target device's kdump service status, kernel parameters, and network parameters meet compatibility requirements based on the system-level configuration standards set by the complete detection configuration, to obtain a third judgment result; verifying the target device's network card basic configuration, performance functions, and multi-queue capabilities based on the network card hardware characteristic parameters recorded by the complete detection configuration, to obtain a fourth judgment result; and verifying whether the target device's kernel's key configurations meet hardware and system compatibility requirements based on the kernel compilation configuration preset by the complete detection configuration, to obtain a fifth judgment result.

[0009] Optionally, the determination rules include exact matching rules, numerical comparison rules, inclusion relationship matching rules, and regular expression matching rules; wherein, the exact matching rule requires that the actual output of the detection command be completely consistent with the preset expected value; the numerical comparison rule converts the actual output into a numerical value and compares it with a preset threshold for range or size; the inclusion relationship matching rule verifies whether the preset content exists in the actual output; and the regular expression matching rule verifies whether the actual output format meets the requirements using a preset regular expression.

[0010] Optionally, the step of collecting the judgment results, execution time, and detailed logs of all test items to generate a visual test report includes: collecting the first judgment result, the second judgment result, the third judgment result, the fourth judgment result, the fifth judgment result, and the execution time and detailed logs corresponding to each judgment result; using green to indicate passed test items and red to indicate failed test items; displaying the test data of each test item in a hierarchical manner according to the order of overview-category statistics-detailed results; generating corresponding problem analysis and solution suggestions for failed test items; and providing collapse / expand, category filtering, and keyword search functions for the test results of each test item.

[0011] Secondly, this application provides a hardware and system compatibility testing device, comprising:

[0012] The acquisition module is used to acquire the device configuration file and the system detection configuration file. The device configuration file includes the SSH connection parameters of the target detection device, the device model, and a list of test cases to be executed. The system detection configuration file is a test file pre-configured according to the operating system and hardware architecture of the target detection device.

[0013] A connection establishment module is used to establish an encrypted SSH connection with the target detection device based on the SSH connection parameters in the device configuration file and using an encryption protocol.

[0014] The generation module is used to load the corresponding system detection configuration file based on the device model in the device configuration file, and to deeply merge the device configuration file and the system detection configuration file to generate a complete detection configuration;

[0015] The detection module is used to execute detection items of a preset category in a preset order, and capture the command exit status code, standard output stream and standard error stream of each detection item during the execution process, and determine the success or failure of the detection results based on the judgment rules in the complete detection configuration to obtain the judgment result;

[0016] The report generation module is used to collect the judgment results, execution time and detailed logs of all test items and generate a visual test report.

[0017] Thirdly, this application provides a computer device, 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 implement the steps of the hardware and system compatibility testing method described in any one of the above.

[0018] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the hardware and system compatibility detection method described in any one of the above descriptions.

[0019] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the hardware and system compatibility detection method described in any one of the above descriptions.

[0020] According to the specific embodiments provided in this application, the following technical effects are disclosed:

[0021] This application provides a hardware and system compatibility testing method, apparatus, device, medium, and product. It loads the corresponding system testing configuration file based on the device model in the device configuration file, and deeply merges the device configuration file and the system testing configuration file to generate a complete testing configuration. It executes preset categories of testing items in a preset order, capturing the command exit status code, standard output stream, and standard error stream for each testing item during execution. Based on the judgment rules in the complete testing configuration, it determines the success or failure of the testing results, obtaining a judgment result. By collecting the judgment results, execution time, and detailed logs of all testing items, it generates a visual testing report. This allows for fully automated execution without manual intervention, improving the efficiency of hardware and system compatibility testing. The generated complete testing configuration allows for compatibility with multiple operating systems without modifying the execution program, effectively improving the flexibility of hardware and system compatibility. The generated visual testing report facilitates technicians in quickly locating the cause of failure, shortening troubleshooting time, and improving testing efficiency to a certain extent. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A schematic flowchart illustrating a hardware and system compatibility testing method provided in an embodiment of this application;

[0024] Figure 2 A schematic diagram of the functional modules of a hardware and system compatibility testing device provided in an embodiment of this application;

[0025] Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0027] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0028] In one exemplary embodiment, such as Figure 1 As shown, a hardware and system compatibility testing method is provided. This method is executed by a computer device, specifically by a terminal or server alone, or by both a terminal and a server. In this embodiment, the method is described using a terminal as an example, and includes the following steps S101 to S105. Wherein:

[0029] Step S101: Obtain the device configuration file and the system detection configuration file.

[0030] In the example embodiment, both the device configuration file and the system detection configuration file adopt the YAML format. The device configuration file includes the SSH connection parameters of the target detection device, the device model, and a list of test cases to be executed. The system detection configuration file is a test file pre-configured according to the operating system and hardware architecture of the target detection device. The system detection configuration files include ubuntu_x86.yml, ubuntu_arm.yml, openeuler_x86.yml, openeuler_arm.yml, and openwrt_arm.yml.

[0031] It should be noted that when reading the device configuration file, the Python-based PyYAML library executes the yaml.safe_load() function to parse the file content and automatically verifies the completeness and format compliance of required fields (such as SSH IP address and device model) (such as whether the IP address conforms to the format "xxx.xxx.xxx.xxx"). If there are any missing or incorrect fields, a prompt will be output and the process will be terminated.

[0032] Step S102: Based on the SSH connection parameters in the device configuration file, establish an encrypted SSH connection with the target detection device using an encryption protocol.

[0033] In the example embodiment, based on the SSH connection parameters in the device configuration file, an encrypted remote connection with the target detection device is established using the SSH protocol. The specific implementation method is as follows:

[0034] The SSHClient object is created using the paramiko library, and a connection timeout is set (default 10 seconds) to prevent program blocking due to network anomalies. Password authentication is supported; the username and password in the configuration file are loaded, and the ssh.connect() method is executed to initiate an encrypted connection, ensuring the security of data transmission. If a network interruption occurs (e.g., the target device is offline), the target device IP address is output: "Network unreachable, please check the link." If authentication fails (e.g., incorrect password), the error message "Username / password incorrect" or "Target device rejects SSH login for this account" is output, facilitating quick troubleshooting of connection problems. A single SSH connection is maintained throughout the entire testing process to avoid resource consumption (e.g., reducing TCP handshake counts) and efficiency loss caused by repeatedly establishing connections.

[0035] Step S103: Based on the device model in the device configuration file, load the corresponding system detection configuration file, and deeply merge the device configuration file and the system detection configuration file to generate a complete detection configuration.

[0036] In the example implementation, to adapt to the operating system and hardware architecture characteristics of the target device, it is necessary to load the corresponding system detection configuration file based on the device model and merge it to generate a complete detection configuration, namely:

[0037] The device model field (e.g., ubuntu_x86) is extracted from the device configuration file. Based on a preset naming convention (e.g., {device model}.yml), the corresponding system detection configuration file (e.g., "ubuntu_x86.yml") is automatically located and loaded. A built-in merging algorithm is used to fuse key information from the two configuration files: retaining SSH connection parameters and basic device information (e.g., CPU model, network card list) from the device configuration file; merging detection items, command templates, and judgment rules from the system detection configuration file; and verifying that the merged complete detection configuration contains the preset categories of detection items and the judgment rules for each detection item. If any information is missing, the configuration merging fails, indicating a missing command template for the xxx detection item, ensuring that subsequent detections can be executed normally.

[0038] Optionally, a merging algorithm can be configured to merge the connection information of the device configuration file, the basic parameters of the device, and the detection items, detection command templates, and judgment rules of the system detection configuration file to generate a complete detection configuration.

[0039] It should be noted that the determination rules in this application embodiment include exact matching rules, numerical comparison rules, inclusion relationship matching rules, and regular expression matching rules; wherein, the exact matching rule requires that the actual output of the detection command be completely consistent with the preset expected value; the numerical comparison rule converts the actual output into a numerical value and compares it with a preset threshold for range or size; the inclusion relationship matching rule verifies whether the preset content exists in the actual output; and the regular expression matching rule verifies whether the actual output format meets the requirements through a preset regular expression.

[0040] Step S104: Execute the preset category of detection items in a preset order, and capture the command exit status code, standard output stream and standard error stream of each detection item during the execution process. Then, determine the success or failure of the detection results based on the judgment rules in the complete detection configuration to obtain the judgment result.

[0041] In the example embodiment, the preset categories of detection items include third-party software detection, network function detection, system configuration detection, network card function detection, and kernel configuration detection; the preset order is to set third-party software detection, network function detection, system configuration detection, network card function detection, and kernel configuration detection in sequence.

[0042] In a specific embodiment, step S104 above, which involves executing preset categories of detection items in a preset order and capturing the command exit status code, standard output stream, and standard error stream for each detection item during execution, may include: verifying whether the target device has installed the third-party tools required for hardware and system compatibility based on the required_commands list of the complete detection configuration, and obtaining a first determination result; verifying the integrity of the bridging, network namespace, and virtual network device functions of the target device based on the network virtualization function parameters of the complete detection configuration, and obtaining a second determination result; verifying whether the kdump service status, kernel parameters, and network parameters of the target device meet the compatibility requirements based on the system-level configuration standards set in the complete detection configuration, and obtaining a third determination result; verifying the basic configuration, performance functions, and multi-queue capabilities of the target device's network card based on the network card hardware characteristic parameters recorded in the complete detection configuration, and obtaining a fourth determination result; and verifying whether the key configurations of the target device's kernel meet the hardware and system compatibility requirements based on the kernel compilation configuration items preset in the complete detection configuration, and obtaining a fifth determination result.

[0043] Understandably, based on the complete detection configuration, the detection is performed in a preset order: third-party software detection → network function detection → system configuration detection → network card function detection → kernel configuration detection. Success or failure is output through multi-dimensional result capture and rule-based judgment. Specifically:

[0044] Third-party software detection involves reading the required_commands list from the complete detection configuration and selecting the software commands to be verified (such as brctl, tcpdump, ethtool, iperf3). Then, via SSH connection, these commands are executed one by one on the target device using either the `which` or `command-v` command. If the output includes the command path (e.g., ` / usr / sbin / brctl`), the software is considered installed and compatible (passed). If the output is "command not found", the software is considered not installed and incompatible (failed).

[0045] Network function testing: Tests are performed based on the network virtualization function parameters configured, namely:

[0046] Bridging Functionality: Execute `brctlladdbrtest-br` to create a test bridge, `brctlsetagingtest-br300` to configure the aging time, and `brctlldelbrtest-br` to delete the bridge. If the entire process is error-free (exit status code is 0), the bridging function is considered compatible. Network Namespaces: Execute `ipnetnsaddtest-ns` to create a namespace, `iplinkseteth0netnstest-ns` to move the network interface card (NIC) into the namespace, and `ipnetnsdeltest-ns` to delete the namespace. If the NIC can be moved normally and network isolation within the namespace is effective, compatibility is considered. Virtual Network Devices: Execute `vconfigaddeth0100` to create a VLAN.

[0047] The command `nmcliconaddtypebondifnametest-bondmode802.3ad` creates a Bond. If the device can be successfully created, configured, and deleted, it is considered compatible.

[0048] System configuration check: Verification is performed based on the system-level configuration standards in the configuration, namely:

[0049] kdump service: Executing `systemctl.lis-activekdump` and seeing "active" indicates the service is working correctly and compatible. Parsing the ` / proc / cmdline` file, if it contains `crashkernel=128M` (consistent with the default threshold), the crashkernel configuration is compatible. Kernel parameters: Executing `ulimit -c` verifies the kernel dump configuration (if the output is "unlimited" and consistent with the default), and `sysctl.lkernel.softlockup_panic` verifies soft lockup detection (if the output is "1" and consistent with the default), then compatibility is confirmed. Network parameters: Executing `sysctlnet.ipv4.ip_forward` verifies IP forwarding (if the output is "1" and consistent with the default), and `sysctlnet.ipv4.conf.all.accept_arp_filter` verifies ARP filtering (if the output is "0" and consistent with the default), then compatibility is confirmed.

[0050] Network interface card (NIC) functionality testing: Based on the NIC hardware characteristic parameters in the configuration, namely: Basic configuration: Execute `ifconfig eth0 mtu9000` to modify the MTU, and `ifconfig eth0 hwether00:11:22:33:44:55` to modify the MAC address. Then execute `ifconfig eth0` to verify that the parameters take effect, and compatibility is determined; Performance functionality: Execute `ethtool -K eth0 tsoon` to enable TSO uninstallation, and `ethtool -s eth0 speed1000 duplexfull` to set the speed. If the output status of `ethtool eth0` is consistent with the configuration, compatibility is determined; Multi-queue capability: Execute `ethtool -leth0` to query the number of supported queues (e.g., output combined:8). If it is ≥ the configured preset threshold (e.g., 4), compatibility is determined.

[0051] Kernel configuration detection: Read the / boot / config-$(uname-r) file (which stores the kernel compilation configuration) of the target device, read the list of preset kernel configuration items (such as CONFIG_KDUMP, CONFIG_CRASH_DUMP, CONFIG_NET_VLAN) from the complete detection configuration, and execute grep configuration item / boot / config-$(uname-r); if the output is CONFIG_KDUMP=y (built-in) or CONFIG_NET_VLAN=m (module), and it is consistent with the preset configuration state, then it is considered compatible; if the output is #CONFIG_KDUMPisnotset (not set), then it is considered incompatible.

[0052] Based on the characteristics of the testing items, four types of judgment rules are used to verify the results and ensure the accuracy of the judgment, namely:

[0053] Exact matching rule: The actual output of the detection command must be exactly the same as the preset expected value (e.g., in system configuration detection, the output 1 of sysctlnet.ipv4.ip_forward must be exactly the same as the preset 1).

[0054] Numerical comparison rules: After converting the actual output into a numerical value, compare it with a preset threshold (e.g., in network card speed detection, the output Speed: 1000Mb / s of ethtooleth0 must be ≥ the preset 1000Mb / s).

[0055] Inclusion matching rules: Verify whether the preset content exists in the actual output (e.g., in third-party software detection, the output of whichbrctl must include / usr / sbin / brctl).

[0056] Regular expression matching rules: The output format is verified by a preset regular expression (e.g., in kernel configuration detection, the regular expression CONFIG_KDUMP=(y|m) is used to match the output to ensure that the configuration item is built-in or module status).

[0057] Meanwhile, an independent timeout control is set for each detection command (default 30 seconds, which can be adjusted in the configuration). By capturing socket timeout and pipe timeout exceptions, the overall detection process is prevented from being blocked by individual commands (such as slow execution of ethtool-leth0). After a timeout, the project is automatically judged as failed, and detailed logs of command execution timeout are recorded.

[0058] Step S105: Collect the judgment results, execution time and detailed logs of all detection items, and generate a visual detection report.

[0059] As can be understood from the above embodiments, the results data of all testing items are collected, and a visual testing report in HTML format is generated through structured processing and visualization. Specifically:

[0060] The report summarizes the judgment results (pass / fail), execution time (e.g., 2.5 seconds for third-party software testing), and detailed logs (e.g., command output, expected value, and actual value for failed items) for five major categories of testing items. Data is organized hierarchically by testing category → testing item → result details, for example, network function testing → bridging function → pass (execution command: brctladdbrtest-br; output: no errors). Passed items are indicated in green, and failed items in red for easy identification of result status. The report is presented in the order of overview → category statistics → detailed results: displaying the testing equipment model, testing time, total number of items, and pass / fail statistics (e.g., 10 tests, 7 pass, 3 fail); categorized by third-party software... The system displays the pass rate for each category, such as network functions (e.g., system configuration check: 4 out of 5 items passed, pass rate 80%); it also displays the execution command, output content, judgment rules, and failure reason (if failed) for each item; it supports collapsing / expanding (clicking on a failed item will display the complete log), category filtering (e.g., only displaying "failed" items), and keyword search (entering "kdump" will quickly locate related items); and it automatically matches solutions for failed items, such as missing iperf3 → suggesting sudo apt install iperf3 to install it, or the kernel configuration item CONFIG_KDUMP not set → suggesting recompiling the kernel and enabling this configuration.

[0061] Optionally, the system collects the first, second, third, fourth, and fifth judgment results, along with the execution time and detailed logs corresponding to each judgment result. It uses green to indicate passed test items and red to indicate failed test items. The system displays the test data for each test item in a hierarchical manner, following the order of overview, categorized statistics, and detailed results. It generates corresponding problem analyses and solutions for failed test items. The system provides collapse / expand, categorized filtering, and keyword search functions for the test results of each test item.

[0062] It should be noted that the visual detection report in this application embodiment includes report header information, report summary, test result statistics, and detailed test result table.

[0063] By implementing steps S101 to S105, the corresponding system detection configuration file is loaded based on the device model in the device configuration file. The device configuration file and the system detection configuration file are then deeply merged to generate a complete detection configuration. Pre-defined categories of detection items are executed in a preset order, and the command exit status code, standard output stream, and standard error stream for each detection item are captured during execution. The success or failure of the detection results is determined based on the judgment rules in the complete detection configuration. A visual detection report is generated by collecting the judgment results, execution time, and detailed logs of all detection items. This process enables fully automated execution without manual intervention, improving the efficiency of hardware and system adaptation testing. The generated complete detection configuration allows for adaptation to multiple operating systems without modifying the execution program, effectively improving the flexibility of hardware and system adaptation. The generated visual detection report facilitates technicians in quickly locating the cause of failure, shortening troubleshooting time, and improving testing efficiency to a certain extent.

[0064] Based on the same inventive concept, this application also provides a hardware and system compatibility testing apparatus for implementing the above-described hardware and system compatibility testing method. The solution provided by this apparatus is similar to the implementation described in the above-described method; therefore, the specific limitations in one or more hardware and system compatibility testing apparatus embodiments provided below can be found in the limitations of the hardware and system compatibility testing method described above, and will not be repeated here.

[0065] In one exemplary embodiment, such as Figure 2 As shown, a hardware and system compatibility testing device 200 is provided. The device includes: an acquisition module 201, a connection establishment module 202, a generation module 203, a detection module 204, and a report generation module 205.

[0066] The acquisition module 201 is used to acquire the device configuration file and the system detection configuration file. The device configuration file includes the SSH connection parameters of the target detection device, the device model, and the list of test cases to be executed. The system detection configuration file is a test file pre-configured according to the operating system and hardware architecture of the target detection device.

[0067] The connection establishment module 202 is used to establish an encrypted SSH connection with the target detection device based on the SSH connection parameters in the device configuration file and using an encryption protocol;

[0068] The generation module 203 is used to load the corresponding system detection configuration file based on the device model in the device configuration file, and to deeply merge the device configuration file and the system detection configuration file to generate a complete detection configuration.

[0069] The detection module 204 is used to execute the detection items of the preset category in a preset order, and capture the command exit status code, standard output stream and standard error stream of each detection item during the execution process, and determine the success or failure of the detection results based on the judgment rules in the complete detection configuration to obtain the judgment result;

[0070] The report generation module 205 is used to collect the judgment results, execution time and detailed logs of all test items and generate a visual test report.

[0071] As an optional implementation, both the device configuration file and the system detection configuration file are in YAML format; the system detection configuration files include ubuntu_x86.yml, ubuntu_arm.yml, openeuler_x86.yml, openeuler_arm.yml and openwrt_arm.yml.

[0072] As an optional implementation, the above-mentioned generation module 203 is specifically used to merge the connection information of the device configuration file, the basic parameters of the device, and the detection items, detection command templates, and judgment rules of the system detection configuration file through a configuration merging algorithm to generate a complete detection configuration.

[0073] As an optional implementation, the aforementioned preset categories of detection items include third-party software detection, network function detection, system configuration detection, network card function detection, and kernel configuration detection. Specifically, the detection module 204 is used to: verify whether the target device has installed the third-party tools required for hardware and system compatibility based on the required_commands list of the complete detection configuration, obtaining a first judgment result; verify the integrity of the target device's bridging, network namespace, and virtual network device functions based on the network virtualization function parameters of the complete detection configuration, obtaining a second judgment result; verify whether the target device's kdump service status, kernel parameters, and network parameters meet compatibility requirements based on the system-level configuration standards set in the complete detection configuration, obtaining a third judgment result; verify the target device's network card's basic configuration, performance functions, and multi-queue capabilities based on the network card hardware characteristic parameters recorded in the complete detection configuration, obtaining a fourth judgment result; and verify whether the target device's kernel's key configurations meet hardware and system compatibility requirements based on the kernel compilation configuration items preset in the complete detection configuration, obtaining a fifth judgment result.

[0074] As an optional implementation, the above-mentioned judgment rules include exact matching rules, numerical comparison rules, inclusion relationship matching rules, and regular expression matching rules; wherein, the exact matching rule requires that the actual output of the detection command be completely consistent with the preset expected value; the numerical comparison rule converts the actual output into a numerical value and compares it with a preset threshold in terms of range or size; the inclusion relationship matching rule verifies whether the preset content exists in the actual output; and the regular expression matching rule verifies whether the actual output format meets the requirements through a preset regular expression.

[0075] As an optional implementation, the report generation module 205 is specifically used to collect the first judgment result, the second judgment result, the third judgment result, the fourth judgment result, the fifth judgment result, and the execution time and detailed logs corresponding to each judgment result; to use green to mark the passed test items and red to mark the failed test items; to display the test data of each test item in a hierarchical manner in the order of overview-category statistics-detailed results; to generate corresponding problem analysis and solution suggestions for the failed test items; and to provide folding / expanding, category filtering, and keyword search functions for the test results of each test item.

[0076] This implementation method loads the corresponding system test configuration file based on the device model in the device configuration file, and deeply merges the device configuration file and the system test configuration file to generate a complete test configuration. It executes preset categories of test items in a preset order, capturing the command exit status code, standard output stream, and standard error stream for each test item during execution. Based on the judgment rules in the complete test configuration, it determines the success or failure of the test results. By collecting the judgment results, execution time, and detailed logs of all test items, it generates a visual test report. This method enables fully automated execution without manual intervention, improving the efficiency of hardware and system adaptation testing. The generated complete test configuration allows for adaptation to multiple operating systems without modifying the execution program, effectively improving the flexibility of hardware and system adaptation. The generated visual test report facilitates technicians in quickly locating the cause of failure, shortening troubleshooting time, and improving testing efficiency to a certain extent.

[0077] In an exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as shown in Figure 3. The computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is connected to the system bus via the I / O interfaces. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device stores hardware and system compatibility testing data. The I / O interfaces of the computer device are used for exchanging information between the processor and external devices. The communication interface of the computer device is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a hardware and system compatibility testing method.

[0078] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0079] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0080] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0081] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0082] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0083] 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, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0084] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0085] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0086] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for hardware and system compatibility testing, characterized in that, The hardware and system compatibility testing methods include: Obtain the device configuration file and the system detection configuration file. The device configuration file includes the SSH connection parameters of the target detection device, the device model, and a list of test cases to be executed. The system detection configuration file is a test file pre-configured according to the operating system and hardware architecture of the target detection device. Based on the SSH connection parameters in the device configuration file, an encrypted SSH connection with the target detection device is established using an encryption protocol; during the connection process, the username and password in the configuration file are loaded, and the ssh.connect() method is executed to initiate an encrypted connection; and a single SSH connection is maintained throughout the entire detection process; Based on the device model in the device configuration file, the corresponding system detection configuration file is loaded, and the device configuration file and the system detection configuration file are deeply merged to generate a complete detection configuration. Specifically, the device model field is extracted from the device configuration file, and the corresponding system detection configuration file is automatically located and loaded according to a preset naming convention. The SSH connection parameters and basic device information in the device configuration file are retained through a built-in merging algorithm, and the detection items, command templates, and judgment rules in the system detection configuration file are merged to generate a complete detection configuration. The complete detection configuration is verified to ensure that subsequent detections can be executed normally. The system executes preset categories of detection items in a preset order, and captures the command exit status code, standard output stream, and standard error stream for each detection item during execution. Based on the judgment rules in the complete detection configuration, the system determines the success or failure of the detection results and obtains the judgment result. Collect the judgment results, execution time and detailed logs of all test items, and generate a visual test report.

2. The hardware and system compatibility testing method according to claim 1, characterized in that, Both the device configuration file and the system detection configuration file are in YAML format. The system detection configuration files include ubuntu_x86.yml, ubuntu_arm.yml, openeuler_x86.yml, openeuler_arm.yml, and openwrt_arm.yml.

3. The hardware and system compatibility testing method according to claim 1, characterized in that, The preset categories of detection items include third-party software detection, network function detection, system configuration detection, network card function detection, and kernel configuration detection; The process of executing preset categories of detection items in a preset order, and capturing the command exit status code, standard output stream, and standard error stream for each detection item during execution, includes: Based on the required_commands list of the complete detection configuration, verify whether the target device has installed the third-party tools required for hardware and system compatibility, and obtain the first determination result; Based on the network virtualization function parameters of the complete detection configuration, the integrity of the bridging, network namespace and virtual network device functions of the target device is verified to obtain a second judgment result. Based on the system-level configuration standards set by the complete detection configuration, the kdump service status, kernel parameters and network parameters of the target device are verified to meet the compatibility requirements, and a third judgment result is obtained. Based on the network card hardware characteristic parameters of the complete detection configuration record, the basic configuration, performance functions and multi-queue capabilities of the target device's network card are verified to obtain the fourth judgment result. Based on the kernel compilation configuration items preset in the complete detection configuration, the key configuration of the target device kernel is verified to meet the hardware and system compatibility requirements, and the fifth judgment result is obtained.

4. The hardware and system compatibility testing method according to claim 3, characterized in that, The judgment rules include exact matching rules, numerical comparison rules, inclusion relationship matching rules, and regular expression matching rules; wherein, the exact matching rule requires that the actual output of the detection command be completely consistent with the preset expected value; the numerical comparison rule converts the actual output into a numerical value and compares it with a preset threshold for range or size; the inclusion relationship matching rule verifies whether the preset content exists in the actual output; and the regular expression matching rule verifies whether the actual output format meets the requirements through a preset regular expression.

5. The hardware and system compatibility testing method according to claim 3, characterized in that, The process involves collecting the judgment results, execution time, and detailed logs of all detection items to generate a visual detection report, including: Collect the first judgment result, the second judgment result, the third judgment result, the fourth judgment result, the fifth judgment result, and the execution time and detailed logs corresponding to each judgment result, and use green to mark the passed detection items and red to mark the failed detection items; The test data for each test item are displayed hierarchically in the order of overview, category statistics, and detailed results. For failed detection items, generate corresponding problem analysis and solution suggestions; The test results for each test item are provided with collapse / expand, category filtering, and keyword search functions.

6. A hardware and system compatibility testing device, characterized in that, The hardware and system compatibility testing device includes: The acquisition module is used to acquire the device configuration file and the system detection configuration file. The device configuration file includes the SSH connection parameters of the target detection device, the device model, and a list of test cases to be executed. The system detection configuration file is a test file pre-configured according to the operating system and hardware architecture of the target detection device. A connection establishment module is used to establish an encrypted SSH connection with the target detection device based on the SSH connection parameters in the device configuration file and using an encryption protocol. During the connection process, the username and password in the configuration file are loaded, and the ssh.connect() method is executed to initiate the encrypted connection. A single SSH connection is maintained throughout the entire detection process. The generation module is used to load the corresponding system detection configuration file based on the device model in the device configuration file, and to deeply merge the device configuration file and the system detection configuration file to generate a complete detection configuration. Specifically, it extracts the device model field from the device configuration file, automatically locates and loads the corresponding system detection configuration file according to a preset naming convention, retains the SSH connection parameters and basic device information in the device configuration file through a built-in merging algorithm, merges the detection items, command templates, and judgment rules in the system detection configuration file, and generates a complete detection configuration. It verifies whether the complete detection configuration contains the necessary information to ensure that subsequent detections can be executed normally. The detection module is used to execute detection items of a preset category in a preset order, and capture the command exit status code, standard output stream and standard error stream of each detection item during the execution process, and determine the success or failure of the detection results based on the judgment rules in the complete detection configuration to obtain the judgment result; The report generation module is used to collect the judgment results, execution time and detailed logs of all test items and generate a visual test report.

7. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the steps of the hardware and system compatibility testing method according to any one of claims 1-5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the hardware and system compatibility testing method according to any one of claims 1-5.

9. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the hardware and system compatibility testing method according to any one of claims 1-5.

Images