A component upgrade adaptation detection method and device

Abstract

This invention provides a component upgrade compatibility detection method and apparatus. The method includes: determining that a component to be upgraded exists in a first software system; wherein the first software system includes dependent components that depend on the component to be upgraded; determining a first call function sequence of the dependent components to the component to be upgraded; the first call function sequence is used to characterize the functions of the component to be upgraded called sequentially by the dependent components; determining whether the state machine of the component to be upgraded has a second call function sequence that matches the first call function sequence; the state machine is obtained by calling and testing the component to be upgraded in software systems that have upgrade incompatibility; if a matching second call function sequence exists, it is determined that the first software system has upgrade incompatibility with the component to be upgraded. This method improves the accuracy of component upgrade compatibility detection and reduces false alarms.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and apparatus for detecting component upgrade compatibility. Background Technology

[0002] In recent years, with the development of computer technology, more and more technologies are being applied in the financial field, and the traditional financial industry is gradually transforming into Fintech. However, due to the security and real-time requirements of the financial industry, higher demands are being placed on technology. For example, in order to ensure the quality of various functions of software systems in the financial industry, the components of the software systems are constantly and rapidly being upgraded.

[0003] A software component is defined as a reusable software unit, a simple encapsulation of data and methods. Software components can be easily applied to assemble applications. Components can have their own properties and methods. Properties are simple accessors to the component's data. Methods are simple, visible functionalities of the component. In programming languages ​​such as Java, C++, and C#, APIs (Application Programming Interfaces) are implemented through the method definitions of "classes" and "interfaces." Software systems are typically composed of multiple interdependent components, mostly developed independently by different teams. If a software system includes component A developed by team 1 and component B developed by team 2, component A will call component B, meaning component A depends on component B. If team 2 iterates and upgrades component B, to ensure the normal operation of the software system, it is necessary to ensure that component A can still call component B normally after the upgrade. Currently, many components are grouped into a third-party library to provide services that can be called externally. Many software developers, to avoid the negative impact of upgrading dependent components on the software system, do not upgrade dependent components in their software systems. However, delayed component upgrades can actually create significant security vulnerabilities.

[0004] To address this issue, research teams have proposed several technical solutions, such as Dependabot (a tool for detecting components in software systems that require updating). Dependabot uses large-scale historical component upgrade data to issue warnings about potential incompatible upgrades. While this method can detect incompatibility issues in some component upgrades, it still experiences a significant number of false alarms.

[0005] Therefore, there is an urgent need for a component upgrade compatibility detection method and device to improve the accuracy of component upgrade compatibility detection and reduce false alarms. Summary of the Invention

[0006] This invention provides a component upgrade compatibility detection method and apparatus to improve the accuracy of component upgrade compatibility detection and reduce false alarms.

[0007] In a first aspect, embodiments of the present invention provide a component upgrade adaptation detection method, the method comprising:

[0008] It is determined that there is a component to be upgraded in the first software system; wherein, the first software system includes dependent components that depend on the component to be upgraded;

[0009] Determine a first sequence of function calls from the dependent component to the component to be upgraded; the first sequence of function calls is used to characterize the functions of the component to be upgraded called sequentially by the dependent component.

[0010] Determine whether the state machine of the component to be upgraded has a second call function sequence that matches the first call function sequence; the state machine is obtained by calling and testing various software systems that are incompatible with the upgrade of the component to be upgraded.

[0011] If a matching second function call sequence exists, it is determined that the first software system is incompatible with the upgrade of the component to be upgraded.

[0012] In the above method, the first software system contains a component to be upgraded, and the first software system includes dependent components that depend on the component to be upgraded. Thus, the software system containing the component to be upgraded can be obtained, and the possibility of upgrade incompatibility issues when upgrading the dependent component to an updated version of the software system can be detected. A first function call sequence from the dependent component to the component to be upgraded is determined; the first function call sequence represents the functions of the component to be upgraded called sequentially by the dependent component. Thus, the characteristics of the function call sequence appearing when the dependent component calls the component to be upgraded can be obtained. It is determined whether the state machine of the component to be upgraded has a second function call sequence that matches the first function call sequence. If a matching second function call sequence exists, it is determined that the first software system has upgrade incompatibility with the component to be upgraded. This is because the state machine is obtained by calling and testing various software systems with upgrade incompatibility with the component to be upgraded. In other words, the state machine contains various function call sequence characteristics that may exist for upgrade incompatibility of the component to be upgraded. Thus, by comparing the matching of the first function call sequence of the dependent component to the component to be upgraded with the second function call sequence in the state machine, it can be determined whether the characteristics of the first function call sequence are closer to the second function call sequence in the state machine. Compared with the existing detection tool Dependabot, which only detects upgrade incompatibility issues based on the interface-related parameters of the component to be upgraded, this application determines whether the component to be upgraded can be upgraded based on the matching of the special properties of the dependent component (function call sequence of the interface) with the characteristics of the updated version component (function call sequence of the interface). This method detects upgrade incompatibility issues based on the characteristics of the dependent component and the updated version component, resulting in higher accuracy.

[0013] Optionally, determining that the first software system has an upgrade incompatibility with the component to be upgraded includes:

[0014] The input and output values ​​of each function in the second call function sequence are obtained through the state machine;

[0015] Based on the input and output values ​​of each function in the second function call sequence, construct the first test case;

[0016] The first test case is run in a second software system, which is a software system upgraded based on the components to be upgraded in the first software system.

[0017] If the first test case fails to run, it is determined that the first software system is incompatible with the upgrade of the component to be upgraded.

[0018] In the above method, after determining that the first function call sequence of the dependent component matches the second function call sequence of the state machine, a first test case is constructed based on the input and output values ​​of each function in the second function call sequence. This first test case is then used to test the second software system obtained after upgrading the component to be upgraded in the first software system. If the first test case fails, it can be determined that the first software system has an upgrade incompatibility issue with the component to be upgraded. Thus, after the first and second function call sequences match, it is considered that the characteristics of the dependent component in the software system are compatible with the characteristics of the failed upgrade of the updated version component, and there is a high probability of an upgrade incompatibility issue. Further verification based on the first test case can save resources and reduce detection efficiency caused by generating corresponding test cases for the compatible software system without performing the matching process.

[0019] Optionally, after the test case fails to run, the method further includes: generating a third function call sequence based on the function calls made by the test case to the updated components of the component to be upgraded during runtime; and updating the state machine through the third function call sequence.

[0020] In the above method, after determining that the component to be upgraded is not suitable for upgrading, that is, the upgrade of the dependent component to the component to be upgraded has an upgrade incompatibility problem, the third call function sequence of the failed execution of the updated version component of the component to be upgraded is updated to the state machine, so that the state machine contains the call function sequences of the updated version component and the dependent components (combined with the updated version component to obtain the components of the software system) with incompatibility characteristics, ensuring the comprehensiveness and accuracy of the state machine.

[0021] Optionally, the first software system is in an online application state; the second software system is obtained by upgrading the components to be upgraded in the offline test version corresponding to the first software system; if the first test case runs successfully, the components to be upgraded in the first software system are upgraded.

[0022] In the above method, to ensure the normal operation of the business, the second software system can be obtained by upgrading the components to be upgraded in the offline test version corresponding to the first software system. Once the first test case runs successfully, the components to be upgraded in the first software system can be upgraded. This prevents the first software system in the online application from potentially causing upgrade failures, rollbacks, or other disruptions to business operations.

[0023] Optionally, the state machine is obtained by calling and testing various software systems that are incompatible with the upgrade component, including:

[0024] Determine the version number pair of the component to be upgraded; the version number pair is the version number before and after the upgrade;

[0025] For any software system with the components to be upgraded, after determining that the software system is incompatible with the upgrade through the second test case, the third function call sequence executed by the second test case and the input and output values ​​of each function in the third function call sequence are obtained;

[0026] The state machine is generated based on the sequence of third function calls, the input and output values ​​of each function in the sequence of third function calls, and the version number pair.

[0027] In the above method, version number pairs containing the version numbers of the component to be upgraded before and after the upgrade are determined. For any software system containing the component to be upgraded, after determining that the software system has upgrade incompatibility through a second test case, the third function call sequence executed by the second test case and the input / output values ​​of each function in the third function call sequence are obtained. Based on each third function call sequence, the input / output values ​​of each function in the third function call sequence, and the version number pairs, a state machine is generated. In this way, it is ensured that more software systems containing the component to be upgraded are obtained, and the components that depend on the component to be upgraded in these software systems are not completely the same. For example, the components that depend on the component to be upgraded in these software systems may come from different developers and different software projects (different components that depend on the component to be upgraded). The third function call sequences of the updated version component in different software projects, the input / output values ​​of each function in the third function call sequence, and the version number pairs are obtained to generate the state machine. In this way, the execution failure characteristics of the updated version component contained in the state machine are more complete.

[0028] Optionally, the state machine is generated based on each third function call sequence, the input / output values ​​of each function in each third function call sequence, and the version number pair, including:

[0029] The version number pair is used as the entry permission condition of the state machine. The third function call sequence and the input and output values ​​of each function in the third function call sequence are integrated to obtain the application state condition of the state machine. The application state condition includes the function call sequence and the input and output values ​​of each function in the updated component due to the incompatibility of the software system upgrade.

[0030] In the above method, version numbers are used as entry conditions for the state machine. This ensures that the obtained state machine corresponds to the component to be upgraded and the updated version component. The application state conditions of the state machine are obtained by integrating the sequence of third function calls and the input / output values ​​of each function within that sequence. This ensures that the state machine contains the function call sequences of the updated component due to incompatibility with software system upgrades, along with the input / output values ​​of each function, improving the accuracy and comprehensiveness of matching the first and second function call sequences.

[0031] Optionally, determining the first function call sequence of the dependent component to the component to be upgraded includes: performing code analysis on the dependent component to determine the first function call sequence of the dependent component to the component to be upgraded.

[0032] In the above method, the first function call sequence of the dependent component to be upgraded can be determined directly by analyzing the code, which speeds up the detection process.

[0033] Secondly, embodiments of the present invention provide a component upgrade and adaptation detection device, the device comprising:

[0034] An acquisition module is used to determine that there is a component to be upgraded in the first software system; wherein, the first software system includes dependent components that depend on the component to be upgraded;

[0035] The detection module is used to determine a first sequence of function calls from the dependent component to the component to be upgraded; the first sequence of function calls is used to characterize the functions of the component to be upgraded called sequentially by the dependent component.

[0036] The detection module is further configured to determine whether the state machine of the component to be upgraded has a second call function sequence that matches the first call function sequence; the state machine is obtained by calling and testing various software systems that are incompatible with the upgrade of the component to be upgraded.

[0037] The detection module is further configured to determine, if a matching second call function sequence exists, that the first software system is incompatible with the upgrade of the component to be upgraded.

[0038] Thirdly, embodiments of this application also provide a computer device, including: a memory for storing a program; and a processor for calling the computer program stored in the memory and executing the method described in various possible designs of the first aspect according to the obtained program.

[0039] Fourthly, embodiments of this application also provide a computer-readable non-volatile storage medium including a computer-readable program that, when read and executed by a computer, causes the computer to perform the method described in various possible designs of the first aspect.

[0040] These or other implementations of this application will become clearer and easier to understand in the following description of the embodiments. Attached Figure Description

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

[0042] Figure 1 This is a schematic diagram of an architecture for component upgrade adaptation detection provided in an embodiment of the present invention;

[0043] Figure 2 A flowchart illustrating a component upgrade and adaptation detection method provided in an embodiment of the present invention;

[0044] Figure 3 A flowchart illustrating a component upgrade and adaptation detection method provided in an embodiment of the present invention;

[0045] Figure 4 A flowchart illustrating a component upgrade and adaptation detection method provided in an embodiment of the present invention;

[0046] Figure 5 This is a schematic diagram of a component upgrade and adaptation detection device provided in an embodiment of the present invention. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0048] Currently, production software systems are typically composed of multiple interdependent components. These components are mostly developed independently by different teams, and a completed component is highly likely to be applied to different software systems. In other words, this component (since upgrading this component can cause software system upgrade incompatibility issues, we will refer to it as the component to be upgraded, and the upgraded component corresponding to it as the updated version component) needs to be usable by various different software systems. This component to be upgraded needs to be callable by dependent components (for ease of explanation, we will refer to these dependent components) in these different software systems. However, the methods used by dependent components in different software systems to implement interface calls to the component to be upgraded are not entirely the same (it should be noted that interface calls between dependent components and the component to be upgraded can be implemented through one or more function calls). Therefore, during the iterative upgrade of the component to be upgraded, detecting whether the updated version component can be called by the corresponding dependent components—and whether there are upgrade incompatibility issues in the software system—has become an important research problem for component developers.

[0049] Upgrades to components can be broadly categorized into two types: changes that affect the API and changes that do not. Changes affecting the API refer to changes in the number or type of parameters required by the API; for example, the original API required integer parameters, while the modified API requires string parameters. Current methods can relatively easily identify changes that affect the API. However, identifying changes that do not affect the API requires sufficient test cases, which many real-world software projects lack.

[0050] Dependabot uses massive amounts of historical upgrade data to warn of potential incompatible upgrades. For example, if a known error occurred during the upgrade of component X corresponding to dependent component A (e.g., before the upgrade, the component X contained a parameter affecting the API with a time limit of 10 minutes; after the upgrade, the updated version of the component contains a parameter affecting the API with a time limit of 5 minutes, causing dependent component A to be unable to correctly call the API parameter of the updated version of component X with a time limit of 5 minutes based on the API parameter of 10 minutes. To further illustrate, the dependent component is a voice acquisition component, and the component to be upgraded is a voice analysis component. The voice acquisition component has its API parameter set to be able to acquire voice with a time limit of 10 minutes, and the voice analysis component has its API parameter set to be able to analyze voice with a time limit of 10 minutes. If the upgraded voice analysis component has its API parameter set to be able to analyze voice with a time limit of 5 minutes, then the upgraded voice analysis component cannot be adapted to the voice acquisition component, and the voice acquisition and analysis software system has an upgrade incompatibility problem. This is just an example and does not limit the specific types of API parameters or their applications), then when the same upgrade is performed on the component X corresponding to dependent component B, Dependabot will issue a warning to dependent component B. However, when dependent component B is not affected by the upgrade data of the component X to be upgraded (in the example above, the API parameter of dependent component B - the voice acquisition module - is set to collect voice with a maximum time limit of 5 minutes), this warning is a false alarm. Consequently, if a large number of dependent components use this method for detection, a large number of false alarms may occur. Such false alarms will significantly increase the maintenance cost for developers, requiring a significant investment of time to confirm whether the warning issue actually occurs in the dependent component. Therefore, further research is needed on the issue of software system upgrade incompatibility.

[0051] Figure 1This invention provides a system architecture for component upgrade compatibility detection, aimed at improving the accuracy of software system upgrade incompatibility detection. The data acquisition module 101, for any software system with a component to be upgraded, after determining through a second test case that the software system has upgrade incompatibility, acquires the third function call sequence executed by the second test case and the input / output values ​​of each function in the third function call sequence, determining the version number pair of the component before and after the upgrade. A state machine is generated based on each third function call sequence, the input / output values ​​of each function in each third function call sequence, and the version number pair. The components in each software system that depend on the component to be upgraded may not be completely identical. The state machine can be updated subsequently; that is, if a software system (including the software system containing the component to be upgraded) is upgraded (i.e., the component to be upgraded is updated to a newer version component) and fails to run under its corresponding test case, indicating an upgrade incompatibility problem, the state machine is updated based on the third function call sequence executed by the software system under its corresponding test case and the input / output values ​​of each function in the third function call sequence. After generating or updating the state machine, the data acquisition module 101 stores the latest state machine in the database 102. It should be noted that the state machine update process can be performed in either the detection module 103 or the data acquisition module 101; no specific restriction is imposed here.

[0052] Database 102 is used to store the state machine acquired by data acquisition module 101. It can also store the third function call sequence corresponding to each software system, the input and output values ​​of each function in the third function call sequence, and related information such as version numbers. There are no specific restrictions on the data stored in database 102.

[0053] The detection module 103 is used to obtain a first software system containing a component to be upgraded, which also includes dependent components that depend on the component to be upgraded. It determines a first function call sequence representing the sequential calls of functions of the component to be upgraded by the dependent components. It then determines the state machine corresponding to the component to be upgraded from the database 102, and further determines whether the state machine contains a second function call sequence that matches the first function call sequence. If a matching second function call sequence exists, the first software system is highly likely to have an upgrade incompatibility issue. Subsequently, it obtains the input and output values ​​of each function in the second function call sequence through the state machine, and constructs a first test case based on these values ​​(this can also be done based on the input and output values ​​of each function in the second function call sequence and the dependent components in the first software system). After upgrading the component to be upgraded in the first software system, a second software system is obtained. A first test case is run in the second software system. If the run is successful, it is determined that the first software system does not have an upgrade incompatibility issue with the component to be upgraded, and the component to be upgraded in the first software system can be upgraded. If the run fails, it proves that the first software system has an upgrade incompatibility issue with the component to be upgraded. Then, based on the function calls in the updated component of the component to be upgraded in the second software system when the first test case fails, a third function call sequence is generated. The state machine is updated using the third function call sequence, and the updated state machine is returned to the database. It should be noted that the state machine update process can be performed in the detection module 103 or the data acquisition module 101; no specific restriction is placed here. To ensure the normal operation of the business in the software system, the component to be upgraded in the offline test version corresponding to the first software system is upgraded to obtain the second software system for testing.

[0054] Based on the above system architecture, embodiments of this application provide a flowchart for a component upgrade and adaptation detection method, such as... Figure 2 As shown, it includes:

[0055] Step 201: Determine that there is a component to be upgraded in the first software system; wherein, the first software system includes dependent components that depend on the component to be upgraded;

[0056] It should be noted here that the first software system can be application software, operating system, mini-program, or client software system that can run based on written code programs. There are no restrictions on the specific type of software system.

[0057] The first software system contains a component to be upgraded and dependent components that depend on the component to be upgraded. For example, the interface calls between the component to be upgraded and the dependent components are realized through a certain sequence of function calls.

[0058] Step 202: Determine the first function call sequence of the dependent component to the component to be upgraded; the first function call sequence is used to characterize the functions of the component to be upgraded called sequentially by the dependent component;

[0059] Here, the first function call sequence can be the call sequence of various functions that the dependent component may be involved in in implementing the interface calls to the component to be upgraded.

[0060] Step 203: Determine whether the state machine of the component to be upgraded has a second call function sequence that matches the first call function sequence; the state machine is obtained by calling and testing various software systems that are not compatible with the upgrade of the component to be upgraded.

[0061] Here, the state machine may contain various second call function sequences, which are obtained by each software system when the upgrade of the component to be upgraded fails. These sequences include the characteristics of the function calls when the upgrade of the component to be upgraded fails (components in each software system that depend on the component to be upgraded cannot successfully call the interface of the updated version of the component to be upgraded).

[0062] Step 204: If a matching second call function sequence exists, it is determined that the first software system is incompatible with the upgrade of the component to be upgraded.

[0063] Here, the matching judgment method can be set as follows: if the matching degree between the first function call sequence and the second function call sequence exceeds the matching degree threshold, it is considered that the first function call sequence has a matching second function call sequence. It can also be key feature matching, etc. There is no specific restriction on the matching judgment method here.

[0064] In the above method, the first software system contains a component to be upgraded, and the first software system includes dependent components that depend on the component to be upgraded. Thus, the software system containing the component to be upgraded can be obtained, and the possibility of upgrade incompatibility issues when upgrading the dependent component to an updated version of the software system can be detected. A first function call sequence from the dependent component to the component to be upgraded is determined; the first function call sequence represents the functions of the component to be upgraded called sequentially by the dependent component. Thus, the characteristics of the function call sequence appearing when the dependent component calls the component to be upgraded can be obtained. It is determined whether the state machine of the component to be upgraded has a second function call sequence that matches the first function call sequence. If a matching second function call sequence exists, it is determined that the first software system has upgrade incompatibility with the component to be upgraded. This is because the state machine is obtained by calling and testing various software systems with upgrade incompatibility with the component to be upgraded. In other words, the state machine contains various function call sequence characteristics that may exist for upgrade incompatibility of the component to be upgraded. Thus, by comparing the matching of the first function call sequence of the dependent component to the component to be upgraded with the second function call sequence in the state machine, it can be determined whether the characteristics of the first function call sequence are closer to the second function call sequence in the state machine. Compared with the existing detection tool Dependabot, which only detects upgrade incompatibility issues based on the interface-related parameters of the component to be upgraded, this application determines whether the component to be upgraded can be upgraded based on the matching of the special properties of the dependent component (function call sequence of the interface) with the characteristics of the updated version component (function call sequence of the interface). This method detects upgrade incompatibility issues based on the characteristics of the dependent component and the updated version component, resulting in higher accuracy.

[0065] Based on the above component compatibility detection method, in step 204, after determining that a matching second call function sequence exists, it is further determined that the first software system has an upgrade incompatibility for the component to be upgraded. Specifically, this may include: obtaining the input and output values ​​of each function in the second call function sequence through the state machine; constructing a first test case based on the input and output values ​​of each function in the second call function sequence; running the first test case in a second software system, wherein the second software system is a software system upgraded based on the component to be upgraded in the first software system; if the first test case fails to run, it is determined that the first software system has an upgrade incompatibility for the component to be upgraded.

[0066] In other words, it is determined that there is a component to be upgraded in the first software system, and the first call function sequence of the dependent components is obtained. After determining that the state machine of the component to be upgraded has a second call function sequence that matches the first call function sequence, it is determined that the first software system is likely to have an upgrade incompatibility problem with the component to be upgraded. To further confirm this and improve the accuracy of the detection results, the input and output values ​​of each function in the second call function sequence are obtained through the state machine. A first test case is constructed based on the input and output values ​​of each function in the second call function sequence (to make the first test case more closely match the characteristics of the dependent components in the first software system, it can be constructed based on the dependent components and the input and output values ​​of each function in the second call function sequence). Then, the first test case is run in the second software system obtained after upgrading the component to be upgraded in the first software system, and the detection results are obtained. If the first test case fails to run, it is determined that the first software system has an upgrade incompatibility problem with the component to be upgraded. Alternatively, the first test case can be generated based on an automated test generation tool. The input and output values ​​of each function in the second call function sequence and the dependent components are input into the automated test generation tool to obtain the first test case output by the automated test generation tool.

[0067] Furthermore, based on the above-described component upgrade adaptation detection method flow, this application embodiment also provides a state machine update method flow, namely, after the test case fails, it further includes: generating a third function call sequence based on the function calls made by the test case to the updated component of the component to be upgraded; and updating the state machine through the third function call sequence. For ease of understanding, the state machine update method flow based on the above-described component upgrade adaptation detection method flow is illustrated as follows: if the first test case fails, the function calls made by the first test case to the updated component of the component to be upgraded (i.e., the updated version component corresponding to the component to be upgraded) are obtained, a third function call sequence is generated, and the state machine is updated through the third function call sequence.

[0068] Here is an example, in conjunction with the above. Figure 1 The architecture and Figure 2 The method flow in the document explains the component upgrade and adaptation methods and architecture, such as... Figure 3 As shown,

[0069] a. The detection module 303 can periodically scan the user-provided software system to identify components that need to be upgraded. For example, there is an existing component that needs to be upgraded, version 1.0.1, and there is also a corresponding updated version 1.0.2 component.

[0070] b. If the version pair (component version 1.0.1 to updated component version 1.0.2) already exists in database 302, then the interface calls of the dependent components in the software system (functions in the code of the dependent components used to call the component to be upgraded, and may also include other related function parameters, etc., which are not specifically restricted here) are matched. During the matching process, it is determined whether the state machine in database 302 corresponding to the component to be upgraded and the updated component (including various second function call sequences involved in the failure of the component to be upgraded) accepts the interface calls of the dependent components.

[0071] Here, the interface call is equivalent to the first function call sequence in the method flow described above. This first function call sequence, contained within the dependent component, is used by the dependent component to implement the interface calls of the component to be upgraded and / or the updated version. It should be noted that the description of the first function call sequence here refers to the function call sequence involved in the interface calls of the component to be upgraded and / or the updated version, for ease of understanding. The component to be upgraded and / or the updated version is designed to implement one or more functionalities, and the dependent component may also contain other related functions or parameters for the interface calls of the component implementing these functionalities (other components besides the component to be upgraded and the updated version that can implement these functionalities). Therefore, the first function call sequence here is not limited to the interface calls of the component to be upgraded and / or the updated version, but is based on the level of code writing in the dependent component (the level of code writing refers to the universality and complexity of the function calls, parameter calls, etc., that the component implementing these functionalities may have). Therefore, there are no specific restrictions on the first function call sequence.

[0072] c. During the matching process, the second function call sequence in the state machine corresponding to the component to be upgraded and the updated version component in database 302 receives the first function call sequence of the dependent component (it can be assumed that the matching similarity between the first function call sequence and the second function call sequence exceeds the matching similarity threshold, where the matching similarity threshold can be adjusted according to actual usage requirements). The software system corresponding to the successfully matched first function call sequence has a potential risk of upgrade incompatibility with the component to be upgraded. In addition, if the detection module 303 determines that the first function call sequence and the second function call sequence fail to match (it can be assumed that the matching similarity between the first function call sequence and the second function call sequence does not exceed the matching similarity threshold), the component to be upgraded in the first software system which is in the online application state is upgraded to the updated version component, so that the second software system is in the online application state. It should be noted here that, in one embodiment, in order to ensure the business operation of the first software system, the first software system can be in the online application state; and the second software system is obtained by upgrading the component to be upgraded in the offline test version corresponding to the first software system. That is to say, no matter how the test is conducted, it will not affect the business processing of the first software system.

[0073] d. Further, the detection module 303 inputs the input / output values ​​of each function in the second function call sequence of the state machine and the code of the dependent components into the automated test generation tool. The automated test generation tool constructs a first test case based on the input / output values ​​of each function in the second function call sequence and the code of the dependent components. (In this way, the characteristics of the dependent components are integrated into the first test case, making the first test case more closely match the running conditions of the dependent components and improving the accuracy of component upgrade incompatibility detection.) The first test case successfully triggers the upgrade incompatibility problem in the second software system (the second software system obtained by upgrading the component to be upgraded in the first software system to the updated version component). That is, the first test case executes successfully in the first software system but fails in the second software system. In addition, if the detection module 303 determines that the first test case executes successfully in the second software system, it upgrades the component to be upgraded in the first software system, which is in the online application state, to the updated version component, so that the second software system is in the online application state.

[0074] e. If the incompatibility issue is successfully confirmed, the detection module 303 updates the state machine according to the interface call (third function call sequence) that failed to run in the second software system based on the first test case, and puts the state machine back into the database 302.

[0075] Based on the above component compatibility detection method, in step 203, before determining whether the state machine of the component to be upgraded has a second call function sequence that matches the first call function sequence, that is, before using the state machine, the method flow may also include a method flow for obtaining the state machine. That is, the state machine is obtained by performing call tests on various software systems with upgrade incompatibility of the component to be upgraded, including: determining the version number pair of the component to be upgraded; the version number pair is the version number before and after the upgrade; for any software system with the component to be upgraded, after determining that the software system has upgrade incompatibility through the second test case, obtaining the third function call sequence executed by the second test case and the input and output values ​​of each function in the third function call sequence; generating the state machine based on each third function call sequence, the input and output values ​​of each function in each third function call sequence and the version number pair. In other words, for a component to be upgraded that has an updated version, multiple software systems containing the component to be upgraded are obtained. After determining that any one of these software systems has an upgrade incompatibility issue through a second test case, the interface call sequence of the second test case that failed to run in that software system—the third function call sequence—and the input and output values ​​of each function in the third function call sequence are obtained. Based on the third function call sequence of the multiple software systems with upgrade incompatibility issues, the input and output values ​​of each function in the third function call sequence, and the version number, a state machine is generated.

[0076] Here is an example, in conjunction with the above. Figure 1 The architecture and Figure 2 The method flow in the document explains the component upgrade and adaptation methods and architecture, such as... Figure 3 As shown,

[0077] a. The data acquisition module 301 acquires a large number of existing unit tests (which can be considered as second test cases) from a software project library (optional open source projects) and includes software systems containing components to be upgraded. The upgrade components in these software systems are upgraded one by one to obtain each software system containing the updated version of the components. The second test cases are run in each software system. If it is found that a software system can successfully run the second test cases before the upgrade, but fails to run the second test cases after the upgrade, then an upgrade incompatibility case is found.

[0078] b. Next, extract the dynamic information of the interface of the updated version component for cases where the upgrade is incompatible.

[0079] The dynamic information of the interface includes: (1) the version pair of the component to be upgraded and the updated version component, such as "(component to be upgraded - 1.0.1, updated version component - 1.0.2)". (2) the dynamic execution trajectory, which includes the sequence of functions called when the test case fails. For example, "obj.m1->obj.m2->obj.m3", where "obj" represents the object involved and "m1, m2, m3" represent the names of the called functions. (3) the intermediate execution state, which includes all parameters and return values ​​of each function before and after it is called in the execution trajectory. For example, "r = obj.m1(2,obj2,'test')", where "2", "obj2", and "test" represent the specific parameter values ​​of the function call and "r" represents the function return value.

[0080] c. Finally, based on the interface dynamic information of the aforementioned software systems (including the third function call sequence of each software system, and the input and output values ​​of each function in the third function call sequence), the dynamic information of multiple interfaces for the same version pair of the component to be upgraded is merged and refined. Multiple third function call sequences, and the input and output values ​​of each function in the third function call sequence, are merged into a single state machine. This state machine will receive all interface calls from the component to be upgraded that conform to the second call sequence (which may be the same as or different from the third function, and there is no specific restriction on the second call sequence) derived from the integration of multiple third function call sequences and the input and output values ​​of each function in the third function call sequence, and will reject calls that do not conform to the second function call sequence. Therefore, the merged multiple third function call sequences, and the input and output values ​​of each function in the third function call sequence, can be used to represent the usage scenario of the component to be upgraded in upgrade incompatibility cases found in dependent components. The data acquisition module 301 stores this state machine in the database 302.

[0081] Based on the above examples, this application also provides a method for obtaining a state machine, namely, generating the state machine based on each third function call sequence, the input and output values ​​of each function in each third function call sequence, and the version number pair, including: using the version number pair as the entry permission condition of the state machine; integrating each third function call sequence and the input and output values ​​of each function in each third function call sequence to obtain the application state condition of the state machine, wherein the application state condition includes the function call sequence generated by the updated component due to the incompatibility of upgrades to various software systems and the input and output values ​​of each function therein. In other words, it is necessary to detect the version number of the upgraded and adapted component; only version numbers that meet the entry permission condition in the state machine are allowed to apply the state machine. The state machine generated by integrating each third function call sequence and the input and output values ​​of each function in each third function call sequence contains application state conditions for multiple second function call sequences; the state machine will only accept the first function call sequence of the dependent component if the first function call sequence in the dependent component corresponding to the upgraded and adapted component matches the application state condition of the second function call sequence of the state machine; otherwise, it will not accept it. Additionally, illustratively, the sequence of first function calls to the component to be upgraded from the aforementioned dependent components can be determined through code analysis of the dependent components.

[0082] Based on the system structure and method flow of the above-described component upgrade adaptation detection, embodiments of this application also provide a component upgrade adaptation detection method, such as... Figure 4 As shown, it includes:

[0083] Step 401: For any software system with components to be upgraded, after determining that the software system is incompatible with the upgrade through the second test case, obtain the third function call sequence executed by the second test case and the input and output values ​​of each function in the third function call sequence.

[0084] Here, the aforementioned software system and the second test case can be obtained from various software project repositories. For example, they can be obtained from external open-source repositories on the public network, such as GitHub, or from internal open-source repositories on the intranet. There are no specific restrictions on the method of obtaining the aforementioned software system.

[0085] Step 402: Use the version number of the component to be upgraded as the entry permission condition of the state machine, integrate the above third function call sequences and the input and output values ​​of each function in the third function call sequences to obtain the application state condition of the state machine. The application state condition includes the function call sequence of the updated component based on the incompatibility of the software system upgrade and the input and output values ​​of each function.

[0086] Step 403: Determine that there is a component to be upgraded in the first software system, and the first software system also includes dependent components that depend on the component to be upgraded.

[0087] Step 404: Analyze the code of the dependent components to determine the first sequence of function calls from the dependent components to the component to be upgraded. This first sequence of function calls represents the functions of the component to be upgraded that are called sequentially by the dependent components. Additionally, the first sequence of function calls may also contain other functions or parameters, that is, functions or parameters of other components that have the same or similar functionality as the component to be upgraded, used to call sequentially.

[0088] Step 405: Determine whether the state machine of the corresponding component to be upgraded has a second call function sequence that matches the first call function sequence.

[0089] Step 406: If no matching second function call sequence exists, proceed to step 407; if a matching second function call sequence exists, proceed to step 408.

[0090] Step 407: Upgrade the components to be upgraded in the first software system that is in the online application state, so that the upgraded second software system is in the online application state.

[0091] Step 408: Obtain the input and output values ​​of each function in the second call function sequence through the state machine, and construct the first test case based on the input and output values ​​of each function in the second call function sequence.

[0092] Step 409: Run the first test case in the second software system, which is the software system after upgrading the components to be upgraded in the first software system.

[0093] Here, the second software system is obtained by upgrading the components to be upgraded in the offline test version corresponding to the first software system.

[0094] Step 410: If the first test case fails to run, proceed to step 411; if the first test case runs successfully, proceed to step 407.

[0095] Step 411: It is determined that the first software system has an upgrade incompatibility problem for the component to be upgraded. Based on the calls to each function in the updated component of the component to be upgraded during the execution of the first test case, a third call function sequence is generated, and the state machine is updated through the third call function sequence.

[0096] It should be noted that the above process steps are not unique. For example, steps 401 and 402 do not need to be executed every time steps 403 to 411 are executed.

[0097] Based on the same concept, embodiments of the present invention provide a component upgrade and adaptation detection device. Figure 5 A component upgrade adaptation detection device is provided in the embodiments of this application, such as Figure 5 The following are examples:

[0098] The acquisition module 501 is used to determine that there is a component to be upgraded in the first software system; wherein, the first software system includes dependent components that depend on the component to be upgraded;

[0099] The detection module 502 is used to determine a first sequence of function calls from the dependent component to the component to be upgraded; the first sequence of function calls is used to characterize the functions of the component to be upgraded called sequentially by the dependent component.

[0100] The detection module 502 is further configured to determine whether the state machine of the component to be upgraded has a second call function sequence that matches the first call function sequence; the state machine is obtained by calling and testing various software systems that are not compatible with the upgrade of the component to be upgraded.

[0101] The detection module 502 is further configured to determine, if a matching second call function sequence exists, that the first software system is incompatible with the upgrade of the component to be upgraded.

[0102] Optionally, the detection module 502 is specifically used to: obtain the input and output values ​​of each function in the second call function sequence through the state machine; construct a first test case based on the input and output values ​​of each function in the second call function sequence; run the first test case in a second software system, wherein the second software system is a software system after upgrading the component to be upgraded in the first software system; if the first test case fails to run, it is determined that the first software system has an upgrade incompatibility with the component to be upgraded.

[0103] Optionally, the detection module 502 is further configured to generate a third function call sequence based on the function calls made to the updated components of the component to be upgraded during the runtime of the test case; and update the state machine using the third function call sequence.

[0104] Optionally, the first software system is in an online application state; the second software system is obtained by upgrading the components to be upgraded in the offline test version corresponding to the first software system; if the first test case runs successfully, the detection module 502 is also used to upgrade the components to be upgraded in the first software system.

[0105] Optionally, the detection module 502 is specifically used to: determine the version number pair of the component to be upgraded; the version number pair is the version number before and after the upgrade; for any software system with the component to be upgraded, after determining that the software system has upgrade incompatibility through the second test case, obtain the third function call sequence executed by the second test case and the input and output values ​​of each function in the third function call sequence; and generate the state machine based on each third function call sequence, the input and output values ​​of each function in each third function call sequence and the version number pair.

[0106] Optionally, the detection module 502 is specifically used to: use the version number pair as the entry permission condition of the state machine; integrate the third function call sequence and the input and output values ​​of each function in the third function call sequence to obtain the application state condition of the state machine; the application state condition includes the function call sequence generated by the updated component based on the incompatibility of each software system upgrade and the input and output values ​​of each function therein.

[0107] Optionally, the detection module 502 is specifically used to perform code analysis on the dependent component and determine the first function call sequence of the dependent component to the component to be upgraded.

[0108] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0109] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0110] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0111] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0112] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method of component upgrade adaptation detection, the method comprising: The method includes: It is determined that there is a component to be upgraded in the first software system; wherein, the first software system includes dependent components that depend on the component to be upgraded; Determine a first sequence of function calls from the dependent component to the component to be upgraded; the first sequence of function calls is used to characterize the functions of the component to be upgraded called sequentially by the dependent component. Determine whether the state machine of the component to be upgraded has a second call function sequence that matches the first call function sequence; the state machine is obtained by calling and testing various software systems that are incompatible with the upgrade of the component to be upgraded. If a matching second function call sequence exists, it is determined that the first software system is incompatible with the upgrade of the component to be upgraded. The state machine is obtained by calling and testing various software systems that are incompatible with the upgrade component, including: Determine the version number pair of the component to be upgraded; the version number pair is the version number before and after the upgrade; For any software system with the components to be upgraded, after determining that the software system is incompatible with the upgrade through the second test case, the third function call sequence executed by the second test case and the input and output values ​​of each function in the third function call sequence are obtained; The state machine is generated based on the sequence of third function calls, the input and output values ​​of each function in the sequence of third function calls, and the version number pair.

2. The method as claimed in claim 1, characterized in that, Determining that the first software system has an upgrade incompatibility with the component to be upgraded includes: The input and output values ​​of each function in the second call function sequence are obtained through the state machine; Based on the input and output values ​​of each function in the second function call sequence, construct the first test case; The first test case is run in a second software system, which is a software system upgraded based on the components to be upgraded in the first software system. If the first test case fails to run, it is determined that the first software system is incompatible with the upgrade of the component to be upgraded.

3. The method as claimed in claim 2, characterized in that, After the test case fails to run, the following also applies: Based on the function calls made to the updated components of the component to be upgraded during the runtime of the test cases, a third function call sequence is generated; The state machine is updated through the third function call sequence.

4. The method as claimed in claim 2, wherein, The first software system is in the online application state; The second software system is obtained by upgrading the components to be upgraded in the offline test version corresponding to the first software system; If the first test case runs successfully, the component to be upgraded in the first software system will be upgraded.

5. The method as claimed in claim 1, wherein, The state machine is generated based on the sequence of third function calls, the input / output values ​​of each function in the sequence of third function calls, and the version number pair, including: The version number pair is used as the entry permission condition of the state machine. The third function call sequence and the input and output values ​​of each function in the third function call sequence are integrated to obtain the application state condition of the state machine. The application state condition includes the function call sequence and the input and output values ​​of each function in the updated component due to the incompatibility of the software system upgrade.

6. The method as described in claim 1, characterized in that, Determining the first sequence of function calls from the dependent components to the component to be upgraded includes: Code analysis is performed on the dependent components to determine the first function call sequence of the dependent components to the component to be upgraded.

7. A component upgrade and adaptation detection device, characterized in that, The device includes: An acquisition module is used to determine that there is a component to be upgraded in the first software system; wherein, the first software system includes dependent components that depend on the component to be upgraded; The detection module is used to determine a first sequence of function calls from the dependent component to the component to be upgraded; the first sequence of function calls is used to characterize the functions of the component to be upgraded called sequentially by the dependent component. The detection module is further configured to determine whether the state machine of the component to be upgraded has a second call function sequence that matches the first call function sequence; the state machine is obtained by calling and testing various software systems that are incompatible with the upgrade of the component to be upgraded. The detection module is further configured to determine, if a matching second call function sequence exists, that the first software system is incompatible with the upgrade of the component to be upgraded. The detection module is specifically used to determine the version number pair of the component to be upgraded; the version number pair is the version number before and after the upgrade. For any software system with the components to be upgraded, after determining that the software system is incompatible with the upgrade through the second test case, the third function call sequence executed by the second test case and the input and output values ​​of each function in the third function call sequence are obtained; The state machine is generated based on the sequence of third function calls, the input and output values ​​of each function in the sequence of third function calls, and the version number pair.

8. A computing device, characterized in that, include: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the method according to any one of claims 1 to 6.

9. A computer-readable non-volatile storage medium, characterized in that, Includes computer-readable instructions that, when read and executed by a computer, cause the computer to perform the method as described in any one of claims 1 to 6.

Images