Software package version upgrading result testing method and device

Abstract

The invention relates to the technical field of software testing, and discloses a software package version upgrading result testing method and device.The method comprises the steps that when an upgrading software package is successfully installed in a pre-built virtual testing environment, an association package of a source code package of the upgrading software package is obtained, and the association package is installed or compiled and verified based on the virtual testing environment; obtaining a first result report; wherein the association package at least comprises a binary package having installation dependence with a sub-package generated by the source code package of the upgrading software package and a source code package having compiling dependence with the sub-package generated by the source code package of the upgrading software package; obtaining an upgrading software package of a previous version of the upgrading software package, and obtaining a difference between the upgrading software package of the current version and the upgrading software package of the previous version by utilizing a compatibility checking tool to obtain a difference report; and determining an interface list of binary interface change according to the difference report, and determining a second result report according to the relationship between the interface called by the association packet and the interface list. The method is good in mobility.

Description

Technical Field

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

[0002] As the cybersecurity situation becomes increasingly serious, the demand for cybersecurity from enterprises and individuals increases, which has led to the vigorous development of the information and communication technology industry and the gradual rise of domestic operating systems.

[0003] Domestic independent operating systems are basically built on the open source Linux operating system, including server-oriented systems and client-oriented systems. These operating systems are built from thousands of open source software modules from the core to the application layer. These modules are intertwined and depend on each other for compilation or installation. This structure leads to a problem that once a 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 entire system to operate abnormally, which brings considerable challenges to the software upgrade process.

[0004] Based on this, some studies have adopted the method of identifying dependencies of software packages to assist upgrades, in order to predict the possible impact of software package changes in advance. However, due to the complexity and variability of the software compilation environment in the operating system, although a software package identifies its own compilation dependencies and installation dependencies in the configuration file, these dependencies come from the open source community and may differ from the environment actually provided by the system. If the environment provided by the system is more extensive, resulting in inconsistencies between the actual compilation parameters of the open source software and the parameters specified in the configuration file, in this case, even if the same software package is on the same system, different compilers may encounter different results: one person may be able to compile smoothly, while another may encounter compilation failures.

[0005] In summary, the related technology has the problem of poor mobility. Summary of the invention

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

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

[0008] When the upgrade software package is successfully installed in the pre-built virtual test environment, an associated package of the source code package of the upgrade software package is obtained, and the associated package is installed or compiled and verified 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 a sub-package generated by the source code package of the upgrade software package and a source code package having a compilation dependency on a sub-package generated by the source code package of the upgrade software package;

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

[0010] An interface list of binary interface changes is determined according to the difference report, and a second result report is determined according to a relationship between the interface called by the associated package and the interface list.

[0011] The test is conducted in a pre-built virtual test environment to eliminate the execution differences caused by the system environment; the associated packages with dependencies on the upgrade software package are respectively judged according to the corresponding logic to obtain a first result report to determine the identification results generated by the upgrade software package on other software packages; the upgraded software package is compared with the previous version to obtain a difference report to determine the compatibility of the upgrade software package; the list of binary interface changes is determined according to the difference report, and the result is further judged according to the list of binary interface changes to obtain a second result report to 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 a pre-built virtual test environment, and has good mobility.

[0012] In an optional implementation, determining an interface list of binary interface changes according to the difference report, and determining a second result report according to a relationship between an interface called by an associated package and the interface list, specifically includes:

[0013] Get the list of interfaces with binary interface changes from the diff report;

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

[0015] Download and unpack the binary packages in the binary package list through the tool repository currently used for package management;

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

[0017] Query the interface of the dynamic library call that has changed;

[0018] If the interface called by the changed dynamic library is included in the interface list, a second result report is generated according to the binary package corresponding to the changed dynamic library.

[0019] According to the difference report, a list of binary interface changes is determined, and the software packages in the current system that call the changed binary interfaces are determined, and then the affected situations are determined, so as to efficiently and quickly detect non-identification results of software package upgrades.

[0020] In an optional implementation, obtaining an associated package of a source package of an upgrade software package, installing or compiling and verifying the associated package based on a virtual test environment, and obtaining a first result report specifically includes:

[0021] Using a preset software package dependency tool, obtain a software package that has an installation dependency relationship and / or a compilation dependency relationship with a sub-package generated by a source package of the upgrade software package from a tool repository for package management in the virtual test environment, and obtain at least one associated package;

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

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

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

[0025] The target source code is compiled based on the virtual test environment. If the compilation is normal, the installation and compilation success information is output as the first result report.

[0026] Using a variety of tools, we tested the results of installing the software packages that depend on the upgraded software packages and compiling the software packages that depend on the upgraded software packages. This fundamentally verified the compatibility of the upgraded software package source code and its impact on the operation of the software packages that depend on this package.

[0027] In an optional implementation, installing the upgrade software package in a pre-built virtual test environment specifically includes:

[0028] Obtain a source code package of the upgrade software 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 upgrade package.

[0030] In an optional implementation, installing the upgrade software package in the virtual test environment specifically includes:

[0031] Compile the source code package based on the virtual test environment to obtain the binary package to be installed;

[0032] Install the binary package to be installed.

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

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

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

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

[0037] A first test module is used to obtain an associated package of a source code package of the upgrade software package when the upgrade software package is successfully installed in the pre-built virtual test environment, and to install or compile and verify 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 a sub-package generated by the source code package of the upgrade software package and a source code package having a compilation dependency on a sub-package generated by the source code package of the upgrade software package;

[0038] The second test module is used to obtain the upgrade package of the previous version of the upgrade package, use the compatibility check tool to obtain the difference between the current version of the upgrade package and the previous version of the upgrade package, and obtain a difference report;

[0039] The third test module is used to 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 interface called by the associated package and the interface list.

[0040] In a third aspect, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the software package version upgrade result testing method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

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

[0042] In a fifth aspect, the present invention provides a computer program product, comprising computer instructions for causing a computer to execute the software package version upgrade result testing method of the first aspect or any corresponding embodiment thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

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

[0045] Figure 2 is a flow chart of another method for testing software package version upgrade results according to an embodiment of the present invention;

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

[0047] Figure 4 is a flowchart of 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 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0050] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are 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 testing scenario of the impact of the system software package version upgrade. The present invention uses comprehensive means and an automated method to a certain extent to quickly analyze the impact of the software package upgrade, determine whether the upgraded software package affects the compilation and installation of software packages that depend on the software package and its sub-packages in the system, and generate corresponding report outputs to provide a reference for developers and system maintainers, assist in the management of the system and warehouses, and ensure the stability of the system and tool warehouses for package management (such as yum warehouses).

[0052] According to an embodiment of the present invention, an embodiment of a method for testing software package version upgrade results 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 a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

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

[0054] Step S101, when the upgrade software package is successfully installed in the pre-built virtual test environment, an associated package of the source code package of the upgrade software package is obtained, and the associated package is installed or compiled and verified based on the virtual test environment to obtain a first result report; wherein the associated package includes at least a binary package that has an installation dependency on a sub-package generated by the source code package of the upgrade software package and a source code package that has a compilation dependency on a sub-package generated by the source code package of the upgrade software package.

[0055] Specifically, the selected upgrade software package is a software package that needs to be analyzed for upgrade impact. 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, it is installed in the pre-built virtual test environment to achieve isolation from the host environment. All test analysis items are completed in the constructed virtual test environment, thereby eliminating the execution differences of 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 virtual test environment is constructed using a tool for constructing and testing RPM packages. Specifically, the tool for constructing and testing RPM packages can be a tool for automating the construction, testing, and deployment of RPM packages in the prior art (e.g., mock, etc.), or a tool specifically for constructing and testing RPM packages can be developed using a programming language (e.g., C#, Java, Python, etc.) in combination with construction, testing, and deployment technologies.

[0058] In a specific embodiment, the compilation environment of the source code package is constructed based on mock to obtain a virtual test environment. It should be emphasized that the software packages used to construct the mock environment are all software packages that constitute mirror images in a tool warehouse (such as a yum warehouse) for package management, so as to ensure the consistency of verification.

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

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

[0061] If the installation is successful, it means that the sub-packages generated by the upgrade software package match the system's package management tool repository (such as the yum repository) in terms of installation dependencies. This step verifies the compatibility of the upgrade software package, that is, the matching of the sub-packages generated by the upgrade software package with the tool repository (such as the yum repository) used for package management.

[0062] Afterwards, the associated packages of the source package of the upgrade software package are obtained, and the associated packages at least include binary packages with installation dependencies on sub-packages generated by the source package of the upgrade software package and source packages with compilation dependencies on sub-packages generated by the source package of the upgrade software package. The associated packages are essentially the affected items associated with the source package to be upgraded, that is, the software packages that are installed and compiled and depend on the sub-packages generated by this source package, which mainly reflect the impact of the upgrade, that is, which packages in the tool repository for package management (such as the yum repository) will be affected by the change of this package.

[0063] It should be noted that the query tool that manages OS software package dependencies and provides a complete graph of dependencies and dependencies is used to obtain the associated packages of the source package of the upgrade software package. The query tool that manages OS software package dependencies and provides a complete graph of dependencies and dependencies can adopt the query tool that manages OS software package dependencies and provides a complete graph of dependencies and dependencies in the prior art (such as the pkgship platform, etc.), or it can use programming languages ​​(such as C#, Java, Python, etc.) combined with construction, testing and deployment technologies to develop a special query tool for managing OS software package dependencies and providing a complete graph of dependencies and dependencies.

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

[0065] Among them, Pkgship is a query tool that manages OS software package dependencies and provides a complete map of dependencies and dependencies. 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. You can build your own pkgship platform based on this tool and the user's warehouse to view the compilation and installation dependencies associated with the software package to be upgraded, that is, to find the software package in the yum warehouse that installs the binary package generated by the source code package, and to find the software package in the yum warehouse that compiles the binary package generated by this source code package.

[0066] After obtaining the associated package, the associated package is installed or compiled and verified on the virtual test environment where the upgrade software package is installed to obtain a first result report, which includes success information of the associated package installation / compilation verification or error information of the associated package installation / compilation verification.

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

[0068] Step S102: obtaining an upgrade software package of a previous version of the upgrade software package, using a compatibility check tool to obtain a difference between the current version of the upgrade software package and the previous version of the upgrade software package, and obtaining a difference report.

[0069] Specifically, on the virtual test environment, the previous version of the upgrade software package is obtained, and the difference between the two versions is obtained through a compatibility check tool, and a difference report is generated. These reports include source code compatibility and binary compatibility.

[0070] Furthermore, the upgrade software package of the previous version is obtained from the software package building system. The software package building system can adopt the software package building system in the prior art (such as the koji platform, etc.), or a software package building system specifically used for software package building can be developed by combining building, testing and deployment technologies with programming languages ​​(such as C#, Java, Python, etc.).

[0071] For example, in a specific embodiment, the package list of the previous version is obtained from the koji platform, thereby obtaining the upgrade software package of the previous version, including the binary list and the related debug package.

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

[0073] In addition, the compatibility checking tool can adopt the compatibility checking tools in the existing technology (such as ABI (abi-compliance-checker) tools, etc.), or it can use programming languages ​​​​(such as C#, Java, Python, etc.) combined with build, test and deployment technologies to develop a compatibility checking tool specifically for compatibility checking.

[0074] Furthermore, in a specific embodiment, the compatibility check tool uses an 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. Source code compatibility is mainly related to compilation, and binary compatibility is mainly related to operation.

[0075] Among them, the ABI (abi-compliance-checker) tool is a tool used to check 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 are used by other programs in a dynamically linked form, this problem will only be exposed when the program is running. Perform ABI analysis based on the generated new and old binary packages, obtain a 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 a corresponding report.

[0076] Step S103: determining an interface list of binary interface changes according to the difference report, and determining a second result report according to the relationship between the interface called by the associated package and the interface list.

[0077] After obtaining the difference report, the impact is further analyzed. In step 102, the compatibility of the source code included in the difference report is obtained. In step 101, the compatibility of the compilation is tested by installing or compiling the associated package, but the binary compatibility needs to be further tested.

[0078] Specifically, the interface list of the binary interface changes is determined according to the difference report, it is checked whether the interface called by the associated package is included in the interface list, and the second result report is determined according to the inclusion relationship.

[0079] The software package version upgrade result test method provided by the embodiment of the present invention is tested in a pre-constructed virtual test environment to exclude execution differences caused by the system environment; the associated packages with dependencies on the upgrade software package are respectively judged according to corresponding logic to obtain a first result report to determine the identification results generated by the upgrade software package on other software packages; the upgraded software package is compared with the previous version to obtain a difference report to determine the compatibility of the upgrade software package; the list of binary interface changes is determined according to the difference report, and the result judgment is further performed according to the list of binary interface changes to obtain a second result report to 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 a pre-constructed virtual test environment, and has good mobility.

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

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

[0082] Specifically, the difference report provides the changed entries in the changed dynamic library and the affected interfaces (ie, binary interface changes). The affected interfaces can be directly extracted from the difference report to obtain an interface list.

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

[0084] Specifically, further binary compatibility detection is performed to obtain a list of binary packages generated by installing the source package of the dependent upgrade software package. The list can be directly extracted from the associated package, and the obtained list is recorded as a binary package list.

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

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

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

[0088] In a specific embodiment, the query of the changed dynamic library is performed through the ldd command.

[0089] Step S1035: Query the changed dynamic library call interface.

[0090] Step S1036: If the interface called by the changed dynamic library is included in the interface list, a second result report is generated according to the binary package corresponding to the changed dynamic library.

[0091] Specifically, after obtaining the relevant changed dynamic libraries, check whether the affected interfaces are called in the process of referencing these changed dynamic libraries. Specifically, first check the interfaces called by the changed dynamic libraries. Based on the interface list obtained in step S1031, if the changed dynamic library does not call the interfaces in the interface list, it means that the upgrade of the upgraded software package has no effect on the binary package corresponding to the changed dynamic library. If the changed dynamic library calls the interfaces in the interface list, it means that the upgrade of the upgraded software package has an effect 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. Furthermore, the interface involved in the analysis, the changed dynamic library and the binary package can be further output to form a second result report to provide to the analyst to further determine the relevant impact. Furthermore, the second result report can also include the source code of the binary package.

[0093] In one embodiment, the readelf command is used to query whether the affected interface is called in the binary package that references the dynamic library with the above changes.

[0094] It should be noted that the embodiment of the present invention is more suitable for software packages of Linux systems.

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

[0096] The embodiment of the present invention determines a list of binary interface changes according to the difference report, determines the software package in the current system that calls the changed binary interface, and further determines its affected situation, thereby efficiently and quickly detecting non-identification results of the software package upgrade.

[0097] In some optional implementations of this embodiment, obtaining the associated package of the source package of the upgrade software package in step 101, installing or compiling and verifying the associated package based on the virtual test environment, and obtaining the first result report includes the following steps:

[0098] Step a1: using a preset software package dependency tool, obtain software packages having installation dependency and / or compilation dependency with sub-packages generated by the source package of the upgrade software package from a tool repository for package management in the virtual test environment, and obtain at least one associated package.

[0099] In the virtual test environment where the upgrade software package is installed, a software package dependency tool is used to obtain software packages that have installation dependency and / or compilation dependency with subpackages generated by the source package of the upgrade software package, that is, to obtain associated packages.

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

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

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

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

[0104] If the binary packages in the binary package list can be installed normally and the subpackages of the installed upgrade source packages are not downgraded during the installation process, it means that the installation dependencies of the tool repository for package management (such as the yum repository) match the binary packages in the binary package list, 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 installation dependencies of the tool repository for package management (such as the yum repository) do not match those of some binary packages in the binary package list. 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 upgrade software package is installed, all source packages are extracted through a query tool that manages OS software package dependencies and provides a complete graph of dependencies and dependencies to obtain a source package list. In one embodiment, the source package list of the software package to be upgraded for compilation dependency is obtained through pkgship.

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

[0108] The software package source code maintenance tool can adopt the software package source code maintenance tool in the existing technology (such as GitLab, etc.), or it can use programming languages ​​​​(such as C#, Java, Python, etc.) combined with construction, testing and deployment technologies to develop a software package source code maintenance tool specifically used for software package source code maintenance.

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

[0110] 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 compiled from the yum repository queried by pkgship and dependent on this source code package to produce binary packages can obtain their related source code in gitlab, so as to analyze the impact of software package upgrades on the compilation of this source code package.

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

[0112] Specifically, the target source code is compiled on the virtual test environment where the upgrade software package is installed. It should be noted that when installing the target source codes that have compilation dependencies on the upgrade software package, if the software package is not downgraded in step a3, then the software package will definitely not be downgraded in step a5. Furthermore, if the target source code is compiled normally, it means that at the source code level, the upgrade software package is compatible and will not affect the compilation of other software packages in the tool repository for package management (such as the yum repository).

[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 automation tool.

[0114] The embodiment of the present invention uses multiple tools to respectively detect the results of installing a software package that depends on the upgrade software package and compiling a software package that depends on the upgrade software package, thereby fundamentally verifying the compatibility of the upgrade software package source code and its impact on the operation of the software package that depends on the installation of this package.

[0115] In some optional implementations of this embodiment, installing the upgrade software package in the pre-built virtual test environment specifically includes:

[0116] Step b1: Obtain the source code package of the upgrade software package, and build a virtual test environment for the source code package based on a 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 perform preliminary compilation verification, select the corresponding source code package, use the automated verification tool, and build the compilation environment of this source code package based on the automated verification tool, that is, to obtain the virtual test environment. It should be noted that the software packages used to build the virtual test environment are all software packages that constitute the mirror image in the tool warehouse (such as the yum warehouse) for package management, so as to ensure the consistency of verification.

[0118] Step b2: In the virtual test environment, install the upgrade software package.

[0119] Specifically, the source code package is compiled and the compilation result is installed in a virtual test environment. Generally speaking, the upgrade software package to be upgraded has undergone preliminary verification and can be successfully built and compiled through automated verification tools.

[0120] In some optional implementations 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 a virtual test environment where the upgrade software package is installed, the source code package is compiled in the virtual test environment to obtain a binary package to be installed, and the binary package to be installed is installed.

[0124] It needs to be emphasized again that if the compiled binary package to be installed can be installed successfully, it means that the sub-packages generated by the upgraded software package match the tool repository used for package management (such as the yum repository).

[0125] The embodiment of the present invention performs testing in a 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 software package version upgrade results is provided, which can be used in the above-mentioned computer systems, such as desktop computers, tablet computers, servers, etc. Figure 2 is a flowchart of a method for testing software package version upgrade results according to an embodiment of the present invention. Figure 2 As shown, the process includes the following steps:

[0127] Step S101, when the upgrade software package is successfully installed in the pre-built virtual test environment, the associated package of the source package of the upgrade software package is obtained, and the associated package is installed or compiled and verified based on the virtual test environment to obtain a first result report. The specific steps of step S101 are the same as those in the above embodiment, and the present invention will not repeat them.

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

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

[0130] In order to further explain the software package version upgrade result test provided by the present invention in more detail, a specific embodiment is given, such as Figure 3 and Figure 4 As shown, the specific steps include:

[0131] like Figure 3 As shown, first, you need to select the upgraded software package, record it as the upgraded software package, perform preliminary compilation verification after selection, get the source package of the upgraded software package after selection, use the automated verification tool, build the compilation environment of this source package based on mock, and the software packages used to build the mock environment are all the software packages that constitute the mirror in the yum warehouse, so as to ensure the consistency of verification. Compile the source package. Generally speaking, the software version to be upgraded has been preliminarily verified and can be compiled successfully through mock construction.

[0132] Then install the binary package compiled in the mock environment. If the compiled binary package can be installed successfully, it means that the sub-package generated by the upgraded software package matches the yum repository in terms of installation dependencies. Here, the whole process is completed by automated tools in mock. The compilation environment and dependencies of the source package are derived from the yum repository. Here, the matching of the generated sub-package with the yum repository is verified.

[0133] On the mock environment where the new software package is installed, the affected items associated with the source package to be upgraded in the yum repository are obtained through the pkgship platform as associated packages (i.e., software packages that are installed and compiled to depend on sub-packages generated by this source package). In the mock environment of the new software package, packages that depend on sub-packages generated by this source package are installed. If these packages can be installed normally and the sub-packages of the installed upgraded source package are not downgraded during the installation process, it means that the software packages installed in the yum repository that depend on 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] In the mock environment with the new software package installed, use pkgship to obtain the source code package list of the software package to be upgraded for compilation dependencies, and then obtain the source codes in the list from gitlab based on these lists, and then compile these source codes in 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, there will definitely be no downgrade of the software package in this step. If the compilation of these source code packages is normal, it means that the upgraded software packages 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 completed automatically in the mock environment through automation tools.

[0135] like Figure 4 As shown in the figure, on the mock environment where the new software package is installed, there is a binary package compiled from the source package to be upgraded. At this time, it is necessary to obtain the binary package of the previous version. In order to obtain comprehensive binary packages and related debug packages, choose to obtain the package list of the previous version from the koji platform. After getting the binary packages of two versions and related debug packages, the difference between the two versions is obtained through the open source ABI tool, and a difference report is formed. These reports include source code compatibility and binary compatibility. It should be noted that not all source code packages can obtain ABI-related reports, because ABI is for c / c++ shared libraries. Source code compatibility is mainly related to compilation, and binary compatibility is mainly related to runtime.

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

[0137] In this embodiment, a software package version upgrade result testing device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made are not repeated here. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0138] This embodiment provides a software package version upgrade result testing device, such as Figure 5 As 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 upgrade software package is successfully installed in the pre-built virtual test environment, and to install or compile and verify 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 on sub-packages generated by the source code package of the upgrade software package and source code packages having compilation dependencies on sub-packages generated by the source code package of the upgrade software package;

[0140] The second test module 502 is used to obtain an upgrade package of a previous version of the upgrade package, obtain the difference between the current version of the upgrade package and the previous version of the upgrade package by using a compatibility check tool, and obtain a difference report;

[0141] The third test module 503 is used to 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 interface called by the associated package and the interface list.

[0142] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0143] The software package version upgrade result testing device in this embodiment is presented in the form of a functional unit, where the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes 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 are the package version upgrade results for the tested device.

[0145] See also Figure 6 , Figure 6 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such 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. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional 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 some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 6 A processor 10 is taken as an example.

[0146] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0147] 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 embodiment.

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

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

[0150] The computer device also 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 via a bus or other means. Figure 6 The example of connecting through bus is taken in the following.

[0151] The input device 30 can receive input digital or character information, and generate key signal input related to the user settings and function control of the computer device, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, an indicator bar, 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 tactile feedback device (e.g., a vibration motor), etc. The above-mentioned display device includes but is not limited to a liquid crystal display, a light emitting diode, a display and a plasma display. In some optional embodiments, the display device can be a touch screen.

[0152] The computer device further comprises 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 can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, 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 storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, 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. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0154] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.

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

Claims

1. A method for testing software package version upgrade results, characterized in that: The method comprises: When the upgrade software package is successfully installed in the pre-built virtual test environment, an associated package of the source code package of the upgrade software package is obtained, and the associated package is installed or compiled and verified 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 a sub-package generated by the source code package of the upgrade software package and a source package having a compilation dependency on a sub-package generated by the source code package of the upgrade software package; Obtaining an upgrade package of a previous version of the upgrade package, using a compatibility check tool to obtain a difference between the current version of the upgrade package and the previous version of the upgrade package, and obtaining a difference report; An interface list of binary interface changes is determined according to the difference report, and a second result report is determined according to a relationship between the interface called by the associated package and the interface list.

2. The method according to claim 1, characterized in that: The step of determining the interface list of the binary interface changes according to the difference report, and determining the second result report according to the relationship between the interface called by the associated package and the interface list specifically includes: Obtaining a list of interfaces with binary interface changes from the difference report; Extract binary packages from the associated packages to obtain a binary package list; Download and decompress the binary packages in the binary package list through the tool repository currently used for package management; Querying the changed dynamic libraries referenced by the binary package; Querying the interface called by the changed dynamic library; If the interface called by the changed dynamic library is included in the interface list, a second result report is generated according to the binary package corresponding to the changed dynamic library.

3. The method according to claim 1, characterized in that: The obtaining of the associated package of the source package of the upgrade software package, and installing or compiling and verifying the associated package based on the virtual test environment to obtain a first result report specifically includes: Using a preset software package dependency tool, obtaining a software package having an installation dependency relationship and / or a compilation dependency relationship with a sub-package generated by a source package of the upgrade software package from a tool repository for package management in the virtual test environment, and obtaining at least one associated package; Extract binary packages from the associated packages to obtain a binary package list; When the binary packages in the binary package list are installed normally and the sub-packages of the upgraded source packages are not downgraded, all source packages are extracted from the associated packages to obtain a source package list; Using a preset software package source code maintenance tool, obtain the target source code corresponding to the source code package list in a tool repository for package management; The target source code is compiled based on the virtual test environment, and if the compilation is normal, installation and compilation success information is output as a first result report.

4. The method according to claim 1, characterized in that: Install the upgrade package in the pre-built virtual test environment, including: Obtaining a source code package of the upgrade software package, and building a virtual test environment for the source code package based on a pre-selected automated verification tool; In the virtual test environment, the upgrade software package is installed.

5. The method according to claim 4, characterized in that The step of installing the upgrade software package in the virtual test environment specifically includes: Compiling 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.

6. The method according to claim 1, characterized in that The method further comprises: If the installation or compilation fails, a third result report is output; wherein the third result report includes error information.

7. A software package version upgrade result testing device, characterized in that: The device comprises: A first test module is used to obtain an associated package of a source code package of the upgrade software package when the upgrade software package is successfully installed in the pre-built virtual test environment, and to install or compile and verify 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 a sub-package generated by the source code package of the upgrade software package and a source code package having a compilation dependency on a sub-package generated by the source code package of the upgrade software package; The second test module is used to obtain an upgrade package of a previous version of the upgrade package, obtain the difference between the current version of the upgrade package and the previous version of the upgrade package by using a compatibility check tool, and obtain a difference report; The third test module is used to determine an interface list of binary interface changes according to the difference report, and determine a second result report according to the relationship between the interface called by the associated package and the interface list.

8. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the software package version upgrade result testing method according to any one of claims 1 to 6 by executing the computer instructions.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the software package version upgrade result testing method according to any one of claims 1 to 6.

10. A computer program product, characterized in that The method comprises computer instructions, wherein the computer instructions are used to cause a computer to execute the software package version upgrade result testing method according to any one of claims 1 to 6.

Images