Dependency graph generation method, risk assessment method, device, equipment and medium

Abstract

The present application provides a method for generating a dependency graph, a risk assessment method, an apparatus, a device, and a medium, and relates to the field of software engineering technology. The method for generating a dependency graph includes: parsing a first data set of a target software product to determine a first node set and initial dependencies between nodes in the first node set, wherein the first data set represents business logic data used to run the target software product; generating an initial dependency graph of the target software product based on the first node set and the initial dependencies; parsing a second data set of the target software product to determine a second node set and actual dependencies between nodes in the second node set, wherein the second data set represents business test data generated by the target software product during testing; and updating the initial dependency graph using the second node set and the actual dependencies to obtain a dependency graph of the target software product.

Description

Technical Field

[0001] The present application relates to the field of software engineering technology, and more specifically, to a dependency graph generation method, risk assessment method, apparatus, device, medium, and program product. Background Art

[0002] With the development of internet technology and the continuous growth of business demands, the complexity and scale of modern software products are increasing, which in turn complicates the dependencies between their components. When modifying the code of a software product, the scope of the modification must be strictly controlled to avoid introducing other issues. Therefore, it is essential to build a dependency graph for software products to identify the dependencies between their components.

[0003] In related technologies, the establishment of dependency graphs mainly relies on static code parsing tools to parse the code and obtain the explicit dependency relationships in the code. The dependency graphs established in this way are relatively simple, and the coverage and accuracy of the dependency graphs need to be improved. Summary of the Invention

[0004] In view of this, the present application provides a method for generating a dependency graph, a risk assessment method, an apparatus, a device, and a medium.

[0005] One aspect of the present application provides a method for generating a dependency graph, the method comprising: parsing a first data set of a target software product to determine a first node set and initial dependency relationships between nodes in the first node set, the first data set representing business logic data used to run the target software product; generating an initial dependency graph of the target software product based on the first node set and the initial dependency relationships; parsing a second data set of the target software product to determine a second node set and actual dependency relationships between nodes in the second node set, the second data set representing business test data generated during the testing of the target software product; and updating the initial dependency graph using the second node set and the actual dependency relationships to obtain a dependency graph of the target software product.

[0006] Another aspect of the present application provides a risk assessment method for code changes, including: determining a node to be modified of the code to be changed based on the code to be changed of a target software product; determining at least one associated node that has a dependency relationship with the node to be modified from a dependency graph based on the node to be modified; performing a change risk assessment on the code to be changed based on the number of links and link lengths related to the associated nodes in the dependency graph to obtain a risk assessment result, where the number of links is the total number of links associated with the associated nodes in the dependency graph, and the link length is the total number of nodes contained in the link where the associated node is located; the dependency graph is generated based on the above-mentioned dependency graph generation method.

[0007] Another aspect of the present application provides a dependency graph generation device, comprising: a first parsing module; used to parse a first data set of a target software product to determine a first node set and initial dependency relationships between nodes in the first node set, wherein the first data set represents business logic data used to run the target software product; a generation module, used to generate an initial dependency graph of the target software product based on the first node set and the initial dependency relationships; a second parsing module, used to parse a second data set of the target software product to determine a second node set and actual dependency relationships between nodes in the second node set, wherein the second data set represents business test data generated by the target software product during testing; and an update module, used to update the initial dependency graph using the second node set and the actual dependency relationships to obtain a dependency graph of the target software product.

[0008] Another aspect of the present application provides a risk assessment device for code changes, including: a first determination module, used to determine the node to be modified of the code to be changed based on the code to be changed of the target software product; a second determination module, used to determine at least one associated node that has a dependency relationship with the node to be modified from a dependency graph based on the node to be modified; an assessment module, based on the number of links related to the associated nodes in the dependency graph and the link length, performs a change risk assessment on the code to be changed to obtain a risk assessment result, wherein the number of links is the total number of links associated with the associated nodes in the dependency graph, and the link length is the total number of nodes contained in the link where the associated node is located; wherein the dependency graph is generated based on the above-mentioned dependency graph generation method.

[0009] Another aspect of the present application provides an electronic device, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the above method.

[0010] Another aspect of the present application further provides a computer-readable storage medium having a computer program or instructions stored thereon, which implements the steps of the above method when the computer program or instructions are executed by a processor.

[0011] Another aspect of the present application further provides a computer program product, including a computer program or instructions, which implement the steps of the above method when the computer program or instructions are executed by a processor.

[0012] According to the technical solution of the present application, by parsing static business logic data, a first node set and initial dependency relationships are obtained, and an initial dependency graph is established. Dynamic business test data is then parsed to obtain a second node set and actual dependency relationships. The initial dependency graph is then updated using the second node set and actual dependency relationships to obtain a dependency graph. This not only improves the coverage of the dependency graph, but also verifies and updates the initial dependency relationships in the initial dependency graph, thereby improving the accuracy of the dependency graph. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The above contents and other objects, features and advantages of the present application will become more apparent through the following description of the embodiments of the present application with reference to the accompanying drawings.

[0014] Figure 1 A system architecture diagram of a dependency graph generation method according to an embodiment of the present application is shown.

[0015] Figure 2 A flowchart of a dependency graph generation method according to an embodiment of the present application is shown.

[0016] Figure 3 A flowchart of a dependency graph generation method according to another embodiment of the present application is shown.

[0017] Figure 4 A flowchart of a dependency graph generation method according to another embodiment of the present application is shown.

[0018] Figure 5 A flowchart of a code change risk assessment method according to an embodiment of the present application is shown.

[0019] Figure 6 A module diagram of a dependency graph generating device according to an embodiment of the present application is shown.

[0020] Figure 7 A module diagram of a code change risk assessment device according to an embodiment of the present application is shown.

[0021] Figure 8 A block diagram of an electronic device suitable for implementing the method described above according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0022] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present application. In the detailed description below, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present application. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessarily confusing the concepts of the present application.

[0023] The terms used herein are only for describing specific embodiments and are not intended to limit the present application. The terms "comprise," "include," etc. used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0024] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0025] When expressions such as "at least one of A, B, and C, etc." are used, they should generally be interpreted in accordance with the meaning commonly understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0026] Figure 1 A system architecture diagram of a dependency graph generation method according to an embodiment of the present application is shown.

[0027] like Figure 1 As shown, the system architecture according to this embodiment may include a data collection device 110 , a computing server 120 , a storage device 130 and an application device 140 .

[0028] The data collection device 110 is used to collect multi-source data required to generate the dependency graph, such as business logic data, business test data, etc. The data collection device 110 can transmit the collected data to the computing server 120 via the network.

[0029] The computing server 120 is used to receive data collected from the data collection device 110 and analyze and process the collected data, such as parsing business logic data and salesperson test data and generating a dependency graph. The computing server 120 can transmit the generated dependency graph to the storage device 130 via the network.

[0030] Storage device 130 is used to store the dependency graph generated by computing server 120 and supports computing server 120 in accessing and updating the generated dependency graph. Storage device 130 may include a disk array, distributed storage system, or other storage device. Storage device 130 may transmit the stored dependency graph to application device 140 via a network.

[0031] The application device 140 is used to visualize the dependency graph stored in the storage device 130 .

[0032] Figure 1 The system architecture shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0033] Figure 2 A flowchart of a dependency graph generation method according to an embodiment of the present application is shown.

[0034] like Figure 2 As shown, the method includes operations S210 to S240.

[0035] In operation S210 , a first data set of a target software product is parsed to determine a first node set and initial dependencies between nodes in the first node set, where the first data set represents business logic data for running the target software product.

[0036] In operation S220 , an initial dependency graph of the target software product is generated based on the first node set and the initial dependency relationship.

[0037] In operation S230 , a second data set of the target software product is parsed to determine a second node set and true dependencies between nodes in the second node set, where the second data set represents business test data generated during the testing process of the target software product.

[0038] In operation S240 , the initial dependency graph is updated using the second node set and the real dependency relationship to obtain a dependency graph of the target software product.

[0039] For example, the first data set may include business logic data such as configuration file data and source code data. Parsing the first data set refers to the process of reading, understanding, disassembling, extracting, and organizing information from the first data set to determine the dependencies between nodes in the first data set.

[0040] The first node set includes multiple types of nodes, such as function nodes, class nodes, and module nodes, etc. Based on the different node types, different types of nodes also have different types of dependency relationships.

[0041] For example, the dependencies between function nodes include call dependencies, parameter passing dependencies, global variable dependencies, etc. For another example, the dependencies between class nodes include inheritance dependencies, composition dependencies, and association dependencies. For another example, the dependencies between module nodes include import dependencies, interface dependencies, and circular dependencies.

[0042] For example, a unique node identifier and label can be created for each identified node, and node attributes can be recorded. For each identified dependency, a directed edge is established between the two nodes, and the dependency type is marked. By combining all nodes and directed edges, the initial dependency graph of the target software product is obtained.

[0043] For example, multiple types of initial dependency subgraphs can be established based on different types of nodes, such as function initial dependency subgraphs, class initial dependency subgraphs, module initial dependency subgraphs, etc. By combining multiple initial dependency subgraphs, the initial dependency graph of the target software product is obtained.

[0044] The second data set can be various business test data acquired using monitoring tools during manual and automated testing of the target software product. Business test data can include, for example, software operation data, operational data generated by user operations, database table call data, microservice call data, etc.

[0045] The second node set obtained by parsing the second data set includes not only the nodes present in the first node set, but also nodes not present in the first node set. The second node set represents the set of nodes actually involved in the business operation. Based on the actual call and transfer dependencies between the nodes during business operation, the initial dependencies can be verified and the implicit dependencies between the nodes can be obtained.

[0046] For example, the second node set includes not only function nodes, class nodes, and module nodes, but also element parameter nodes, database table nodes, and service nodes.

[0047] Since static business logic data can only be parsed to reveal the dependencies displayed by each node, it cannot identify the dependencies dynamically generated by the target software at runtime, such as temporary calls between different services and database read and write paths. This reduces the coverage of the dependency graph. Furthermore, when parsing business logic data, the initial dependency graph may be inconsistent with actual operational status due to issues such as false positives or false negatives, or version inconsistencies caused by version updates. This reduces the accuracy of the initial dependency graph.

[0048] According to an embodiment of the present application, by parsing static business logic data, a first node set and initial dependency relationships are obtained, and an initial dependency graph is established. Dynamic business test data is then parsed to obtain a second node set and actual dependency relationships. The initial dependency graph is then updated using the second node set and actual dependency relationships to obtain a dependency graph. This not only improves the coverage of the dependency graph, but also verifies and updates the initial dependency relationships in the initial dependency graph, thereby improving the accuracy of the dependency graph.

[0049] According to an embodiment of the present application, the first data set may include source code and configuration files. Parsing the first data set of the target software product to determine the first node set and the initial dependency relationships between the nodes in the first node set may include: parsing the source code based on a code parsing tool that matches the language type of the source code to obtain a third node set and the initial dependency relationships between the nodes in the third node set. Parsing the configuration file based on a configuration file parsing tool that matches the format of the configuration file to obtain a fourth node set and the initial dependency relationships between the nodes in the fourth node set. Fusing the third node set, the initial dependency relationships between the nodes in the third node set, and the fourth node set, the initial dependency relationships between the nodes in the fourth node set to obtain the first node set and the initial dependency relationships between the nodes in the first node set.

[0050] For source code, the programming language of the source code can be identified first. Different tools are used to parse the source code for different coding languages, and the source code is parsed into an abstract syntax tree. The abstract syntax tree can be traversed to record the declarative nodes in the abstract syntax tree, such as function nodes, class nodes, and module nodes. Non-declarative nodes in the abstract syntax tree, such as code comments and blank lines, can be filtered out. The calling relationship between nodes can be determined by identifying keywords in the abstract syntax. For example, within the method body of function A, the call statement B.process keyword to function B can be searched to identify the calling dependency between function nodes; and the extends keyword in the class declaration can be examined to identify the inheritance dependency between class nodes.

[0051] Select a configuration file parsing tool based on the configuration file format. Use the parsing tool to parse the configuration file into a dictionary, tree, or other structure. Traverse the parsed structure and extract all configuration nodes to form a fourth node set. Analyze the hierarchical and reference relationships between configuration nodes to construct the initial dependencies of the fourth node set.

[0052] The third node set and the fourth node set may be merged into the first node set. The initial dependency relationship of the third node set and the initial dependency relationship of the fourth node set may be merged to generate the initial dependency relationship of the first node set. In addition, if there is a node in the third node set that has a dependency relationship with the fourth node set, the node dependency relationship across the sets may be supplemented.

[0053] According to an embodiment of the present application, by fusing the node sets of the source code and the configuration file and their initial dependencies, the fused dependencies can include not only the dependencies within the code and the configuration file, but also the dependencies between the configuration parameters and the source code, making the static analysis more comprehensive and improving the integrity of the initial dependency graph.

[0054] According to an embodiment of the present application, the second data set includes a test log. Parsing the second data set of the target software product to determine the second node set and the true dependency relationships between the nodes in the second node set may include: parsing interfaces and functions in the test log to obtain target verification nodes for verifying the initial dependency graph and the true dependency relationships between the target verification nodes. Parsing element parameters, database tables, and service calls in the test log to obtain target supplementary nodes for supplementing the initial dependency graph and the true dependency relationships between the target supplementary nodes.

[0055] For example, a monitoring tool can be installed in the test environment of the target software product and used to collect logs generated by manual and automated testing. Test logs can include various types, such as the target software product's operation logs, business logs generated by user operations, database table query logs and transaction logs, and microservice service logs.

[0056] Test logs can record interface call information. Interfaces define how modules and classes interact with each other. By parsing interfaces in test logs, you can determine the dependencies between modules and between classes.

[0057] Test logs record function calls and execution results. Functions are the basic unit of program execution, and functions often have dependencies. By parsing the function call information in test logs, you can determine the calling relationships and dependency paths between functions.

[0058] By parsing the interfaces and functions in the test log, we can obtain the real dependency relationships between the function nodes, class nodes, and module nodes of the target software product during operation. Since the initial dependency graph also records the initial dependency relationships between the corresponding function nodes, class nodes, and washing machine module nodes, the target verification node used to verify the initial dependency graph and the real dependency relationship between the target verification node can be obtained based on the real dependency relationships between the function nodes, class nodes, and module nodes.

[0059] An element parameter is the name of a parameter whose value is passed when a function or method is called. It can include both input and output parameters. All element parameters on the target software product can be used as nodes to establish dependency relationships.

[0060] For example, if a software product has an expand button, and the number of machines in the resource group increases after expansion, there is a dependency relationship between the expand button and the number of machines. By recording the paths and changes in element parameter transfer, we can supplement the initial dependency graph with details about data flow and parameter transfer, making the dependency relationship more precise.

[0061] The query log and transaction log of the database table can record changes when the database table is accessed or modified during the test. For example, data storage, query, update, and delete operations. The service log of the microservice can record the interaction information between different services during the test, such as request and response information. Changes to the database table can supplement the dependencies on data storage and access in the initial dependency graph. The interaction information between different services can supplement the dependencies on service calls in the initial dependency graph.

[0062] According to the embodiments of the present application, by parsing the interfaces and functions in the test log, the target verification node used to verify the initial dependency graph and the actual dependency relationship of the target verification node can be obtained, ensuring that the logical structure reflected by the initial dependency graph is consistent with the actual operation situation; at the same time, in-depth analysis of the element parameters, database tables and service calls in the test log can be performed to obtain target supplementary nodes not covered by the initial dependency graph, thereby comprehensively supplementing the initial dependency graph and improving the integrity of the dependency graph.

[0063] Figure 3 A flowchart of a method for generating a dependency graph according to another embodiment of the present application is shown.

[0064] like Figure 3 As shown, by parsing the source code 301, a third node set 304 and the initial dependency relationship 305 of each node in the third node set can be obtained. By parsing the configuration file 302, a fourth node set 306 and the initial dependency relationship 307 of each node in the fourth node set can be obtained.

[0065] By fusing the third node set 304 and the fourth node set 306, a first node set 312 is obtained. By fusing the initial dependency relationships 305 of the nodes in the third node set and the initial dependency relationships 307 of the nodes in the fourth node set, an initial dependency relationship 313 of the nodes in the first node set is obtained. Using the first node set 312 and the initial dependency relationships 313 of the nodes in the first node set, an initial dependency graph 314 is generated.

[0066] By parsing the test log 303 , the target verification node 308 , the target verification node's real dependency relationship 309 , the target supplementary node 310 , and the target supplementary node's real dependency relationship 311 can be obtained.

[0067] The initial dependency graph 314 is verified using the target verification node 308 and its actual dependency relationships 309. Based on the verification results, invalid initial dependencies are deleted and replaced with modified ones. The initial dependency graph 314 is supplemented using the target supplement node 310 and its actual dependency relationships 311, ultimately resulting in a dependency graph 315. This improves the coverage and accuracy of the dependency graph.

[0068] According to an embodiment of the present application, using the second node set and the real dependency relationship, the initial dependency graph is updated to obtain the dependency graph of the target software product, which may include: obtaining a target verification node from the second node set, the target verification node being the same node in the second node set as the first node set; based on the real dependency relationship of the target verification node, the initial dependency relationship of the target verification node is verified to obtain a verification result; based on the verification result, the initial dependency graph is updated to obtain a dependency graph.

[0069] Exemplarily, accurate matching of target verification nodes in the first node set and the second node set may be achieved based on the unique identifiers of the nodes.

[0070] Optionally, during the code writing process, parameter naming rules can be standardized so that the same parameter is named the same for both input and output parameters of all functions, so as to accurately identify the dependencies between function calls and the dependencies between elements of the software product.

[0071] When there is a naming inconsistency, fuzzy matching can be used to match the target verification nodes in the first node set and the second node set.

[0072] Optionally, a feature vector can be constructed based on the target verification node's node attribute information, which can include information such as service function descriptions, subsystems, and interfaces. Secondly, the names of the target verification nodes to be matched are standardized using a predefined naming rule library. A similarity algorithm (such as edit distance or cosine similarity) is used to calculate the feature matching degree of the target verification nodes in the standardized first and second node sets. If the matching degree exceeds a threshold (e.g., 90%), the nodes are determined to be the same.

[0073] After determining the target verification node, the initial dependency relationships of the target verification node can be verified. The verification result is determined based on whether the initial dependency relationships are consistent with the actual dependency relationships. If the initial dependency relationships are consistent with the actual dependency relationships, the initial dependency relationships are considered valid and are retained in the initial dependency graph. If they are inconsistent, the initial dependency relationships in the initial dependency graph are updated to obtain the dependency graph of the target software product.

[0074] According to the embodiments of the present application, the initial dependency relationship is verified using the actual dependency relationship of the target verification node, and the initial dependency graph is updated based on the verification results. This can obtain a dependency graph that conforms to the actual situation and accurately reflects the dependency relationship between nodes, thereby providing a solid and reliable data foundation for subsequent analysis and decision-making tasks based on the dependency graph.

[0075] According to an embodiment of the present application, updating the initial dependency graph based on the verification result may include: if the verification result indicates that the initial dependency of the target verification node is an invalid dependency, deleting the initial dependency from the initial dependency graph. The invalid dependency indicates that the initial dependency does not exist during the operation of the target software product.

[0076] For example, when the initial dependency graph shows that two target verification nodes have a dependency relationship, but through log analysis it is found that there is no dependency relationship such as data interaction, method call, etc. between the two target verification nodes, it means that the initial dependency relationship between the two target verification nodes may be an invalid dependency relationship.

[0077] For example, in the initial dependency graph, module A depends on both module B and module C, resulting in two initial dependency relationships: A→B and A→C. Test log analysis reveals that module A doesn't actually require any functionality or services provided by module B. There's no actual data exchange, method calls, or other dependency behaviors between modules A and B. This means the initial dependency relationship between modules A and B is invalid. Therefore, the initial dependency relationship A→B can be deleted from the initial dependency graph, while retaining the A→C relationship.

[0078] According to an embodiment of the present application, updating the initial dependency graph based on the verification result may include: when the verification result indicates that the initial dependency of the target verification node has changed, replacing the initial dependency relationship with the real dependency relationship of the target verification node in the initial dependency graph.

[0079] For example, when the initial dependency graph shows that there is a dependency relationship between the first target verification node and the second target verification node, and log analysis finds that the dependency path between the first target verification node and the second target verification node has changed, it means that the initial dependency has changed.

[0080] For example, in the initial dependency graph, module A can directly call specific functions in module B to obtain data, indicating an initial dependency relationship of A→B. However, due to version adjustments, an intermediate module C was introduced. Module A now indirectly obtains data generated by module B by calling intermediate module C. Log analysis revealed that the initial dependency relationship A→B between target validators A and B has changed, and the actual dependency relationship is now A→C→B, where A→C and C→B are the actual dependencies between target validators A, B, and C. Therefore, the initial dependency graph can be updated, deleting the original A→B dependency and adding the actual dependencies A→C and C→B.

[0081] According to the embodiments of the present application, when the initial dependency is found to be invalid, it is deleted in time to remove redundant and inaccurate dependency information in the graph; when the initial dependency changes, it is replaced with the real dependency, which enables the dependency graph to accurately reflect the actual dependency of the target software product.

[0082] According to an embodiment of the present application, the initial dependency graph is updated using the second node set and the real dependency relationship between each node in the second node set to obtain a dependency graph, including: obtaining a target supplementary node from the second node set, the target supplementary node being a node in the second node set that is different from the first node set; adding the target supplementary node and the real dependency relationship of the target supplementary node to the initial dependency graph to obtain a dependency graph.

[0083] All nodes other than the target verification node in the second node set can be used as target supplementary nodes. If the type of the target supplementary node already exists in the first node set, the target supplementary node and its real dependencies can be added to the initial dependency subgraph of that type based on the real dependencies. If the type of the target supplementary node does not exist in the first node set, an initial dependency subgraph of that type can be established based on all target supplementary nodes of that type and their real dependencies. A dependency graph is obtained based on the initial dependency subgraphs of all types.

[0084] For example, you can set different edge colors for different types of dependencies. For example, call dependencies can be displayed in orange, read-write dependencies can be displayed in blue, and so on. Visualization tools can be used to display dependency graphs in detail, and support displaying different types of dependency subgraphs based on node type, such as function dependency subgraphs and element parameter dependency subgraphs.

[0085] According to an embodiment of the present application, by updating the initial dependency graph through target supplementary nodes and their real dependency relationships, various types of dependencies dynamically generated during the runtime of the target software product can be supplemented, thereby improving the coverage of the dependency graph.

[0086] According to an embodiment of the present application, after updating the initial dependency graph using the second node set and the actual dependency relationships to obtain the dependency graph of the target software product, the method may further include: inputting the dependency graph and the pending nodes into a dependency prediction model, outputting predicted nodes that have dependencies with the pending nodes, and outputting predicted dependencies between the pending nodes and the predicted nodes. The pending nodes are service nodes that were not tested during the testing process; and if the predicted dependencies are determined to be valid, adding the predicted dependencies to the dependency graph.

[0087] The dependency prediction model can be trained using a graph neural network. The present application is not limited thereto, and the dependency prediction model can also be a graph attention network, a Transformer-based graph model, etc.

[0088] For example, a historical dependency graph can be obtained, and some nodes can be randomly or strategically selected as sample nodes to be processed. The actual dependencies in the historical dependency graph are used as labels to train a graph neural network to obtain a dependency prediction model. After training, the dependency prediction model is deployed in a test environment. The dependency graph of the current target software product and the nodes to be tested are input, and the predicted nodes and predicted dependencies are output.

[0089] After obtaining the predicted nodes and predicted dependencies, the predicted dependencies can be verified, for example, by manually annotating the prediction results. If the predicted dependencies are true and valid, the predicted dependencies are added to the initial dependency graph; if the predicted dependencies are invalid, they are discarded.

[0090] According to the embodiments of the present application, due to the relatively complex architecture or large scale of the target software product, not all services can be tested during the testing process. Therefore, the true dependencies of the service nodes of untested services cannot be reflected in the dependency graph. Therefore, using the dependency prediction model to predict the dependencies of untested service nodes can further supplement the dependency graph and reduce the risk of missed nodes.

[0091] Figure 4 A flowchart of a dependency graph generation method according to another embodiment of the present application is shown.

[0092] like Figure 4 As shown, the first data set 401 is parsed to obtain a first node set 312 and initial dependency relationships 313 between the nodes in the first node set. An initial dependency graph 314 is generated based on the first node set 312 and initial dependency relationships 313 between the nodes in the first node set.

[0093] The second data set 402 is parsed to obtain a second node set 403 and an initial dependency relationship 404 of each node in the second node set. Based on the initial dependency relationship 404 of each node in the second node set 403, the initial dependency graph 314 is updated to obtain a dependency graph 315.

[0094] Dependency graph 315 and node to be processed 405 are input into dependency prediction model 406, which outputs predicted node 407 and predicted dependency relationship 408 of the predicted node. If predicted dependency relationship 408 of the predicted node is determined to be a valid dependency relationship, dependency graph 315 is supplemented based on predicted node 407 and predicted dependency relationship 408 of the predicted node.

[0095] According to the embodiments of the present application, by combining static business logic data, dynamic business test data and dependency prediction model prediction, a dependency graph of the target software product is constructed, which can more comprehensively cover the nodes involved in the target software product and further improve the comprehensiveness of the dependency graph.

[0096] Figure 5 A flowchart of a code change risk assessment method according to an embodiment of the present application is shown.

[0097] like Figure 5 As shown, the method includes operations S510 to S530.

[0098] In operation S510 , based on the code to be changed of the target software product, a node to be modified of the code to be changed is determined.

[0099] In operation S520 , based on the node to be modified, at least one associated node having a dependency relationship with the node to be modified is determined from a dependency graph.

[0100] In operation S530, based on the number of links and link lengths related to the associated node in the dependency graph, a change risk assessment is performed on the code to be changed to obtain a risk assessment result. The number of links is the total number of links associated with the associated node in the dependency graph, and the link length is the total number of nodes included in the link where the associated node is located.

[0101] According to an embodiment of the present application, the dependency graph may be generated through the method of operations S210 to S240 .

[0102] For example, a search can be performed in the dependency graph based on the node to be modified. Graph traversal algorithms, such as depth-first search or breadth-first search, can be used to find nodes directly or indirectly associated with the node to be modified. Starting from the node to be modified, the dependency edges can be traversed, recording all visited nodes.

[0103] For each associated node, count the total number of links associated with it in the dependency graph. A link is a path from the associated node to other nodes along the dependency edges. For example, if associated node A depends on nodes B and C, there are two links associated with associated node A: A→B and A→C.

[0104] Calculate the total number of nodes on the link where the associated node is located. For example, for a link A→B→C, the link length is 3 (including nodes A, B, and C). You can find the link length by traversing all nodes on the link.

[0105] For example, risk assessment indicators can be defined based on the number and length of links. For example, a greater number of links indicates a higher degree of dependency on other nodes, a wider range of potential impacts of code changes, and a greater risk. A longer link length indicates a more complex dependency relationship, making the potential chain reaction of changes more difficult to predict and thus increasing the risk.

[0106] Alternatively, a weighted scoring approach can be used to establish a risk assessment model. Weights are assigned to the number and length of links, respectively. A risk score is then calculated based on the number and length of links associated with the node. The risk level of the code change is determined based on the risk score's range, such as low risk, medium risk, or high risk.

[0107] According to the embodiments of the present application, after determining the node to be modified based on the target software code to be changed, the associated nodes that are dependent on it are mined from the dependency graph, and the change risk assessment is carried out based on the number and length of links of the associated nodes in the dependency graph. This can more accurately and comprehensively quantify the possible impact of the code to be changed, identify high-risk change areas in advance, provide scientific risk warnings for developers, and assist in formulating more reasonable change plans.

[0108] Figure 6 A module diagram of a dependency graph generating device according to an embodiment of the present application is shown.

[0109] like Figure 6As shown, the dependency graph generating device 600 includes a first parsing module 610 , a generating module 620 , a second parsing module 630 and an updating module 640 .

[0110] The first parsing module 610 is configured to parse a first data set of the target software product to determine a first node set and initial dependencies between nodes in the first node set, wherein the first data set represents business logic data for running the target software product.

[0111] The generating module 620 is configured to generate an initial dependency graph of the target software product based on the first node set and the initial dependency relationship.

[0112] The second parsing module 630 is used to parse the second data set of the target software product to determine the second node set and the real dependency relationship between the nodes in the second node set. The second data set represents the business test data generated by the target software product during the testing process.

[0113] The updating module 640 is configured to update the initial dependency graph using the second node set and the real dependency relationship to obtain a dependency graph of the target software product.

[0114] According to an embodiment of the present application, the update module 640 includes an acquisition submodule, a verification submodule, and an update submodule.

[0115] The first acquisition submodule is used to acquire a target verification node from the second node set, where the target verification node is the same node in the second node set as that in the first node set.

[0116] The verification submodule is used to verify the initial dependency relationship of the target verification node based on the real dependency relationship of the target verification node to obtain a verification result.

[0117] The update submodule updates the initial dependency graph based on the verification results to obtain a dependency graph.

[0118] According to an embodiment of the present application, the update submodule includes a deletion unit and a replacement unit.

[0119] The deletion unit is used to delete the initial dependency in the initial dependency graph when the verification result indicates that the initial dependency of the target verification node is an invalid dependency. The invalid dependency indicates that the initial dependency does not exist during the operation of the target software product.

[0120] The replacement unit is used to replace the initial dependency relationship with the real dependency relationship of the target verification node in the initial dependency graph when the verification result indicates that the initial dependency of the target verification node has changed.

[0121] According to an embodiment of the present application, the updating module 640 includes a second acquiring submodule and a supplementing submodule.

[0122] The second acquisition submodule is configured to acquire a target supplementary node from the second node set, where the target supplementary node is a node in the second node set that is different from the first node set.

[0123] The supplement submodule is used to add the target supplement node and the real dependency relationship of the target supplement node to the initial dependency graph to obtain the dependency graph.

[0124] According to an embodiment of the present application, the first data set includes source code and configuration files; the first parsing module 610 includes a first parsing sub-module, a second parsing sub-module and a fusion sub-module.

[0125] The first parsing submodule is configured to parse the source code based on a code parsing tool that matches the language type of the source code to obtain a third node set and initial dependency relationships between nodes in the third node set.

[0126] The second parsing submodule is configured to parse the configuration file based on a configuration file parsing tool that matches the format of the configuration file to obtain a fourth node set and initial dependency relationships between nodes in the fourth node set.

[0127] The fusion submodule is used to fuse the third node set and the initial dependency relationship between each node in the third node set with the fourth node set and the initial dependency relationship between each node in the fourth node set to obtain the first node set and the initial dependency relationship between each node in the first node set.

[0128] According to an embodiment of the present application, the second data set includes a test log; the second parsing module 630 includes a third parsing submodule and a fourth parsing submodule.

[0129] The third parsing submodule is used to parse the interfaces and functions in the test log to obtain the target verification node and the real dependency relationship of the target verification node for verifying the initial dependency graph.

[0130] The fourth parsing submodule is used to parse the element parameters, database tables and service calls in the test log to obtain the target supplementary nodes used to supplement the initial dependency graph and the real dependency relationships between the target supplementary nodes.

[0131] According to an embodiment of the present application, the dependency graph generating device 600 further includes a prediction module and a supplementation module.

[0132] The prediction module is used to input the dependency graph and the nodes to be processed into the dependency prediction model, and output the predicted nodes that have a dependency relationship with the nodes to be processed and the predicted dependency relationship between the nodes to be processed and the predicted nodes, wherein the nodes to be processed are business nodes that have not been tested during the test process.

[0133] The supplement module is used to supplement the predicted dependency relationship between target nodes into the dependency graph when it is determined that the predicted dependency relationship is a valid dependency relationship.

[0134] Figure 7 A module diagram of a code change risk assessment device according to an embodiment of the present application is shown.

[0135] like Figure 7 As shown, the risk assessment device 700 includes a first determination module 710 , a second determination module 720 and an assessment module 730 .

[0136] The first determining module 710 is configured to determine nodes to be modified in the code to be changed based on the code to be changed of the target software product.

[0137] The second determining module 720 is configured to determine, based on the node to be modified, at least one associated node that has a dependency relationship with the node to be modified from the dependency graph.

[0138] The evaluation module 730 performs a change risk assessment on the code to be changed based on the number of links and link lengths related to the associated nodes in the dependency graph to obtain a risk assessment result. The number of links is the total number of links associated with the associated nodes in the dependency graph, and the link length is the total number of nodes contained in the links where the associated nodes are located. The dependency graph is generated based on the above-mentioned dependency graph generation method.

[0139] Figure 8 A block diagram of an electronic device suitable for implementing the method described above according to an embodiment of the present application is shown. Figure 8 The electronic device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0140] Electronic device is intended to refer to various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic device may also refer to various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are intended to be examples only and are not intended to limit the implementation of the present application described and / or claimed herein.

[0141] like Figure 8As shown, electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. Various programs and data required for the operation of electronic device 800 may also be stored in RAM 803. Computing unit 801, ROM 802, and RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to bus 804.

[0142] Multiple components in the electronic device 800 are connected to the I / O interface 805, including an input unit 806, such as a keyboard, a mouse, etc.; an output unit 807, such as various types of displays, speakers, etc.; a storage unit 808, such as a magnetic disk, an optical disk, etc.; and a communication unit 809, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 809 allows the electronic device 800 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0143] The computing unit 801 can be any general-purpose and / or specialized processing component with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as the testing method. For example, in some embodiments, the testing method may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 808. In some embodiments, part or all of the computer program may be loaded and / or installed onto the electronic device 800 via the ROM 802 and / or the communication unit 809. When the computer program is loaded into the RAM 803 and executed by the computing unit 801, one or more steps of the testing method described above may be performed. Alternatively, in other embodiments, the computing unit 801 may be configured to perform the testing method via any other suitable means (e.g., via firmware).

[0144] Various embodiments of the systems and techniques described above can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-a-chip systems (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0145] The program code for implementing the method of the present application can be written in any combination of one or more programming languages. Such program code can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable test device so that when the program code is executed by the processor or controller, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0146] In the context of this application, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or apparatus. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of machine-readable storage media may include an electrical connection based on one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), optical fibers, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0147] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0148] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0149] A computer system may include a client and a server. The client and server are generally remote from each other and typically interact through a communication network. The client-server relationship arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server may be a cloud server, a server in a distributed system, or a server integrated with a blockchain.

[0150] Those skilled in the art will appreciate that the features described in the various embodiments of this application may be combined and / or coupled in various ways, even if such combinations or couplings are not explicitly described in this application. In particular, the features described in the various embodiments of this application may be combined and / or coupled in various ways without departing from the spirit and teachings of this application. All such combinations and / or couplings fall within the scope of this application.

[0151] The embodiments of the present application have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of the present application. Although each embodiment has been described separately above, this does not mean that the measures in each embodiment cannot be advantageously used in combination. Without departing from the scope of the present application, those skilled in the art may make various substitutions and modifications, and these substitutions and modifications should all fall within the scope of the present application.

Claims

1. A method for generating a dependency graph, characterized in that: include: Parsing a first data set of a target software product to determine a first node set and initial dependencies between nodes in the first node set, wherein the first data set represents business logic data for running the target software product; the first node includes at least one of a function node, a class node, and a module node; generating an initial dependency graph of the target software product based on the first node set and the initial dependency relationship; parsing a second data set of the target software product to determine a second node set and true dependencies between nodes in the second node set, wherein the second data set represents business test data generated during the testing of the target software product; the second node includes at least one of a function node, a class node, a module node, an element parameter node, a database table node, and a service node; Using the second node set and the real dependency relationship, the initial dependency graph is updated to obtain a dependency graph of the target software product; The step of parsing the second data set of the target software product to determine the second node set and the real dependency relationships between the nodes in the second node set includes: Parse the element parameters, database tables, and service calls in the test log to obtain the target supplementary nodes and the real dependency relationships between the target supplementary nodes used to supplement the initial dependency graph; The updating of the initial dependency graph using the second node set and the real dependency relationship to obtain the dependency graph of the target software product includes: Acquire a target supplementary node from the second node set, where the target supplementary node is a node in the second node set that is different from the first node set; When the type of the target supplementary node does not exist in the first node set, establishing an initial dependency subgraph of the type based on the target supplementary nodes of the type and the real dependency relationships of the target supplementary nodes; Based on multiple types of initial dependency subgraphs, a dependency graph is obtained.

2. The method according to claim 1, characterized in that The updating of the initial dependency graph using the second node set and the real dependency relationship to obtain the dependency graph of the target software product includes: Obtain a target verification node from the second node set, where the target verification node is the same node in the second node set as that in the first node set; Verifying the initial dependency relationship of the target verification node based on the real dependency relationship of the target verification node to obtain a verification result; Based on the verification result, the initial dependency graph is updated to obtain the dependency graph.

3. The method according to claim 2, characterized in that The updating of the initial dependency graph based on the verification result includes: If the verification result indicates that the initial dependency of the target verification node is an invalid dependency, deleting the initial dependency from the initial dependency graph, wherein the invalid dependency indicates that the initial dependency does not exist during the operation of the target software product; In a case where the verification result indicates that the initial dependency relationship of the target verification node has changed, the initial dependency relationship is replaced with the real dependency relationship of the target verification node in the initial dependency graph.

4. The method according to claim 1, wherein The updating of the initial dependency graph using the second node set and the real dependency relationship to obtain the dependency graph of the target software product includes: Acquire a target supplementary node from the second node set, where the target supplementary node is a node in the second node set that is different from the first node set; The target supplementary node and the real dependency relationship of the target supplementary node are added to the initial dependency graph to obtain the dependency graph.

5. The method according to claim 1, wherein The first data set includes source code and configuration files; The step of parsing the first data set of the target software product to determine the first node set and the initial dependency relationships between the nodes in the first node set includes: Parsing the source code using a code parsing tool that matches a language type of the source code to obtain a third node set and initial dependency relationships between nodes in the third node set; Parsing the configuration file using a configuration file parsing tool that matches the format of the configuration file to obtain a fourth node set and initial dependency relationships between nodes in the fourth node set; The third node set and the initial dependency relationship between each node in the third node set are merged with the fourth node set and the initial dependency relationship between each node in the fourth node set to obtain the first node set and the initial dependency relationship between each node in the first node set.

6. The method according to claim 1, characterized in that The second data set includes a test log; The step of parsing the second data set of the target software product to determine the second node set and the real dependency relationships between the nodes in the second node set includes: The interfaces and functions in the test log are parsed to obtain a target verification node for verifying the initial dependency graph and a real dependency relationship of the target verification node.

7. The method according to claim 1, characterized in that Also includes: Inputting the dependency graph and the node to be processed into a dependency relationship prediction model, and outputting a predicted node having a dependency relationship with the node to be processed, and a predicted dependency relationship between the node to be processed and the predicted node, wherein the node to be processed is a service node that has not been tested during the test process; When it is determined that the predicted dependency is a valid dependency, the predicted dependency is added to the dependency graph.

8. A method for risk assessment of code changes, characterized in that: include: Determining, based on the code to be changed of the target software product, a node to be modified of the code to be changed; Based on the node to be modified, determining from a dependency graph at least one associated node that has a dependency relationship with the node to be modified; Performing a change risk assessment on the code to be changed based on the number and link lengths of links associated with the associated node in the dependency graph to obtain a risk assessment result, wherein the number of links is the total number of links associated with the associated node in the dependency graph, and the link length is the total number of nodes included in the link where the associated node is located; Wherein, the dependency graph is generated based on the method described in any one of claims 1 to 7.

9. A device for generating a dependency graph, characterized in that: include: First parsing module; for parsing a first data set of a target software product to determine a first node set and initial dependencies between nodes in the first node set, the first data set representing business logic data for running the target software product; The first node includes at least one of a function node, a class node, and a module node; A generating module, configured to generate an initial dependency graph of the target software product based on the first node set and the initial dependency relationship; a second parsing module, configured to parse a second data set of the target software product to determine a second node set and actual dependencies between nodes in the second node set, wherein the second data set represents business test data generated during the testing of the target software product; the second node includes at least one of a function node, a class node, a module node, an element parameter node, a database table node, and a service node; an updating module, configured to update the initial dependency graph using the second node set and the real dependency relationship to obtain a dependency graph of the target software product; The second parsing module includes a fourth parsing submodule, which is used to parse the element parameters, database tables and service calls in the test log to obtain the target supplementary nodes and the real dependency relationships between the target supplementary nodes for supplementing the initial dependency graph; The updating of the initial dependency graph using the second node set and the real dependency relationship to obtain the dependency graph of the target software product includes: Acquire a target supplementary node from the second node set, where the target supplementary node is a node in the second node set that is different from the first node set; When the type of the target supplementary node does not exist in the first node set, establishing an initial dependency subgraph of the type based on the target supplementary nodes of the type and the real dependency relationships of the target supplementary nodes; Based on multiple types of initial dependency subgraphs, a dependency graph is obtained.

10. A risk assessment device for code changes, characterized in that: include: A first determining module is configured to determine, based on the code to be changed of the target software product, a node to be modified in the code to be changed; A second determining module is configured to determine, based on the node to be modified, from a dependency graph at least one associated node that has a dependency relationship with the node to be modified; an assessment module, performing a change risk assessment on the code to be changed based on the number and link length of links associated with the associated node in the dependency graph, to obtain a risk assessment result, wherein the number of links is the total number of links associated with the associated node in the dependency graph, and the link length is the total number of nodes included in the link where the associated node is located; Wherein, the dependency graph is generated based on the method described in any one of claims 1 to 8.

11. An electronic device comprising: one or more processors; a memory for storing one or more computer programs; The method further comprises the step of executing the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

12. A computer-readable storage medium having executable instructions stored thereon, wherein a computer program or instruction is stored thereon, characterized in that: When the computer program or instructions are executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

13. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instructions are executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

Images