Upgrade package automatic testing method, device and electronic equipment

Abstract

The application discloses an upgrade package automatic testing method and device and electronic equipment, and relates to the technical field of software testing. The method comprises the following steps: obtaining configuration information of a test environment; determining a corresponding upgrade path according to the configuration information; starting multiple concurrent threads according to the number of the test environment; executing an upgrade operation according to the upgrade path of the corresponding test environment by each thread; and automatically testing the upgrade package in the upgrade process. Thus, parallel testing and path self-adaptation of the upgrade package are realized, technical problems of low testing efficiency and resource waste of the manual testing method when facing complex upgrade package testing tasks are solved, and technical effects of reducing manual intervention, shortening the testing period and enhancing testing consistency are achieved.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to automated testing methods, apparatus and electronic equipment for upgrade packages. Background Technology

[0002] Server virtualization technology is a technique that abstracts physical server resources into multiple logical resources through software. Its core lies in achieving efficient utilization and flexible management of hardware resources. With the accelerated iteration of virtualization products, compatibility and stability testing of upgrade packages has become a crucial aspect of ensuring system reliability.

[0003] Current mainstream upgrade package testing methods still rely on manual operation. During the testing process, version information, hardware configuration, and upgrade paths for each test environment must be manually recorded, and the environment must be reinitialized after each upgrade. This method suffers from high repetition, low efficiency, and unreliable test results when faced with increasingly complex upgrade package testing tasks, especially in large-scale concurrent upgrade scenarios, which further exacerbates the difficulty of the testing work. Summary of the Invention

[0004] This application provides an automated testing method, apparatus, and electronic equipment for upgrade packages, in order to at least solve the problems of low testing efficiency and resource waste caused by manual testing methods when faced with complex upgrade package testing tasks.

[0005] This application provides an automated testing method for upgrade packages, including: obtaining configuration information of the test environment; determining the upgrade path of the test environment based on the configuration information; starting a number of concurrent threads equal to the number of test environments, and performing upgrade operations through the concurrent threads; and testing the upgrade package according to the upgrade path of the test environment corresponding to each thread during the execution of the upgrade operation.

[0006] This application also provides an automated testing device for upgrade packages, comprising: an acquisition module for acquiring configuration information of a test environment; a determination module for determining the upgrade path of the test environment based on the configuration information; an upgrade module for starting a number of concurrent threads equal to the number of test environments and performing upgrade operations through the concurrent threads; and a testing module for testing the upgrade package according to the upgrade path of the test environment corresponding to each thread during the execution of the upgrade operation.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described automated testing methods for upgrade packages when executing the computer program.

[0008] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described automated testing methods for upgrade packages.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described automated testing methods for upgrade packages.

[0010] This application obtains the configuration information of the test environment, determines the corresponding upgrade path based on the configuration information, and starts multiple concurrent threads according to the number of test environments. Each thread performs the upgrade operation according to the upgrade path of its corresponding test environment. Simultaneously, automated testing of the upgrade package is performed during the upgrade process, thus achieving parallel testing and path adaptation of the upgrade package. Therefore, it can solve the technical problems of low testing efficiency and resource waste in manual testing methods when facing complex upgrade package testing tasks, achieving the technical effects of reducing manual intervention, shortening the testing cycle, and enhancing test consistency. Attached Figure Description

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

[0012] Figure 1 A hardware structure block diagram of an automated testing method for an upgrade package provided in this application embodiment;

[0013] Figure 2 A flowchart illustrating an automated testing method for an upgrade package provided in this application embodiment;

[0014] Figure 3 This application provides a schematic diagram of an upgrade testing process for a server virtualization product.

[0015] Figure 4 This is a structural diagram of an automated testing device for an upgrade package provided in an embodiment of this application. Detailed Implementation

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

[0017] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0018] First, some nouns or terms that appear in the explanation of the embodiments of this application shall be interpreted as follows:

[0019] VM (Virtual Machine): refers to an independently running instance of an operating system created on a physical server using virtualization technology.

[0020] CI / CD (Continuous Integration / Continuous Delivery) is a software engineering practice aimed at achieving frequent code integration, automated testing, and rapid deployment through automated processes. Continuous Integration (CI) refers to developers frequently merging code changes into a shared backbone and automatically triggering builds and tests to detect integration errors as early as possible. Continuous Delivery (CD), building on this, ensures that tested code can be automatically deployed to production or testing environments at any time, thereby shortening release cycles and improving software quality and delivery efficiency. In this application, a CI / CD pipeline is used to automate packaging, deploying to the testing environment, and triggering upgrade testing processes, achieving efficient and repeatable execution of testing tasks.

[0021] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0022] The specific application environment architecture or specific hardware architecture on which the automated testing method for the upgrade package depends is described here.

[0023] The methods and embodiments provided in this application can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1 This is a hardware structure block diagram of the automated testing method for upgrade packages according to an embodiment of this application. For example... Figure 1 As shown, the server device may include one or more ( Figure 1Only one is shown in the image. A processor 102 (which may include, but is not limited to, a central processing unit (CPU), microprocessor (MCU), or programmable logic device (FPGA), etc.) and a memory 104 for storing data are also shown. The server device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server equipment described above. For example, the server equipment may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0024] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the automated testing method for upgrade packages in this embodiment. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thus implementing the aforementioned method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to server devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0025] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the server device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0026] This application provides an automated testing method for upgrade packages, and the method is described in detail below, along with its execution flow. Figure 2 As shown, the process of this method may include the following steps:

[0027] Step S202: Obtain the configuration information of the test environment.

[0028] Step S204: Determine the upgrade path of the test environment based on the configuration information.

[0029] Step S206: Start a number of concurrent threads equal to the number of test environments, and perform the upgrade operation through the concurrent threads.

[0030] Step S208: During the upgrade operation, the upgrade package is tested according to the upgrade path of the test environment corresponding to each thread.

[0031] In steps S202 to S208 above, the intelligent generation of upgrade paths is driven by configuration information, and the parallel and adaptive upgrade testing of multiple test environments is realized in a one-to-one concurrent thread manner. This significantly improves the testing efficiency and accuracy of server virtualization product upgrade packages, while ensuring that the upgrade behavior in different test environments strictly matches the target version, avoiding the risks of manual intervention and mismatch.

[0032] To better illustrate the automated testing process of the aforementioned upgrade package, the embodiments of this application... Figure 3 A schematic diagram of an optional server virtualization product upgrade testing process is shown, such as... Figure 3 As shown, this automated process mainly involves three key parts: the test environment device, the upgrade path device, and the upgrade device. A detailed functional analysis is as follows:

[0033] Test Environment Device: Primarily used for deploying test environments. Utilizing a CI / CD pipeline approach, it automatically generates software packages and upgrade packages after each round of development for the server virtualization product. These software packages can be deployed to test environments for different hardware CPU architectures (e.g., x86, AMD), product types, and product customization requirements. After deployment, the device accesses the test environment's connectivity, creates a snapshot, and acquires its configuration information, including but not limited to hardware architecture identifiers, product type identifiers, product customization identifiers, and the initial test environment version. This information is then fed back to the upgrade path device.

[0034] Upgrade path device: It is mainly responsible for receiving the configuration information of the test environment device, determining the corresponding upgrade package based on the initial version of the test environment and the expected target version to be upgraded, querying whether each upgrade package contains patch package files, calculating all available upgrade paths, and feeding them back to the upgrade device.

[0035] Upgrade device: Primarily responsible for launching multiple concurrent threads equal to the number of test environments based on available upgrade paths reported by the upgrade path device, enabling concurrent upgrades. This includes uploading and applying upgrade package / patch files corresponding to different hardware architecture identifiers, product type identifiers, and product customization identifiers to the test environment, then determining the upgrade progress. If the upgrade is complete, it performs upgrade verification; if the upgrade is incomplete, it continues to upload and apply upgrade package / patch files. Once the upgrade path is complete, it notifies the test environment device to restore the snapshot and continues executing the upgrade path until all available upgrade paths are completed.

[0036] In one exemplary embodiment, before obtaining the configuration information of the test environment, the method further includes: generating a software package for the server virtualization product based on a software delivery pipeline approach, wherein the software delivery pipeline approach is an end-to-end automated process orchestrated and continuously driven based on preset rules; and deploying the corresponding test environment according to the software package.

[0037] Automating the generation of server virtualization product software packages through a software delivery pipeline is a key prerequisite for achieving a closed-loop automated testing system.

[0038] In this embodiment, a CI / CD pipeline approach can be used to automatically output corresponding versions of software packages based on different hardware architectures (such as x86, ARM), product models (standard version, enterprise enhanced version), and customer-customized parameters, thereby ensuring that each software package is precisely matched with its target deployment environment. This mechanism fundamentally solves the problem of test environment failure caused by version confusion and architecture mismatch in traditional manual packaging. Furthermore, based on the generated software packages, the deployment engine is automatically invoked to deploy the corresponding test environment on the target physical or virtual server. This deployment process can automatically adapt to the target machine's hardware resources and network environment without manual intervention.

[0039] Optionally, generating a software package for a server virtualization product based on a software delivery pipeline includes: obtaining the source code files and configuration parameters of the server virtualization product; and generating a software package containing identification information based on the source code files and configuration parameters, wherein the identification information includes at least one of the following: a hardware architecture identifier, a product type identifier, and a product customization identifier, wherein the hardware architecture identifier is used to indicate the CPU architecture adapted to the server virtualization product, the product type identifier is used to indicate the standardized classification version of the server virtualization product, and the product customization identifier is used to indicate the customer's customization requirements.

[0040] In this embodiment, the generation of the software package incorporates the heterogeneous requirements of server virtualization products in actual deployment and achieves multi-dimensional differentiated construction through a CI / CD pipeline approach. Specifically, it first requires obtaining the source code files and build configuration parameters of the server virtualization product. The source code files typically contain the core components of the virtualization platform, while the configuration parameters explicitly specify the differentiated conditions for the deployment scenario, including but not limited to hardware CPU architecture (such as x86, ARM), product category version (such as standard version, enterprise enhanced version), and customer customization requirements (such as specific security policies, driver modules, compliance certification support, etc.). By injecting these parameters as the build context into the pipeline and embedding corresponding preprocessing instructions and loading adaptation drivers during the compilation stage, a software package with unique identification information (i.e., hardware architecture identifier, product type identifier, and product customization identifier) ​​can be generated.

[0041] It's important to note that this identification information isn't merely appended to metadata; it directly participates in the intelligent matching and upgrade path deduction of the subsequent testing environment. For example, the hardware architecture identifier ensures that x86 architecture software packages are not incorrectly deployed to ARM servers, avoiding startup failures caused by instruction set incompatibility; the product type identifier enables the system to distinguish between basic and enhanced feature versions, thus selecting the correct feature evolution path during upgrade path calculation; and the product customization identifier is used to identify customer-specific patches or extension modules, ensuring that customized features are not overwritten or omitted during the upgrade process. This refined construction mechanism based on identifiers effectively overcomes the problems of mismatched upgrade packages and invalid tests caused by missing architecture and customization information in traditional testing methods.

[0042] In one exemplary embodiment, after deploying the corresponding test environment according to the software package, the method further includes: verifying the network connectivity of the test environment through a preset network probing protocol and obtaining a verification result; if the verification result indicates that the network connectivity verification is successful, performing automated testing of the upgrade package of the test environment; if the verification result indicates that the network connectivity verification fails, terminating the automated testing of the upgrade package of the test environment and outputting an exception log.

[0043] In this embodiment, the preset network probing protocols include, but are not limited to, ICMP Ping, TCP port probing, HTTP health checks, or custom virtualization management interface connectivity tests. The purpose is to confirm whether the target test environment has been successfully started, whether services are listening normally, and whether the management channel is reachable. Only after network connectivity verification is passed will operations such as uploading the upgrade package and verifying the application and version continue. If the detection fails, the current testing process is immediately terminated, and corresponding exception logs are output, providing traceable diagnostic information for operations and maintenance personnel and avoiding upgrade package timeouts, resource waste, or incorrect upgrade failures due to unreachable environments.

[0044] In an exemplary embodiment, after verifying the network connectivity of the test environment through a preset network detection protocol, the method further includes: creating a system snapshot of the test environment, wherein the system snapshot is used to record the running state of the test environment in the initial version; and, upon receiving an upgrade completion signal, restoring the test environment to the initial version based on the system snapshot.

[0045] Specifically, the system snapshot records the complete running state of the test environment in its initial version, including but not limited to the operating system kernel, virtualization platform version, installed drivers, network configuration, service status, storage volume snapshots, and the original content of key configuration files. This system snapshot is not a simple file backup, but rather an initial state capture based on virtualization technology. It ensures that each upgrade test starts from a completely consistent starting point, effectively solving the environment drift problem in traditional testing—that is, residual configurations, caches, or temporary files from the previous test affecting the accuracy of subsequent test results.

[0046] Furthermore, upon receiving an upgrade completion signal (such as the upgrade script returning a success code, the target version number being verified, or a critical service restarting successfully), the snapshot rollback process will be triggered immediately to restore the test environment to its initial version state. This enables the test environment to be reset instantly without the need for manual system reinstallation, software redeployment, or manual cleanup of intermediate states, significantly shortening the test environment's cycle time.

[0047] In scenarios supporting concurrent testing across multiple paths and versions, this snapshot mechanism is particularly important: multiple concurrent threads can execute different upgrade paths on different environments simultaneously, and each thread can roll back independently after completing its dedicated upgrade path without interfering with others, thus achieving true parallel and pipelined testing. Furthermore, the retention of system snapshots provides crucial evidence for fault backtracking. If an upgrade causes a system crash, the difference between the snapshot and the abnormal state can be compared to accurately pinpoint the point of failure, providing a solid guarantee for the quality assessment of server virtualization product upgrade packages.

[0048] In one exemplary embodiment, obtaining configuration information of the test environment includes: obtaining the hardware architecture identifier, product type identifier, and product customization identifier of the test environment; determining the initial version of the test environment; and determining the configuration information of the test environment based on the hardware architecture identifier, product type identifier, product customization identifier, and initial version.

[0049] Specifically, the configuration information of the test environment mainly includes the following four key dimensions: hardware architecture identifier, product type identifier, product customization identifier, and the initial version of the test environment. Among these, the hardware architecture identifier (e.g., x86_64, ARM64) determines the instruction set and underlying driver compatibility of the upgrade package; the product type identifier (e.g., standard version, enterprise enhanced version) defines the boundaries of the function set supported by the test environment, such as whether it includes an encryption module; the product customization identifier (e.g., customer A_security enhancement_V2) marks non-standard function customizations proposed by specific customers or industry scenarios; and the initial version information (e.g., v3.1.0) serves as the starting point for the version and is the benchmark for calculating available upgrade paths.

[0050] This configuration information modeling based on multi-dimensional identifiers solves the risks of accidental upgrades, missing features, or compatibility crashes caused by a single upgrade package adapting to all environments in traditional testing methods. It allows each testing environment to obtain a dedicated upgrade path plan. Simultaneously, this mechanism supports the scalability of version evolution. When a new customized requirement or hardware architecture is added, simply adding an identifier to the configuration system and updating the version dependency rules allows for seamless integration into the automated testing process without refactoring the entire system.

[0051] In one exemplary embodiment, determining the upgrade path of the test environment based on configuration information includes: determining the upgrade package corresponding to the test environment based on the configuration information; and determining the upgrade path of the test environment based on the upgrade package.

[0052] By acquiring the configuration information of the test environment and accurately identifying the matching upgrade package based on this information, the system constructs the corresponding upgrade path according to the version characteristics, architecture identifier, or patch content of the upgrade package. This ensures that the upgrade path of each test environment is directly driven by its own dedicated upgrade package rather than relying on fuzzy rules for inference. Subsequently, an independent concurrent thread is started for each test environment. Each thread strictly follows its corresponding upgrade path when performing upgrade operations, ensuring that test environments with different CPU architectures or customized configurations can automatically adapt to the differentiated upgrade process. This achieves high-precision matching of upgrade paths and effectively solves the problems of test failure, concurrency conflicts, and unreliable results caused by the lack of clear basis for determining upgrade paths in traditional testing methods.

[0053] Optionally, the upgrade package corresponding to the test environment is determined based on the configuration information, including: obtaining the initial version, hardware architecture identifier, product type identifier, and customization identifier of the test environment from the configuration information; determining the target version of the test environment, wherein the target version represents the expected version after upgrading the test environment; determining the upgrade chain of the test environment based on the initial version and the target version, wherein the upgrade chain consists of multiple consecutive upgrade packages used to gradually upgrade the test environment from the initial version to the target version; and filtering each upgrade package in the upgrade chain based on the hardware architecture identifier, product type identifier, and customization identifier to obtain an upgrade package adapted to the test environment.

[0054] In this embodiment, the upgrade package selection mechanism adopts a hierarchical, progressive logic of first defining the path and then adapting constraints to improve the systematicness and accuracy of upgrade path planning. First, the initial version of the test environment is extracted from the configuration information as the starting point for the upgrade. Then, the target version is dynamically determined based on a preset version upgrade strategy or user requirements; this target version represents the final state that this test aims to achieve. Based on the initial and target versions, a version dependency graph is invoked to automatically derive one or more upgrade chains, which are ordered sequences of intermediate versions that must be traversed from the initial version to the target version. It should be noted that this upgrade chain not only includes the upgrade nodes of the main version but also implicitly includes all necessary patch packages, hotfix packages, or feature enhancement packages.

[0055] After obtaining the upgrade chain, the hardware architecture identifier, product type identifier, and customization identifier of the test environment are introduced as filters to perform secondary verification on each upgrade package in the upgrade chain. For example, although the third package (v3.4.0) in an upgrade chain is a legitimate intermediate version, if it only supports the x86 architecture while the current test environment is ARM64, the package will be automatically removed, and the system will search for an ARM-compatible alternative version or patch. Similarly, if an upgrade package contains high-availability cluster functionality, but the product type identifier of the test environment is the standard version, the package will be excluded due to functional overreach. For environments with industry-specific customization identifiers, the system will ensure that each package in the upgrade chain contains the corresponding compliance patch or security hardening module; otherwise, the path will be considered invalid. This package-by-package filtering mechanism based on multi-dimensional identifiers ensures that the final generated upgrade path is not only logically valid in terms of version but also compatible with the environment, eliminating the risk of a version being upgradable but the environment being incompatible.

[0056] Optionally, determining the upgrade path of the test environment based on the upgrade package includes: querying the patch package corresponding to the upgrade package to obtain the query results, wherein the patch package only contains incremental fixes corresponding to the version upgrade; if the query results indicate that there is no corresponding patch package for the upgrade package, determining the upgrade path of the test environment based on the upgrade package; if the query results indicate that there is a corresponding patch package for the upgrade package, determining the upgrade path of the test environment based on the upgrade package and the corresponding patch package.

[0057] In the iterative process of server virtualization products, version upgrades are typically released in two forms: one is a complete major version upgrade package, containing all features and dependencies; the other is a lightweight patch package, which only encapsulates incremental fixes for specific defects, security vulnerabilities, or platform compatibility issues. In this embodiment, by querying whether each candidate upgrade package is associated with a patch package, it is determined whether the upgrade step has the potential for an incomplete upgrade, thereby determining the structure of the upgrade path. This enables the system to intelligently identify and integrate incremental fixes, thus achieving more refined and reliable upgrade path planning.

[0058] Specifically, when a query result shows that an upgrade package has no corresponding patch package, it can be directly included in the path as an independent upgrade node without additional intervention. When the query result shows that the upgrade package has one or more patch packages, it is no longer treated as a single action, but rather a composite upgrade unit consisting of the main upgrade package and the patch packages is constructed. For example, when upgrading from v3.1.0 to v3.3.0, if the v3.3.0 main package has two critical security patches (Patch-3.3.0-Security-01 and Patch-3.3.0-Fix-02), the system will generate a path: first deploy the v3.3.0 main package, and then apply the two patch packages in sequence, ensuring that the repair logic is executed in the order of dependencies. Ignoring the order and existence of patch packages and skipping or applying them out of order may lead to functional abnormalities, service crashes, or security policy failures, resulting in a superficially successful upgrade but a vulnerable system. By proactively identifying and integrating patch packages, the system can automatically construct a complete execution flow containing the "main package-patch sequence," ensuring that every upgrade conforms to standard upgrade specifications.

[0059] In an exemplary embodiment, before starting a number of concurrent threads equal to the number of test threads, the method further includes: determining the execution priority of the test environment; judging the availability status of system resources to obtain a first judgment result; maintaining the concurrent threads if the first judgment result indicates that the system resources meet the running requirements of the concurrent threads; and reducing the number of concurrent threads according to the priority of the test environment if the first judgment result indicates that the system resources do not meet the running requirements of the concurrent threads.

[0060] In this embodiment, the execution priority of the test environment integrates multiple business dimensions, including but not limited to the urgency of the test target, the level of customization, the criticality of the version, and the historical failure rate.

[0061] By acquiring the configuration information of the test environment and determining the upgrade path for each test environment accordingly, and further combining the execution priority of the test environment with the real-time availability of system resources for dynamic evaluation, when system resources are sufficient to support the running of concurrent threads equal to the number of test environments, full concurrent execution is maintained to maximize test efficiency; when system resources are insufficient, the number of concurrent threads is intelligently reduced according to the preset execution priority, prioritizing the execution of upgrade tasks for high-priority test environments and postponing the start of low-priority tasks. This avoids system instability or test failure caused by thread overload under resource-constrained conditions, ensuring that the upgrade test process is always carried out continuously within a controllable and orderly range.

[0062] In one exemplary embodiment, a number of concurrent threads equal to the number of test environments are started, and an upgrade operation is performed through the concurrent threads, including: obtaining target configuration information and target upgrade path of the target test environment, wherein the target test environment is the test environment corresponding to the target thread, and the target thread is any one of the concurrent threads; obtaining the target upgrade package and target patch package corresponding to the target test environment from the upgrade package database according to the target configuration information and target upgrade path; and performing an upgrade operation on the target test environment in the target thread according to the target upgrade package and target patch package.

[0063] In this embodiment, each target thread independently obtains the target configuration information and target upgrade path of its corresponding target test environment during execution. Based on the matching configuration information and upgrade path, it retrieves and downloads the exclusive upgrade package and patch package that are compatible with it from the upgrade package database. Then, in the isolated execution environment of the target thread, it performs the upgrade operation on the target test environment according to the obtained target upgrade package and target patch package, ensuring that each test environment uses upgrade resources that are fully matched with its CPU architecture, system version and customization requirements.

[0064] It should be noted that the upgrade operation within the thread strictly follows the execution sequence defined by the target upgrade path, which is a directed graph path composed of version dependencies, patch constraints, compatibility rules, etc. For example, upgrading from v2.8 to v3.5 must go through two intermediate versions, v3.0 and v3.3, and v3.3 must be patched first.

[0065] Furthermore, different threads can handle completely different combinations of architectures, versions, and configurations simultaneously. The system does not need to write independent scripts for each environment type; instead, it achieves a single engine and multiple paths through dynamic binding of configurations and paths. At the same time, because each thread independently manages the download, application, and verification process of its upgrade package, resource isolation is excellent. Even if one thread fails due to network interruption or patch anomaly, it will not affect the normal execution of other threads, greatly improving the fault tolerance and stability of the overall testing system.

[0066] In one exemplary embodiment, the method further includes: determining the upgrade progress in the target thread to obtain a second determination result; if the second determination result indicates that the target test environment upgrade is complete, performing version verification on the target test environment; if the second determination result indicates that the target test environment upgrade is incomplete, continuing to retrieve upgrade packages and patch packages corresponding to the un-upgraded paths in the target upgrade path from the upgrade package database and performing upgrade operations on the target test environment.

[0067] By launching an equal number of concurrent threads as the test environment to execute the upgrade operation in parallel, and simultaneously monitoring the upgrade progress of each target thread in real time, the upgrade is immediately triggered when the result indicates that the upgrade is complete. This triggers a version verification process for the target test environment, using pre-defined verification scripts to check key indicators such as functional integrity, service availability, security policy compliance, and log anomalies, ensuring the accuracy and completeness of the upgrade results. If the result indicates that the upgrade is not yet complete, the system automatically and dynamically retrieves the subsequent upgrade packages and patch packages corresponding to the unexecuted sub-paths in the target upgrade path of the test environment from the upgrade package database, and continues to drive the thread to complete the remaining upgrade steps. This achieves intelligent tracking and automatic continuation of multi-path, multi-stage upgrade processes, thus avoiding test failures due to incomplete upgrade paths or missing intermediate packages without interrupting the concurrent testing process, improving the automation level and robustness of the testing process.

[0068] This mechanism is particularly suitable for upgrade scenarios with long paths, multiple patches, and complex dependencies. In traditional environment testing methods, failure in the middle may cause the entire test chain to be interrupted. However, the embodiments of this application treat each test environment as an independent proxy component with self-repair capabilities. It can automatically recover, resume, and retry until the path is completed, providing irreplaceable protection for version security release in critical business scenarios.

[0069] It should be noted that the intelligent matching mechanism and concurrent upgrade method proposed in this application have strong versatility and portability. Their core value extends beyond general-purpose server virtualization platforms; they are deeply adaptable to multiple critical industry sectors with stringent stability, security, and compliance requirements, such as enterprise-level private cloud desktop systems, financial IT systems, and industrial control systems. Their architecture eliminates dependence on a single platform, seamlessly adapting to any virtualization system with heterogeneous environments, customized needs, and high reliability requirements. This provides a scalable and securely deployable general solution for the automated operation and maintenance of critical infrastructure, possessing broad industrial scalability and strategic value.

[0070] The automated upgrade package testing method of this application can significantly improve the effect of personalized upgrade testing and reduce manual intervention by using a server CPU architecture-based and customized upgrade package path matching mechanism, a thread concurrency method based on the number of test environments, and an automated upgrade package application and environment initialization optimization method. This solves the problems of low efficiency and insufficient adaptability in the current testing process.

[0071] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0072] Embodiments of this application also provide an automated testing apparatus for upgrade packages, which can be used to implement the automated testing method for upgrade packages provided in the above embodiments. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0073] Figure 4 This is a structural block diagram of an automated testing device for an upgrade package according to an embodiment of this application, such as... Figure 4 As shown, the automated testing apparatus for the upgrade package includes:

[0074] Module 40 is used to obtain configuration information of the test environment;

[0075] Module 42 is used to determine the upgrade path of the test environment based on the configuration information;

[0076] Upgrade module 44 is used to start a number of concurrent threads equal to the number in the test environment, and to perform upgrade operations through the concurrent threads;

[0077] Test module 46 is used to test the upgrade package according to the upgrade path of the test environment corresponding to each thread during the upgrade operation.

[0078] The aforementioned device acquires the configuration information of the test environment, determines the corresponding upgrade path based on the configuration information, and starts multiple concurrent threads according to the number of test environments. Each thread executes the upgrade operation according to the upgrade path of its corresponding test environment. Simultaneously, automated testing of the upgrade package is performed during the upgrade process, thus achieving parallel testing and path adaptation of the upgrade package. Therefore, it can solve the technical problems of low testing efficiency and resource waste in manual testing methods when facing complex upgrade package testing tasks, achieving the technical effects of reducing manual intervention, shortening the testing cycle, and enhancing test consistency.

[0079] In one exemplary embodiment, the acquisition module 40 is used to acquire the hardware architecture identifier, product type identifier, and product customization identifier of the test environment; determine the initial version of the test environment; and determine the configuration information of the test environment based on the hardware architecture identifier, product type identifier, product customization identifier, and initial version.

[0080] In an exemplary embodiment, the determining module 42 is used to determine the upgrade package corresponding to the test environment based on the configuration information; and to determine the upgrade path of the test environment based on the upgrade package.

[0081] In an exemplary embodiment, the determining module 42 is configured to obtain the initial version, hardware architecture identifier, product type identifier, and customization identifier of the test environment from the configuration information; determine the target version of the test environment, wherein the target version represents the expected version after upgrading the test environment; determine the upgrade chain of the test environment based on the initial version and the target version, wherein the upgrade chain consists of multiple consecutive upgrade packages, used to gradually upgrade the test environment from the initial version to the target version; and filter each upgrade package in the upgrade chain based on the hardware architecture identifier, product type identifier, and customization identifier to obtain an upgrade package that is compatible with the test environment.

[0082] In one exemplary embodiment, the determining module 42 is used to query the patch package corresponding to the upgrade package and obtain the query result, wherein the patch package only contains incremental fix content corresponding to the version upgrade; if the query result indicates that there is no corresponding patch package for the upgrade package, the upgrade path of the test environment is determined based on the upgrade package; if the query result indicates that there is a corresponding patch package for the upgrade package, the upgrade path of the test environment is determined based on the upgrade package and the corresponding patch package.

[0083] In an exemplary embodiment, the upgrade module 44 is configured to determine the execution priority of the test environment; determine the availability status of system resources to obtain a first determination result; maintain concurrent threads if the first determination result indicates that the system resources meet the running requirements of concurrent threads; and reduce the number of concurrent threads according to the priority of the test environment if the first determination result indicates that the system resources do not meet the running requirements of concurrent threads.

[0084] In an exemplary embodiment, the upgrade module 44 is used to obtain the target configuration information and target upgrade path of the target test environment, wherein the target test environment is the test environment corresponding to the target thread, and the target thread is any thread among the concurrent threads; to obtain the target upgrade package and target patch package corresponding to the target test environment from the upgrade package database according to the target configuration information and target upgrade path; and to perform an upgrade operation on the target test environment in the target thread according to the target upgrade package and target patch package.

[0085] In one exemplary embodiment, the upgrade module 44 is used to determine the upgrade progress in the target thread and obtain a second determination result; if the second determination result indicates that the target test environment upgrade is complete, the module performs version verification on the target test environment; if the second determination result indicates that the target test environment upgrade is incomplete, the module continues to retrieve the upgrade package and patch package corresponding to the un-upgraded path in the target upgrade path from the upgrade package database and perform the upgrade operation on the target test environment.

[0086] In one exemplary embodiment, the apparatus further includes a deployment module 48 for generating software packages for server virtualization products based on a software delivery pipeline approach, wherein the software delivery pipeline approach is an end-to-end automated process orchestrated and continuously driven based on preset rules; and deploying a corresponding test environment according to the software packages.

[0087] In an exemplary embodiment, the deployment module 48 is used to obtain the source code files and configuration parameters of the server virtualization product; based on the software delivery pipeline approach, it generates a software package containing identification information according to the source code files and configuration parameters, wherein the identification information includes at least one of the following: hardware architecture identifier, product type identifier, and product customization identifier, wherein the hardware architecture identifier is used to indicate the CPU architecture adapted to the server virtualization product, the product type identifier is used to indicate the standardized classification version of the server virtualization product, and the product customization identifier is used to indicate the customer's customization requirements.

[0088] In an exemplary embodiment, the deployment module 48 is configured to verify the network connectivity of the test environment through a preset network probing protocol and obtain a verification result; if the verification result indicates that the network connectivity verification is successful, to execute an automated test of the upgrade package for the test environment; if the verification result indicates that the network connectivity verification fails, to terminate the automated test of the upgrade package for the test environment and output an exception log.

[0089] In an exemplary embodiment, the deployment module 48 is configured to create a system snapshot of the test environment, wherein the system snapshot is used to record the running state of the test environment in the initial version; and upon receiving an upgrade completion signal, to restore the test environment to the initial version based on the system snapshot.

[0090] It should be noted that the description of the features in the embodiment corresponding to the automated testing device for upgrade packages can be found in the relevant description of the embodiment corresponding to the automated testing method for upgrade packages, and will not be repeated here.

[0091] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above embodiments of the automated testing method for upgrade packages.

[0092] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the automated testing method for upgrade packages at runtime.

[0093] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0094] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the automated testing method for upgrade packages.

[0095] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above embodiments of the automated testing method for upgrade packages.

[0096] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0097] Those skilled in the art will further 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, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. 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 implementation should not be considered beyond the scope of this application.

[0098] The above provides a detailed description of the automated testing method, apparatus, and electronic device for upgrade packages provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. An automated testing method for upgrade packages, characterized in that, include: Obtain the configuration information of the test environment; The upgrade path for the test environment is determined based on the configuration information. Start a number of concurrent threads equal to the number in the test environment, and perform the upgrade operation through the concurrent threads; as well as During the upgrade process, the upgrade package is tested according to the upgrade path of the test environment corresponding to each thread.

2. The automated testing method for upgrade packages according to claim 1, characterized in that, Before obtaining the configuration information of the test environment, the method further includes: The software package for generating server virtualization products is generated based on a software delivery pipeline approach, wherein the software delivery pipeline approach is an end-to-end automated process orchestrated and continuously driven based on preset rules. Deploy the corresponding test environment based on the software package.

3. The automated testing method for upgrade packages according to claim 2, characterized in that, Software packages for generating server virtualization products based on a software delivery pipeline approach include: Obtain the source code files and configuration parameters of the server virtualization product; Based on the software delivery pipeline method, a software package containing identification information is generated according to the source code file and the configuration parameters. The identification information includes at least one of the following: hardware architecture identifier, product type identifier, and product customization identifier. The hardware architecture identifier is used to indicate the CPU architecture adapted to the server virtualization product. The product type identifier is used to indicate the standardized classification version of the server virtualization product. The product customization identifier is used to indicate the customer's customization requirements.

4. The automated testing method for upgrade packages according to claim 2, characterized in that, After deploying the corresponding test environment based on the software package, the method further includes: The network connectivity of the test environment is verified by using a preset network detection protocol, and the verification results are obtained. If the verification result indicates that the network connectivity verification is successful, perform automated testing of the upgrade package for the test environment; If the verification result indicates that the network connectivity verification has failed, terminate the automated testing of the upgrade package in the test environment and output an exception log.

5. The automated testing method for upgrade packages according to claim 4, characterized in that, After verifying the network connectivity of the test environment using a preset network probing protocol, the method further includes: Create a system snapshot of the test environment, wherein the system snapshot is used to record the running state of the test environment in the initial version; and Upon receiving the upgrade completion signal, the test environment is restored to the initial version based on the system snapshot.

6. The automated testing method for upgrade packages according to claim 1, characterized in that, Obtain the configuration information of the test environment, including: Obtain the hardware architecture identifier, product type identifier, and product customization identifier of the test environment; Determine the initial version of the test environment; The configuration information of the test environment is determined based on the hardware architecture identifier, the product type identifier, the product customization identifier, and the initial version.

7. The automated testing method for upgrade packages according to claim 1, characterized in that, Determining the upgrade path of the test environment based on the configuration information includes: Based on the configuration information, determine the upgrade package corresponding to the test environment; The upgrade path for the test environment is determined based on the upgrade package.

8. The automated testing method for upgrade packages according to claim 7, characterized in that, Based on the configuration information, the upgrade package corresponding to the test environment is determined, including: Obtain the initial version, hardware architecture identifier, product type identifier, and customization identifier of the test environment from the configuration information; Determine the target version of the test environment, wherein the target version represents the expected version after upgrading the test environment; Based on the initial version and the target version, an upgrade chain for the test environment is determined, wherein the upgrade chain consists of multiple consecutive upgrade packages, used to gradually upgrade the test environment from the initial version to the target version; Based on the hardware architecture identifier, the product type identifier, and the customization identifier, each upgrade package in the upgrade chain is filtered to obtain an upgrade package that is compatible with the test environment.

9. The automated testing method for upgrade packages according to claim 7, characterized in that, Determining the upgrade path for the test environment based on the upgrade package includes: Query the patch package corresponding to the upgrade package to obtain the query results. The patch package only contains incremental fixes corresponding to the version upgrade. If the query result indicates that the upgrade package does not have a corresponding patch package, the upgrade path of the test environment is determined based on the upgrade package; If the query result indicates that a corresponding patch package exists for the upgrade package, the upgrade path for the test environment is determined based on the upgrade package and the corresponding patch package.

10. The automated testing method for upgrade packages according to claim 1, characterized in that, Before starting a number of concurrent threads equal to the number in the test environment, the method further includes: Determine the execution priority of the test environment; Determine the availability status of system resources and obtain the first determination result; If the first determination result indicates that the system resources meet the running requirements of the concurrent thread, the concurrent thread shall be maintained; If the first judgment result indicates that the system resources do not meet the running requirements of the concurrent threads, the number of concurrent threads is reduced according to the priority of the test environment.

11. The automated testing method for upgrade packages according to claim 1, characterized in that, Start a number of concurrent threads equal to the number in the test environment, and perform the upgrade operation through the concurrent threads, including: Obtain the target configuration information and target upgrade path of the target test environment, wherein the target test environment is the test environment corresponding to the target thread, and the target thread is any one of the concurrent threads; Based on the target configuration information and the target upgrade path, retrieve the target upgrade package and target patch package corresponding to the target test environment from the upgrade package database; In the target thread, an upgrade operation is performed on the target test environment based on the target upgrade package and the target patch package.

12. The automated testing method for upgrade packages according to claim 11, characterized in that, The method further includes: Determine the upgrade progress in the target thread to obtain a second determination result; If the second judgment result indicates that the target test environment has been upgraded, the target test environment is verified for version. If the second judgment result indicates that the target test environment upgrade is incomplete, the upgrade package and patch package corresponding to the unupgraded path in the target upgrade path are retrieved from the upgrade package database to perform the upgrade operation on the target test environment.

13. An automated testing device for upgrade packages, characterized in that, include: The acquisition module is used to obtain the configuration information of the test environment; The determination module is used to determine the upgrade path of the test environment based on the configuration information; The upgrade module is used to start a number of concurrent threads equal to the number of threads in the test environment, and to perform the upgrade operation through the concurrent threads; The testing module is used to test the upgrade package during the upgrade process, based on the upgrade path of the test environment corresponding to each thread.

14. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the automated testing method for the upgrade package as described in any one of claims 1 to 12 when executing the computer program.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the automated testing method for the upgrade package as described in any one of claims 1 to 12.

Images