Software Package Version Upgrade Result Testing Method and Device

Abstract

The present invention relates to the technical field of software testing, and discloses a method and a device for testing the result of software package version upgrade. The method discloses that when the upgraded software package is successfully installed in a pre-constructed virtual test environment, the associated packages of the source code package of the upgraded software package are obtained, and the associated packages are installed or compiled and verified based on the virtual test environment to obtain a first result report; wherein, the associated packages at least include binary packages having installation dependencies on the sub-packages generated by the source code package of the upgraded software package and source code packages having compilation dependencies on the sub-packages generated by the source code package of the upgraded software package; the upgraded software package of the previous version of the upgraded software package is obtained, and the differences between the current version of the upgraded software package and the previous version of the upgraded software package are obtained by using a compatibility check tool to obtain a difference report; an interface list with binary interface changes is determined according to the difference report, and a second result report is determined according to the relationship between the interfaces called by the associated packages and the interface list. The present invention has good migration performance.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and particularly to a method and device for testing the results of software package version upgrades. Background Art

[0002] With the increasingly serious network security situation, the demand for network security by enterprises and individuals has increased, promoting the vigorous development of the information and communication technology (ICT) innovation industry and the gradual rise of domestic operating systems.

[0003] Domestic independent operating systems are basically built based on the open-source Linux operating system, including server-oriented systems and client-oriented systems. These operating systems are constructed from thousands of open-source software modules from the core to the application layer. These modules are intertwined, and compilation or installation is mutually dependent. This structure leads to a problem that once a certain part changes, it may have a significant impact on the entire system. For example, the repair of a CVE vulnerability or the update and upgrade of a function of a software may affect the normal operation of other software packages that depend on it, and even cause the abnormal operation of the entire system, which brings quite a challenge to the software upgrade process.

[0004] Based on this, some research uses the method of dependency identification for software packages to assist in upgrades, in order to predict in advance the possible impacts brought by software package changes. However, due to the complex and changeable software compilation environment in the operating system, although a software package identifies its compilation dependencies and installation dependencies in the configuration file, these dependency relationships originate from the open-source community and may be different from the environment actually provided by the system. If the environment provided by the system is more extensive, resulting in inconsistent actual compilation parameters of the open-source software with the parameters specified in the configuration file, in this case, even for the same software package on the same system, different compilers may encounter different results: one person may be able to compile smoothly, while another person may encounter compilation failure problems.

[0005] In summary, the related technologies have the problem of poor migration. Summary of the Invention

[0006] In view of this, the present invention provides a method, device, equipment, storage medium and program product for testing the results of software package version upgrades to solve the problem of poor migration.

[0007] In a first aspect, the present invention provides a method for testing the results of software package version upgrades, the method comprising:

[0008] When the upgrade software package is successfully installed in the pre-built virtual test environment, obtain the associated packages of the source code package of the upgrade software package, and perform installation or compilation verification on the associated packages based on the virtual test environment to obtain the first result report; wherein, the associated packages at least include binary packages having installation dependencies with the sub-packages generated by the source code package of the upgrade software package and source code packages having compilation dependencies with the sub-packages generated by the source code package of the upgrade software package;

[0009] Obtain the previous version of the upgrade software package, and use a compatibility check tool to obtain the differences between the current version of the upgrade software package and the previous version of the upgrade software package to obtain a difference report;

[0010] Determine the list of interfaces with binary interface changes according to the difference report, and determine the second result report according to the relationship between the interfaces called by the associated packages and the interface list.

[0011] Perform tests in the pre-built virtual test environment to eliminate execution differences caused by the system environment; respectively perform result judgments on the associated packages having dependencies with the upgrade software package according to the corresponding logic to obtain the first result report, and determine the identification results generated by the upgrade software package on other software packages; compare the upgraded software package with the previous version to obtain a difference report, and determine the compatibility of the upgrade software package; determine the list of binary interface changes according to the difference report, and further perform result judgments according to the list of binary interface changes to obtain the second result report, and determine the non-identification results generated by the upgrade software package on other software packages. The present invention detects the results of the upgrade software package on other software packages from multiple aspects in the pre-built virtual test environment, and has good migratability.

[0012] In an alternative embodiment, determining the list of interfaces with binary interface changes according to the difference report, and determining the second result report according to the relationship between the interfaces called by the associated packages and the interface list specifically includes:

[0013] Obtain the list of interfaces with binary interface changes from the difference report;

[0014] Extract binary packages from the associated packages to obtain a list of binary packages;

[0015] Download and decompress the binary packages in the list of binary packages through the current tool repository for package management;

[0016] Query the changed dynamic libraries referenced by the binary packages;

[0017] Query the interfaces called by the changed dynamic libraries;

[0018] If the interfaces called by the changed dynamic libraries are included in the interface list, generate the second result report according to the binary packages corresponding to the changed dynamic libraries.

[0019] Determine a list of binary interface changes based on the difference report, determine the packages in the current system that call the changed binary interfaces, and then determine their affected situations, so as to efficiently and quickly detect the non-identical results of package upgrades.

[0020] In an alternative implementation, obtain the associated packages of the source code package of the upgraded package, and perform installation or compilation verification on the associated packages based on the virtual test environment to obtain the first result report, specifically including:

[0021] Use a preset package dependency tool to obtain, from the tool repository for package management in the virtual test environment, the packages that have installation dependencies and / or compilation dependencies on the sub-packages generated by the source code package of the upgraded package, to obtain at least one associated package;

[0022] Extract the binary packages from the associated packages to obtain a binary package list;

[0023] When the binary packages in the binary package list are installed normally and the sub-packages of the upgraded source code package are not downgraded for installation, extract all the source code packages from the associated packages to obtain a source code package list;

[0024] Use a preset source code maintenance tool for packages to obtain the target source code corresponding to the source code package list in the tool repository for package management;

[0025] Based on the virtual test environment, compile the target source code. If all compilations are normal, output the installation and compilation success information as the first result report.

[0026] Use multiple tools to detect the results of the packages that depend on the upgraded package for installation and the packages that depend on the upgraded package for compilation respectively, which fundamentally verifies the compatibility of the upgraded package source code and the running impact on the packages that depend on this package for installation.

[0027] In an alternative implementation, install the upgraded package in a pre-constructed virtual test environment, specifically including:

[0028] Obtain the source code package of the upgraded package, and build a virtual test environment for the source code package based on a pre-selected automated verification tool;

[0029] In the virtual test environment, install the upgraded package.

[0030] In an alternative implementation, install the upgraded package in the virtual test environment, specifically including:

[0031] Based on the virtual test environment, compile the source code package to obtain the binary package to be installed;

[0032] Install the binary package to be installed.

[0033] Test under the constructed virtual test environment to isolate the verification environment and eliminate the execution differences caused by the system environment.

[0034] In an alternative embodiment, the method further includes:

[0035] If the installation or compilation fails, output a third result report; wherein, the third result report includes error messages.

[0036] In a second aspect, the present invention provides a software package version upgrade result testing device, the device includes:

[0037] A first test module, configured to, when the upgrade software package is successfully installed in a pre-constructed virtual test environment, obtain the associated packages of the source code package of the upgrade software package, and perform installation or compilation verification on the associated packages based on the virtual test environment to obtain a first result report; wherein, the associated packages at least include binary packages having installation dependencies with the sub-packages generated by the source code package of the upgrade software package and source code packages having compilation dependencies with the sub-packages generated by the source code package of the upgrade software package;

[0038] A second test module, configured to obtain the previous version of the upgrade software package, and use a compatibility check tool to obtain the differences between the current version of the upgrade software package and the previous version of the upgrade software package to obtain a difference report;

[0039] A third test module, configured to determine a list of interfaces with binary interface changes according to the difference report, and determine a second result report according to the relationship between the interfaces called by the associated packages and the list of interfaces.

[0040] In a third aspect, the present invention provides a computer device, including: a memory and a processor, which are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to execute the software package version upgrade result testing method according to the first aspect or any corresponding embodiment thereof.

[0041] In a fourth aspect, the present invention provides a computer-readable storage medium, on which computer instructions are stored, and the computer instructions are used to cause a computer to execute the software package version upgrade result testing method according to the first aspect or any corresponding embodiment thereof.

[0042] In a fifth aspect, the present invention provides a computer program product, including computer instructions, and the computer instructions are used to cause a computer to execute the software package version upgrade result testing method according to the first aspect or any corresponding embodiment thereof. Description of the Drawings

[0043] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0044] Figure 1 is a schematic flowchart of a software package version upgrade result testing method according to an embodiment of the present invention;

[0045] Figure 2 is a schematic flowchart of another software package version upgrade result testing method according to an embodiment of the present invention;

[0046] Figure 3 is a schematic flowchart of yet another software package version upgrade result testing method according to an embodiment of the present invention;

[0047] Figure 4 is a schematic flowchart of still another software package version upgrade result testing method according to an embodiment of the present invention;

[0048] Figure 5 is a structural block diagram of a software package version upgrade result testing device according to an embodiment of the present invention;

[0049] Figure 6 is a schematic hardware structure diagram of a computer device according to an embodiment of the present invention. Specific Embodiments

[0050] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present invention.

[0051] The software package version upgrade result testing method provided by the present invention is applicable to the test scenario affected by the system software package version upgrade. The present invention uses comprehensive means and an automated method to quickly analyze the impact of the software package upgrade to determine whether the upgraded software package affects the software packages that compile and install depending on this software package and its sub-packages in the system, and generates a corresponding report output to provide reference for developers and system maintainers, assisting in the management of the system and the repository to ensure the stability of the system and the tool repository for package management (such as the yum repository).

[0052] According to an embodiment of the present invention, an embodiment of a method for testing the result of software package version upgrade is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0053] In this embodiment, a method for testing the result of software package version upgrade is provided, which can be used in the above computer systems, such as desktop computers, tablet computers, servers, etc. Figure 1 It is a flowchart of the method for testing the result of software package version upgrade according to an embodiment of the present invention, as Figure 1 shown, and the process includes the following steps:

[0054] Step S101, when the upgrade software package is successfully installed in the pre-constructed virtual test environment, obtain the associated packages of the source code package of the upgrade software package, and perform installation or compilation verification on the associated packages based on the virtual test environment to obtain the first result report; wherein, the associated packages at least include binary packages having installation dependencies with the sub-packages generated by the source code package of the upgrade software package and source code packages having compilation dependencies with the sub-packages generated by the source code package of the upgrade software package.

[0055] Specifically, the selected upgrade software package is a software package for which the analysis of upgrade impact is required. The present invention does not limit the system to which the software package belongs. For example, it can be a LINUX system software package or a software package of other systems.

[0056] After selecting the upgrade software package, install it in the pre-constructed virtual test environment, which realizes the isolation from the host environment. All test analysis items are completed in the constructed virtual test environment, thereby eliminating the execution differences in subsequent steps caused by the system environment, ensuring the purity of the test environment without affecting the host environment, and avoiding the problem of increasing redundancy of the host.

[0057] Furthermore, a tool for building and testing RPM packages is used to build the virtual test environment. Specifically, the tool for building and testing RPM packages can adopt an existing tool for automatically building, testing, and deploying RPM packages in the prior art (such as mock, etc.), or a dedicated tool for building and testing RPM packages can be developed using programming languages (such as C#, Java, Python, etc.) in combination with building, testing, and deployment technologies.

[0058] In a specific embodiment, a compilation environment for this source code package is built based on mock to obtain the virtual test environment. It should be emphasized that the software packages used to build the mock environment are all software packages that form an image in the tool repository for package management (such as the yum repository), which ensures the consistency of verification.

[0059] Among them, mock is a tool for building and testing RPM packages. It simulates the build environment by installing all the necessary dependencies in a chroot environment. The advantage of doing this is to ensure that the software package build process is clean, reproducible, and can avoid potential dependency issues.

[0060] In addition, if the mock tool is used to build a virtual test environment, the installation of the upgraded software package can be completed in mock through an automated verification tool.

[0061] If the installation is successful, it indicates that the sub-packages generated by the upgraded software package are compatible with the tool repositories (such as the yum repository) used for package management in the system. This step verifies the compatibility of the upgraded software package, that is, the matching of the sub-packages generated by the upgraded software package with the tool repositories (such as the yum repository) used for package management.

[0062] After that, obtain the associated packages of the source package of the upgraded software package. The associated packages include at least the binary packages that have installation dependencies with the sub-packages generated by the source package of the upgraded software package and the source packages that have compilation dependencies with the sub-packages generated by the source package of the upgraded software package. The associated packages are essentially the affected items associated with the source package to be upgraded, that is, the software packages that install and compile depending on the sub-packages generated by this source code, which mainly reflects the impact scope of the upgrade, that is, which packages in the tool repositories (such as the yum repository) used for package management will be affected by the change of this package.

[0063] It should be noted that a query tool for managing OS software package dependencies and providing a complete map of dependency and being-dependent relationships is used to obtain the associated packages of the source package of the upgraded software package. This query tool for managing OS software package dependencies and providing a complete map of dependency and being-dependent relationships can use the existing query tools for managing OS software package dependencies and providing a complete map of dependency and being-dependent relationships in the prior art (such as the pkgship platform, etc.), or a dedicated query tool for managing OS software package dependencies and providing a complete map of dependency and being-dependent relationships can be developed using programming languages (such as C#, Java, Python, etc.) combined with building, testing, and deployment technologies.

[0064] In a specific embodiment, the associated packages of the source package of the upgraded software package in the tool repositories (such as the yum repository) used for package management are obtained through the pkgship platform.

[0065] Among them, Pkgship is a query tool that manages the dependencies of OS software packages and provides a complete graph of dependencies and being-dependent relationships. Pkgship provides functions such as software package dependency query, lifecycle management, and patch query. This software package is developed, maintained, and open-sourced by the Euler team. Based on this tool and the user's repository, one can build their own Pkgship platform to view the compilation and installation dependencies associated with the software package to be upgraded, that is, to find the software packages that produce binary packages from the source packages installed in the yum repository, and to find the software packages that compile and depend on this source package to produce binary packages in the yum repository.

[0066] After obtaining the associated packages, install or compile and verify the associated packages on the virtual test environment where the upgraded software package is installed to obtain the first result report. The first result report includes the success information of the installation / compile verification of the associated packages, or the error information of the installation / compile verification of the associated packages.

[0067] Furthermore, if the virtual test environment is a mock environment, the installation or compile verification of the associated packages can also be completed through an automated tool in the mock.

[0068] Step S102: Obtain the previous version of the upgraded software package, and use a compatibility check tool to obtain the differences between the current version of the upgraded software package and the previous version to obtain a difference report.

[0069] Specifically, on the virtual test environment, obtain the previous version of the upgraded software package, and through the compatibility check tool, obtain the differences between these two versions and form a difference report. These reports include the source code compatibility and binary compatibility.

[0070] Furthermore, obtain the previous version of the upgraded software package from the software package build system. This software package build system can adopt the software package build system in the existing technology (such as the koji platform, etc.), or can use programming languages (such as C#, Java, Python, etc.) combined with build, test, and deployment technologies to develop a software package build system specifically for software package building.

[0071] For example, in a specific embodiment, obtain the list of packages of the previous version from the koji platform, so as to obtain the previous version of the upgraded software package, including the binary list and related debug packages.

[0072] Among them, it should be explained that the koji software package building system is a software system based on mock for building rpm packages, which provides a centralized rpm software package building environment. Koji maintains the building of all software packages in the yum repository. The current used version of the changed software package can be queried on this platform. All binary packages and related debug packages generated by the software package before the change can be obtained through this platform. By comparing the information of the corresponding binary packages and debug packages downloaded from this platform with those generated by the software package being upgraded, the compatibility issue between the two versions can be reflected from one aspect.

[0073] In addition, the compatibility checking tool can adopt the compatibility checking tools in the prior art (such as the ABI (abi-compliance-checker) tool, etc.), or can also develop a compatibility checking tool dedicated to compatibility checking by using programming languages (such as C#, Java, Python, etc.) in combination with building, testing and deployment technologies.

[0074] Furthermore, in a specific embodiment, the compatibility checking tool adopts the ABI (abi-compliance-checker) tool. It should be noted that not all source code packages can obtain ABI-related reports because ABI is for c / c++ shared libraries. The compatibility of the source code is mainly related to compilation, and the binary compatibility is mainly related to running.

[0075] Among them, the ABI (abi-compliance-checker) tool is a tool for checking the backward binary compatibility of shared C / C++ libraries. It checks changes in the call stack, changes in the v-table, deleted symbols, etc. For some C / C++ dynamic libraries that have been used by other programs in the form of dynamic linking, this problem will only be exposed when the program runs. Perform ABI analysis based on the generated new and old binary packages, obtain the change report, and find out the affected symbol changes. Then check which binary packages in the yum repository will reference these changes and the affected binary symbols, and give the corresponding report.

[0076] Step S103, determine the interface list of the binary interface changes according to the difference report, and determine the second result report according to the relationship between the interfaces called by the associated packages and the interface list.

[0077] After obtaining the difference report, further analyze the impact scope. In step 102, the compatibility of the source code included in the difference report is obtained. In step 101, the compilation compatibility of the associated packages is detected by installation or compilation verification, but the binary compatibility needs to be further detected.

[0078] Specifically, determine the interface list of binary interface changes according to the difference report, check whether the interfaces called by the associated packages are included in the interface list, and determine the second result report according to the inclusion relationship.

[0079] The software package version upgrade result testing method provided by the embodiments of the present invention is tested in a pre-constructed virtual test environment to eliminate execution differences caused by the system environment; the associated packages having a dependency relationship with the upgraded software package are respectively judged according to the corresponding logic to obtain a first result report, and the identification result generated by the upgraded software package on other software packages is determined; compare the upgraded software package with the previous version to obtain a difference report, and determine the compatibility of the upgraded software package; determine the list of binary interface changes according to the difference report, and further judge the result according to the list of binary interface changes to obtain a second result report, and determine the non-identification result generated by the upgraded software package on other software packages. The present invention detects the results of the upgraded software package on other software packages from multiple aspects in a pre-constructed virtual test environment, and has good migration performance.

[0080] In some optional implementation manners of this embodiment, step S103 specifically includes the following steps:

[0081] Step S1031: Obtain the interface list of binary interface changes from the difference report.

[0082] Specifically, the difference report gives the changed dynamic libraries, which include the changed entries and the affected interfaces (i.e., binary interface changes). The affected interfaces can be directly extracted from the difference report to obtain the interface list.

[0083] Step S1032: Extract binary packages from the associated packages to obtain a binary package list.

[0084] Specifically, for further detection of binary compatibility, obtain the list of binary packages generated by the source packages that install the dependent upgraded software package. This list can be directly extracted from the associated packages, and the obtained list is denoted as the binary package list.

[0085] Step S1033: Download and decompress the binary packages in the binary package list through the current tool repository for package management.

[0086] Step S1034: Query the changed dynamic libraries referenced by the binary packages.

[0087] Download the binary packages in the binary package list through the tool repository for package management (such as the yum repository), decompress these binary packages, and then query which of these binary packages reference the changed dynamic libraries and extract the relevant dynamic libraries.

[0088] In a specific embodiment, the ldd command is used to query the changed dynamic libraries.

[0089] Step S1035: Query the interfaces called by the changed dynamic libraries.

[0090] Step S1036: If the interfaces called by the changed dynamic libraries are included in the interface list, generate a second result report based on the binary package corresponding to the changed dynamic library.

[0091] Specifically, after obtaining the relevant changed dynamic libraries, query whether the affected interfaces are called during the process of referencing these changed dynamic libraries. Specifically, first query the interfaces called by the changed dynamic libraries. Based on the interface list obtained in step S1031, if the changed dynamic libraries do not call the interfaces in the interface list, it means that the upgrade of the upgraded software package has no impact on the binary package corresponding to the changed dynamic library. If the changed dynamic libraries call the interfaces in the interface list, it means that the upgrade of the upgraded software package has an impact on the binary package corresponding to the changed dynamic library.

[0092] At this time, the output second result report is whether the upgrade of the upgraded software package has an impact on the binary package corresponding to the changed dynamic library. Further, the interfaces, changed dynamic libraries, and binary packages involved in the analysis can be further output to form a second result report to provide to the analysts to further determine the relevant impacts. Further, the second result report can also include the source code of the binary package.

[0093] In one embodiment, use the readelf command to query whether the affected interfaces are called in the binary package that references the above-mentioned changed dynamic libraries.

[0094] It should be noted that the embodiments of the present invention are more applicable to software packages for the Linux system.

[0095] For packages of interpreted languages such as python and perl, the second result report output by step SS1036 can give which source code packages call which changed dynamic libraries and their affected symbols.

[0096] The embodiments of the present invention determine the list of binary interface changes according to the difference report, determine the software packages in the current system that call the changed binary interfaces, and then determine their affected situations, efficiently and quickly detecting the non-identical results of software package upgrades.

[0097] In some alternative implementation manners of this embodiment, obtaining the associated packages of the source code package of the upgraded software package in step 101, installing or compiling and verifying the associated packages based on the virtual test environment, and obtaining the first result report include the following steps:

[0098] Step a1: Using a preset software package dependency tool, obtain, from the tool repository for package management in the virtual test environment, software packages that have installation dependencies and / or compilation dependencies on the sub-packages generated by the source package of the upgraded software package, to obtain at least one associated package.

[0099] On the virtual test environment where the upgraded software package is installed, use the software package dependency tool to obtain software packages that have installation dependencies and / or compilation dependencies on the sub-packages generated by the source package of the upgraded software package, that is, obtain the associated packages.

[0100] Step a2: Extract binary packages from the associated packages to obtain a binary package list.

[0101] Extract binary packages from the associated packages to obtain a binary package list.

[0102] After that, install the binary packages in the binary package list on the virtual test environment where the upgraded software package is installed.

[0103] Step a3: When the binary packages in the binary package list are installed normally and the sub-packages of the upgraded source package are not downgraded during installation, extract all the source packages from the associated packages to obtain a source package list.

[0104] If all the binary packages in the binary package list can be installed normally and there is no situation where the sub-packages of the installed upgraded source package are downgraded during the installation process, it means that the tool repository for package management (such as the yum repository) is compatible with the binary packages in the binary package list in terms of installation dependencies, and the upgrade will not affect the installation of other software packages in the tool repository for package management (such as the yum repository).

[0105] On the contrary, if there are binary packages in the binary package list that cannot be installed normally, it means that the tool repository for package management (such as the yum repository) is not compatible with some of the binary packages in the binary package list in terms of installation dependencies, and the upgrade will affect the installation of other software packages in the tool repository for package management (such as the yum repository).

[0106] On the virtual test environment where the upgraded software package is installed, extract all the source packages through a query tool that manages the OS software package dependencies and provides a complete map of the dependency and being-dependent relationships, to obtain a source package list. In one embodiment, obtain the source package list of the soft package to be upgraded for compilation dependencies through pkgship.

[0107] Step a4: Using a preset software package source code maintenance tool, obtain the target source code corresponding to the source package list in the tool repository for package management.

[0108] The source code maintenance tool for the software package can adopt the source code maintenance tool in the existing technology (such as GitLab, etc.), or can develop a source code maintenance tool specifically for software package source code maintenance by using programming languages (such as C#, Java, Python, etc.) in combination with building, testing and deployment technologies.

[0109] In a specific embodiment, then according to the source code package list, obtain these source codes in the list from gitlab to obtain the target source code.

[0110] Among them, GitLab is a Web-based management tool based on the Git version control system. The source code maintenance of all software packages in the Yum repository is completed in gitlab. All packages that compile and depend on this source code package to generate binary packages in the yum repository queried from pkgship can obtain their relevant source codes in gitlab, so as to analyze the impact surface of the software package upgrade on the packages that compile and depend on this source code package.

[0111] Step a5: Compile the target source code based on the virtual test environment. If all compilations are normal, output the installation and compilation success information as the first result report.

[0112] Specifically, compile the target source code on the virtual test environment where the upgraded software package is installed. It should be noted that when installing these target source codes that have compilation dependencies with the upgraded software package, if there is no software package downgrading situation in step a3, then there will definitely be no software package downgrading situation in step a5. Further, if all target source code compilations are normal, it means that at the source code level, the upgraded software package is compatible and will not affect the compilation of other software packages in the tool repository (such as the yum repository) for package management.

[0113] In addition, if the virtual test environment is a mock environment, the process of step a5 can also be automatically completed in the mock environment through an automated tool.

[0114] The embodiments of the present invention use a variety of tools to respectively detect the results of the software packages that are installed and depend on the upgraded software package and the software packages that are compiled and depend on the upgraded software package, fundamentally verifying the compatibility of the upgraded software package source code and the impact on the operation of the software packages that are installed and depend on this package.

[0115] In some optional implementation manners of this embodiment, install the upgraded software package in the pre-constructed virtual test environment, specifically including:

[0116] Step b1: Obtain the source code package of the upgraded software package, and build a virtual test environment for the source code package based on the pre-selected automated verification tool.

[0117] Specifically, first obtain the source code package of the upgrade software package. Before compiling the source code package, it is generally necessary to conduct preliminary compilation verification. Select the corresponding source code package and use an automated verification tool to build the compilation environment for this source code package based on the automated verification tool, that is, obtain a virtual test environment. It should be noted that the software packages used to build the virtual test environment are all software packages that form an image in the tool repository for package management (such as the yum repository), which ensures the consistency of verification.

[0118] Step b2: Install the upgrade software package in the virtual test environment.

[0119] Specifically, when compiling the source code package and installing the compilation result in the virtual test environment, generally the upgrade software packages to be upgraded have passed preliminary verification and can be successfully compiled through the automated verification tool.

[0120] In some alternative implementation manners of this embodiment, step b2 specifically includes the following steps:

[0121] Step b21: Compile the source code package based on the virtual test environment to obtain a binary package to be installed;

[0122] Step b22: Install the binary package to be installed.

[0123] Specifically, in the virtual test environment where the upgrade software package is installed, compile the source code package in the virtual test environment to obtain a binary package to be installed. Install the binary package to be installed.

[0124] It should be emphasized again that if the binary package to be installed compiled can be successfully installed, it indicates that the sub-packages generated by the upgrade software package are compatible with the tool repository for package management (such as the yum repository).

[0125] The embodiment of the present invention conducts tests in the constructed virtual test environment to isolate the verification environment and eliminate execution differences caused by the system environment.

[0126] In this embodiment, a method for testing the result of software package version upgrade is provided, which can be used in the above computer systems, such as desktop computers, tablet computers, servers, etc. Figure 2 It is a flowchart of the method for testing the result of software package version upgrade according to the embodiment of the present invention, as Figure 2 shown. The process includes the following steps:

[0127] Step S101, when the upgrade software package is successfully installed in the pre-constructed virtual test environment, obtain the associated packages of the source code package of the upgrade software package, and perform installation or compilation verification on the associated packages based on the virtual test environment to obtain a first result report. Among them, the specific steps of step S101 are the same as those in the above embodiment, and the present invention will not elaborate on this.

[0128] Step S201, if the installation or compilation fails, output a third result report; wherein, the third result report includes error messages.

[0129] If a failure occurs during the installation or compilation, output a third result report including error messages.

[0130] To further elaborate on the software package version upgrade result test provided by the present invention, a specific embodiment is given, as Figure 3 and Figure 4 shown, which specifically includes the following steps:

[0131] As Figure 3 shown, first, select the software package to be upgraded, denoted as the upgrade software package. After selection, perform a preliminary compilation verification. After selection, obtain the source code package of the upgrade software package, and use an automated verification tool to build a compilation environment for this source code package based on mock. The software packages used to build the mock environment are all software packages that form an image in the yum repository, so as to ensure the consistency of verification. Compile the source code package. Generally speaking, the software versions to be upgraded have passed preliminary verification and can be successfully compiled through mock.

[0132] Then install the binary package compiled in the mock environment. If the compiled binary package can be successfully installed, it means that the sub-packages generated by the upgraded software package are matched with the yum repository in terms of installation dependencies. Here, it should be noted that the entire process is completed through an automated tool in mock. The compilation environment and dependencies of the source code package are all sourced from the yum repository, and here the matching of the generated sub-packages with the yum repository is verified.

[0133] On the mock environment where the new software package is installed, obtain the affected items associated with the source code package to be upgraded in the yum repository as associated packages (i.e., the software packages that install and compile the sub-packages generated by this source code). Install the packages that depend on the sub-packages generated by this source code package in the mock environment of the new software package. If these software packages can all be normally installed and no downgrading of the sub-packages of the installed upgraded source code package occurs during the installation process, it means that the software packages in the yum repository that install the sub-packages generated by the upgraded software package are matched, and the upgrade will not affect the installation of other software packages in the yum repository.

[0134] On top of the mock environment with the new software package installed, use pkgship to obtain the list of source code packages for the compilation dependencies of the software package to be upgraded. Then, based on these lists, obtain the source codes in these lists from GitLab, and then compile these source codes on top of the mock environment with the new software package installed. When installing these compilation dependencies, if there is no downgrade of the software package in the previous installation step, then there will definitely be no downgrade of the software package in this step. If the compilation of these source code packages is normal, it indicates that the software packages to be upgraded at the source code level are compatible and will not affect the compilation of the software packages in the yum repository. This process is also automatically completed through an automated tool in the mock environment.

[0135] As Figure 4 shown, on top of the mock environment with the new software package installed, there are binary packages compiled from the source code packages to be upgraded. At this time, it is necessary to obtain the binary packages of the previous version. In order to obtain comprehensive binary packages and related debug packages, choose to obtain the list of packages of the previous version from the Koji platform. After obtaining the binary packages and related debug packages of the two versions, use the open-source ABI tool to obtain the differences between these two versions and form a difference report. These reports include the compatibility of the source code and the compatibility of the binary. It should be noted that not all source code packages can obtain ABI-related reports because ABI is for C / C++ shared libraries. The compatibility of the source code is mainly related to compilation, and the compatibility of the binary is mainly related to runtime.

[0136] The software package version upgrade result testing method provided by the present invention realizes the impact analysis of software package upgrade through automated means, combines multiple tools and means to analyze and verify the impact surface from multiple aspects, and at the same time achieves the isolation of the verification environment. Each test verification item has a corresponding report to present to the R & D personnel to assist the R & D personnel in analysis, avoiding the problems that after the software package is upgraded, the software that depends on this software package for installation and operation cannot run, or the software that depends on this software package for compilation cannot be compiled successfully after the software package is upgraded.

[0137] In this embodiment, a software package version upgrade result testing device is also provided. This device is used to implement the above-mentioned embodiments and preferred implementation manners, and those that have been described will not be repeated. As used hereinafter, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0138] This embodiment provides a software package version upgrade result testing device, as Figure 5 shown, including:

[0139] The first test module 501 is used to obtain the associated packages of the source code package of the upgrade software package when the installation of the upgrade software package in the pre-built virtual test environment is successful, and perform installation or compilation verification on the associated packages based on the virtual test environment to obtain a first result report. Among them, the associated packages at least include binary packages with installation dependencies on the sub-packages generated by the source code package of the upgrade software package and source code packages with compilation dependencies on the sub-packages generated by the source code package of the upgrade software package.

[0140] The second test module 502 is used to obtain the previous version of the upgrade software package, and use a compatibility check tool to obtain the differences between the current version of the upgrade software package and the previous version of the upgrade software package to obtain a difference report.

[0141] The third test module 503 is used to determine a list of interfaces with binary interface changes according to the difference report, and determine a second result report according to the relationship between the interfaces called by the associated packages and the list of interfaces.

[0142] The further function descriptions of the above-mentioned various modules and units are the same as those in the corresponding embodiments above, and will not be repeated here.

[0143] The software package version upgrade result test device in this embodiment is presented in the form of functional units. Here, the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and a memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0144] The embodiment of the present invention also provides a computer device having the above Figure 5 shown software package version upgrade result test device.

[0145] Please refer to Figure 6 , Figure 6 which is a schematic structural diagram of a computer device provided by an alternative embodiment of the present invention. As Figure 6As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Each component communicates with each other using different buses and can be installed on a common motherboard or installed in other ways as needed. The processor can process instructions executed within the computer device, including instructions stored in the memory or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some alternative embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides part of the necessary operations (for example, as a server array, a set of blade servers, or a multi-processor system). Figure 6 In the figure, a processor 10 is taken as an example.

[0146] The processor 10 can be a central processing unit, a network processor, or a combination thereof. Among them, the processor 10 can further include a hardware chip. The above hardware chip can be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The above programmable logic device can be a complex programmable logic device, a field programmable gate array, a general array logic, or any combination thereof.

[0147] Among them, the memory 20 stores instructions executable by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiments.

[0148] The memory 20 can include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created according to the use of the computer device. In addition, the memory 20 can include a high-speed random access memory, and can also include a non-transitory memory, such as at least one disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some alternative embodiments, the memory 20 can optionally include a memory remotely set relative to the processor 10, and these remote memories can be connected to the computer device through a network. Examples of the above network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0149] The memory 20 can include a volatile memory, such as a random access memory; the memory can also include a non-volatile memory, such as a flash memory, a hard disk, or a solid-state drive; the memory 20 can also include a combination of the above types of memories.

[0150] The computer device further includes an input device 30 and an output device 40. The processor 10, the memory 20, the input device 30, and the output device 40 may be connected by a bus or other means. Figure 6 Taking connection by bus as an example.

[0151] The input device 30 can receive input digital or character information, and generate key signal inputs related to user settings and function control of the computer device, such as a touch screen, a keypad, a mouse, a trackpad, a touchpad, a pointing stick, one or more mouse buttons, a trackball, a joystick, etc. The output device 40 may include a display device, an auxiliary lighting device (e.g., an LED), and a haptic feedback device (e.g., a vibration motor), etc. The above display device includes but is not limited to a liquid crystal display, a light-emitting diode, a display, and a plasma display. In some alternative embodiments, the display device may be a touch screen.

[0152] The computer device further includes a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0153] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or be implemented as computer code that can be recorded on a storage medium, or be implemented by downloading through a network and originally stored in a remote storage medium or a non-transitory machine-readable storage medium and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid-state drive, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code, and when the software or computer code is accessed and executed by the computer, the processor, or the hardware, the method shown in the above embodiment is implemented.

[0154] A part of the present invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can call or provide the methods and / or technical solutions according to the present invention through the operations of the computer. Those skilled in the art should understand that the forms of existence of computer program instructions in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways for computer program instructions to be executed by a computer include, but are not limited to: the computer directly executes the instructions, or the computer compiles the instructions and then executes the corresponding compiled program, or the computer reads and executes the instructions, or the computer reads and installs the instructions and then executes the corresponding installed program. Herein, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible by the computer.

[0155] Although the embodiments of the present invention are described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for testing the result of software package version upgrade, characterized in that, The method includes: When the upgrade software package is successfully installed in a pre-constructed virtual test environment, obtain the associated packages of the source code package of the upgrade software package, and perform installation or compilation verification on the associated packages based on the virtual test environment to obtain a first result report; wherein, the associated packages at least include binary packages having installation dependencies with the sub-packages generated by the source code package of the upgrade software package and source code packages having compilation dependencies with the sub-packages generated by the source code package of the upgrade software package; Obtain the previous version of the upgrade software package of the upgrade software package, and use a compatibility check tool to obtain the differences between the current version of the upgrade software package and the previous version of the upgrade software package to obtain a difference report; Determine a list of interfaces with binary interface changes according to the difference report, and determine a second result report according to the relationship between the interfaces called by the associated packages and the list of interfaces; The step of determining a list of interfaces with binary interface changes according to the difference report and determining a second result report according to the relationship between the interfaces called by the associated packages and the list of interfaces specifically includes: Obtain a list of interfaces with binary interface changes from the difference report; Extract binary packages from the associated packages to obtain a list of binary packages; Download and decompress the binary packages in the list of binary packages through the current tool repository for package management; Query the changed dynamic libraries referenced by the binary packages; Query the interfaces called by the changed dynamic libraries; If the interfaces called by the changed dynamic libraries are included in the list of interfaces, generate a second result report according to the binary packages corresponding to the changed dynamic libraries.

2. The method according to claim 1, wherein The step of obtaining the associated packages of the source code package of the upgrade software package and performing installation or compilation verification on the associated packages based on the virtual test environment to obtain a first result report specifically includes: Use a preset software package dependency relationship tool to obtain, from the tool repository for package management in the virtual test environment, software packages having installation dependencies and / or compilation dependencies with the sub-packages generated by the source code package of the upgrade software package to obtain at least one associated package; Extract binary packages from the associated packages to obtain a list of binary packages; When the binary packages in the list of binary packages are installed normally and the sub-packages of the upgraded source code package are not downgraded for installation, extract all the source code packages from the associated packages to obtain a list of source code packages; Use a preset software package source code maintenance tool to obtain the target source code corresponding to the list of source code packages in the tool repository for package management; Compile the target source code based on the virtual test environment. If all compilations are normal, output installation and compilation success information as the first result report.

3. The method according to claim 1, wherein Install the upgrade software package in a pre-constructed virtual test environment, specifically including: Obtain the source code package of the upgrade software package, and construct a virtual test environment for the source code package based on a pre-selected automated verification tool; In the virtual test environment, install the upgrade software package.

4. The method according to claim 3, wherein The step of installing the upgrade software package in the virtual test environment specifically includes: Compile the source code package based on the virtual test environment to obtain a binary package to be installed; Install the binary package to be installed.

5. The method according to claim 1, wherein The method further includes: If the installation or compilation fails, the third result report is output; wherein, the third result report includes error messages.

6. A software package version upgrade result testing device, characterized in that, The device includes: A first test module, configured to, when the upgrade software package is successfully installed in a pre-constructed virtual test environment, obtain an associated package of the source code package of the upgrade software package, and perform installation or compilation verification on the associated package based on the virtual test environment to obtain a first result report; wherein, the associated package at least includes a binary package having an installation dependency on the sub-packages generated by the source code package of the upgrade software package and a source code package having a compilation dependency on the sub-packages generated by the source code package of the upgrade software package; A second test module, configured to obtain the previous version of the upgrade software package, and use a compatibility check tool to obtain the differences between the current version of the upgrade software package and the previous version of the upgrade software package to obtain a difference report; A third test module, configured to determine a list of interfaces with binary interface changes according to the difference report, and determine a second result report according to the relationship between the interfaces called by the associated package and the list of interfaces; The step of determining a list of interfaces with binary interface changes according to the difference report, and determining a second result report according to the relationship between the interfaces called by the associated package and the list of interfaces specifically includes: Obtaining a list of interfaces with binary interface changes from the difference report; Extracting binary packages from the associated package to obtain a list of binary packages; Downloading and decompressing the binary packages in the list of binary packages through the current tool repository for package management; Querying the changed dynamic libraries referenced by the binary packages; Querying the interfaces called by the changed dynamic libraries; If the interfaces called by the changed dynamic libraries are included in the list of interfaces, generating a second result report according to the binary packages corresponding to the changed dynamic libraries.

7. A computer device, characterized in that, Including: A memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to execute the software package version upgrade result test method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, Computer instructions are stored on the computer-readable storage medium, and the computer instructions are used to cause a computer to execute the software package version upgrade result test method according to any one of claims 1 to 5.

9. A computer program product, characterized in that, Including computer instructions, and the computer instructions are used to cause a computer to execute the software package version upgrade result test method according to any one of claims 1 to 5.

Images