Operating system mirror image testing method and device, electronic equipment and product

Abstract

The embodiment of the invention is suitable for the field of computers, and provides an operating system mirror image testing method and device, electronic equipment and a product, the method is applied to the electronic equipment, and the electronic equipment comprises a first virtual machine and a second virtual machine connected with the first virtual machine through a virtual network. The method comprises the following steps: controlling a first virtual machine to execute a mirror image generation script to generate a target mirror image packet of a target operating system, and transmitting the target mirror image packet to a second virtual machine through a virtual network; and controlling the second virtual machine to install the target mirror image package and test, and generating a test report of the target operating system. By adopting the method, the test efficiency of the target operating system can be improved.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to an operating system image testing method, apparatus, electronic device and product. Background Technology

[0002] With the rapid development of information technology, the demand for customized operating systems in scenarios such as server deployment, embedded devices, and dedicated terminals is increasing. As the core carrier of customized deliverables, the functional integrity and operational stability of operating system images directly affect the quality of project delivery. Therefore, efficient and accurate testing of images has become a core industry requirement.

[0003] Currently, existing technologies require technicians to manually compile and generate a customized operating system image package on a dedicated physical machine for image creation. This image package is then manually written to a physical USB drive, which is then transported to and connected to a designated test physical machine. After manually restarting the test physical machine, the USB drive is used to boot. Once the test physical machine reads the image package from the USB drive and completes the system installation, the technicians must manually run test cases, verify system functionality, record the results, and generate a test report.

[0004] However, the above method relies entirely on manual intervention, requiring the copying of the image package via physical media such as USB flash drives and the completion of cross-device scheduling. This not only increases the hardware and copying costs of the physical media, but also makes the testing process cumbersome and time-consuming, resulting in low testing efficiency. Summary of the Invention

[0005] This application provides an operating system image testing method, apparatus, electronic device, and product, which can solve the problem of low testing efficiency for operating systems.

[0006] In a first aspect, embodiments of this application provide an operating system image testing method, applied to an electronic device, the electronic device including a first virtual machine and a second virtual machine connected to the first virtual machine via a virtual network, the method including: The first virtual machine is controlled to execute an image generation script to generate a target image package of the target operating system, and the target image package is transmitted to the second virtual machine through a virtual network. Control the second virtual machine to install the target image package and perform testing, generating a test report for the target operating system.

[0007] In the above technical solution, by dividing the electronic device into a first virtual machine and a second virtual machine, the first virtual machine independently executes the image generation script to generate the target image package of the target operating system, and directly transmits it to the second virtual machine via a virtual network. Compared with related technologies that rely on physical media such as USB flash drives for copying and manual cross-physical device scheduling, this solution eliminates the steps of physical media preparation, manual copying, and device scheduling. This not only reduces the cost of physical resource investment but also improves the transmission efficiency of the target image package, thereby improving the overall testing efficiency of the target test system. Simultaneously, the first virtual machine focuses on the image generation task, avoiding the consumption of computing resources during testing. Finally, by controlling the second virtual machine to automatically complete the installation and testing of the target image package and generate a test report, complete isolation between the image generation environment and the testing environment is achieved. This effectively avoids the problem of resource consumption during target image package generation interfering with test stability caused by single-environment coupling in related technologies, ensuring the accuracy and reliability of test results, and improving the testing efficiency of the target operating system.

[0008] In one embodiment, controlling a first virtual machine to execute an image generation script to generate a target image package includes: Obtain the configuration file of the target image package and the installation package corresponding to the target operating system; the configuration file includes a configuration rule file and a dependency configuration file. The configuration rule file describes the configuration rules during the installation of the target image package, and the dependency configuration file records the dependency relationships between multiple software packages in the target image package; the installation package is used to encapsulate functional components that implement customized functions of the target operating system; Control the first virtual machine to execute the image generation script, integrate configuration files and installation packages to generate the target image package.

[0009] The above technical solution obtains a configuration file containing configuration rules and dependency configuration files, as well as an installation package encapsulating customized functional components. It then automatically integrates these two types of resources using an image generation script to generate a target image package, replacing the tedious traditional methods of manually modifying configurations and integrating software packages. This not only avoids configuration errors and missing dependencies caused by human error, ensuring the standardization and consistency of the generated target image package, but also improves the efficiency of target image package generation, enabling rapid response to adjustments based on the customized requirements of the target operating system.

[0010] In one embodiment, obtaining the configuration file of the target image package and the installation package corresponding to the target operating system includes: The configuration file generator displays a graphical configuration interface and generates configuration rule files in response to user configuration operations within the graphical configuration interface. The dependency generator resolves the dependencies of multiple packages to be integrated into the target image package and generates a dependency configuration file. The control package generator uses a preset standardized template to encapsulate functional components that implement customized functions of the target operating system into a preset format package.

[0011] The above technical solution achieves automated and standardized generation of configuration rule files, dependency configuration files, and customized installation packages through the graphical configuration interface of the configuration file generator, the automated parsing of the dependency generator, and the standardized template encapsulation of the installation package generator. This not only replaces the tedious operations of manually writing configuration files, sorting out software package dependencies, and manually encapsulating installation packages, thus lowering the technical threshold, but also avoids problems such as configuration syntax errors, missing dependencies, and chaotic installation package formats caused by human oversight from the source. It ensures the consistency and usability of configuration files and installation packages, lays a solid foundation for the efficient integration of subsequent target image packages, and significantly improves the generation efficiency and iteration speed of customized target image packages for template operating systems.

[0012] In one embodiment, the second virtual machine is controlled to install the target image package and perform testing, generating a test report of the target operating system, including: Control the second virtual machine to download the target image package and store the second virtual machine to the preset first virtual hard disk; After the target image package is transferred, control the first virtual machine to send a restart command to the second virtual machine; The system controls the boot system deployed on the preset second virtual hard disk in the second virtual machine to respond to the restart command, drive the second virtual machine to restart, and guide the second virtual machine to read the target image package from the first virtual hard disk and install the target image package to the preset third virtual hard disk; After the target image package is installed, control the second virtual machine to start the target operating system in the third virtual hard disk, test the target operating system, and generate a test report of the target operating system.

[0013] In the above technical solution, by functionally partitioning the three virtual hard disks of the second virtual machine, a chain-like automated operation is achieved, encompassing the download and storage of the target image package, system booting, and installation of the target operating system. From the targeted storage of the target image package to the first virtual hard disk, to the first virtual machine triggering a restart command to initiate the installation process, to the boot system driver on the second virtual hard disk restarting and strategically reading the target image package and installing it to the third virtual hard disk, and finally automatically launching the target operating system and completing comprehensive testing to generate a standardized test report, the entire process requires no manual intervention, replacing the cumbersome traditional process of manually copying images, adjusting boot items, manually installing, and compiling reports. Simultaneously, the functional isolation of the three virtual hard disks avoids storage conflicts between the image file, boot system, and target operating system, ensuring the purity of the installation and testing environment, significantly improving the efficiency and standardization of operating system image testing, and ensuring the accuracy and traceability of test results.

[0014] In one embodiment, after controlling the second virtual machine to install the target image package and perform testing, and generating a test report for the target operating system, the method further includes: Test results for the target operating system are generated based on the test report; If the test fails, the second virtual machine will delete the files corresponding to the target operating system installed on the third virtual hard disk, and the steps of generating the target image package and performing the test will be repeated.

[0015] In the above technical solution, intuitive and clear test results are automatically generated based on test reports, enabling rapid determination of whether the target operating system meets the standards. When the test result is a failure, the second virtual machine is controlled to clean up residual files of the target operating system in the third virtual hard disk, restoring a clean test environment. Furthermore, the target image package generation and testing process is executed repeatedly in a closed loop, without the need for manual intervention to clean up or restart the process. This avoids the problem of residual files interfering with the next test results due to incomplete manual cleaning, and eliminates the tedious operation of manually triggering retests. This shortens the iterative optimization cycle of the target image package and improves the testing efficiency and final delivery quality of customized operating system images.

[0016] In one embodiment, the method further includes: During the repeated steps of generating the target image package and conducting tests, the target image package downloaded and stored in the first virtual hard disk is retained.

[0017] In the above technical solution, by retaining the target image packages in the first virtual hard disk during repeated iterative testing, there is no need to clean up historical versions or occupy additional testing resources. At the same time, it can provide a complete version traceability basis for the iterative optimization of the target image package, which facilitates quick comparison of the differences between different versions of the target image package to locate the root cause of the problem. Meanwhile, it avoids the resource consumption of repeatedly downloading historical versions, which greatly improves the efficiency of the iterative optimization of the target operating system image and the accuracy of problem diagnosis.

[0018] In one embodiment, the system performance allocated to the first virtual machine is superior to that allocated to the second virtual machine.

[0019] In the above technical solution, by allocating the system performance of the first virtual machine to be better than that of the second virtual machine, it is possible to adapt to the high computing power requirements of image creation, so that the configuration of the two virtual machines can be fully matched with the functional positioning of the testing phase, and realize the on-demand allocation of virtualization resources.

[0020] Secondly, embodiments of this application provide an operating system image testing device applied to an electronic device. The electronic device includes a first virtual machine and a second virtual machine connected to the first virtual machine via a virtual network. The device includes: The first control module is used to control the first virtual machine to execute the image generation script to generate the target image package of the target operating system, and to transmit the target image package to the second virtual machine through the virtual network. The second control module is used to control the second virtual machine to install the target image package and perform tests, and generate a test report of the target operating system.

[0021] Thirdly, embodiments of this application provide an electronic 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 method described in the first aspect above.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0023] Fifthly, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to execute the method described in the first aspect. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art 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.

[0025] Figure 1 This is a flowchart illustrating the implementation of an operating system image testing method according to an embodiment of this application; Figure 2 This is a schematic diagram illustrating an implementation method for generating a target image package in an operating system image testing method provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating one implementation method for generating an installation package in an operating system image testing method provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating one implementation method for generating a test report in an operating system image testing method provided in an embodiment of this application; Figure 5 This is a flowchart illustrating the implementation of an operating system image testing method according to another embodiment of this application; Figure 6 This is a schematic diagram of the structure of an operating system image testing device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0027] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0028] It should be noted that the information collection process (such as patient information collection process, physiological information collection process, etc.) / feature extraction process involved in this application is carried out with the user's knowledge and permission. That is, the information collection process / feature extraction process complies with the requirements of laws and regulations and does not constitute an act that harms the public interest.

[0029] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0030] With the rapid iteration of information technology, the demand for customized operating systems continues to rise. In specific application scenarios such as server deployment, embedded devices, and dedicated terminals, the need for customized modifications to the operating system kernel configuration, software package combinations, and functional modules is becoming increasingly urgent. In the entire process of operating system customization, image creation and test environment construction are core links that determine the project development cycle and the quality of the final product. Their execution efficiency directly affects the project delivery schedule and market response speed.

[0031] Currently, the industry commonly uses a traditional manual operation and physical machine deployment model for operating system image creation and test environment construction. The specific implementation process is as follows: technicians manually modify various configuration rule files (such as isolinux.cfg, grub.cfg, ks.cfg, etc.) in the image package, manually place the customized installation package into the specified Packages directory, and then manually generate the repodata / normal.xml dependency configuration rule file; subsequently, they use a special tool to compile and generate the image package, and write the image package to a physical storage medium such as a USB flash drive; finally, they connect the USB flash drive containing the image package to the test physical machine, and manually start the physical machine to complete the installation and testing of the operating system.

[0032] However, the above solution has the following drawbacks: 1. Manual operation is inefficient and has a high error rate: The customization process requires manual modification of multiple configuration rule files one by one, and software package dependencies also need to be manually verified one by one. When image parameters need to be adjusted frequently (such as adding software modules or modifying automated installation processes), the workload of repetitive manual operations increases exponentially. At the same time, the probability of configuration errors caused by human oversight (such as missing dependencies, incorrect file path configurations, etc.) increases significantly. On average, 1-2 errors occur every 5 image parameter modifications, and each error investigation and correction takes an additional 1-2 hours, which seriously slows down the development pace.

[0033] 2. Lengthy Image Transfer and Testing Cycle: After each image parameter modification, a file of hundreds of MB to several GB needs to be written from the creation device to a physical USB drive. Due to the limitations of USB interface transfer speed, the transfer speed in this step is usually only 10-20 MB / s. Subsequently, the USB drive needs to be manually transferred to the test machine and boot configured. The entire process (including image generation, USB drive writing, and physical machine boot and installation) takes an average of 1.5-2 hours. If multiple iterations of image modifications are required, the accumulated time will severely hinder project progress. For example, a customized project involving 10 image modifications may require 15-20 hours just for the test environment setup stage.

[0034] 3. This method is highly dependent on physical hardware: it requires a dedicated physical machine and multiple physical USB drives for each testing stage, and the scheduling of hardware devices among different testers is prone to conflict, further reducing overall work efficiency.

[0035] Based on this, in order to reduce the hardware cost and copying of the required physical media and improve the overall testing efficiency, one embodiment of this application provides an operating system image testing method. This method can be applied to electronic devices such as laptops, ultra-mobile personal computers (UMPCs), and netbooks. This embodiment of the application does not impose any restrictions on the specific type of electronic device.

[0036] Please see Figure 1 , Figure 1 The diagram illustrates an implementation flowchart of an operating system image testing method provided in an embodiment of this application. The method is applied to an electronic device, which includes a first virtual machine and a second virtual machine connected to the first virtual machine via a virtual network. The method includes the following steps: S101. Control the first virtual machine to execute the image generation script to generate the target image package of the target operating system, and transmit the target image package to the second virtual machine through the virtual network.

[0037] In one embodiment, the first virtual machine is a dedicated virtual environment for image generation deployed on an electronic device, used to undertake the task of generating the target image package. To meet the computational demands of image compilation and file integration, it typically allocates more abundant computer resources such as CPU, memory, and disk I / O, and is completely isolated from the testing environment to prevent the resources consumed during the generation process from interfering with subsequent testing.

[0038] The second virtual machine is a dedicated virtual environment for image testing, designed to work in conjunction with the first virtual machine. It is used to receive the target image package and complete the installation and testing operations. Its environment configuration can simulate the actual application scenarios of the target operating system (such as server or embedded device operating environments) as needed, ensuring the authenticity of the test results. At the same time, it is isolated from the first virtual machine to prevent test operations from negatively impacting the stability of the generated image.

[0039] The aforementioned image generation script is a set of instructions for automating image generation. It encapsulates the entire process logic for generating the target image package. It typically includes instructions for calling image compilation tools (such as livemedia-creator), the reading path for configuration rule files, integration rules for customized software packages, and settings for the format and storage path of the target image package. It is used to replace the traditional manual modification of configuration and integration files, thereby automating and standardizing image generation.

[0040] The target operating system mentioned above is a customized operating system for specific application scenarios (such as server deployment and embedded devices). Compared with general-purpose operating systems, the target operating system has custom kernel parameters, exclusive software package combinations, and specific functional modules (such as security hardening components and dedicated drivers), which can meet the functional requirements of the specific scenario.

[0041] The target image package mentioned above is a bootable image file containing the complete installation files of the target operating system, commonly in ISO format. This file integrates the target operating system's kernel files, customized software packages, automatic installation configuration rules files, dependency configuration files, etc., and can be directly used for automated system installation; it serves as the carrier of the target operating system.

[0042] The target image package can be generated through an automated script execution process. For example, the first virtual machine loads and runs the image generation script, which automatically generates an installable target image package according to preset logic, without manual intervention.

[0043] The aforementioned virtual network is an internal logical network connecting the first virtual machine and the second virtual machine. For example, the virtual network can be VMware's Host-Only mode network or VirtualBox's bridged network; there is no limitation on this. The virtual network can be built by the virtualization software of electronic devices and does not rely on physical network cards or external networks. Typically, virtual networks offer high transmission speeds, low latency, and environmental isolation, enabling efficient and secure transmission of target image packages.

[0044] It should be noted that a dedicated first virtual machine runs the image generation script, generating the target image package of the target operating system through an automated process. Then, using a virtual network, the generated target image package is directly transferred to a dedicated second virtual machine, providing a platform for subsequent installation and testing. The entire process automates image generation and transfer, and the transfer is achieved through a virtual network, replacing the cumbersome traditional manual copying of the image package to physical media and cross-device scheduling.

[0045] S102. Control the second virtual machine to install the target image package and perform testing, and generate a test report of the target operating system.

[0046] In one embodiment, the first virtual machine can upload the target image package to a preset HTTP image repository (deployed on a physical host or dedicated server) and synchronously update the image index file (recording the image package version, storage path, and checksum). Then, the second virtual machine can automatically send a boot request to the PXE server at startup without storing the image package, using its configured PXE (Preboot Execution Environment) network boot function. The PXE server can return the boot configuration (including the HTTP image repository address and image index file path), and the second virtual machine can directly pull the target image package from the image repository via the virtual network. This eliminates the need for local virtual hard disk storage of the image, avoiding the image file occupying storage space in the test environment.

[0047] Next, the second virtual machine can download the target image package and automatically retrieve the corresponding automated installation configuration rule files from the image repository. It will then automatically complete the partitioning and formatting of the target operating system, kernel deployment, installation of customized software packages, and configuration of dependent libraries. Furthermore, during the installation process, the second virtual machine can provide real-time feedback to the image repository on the installation progress (such as partition completion rate and the number of software packages installed). If file corruption or fetch failure occurs, it will automatically trigger a resume function to ensure the integrity of the installation. Finally, after installation, the second virtual machine can automatically restart, load the target operating system from the second virtual hard disk, and complete the initial configuration (such as network adaptation and service auto-start).

[0048] Furthermore, for the target operating system that has been installed, the second virtual machine can run preset test scripts (replacing the traditional manual item-by-item verification) to perform tests and generate test reports.

[0049] In one embodiment, the testing dimensions of the target operating system may include: the basic functions of the target operating system (such as boot-up and network connectivity), customized functional modules (such as dedicated drivers and security hardening components), and automatically captured anomalies during the testing process (such as function failures, program crashes, and missing dependencies). The test scripts can simulate real-world application scenarios of the target operating system (such as high-concurrency server scenarios and low-power embedded device scenarios) to ensure that the test results closely reflect real-world usage environments.

[0050] The aforementioned test report is a structured technical document that records the entire testing process of the target operating system, used to present test results and locate problems. Specifically, the test may include basic information, test dimension coverage, anomaly information, and conclusions. Basic information may include test time, second virtual machine configuration, and target image package version / generation time. Test dimension coverage may include the number of test cases executed for each functional module and the pass rate. Anomaly information may include the types of errors found during testing (e.g., functional failure, missing dependencies), error details (error logs, occurrence point), and error severity (fatal / general / minor). Conclusions may include whether the test passed and suggestions for corrective action for items that failed.

[0051] After the test script is executed, the second virtual machine can automatically collect raw data during the test (test case execution results, exception logs, resource monitoring data), and classify, organize, and statistically analyze the raw data according to a preset report template (such as calculating the pass rate and classifying error types). Finally, the analyzed data is automatically populated into the corresponding fields of the template to generate a complete test report.

[0052] Understandably, by automating installation, testing, and test report generation within a virtualized environment, a second virtual machine can independently complete the entire process of receiving the target image package, installing the target operating system, testing, and outputting a test report. This leverages the scenario-specific configuration of the second virtual machine to ensure test realism, while automating the traditional manual installation, testing, and report writing processes, thus solving the problems of low efficiency and high error rates associated with manual operations. Furthermore, due to the resource isolation between the second and first virtual machines, the testing process will not interfere with the image generation stage, ensuring the accuracy of the test results.

[0053] In this embodiment, the electronic device is divided into a first virtual machine and a second virtual machine. The first virtual machine independently executes the image generation script to generate the target image package of the target operating system, and then directly transmits it to the second virtual machine via a virtual network. Compared with related technologies that rely on physical media such as USB flash drives for copying and manual cross-physical device scheduling, this method eliminates the steps of physical media preparation, manual copying, and device scheduling. This not only reduces the cost of physical resource investment but also improves the transmission efficiency of the target image package, thereby improving the overall testing efficiency of the target test system. Simultaneously, the first virtual machine focuses on the image generation task, avoiding the consumption of computing resources during testing. Finally, by controlling the second virtual machine to automatically complete the installation and testing of the target image package and generate a test report, complete isolation between the image generation environment and the testing environment is achieved. This effectively avoids the problem of resource consumption during target image package generation interfering with test stability caused by single-environment coupling in related technologies, ensuring the accuracy and reliability of the test results.

[0054] In another embodiment, the electronic device can be via, as... Figure 2 The steps S201-S202 shown control the first virtual machine to execute the image generation script to generate the target image package. Details are as follows: S201. Obtain the configuration file of the target image package and the installation package corresponding to the target operating system.

[0055] The aforementioned configuration files include configuration rule files and dependency configuration files. The configuration rule files describe the configuration rules during the installation of the target image package, while the dependency configuration files record the dependencies between multiple software packages in the target image package. The installation package is used to encapsulate functional components that implement customized functions of the target operating system.

[0056] In one embodiment, the aforementioned configuration file is a structured parameter file that supports the automated generation and installation of the target image package. It is stored in a designated directory of the first virtual machine for automatic reading by the image generation script. Specifically, the configuration file can be divided into two categories: configuration rule files and dependency configuration files. Common formats include XML, CFG, or KS (Kickstart) formats.

[0057] The aforementioned installation package is an installable software package file that encapsulates customized functions for the target operating system. It is customized for specific scenarios and differs from the default packages of general-purpose operating systems. For example, taking Linux as the target operating system, the installation package can be in RPM format (or compatible with DEB and other formats), and can be automatically integrated into the target image package by the image generation script. After installation, it can provide customized functions for the target operating system.

[0058] The configuration rule file described above is an instruction-type file that describes the rules for the entire installation process of the target image package. It can be used to define the automated execution logic during the installation of the target operating system, eliminating the need for manual intervention. Specifically, the configuration rule file may include system user / password configuration, installation source address, firewall / other system parameters, and initialization scripts after installation (such as service auto-start configuration).

[0059] Based on the above explanation, configuration rules can be considered as a standardized set of instructions embedded in a configuration rule file, used to clarify the execution logic of the target image package during the installation process and system initialization phase. These configuration rules may include system account configuration rules, installation source and package selection rules, system parameter configuration rules, initialization script execution rules, etc., without limitation.

[0060] Understandably, in the target image package generation process, the configuration rules are generated and written to the configuration rule file by the first virtual machine. When the second virtual machine installs the target image package, it is guided to read the configuration rules in this configuration rule file to complete the installation of the second virtual machine.

[0061] The aforementioned dependency configuration file is an index-type file that records the dependency logic between all packages within the target image package, used to resolve dependency missing issues during package installation. The dependency configuration file can record the names, versions, and compatible architectures of the prerequisite dependencies required by each package in a structured format. During image generation and installation, the integrity of dependencies can be automatically verified, preventing installation failures or functional abnormalities due to missing dependencies.

[0062] Based on the above explanation, dependencies can be considered as the execution / installation association logic between multiple software packages in the target image package. That is, the normal installation or operation of one software package requires that another (or more) software packages be installed. Dependencies can be divided into hard dependencies (the software package cannot be installed / run if it is missing, such as installing Nginx requires the pcre-devel dependency package to be installed first) and soft dependencies (their absence does not affect the core functionality, but will result in the loss of extended functionality, such as installing Python requires the optional pip dependency package). The dependency configuration file primarily records the hard dependency logic.

[0063] The aforementioned software package is a standardized file carrier used at the target operating system level for software distribution, installation, and management. It can package the software's executable program, configuration files, dependency libraries, documentation, and other related content into a single or related collection of files.

[0064] The aforementioned customized features are added / adjusted by the target operating system to adapt to specific application scenarios (such as server deployment, embedded devices, and dedicated terminals), and are distinct from the basic functions of a general-purpose operating system. Among these, functional components are the smallest functional units that implement customized features and are the encapsulated content of the installation package. A single installation package can encapsulate one or more related functional components.

[0065] In one embodiment, the user can write the aforementioned configuration file in a first virtual machine. Furthermore, the installation package can be an installation package generated by encapsulating customized functional components provided by developers using a preset encapsulation template.

[0066] S202. Control the first virtual machine to execute the image generation script, integrate the configuration file and installation package to generate the target image package.

[0067] In one embodiment, after the image generation script starts, the first virtual machine can load the configuration file and installation package and perform a validity check. This check verifies the syntax of the configuration rule file, the completeness of the dependency configuration file, and the dependencies and signatures of the installation package. If the verification passes, a basic image skeleton is built, integrating the configuration rule file, dependency configuration file, and customized installation package into the corresponding directory of the skeleton according to a standard directory structure. Finally, a compilation tool is invoked to package the integrated image skeleton into a bootable target image package.

[0068] Based on the above description, the target image package can be considered as a bootable installation file that integrates the above software packages and configuration files. The configuration rule file can guide the second virtual machine to install the target operating system, and the dependency configuration file can record the association logic between software packages, ensuring that the second virtual machine can automatically complete the deployment of all software packages in sequence when installing the target operating system, thus ensuring the integrity of system functions.

[0069] In this embodiment, by obtaining a configuration file containing configuration rules and dependency configuration files, and an installation package encapsulating customized functional components, and automatically integrating these two types of resources based on an image generation script to generate a target image package, the tedious traditional manual modification of configurations and manual integration of software packages is replaced. This not only avoids configuration errors and missing dependencies caused by human oversight, ensuring the standardization and consistency of the generated target image package, but also improves the efficiency of target image package generation, enabling rapid response to adjustments based on the customized requirements of the target operating system.

[0070] In another embodiment, the electronic device can be via, as... Figure 3 Steps S301-S303, as shown, are for obtaining the configuration file and installation package. Details are as follows: S301, Control the configuration file generator to display the graphical configuration interface, and generate configuration rule files in response to the user's configuration operations in the graphical configuration interface.

[0071] In one embodiment, the configuration file generator can be a set of automated tools deployed in a first virtual machine, serving as a vehicle for the visualization and standardized generation of configuration rule files, rather than the traditional method of manually writing configuration rule files. The configuration file generator typically consists of multi-functional modules that work collaboratively to directly convert user visualization operations into configuration rule files that conform to grammatical standards, avoiding syntax errors and logical omissions that occur during manual writing.

[0072] As an example, the configuration file generator mentioned above can be a ks file generator, which may include functional modules such as partition configuration, user creation, installation package selection, and boot item settings.

[0073] The graphical configuration interface described above is a visual interactive window provided by the configuration file generator, replacing the traditional command-line method of writing configuration rule files. It is intuitive and easy to use. The graphical configuration interface can be divided into multiple operation areas according to functional modules. For example, there is a disk partition configuration area (supports selecting the target disk, setting the partition size and format), a system account configuration area (supports entering administrator / regular user information and setting permissions), a package selection area (supports selecting pre-installed / removed packages), and a network and system parameter configuration area (supports setting IP, time zone, firewall policies), etc. Users do not need to understand the underlying syntax of configuration rule files (such as the command format of ks.cfg) to complete the setting of all configuration items.

[0074] The above configuration operations are a series of visual interactive behaviors completed by the user in the graphical configuration interface, serving as the input basis for generating the configuration rule file. These configuration operations can be captured in real time by the configuration file generator and converted into corresponding configuration instructions, ensuring a one-to-one correspondence between the configuration operations and the content of the configuration rule file.

[0075] Understandably, the configuration file generator deployed in the first virtual machine is launched, automatically loading the preset configuration template and displaying a graphical configuration interface. Users can then complete configuration operations within the graphical interface according to the customized requirements of the target operating system. Finally, the configuration file generator parses all user configuration operations and automatically generates corresponding configuration rule files according to the standard format of configuration rule files. This replaces the tedious process of manually writing configuration rule files, improves the efficiency of configuration rule file generation, and avoids syntax errors and logical loopholes caused by manual input, ensuring the consistency and usability of the configuration rule files.

[0076] S302. The control dependency generator parses the dependency relationships of multiple software packages to be integrated into the target image package and generates a dependency configuration file.

[0077] In one embodiment, the dependency generator is an automated dependency resolution tool module deployed in the first virtual machine, used to replace the traditional manual sorting and verification of package dependencies, and has automated and accurate dependency analysis capabilities. For example, the dependency generator can be a normal.xml generator.

[0078] The dependency generator can identify the dependency rules of different types of software packages (basic software packages, customized installation packages), verify the version compatibility of dependency packages (such as the version range of dependency packages that a specific software package needs to adapt to), and avoid functional abnormalities caused by version mismatch.

[0079] In one embodiment, the above integration involves placing the basic software packages (such as kernel modules and system tools) and customized installation packages (encapsulating customized functional components) required by the target operating system in a designated directory of the first virtual machine. The dependency generator performs global dependency resolution on all software packages in this directory to clarify the relationship logic between each software package, providing a basis for dependency integrity verification when the subsequent image generation script physically integrates the above software packages into the target image package.

[0080] As an example, a dependency generator can automatically scan and load all packages to be integrated into the target image package, and parse the dependency metadata of each package (such as the name, version number, and compatible architecture of required dependent packages). Then, the dependency generator can organize all the parsed dependencies (including mandatory hard dependencies and optional soft dependencies) into a standardized format (such as XML) to generate a dependency configuration file that conforms to image creation specifications. Based on the above steps, by replacing manual verification with automated parsing, problems such as missing dependencies and version mismatches caused by human error can be avoided, ensuring the completeness of package dependencies integrated into the target image package and guaranteeing the normal operation of the target operating system after installation.

[0081] S303, The control installation package generator, based on a preset standardized template, encapsulates functional components that implement customized functions of the target operating system into an installation package in a preset format.

[0082] In one embodiment, the standardized template is an installation package packaging rule file deployed in the first virtual machine and built into the installation package generator (e.g., software developed based on the rpmbuild framework). It is used to define a unified standard for installation package packaging and avoid chaotic installation package formats, missing metadata, or insufficient compatibility among different functional components.

[0083] The standardized templates may include the following rule templates: Structure template: Specifies the internal directory hierarchy of the installation package to ensure that the functional components of the installation package can be recognized and loaded by the target operating system after installation; Metadata template: Defines basic information fields for the installation package (such as package name, version number, compatible architecture, author, release date, dependency description, and installation / uninstallation instructions). For example, rules such as "automatically clean up log files generated by components during uninstallation" are included.

[0084] The above-mentioned preset format is an installation package file format determined in advance for the package management system of the target operating system. In essence, it is a standardized format adapted to the system's native package management tools, ensuring that the installation package can be integrated by the image generation script and can be automatically recognized and installed by the system when installing on the second virtual machine.

[0085] For example, the default format can be RPM, which is compatible with the yum / rpm package management tools of CentOS. If the target operating system is Debian / Ubuntu, the default format can be DEB, with the principle of full compatibility with the package management system of the target operating system to avoid problems such as unresolved packages and installation failures.

[0086] It should be noted that by using standardized templates and preset formats, the packaging of functional components is automated and standardized, replacing the traditional method of manually writing spec files and manually executing the rpmbuild command to package the installation package. This not only lowers the packaging threshold but also ensures that all customized installation packages have a unified format and consistent compatibility, avoiding compatibility issues during subsequent image integration or system installation caused by non-standard installation package formats.

[0087] In this embodiment, the graphical configuration interface of the configuration file generator, the automated parsing of the dependency generator, and the standardized template encapsulation of the installation package generator are used to automate and standardize the generation of configuration rule files, dependency configuration files, and customized installation packages. This not only replaces the tedious operations of manually writing configuration files, sorting out software package dependencies, and manually encapsulating installation packages, thus lowering the technical threshold, but also avoids problems such as configuration syntax errors, missing dependencies, and chaotic installation package formats caused by human oversight from the source. This ensures the consistency and usability of configuration files and installation packages, lays a solid foundation for the efficient integration of subsequent target image packages, and significantly improves the generation efficiency and iteration speed of customized target image packages for template operating systems.

[0088] In another embodiment, the electronic device can be via, as... Figure 4 Steps S401-S404, as shown, are for obtaining the configuration file and installation package. Details are as follows: S401. Control the second virtual machine to download the target image package and store the second virtual machine to the preset first virtual hard disk.

[0089] In one embodiment, the first virtual hard disk is a dedicated virtual storage medium (distinct from a physical hard disk) pre-planned and created within the second virtual machine. It is a logical storage partition in the virtualization environment, rather than physical hardware. Specifically, the first virtual hard disk is a dedicated image storage partition in the second virtual machine, used to receive and store target image packages, avoiding path confusion or storage space conflicts caused by mixing image files with system files and test files. Simultaneously, the first virtual hard disk is adapted to the Ventoy boot disk's reading logic, ensuring efficient file reading during subsequent image installation.

[0090] It should be noted that the virtualization management program in the electronic device can issue instructions to the second virtual machine. The second virtual machine, through a virtual network interconnected with the first virtual machine, actively pulls the target image package generated by the first virtual machine (replacing the traditional manual operation of writing the image to a physical USB drive and then inserting it into the physical machine). After the target image package is downloaded, the virtualization management program can control the second virtual machine to automatically store the image package in a designated directory on its internal preset first virtual hard disk, rather than on other virtual hard disks. Thus, storing the target image package centrally on the first virtual hard disk ensures that the image file is isolated from the subsequent boot system (second virtual hard disk) and test data (third virtual hard disk) of the second virtual machine, avoiding mutual interference. It also prepares the storage for the second virtual machine to read the image package from the first virtual hard disk and complete the operating system installation. The entire process requires no manual intervention in storage path selection or media insertion / removal, automating the transfer of the target image package to storage and solving problems such as path confusion and human error caused by traditional physical media storage.

[0091] S402. After the target image package is transferred, control the first virtual machine to send a restart command to the second virtual machine.

[0092] In one embodiment, the aforementioned restart command is a standardized virtualization management command issued by the first virtual machine to the second virtual machine. It is a dedicated control command adapted to virtualization platforms such as VMware / KVM (e.g., VMware's VMX restart command, KVM's QEMU restart command), rather than the traditional method of manually restarting the physical machine.

[0093] The restart command typically includes explicit execution parameters: restart trigger timing (after the target image package is transferred and verified) and restart mode (cold restart, i.e., first completely shut down the system processes currently running on the second virtual machine, and then restart). It can be directly recognized and executed by the virtualization management agent program built into the second virtual machine, and is an automated trigger signal that connects image transfer and system installation.

[0094] It should be noted that the first virtual machine monitors the transfer status of the target image package to the first virtual hard disk of the second virtual machine in real time through the virtual network. After confirming that the target image package transfer is complete and the file integrity verification passes, it automatically generates a restart command and sends it to the second virtual machine through a dedicated communication channel in the virtual network (such as a virtual serial port or the virtualization platform's internal API). After receiving the command, the management agent program of the second virtual machine executes the cold restart process as required by the command, shuts down the currently running boot system process, and completes the system power-off and power-on restart action.

[0095] S403. Control the boot system deployed on the preset second virtual hard disk in the second virtual machine to respond to the restart command, drive the second virtual machine to restart, and guide the second virtual machine to read the target image package from the first virtual hard disk and install the target image package to the preset third virtual hard disk.

[0096] In one embodiment, the second virtual hard disk is a pre-planned virtual storage medium dedicated to the boot system within the second virtual machine, serving as the partition carrying the boot system among the three virtual hard disks in the second virtual machine. The second virtual hard disk may pre-install the boot system and deploy a boot program, and is functionally isolated from the first virtual hard disk storing the target image package and the third virtual hard disk installing the target operating system, thus providing boot capability after the second virtual machine restarts.

[0097] The aforementioned boot system is a set of boot management programs deployed in the second virtual hard disk, replacing the boot item configuration function of a traditional physical machine. Typically, the boot system includes taking over the boot process of the second virtual machine in response to restart commands, as well as recognizing and reading the image file format in the first virtual hard disk and automatically triggering the operating system installation boot, without the need for manual selection of boot media or installation path.

[0098] The aforementioned third virtual hard disk is a dedicated virtual storage medium for installing the target operating system within the second virtual machine. It is a partition among the three virtual hard disks specifically designed to host the complete target operating system, and is completely isolated from the first virtual hard disk storing the image and the second virtual hard disk hosting the boot system. The third virtual hard disk serves as the installation destination for the target image package, avoiding system conflicts caused by the coexistence of the target operating system, boot program, and image file, while reserving sufficient space to meet the operational requirements of customized operating systems.

[0099] It should be noted that after the second virtual machine receives the restart command from the first virtual machine, the boot system deployed on the second virtual hard disk is activated and takes over the restart process of the second virtual machine. The boot system can drive the second virtual machine to complete a cold restart (shutting down the current boot system process and powering it back on). After restarting, it automatically scans all virtual hard disks of the second virtual machine and locates the first virtual hard disk storing the target image package. The boot system can read the target image package in the first virtual hard disk, parse the installation configuration rules within the image, and perform operations such as boot item selection and installation path setting without manual intervention. Based on the configuration rule file, it automatically and completely installs the target operating system in the target image package to the pre-planned third virtual hard disk, completing the entire process of system partitioning, software package deployment, and parameter configuration. Thus, it achieves full automation from restart to installation path orientation, ensuring the accuracy of the installation process (directed installation to the third virtual hard disk) and avoiding installation failures caused by human error, significantly improving system installation efficiency.

[0100] S404. After the target image package is installed, control the second virtual machine to start the target operating system in the third virtual hard disk, test the target operating system, and generate a test report of the target operating system.

[0101] In one embodiment, once the second virtual machine automatically determines that the target image package has been successfully installed on the third virtual hard disk, it can boot the target operating system from the third virtual hard disk under the control of the bootloader and complete the initialization configuration. After the target operating system boots, it automatically triggers a preset test script and performs comprehensive tests, including basic functions, customized functions, dependency integrity, and scenario-based stability, generating a test report. This process can be completed without manual intervention, replacing the cumbersome traditional steps of manual booting, manual testing, and report compilation, ensuring testing efficiency and the accuracy and traceability of the results.

[0102] In this embodiment, by functionally partitioning the three virtual hard disks of the second virtual machine, a chain-like automated operation is achieved, encompassing the download and storage of the target image package, system booting, and installation of the target operating system. From the targeted storage of the target image package to the first virtual hard disk, to the first virtual machine triggering a restart command to initiate the installation process, to the boot system driver on the second virtual hard disk restarting and strategically reading the target image package and installing it to the third virtual hard disk, and finally automatically launching the target operating system and completing comprehensive testing to generate a standardized test report, the entire process requires no manual intervention. This replaces the cumbersome traditional process of manually copying the image, adjusting boot items, manually installing, and compiling reports. Simultaneously, the functional isolation of the three virtual hard disks avoids storage conflicts between the image file, the boot system, and the target operating system, ensuring the purity of the installation and testing environment, significantly improving the efficiency and standardization of operating system image testing, and ensuring the accuracy and traceability of test results.

[0103] In another embodiment, the electronic device can be via, as... Figure 5 The steps S501-S502 shown illustrate obtaining the configuration file and installation package. Details are as follows: S501. Generate test results for the target operating system based on the test report.

[0104] In one embodiment, the above test results are judgment conclusions extracted from the test report. They are different from the detailed data record attributes of the test report. The test results can be regarded as an intuitive and clear conclusion output on whether the target operating system meets the preset standards.

[0105] The test results may include whether the target operating system passes the test (e.g., the test passes or fails), the problems affecting system functionality, stability, and security, and the severity of those problems.

[0106] The electronic device can use a pre-set automated program to read structured data from the test report (total number or pass count of test cases, anomaly types and quantities, performance indicator values) and verify the integrity of the data (to avoid missing key module data in the report). Then, the parsed report data is compared with a pre-set rule base to perform compliance checks, issue level classification, and indicator compliance analysis. Finally, test results are generated according to a fixed template, with a clear format and explicit conclusions, supporting direct export or synchronization to the image management platform. By automating the extraction process instead of manual summarization, the objectivity and consistency of test results are ensured, and the time from report generation to conclusion output is significantly shortened, improving the response efficiency of image iteration and optimization.

[0107] S502. If the test result is a test failure, control the second virtual machine to delete the files corresponding to the target operating system that has been installed in the third virtual hard disk, and repeat the steps of generating the target image package and performing the test.

[0108] In one embodiment, if the test fails, the target operating system still running on the third virtual hard disk can be shut down (releasing file locks to prevent deletion failure). For example, batch cleanup and partition formatting operations can be performed on the third virtual hard disk to delete all associated files of the installed target operating system (including system kernel, customized software packages, configuration files, test logs, temporary caches, etc.), instead of manually deleting them one by one, to avoid residual files interfering with the next image installation and testing (such as file conflicts or dependency residues leading to misjudgments).

[0109] Afterwards, the first virtual machine can re-execute the target image package generation steps. For example, testers can adjust the generation parameters of the target image package in the first virtual machine based on the reasons for the previous test failure (such as missing dependencies, incorrect configuration rules, or abnormal encapsulation of customized functional components). This adjustment includes supplementing missing dependency packages, correcting configuration rule files, and re-encapsulating functional components. The first virtual machine then integrates and generates a new target image package. Subsequently, the entire process of downloading and storing the target image package (the new target image package) in the second virtual machine, sending a restart command in the first virtual machine, booting the system to install the target image package to the third virtual hard disk, starting the target operating system and conducting tests, and generating a test report is executed again.

[0110] The above testing process can be executed repeatedly until the test result is determined to be a pass, at which point the test of the target operating system ends. If the test result is still a failure after multiple retries, an alarm can be automatically triggered (such as pushing the reason for the failure to technical personnel or notifying manual intervention for troubleshooting).

[0111] In this embodiment, intuitive and clear test results are automatically generated based on test reports, enabling rapid determination of whether the target operating system meets the standards. When the test result indicates a failure, the second virtual machine is controlled to clean up residual files of the target operating system in the third virtual hard disk, restoring a clean test environment. Furthermore, the target image package generation and testing process is executed repeatedly in a closed loop, without any manual intervention in cleaning or restarting the process. This avoids the problem of residual files interfering with subsequent test results due to incomplete manual cleaning, and eliminates the tedious operation of manually triggering retests. This shortens the iterative optimization cycle of the target image package and improves the testing efficiency and final delivery quality of customized operating system images.

[0112] In another embodiment, during the repeated execution of the step of generating the target image package and performing tests, the target image package stored in the first virtual hard disk for each download is retained.

[0113] In one embodiment, the target image package downloaded and stored in each iteration refers to a different version of the target image package that is transferred to the first virtual hard disk of the second virtual machine each time during the closed-loop iterative process of repeatedly generating and testing the target image package. Different versions of the target image package correspond to different optimization iteration stages (such as a new version of the image generated after correcting configuration rules due to test failures and adding dependency packages), and each version is associated with a corresponding test report and test results, which is a historical collection of target image package iteration optimizations.

[0114] Understandably, retaining historical target image packages enables comparative analysis between different versions. When a test fails, differences in configuration and installation packages between historical target image packages can quickly pinpoint the problem (e.g., whether dependency conflicts are caused by newly added customized components). Furthermore, if it's necessary to reproduce historical test scenarios or roll back to a specific version, the target image package already stored in the first virtual hard disk can be directly accessed, eliminating the need to download it again from the first virtual machine, saving virtual network bandwidth and transmission time. Finally, historical target image packages and corresponding test results can form a complete iterative archive, facilitating technical personnel to summarize optimization patterns and guide subsequent customized development of image packages.

[0115] In this embodiment, by retaining the target image packages from each iteration in the first virtual hard disk during repeated testing, there is no need to clean up historical versions or occupy additional testing resources. This provides a complete version traceability basis for the iterative optimization of the target image package, making it easy to quickly compare the differences between different versions of the target image package to locate the root cause of the problem. At the same time, it avoids the resource consumption of repeatedly downloading historical versions, greatly improving the efficiency of the iterative optimization of the target operating system image and the accuracy of problem diagnosis.

[0116] In another embodiment, the system performance allocated to the first virtual machine is superior to that allocated to the second virtual machine. Here, system performance refers to the operational capabilities supported by the hardware resources allocated to the virtual machine by the virtualization platform (such as VMware, VirtualBox, KVM, etc.). Typically, system performance includes CPU computing power, memory capacity, disk I / O read / write performance, network bandwidth, etc., and is not limited thereto.

[0117] CPU computing power can be characterized by the number of CPU cores, clock speed, and computing power quota; memory capacity can be characterized by the allocated running memory size, which typically determines the number of tasks a virtual machine can handle simultaneously; disk I / O read / write performance can be characterized by the allocated disk type (such as SSD or HDD virtual disk) and I / O read / write speed; network bandwidth can be characterized by the maximum transmission rate of the allocated virtual network interface card. The configuration of these system performance parameters directly determines the efficiency of the virtual machine in handling compute-intensive and I / O-intensive tasks.

[0118] In one embodiment, the system performance allocated to the first virtual machine is superior to that allocated to the second virtual machine because the first virtual machine is allocated higher-specification hardware resources and more abundant resource quotas, enabling it to efficiently support high-load, time-consuming tasks during image generation, such as compiling the system kernel, integrating massive software packages, and verifying dependencies. Conversely, the second virtual machine's tasks are image installation and functional testing, which have relatively lower hardware resource requirements. Therefore, the resource specifications configured for the second virtual machine are lower than those configured for the first virtual machine, thereby achieving on-demand allocation of virtualization resources and avoiding resource waste.

[0119] For example, the host configuration of the electronic device can be: equipped with an Intel Xeon E3-1230v5 processor (or an AMD processor of equivalent performance), 32GB of DDR4 RAM, and a 512GB SSD for storing virtual machine-related files; the host operating system is Windows 10 Professional, and the virtualization software can be VMware Workstation 16 Pro.

[0120] The first virtual machine is configured with the following system performance: an 8-core CPU, 16GB of memory, a 200GB SSD partition, and a pre-installed CentOS 7.9 operating system. The system includes the livemedia-creator image compilation tool, the scp file transfer tool, and a complete automated image modification toolchain. The configuration file generator is developed using Python + PyQt5, the dependency generator integrates the libsolv dependency parsing library, and the package generator is a secondary development based on the rpmbuild framework, efficiently supporting high-load tasks such as image compilation and package dependency verification.

[0121] The second virtual machine is configured with the following system performance: a 4-core CPU, 8GB of memory, and three independent virtual hard disks. The first virtual hard disk has a capacity of 32GB, the second virtual hard disk has a capacity of 50GB, and the third virtual hard disk has a capacity of 100GB. The second virtual hard disk is pre-installed with CentOS 7.9, and the first virtual hard disk is used to create a Ventoy boot disk (e.g., Ventoy version 1.0.96), which can meet the needs of light-load tasks such as image installation and functional testing.

[0122] In summary, the first virtual machine outperforms the second virtual machine in terms of CPU core count, memory capacity, and disk performance, and is able to meet the high computing power requirements of image creation. This ensures that the configurations of the two virtual machines are perfectly matched to the functional positioning of the testing phase, enabling on-demand allocation of virtualization resources.

[0123] In one embodiment, the electronic device can control a first virtual machine to execute an image generation script to generate a target image package of the target operating system. The entire process takes approximately 5 minutes and generates a target image package with a file size of approximately 4.2GB. After the image generation script is executed, the target image package can be automatically transferred to a second virtual machine via a virtual network. The transfer rate is typically stable at around 120MB / s, and the transfer is completed in about 35 seconds. After the transfer is complete, the first virtual machine can send a reboot command to the second virtual machine, and the second virtual machine automatically enters the BIOS interface upon reboot. In the BIOS interface, the second virtual machine can automatically set Ventoy (corresponding to the first virtual hard disk) as the first boot option, save, and restart. The second virtual machine boots from the Ventoy boot disk, and the boot system on the second virtual hard disk can automatically recognize the target image package and enter the installation process (based on the configuration rule file), completing the installation in approximately 8 minutes. After installing the target image package to the third virtual hard disk, the target operating system can be automatically tested, generating a test report (stored at / root / test_report.txt). The entire installation test takes approximately 8 minutes and 23 seconds.

[0124] Through the above implementation steps, the entire process of modifying, generating, and testing a customized target image package is completed. The total time is approximately: generating configuration rule files (1 minute), generating dependency configuration files (30 seconds), packaging the installation package (1 minute), generating the target image package (5 minutes), transferring the target image package (35 seconds), and installation testing (8 minutes and 23 seconds), totaling approximately 16 minutes and 28 seconds. This is 5.5 times more efficient than the traditional method (1.5 hours). Furthermore, after 10 consecutive iterations of modification and testing, only one error occurred due to a package version conflict (detected and alerted in advance by the dependency generator), reducing the error rate to 10%, far lower than the 20%-40% of the traditional method.

[0125] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0126] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an operating system image testing device provided in an embodiment of this application. The modules included in the operating system image testing device in this embodiment are used for execution... Figures 1 to 5 The steps in the corresponding embodiments. Please refer to the details. Figures 1 to 5 as well as Figures 1 to 5 The relevant descriptions in the corresponding embodiments are shown below. For ease of explanation, only the parts relevant to this embodiment are shown. See also... Figure 6 The operating system image testing device 600 is applied to an electronic device, which includes a first virtual machine and a second virtual machine connected to the first virtual machine via a virtual network. The device includes a first control module 610 and a second control module 620, wherein: The first control module 610 is used to control the first virtual machine to execute the image generation script to generate the target image package of the target operating system, and to transmit the target image package to the second virtual machine through the virtual network.

[0127] The second control module 620 is used to control the second virtual machine to install the target image package and perform testing, and generate a test report of the target operating system.

[0128] In one embodiment, the first control module 610 is used to: Obtain the configuration file of the target image package and the installation package corresponding to the target operating system; the configuration file includes a configuration rule file and a dependency configuration file. The configuration rule file describes the configuration rules during the installation of the target image package, and the dependency configuration file records the dependency relationships between multiple software packages in the target image package; the installation package is used to encapsulate functional components that implement customized functions of the target operating system; Control the first virtual machine to execute the image generation script, integrate configuration files and installation packages to generate the target image package.

[0129] In one embodiment, the first control module 610 is used to: The configuration file generator displays a graphical configuration interface and generates configuration rule files in response to user configuration operations within the graphical configuration interface. The dependency generator resolves the dependencies of multiple packages to be integrated into the target image package and generates a dependency configuration file. The control package generator uses a preset standardized template to encapsulate functional components that implement customized functions of the target operating system into a preset format package.

[0130] In one embodiment, the second control module 620 is used for: Control the second virtual machine to download the target image package and store the second virtual machine to the preset first virtual hard disk; After the target image package is transferred, control the first virtual machine to send a restart command to the second virtual machine; The system controls the boot system deployed on the preset second virtual hard disk in the second virtual machine to respond to the restart command, drive the second virtual machine to restart, and guide the second virtual machine to read the target image package from the first virtual hard disk and install the target image package to the preset third virtual hard disk; After the target image package is installed, control the second virtual machine to start the target operating system in the third virtual hard disk, test the target operating system, and generate a test report of the target operating system.

[0131] In one embodiment, the operating system image testing apparatus 600 further includes: The generation module is used to generate test results for the target operating system based on the test report.

[0132] The iteration module is used to control the second virtual machine to delete the files corresponding to the target operating system installed in the third virtual hard disk if the test result is a test failure, and to repeat the steps of generating the target image package and performing the test.

[0133] In one embodiment, the operating system image testing apparatus 600 further includes: The retention module is used to retain the target image package downloaded and stored in the first virtual hard disk during repeated execution of the steps of generating the target image package and conducting tests.

[0134] In one embodiment, the system performance allocated to the first virtual machine is superior to that allocated to the second virtual machine.

[0135] When it is understood that, Figure 5 In the schematic diagram of the operating system image testing device shown, each module is used to execute... Figures 1 to 5 The steps in the corresponding embodiments, and for Figures 1 to 5 The steps in the corresponding embodiments have been explained in detail in the above embodiments. Please refer to them for details. Figures 1 to 5 as well as Figures 1 to 5 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0136] Figure 7 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Figure 7 As shown, the electronic device 700 of this embodiment includes: a processor 710, a memory 720, and a computer program 730 stored in the memory 720 and executable on the processor 710, such as a program for an operating system image testing method. When the processor 710 executes the computer program 730, it implements the steps in the various embodiments of the above-described operating system image testing methods, for example... Figure 1 S101 to S102 are shown. Alternatively, the processor 710 implements the above when executing the computer program 730. Figure 6 The functions of each module in the corresponding embodiments, for example, Figure 6 For details on the functions of each module shown, please refer to [link / reference]. Figure 6 The relevant descriptions in the corresponding embodiments.

[0137] For example, the computer program 730 can be divided into one or more modules, one or more of which are stored in the memory 720 and executed by the processor 710 to implement the operating system image testing method provided in this application embodiment. One or more modules can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 730 in the electronic device 700. For example, the computer program 730 can implement the operating system image testing method provided in this application embodiment.

[0138] Electronic device 700 may include, but is not limited to, processor 710 and memory 720. Those skilled in the art will understand that... Figure 7 This is merely an example of electronic device 700 and does not constitute a limitation on electronic device 700. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0139] The processor 710 may be a central processing unit, or it may be other general-purpose processors, digital signal processors, application-specific integrated circuits, off-the-shelf programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0140] The memory 720 can be an internal storage unit of the electronic device 700, such as a hard disk or RAM of the electronic device 700. The memory 720 can also be an external storage device of the electronic device 700, such as a plug-in hard disk, smart memory card, flash memory card, etc., equipped on the electronic device 700. Furthermore, the memory 720 can include both internal storage units and external storage devices of the electronic device 700.

[0141] This application provides a computer-readable storage medium, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the operating system image testing method as described in the above embodiments.

[0142] This application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the operating system image testing method described in the above embodiments.

[0143] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for testing operating system images, characterized in that, Applied to an electronic device, the electronic device including a first virtual machine and a second virtual machine connected to the first virtual machine via a virtual network, the method includes: The first virtual machine is controlled to execute an image generation script to generate a target image package of the target operating system, and the target image package is transmitted to the second virtual machine through the virtual network. Control the second virtual machine to install the target image package and perform testing, and generate a test report of the target operating system.

2. The method according to claim 1, characterized in that, The step of controlling the first virtual machine to execute the image generation script to generate the target image package includes: Obtain the configuration file of the target image package and the installation package corresponding to the target operating system; the configuration file includes a configuration rule file and a dependency configuration file, the configuration rule file is used to describe the configuration rules during the installation of the target image package, and the dependency configuration file is used to record the dependency relationships between multiple software packages in the target image package; the installation package is used to encapsulate functional components that implement customized functions of the target operating system; The first virtual machine is controlled to execute the image generation script, and the configuration file and the installation package are integrated to generate the target image package.

3. The method according to claim 2, characterized in that, The step of obtaining the configuration file of the target image package and the installation package corresponding to the target operating system includes: The configuration file generator displays a graphical configuration interface and generates the configuration rule file in response to the user's configuration operation on the graphical configuration interface. The dependency generator parses the dependency relationships of multiple software packages to be integrated into the target image package and generates the dependency configuration file. The control package generator, based on a preset standardized template, encapsulates the functional components that implement the customized functions of the target operating system into the installation package in a preset format.

4. The method according to claim 1, characterized in that, The process of controlling the second virtual machine to install the target image package and perform testing, generating a test report for the target operating system, includes: Control the second virtual machine to download the target image package, and store the second virtual machine to a preset first virtual hard disk; After the target image package is transmitted, control the first virtual machine to send a restart command to the second virtual machine; The system controls the boot system deployed on the preset second virtual hard disk in the second virtual machine to respond to the restart command, drive the second virtual machine to restart, and guide the second virtual machine to read the target image package from the first virtual hard disk and install the target image package to the preset third virtual hard disk; After the target image package is installed, the second virtual machine is controlled to start the target operating system in the third virtual hard disk, and the target operating system is tested to generate a test report of the target operating system.

5. The method according to claim 4, characterized in that, After controlling the second virtual machine to install the target image package and perform testing, generating a test report for the target operating system, the process further includes: Test results for the target operating system are generated based on the test report; If the test result is a test failure, the second virtual machine is controlled to delete the files corresponding to the target operating system that have been installed in the third virtual hard disk, and the steps of generating the target image package and performing the test are repeated.

6. The method according to claim 5, characterized in that, The method further includes: In the repeated steps of generating the target image package and testing, the target image package downloaded and stored in the first virtual hard disk is retained.

7. The method according to any one of claims 1-6, characterized in that, The system performance allocated to the first virtual machine is better than that allocated to the second virtual machine.

8. An operating system image testing device, characterized in that, An apparatus for use in an electronic device, the electronic device including a first virtual machine and a second virtual machine connected to the first virtual machine via a virtual network, the apparatus comprising: The first control module is used to control the first virtual machine to execute the image generation script to generate a target image package of the target operating system, and to transmit the target image package to the second virtual machine through the virtual network; The second control module is used to control the second virtual machine to install the target image package and perform testing, and generate a test report of the target operating system.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, When the computer program product is run on an electronic device, the electronic device executes the method as described in any one of claims 1 to 7.

Images