Communication service interface bloodline map construction method and influence evaluation method and device

Abstract

The present disclosure relates to the technical field of communication software testing, and provides a communication service interface bloodline graph construction method, an influence evaluation method and device. The interface bloodline graph construction method comprises: for each interface in an interface set, extracting the containing relationship between the interface and its parameters, the direct reference relationship between the parameters contained by the interface and the parameters of other interfaces, and the direct calling relationship between the interface and other interfaces from static code; tracking a parameter propagation path chain from dynamic traffic, inputting the same into an LSTM to predict an indirect correlation relationship between the parameters; taking the interfaces and the parameters as nodes in an interface bloodline graph, and using the relationships to construct edges in the interface bloodline graph. Because parameter-level tracking and dynamic and static fusion analysis are adopted, the influence of interface changes is visible, and the accuracy of interface dependency relationship analysis is improved. Based on the communication service interface bloodline graph construction method, software testing can be performed, and the timeliness of regression testing can be improved.

Description

Technical Field

[0001] This disclosure belongs to the field of communication software testing technology, and in particular relates to a method for constructing a lineage map of communication service interfaces, an impact assessment method, and an apparatus. Background Technology

[0002] In recent years, the popularization and maturity of cloud computing technology has driven a core shift in software service architecture—the architecture model centered on cloud computing platforms has gradually become mainstream. With its efficient and reliable platform support and robust infrastructure, cloud computing provides a solid foundation for the management and utilization of computing resources, and also creates conditions for the flexible expansion and efficient operation and maintenance of software systems.

[0003] Against this backdrop, microservice architecture, as an important architectural pattern for adapting to cloud computing environments, is becoming increasingly widely used. The core of this architecture lies in breaking down a single application into multiple independently running small modules (i.e., microservices). These services collaborate through network interaction to meet user needs. Each microservice focuses on implementing a specific business function, maintaining independence in coding, deployment, and environment configuration, and services do not interfere with each other; essentially, it is a distributed system.

[0004] However, with the deep integration of cloud computing and microservice architecture, software testing for microservices is facing a series of core challenges, among which the invisibility of the impact of interface changes is particularly prominent. Traditional testing platforms can only achieve interface-level dependency mapping, that is, identify "which interfaces have call relationships," but cannot capture the deep impact of cascading parameter changes—such as the potential effect of detailed adjustments like changes in field types or parameter passing paths on test cases. Therefore, there is a problem of coarse-grained interface dependency analysis. This limitation directly leads to a persistently high false positive rate in test scope; according to Gartner's 2024 Test Automation Report, this false positive rate has exceeded 40%, becoming a key bottleneck restricting testing efficiency and quality. Summary of the Invention

[0005] To address the aforementioned issues, this disclosure provides a method for constructing a lineage map of a communication service interface, an impact assessment method, and an apparatus.

[0006] This invention provides a method for constructing a lineage graph of a communication service interface, comprising:

[0007] Determine the set of interfaces;

[0008] For each interface, extract from the static code the inclusion relationship between the interface and its parameters, the direct reference relationship between the parameters contained in the interface and the parameters of other interfaces, and the direct calling relationship between the interface and other interfaces;

[0009] Tracing parameter propagation paths from dynamic traffic and inputting them into an LSTM predicts indirect relationships between parameters.

[0010] For each parameter, determine the parameter change impact chain resulting from its change;

[0011] Using interfaces and parameters as nodes in the interface lineage graph, edges are constructed in the interface lineage graph by utilizing inclusion relationships, parameter propagation path chains, direct reference relationships, direct call relationships, indirect association relationships, and parameter change impact chains;

[0012] For each edge, the weight of the edge is determined based on the frequency of its occurrence in historical calls and / or the priority of the service carried by the interface to which the edge is connected; this completes the construction of the interface lineage graph.

[0013] Furthermore, for each interface, extract from the static code the inclusion relationship between the interface and its parameters, the direct reference relationship between the parameters contained in the interface and the parameters of other interfaces, and the direct calling relationship between the interface and other interfaces, including:

[0014] For each interface, the following syntax analysis is performed using a syntax tree parser:

[0015] Recursively resolve the nested dependencies of the input parameters to obtain the direct reference relationships between the parameters contained in this interface and the parameters of other interfaces;

[0016] Based on JSON Schema or OpenAPI specifications, construct the inclusion relationship between the interface and the output parameters;

[0017] By using custom annotations, the direct calling relationships between this interface and other interfaces can be extracted from the interface documentation.

[0018] Furthermore, the parameter propagation path chain is traced from the dynamic traffic, and input into an LSTM to predict the indirect relationships between parameters, including:

[0019] Extract the request-response chain from historical test logs, and construct the parameter propagation path chain from the extracted response chain through regular expression matching and parameter path parsing;

[0020] The constructed parameter propagation path chain is input into the trained LSTM neural network to predict the indirect relationships in the parameter propagation path chain, obtain the prediction confidence, and extract the indirect relationships between parameters whose prediction confidence is greater than a set value.

[0021] Furthermore, when adding new test logs, the method for constructing the lineage graph of the communication service interface also includes:

[0022] Extract the interface nodes from the newly added test logs;

[0023] Node embedding vectors are constructed using the extracted interface nodes and input into Node2Vec to capture the latest call frequency between interfaces;

[0024] The weights of the corresponding edges are adjusted using the latest captured call frequency.

[0025] This invention also provides a method for assessing the impact of changes to communication service interfaces, comprising:

[0026] An interface lineage graph is constructed using the aforementioned communication service interface lineage graph construction method;

[0027] For each changed interface, all changed parameters are identified by parsing the direct reference relationships between the parameters contained in that interface and the parameters of other interfaces.

[0028] For each changed parameter, the interface lineage graph is used to traverse all interface nodes that can be reached in reverse through the parameter propagation path chain;

[0029] The path from the changed parameter to the final reachable interface node is used as the propagation path, and the interface nodes and parameter nodes on the propagation path are recorded.

[0030] Using the recorded interface nodes and parameter nodes, generate a set of influencing paths;

[0031] Use the set of impact paths to assess the risk of interface changes.

[0032] Furthermore, an interface change risk assessment is conducted using the set of impact paths, including:

[0033] Using the weight values ​​on the generated set of impact paths, assess the risk value of this parameter change to the test cases corresponding to the traversed interface nodes;

[0034] The execution order of regression tests is scheduled according to the risk level to which the risk value belongs.

[0035] Furthermore, the interface change involves a change in the type of its included parameters;

[0036] Using the weight values ​​on the generated set of impact paths, assess the risk of this parameter change to the test cases corresponding to the traversed interface nodes, including:

[0037] Define a parameter type compatibility matrix CompatMat to characterize the impact of different types of changes. ;in, express Parameters in Compatibility after changing from the old type to the new type;

[0038] Calculate the risk value for each test case affected by the changed parameter P using the following formula. : (1- similarity(p) 。

[0039] Furthermore, based on the risk level of the risk value, the execution order of regression tests is scheduled, including:

[0040] When the risk value of a test case exceeds the first set value, it is determined to be high-risk, and an emergency regression is immediately triggered to include the test case in the smoke test set.

[0041] If the risk value of a test case is greater than the second set value but less than or equal to the first set value, it is determined to be of medium risk and the test case is executed in the regular regression phase.

[0042] If the risk value of a test case is less than or equal to the second set value, it is determined to be low risk, and the test case is included in the scope of regular inspection.

[0043] The present invention also provides a communication service interface lineage map construction device, comprising:

[0044] Interface set determination unit, used to determine the interface set;

[0045] The first relationship determination unit is used to extract, for each interface, the inclusion relationship between the interface and its parameters, the direct reference relationship between the parameters contained in the interface and the parameters of other interfaces, and the direct call relationship between the interface and other interfaces from the static code.

[0046] The second relation determination unit is used to trace the parameter propagation path chain from dynamic traffic and input it into LSTM to predict the indirect correlation between parameters.

[0047] The third relation determination unit is used to determine the change impact chain generated by the change of each parameter;

[0048] The generation unit is used to treat interfaces and parameters as nodes in the interface lineage graph. It constructs edges in the interface lineage graph by using inclusion relationships, parameter propagation path chains, direct reference relationships, direct call relationships, indirect association relationships, and change impact chains. For each edge, the weight of the edge is determined based on the frequency of its occurrence in historical calls and / or the priority of the business carried by the interface connected to the edge. This completes the construction of the interface lineage graph.

[0049] The present invention also provides a device for assessing the impact of changes to communication service interfaces, comprising:

[0050] The graph generation unit is used by the aforementioned communication service interface lineage graph construction device to construct the interface lineage graph;

[0051] The identification unit is used to identify all changed parameters for each changed interface by parsing the direct reference relationships between the parameters contained in the interface and the parameters of other interfaces.

[0052] The traversal unit is used to traverse all interface nodes that can be reached in reverse through the parameter propagation path chain for each changed parameter, using the interface lineage graph.

[0053] The recording unit is used to record the interface nodes and parameter nodes along the propagation path, which is the path from the changed parameter to the finally reachable interface node.

[0054] The set generation unit is used to generate an influencing set of paths by utilizing the interface nodes and parameter nodes of the path utilization record.

[0055] The assessment unit is used to assess the risk of interface changes using a set of impact paths.

[0056] The present invention also provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0057] Memory, used to store computer programs;

[0058] The processor implements the above method when executing programs stored in memory.

[0059] The present invention also provides a computer storage medium storing a computer program, which, when executed by a processor, implements the above-described method.

[0060] Compared with the prior art, this disclosure has the following advantages:

[0061] 1. The use of parameter-level tracing combined with dynamic and static fusion analysis improves the accuracy of interface dependency analysis;

[0062] 2. Lightweight incremental updates and intelligent scheduling are adopted, which improves the timeliness of software testing and adapts to the high-frequency change requirements under the microservice architecture;

[0063] 3. It provides automation capabilities from impact analysis to intelligent scheduling, which can be further extended to test execution, thereby realizing full-chain automation capabilities from impact analysis to test execution and reducing the cost of manual intervention.

[0064] Other features and advantages of this disclosure will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the disclosure. The objects and other advantages of this disclosure may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

[0065] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0066] Figure 1 A schematic diagram of a method for constructing a lineage graph of a communication service interface according to an embodiment of the present disclosure is shown;

[0067] Figure 2 A schematic diagram of an interface lineage diagram according to an embodiment of the present disclosure is shown;

[0068] Figure 3 A schematic diagram of an explicit call edge constructed according to an embodiment of the present disclosure is shown;

[0069] Figure 4 A schematic diagram of an explicit parameter edge constructed according to an embodiment of the present disclosure is shown;

[0070] Figure 5 A schematic diagram of implicit parameter edges constructed using LSTM according to an embodiment of the present disclosure is shown;

[0071] Figure 6 A schematic diagram illustrating the impact chain of price field changes according to embodiments of the present disclosure is shown.

[0072] Figure 7 A schematic diagram illustrating an example of order_id type change and weight according to an embodiment of this disclosure is shown;

[0073] Figure 8 A flowchart of a method for assessing the impact of a change in a communication service interface according to an embodiment of this disclosure is shown;

[0074] Figure 9 A schematic diagram of the parameter propagation path chain traversed when the membership level vip_level changes according to an embodiment of the present disclosure is shown.

[0075] Figure 10 A block diagram of an interface lineage mapping device according to an embodiment of the present disclosure is shown;

[0076] Figure 11A block diagram of a communication service interface change impact assessment apparatus according to an embodiment of the present disclosure is shown;

[0077] Figure 12 A block diagram of an electronic device system according to an embodiment of the present disclosure is shown. Detailed Implementation

[0078] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0079] Example 1

[0080] Figure 1 This disclosure illustrates a method for constructing a lineage graph of a communication service interface, comprising the following steps:

[0081] Step 101: Determine the interface set.

[0082] Step 102: For each interface in the interface set, extract from the static code the inclusion relationship between the interface and its parameters, the direct reference relationship between the parameters contained in the interface and the parameters of other interfaces, and the direct calling relationship between the interface and other interfaces.

[0083] Specifically, assuming a given set of interface definitions API_SET, for each interface api∈API_SET, the following syntax analysis is performed using a syntax tree parser, such as the improved CST:

[0084] (1) Recursively resolve the nested dependencies of the input parameters to obtain the direct reference relationships between the parameters contained in the interface and other parameters;

[0085] For example, the input parameter p1 of api1 depends on the response field res2.f1 of api2.

[0086] (2) Based on JSON Schema or OpenAPI specifications, construct the inclusion relationship between the interface and the output parameters;

[0087] (3) Extract the direct calling relationship between the interface and other interfaces from the interface documentation through custom annotations.

[0088] For example, the custom annotation @Dependency(api="order-service / getOrder") can be used to extract the call relationship between the API and the order-service or getOrder API from the API documentation.

[0089] Step 103: Trace the parameter propagation path chain from the dynamic traffic and input it into LSTM to predict the indirect correlation between parameters.

[0090] Specifically, request-response chains can be extracted from historical test logs, and parameter propagation path chains can be constructed from the extracted response chains through regular expression matching and parameter path parsing.

[0091] For example, the constructed parameter propagation path chain can be Chain=[req_1.p1→res_1.f2→req_2.p3→...].

[0092] The constructed parameter propagation path chain is input into the trained LSTM neural network to predict the indirect relationships within the path chain, obtaining the prediction confidence. Indirect relationships with prediction confidence greater than a set value are extracted. This set value can be 0.7. This part will be described in detail below.

[0093] Step 104: For each parameter, determine the parameter change impact chain caused by its change.

[0094] Step 105: Using the interface and parameters as nodes in the interface lineage graph, construct the edges in the interface lineage graph using the inclusion relationship, direct reference relationship, direct call relationship, indirect association relationship and parameter change influence chain.

[0095] There are two types of nodes in this disclosure: one is the interface node, such as / createOrder and / pay, which represents the service node; the other is the parameter node, such as order_id and user_id, which represents the atomic data unit.

[0096] Specifically, the edges here can be divided into six types:

[0097] Explicit containment edges: the containment relationship between interfaces and parameters;

[0098] Explicit call edges: direct call relationships between interfaces; such as / pay→ / notify.

[0099] Explicit parameter edges: Based on the parameter propagation path chain traced in dynamic traffic and the direct reference relationship between the parameters contained in this interface and other parameters, the direct reference relationship between parameters is obtained; for example, / shipping.order_id ← / pay.order_id.

[0100] Implicit parameter edges: Indirect relationships between parameters predicted by LSTM; for example, vip_level (membership level) implicitly affects price (product price).

[0101] Change-affected edges: The relationship between parameters affected by changes, obtained from the change-affected chain.

[0102] Explicit edges can be represented by solid lines, while implicit edges and edges affected by changes can be represented by dashed lines with labels.

[0103] Step 106: For each edge, determine the weight of the edge based on the frequency of its occurrence in historical calls and / or the priority of the service carried by the interface to which the edge is connected.

[0104] This completes the construction of the interface lineage graph.

[0105] In addition to relationship attributes, interfaces and parameters in the interface lineage graph also have weight attributes, which need to be quantified. The purpose of quantification is to clarify the importance of this relationship, which will affect subsequent test case generation and test plan execution. A change in one field may have a series of effects, the specific effects of which are determined by the constructed interface lineage graph.

[0106] Furthermore, the weights of the aforementioned edges are not fixed. When new test logs are added, Node2Vec incremental learning can be initiated. In the incremental learning parameters, the window size can be set to 5, and the jump probability parameters p=1 and q=2. Details are as follows:

[0107] (1) First, extract the interface nodes from the newly added test logs;

[0108] (2) Construct a node embedding vector embedding(v) using the extracted interface nodes, input it into Node2Vec, and then capture the latest call frequency between interfaces; adjust the weight of the corresponding edge using the captured latest call frequency to ensure the timeliness of the interface lineage graph.

[0109] The following is through Figure 2 The example interface lineage illustrates the scheme of this disclosure.

[0110] Figure 2 This document contains the interfaces and parameters involved in the user order placement process, explained in detail below:

[0111] 1. User Services

[0112] (1) Interface: / getUserInfo

[0113] (2) Output parameters: 1) user_id = "U1001" (explicit); 2) vip_level = "Diamond Member" (explicit).

[0114] 2. Goods and Services

[0115] (1) Interface: / getProductDetail

[0116] (2) Output parameters: 1) product_id = "P2005" (explicit); 2) price = "299.0" (explicit + implicit, affected by vip_level).

[0117] 3. Order Service

[0118] (1) Interface: / createOrder

[0119] (2) Input parameters: 1) user_id (from user service); 2) product_id (from product service); 3) price (from product service)

[0120] (3) Output parameters: 1) order_id = "ORD8800" (newly generated); 2) total_amount = price×0.8 (20% discount for diamond members).

[0121] 4. Payment Services

[0122] (1) Interface: / Pay

[0123] (2) Input parameters: 1) order_id (from order service); 2) total_amount (from order service).

[0124] 5. Logistics services

[0125] (1) Interface: / scheduleDelivery;

[0126] (2) Input parameters: 1) order_id (from order service); 2) delivery_address (from user profile, LSTM prediction).

[0127] 6. Price protection service

[0128] (1) Interface: / shipping

[0129] (2) Input parameters: 1) amount; 2) insurance_flag.

[0130] First, determine the set of the above 6 interfaces involved in the user order placement process;

[0131] Secondly, extract the direct call relationships between interfaces from the static code and construct explicit call edges: Figure 3 The example demonstrates the construction of an explicit call edge: Order Service ---> (Explicit Call) ---> Payment Service, completing the payment. Order Service ---> (Explicit Call) ---> Logistics Service, arranging delivery.

[0132] Next, extract the parameters contained in each of the six interfaces from the static code, and construct the containment edges between the interfaces and their parameters. Figure 2 It is not shown in the text.

[0133] Next, the direct reference relationships between the parameters contained in the interface and other parameters are extracted from the static code, and combined with the parameter propagation path chain traced from the dynamic traffic, the direct reference relationships between parameters are obtained, and explicit parameter edges are constructed. Figure 4 The example demonstrates the construction of explicit parameter edges: user_id → order_id: the user ID directly generates the order ID; vip_level + price → total_amount: the membership level and the product price jointly determine the total order amount; user_address → delivery_address: the user address is directly used as the delivery address.

[0134] Next, from the dynamic traffic, we use LSTM to track the indirect relationships between parameters and construct implicit parameter edges; Figure 5 The example illustrates the implicit parameter edges constructed using LSTM: Diamond members see prices 15% lower than regular members (vip_level→price); the system predicts that VIP users are more likely to use the company address (vip_level→delivery_address); high-priced goods tend to be delivered to secure addresses (price→delivery_address).

[0135] Next, determine the impact chain of parameter changes. Figure 6 The effect chain of price field changes is shown. Figure 6 The removal of the `price` field may cause anomalies in many modules. The direct impact is on order services and related payment services, potentially leading to main process errors. The implicit impact is on logistics services, affecting delivery strategies and causing incorrect delivery priorities. Indirectly, it affects payment amount transfer and insurance service triggering, potentially causing insurance decisions to fail and payment amounts to be incorrect.

[0136] Then, based on the above relationships, edges in the interface lineage graph are constructed. Solid lines represent explicit parameter edges, explicit call edges, and containment edges between interfaces and parameters, while dashed lines represent implicit parameter edges and change-impact edges in the change-impact chain. Labels for change-impact or LSTM predictions are added to the corresponding edges, resulting in the following: Figure 2 The interface lineage diagram is shown.

[0137] Finally, the weights on the edges are calculated using the weight calculation formula described above. Figure 7 Examples of changes to the order_id type and their weights are provided. Changes to the order_id type affect the logistics interface, recommendation interface, and log interface. Figure 2 The weights are not shown in the text.

[0138] The following explains how to use a trained LSTM neural network to predict indirect relationships in the parameter propagation path chain.

[0139] The role of LSTM is to discover "implicit parameter dependencies" from massive historical call logs, that is, parameter combinations that do not appear explicitly in the code or documentation but are repeatedly co-occurring in actual business behavior.

[0140] For example, when a user pays an amount greater than the set amount, the system is more likely to automatically select the "price protection service".

[0141] LSTM Objective: To predict the implicit association probability between "high payment amount" and "price protection service" using historical parameter sequences. Input Data Source: Parameter propagation path chains sorted by time extracted from test logs (TEST_LOG).

[0142] LSTM discovers the implicit rule that "high amount often leads to insured=1" by looking through thousands of such chains.

[0143] Setting up the input data for the LSTM algorithm:

[0144] First, relevant feature data are obtained based on the parameter propagation path chain;

[0145] Secondly, feature values ​​are selected from the feature data based on the prediction requirements;

[0146] Next, the selected feature values ​​are concatenated to obtain the input data.

[0147] For example: the parameter propagation path chain [req_1.amount=1200]→[res_1.order_id=O123]→[req_2.order_id=O123]→[res_2.insured=1].

[0148] The parameter propagation path chain unfolds a complete business operation over time, forming a causal sequence, which is:

[0149] [req_1.amount=1200]→[res_1.order_id=O123]→[req_2.order_id=O123]→[res_2.insured=1];

[0150] LSTM can learn the temporal causality of "high total amount → appearance of order_id → triggering insured" through this parameter propagation path chain;

[0151] [req_1.amount=1200] indicates that the first request (req_1) called the / pay interface and submitted an order for 1200 yuan;

[0152] [res_1.order_id=O123] indicates that the response (res_1) of / pay returns the newly generated order number O123, which is also [req_2.order_id=O123];

[0153] [req_2.order_id=O123] indicates that the second request (req_2) called the / shipping interface and used order_id=O123 as an input parameter. The system is calculating a logistics plan for order O123.

[0154] [res_2.insured=1] indicates that the response (res_2) to / shipping returns insured=1 (insurance is enabled).

[0155] The above process can be expressed in natural language as follows: "User pays 1200 yuan → Order O123 is generated → Logistics system recognizes O123 → Automatic insurance is provided due to the high amount."

[0156] A lot of feature data can be extracted from the parameter propagation path chain (partial examples), as shown in Tables 1, 2 and 3 below:

[0157] Table 1

[0158]

[0159] Table 2

[0160]

[0161] Table 3

[0162]

[0163] Then the required feature values ​​are concatenated and used as input to the LSTM model.

[0164] In the example, the four rows of data in Table 4 below are input into the LSTM. The LSTM can learn that high amounts often appear together with insurance based on the fact that it first sees 1200 yuan, then O123, and finally the price guarantee = 1. Then it can build implicit dependencies based on this.

[0165] Table 4

[0166]

[0167] In this embodiment of the scheme, interface dependencies are extracted from static code and dynamic traffic to construct parameter-level interface lineage relationship data, which is then quantitatively modeled to ultimately generate an interface lineage graph with dynamic weights. By employing a two-layer interface lineage graph modeling method—parameter-level tracking + dynamic-static fusion analysis—the limitations of single-dimensional dependency analysis are overcome, improving the accuracy of dependency analysis. Furthermore, the impact of changes is also displayed in the graph, making the impact of interface changes visible and improving the accuracy of subsequent testing. Further, an ordered LSTM column prediction model is applied to interface parameter dependency discovery, enhancing the completeness of dependency modeling; and graph embedding technology enables real-time evolution of the graph, overcoming the performance bottleneck of traditional full-scale reconstruction.

[0168] Example 2

[0169] This disclosure also provides a method for assessing the impact of changes to communication service interfaces, such as... Figure 8 As shown, it includes the following steps:

[0170] Step 801: Construct an interface lineage graph using the above-described communication service interface lineage graph construction method.

[0171] Step 802: For each changed interface, identify all changed parameters by parsing the direct reference relationships between the parameters contained in the interface and other parameters.

[0172] Specifically, the parameter tree ParamTree_X of the API_X interface is parsed to identify all changed parameters P={p:(old_type},new_type)}, such as changing the field type from string to object, adding options to the enumeration value, etc.

[0173] Step 803: For each changed parameter, use the interface lineage graph to traverse all interface nodes that can be reached in reverse through the parameter propagation path chain.

[0174] Specifically, for each changed parameter p∈P, a depth-restricted reverse BFS is performed in the communication service interface lineage graph construction method (for example, setting a depth threshold d=3, based on the statistical law that the influence of more than 3 layers is negligible in 85% of scenarios).

[0175] Figure 9 The document describes the parameter propagation path chain reached by reverse BFS (Breadth-First Search) with a depth threshold of 3 when the membership level (vip_level) changes: membership level (vip_level) → total order amount (total_amount) → payment amount. The three interfaces are / pay, order service ( / createOrder), and user service ( / getUserinfo). Figure 9 The process of backpropagation determining the impact on the Layer 3 interface is shown in red arrows, orange solid boxes, and red numbers.

[0176] Step 804: Use the path from the changed parameter to the final reachable interface node as the propagation path, and record the interface nodes and parameter nodes on the propagation path.

[0177] Continue Figure 9 In the example, the path from VIP level (vip_level) to total order amount (total_amount) to payment amount (amount) to payment service ( / pay) to order service ( / createOrder) to user service ( / getUserinfo) is used as the propagation path. The interface nodes on the propagation path are recorded as: payment service ( / pay), order service ( / createOrder), and user service ( / getUserinfo), as well as the parameter nodes as: VIP level (vip_level), total order amount (total_amount), and payment amount (amount).

[0178] Step 805: Use the recorded interface nodes and parameter nodes to generate a set of influencing paths.

[0179] Using the example from step 804, the generated set of influence paths is as follows:

[0180] Membership level (vip_level) → Total order amount (total_amount), Total order amount (total_amount) → Payment amount (amount), Payment amount (amount) → Payment service ( / pay), Payment service ( / pay) → Order service ( / createOrder), and Order service ( / createOrder) → User service ( / getUserinfo).

[0181] It's important to note that a propagation path and an influence path are different: a propagation path is a single path, such as A--->B--->C--->D, but the influence path of that propagation path may have many branches. For example: A-->B--->C--->D; A-->E--->F--->D; A--->X--->Y--->D.

[0182] Step 806: Conduct an interface change risk assessment using the set of impact paths.

[0183] Specifically, this step includes:

[0184] 1) Using the weight values ​​on the generated set of impact paths, assess the risk value of this parameter change to the test cases corresponding to the traversed interface nodes;

[0185] More specifically, the change to the interface refers to a change in the parameter types contained in the interface;

[0186] Using the weight values ​​on the generated set of impact paths, assess the risk of this parameter change to the test cases corresponding to the traversed interface nodes, including:

[0187] Define parameter type compatibility matrix This characterizes the degree of impact of different types of changes, among which... ;in, Indicates parameters exist Compatibility after changing from the old type to the new type;

[0188] For example: string→object Compatibility is 0.4. number→long With a compatibility score of 0.9, the parameter p is determined by... string→object At that time, its compatibility ;Depend on number→long hour ， Its compatibility .

[0189] This section considers and quantifies the compatibility impact of the changes; with equal weight, higher compatibility corresponds to lower risk.

[0190] Use the following formula to calculate the changed parameters. Each test case affected Risk value calculation : ， in, Represents the first in the interface lineage graph 1 node Represents the first in the interface lineage graph 1 node Indicates the first The node to the first The path of each node falls within the test scope of the calculated test cases.

[0191] Here, each node has its own unique attribute (ID), for example:

[0192] Membership level (VIP_level) ----> 001; Total order amount (total_amount) ----> 002;

[0193] Similarly, the weight between the two nodes, VIP level and total amount, can be represented as W(001, 002); then the risk value of a certain test case is the sum of all the weights on this path: W(001, 002) + W(002, 003) + ... + W(j-1, j).

[0194] 2) Schedule the execution order of regression tests according to the risk level to which the risk value belongs.

[0195] Specifically, when the risk value of a test case is greater than the first set value, it is determined to be high risk, an emergency regression is immediately triggered, and the test case is included in the smoke test set.

[0196] If the risk value of a test case is greater than the second set value but less than or equal to the first set value, it is determined to be of medium risk and the test case is executed in the regular regression phase.

[0197] If the risk value of a test case is less than or equal to the second set value, it is determined to be low risk, and the test case is included in the scope of regular inspection.

[0198] The first setting value can be 0.8, and the second setting value can be 0.3.

[0199] Furthermore, for each parameter change, supplementary test cases are automatically generated based on boundary value analysis and combined testing strategies.

[0200] Specifically, when a parameter type changes, boundary value analysis is performed based on the changed type to generate boundary inputs, which in turn generate boundary test cases. Based on the implicit dependencies between this parameter and other parameters, composite test cases are generated. Both the generated boundary test cases and composite test cases are supplementary test cases.

[0201] The above steps provide a parameter-level impact analysis and risk quantification system, enabling automated mapping from "interface change" to "precise positioning of test scope" and building a closed-loop intelligent testing ecosystem.

[0202] The following two scenarios will further illustrate the solutions of the embodiments of this disclosure:

[0203] Scenario 1: Changes to the e-commerce order service interface

[0204] 1. Feature Extraction

[0205] The order_id field in the payment interface / pay has been changed from a string type to an object type containing id (string) and region (number):

[0206] -"order_id": "string"

[0207] + "order_id": {

[0208] "type": "object",

[0209] "properties": {

[0210] "id": "string",

[0211] "region": "number"

[0212] }

[0213] }

[0214] 2. Spectrum Matching and Impact Analysis

[0215] Static analysis revealed a change in the order_id type, triggering a parameter dependency comparison.

[0216] In the lineage graph, the order_id parameter of the logistics interface / shipping is located to be directly dependent on / pay.order_id, and the parameter type compatibility is 0.4 (objects and strings are incompatible).

[0217] A reverse BFS traversal depth of ≤3 identified 12 test cases involving the parameter passing path. Assuming the sum of the weights of the path edges corresponding to the first test case (case1) is 0.8, the risk value for this test case is calculated as follows: =0.8× (1- 0.4) =0.48, where the cumulative path weight includes the API call weight and parameter dependency weight.

[0218] 3. Test execution response

[0219] When the first set value is 0.8 and the second set value is 0.3, the first test case is marked as medium risk and executed during the regular regression phase;

[0220] In addition, supplementary test cases need to be generated to verify the parsing logic of / shipping for order_id.id and order_id.region, ensuring compatibility.

[0221] Scenario 2: Optimization of social media platform comment service

[0222] 1. Implicit Association Prediction

[0223] After adding the filter parameter is_hot, analysis of historical call logs revealed the following:

[0224] The front end has a request pattern that uses both is_hot=true and sort_type=time simultaneously;

[0225] The LSTM model predicts a 65% probability of conflict based on parameter combinations (based on a classification model with a training set accuracy of 91%).

[0226] 2. Generate boundary test cases:

[0227] {

[0228] "api": " / comments / list",

[0229] "params": {"is_hot": true, "sort_type": "time", "page_size": 100},

[0230] "expect": {

[0231] "code": 200,

[0232] "data": {

[0233] "total": {"$gt": 0},

[0234] "items": [{"created_at": {"$lt": "2025-05-26"}}]

[0235] }

[0236] }

[0237] }

[0238] This test case covers scenarios with different parameter combinations, verifying the correctness of the coordination between the sorting logic and the popularity filtering.

[0239] In the scheme of this embodiment, based on the established interface lineage graph, and based on the propagation path of interface parameter changes, the impact range and risk level of interface changes on test cases are accurately calculated, realizing risk assessment of interface changes. This lays the foundation for intelligent scheduling of regression test execution order and optimization of test resource allocation. In this process, lightweight incremental updates and intelligent scheduling improve the timeliness of software testing and adapt to the high-frequency change requirements under microservice architecture. Furthermore, it provides end-to-end automation capabilities from impact analysis to test execution, reducing the cost of manual intervention.

[0240] Based on the above-described method for constructing a lineage graph of communication service interfaces, this disclosure also provides an apparatus for constructing a lineage graph of communication service interfaces corresponding to the above method. Figure 10 A block diagram of a communication service interface lineage graph construction apparatus according to an embodiment of the present disclosure is shown, including: an interface set determination unit, a first relationship determination unit, a second relationship determination unit, a third relationship determination unit, and a generation unit; wherein:

[0241] Interface set determination unit, used to determine the interface set;

[0242] The first relationship determination unit is used to extract, for each interface, the inclusion relationship between the interface and its parameters, the direct reference relationship between the parameters contained in the interface and the parameters of other interfaces, and the direct call relationship between the interface and other interfaces from the static code.

[0243] The second relation determination unit is used to trace the parameter propagation path chain from dynamic traffic and input it into LSTM to predict the indirect correlation between parameters.

[0244] The third relation determination unit is used to determine the change impact chain generated by the change of each parameter;

[0245] The generation unit is used to treat interfaces and parameters as nodes in the interface lineage graph. It constructs edges in the interface lineage graph by using inclusion relationships, parameter propagation path chains, direct reference relationships, direct call relationships, indirect association relationships, and change impact chains. For each edge, the weight of the edge is determined based on the frequency of its occurrence in historical calls and / or the priority of the business carried by the interface connected to the edge. This completes the construction of the interface lineage graph.

[0246] The first relation determination unit is specifically used to perform the following syntax analysis for each interface using a syntax tree parser: recursively parse the nested dependencies of input parameters to obtain the direct reference relationships between the parameters contained in this interface and the parameters of other interfaces; construct the inclusion relationship between the interface and the output parameters based on JSON Schema or OpenAPI specifications; and extract the direct call relationship between this interface and other interfaces from the interface documentation through custom annotations.

[0247] The second relationship determination unit is specifically used to extract request-response links from historical test logs, construct parameter propagation path chains from the extracted response links through regular expression matching and parameter path parsing, input the constructed parameter propagation path chains into a trained LSTM neural network, predict the indirect relationships in the parameter propagation path chains, obtain prediction confidence, and extract the indirect relationships between parameters whose prediction confidence is greater than a set value.

[0248] The generation unit is also used to extract interface nodes from the newly added test logs when new test logs are added; to construct node embedding vectors using the extracted interface nodes, and input them into Node2Vec to capture the latest call frequency between interfaces; and to adjust the weight of the corresponding edge using the captured latest call frequency.

[0249] Based on the above-described method for assessing the impact of changes to communication service interfaces, this disclosure also provides an apparatus for assessing the impact of changes to communication service interfaces, corresponding to the above-described method. Figure 11 A block diagram of a communication service interface change impact assessment apparatus according to an embodiment of the present disclosure is shown, including:

[0250] The graph generation unit is used by the aforementioned communication service interface lineage graph construction device to construct the interface lineage graph;

[0251] The identification unit is used to identify all changed parameters for each changed interface by parsing the direct reference relationships between the parameters contained in the interface and the parameters of other interfaces.

[0252] The traversal unit is used to traverse all interface nodes that can be reached in reverse through the parameter propagation path chain for each changed parameter, using the interface lineage graph.

[0253] The recording unit is used to record the interface nodes and parameter nodes along the propagation path, which is the path from the changed parameter to the finally reachable interface node.

[0254] The set generation unit is used to generate an influencing set of paths by utilizing the interface nodes and parameter nodes of the path utilization record.

[0255] The assessment unit is used to assess the risk of interface changes using a set of impact paths.

[0256] The present invention also provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0257] Memory, used to store computer programs;

[0258] The processor implements the above method when executing programs stored in memory.

[0259] The present invention also provides a computer storage medium storing a computer program, which, when executed by a processor, implements the above-described method.

[0260] Based on the same inventive concept as the above-disclosed content, this disclosure also provides an electronic device, such as... Figure 12 As shown. An electronic device according to an embodiment of this disclosure includes at least one processor and at least one memory electrically connected to the processor, wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method described above.

[0261] It should be noted that the electrical connection between the above-mentioned units does not necessarily mean the connection between lines. The indirect connection method can be applied to the embodiments of this disclosure as long as it achieves the purpose of this disclosure.

[0262] Based on the same inventive concept, this disclosure also provides a computer storage medium storing a computer program, which, when executed by a processor, implements the above-described method.

[0263] Although the present disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure.

Claims

1. A method for constructing a lineage graph of communication service interfaces, characterized in that, Applications in a microservices architecture include: Determine the set of interfaces; For each interface, extract from the static code the inclusion relationship between the interface and its parameters, the direct reference relationship between the parameters contained in the interface and the parameters of other interfaces, and the direct calling relationship between the interface and other interfaces; Tracing parameter propagation paths from dynamic traffic and inputting them into an LSTM predicts indirect relationships between parameters. For each parameter, determine the parameter change impact chain resulting from its change; Using interfaces and parameters as nodes in the interface lineage graph, explicit inclusion edges are constructed using the inclusion relationship, explicit parameter edges are constructed using the direct reference relationship, explicit call edges are constructed using the direct call relationship, implicit parameter edges are constructed using the indirect association relationship, and change influence edges are constructed using the parameter change influence chain. For each edge, the weight of the edge is determined based on the frequency of its occurrence in historical calls and / or the priority of the service carried by the interface to which the edge is connected; this completes the construction of the interface lineage graph.

2. The method for constructing a lineage graph of a communication service interface according to claim 1, characterized in that, For each interface, extract the inclusion relationship between the interface and its parameters, the direct reference relationship between the parameters contained in the interface and the parameters of other interfaces, and the direct calling relationship between the interface and other interfaces from the static code, including: For each interface, the following syntax analysis is performed using a syntax tree parser: Recursively resolve the nested dependencies of the input parameters to obtain the direct reference relationships between the parameters contained in this interface and the parameters of other interfaces; Based on JSON Schema or OpenAPI specifications, construct the inclusion relationship between the interface and the output parameters; By using custom annotations, the direct calling relationships between this interface and other interfaces can be extracted from the interface documentation.

3. The method for constructing a lineage graph of a communication service interface according to claim 1, characterized in that, By tracing the parameter propagation path chain in dynamic traffic and inputting it into an LSTM, the indirect relationships between parameters can be predicted, including: Extract the request-response chain from historical test logs, and construct the parameter propagation path chain from the extracted response chain through regular expression matching and parameter path parsing; The constructed parameter propagation path chain is input into the trained LSTM neural network to predict the indirect relationships in the parameter propagation path chain, obtain the prediction confidence, and extract the indirect relationships between parameters whose prediction confidence is greater than a set value.

4. The method for constructing a lineage graph of a communication service interface according to claim 1, characterized in that, When new test logs are added, the method for constructing the lineage graph of the communication service interface further includes: Extract the interface nodes from the newly added test logs; Node embedding vectors are constructed using the extracted interface nodes and input into Node2Vec to capture the latest call frequency between interfaces; The weights of the corresponding edges are adjusted using the latest captured call frequency.

5. A method for assessing the impact of changes to a communication service interface, characterized in that, include: The communication service interface lineage graph construction method according to claim 1 is used to construct the interface lineage graph; For each changed interface, all changed parameters are identified by parsing the direct reference relationships between the parameters contained in that interface and the parameters of other interfaces. For each changed parameter, the interface lineage graph is used to traverse all interface nodes that can be reached in reverse through the parameter propagation path chain; The path from the changed parameter to the final reachable interface node is used as the propagation path, and the interface nodes and parameter nodes on the propagation path are recorded. Using the recorded interface nodes and parameter nodes, generate a set of influencing paths; Use the set of impact paths to assess the risk of interface changes.

6. The method for assessing the impact of changes to communication service interfaces according to claim 5, characterized in that, Using the set of impact paths to conduct interface change risk assessment, including: Using the weight values ​​on the generated set of impact paths, assess the risk value of this parameter change to the test cases corresponding to the traversed interface nodes; The execution order of regression tests is scheduled according to the risk level to which the risk value belongs.

7. The method for assessing the impact of changes to communication service interfaces according to claim 6, characterized in that, The interface change involves a change in the type of its parameters. Using the weight values ​​on the generated set of impact paths, assess the risk of this parameter change to the test cases corresponding to the traversed interface nodes, including: Define parameter type compatibility matrix This characterizes the degree of impact of different types of changes, among which... ;in, express Parameters in Compatibility after changing from the old type to the new type; Use the following formula to calculate the impact of each test case on the changed parameter P. Risk value calculation : 1- similarity(p) ， in, Represents the first in the interface lineage graph 1 node Represents the first in the interface lineage graph 1 node Indicates the first The node to the first The path of each node falls within the test scope of the calculated test cases. 。 8. The method for assessing the impact of changes to communication service interfaces according to claim 6, characterized in that, Based on the risk level of the risk value, the execution order of regression tests is scheduled, including: When the risk value of a test case exceeds the first set value, it is determined to be high-risk, and an emergency regression is immediately triggered to include the test case in the smoke test set. If the risk value of a test case is greater than the second set value but less than or equal to the first set value, it is determined to be of medium risk and the test case is executed in the regular regression phase. If the risk value of a test case is less than or equal to the second set value, it is determined to be low risk, and the test case is included in the scope of regular inspection.

9. A communication service interface lineage map construction device, characterized in that, Applications in a microservices architecture include: Interface set determination unit, used to determine the interface set; The first relationship determination unit is used to extract, for each interface, the inclusion relationship between the interface and its parameters, the direct reference relationship between the parameters contained in the interface and the parameters of other interfaces, and the direct call relationship between the interface and other interfaces from the static code. The second relation determination unit is used to trace the parameter propagation path chain from dynamic traffic and input it into LSTM to predict the indirect correlation between parameters. The third relation determination unit is used to determine the change impact chain generated by the change of each parameter; The generation unit is used to construct explicit inclusion edges, explicit parameter edges, explicit call edges, implicit parameter edges, and change-affected edges using the inclusion relationship, direct reference relationship, direct call relationship, indirect association relationship, and parameter change-affected chain. For each edge, the weight of the edge is determined based on the frequency of its occurrence in historical calls and / or the priority of the service carried by the interface connected to the edge, thus completing the construction of the interface lineage graph.

10. A device for assessing the impact of changes to a communication service interface, characterized in that, include: The graph generation unit is used to construct an interface lineage graph using the communication service interface lineage graph construction device as described in claim 9. The identification unit is used to identify all changed parameters for each changed interface by parsing the direct reference relationships between the parameters contained in the interface and the parameters of other interfaces. The traversal unit is used to traverse all interface nodes that can be reached in reverse through the parameter propagation path chain for each changed parameter, using the interface lineage graph. The recording unit is used to record the interface nodes and parameter nodes along the propagation path, which is the path from the changed parameter to the finally reachable interface node. The set generation unit is used to generate an influencing set of paths by utilizing the interface nodes and parameter nodes of the path utilization record. The assessment unit is used to assess the risk of interface changes using a set of impact paths.

11. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-8.

12. A computer storage medium, characterized in that, The computer storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1-8.

Images