A virtual machine processing method, device and equipment for a software testing task

Abstract

The application provides a virtual machine processing method, device and equipment for software testing tasks, and relates to the field of virtual machines.The method comprises the following steps: obtaining a software testing task list and a template testing virtual machine; configuring a resource package of at least one software testing task on the template testing virtual machine according to a plurality of software testing tasks in the software testing task list, to obtain a plurality of virtual machines; performing dependency processing on the plurality of software testing tasks currently being tested by the plurality of virtual machines respectively; determining the running state of the current virtual machine in the dependency processing of the software testing task by the resource package of at least one software testing task after the current virtual machine is started according to a start task; and destroying the current virtual machine and starting the next virtual machine according to the running state until the plurality of software testing tasks are tested.The scheme of the application realizes the automatic management of the whole running cycle of the virtual machine, and improves the efficiency of virtual machine management and the utilization rate of network resources.

Description

Technical Field

[0001] This invention relates to the field of virtual machines, and more specifically to a virtual machine processing method, apparatus, and device for software testing tasks. Background Technology

[0002] With the rapid development of cloud computing technology, virtual machines, as a core component of cloud computing, have been widely used in enterprise data centers, scientific research experiments, software development, and other fields. In practical applications, it is often necessary to manage the runtime cycle of a large number of virtual machines, including operations such as creation, configuration, operation, monitoring, and destruction. There is also a frequent need to create and run virtual machines in batches and repeatedly to complete specific short-term tasks, such as software compatibility testing, automated deployment verification, or periodic task processing. In this task-driven mode, the runtime cycle of virtual machines is usually short and highly repetitive, and its management process is characterized by frequent creation, consistent configuration requirements, and the need to promptly reclaim resources after the task is completed. Traditional virtual machine management methods mostly rely on manual operation, which has many problems. When conducting large-scale testing tasks, it is necessary to create a large number of virtual machines with specific configurations. After the test is completed, these virtual machines need to be destroyed in a timely manner to release resources. If manual management is adopted, it is not only time-consuming and labor-intensive, but also difficult to guarantee the accuracy and timeliness of management. There is a lack of automated monitoring and response mechanisms for the running status of virtual machines. After the task is completed, virtual machine resources are often idle and cannot be released in a timely manner, resulting in a waste of computing, storage and network resources, and high management costs. Summary of the Invention

[0003] This invention provides a virtual machine processing method, apparatus, and device for software testing tasks, which solves the problems of existing virtual machine management methods being unable to monitor and control the entire virtual machine operation process in real time, as well as the low efficiency of configuring virtual machines, the susceptibility to configuration errors, and the high management costs.

[0004] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows: An embodiment of the present invention proposes a virtual machine processing method for software testing tasks, comprising: Obtain the software test task list and the template test virtual machine created for the software test task list; Based on the multiple software testing tasks in the software testing task list, the template test virtual machine is configured with resource packages for at least one software testing task, and based on a preset range of IP address pools, the template test virtual machine is configured with IP addresses to obtain multiple virtual machines. Dependency handling is performed on multiple software test tasks under the current test using multiple virtual machines; After the current virtual machine starts according to the boot startup task, determine the running status of the current virtual machine in at least one software test task's resource package to handle the software test task's dependencies. Based on the running status, destroy the current virtual machine and start the next virtual machine, until multiple software test tasks are completed.

[0005] Optionally, the template test virtual machine is configured with resource packages for at least one software test task based on multiple software test tasks in the software test task list, including: Based on the multiple software testing tasks in the software testing task list, determine the basic parameters of the software testing resource package corresponding to at least one software testing task; the basic parameters of the software testing resource package include: the task identifier and instructions corresponding to the software testing resource package, the test execution script, the environment configuration parameters, the communication and coordination mechanism, and the start trigger; Based on the basic parameters of the software testing resource package, configure the software package installation source of the template test virtual machine in the physical machine; Based on the software package installation source, configure the resource package for at least one software testing task for the template test virtual machine.

[0006] Optionally, the template test virtual machine is configured with an IP address based on a preset range of IP address pools, including: Configure the Dynamic Host Configuration Protocol (DHCP) service for the physical machine and configure an IP address pool containing the preset range; Start the Dynamic Host Configuration Protocol service to make the IP address pool available for allocation; Configure the network card IP address allocation method of the template test virtual machine to Dynamic Host Configuration Protocol mode; When the template test virtual machine starts, an IP address is dynamically allocated to the template test virtual machine from the IP address pool through the Dynamic Host Configuration Protocol service.

[0007] Optionally, after the current virtual machine starts according to the startup task, determine the running status of the current virtual machine in at least one software test task's resource package for dependency processing of the software test task, including: When the virtual machine starts, it automatically runs the preset startup scripts that have been added to the management list of the check settings service through the pre-configured check settings service; After the preset startup script is executed, at least one software test task information to be processed is obtained from the preset location; Based on the obtained software testing task information, the software testing resource package configured in the virtual machine is used to perform the dependency installation and processing operations for the software testing task. After the processing operation is completed, the status information of the dependency processing results for the software testing task is generated and output. Based on the status information of the dependency processing results, the current running status of the virtual machine is determined.

[0008] Optionally, the virtual machine processing method for the software testing task further includes: Create a directory in the specified directory of the physical server's operating system to store virtual machine hook scripts; Create and configure a virtual machine shutdown hook script in the directory. When the virtual machine management service detects that the virtual machine has entered the shutdown state, it will automatically call and execute the virtual machine shutdown hook script. When the virtual machine shutdown hook script is executed, it cleans up the network resources occupied by the virtual machine and records the corresponding shutdown operation log based on the name identifier of the virtual machine.

[0009] Optionally, multiple virtual machines may be selected to handle dependencies for the various software test tasks currently being tested, including: Once the virtual machine starts, it retrieves a shared list of software test tasks from the physical machine through the startup task. Extract information about at least one software package to be tested assigned to the current virtual machine from the shared list of software test tasks; Based on the extracted software package information, perform installation and dependency testing operations on the current software package in the virtual machine; After completing the installation and dependency testing operations, the shared software test task list is updated, and the test result status is returned to the physical machine so that the next virtual machine can obtain the updated list and execute subsequent test tasks.

[0010] Optionally, based on the running status, the current virtual machine is destroyed and the next virtual machine is started, until multiple software test tasks are completed, including: When the monitoring script detects that the current virtual machine is in a shutdown state, it triggers and executes the pre-configured shutdown hook script associated with that virtual machine. When the shutdown hook script is executed, it cleans up the IP address allocation record corresponding to the virtual machine from the lease file of the virtual machine's host configuration protocol server according to the virtual machine's identification information; After clearing the IP address allocation records, the current virtual machine, which is in a shutdown state, is destroyed using virtualization management commands; After destroying the current virtual machine, restart the host configuration protocol service to make the lease file cleanup operation take effect, and decide whether to clone and start a new virtual machine based on the template test virtual machine to continue executing the test tasks, based on the remaining tasks in the software test task list, until multiple software test tasks are completed.

[0011] Embodiments of the present invention also provide a virtual machine processing apparatus for software testing tasks, comprising: The acquisition module is used to acquire the software test task list and the template test virtual machine created for the software test task list. The first processing module is configured to configure resource packages for at least one software test task on the template test virtual machine according to multiple software test tasks in the software test task list, and to configure IP addresses for the template test virtual machine according to a preset range of IP address pools, thereby obtaining multiple virtual machines; to process dependencies of the multiple software test tasks being tested through the multiple virtual machines respectively; after the current virtual machine starts according to the boot startup task, to determine the running status of the current virtual machine in processing dependencies of the software test tasks in the resource packages of at least one software test task; and to destroy the current virtual machine and start the next virtual machine according to the running status, until the multiple software test tasks are completed.

[0012] Embodiments of the present invention also provide a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method described above.

[0013] Embodiments of the present invention also provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described above.

[0014] The above-described solution of the present invention has at least the following beneficial effects: The virtual machine processing method for software testing tasks described in this invention involves obtaining a software testing task list and a template test virtual machine created for the software testing task list; configuring resource packages for at least one software testing task on the template test virtual machine according to multiple software testing tasks in the software testing task list, and configuring IP addresses for the template test virtual machine according to a preset range of IP address pools, resulting in multiple virtual machines; processing dependencies for the multiple software testing tasks under current testing using these multiple virtual machines; determining the running status of the current virtual machine in processing dependencies for at least one software testing task's resource package after it starts according to the boot task; and destroying the current virtual machine and starting the next virtual machine based on the running status, until multiple software testing tasks are completed. This method achieves automated management of the entire virtual machine runtime cycle, improving the efficiency and flexibility of virtual machine management and the utilization rate of network resources, reducing operating costs, and preventing configuration errors. Attached Figure Description

[0015] Figure 1 This is a flowchart of the virtual machine processing method for software testing tasks according to the present invention; Figure 2 This is a block diagram of the virtual machine processing device for software testing tasks according to the present invention; Detailed Implementation Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0016] like Figure 1 As shown, an embodiment of the present invention provides a virtual machine processing method for software testing tasks, including: Step 1: Obtain the software test task list and the template test virtual machine created for the software test task list; Step 2: Configure the resource package of at least one software test task for the template test virtual machine according to the multiple software test tasks in the software test task list, and configure the IP address of the template test virtual machine according to the IP address pool within a preset range, so as to obtain multiple virtual machines; Step 3: Perform dependency processing on the multiple software test tasks being tested using multiple virtual machines; Step 4: After the current virtual machine starts according to the boot startup task, determine the running status of the current virtual machine in at least one software test task's resource package for handling dependencies on the software test task. Step 5: Based on the running status, destroy the current virtual machine and start the next virtual machine until multiple software test tasks are completed.

[0017] In this embodiment, the software test task list is the core basis for software testing, recording in detail all relevant information of the test tasks that need to be executed. The client can submit the software test task list through the interactive interface or application programming interface provided by the physical machine. For example, it can be used to perform installation dependency tests on multiple software packages through a preset number of virtual machines. In the software package dependency test example, the list can be compared to a list of software packages to be tested (such as a B9checklist file), which clearly records the names of the software packages whose dependencies need to be verified, the test objectives (such as ensuring that the software packages can be installed normally and that the dependencies are not abnormal), and other key content. All subsequent test operations of the virtual machines will revolve around the tasks in this list to ensure that the test does not deviate from the objectives.

[0018] In this embodiment, the creation of the template test virtual machine in step 1 is mainly used to create a template test virtual machine and perform a series of configurations so that the virtual machine can automatically perform corresponding operations according to the user-defined tasks, meeting the personalized needs of different tasks. The template test virtual machine can be created in the following way: First, start the libvirtd (virtual machine management) service, select an operating system image that matches the test task (such as a non-everything image adapted for package testing) for installation to avoid irrelevant software interfering with the test results; configure the basic operating environment, including changing the network card IP allocation method to DHCP (to ensure that the virtual machines cloned in batches can automatically obtain IPs), and correctly setting the package installation source (to ensure that the software required in the test can be obtained normally); add the basic configuration of the boot startup tasks in advance to adapt to the task list, allowing users to adjust it independently according to the specific test requirements in the list, so that the virtual machine can directly connect to the test tasks after startup without additional manual configuration, realizing automatic task driving; create a script to execute when the template test virtual machine starts up, and use the chkconfig (check settings) service to realize the script to start automatically at boot, thereby obtaining the template test virtual machine.

[0019] The virtual machine processing method for software testing tasks described in this invention automatically generates virtual machines corresponding to the software testing tasks by matching template test virtual machines during software testing. This replaces the repetitive steps of traditional manual virtual machine creation, system installation, and environment configuration, significantly reducing the manual intervention required by administrators, effectively shortening the cycle of batch deployment of virtual machines, and enabling rapid response to large-scale, rapidly iterative task requirements, thus significantly improving the overall efficiency of virtual machine management. Simultaneously, it solves problems such as parameter deviations and operational errors that easily occur during manual configuration, ensuring the accuracy and repeatability of task execution results such as software compatibility testing and automated deployment verification. By acquiring the current task execution status of the virtual machine in real time during task execution and destroying the virtual machine based on the status data, this mechanism can promptly identify key nodes such as task completion status and abnormal virtual machine operation status, triggering corresponding preprocessing actions such as resource reclamation and fault handling, avoiding idle virtual machine resources after task completion. This effectively reduces the waste of computing, storage, and network resources, improves the resource utilization rate of cloud computing infrastructure, thereby achieving automated management of the entire virtual machine lifecycle, improving the efficiency and flexibility of virtual machine management and the utilization rate of network resources, reducing operating costs, and preventing configuration errors.

[0020] In an optional embodiment of the present invention, step 2, configuring the resource package of at least one software test task for the template test virtual machine according to multiple software test tasks in the software test task list, may include: Step 21: Based on the multiple software testing tasks in the software testing task list, determine the basic parameters of the software testing resource package corresponding to at least one software testing task; the basic parameters of the software testing resource package include: the task identifier and instructions corresponding to the software testing resource package, the test execution script, the environment configuration parameters, the communication and coordination mechanism, and the start trigger; Step 22: Based on the basic parameters of the software test resource package, configure the software package installation source of the template test virtual machine in the physical machine; Step 23: Configure resource packages for at least one software test task for the template test virtual machine according to the software package installation source.

[0021] In this embodiment, step 21 may include: determining the basic parameters required for the resource package to run based on the task test scenario, including operating system version compatibility requirements, memory / storage resource thresholds, network connection modes, etc., to avoid the resource package failing to run properly due to mismatched environmental parameters; clarifying the communication protocol, data interaction format, and collaboration rules (such as the frequency and data format of the virtual machine feeding back the resource package configuration status to the control node) between the virtual machine and the physical machine, other virtual machines, or test control nodes corresponding to the resource package, to ensure smooth information transmission during the test; setting the triggering conditions for the resource package to take effect, usually associated with the virtual machine startup process, to ensure that the resource package loading or test execution script execution can be automatically triggered after the virtual machine starts up, reducing manual intervention; In this embodiment, step 22 may include selecting a suitable software package installation source type (such as a local installation source or a network installation source) based on the determined environment configuration parameters; if a local installation source is selected, the software package installation file corresponding to the basic parameters of the resource package is copied to a specified directory on the physical machine, a local shared installation source is set up, and access permissions are configured; if a network installation source is selected, the address information and authentication information of the network installation source are configured on the physical machine to ensure that the physical machine can access the network source normally; on the physical machine, the software package acquisition path of the template test virtual machine is configured through a virtual machine management tool (such as libvirtd related management tools) to point to the installation source that has been set up on the physical machine, and the connection validity is verified to ensure that the template virtual machine can obtain software packages normally from the installation source; In this embodiment, step 23 may include: starting the template test virtual machine, accurately selecting at least one software test resource package corresponding to a test task from the installation source configured on the physical machine according to the determined task identifier, and ensuring that the version and type of the resource package are consistent with the task requirements; deploying the selected resource package from the installation source to the specified directory of the template virtual machine through the communication channel between the template virtual machine and the physical machine, and completing the configuration operations such as installation, decompression, and path configuration of the resource package according to the basic parameters set in step 21.

[0022] In an optional embodiment of the present invention, step 2, configuring the IP address of the template test virtual machine according to a preset range of IP address pools, may include: Step 24: Configure DHCP (Dynamic Host Configuration Protocol) service for the physical machine and configure an IP address pool containing the preset range; Step 25: Start the DHCP service to make the IP address pool available for allocation; Step 26: Configure the network card IP address allocation method of the template test virtual machine to DHCP mode; Step 27: When the template test virtual machine starts, dynamically allocate an IP address to the template test virtual machine from the IP address pool through the DHCP service.

[0023] In this embodiment, the DHCP (Dynamic Host Configuration Protocol) service is mainly used to provide an automated allocation mechanism for virtual machines to obtain IP (network address) addresses, ensuring that virtual machines can quickly and accurately obtain available IP addresses for network communication. The DHCP service can be obtained by configuring the IP (network address) pool of the DHCP service. The specific implementation process of steps 24 to 26 in this embodiment can be as follows: install the dhcp package in the physical machine system, check the service status through systemctlstatus dhcp after installation to ensure that the DHCP service is started normally; then, by modifying the dhcpd.conf file in the physical machine, allocate the IP pool within the preset range, and enable the automatic update function of the DNS (Dynamic Domain Name System) server. When the DHCP server updates the IP address of a virtual machine, it can automatically update the corresponding DNS record to ensure that the IP address and the virtual machine domain name maintain the correct correspondence.

[0024] In an optional embodiment of the present invention, step 3, which processes dependencies for the multiple software testing tasks under the current test using multiple virtual machines, may include: Step 31: After the virtual machine starts, obtain the shared software test task list from the physical machine through the boot startup task; Step 32: Extract information on at least one software package to be tested assigned to the current virtual machine from the shared software test task list; Step 33: Based on the extracted software package information, perform the installation and dependency testing operations for the current software package in the virtual machine; Step 34: After completing the installation and dependency testing operations, update the shared software test task list and return the test result status to the physical machine so that the next virtual machine can obtain the updated list and execute subsequent test tasks.

[0025] In this embodiment, step 31 may include: actively initiating a shared directory access request to the physical machine through a startup task (such as a preset script) according to the configured path, completing authentication through pre-configured authentication information (such as username, password, and key) to avoid unauthorized access; after successful authentication, accurately downloading the current version of the software test task list from the shared directory of the physical machine, saving it to a specified cache directory on the local machine, and recording the acquisition time and list version number (for subsequent traceability and update comparison). In this embodiment, step 32 may include: the virtual machine first obtains its own unique identifier (such as a preset virtual machine name prefix or ID number), which is consistent with the rules of the "task allocation object" field in the shared task list and serves as the core matching basis for task extraction; the startup task parses the shared list according to preset rules, filters out task entries with an allocation status of unallocated and adapted to the current virtual machine test environment (such as operating system version matching), and then determines at least one software package information to be tested to be allocated to the current virtual machine according to the preset task allocation rules in the list (such as round-robin allocation by virtual machine ID or targeted allocation by task type); extracts software package information from the matched task entries and stores it locally on the virtual machine, the information including: software package name, version number, installation requirements (such as installation path and configuration parameters), dependency verification standards (such as a list of dependency packages to be verified and verification methods), and task ID (unique identifier); after extraction, the task is marked as being processed locally, and a temporary lock request is initiated to the physical machine to update the allocation status of the corresponding task entry in the shared list to being locked (marking the locking subject as the current virtual machine) to prevent other virtual machines from repeatedly extracting the task.

[0026] In this embodiment, step 33 may include: based on the extracted package information, calling the installation tools (such as yum, apt) configured in the virtual machine, downloading the corresponding version of the package from the physical machine installation source (the package installation source configured in the physical machine in step 2) according to the extracted installation requirements, and automatically performing the installation operation; after the package is installed, performing tests according to the preset dependency verification standards: automatically detecting whether all the dependency packages required for the package to run are successfully installed and whether the versions match; starting the core function of the package and verifying whether the dependencies can support the normal operation of the function (such as testing whether the core commands of the package can be executed and whether the service can start normally); simulating abnormal scenarios (such as disabling a certain dependency) to verify the fault tolerance and dependency alarm mechanism of the package; if a dependency is found to be missing or mismatched during the test, automatically attempting to supplement and install the compatible dependency package from the installation source and then retesting; if the problem still cannot be solved after supplementing the installation, recording detailed abnormal information (such as dependency package name, reason for version incompatibility); if there are no abnormalities in the test, confirming that the test has passed.

[0027] In this embodiment, step 34 may include: After the test is completed, the virtual machine automatically organizes standardized test results, including: task ID, package name and version, test time, test result (pass / fail / abnormal), detailed test log (installation steps, dependency list, test case execution status), and exception details (supplemented when there is a failure / abnormality); the virtual machine re-accesses the physical machine's shared directory, opens the shared task list, locates the task entry it is processing by task ID, and executes the following update tasks: first, updates the allocation status from locked to completed, and then fills in the relevant fields of the test result (such as result type, completion time); an exclusive lock mechanism is enabled during the update to avoid the list being disordered due to multiple virtual machines updating at the same time; the results are synchronized in two ways to ensure that the physical machine receives them accurately: the organized test results are generated into an independent result file (naming rule: task ID, virtual machine ID, timestamp), and uploaded to the result feedback subdirectory of the physical machine's shared directory; a push notification (such as an HTTP request) is sent to the physical machine's test control service to inform that the results have been generated, so that the physical machine can summarize them in a timely manner; after the virtual machine confirms that the shared list has been updated successfully (by comparing the list versions before and after the update) and that the result file has been successfully uploaded, it clears the locally cached task information.

[0028] In an optional embodiment of the present invention, step 4, after the current virtual machine starts according to the boot startup task, determining the running status of the current virtual machine in at least one software test task's resource package for dependency processing of the software test task, may include: Step 41: When the virtual machine starts, the preset startup scripts that have been added to the management list of the chkconfig service will be run automatically through the pre-configured chkconfig service. Step 42: After the preset startup script is executed, at least one software test task information to be processed is obtained from a preset location; Step 43: Based on the obtained software testing task information, perform the dependency installation and processing operations for the software testing task through the software testing resource package configured in the virtual machine; Step 44: After the processing operation is completed, generate and output the status information of the dependency processing results for the software testing task; Step 45: Determine the current running status of the virtual machine based on the status information of the dependency processing result.

[0029] In this embodiment, step 41 may include: when the current virtual machine starts up, the system will automatically initialize various basic services, and the chkconfig service will start and load all preset services or scripts in its management list; at this time, the chkconfig service will automatically call and run the target startup script according to the preset startup priority (this script is pre-configured for the software testing task and is specifically used to trigger the subsequent dependency processing flow); in this embodiment, step 42 may include: after the preset startup script is successfully executed, it will locate the preset location storing the software testing task information according to the path preset in the script (this location can be a local directory of the virtual machine, a shared storage directory of the physical machine, or the task distribution directory of the test control node, and access permissions have been pre-configured); the script will obtain at least one software testing task information file to be processed (such as a task list document, task configuration file, etc.) from this location according to the preset reading rules, and parse the file content to extract key information, including but not limited to the identifier of the task to be tested, the test target, the list of required dependencies, the dependency processing standards, etc. In this embodiment, step 43 may include: based on the software test task information parsed in step 42, the virtual machine locates the pre-configured corresponding software test resource package (this resource package is configured in step 2 for the test task list, including dependency installation tools, adapted dependency package files, processing scripts, etc.), and confirms that the resource package is in a callable state; according to the dependency list in the task information, the resource package automatically calls the internal installation tool to obtain the required dependency packages from the preset package installation source and performs the installation operation according to the preset installation order; during the process, the association between dependency packages is automatically handled (such as installing the basic dependency package first, and then installing the upper-level dependency package) to avoid installation conflicts; after the dependency installation is completed, the resource package will perform subsequent adaptation processing (such as configuring dependency running parameters, associating the test task with the dependency running path, etc.); step 44 may include: after the dependency processing is completed (regardless of (Success or failure) The system will summarize the key information of the entire processing process and organize it into standardized dependency processing result status information, including: task identifier, processing completion time, processing result (success / failure), detailed processing log (such as the list of installed dependencies, the running status of each stage of the virtual machine), and exception information (if the processing fails, it includes exception details and troubleshooting guidance). According to the preset output rules, the processing result status information is output to multiple target locations in a specified form to ensure that the information is traceable and can be identified by subsequent processes, thereby ensuring that the virtual machine running status can be accurately determined later. Step 45 may include: determining the current running status of the virtual machine based on parameters such as the task identifier and processing completion time in the dependency processing result status information. For example, if the dependency processing result status information shows that the current virtual machine has started the current task at a certain time, it can be confirmed that the current virtual machine is in a shutdown state.

[0030] In an optional embodiment of the present invention, the virtual machine processing method for the software testing task further includes: Step 61: Create a directory in the specified directory of the physical server's operating system to store virtual machine hook scripts; Step 62: Create and configure a virtual machine shutdown hook script in the directory. When the libvirtd service detects that the virtual machine has entered the shutdown state, it will automatically call and execute the virtual machine shutdown hook script. Step 63: When the virtual machine shutdown hook script is executed, it cleans up the network resources occupied by the virtual machine and records the corresponding shutdown operation log according to the name identifier of the virtual machine.

[0031] In this embodiment, step 61 may include: first, logging into the physical server operating system and identifying the default directory for hook script recognition supported by the libvirtd service (if the documentation specifies a directory, follow the documentation requirements first; otherwise, use the system's standard libvirt hook script directory, such as / etc / libvirt / hooks / ), to avoid scripts not being recognized by the service due to incorrect directory paths; using system commands to create a directory specifically for storing virtual machine hook scripts (which can be named vm-shutdown-hooks) under the confirmed specified path, and configuring appropriate permissions for the created hook script directory, typically set to read and write permissions only for the physical server administrator and executable permissions for the libvirtd service (to prevent ordinary users from accidentally modifying or deleting scripts), and confirming that the directory owner and group are associated with the libvirtd service-related users to ensure the service has normal access permissions to the directory.

[0032] In this embodiment, step 62 may include: entering the hook script directory, creating a virtual machine shutdown hook script file (e.g., named qemu-shutdown-hook) using a text editing tool, and adding a basic header declaration to the script (specifying the script interpreter, such as the shell interpreter adapted to the operating system); writing shutdown state detection and triggering logic in the script, including: associating with libvirtd service state monitoring: capturing virtual machine state signals transmitted by the libvirtd service through script code, specifying that subsequent script logic will only be executed when a signal indicating that the virtual machine has entered the shutdown state is received (e.g., the SHUTDOWN state identifier defined by libvirt); defining script triggering conditions: limiting the script to only apply to virtual machines related to the current software testing task (this can be achieved by matching virtual machine name prefixes, identifiers, etc.), avoiding accidental triggering of operations on other unrelated virtual machines; configuring executable permissions for the hook script (ensuring that the libvirtd service can be called normally), and registering the script path to the hook script configuration list of the libvirtd service to complete the association between the script and the service.

[0033] In this embodiment, step 63 may include: when the libvirtd service detects that a virtual machine is shutting down and calls the hook script, the script first extracts the name identifier (such as the virtual machine's unique name, ID, etc.) of the currently shut-down virtual machine from the parameters passed by the libvirtd service, using this as the sole basis for subsequent operations to ensure that resource cleanup and log recording accurately correspond to the target virtual machine; based on the extracted virtual machine name identifier, the script performs network resource cleanup, including: releasing IP addresses, for example, reclaiming the IP address occupied by the virtual machine to a preset IP address pool (the IP pool configured in step 2), marking it as "reallocable" to avoid IP resource residue leading to waste or conflict; cleaning up network-related configurations, for example, deleting network forwarding rules, port mappings, ARP cache entries, and other network configurations corresponding to the virtual machine to ensure that there is no redundant information in the network environment interfering with the subsequent operation of the virtual machine. Okay; at the same time, the script automatically generates standardized shutdown operation logs, including: virtual machine name identifier, shutdown trigger time, network resource cleanup details (such as reclaimed IP addresses, cleaned network configuration items), cleanup results (success / failure), script execution status, etc.; and writes the log content to a preset log file (which can be stored in a dedicated log directory such as / var / log / libvirt / vm-shutdown / on the physical server) to ensure centralized log management and easy querying; before the script finishes execution, it verifies the network resource cleanup results and log records to confirm that IP addresses have been successfully reclaimed to the IP pool, network configurations have no residue, and log records are complete and formatted correctly; if cleanup or log recording fails, the script will mark the exception information in the log and report the exception status to the libvirtd service log for subsequent troubleshooting.

[0034] In an optional embodiment of the present invention, step 5, based on the running state, destroys the current virtual machine and starts the next virtual machine, until multiple software test tasks are completed, including: Step 51: When the monitoring script detects that the current virtual machine is in a shutdown state, it triggers and executes the pre-configured shutdown hook script associated with the virtual machine. Step 52: When the shutdown hook script is executed, the IP address allocation record corresponding to the virtual machine is cleared from the lease file of the DHCP server according to the identification information of the virtual machine. Step 53: After clearing the IP address allocation record, destroy the current virtual machine that is in a shutdown state using virtualization management commands; Step 54: After destroying the current virtual machine, restart the DHCP service to make the lease file cleanup operation take effect, and decide whether to clone and start a new virtual machine based on the template test virtual machine to continue executing the test tasks, based on the remaining tasks in the software test task list, until multiple software test tasks are completed.

[0035] In this embodiment, the monitoring script actively queries or receives virtual machine status information pushed by the libvirtd service at a preset frequency (e.g., every 10 seconds), and filters the current virtual machine status data to identify shutdown status indicators such as "shutting down" and "already shut down". Step 51 may include: when the current virtual machine is detected to be in shutdown state, the script immediately extracts the unique identifier of the virtual machine (e.g., virtual machine name, ID), matches the identifier with a pre-configured dedicated shutdown hook script (ensuring that the hook script corresponds one-to-one with the target virtual machine to avoid accidentally triggering other scripts), and automatically calls and executes the script; at the same time, the monitoring script can also synchronously record the details of the trigger event, including the virtual machine identifier, shutdown status detection time, hook script call time and call status (success / failure). If the call fails, an alarm message is immediately generated and pushed to the physical machine management terminal for timely troubleshooting.

[0036] In this embodiment, step 52 may include: after the shutdown hook script is executed, it first obtains the unique identifier of the current virtual machine from the calling parameters, and then locates the lease file of the DHCP server (such as / var / lib / dhcpd / dhcpd.leases) according to the preset path. This file records the detailed information of all assigned IPs (including virtual machine identifier, IP address, lease term, etc.). The script traverses the contents of the lease file according to the virtual machine identifier, filters out the IP address allocation record bound to the current virtual machine, and after confirming that the IP address, virtual machine identifier and other information in the record are correct, it performs a cleanup operation to delete the allocation record or mark it as invalid, ensuring that the IP address is no longer associated with the current virtual machine. After the cleanup is completed, the script reads the lease file for a second check to confirm that the target record has been successfully cleaned or invalidated. At the same time, it verifies whether the IP address has changed from an assigned state to a pending state through the query command of the DHCP service. If the cleanup fails, the script automatically retryes the cleanup operation. If it still fails, it records the exception and issues an alarm.

[0037] In this embodiment, step 53 may include: before performing the destruction operation, first querying the current virtual machine status again through the libvirtd service to ensure that it is in a stable, shut-down state (to avoid resource residue caused by performing destruction while the machine is shut down), and at the same time confirming that the IP allocation record has been cleared and there are no resource-related residues; calling standardized virtualization management commands (such as virsh-related commands) on the physical machine, passing in the unique identifier of the current virtual machine, and performing the destruction operation, not only deleting the running instance of the virtual machine, but also clearing the virtual machine's configuration files, disk images (if the default is to delete the image after the task is completed) and other associated resources on the physical machine, completely releasing the physical machine's hardware resources; after the destruction command is executed, querying the virtual machine list through the virtualization management tool to confirm that the target virtual machine has been removed from the list; at the same time, checking the CPU, memory, storage and other resource usage of the physical machine to confirm that the resources related to the virtual machine have been released and there are no resource residues.

[0038] In this embodiment, step 54 may include: executing a DHCP service restart command on the physical machine (stopping the service first and then starting it) to ensure that the lease file cleanup operation takes effect and the updated IP address pool status (released IPs are reinstated into the allocation range) is recognized by the DHCP service; simultaneously configuring the DHCP service to start automatically on boot to avoid service interruption caused by subsequent physical machine restarts; after restarting the service, the script automatically accesses the shared software test task list on the physical machine, counts the number of remaining tasks according to preset rules, filters out unassigned, locked but incomplete (it needs to be verified whether it is a failed lock) task entries, and summarizes them to obtain the remaining test task list; deciding whether to clone and start a new virtual machine: if there are remaining test tasks: perform a cloning operation based on the template test virtual machine created in step 1, and automatically inherit the template's basic environment configuration (such as operating system, basic services, DHCP) during the cloning process. (IP acquisition mode), and simultaneously assign a unique identifier to the new virtual machine; after cloning, immediately start the new virtual machine to enter the subsequent test task execution process (starting from obtaining the shared task list); if there are no remaining test tasks: terminate the cloning startup process, generate a prompt message that the current batch of test tasks has been completed, and synchronously update the overall status of the software test task list to complete; repeat the above steps until the overall status of the finally updated software test task list is completed, then it proves that the tasks in the entire task list have been fully automatically tested by the virtual machine processing method for software test tasks described in this invention.

[0039] The following example illustrates the specific implementation process of the virtual machine processing method for software testing tasks described in this invention: (The example uses package installation dependency testing.) First, it should be noted that when building a new operating system image, the software packages in the software source need to be installed and tested to ensure that the non-Everything image provided externally can handle all package dependencies and install them correctly. This process requires continuously creating new non-Everything image virtual machines to prevent manually installed packages from affecting the dependencies of the packages being installed in this test. Therefore, the solution of this invention can automatically perform package installation dependency testing. The specific implementation process is as follows: First, install the DHCP package on the physical machine. After installation, check the service status using `systemctl status dhcp` to ensure the DHCP service is running correctly. Then, modify the ` / etc / dhcp / dhcpd.conf` file, specifying the `range` field to allocate IP addresses in the range 192.18.17.235-192.18.17.245, and the `routers` field to allocate the routing address 192.18.17.1. Specify the lease duration for dynamically allocated IP addresses. Enable the DNS server automatic update function `ddns-updateson`, which automatically updates the corresponding DNS records when the DHCP server updates the IP address of a virtual machine, ensuring the correct mapping between IP addresses and virtual machine domain names. Use the `virsh` command to create a template test virtual machine based on the virtual machine image file. Enter the virtual machine via the console command link. First, modify the `ifcfg-enp1s0` network interface configuration file, changing `BOOTPROTO` (boot protocol) to DHCP mode. This will allow the virtual machine to establish a connection with the physical machine's DHCP server after startup and obtain a dynamically assigned IP address. Ensure the server has the libvirtd service installed and running. Install the template test virtual machine according to the preset virtual machine image template and UEFI firmware, and modify the `qemu.conf` file of the libvirt service to specify the location of the AARCH (ARM architecture) server UEFI firmware. To add a startup task to the test virtual machine, a script was created to execute on startup. The script was implemented using the chkconfig service, which was added to the chkconfig management list and configured to start its tasks at a specific runlevel. The startup script `autostart.sh` was created in the ` / etc / rc.d / init.d` directory, and the script `B9yumtest.sh` was run. The `B9yumtest.sh` script modifies the package manifest file `B9checklist` on the physical machine and returns the names of the packages to be installed. After obtaining the package names, the virtual machine installs the corresponding packages and returns the installation results to the physical machine. The analysis is as follows: The B9yumtest.sh script uses the expect command to perform passwordless SSH login and uploads the B9checklist package manifest file from the physical machine to the virtual machine. The virtual machine obtains the first line of content, which is the package that needs to be installed and tested. Then, it performs yum installation to test whether the dependencies are normal. At the same time, it returns the B9checklist package manifest file with the first line of content deleted to the physical machine via SSH command for other virtual machines to obtain and use later. The boot task here is just an example and can be configured by the user to complete the configuration of the task-driven virtual machine used in this invention and achieve a high degree of customization of the virtual machine template.

[0040] Meanwhile, a virtual machine shutdown hook script is configured within the libvirtd service to ensure that the virtual machine can automatically perform corresponding operations after shutdown. Lease information is stored in ` / var / lib / dhcpd / dhcpd.leases`. If the lease time is set too long, it can lead to IP addresses not being allocated, resulting in insufficient IP pool resources. Therefore, a shutdown hook script is used for dynamic IP release. A `hooks` folder is created in the ` / etc / libvirt` directory of the system, and a hook script named `qemu` is created. When the libvirt service detects that a virtual machine with a specified name has entered the stopped shutdown state, the corresponding hook script will be triggered to use the `sed` command to delete the lease information in the lease file, ensuring accurate matching and execution of the preset hook operations in the shutdown state. Simultaneously, the shutdown behavior of relevant test virtual machines is batch-controlled based on the virtual machine name, and detailed operation logs are recorded for subsequent querying and analysis. Then, the `virsh-clone` command is used to clone multiple test virtual machines based on the template test virtual machine. After these test virtual machines are started, the monitoring script will periodically check the running status of each virtual machine. Once a test virtual machine is detected to be in a shutdown state, the script will perform a destruction operation on it and clone a new test virtual machine again based on the template test virtual machine, thus forming an automated loop process to achieve task-driven automated management of batch virtual machines throughout their entire lifecycle. The monitoring script specifies the names of the virtual machines to be created through a name list. When a virtual machine is detected to be in a shutdown state, the `virsh` command is used to perform a destruction and reconstruction operation. After deleting the virtual machine, the DHCP service needs to be restarted to ensure that the shutdown hook script `qemu` takes effect on the lease file modifications. The loop of creating test virtual machines stops when the B9checklist file (software test task list) is empty.

[0041] like Figure 2 As shown, embodiments of the present invention also provide a virtual machine processing device 20 for software testing tasks, comprising: Module 201 is used to obtain the software test task list and the template test virtual machine created for the software test task list. The first processing module 202 is configured to configure resource packages for at least one software test task on the template test virtual machine according to multiple software test tasks in the software test task list, and to configure IP addresses for the template test virtual machine according to a preset range of IP address pools to obtain multiple virtual machines; to process dependencies of the multiple software test tasks being tested through the multiple virtual machines respectively; after the current virtual machine starts according to the boot startup task, to determine the running status of the current virtual machine in processing dependencies of the software test tasks in the resource packages of at least one software test task; and to destroy the current virtual machine and start the next virtual machine according to the running status, until the multiple software test tasks are completed.

[0042] Optionally, the template test virtual machine is configured with resource packages for at least one software test task based on multiple software test tasks in the software test task list, including: Based on the multiple software testing tasks in the software testing task list, determine the basic parameters of the software testing resource package corresponding to at least one software testing task; the basic parameters of the software testing resource package include: the task identifier and instructions corresponding to the software testing resource package, the test execution script, the environment configuration parameters, the communication and coordination mechanism, and the start trigger; Based on the basic parameters of the software testing resource package, configure the software package installation source of the template test virtual machine in the physical machine; Based on the software package installation source, configure the resource package for at least one software testing task for the template test virtual machine.

[0043] Optionally, the template test virtual machine is configured with an IP address based on a preset range of IP address pools, including: Configure DHCP service for the physical machine and configure an IP address pool containing the preset range; Start the DHCP service to make the IP address pool available for allocation; Configure the network card IP address allocation method of the template test virtual machine to DHCP mode; When the template test virtual machine starts, an IP address is dynamically allocated from the IP address pool through the DHCP service.

[0044] Optionally, after the current virtual machine starts according to the startup task, determine the running status of the current virtual machine in at least one software test task's resource package for dependency processing of the software test task, including: When the virtual machine starts, it automatically runs the preset startup scripts that have been added to the management list of the chkconfig service through the pre-configured chkconfig service; After the preset startup script is executed, at least one software test task information to be processed is obtained from the preset location; Based on the obtained software testing task information, the software testing resource package configured in the virtual machine is used to perform the dependency installation and processing operations for the software testing task. After processing is complete, the status information of the dependency processing results for the software testing task is generated and output. Based on the status information of the dependency processing results, the current running status of the virtual machine is determined.

[0045] Optionally, the virtual machine processing device for the software testing task further includes: The second processing module is used to create a directory for storing virtual machine hook scripts in a specified directory of the physical server operating system; to create and configure a virtual machine shutdown hook script in the directory; when the libvirtd service detects that a virtual machine has entered a shutdown state, it automatically calls and executes the virtual machine shutdown hook script; when the virtual machine shutdown hook script is executed, it cleans up the network resources occupied by the virtual machine according to the name identifier of the virtual machine and records the corresponding shutdown operation log.

[0046] Optionally, multiple virtual machines may be selected to handle dependencies for the various software test tasks currently being tested, including: Once the virtual machine starts, it retrieves a shared list of software test tasks from the physical machine through the startup task. Extract information about at least one software package to be tested assigned to the current virtual machine from the shared list of software test tasks; Based on the extracted software package information, perform installation and dependency testing operations on the current software package in the virtual machine; After completing the installation and dependency testing operations, the shared software test task list is updated, and the test result status is returned to the physical machine so that the next virtual machine can obtain the updated list and execute subsequent test tasks.

[0047] Optionally, based on the running status, the current virtual machine is destroyed and the next virtual machine is started, until multiple software test tasks are completed, including: When the monitoring script detects that the current virtual machine is in a shutdown state, it triggers and executes the pre-configured shutdown hook script associated with that virtual machine. When the shutdown hook script is executed, it cleans up the IP address allocation record corresponding to the virtual machine from the lease file of the DHCP server according to the identification information of the virtual machine; After clearing the IP address allocation records, the current virtual machine, which is in a shutdown state, is destroyed using virtualization management commands; After destroying the current virtual machine, restart the DHCP service to make the lease file cleanup operation take effect, and decide whether to clone and start a new virtual machine based on the template test virtual machine to continue executing the test tasks, based on the remaining tasks in the software test task list, until multiple software test tasks are completed.

[0048] It should be noted that this device is the same as the method described above. All implementations in the above method embodiments are applicable to the embodiments of this device and can achieve the same technical effect.

[0049] Embodiments of the present invention also provide a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0050] Embodiments of the present invention also provide a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0051] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0052] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0053] In the embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0054] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0055] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0056] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0057] Furthermore, it should be noted that in the apparatus and method of the present invention, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent solutions of the present invention. Moreover, the steps performing the above series of processes can naturally be executed in the order described, but are not necessarily required to be executed in chronological order; some steps can be executed in parallel or independently of each other. Those skilled in the art will understand that all or any step or component of the method and apparatus of the present invention can be implemented in any computing device (including processors, storage media, etc.) or network of computing devices, in hardware, firmware, software, or a combination thereof. This is something that those skilled in the art can achieve by using their basic programming skills after reading the description of the present invention.

[0058] Therefore, the object of the present invention can also be achieved by running a program or a set of programs on any computing device. The computing device can be a known general-purpose device. Therefore, the object of the present invention can also be achieved simply by providing a program product containing program code implementing the method or apparatus. That is, such a program product also constitutes the present invention, and the storage medium storing such a program product also constitutes the present invention. Obviously, the storage medium can be any known storage medium or any storage medium developed in the future. It should also be noted that in the apparatus and method of the present invention, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent to the present invention. Furthermore, the steps performing the above series of processes can naturally be performed in the order described, but are not necessarily required to be performed in chronological order. Some steps can be performed in parallel or independently of each other.

[0059] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A virtual machine processing method for software testing tasks, characterized in that, include: Obtain the software test task list and the template test virtual machine created for the software test task list; Based on the multiple software testing tasks in the software testing task list, the template test virtual machine is configured with resource packages for at least one software testing task, and based on a preset range of IP address pools, the template test virtual machine is configured with IP addresses to obtain multiple virtual machines. Dependency handling is performed on multiple software test tasks under the current test using multiple virtual machines; After the current virtual machine starts according to the boot startup task, determine the running status of the current virtual machine in at least one software test task's resource package to handle the software test task's dependencies. Based on the running status, destroy the current virtual machine and start the next virtual machine, until multiple software test tasks are completed.

2. The virtual machine processing method for software testing tasks according to claim 1, characterized in that, Configure resource packages for at least one software test task for the template test virtual machine based on multiple software test tasks in the software test task list, including: Based on the multiple software testing tasks in the software testing task list, determine the basic parameters of the software testing resource package corresponding to at least one software testing task; the basic parameters of the software testing resource package include: the task identifier and instructions corresponding to the software testing resource package, the test execution script, the environment configuration parameters, the communication and coordination mechanism, and the start trigger; Based on the basic parameters of the software testing resource package, configure the software package installation source of the template test virtual machine in the physical machine; Based on the software package installation source, configure the resource package for at least one software testing task for the template test virtual machine.

3. The virtual machine processing method for software testing tasks according to claim 1, characterized in that, Based on a preset range of IP address pools, configure the IP address of the template test virtual machine, including: Configure the Dynamic Host Configuration Protocol (DHCP) service for the physical machine and configure an IP address pool containing the preset range; Start the Dynamic Host Configuration Protocol service to make the IP address pool available for allocation; Configure the network card IP address allocation method of the template test virtual machine to Dynamic Host Configuration Protocol mode; When the template test virtual machine starts, an IP address is dynamically allocated to the template test virtual machine from the IP address pool through the Dynamic Host Configuration Protocol service.

4. The virtual machine processing method for software testing tasks according to claim 1, characterized in that, After the current virtual machine starts according to the startup task, determine the running status of the current virtual machine in at least one software test task's resource package that handles dependencies on the software test task, including: When the virtual machine starts, it automatically runs the preset startup scripts that have been added to the management list of the check settings service through the pre-configured check settings service; After the preset startup script is executed, at least one software test task information to be processed is obtained from the preset location; Based on the obtained software testing task information, the software testing resource package configured in the virtual machine is used to perform the dependency installation and processing operations for the software testing task. After the processing operation is completed, the status information of the dependency processing results for the software testing task is generated and output. Based on the status information of the dependency processing results, the current running status of the virtual machine is determined.

5. The virtual machine processing method for software testing tasks according to claim 4, characterized in that, Also includes: Create a directory in the specified directory of the physical server's operating system to store virtual machine hook scripts; Create and configure a virtual machine shutdown hook script in the directory. When the virtual machine management service detects that the virtual machine has entered the shutdown state, it will automatically call and execute the virtual machine shutdown hook script. When the virtual machine shutdown hook script is executed, it cleans up the network resources occupied by the virtual machine and records the corresponding shutdown operation log based on the name identifier of the virtual machine.

6. The virtual machine processing method for software testing tasks according to claim 1, characterized in that, Multiple virtual machines are assigned to handle dependencies for the various software test tasks currently being tested, including: Once the virtual machine starts, it retrieves a shared list of software test tasks from the physical machine through the startup task. Extract information about at least one software package to be tested assigned to the current virtual machine from the shared list of software test tasks; Based on the extracted software package information, perform installation and dependency testing operations on the current software package in the virtual machine; After completing the installation and dependency testing operations, the shared software test task list is updated, and the test result status is returned to the physical machine so that the next virtual machine can obtain the updated list and execute subsequent test tasks.

7. The virtual machine processing method for software testing tasks according to claim 3, characterized in that, Based on the described running status, destroy the current virtual machine and start the next virtual machine, until multiple software test tasks are completed, including: When the monitoring script detects that the current virtual machine is in a shutdown state, it triggers and executes the pre-configured shutdown hook script associated with that virtual machine. When the shutdown hook script is executed, it cleans up the IP address allocation record corresponding to the virtual machine from the lease file of the Dynamic Host Configuration Protocol server according to the identification information of the virtual machine. After clearing the IP address allocation records, the current virtual machine, which is in a shutdown state, is destroyed using virtualization management commands; After destroying the current virtual machine, restart the Dynamic Host Configuration Protocol service to make the lease file cleanup operation take effect, and decide whether to clone and start a new virtual machine based on the template test virtual machine to continue executing the test tasks, based on the remaining tasks in the software test task list, until multiple software test tasks are completed.

8. A virtual machine processing device for software testing tasks, characterized in that, include: The acquisition module is used to acquire the software test task list and the template test virtual machine created for the software test task list. The first processing module is configured to configure resource packages for at least one software test task for the template test virtual machine according to multiple software test tasks in the software test task list, and to configure IP addresses for the template test virtual machine according to a preset range of IP address pools to obtain multiple virtual machines; and to process dependencies for the multiple software test tasks currently being tested through the multiple virtual machines respectively. After the current virtual machine starts according to the boot startup task, determine the running status of the current virtual machine in which the resource package of at least one software test task handles the dependency of the software test task; based on the running status, destroy the current virtual machine and start the next virtual machine, until multiple software test tasks are completed.

9. A computing device, characterized in that, include: A processor, a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A storage instruction that, when executed on a computer, causes the computer to perform the method as described in any one of claims 1 to 7.

Images