Method and device for testing compatibility of server operating system
By configuring automated operating system compatibility testing through pipeline configuration, the problems of tedious and repetitive work in traditional methods are solved, and efficient and accurate test results are achieved.
Patent Information
- Application Number
- CN202510715181.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-30
- Publication Date
- 2025-10-03
AI Technical Summary
Traditional operating system compatibility testing methods are complex and require manual configuration of test scripts, resulting in a large amount of repetitive work and affecting testing efficiency and accuracy.
A pipeline configuration approach is adopted, and the process is controlled by the Jenkins pipeline to automate the execution of operating system compatibility tests. This includes steps such as downloading test scripts, configuring offline sources, installing test tools, and preparing the environment, ensuring that the testing process is standardized and streamlined.
It reduces manual operations, improves testing efficiency and accuracy, ensures the consistency and reliability of test results, and shortens the testing cycle.
Smart Images

Figure CN120743749A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of compatibility testing, and in particular to a server operating system compatibility testing method and device. Background Art
[0002] In today's digital age, operating systems, as the core software of computer systems, shoulder critical responsibilities such as managing hardware resources and providing an environment for application runtimes. With the rapid development of information technology, a wide variety of operating system types and versions have emerged on the market, along with a growing number of software products. To ensure that these software products can run stably and efficiently in diverse operating system environments, operating system compatibility testing has become an essential step in the software development and release process. Traditional operating system compatibility testing methods suffer from numerous drawbacks, severely hindering testing efficiency and quality. The testing process is extremely complex, requiring testers to design and write specific test scripts for each target operating system. Furthermore, when compatibility testing requires adapting different operating systems to multiple servers simultaneously, traditional methods result in a significant amount of repetitive manual work. This repetitive work not only consumes significant manpower and time, but is also prone to errors due to human negligence, compromising the accuracy and reliability of test results. Summary of the Invention
[0003] In order to solve the above technical problems, the present invention is proposed. Embodiments of the present invention provide a server operating system compatibility testing method and apparatus, which can improve the compatibility testing speed and quality.
[0004] According to one aspect of the present invention, a server operating system compatibility testing method is provided, comprising: obtaining a task script and a test parameter configuration; wherein the task script includes a process of operating system compatibility testing, and the process of operating system compatibility testing includes: downloading a test script, configuring an offline source, installing a test tool, initial preparation of the environment, and performing at least one of actual tests; based on the task script, generating a pipeline task; based on the test instructions and the test parameter configuration, starting the pipeline task; wherein the pipeline task runs on a server where the pipeline is deployed, and the server where the pipeline is deployed and the server to be tested are in the same network environment; based on the started pipeline task, executing a pipeline test on the server to be tested.
[0005] In one embodiment, the task script includes a groovy script; wherein, based on the task script, a pipeline task is generated, including: Jenkins generates pipeline steps according to the operating system compatibility test process written in the groovy script; wherein, the pipeline steps include at least one of downloading test scripts, configuring offline sources, installing test tools, initial preparation of the environment and performing actual tests; in the pipeline steps, a skip option is configured for the pipeline steps that need to be skipped; and a pipeline task is generated based on the skip option, the pipeline steps and the test parameters.
[0006] In one embodiment, based on the started pipeline task, a pipeline test is performed on the server to be tested, including: during the process of executing the pipeline test on the server to be tested, when any pipeline step is completed, a status check is performed on the completed pipeline step to obtain the step status check result; the step status check result is integrated and a test result notification is generated; when the server to be tested completes the pipeline test, the test result notification is sent.
[0007] In one embodiment, based on the test instruction and the test parameter configuration, a pipeline task is started, including: based on the test instruction, starting a pipeline concurrent task; after the pipeline concurrent task is started, downloading the configuration information of the pipeline task based on the test parameter configuration; parsing the configuration information of the pipeline task and extracting the test parameters; wherein, based on the started pipeline task, a pipeline test is performed on the server to be tested, including: based on the extracted test parameters, executing a pipeline control process on the server to be tested.
[0008] In one embodiment, based on the started pipeline task, a pipeline test is performed on the server to be tested, including: downloading a test script and placing the test script in a designated directory of the server to be tested; determining the test type of the server to be tested according to the test parameter configuration; installing corresponding test work according to the test type of the server to be tested; performing network configuration on the network environment of the server to be tested; wherein, when the server network setting of the server to be tested is a temporary setting, solidifying the network configuration of the server to be tested; performing at least one of benchmark testing, southbound compatibility testing, LTP functional testing and LTP stress testing on the server to be tested.
[0009] In one embodiment, the benchmark test includes: performing benchmark performance tests on the operating system, CPU, memory, hard disk, and network of the server to be tested; and the southbound compatibility test includes verifying the compatibility of the server, board, and operating system of the server to be tested.
[0010] In one embodiment, performing southbound compatibility testing on the server to be tested includes: performing hardware compatibility testing using oec-hardware; writing an Expect script and presetting interactive content; based on the preset interactive content, simulating the interaction process between the user and the oec-hardware tool by controlling the Expect script to execute the test task.
[0011] In one embodiment, a server operating system compatibility testing method includes: after completing the LTP functional test, summarizing the failed use cases and retesting; recording the use cases that failed the LTP functional test; when all the test cases of the LTP functional test pass, performing the LTP stress test; recording the failed use cases in the LTP stress test and the test pass rate.
[0012] In one embodiment, based on the started pipeline task, pipeline testing is performed on the server to be tested, and the method also includes: when the test environment of the server to be tested is an offline test, obtaining the server information of the server to be tested and the system information of the operating system; wherein, the server information includes the host name and IP address of the server, and the system information includes the operation type and version number of the operating system; according to the requirements of the test tool of the server to be tested, collecting offline sources and transmitting them to the server to be tested in the offline environment; according to the type and version of the operating system of the server to be tested, matching the corresponding offline sources and installing them.
[0013] According to another aspect of the present invention, a server operating system compatibility testing device is provided, including: an acquisition module for acquiring a task script and a test parameter configuration; wherein the task script includes the process of the operating system compatibility test, and the process of the operating system compatibility test includes: downloading the test script, configuring an offline source, installing a test tool, initial preparation of the environment, and performing at least one of actual tests; a generation module for generating a pipeline task based on the task script; a startup module for starting the pipeline task based on the test instruction and the test parameter configuration; wherein the pipeline task runs on a server where the pipeline is deployed, and the server where the pipeline is deployed and the server to be tested are in the same network environment; a testing module for performing a pipeline test on the server to be tested based on the started pipeline task.
[0014] The server operating system compatibility testing method and device provided by the present invention combine the pipeline with the operating system compatibility test. Through the pipeline configuration, the testing process can be standardized and procedurally executed. When compatibility testing is required, it is only necessary to trigger the start of the pipeline, and the corresponding pipeline tasks will be automatically executed on each server to be tested according to the scripted process without manual intervention, thereby reducing the workload of manual operations, improving testing efficiency, ensuring the consistency and repeatability of the testing process, and improving the accuracy and reliability of the test results. BRIEF DESCRIPTION OF THE DRAWINGS
[0015] The above and other objects, features, and advantages of the present invention will become more apparent through a more detailed description of the embodiments of the present invention in conjunction with the accompanying drawings. The accompanying drawings are provided to provide a further understanding of the embodiments of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and are not intended to limit the present invention. In the drawings, the same reference numerals generally represent the same components or steps.
[0016] Figure 1 The figure is a flow chart of a server operating system compatibility testing method provided by an exemplary embodiment of the present invention.
[0017] Figure 2 It is a structural diagram of a server operating system compatibility testing device provided by an exemplary embodiment of the present invention. DETAILED DESCRIPTION
[0018] Below, the exemplary embodiments according to the present invention will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments of the present invention, and it should be understood that the present invention is not limited to the exemplary embodiments described herein.
[0019] Traditional operating system compatibility testing methods have complicated testing processes and require manual configuration of test scripts. When multiple servers are adapted at the same time, there are a lot of repeated manual operations. To solve this problem, this application can standardize the testing process and execute it in a procedural manner through pipeline configuration. Figure 1 This is a flow chart of a server operating system compatibility testing method provided by an exemplary embodiment of the present invention. Figure 1 For example, first, obtain the task script and test parameter configuration (see Figure 1 S110); wherein the task script includes the process of operating system compatibility testing, and the process of operating system compatibility testing includes at least one of: downloading test scripts, configuring offline sources, installing test tools, initial preparation of the environment, and performing actual testing. Then, based on the task script, a pipeline task is generated (see Figure 1Then, based on the test instructions and test parameter configuration, the pipeline task is started (see Figure 1 S130); wherein, the pipeline task runs on the server where the pipeline is deployed, and the server where the pipeline is deployed and the server to be tested are in the same network environment. Finally, based on the started pipeline task, the pipeline test is performed on the server to be tested (see Figure 1 S140).
[0020] In some embodiments, the deployment pipeline server is a computer device or virtual instance specifically designed to run and manage the software deployment pipeline. A deployment pipeline is a collection of automated steps used to gradually push software code from the development stage to the production environment, including code compilation, building, testing, and deployment. This server is responsible for coordinating and organizing the execution of these steps, ensuring that the entire deployment process follows predetermined procedures and rules. A test server is a computer device or virtual instance used to test software. During the software development process, developers deploy the built software to the test server and then run various test cases to verify that the software meets requirements for functionality, performance, and stability. Offline source servers are primarily used to store and manage resources such as source code, dependency libraries, and configuration files for software projects. Due to security and network restrictions, these resources may not be directly accessible from the external network or may need to be managed in a relatively independent environment. Therefore, offline source servers are used to provide these resources. Ensure that all three servers are located in the same network environment. Network connectivity between them can be achieved by configuring network routing and subnetting. For example, in an enterprise's internal network, they can be connected to the same switch or router and assigned corresponding IP addresses so that they can access each other.
[0021] As a possible implementation method, when executing the deployment process, the server in the deployment pipeline deploys the built software package to the server under test for testing. At the same time, the server under test will feed back the test results to the server in the deployment pipeline. The server in the deployment pipeline decides whether to proceed with subsequent deployment steps (such as deployment to the production environment) based on the test results. When executing steps such as code building, the server in the deployment pipeline needs to obtain the project's source code and related dependency libraries from the offline source server. The offline source server provides a stable source of resources for the server in the deployment pipeline, ensuring that the deployment process can proceed smoothly.
[0022] In some embodiments, Jenkins is an open source CI&CD software for automating various tasks, including building, testing, and deploying software. Jenkins provides an easy-to-use graphical interface that can automate build and deployment processes by configuring simple tasks. Jenkins can be integrated with various version control systems (such as git, SVN) and build tools (such as Maven, Gradle), supporting multiple programming languages and platforms. The present invention is based on the Jenkins pipeline control process, and gitlab stores test scripts for version control to achieve automation and standardization of operating system compatibility testing.
[0023] By configuring and starting pipeline tasks, you can ensure that each test follows the same steps and rules. Once a pipeline task is started, it automatically executes the pre-set tasks, eliminating the discrepancies and errors that can arise from manual operation. This ensures consistent and repeatable test results, which is crucial for software quality assessment and problem troubleshooting. Furthermore, automated pipelines enable fast and efficient test execution. Once a pipeline task is started, the system automatically completes a series of tedious operations without manual intervention, significantly shortening the testing cycle. Furthermore, pipelines can execute multiple test tasks in parallel, further improving testing efficiency. During pipeline execution, the execution status and results of each task can be monitored in real time. After starting a pipeline task, the system records each task's start time, end time, and execution results, and provides this information to relevant personnel. If a task fails, the system issues a prompt alert, enabling developers to quickly identify and resolve the issue.
[0024] Combined with the following Figure 1 , a more detailed introduction to the server operating system compatibility testing method provided in the embodiment of the present application is given.
[0025] In S110 , the task script and test parameter configuration are obtained.
[0026] In some embodiments, task scripts include Groovy scripts. Jenkins supports the use of Groovy scripts (particularly the Jenkins Pipeline script syntax) to define pipelines. Groovy scripts provide developers with a flexible and powerful way to describe the various stages and tasks of a pipeline, as well as the logical relationships between them. By writing Groovy scripts, you can precisely control the execution process of the pipeline, for example, defining different stages such as build, test, and deployment, and setting specific operations and conditional judgments for each stage. In addition, Groovy scripts allow test parameter configurations (common configurations such as server IP, server username, password, and secret key) to be managed and maintained in code. This allows changes in project requirements to be made by simply modifying the Groovy script, without having to manually operate the Jenkins graphical interface, improving configuration flexibility and maintainability. The Groovy script encompasses the entire operating system compatibility testing process: downloading the test script from Git, configuring the offline source, installing the test tool, initial environment preparation, benchmarking, southbound compatibility testing, LTP (Linux Test Project) functional testing, and LTP (Linux Test Project) stress testing.
[0027] In S120 , a pipeline task is generated based on the task script.
[0028] In some embodiments, Jenkins generates pipeline steps based on the operating system compatibility test process written in a Groovy script. The pipeline steps include at least one of downloading the test script, configuring an offline source, installing the test tool, initializing the environment, and executing the actual test. Within the pipeline steps, skip options are configured for pipeline steps that require skipping. Based on the skip options, pipeline steps, and test parameters, pipeline tasks are generated. By configuring skipped steps within the pipeline, specific test steps can be selected, thereby providing flexibility and variability in testing.
[0029] As a possible implementation, Jenkins provides a web-based graphical interface for configuring pipelines. Jenkins generates pipeline steps based on the test procedures written in Groovy scripts, ensuring that tests are executed sequentially. In other words, developers write a Groovy script to define a pipeline, create a new pipeline task in Jenkins, and upload the Groovy script as the pipeline definition file to Jenkins. The Git repository address is also configured so that Jenkins can retrieve code and configuration information from the repository.
[0030] In some embodiments, during pipeline testing of the server under test, when any pipeline step is completed, a status check is performed on the completed pipeline step to obtain the step status check result; the step status check results are integrated and a test result notification is generated; and when the server under test completes the pipeline test, a test result notification is sent. Status checks are automatically performed after each stage of the pipeline is completed to ensure the orderly progress of the process. Email notifications are integrated and test result notifications are automatically sent after the pipeline is completed, allowing staff to monitor the test and intervene promptly if problems arise.
[0031] In S130 , based on the test instruction and the test parameter configuration, the pipeline task is started.
[0032] Starting a pipeline task is the process of converting the pipeline definition into actual execution. When starting a task, Jenkins will execute the tasks of each stage in sequence according to the pipeline definition, such as downloading code from the Git repository, compiling the code, running test cases, and deploying to the target environment.
[0033] In some embodiments, a concurrent pipeline task is initiated based on a test instruction. After the concurrent pipeline task is initiated, the configuration information for the pipeline task is downloaded based on the test parameter configuration. The pipeline task configuration information is parsed and the test parameters are extracted. Based on the extracted test parameters, the pipeline control process is executed on the server under test. It is understood that initiating a concurrent pipeline task is the starting point for the entire task execution, allowing multiple pipeline task instances to be initiated simultaneously, allowing Jenkins to process pipelines from multiple branches simultaneously. In some scenarios, such as when building and testing multiple code branches simultaneously or processing tasks for multiple projects in parallel, initiating concurrent tasks can improve execution efficiency and fully utilize system resources. Next, after the task is initiated, Jenkins needs to obtain the pipeline task configuration information. This pipeline task configuration information is typically stored in a git repository. By downloading git, Jenkins can obtain the latest task configuration, including build scripts, test cases, deployment targets, and other information. The pipeline task configuration information may include public configuration information such as server IP, server username, password, and secret key. The pipeline task configuration information is parsed and test parameters are extracted for use in subsequent pipeline control processes. By parsing the configuration information, Jenkins determines the specific operations and parameter values required for each stage. Finally, the pipeline control process is executed on the server under test. This process is performed on the server where the pipeline is deployed. This server is located in the same network environment as the test server and the offline source server. To ensure smooth testing, a smooth network environment is ensured.
[0034] As a possible implementation method, the number of concurrent tasks can usually be set in the pipeline configuration file. This number needs to be determined based on the server's resource situation and the nature of the tasks. For example, if the server resources are sufficient and there is no obvious resource competition between tasks, the number of concurrent tasks can be appropriately increased; if the server resources are limited or there is a resource conflict between tasks, the number of concurrent tasks needs to be controlled to avoid system overload. Although tasks are executed concurrently, there may be some logical dependencies. For example, some test tasks may need to be started after the build task is completed. When starting concurrent tasks, these dependencies need to be clarified to ensure the correct execution of the pipeline. This can be achieved by defining the order and triggering conditions of the tasks in the pipeline configuration file.
[0035] In S140 , based on the started pipeline task, a pipeline test is performed on the server to be tested.
[0036] In some embodiments, a test script is downloaded and placed in a designated directory of the server to be tested; the test type of the server to be tested is determined based on the test parameter configuration; the corresponding test work is installed based on the test type of the server to be tested; the network environment of the server to be tested is configured; wherein, when the server network of the server to be tested is set to a temporary setting, the network configuration of the server to be tested is solidified; and at least one of a benchmark test, a southbound compatibility test, an LTP functional test, and an LTP stress test is performed on the server to be tested.
[0037] As you can understand, first, storing the test script in git facilitates version control and source code traceability. When the pipeline task is started, the pipeline control downloads the test script from git and places it in the designated directory of the server under test. Secondly, if the test environment of the server under test is offline, installing the test tool in this environment requires configuring an offline source. The pipeline control script configures the offline source corresponding to the operating system for the server and tests the installation software package to ensure that the offline source is functioning properly and that the software package installs smoothly on the server. For example, the pipeline control script obtains the server information and operating system information of the server under test. Server information includes the server's host name and IP address, and system information includes the operating system type and version number. Based on the requirements of the test tool for the server under test, the offline source is collected and transferred to the server under test in the offline environment. Based on the operating system type and version of the server under test, the corresponding offline source is matched and installed. Next, the parameter settings determine the type of test to be performed on the server. Different servers play different roles in compatibility testing, and testing is performed on different servers. In the extreme case, with only one server, the entire compatibility test process can be performed on the server, but some test items will not be fully tested. Install the test tool based on the server's test type and determine whether the tool has been installed successfully. After the tool has been successfully installed, proceed to the next steps. Next, determine whether the server's network settings are fixed. If they are temporary, fix the network configuration. The benchmark test requires the SELinux parameter to be set to Disabled. This parameter can be set using a script.
[0038] Finally, perform at least one of the following tests on the server: benchmark test, southbound compatibility test, LTP function test, and LTP stress test:
[0039] Benchmark testing is a performance test of server hardware, primarily targeting the operating system, CPU, memory, hard drive, and network. Operating system, CPU, memory, and hard drive testing only applies to the current server under test. Test scripts can be updated based on the disk configuration of the server under test. Network testing determines the script content executed on the server based on the server and client configurations in the pipeline parameters. While testing is in progress, no other tests can be performed on the server; it serves solely as a network test server. Pipeline control benchmark testing only tests items that can be tested in the current server state. Testing items that require a server restart or kernel upgrade requires manual intervention.
[0040] oec-hardware is a hardware compatibility testing tool provided by the openEuler community. It is primarily used to verify the compatibility of server systems, boards, and operating systems, focusing on basic functionality. Southbound compatibility testing uses oec-hardware for hardware compatibility testing. The oec-hardware test project is interactive, requiring continuous human interaction and interactive operations. To prevent test process interruptions caused by interactive operations, Expect scripts are written to pre-set interactive content. The pipeline controls the Expect scripts, simulating the user interaction with the oec-hardware tool and automatically executing test tasks. The interactive process during the test is controlled by parameters, and test items that require a server restart are skipped. Related test items can be supplemented after the pipeline test process is completed.
[0041] LTP (Linux Test Project) is an open-source tool for testing the stability and performance of Linux systems. Through functional, stress, and regression testing, LTP stresses the system to assess its operation under overload conditions, thereby determining its stability and reliability. LTP functional testing is pipelined. After completion, failed tests are automatically aggregated and retested, and any failed tests are recorded. Modifying the configuration of test items in failed tests requires manual intervention, and the automated pipeline process can be stopped at this step, allowing the user to proceed to the next step after the test is completed.
[0042] LTP stress testing requires all functional test cases to pass, and by default, this option is selected. After the functional test retest is complete, click the relevant step in the pipeline to initiate the test. After the test is complete, the test results are automatically processed, and the failure cases and test pass rate are output to facilitate further test report preparation.
[0043] Figure 2 FIG. 1 is a schematic diagram of a server operating system compatibility testing device provided by an exemplary embodiment of the present invention. Figure 2As shown, the server operating system compatibility testing device 2 includes: an acquisition module 21, which is used to obtain a task script and a test parameter configuration; wherein, the task script includes the process of the operating system compatibility test, and the process of the operating system compatibility test includes: downloading the test script, configuring the offline source, installing the test tool, initial preparation of the environment, and performing at least one of the actual tests; a generation module 22, which is used to generate a pipeline task based on the task script; a startup module 23, which is used to start the pipeline task based on the test instruction and the test parameter configuration; wherein, the pipeline task runs on the server where the pipeline is deployed, and the server where the pipeline is deployed and the server to be tested are in the same network environment; a testing module 24, which is used to perform a pipeline test on the server to be tested based on the started pipeline task.
[0044] In one embodiment, the task script includes a groovy script; wherein, the generation module 22 can be configured as: Jenkins generates pipeline steps according to the operating system compatibility test process written in the groovy script; wherein, the pipeline steps include at least one of downloading the test script, configuring the offline source, installing the test tool, initial preparation of the environment and performing the actual test; in the pipeline steps, a skip option is configured for the pipeline steps that need to be skipped; and a pipeline task is generated based on the skip option, the pipeline steps and the test parameters.
[0045] In one embodiment, the test module 24 can be configured as follows: during the process of executing the pipeline test on the server to be tested, when any pipeline step is completed, a status check is performed on the completed pipeline step to obtain the step status check result; the step status check result is integrated and a test result notification is generated; when the pipeline test on the server to be tested is completed, a test result notification is sent.
[0046] In one embodiment, the startup module 23 can be configured to: start the pipeline concurrent task based on the test instruction; after the pipeline concurrent task is started, download the configuration information of the pipeline task based on the test parameter configuration; parse the configuration information of the pipeline task and extract the test parameters; wherein, the test module 24 can be correspondingly configured to: execute the pipeline control process on the server to be tested based on the extracted test parameters.
[0047] In one embodiment, the test module 24 can be configured to: download the test script and place the test script in a designated directory of the server to be tested; determine the test type of the server to be tested based on the test parameter configuration; install the corresponding test work based on the test type of the server to be tested; perform network configuration on the network environment of the server to be tested; wherein, when the server network of the server to be tested is set to a temporary setting, the network configuration of the server to be tested is solidified; perform at least one of benchmark testing, southbound compatibility testing, LTP functional testing and LTP stress testing on the server to be tested.
[0048] In one embodiment, the server operating system compatibility testing device 2 can be configured as follows: benchmark testing includes: benchmark performance testing of the operating system, CPU, memory, hard disk, and network of the server to be tested; southbound compatibility testing includes verifying the compatibility of the server machine, board card, and operating system of the server to be tested.
[0049] In one embodiment, the test module 24 can be configured to: use oec-hardware to perform hardware compatibility testing; wherein, write an Expect script and preset interactive content; based on the preset interactive content, simulate the interaction process between the user and the oec-hardware tool by controlling the Expect script to perform the test task.
[0050] In one embodiment, the server operating system compatibility testing device 2 can be configured as follows: after completing the LTP functional test, summarize the failed use cases and retest; record the use cases that failed the LTP functional test; when all the test cases of the LTP functional test pass, perform the LTP stress test; record the failed use cases in the LTP stress test and the test pass rate.
[0051] In one embodiment, the testing module 24 can be configured as follows: when the test environment of the server to be tested is an offline test, obtain the server information of the server to be tested and the system information of the operating system; wherein the server information includes the host name and IP address of the server, and the system information includes the operation type and version number of the operating system; according to the requirements of the testing tool of the server to be tested, collect offline sources and transmit them to the server to be tested in the offline environment; according to the type and version of the operating system of the server to be tested, match the corresponding offline sources and install them.
[0052] An embodiment of the present invention provides a server operating system compatibility testing device. The device embodiment can be implemented by software, or by hardware, or by a combination of software and hardware. From a hardware perspective, in addition to the CPU, memory, network interface, and non-volatile memory, the device in the embodiment where the device is located can generally also include other hardware, such as a forwarding chip responsible for processing messages, etc. Taking software implementation as an example, as a device in a logical sense, it is formed by the CPU of the device where it is located reading the corresponding computer program instructions in the non-volatile memory into the memory and running them.
[0053] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the storage medium stores a computer program for executing the server operating system compatibility testing method of any of the above embodiments.
[0054] In addition to the above-mentioned methods and devices, an embodiment of the present invention may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps of the server operating system compatibility testing method according to various embodiments of the present invention described above.
[0055] According to another aspect of the present invention, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; and a processor for executing the server operating system compatibility testing method of any of the above embodiments.
[0056] In addition, an embodiment of the present invention may also be a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, causes the processor to execute the steps of the server operating system compatibility testing method according to various embodiments of the present invention described above.
[0057] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.
Claims
1. A server operating system compatibility testing method, characterized in that: include: Obtaining a task script and test parameter configuration; wherein the task script includes a process for operating system compatibility testing, and the operating system compatibility testing process includes at least one of: downloading a test script, configuring an offline source, installing a test tool, performing initial environment preparation, and performing actual testing; Generate pipeline tasks based on the task script; Based on the test instruction and the test parameter configuration, the pipeline task is started; wherein the pipeline task is run on the server where the pipeline is deployed, and the server where the pipeline is deployed and the server to be tested are in the same network environment; Based on the started pipeline tasks, execute pipeline tests on the server to be tested.
2. The server operating system compatibility testing method according to claim 1, characterized in that: The task script includes a Groovy script; wherein, based on the task script, generating a pipeline task includes: Jenkins generates pipeline steps based on the operating system compatibility test process written in the Groovy script; wherein the pipeline steps include at least one of downloading the test script, configuring the offline source, installing the test tool, initial preparation of the environment, and executing the actual test; In the pipeline steps, a skip option is configured for the pipeline steps that need to be skipped; A pipeline task is generated based on the skip option, the pipeline step, and the test parameter.
3. The server operating system compatibility testing method according to claim 2, characterized in that: Based on the started pipeline tasks, pipeline tests are performed on the server to be tested, including: During the pipeline test on the server to be tested, when any pipeline step is completed, a status check is performed on the completed pipeline step to obtain a step status check result; Integrate step status check results and generate test result notifications; After the pipeline test is completed on the server to be tested, the test result notification is sent.
4. The server operating system compatibility testing method according to claim 1, wherein: Based on the test instructions and the test parameter configuration, the pipeline task is started, including: Based on the test instruction, start the pipeline concurrent task; After the concurrent task of the pipeline is started, the configuration information of the pipeline task is downloaded based on the test parameter configuration; Parsing the configuration information of the pipeline task and extracting test parameters; Among them, based on the started pipeline tasks, pipeline testing is performed on the server to be tested, including: Based on the extracted test parameters, a pipeline control process is executed on the server to be tested.
5. The server operating system compatibility testing method according to claim 1, wherein: Based on the started pipeline tasks, pipeline tests are performed on the server to be tested, including: Download the test script and place it in the specified directory of the server to be tested; Determining the test type of the server to be tested according to the test parameter configuration; Install the corresponding test task according to the test type of the server to be tested; Performing network configuration on the network environment of the server to be tested; wherein, when the server network setting of the server to be tested is a temporary setting, solidifying the network configuration of the server to be tested; At least one of a benchmark test, a southbound compatibility test, an LTP function test, and an LTP stress test is performed on the server to be tested.
6. The server operating system compatibility testing method according to claim 5, characterized in that: The benchmark test includes: performing a benchmark performance test on the operating system, CPU, memory, hard disk, and network of the server to be tested; The southbound compatibility test includes verifying the compatibility of the server, board and operating system of the server to be tested.
7. The server operating system compatibility testing method according to claim 6, characterized in that: The southbound compatibility test of the server to be tested includes: Use oec-hardware to perform hardware compatibility testing; write Expect scripts and preset interactive content; Based on the preset interactive content, the test task is executed by controlling the Expect script to simulate the interaction process between the user and the oec-hardware tool.
8. The server operating system compatibility testing method according to claim 6, characterized in that: Server operating system compatibility testing methods include: After completing the LTP functional test, summarize the failed cases and retest them; Record the test cases that failed in the LTP functional test; When all test cases of LTP functional test pass, LTP stress test is carried out; Record the failed cases and test pass rate in the LTP stress test.
9. The server operating system compatibility testing method according to claim 1, wherein: Based on the started pipeline tasks, pipeline testing is performed on the server to be tested, including: When the test environment of the server to be tested is an offline test, obtaining server information and system information of the operating system of the server to be tested; wherein the server information includes the host name and IP address of the server, and the system information includes the operation type and version number of the operating system; Collect offline sources and transfer them to the server to be tested in an offline environment according to the requirements of the test tool of the server to be tested; According to the operating system type and version of the server to be tested, the corresponding offline source is matched and installed.
10. A server operating system compatibility testing device, characterized in that: include: An acquisition module is configured to acquire a task script and test parameter configuration; wherein the task script includes a process for operating system compatibility testing, and the operating system compatibility testing process includes at least one of: downloading a test script, configuring an offline source, installing a test tool, performing initial environment preparation, and performing actual testing; A generation module, used to generate pipeline tasks based on the task script; A startup module, configured to start a pipeline task based on a test instruction and the test parameter configuration; wherein the pipeline task runs on a server where the pipeline is deployed, and the server where the pipeline is deployed and the server to be tested are in the same network environment; The test module is used to perform pipeline testing on the server to be tested based on the started pipeline tasks.
Citation Information
Cited By
Software testing method
CN120929386A