A method for supporting dynamic assembly and automated testing of software modules across business scenarios

Abstract

The application discloses a kind of software module dynamic assembly and automated testing method supporting cross-service scene, it is related to software engineering field.The method selects software module according to the scene constraint information of target service scene and constructs target module assembly graph;It is structurally matched with historical module assembly graph, determines common assembly subgraph, and according to the coverage relationship of target boundary condition and historical verification boundary condition, reuses historical verification evidence;Test data is generated to the connection edge not covered, and local test path is constructed and executed automated testing;When test fails, based on actual transmission data and module input, output constraint positioning failure connection edge and constraint that is violated, generate scene connection constraint, replace software module according to this and carry out local reassembly and retest, and test pass result forms new historical verification record.The application can reduce cross-scene repeated testing, reduce test and reassembly range, improve dynamic assembly and automated verification efficiency.

Description

Technical Field

[0001] This invention relates to the field of software engineering, and in particular to a method for dynamic assembly and automated testing of software modules that supports cross-business scenarios. Background Technology

[0002] As software systems increasingly move towards modularization, componentization, and service-orientation, software functions are typically broken down into software modules with relatively independent functions and standard interfaces. When facing different business scenarios such as order processing, user authentication, risk control, and resource approval, appropriate software modules can be selected based on business needs and assembled according to the calling and data transfer relationships between modules, thereby shortening the development and deployment cycle of software functions.

[0003] Existing software module assembly methods typically select and connect modules based on their functional identifiers, interface definitions, and dependencies. After assembly, the results are verified through unit testing, interface testing, or regression testing. For module combinations that repeatedly appear in different business scenarios, existing methods generally require re-executing the corresponding tests or simply reusing historical test results based on module identifiers and interface forms. Since the same module combination may correspond to different input ranges, output requirements, module versions, and initial states in different business scenarios, directly reusing historical test results may not accurately reflect the usability of the module combination in the current business scenario. Retesting the entire module assembly result, on the other hand, generates numerous redundant tests, increasing testing time and computational resource consumption.

[0004] Furthermore, existing automated testing methods typically record test cases, abnormal modules, or error messages when tests fail. However, they struggle to combine this information with the field transmission relationships between modules to further pinpoint the specific connection edges that caused the test failure and the violated interface constraints. Therefore, during subsequent business scenario assembly, module connection relationships with the same issues may be generated again. Even if the abnormal module is replaced, it often requires retesting a large range of module call paths, and an effective feedback loop has not yet been formed between historical test results, failure location results, and subsequent module assembly.

[0005] To address this, a method for dynamic assembly and automated testing of software modules across business scenarios is proposed. Summary of the Invention

[0006] The main objective of this invention is to provide a method for dynamic assembly and automated testing of software modules across business scenarios, which can effectively solve the problems in the background art.

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0008] A method for dynamic assembly and automated testing of software modules supporting cross-business scenarios includes the following steps:

[0009] S1. Obtain the scenario constraint information of the target business scenario, select software modules from the module library according to the scenario constraint information, and construct the target module assembly diagram; wherein, the software module has module description information, which includes at least function identifier, version information, input constraints, output constraints and state premises, and the nodes in the target module assembly diagram represent software modules, and the connecting edges represent the calling relationship or data transmission relationship between software modules;

[0010] S2. Obtain historical verification records corresponding to historical business scenarios, and determine a common assembly subgraph based on the structural correspondence between the target module assembly diagram and the historical module assembly diagram in the historical verification records; wherein, the historical verification records include at least the verification status, verification boundary conditions and test pass results of each connecting edge in the historical module assembly diagram, and the verified assembly subgraph is composed of the connecting edges with the verification status of pass and their associated nodes.

[0011] S3. Determine the target boundary conditions of the common assembly subgraph in the target business scenario, and compare the target boundary conditions with the verification boundary conditions of the corresponding verified assembly subgraph; when the target boundary conditions are covered by the verification boundary conditions, determine the test pass result of the verified assembly subgraph as reusable verification evidence of the common assembly subgraph; the coverage at least indicates that the ingress data range defined by the target boundary conditions is included in the verified ingress data range defined by the verification boundary conditions, the egress data range defined by the verification boundary conditions is included in the data range that the target downstream software module can receive, and the target initial state satisfies the premise of the verified state;

[0012] S4. Based on the coverage of the reusable verification evidence, determine the connection edges in the target module assembly diagram that are not covered by the reusable verification evidence as connection edges to be verified; for the connection edges to be verified, generate test data based on the output constraints of the upstream software module and the input constraints of the downstream software module, and extend upstream from the connection edges to be verified to the nearest verified assembly subgraph boundary or the input node of the target module assembly diagram, and extend downstream to the nearest verified assembly subgraph boundary or the output node of the target module assembly diagram to form a local test path and execute automated testing;

[0013] S5. When the automated test fails, the failed connection edge and the violated constraint are determined based on the actual transmitted data, field transmission relationship, output constraint of the upstream software module and input constraint of the downstream software module of each connection edge in the local test path, and a scenario-based connection constraint is generated based on the target business scenario, the failed connection edge and the violated constraint.

[0014] S6. When the automated test passes, the tested assembly subgraph, verification boundary conditions, connection edge verification status, and test pass result corresponding to the local test path are associated and stored to form a new historical verification record. When the automated test fails, a replacement software module is selected from the module library according to the scenario-based connection constraints. The replacement software module is used to replace the software module associated with the failed connection edge. An adjusted module assembly diagram is obtained while retaining other assembly structures in the target module assembly diagram. The affected local path is determined by extending upstream from the replacement software module to the nearest verified assembly subgraph boundary or input node and downstream to the nearest verified assembly subgraph boundary or output node. A retest is performed, and when the retest passes, the corresponding tested assembly subgraph, verification boundary conditions, connection edge verification status, and test pass result are associated and stored to form a new historical verification record.

[0015] Furthermore, the historical verification record is a structured record, including historical module assembly diagram identifiers, node sets, connection edge sets, verification status of each connection edge, version information of each software module, verification boundary conditions, and test result identifiers.

[0016] The determination of the common assembly subgraph includes:

[0017] For the nodes in the target module assembly diagram Nodes in the historical module assembly diagram The node matching degree is calculated according to the following formula:

[0018]

[0019] in, The function matching degree is set to 1 when the function identifiers of the corresponding software modules of the two nodes are the same, and 0 otherwise. The ratio of the number of elements in the intersection to the number of elements in the union of the input interface field sets of two nodes; The ratio of the number of elements in the intersection to the number of elements in the union of the output interface field sets of two nodes;

[0020] Will satisfy and The node pairs are identified as candidate matching node pairs;

[0021] Using the node matching degree as the weight of the candidate matching node pair, perform maximum weighted binary matching to obtain a one-to-one matching node;

[0022] The connecting edges that match the nodes at both ends of the two module assembly graphs, have the same connection direction, and are of the same type are identified as matching connecting edges. The connected subgraphs formed by the mutually connected matching nodes and matching connecting edges are identified as candidate common assembly subgraphs.

[0023] The candidate common assembly subgraph containing the largest number of matching nodes is determined as the common assembly subgraph;

[0024] In this context, the version information of the software module is not used as a matching condition for functional nodes, but is used to determine the coverage relationship of the verification boundary conditions.

[0025] Furthermore, boundary fingerprints are generated for the verification boundary conditions and the target boundary conditions, respectively, and the boundary fingerprints are represented by the following boundary fingerprint model:

[0026]

[0027] in, For the entry constraint feature sequence, For export constraint feature sequences, For module version feature sequences, For the state premise feature sequence, , , and These are the summary values ​​for the corresponding feature sequences;

[0028] The generation of the boundary fingerprint includes:

[0029] The input constraints and output constraints are converted into constraint feature terms. Each constraint feature term includes at least a field identifier, data type, value constraint, precision, unit, null value attribute, and source location identifier. The source location identifier is used to indicate the corresponding software module or connection edge.

[0030] The constraint feature items are sorted and standardized according to the field identifiers to obtain the inlet constraint feature sequence and the outlet constraint feature sequence, respectively.

[0031] The module identifier, major version number, and minor version number are encoded according to the order in which the software modules are called to obtain the module version feature sequence;

[0032] The state premises are sorted and encoded according to the state variable identifiers to obtain the state premise feature sequence; and

[0033] Perform SHA-256 digest operation on each feature sequence to obtain the corresponding digest value;

[0034] The summary value is used for retrieving historical verification records and verifying the integrity of feature sequences. The reuse of verification evidence also requires determining the coverage relationship of verification boundary conditions based on the corresponding feature sequences.

[0035] Furthermore, candidate verification evidence is determined from the historical verification records, including:

[0036] The entry matching degree, exit matching degree, version matching degree, and state matching degree are calculated based on the corresponding feature sequences of the target boundary fingerprint and the historical boundary fingerprint, respectively.

[0037] Specifically, the ratio of the number of identical constraint feature items in two entry constraint feature sequences to the number of the union of constraint feature items is determined as the entry matching degree; the ratio of the number of identical constraint feature items in two exit constraint feature sequences to the number of the union of constraint feature items is determined as the exit matching degree; and the ratio of the number of identical state feature items in two state premise feature sequences to the number of the union of state feature items is determined as the state matching degree.

[0038] The longest common subsequence of two module version feature sequences is determined, and the ratio of the number of software modules with the same module identifier and version number in the longest common subsequence to the number of software modules in the longer module version feature sequence is determined as the version matching degree.

[0039] The boundary candidate matching degree is calculated according to the following formula:

[0040]

[0041] in, For boundary candidate matching degree, For entry matching degree, For export matching degree, For version compatibility, State matching degree;

[0042] Historical verification records with a boundary candidate matching degree greater than or equal to 0.90 are identified as candidate verification evidence;

[0043] For the candidate verification evidence, the target entry constraint is converted into a target entry constraint predicate, the historically verified entry constraint is converted into a historical entry constraint predicate, the historically verified exit constraint is converted into a historical exit constraint predicate, and the input constraint of the target downstream software module is converted into a target receiving constraint predicate.

[0044] When the target entry constraint predicate can derive the historical entry constraint predicate, the historical exit constraint predicate can derive the target receiving constraint predicate, the target initial state satisfies the premise of the historical verified state, and the module version satisfies the preset version compatibility relationship, it is determined that the target boundary condition is covered by the verification boundary condition, and the candidate verification evidence is determined as reusable verification evidence.

[0045] Furthermore, when the target boundary condition of the common assembly subgraph is not covered by the corresponding verification boundary condition, the common assembly subgraph is segmented and reused, including:

[0046] Based on the target boundary fingerprint and the historical boundary fingerprint, inconsistency constraint features are determined, and based on the source location identifier carried by the inconsistency constraint features, the inconsistency constraint features are mapped to the corresponding software module or connection edge.

[0047] The corresponding connecting edge or the entry and exit connecting edges of the corresponding software module are determined as the splitting edge;

[0048] Remove the dividing edge from the common assembly subgraph, and determine each connected component formed after removing the dividing edge as an assembly segment, so that there is no overlap between different assembly segments;

[0049] The connecting edge pointing from the outside of the assembled segment to the inside of the assembled segment is defined as the segment entry edge, and the connecting edge pointing from the inside of the assembled segment to the outside of the assembled segment is defined as the segment exit edge.

[0050] Based on the segment entry edge, segment exit edge, module version and state premise in the assembled segment, a segment boundary fingerprint is generated in accordance with the manner described in claim 3, and it is determined in accordance with the manner described in claim 4 whether the target segment boundary condition corresponding to the assembled segment is covered by the historical segment boundary condition.

[0051] The assembled fragments whose target fragment boundary conditions are covered by the historical fragment boundary conditions are identified as reusable assembled fragments, and the segmentation edges and connection edges not covered by reusable assembled fragments are identified as the connection edges to be verified.

[0052] Furthermore, test data is generated based on the upstream output constraints and downstream input constraints of the connection edge to be verified, including:

[0053] Convert the output constraints of the upstream software module into upstream output constraint predicates. The input constraints of downstream software modules are converted into downstream input constraint predicates. The constraint predicate consists of at least one of the following: data type predicate, numeric range predicate, enumeration predicate, string pattern predicate, null value predicate, and cross-field constraint predicate.

[0054] Construct normal test constraints and conflict test constraints according to the following formula:

[0055]

[0056]

[0057] in, For the connection edge to be verified Normal test constraints, For the connection edge to be verified Conflict test constraints;

[0058] The satisfiability of the normal test constraints and conflict test constraints is solved separately. When the normal test constraints are satisfiable, normal test data is generated using the solutions that satisfy the normal test constraints; when the conflict test constraints are satisfiable, conflict test data is generated using the solutions that satisfy the conflict test constraints.

[0059] Specifically, for numerical range predicates, at least the boundary value, the representative value within the range, and the value that differs from the boundary by one minimum precision unit are selected for solving; for enumerated predicates or string pattern predicates, representative values ​​that satisfy and do not satisfy the corresponding predicates are generated respectively.

[0060] Furthermore, determining the local test path and failed connection edges includes:

[0061] Starting from the connection edge to be verified, traverse upstream to the nearest reusable assembly segment's exit edge or the target module assembly diagram's input node, and traverse downstream to the nearest reusable assembly segment's entry edge or the target module assembly diagram's output node. The traversed connection edges are then arranged into the local test path according to the topology execution order.

[0062] When executing the local test path, the actual transmitted data on each connection edge is collected, and the field transmission relationship of each field in the actual transmitted data from the upstream software module output to the test failure position is recorded to form a data transmission chain corresponding to the test failure result.

[0063] For the connection edge in the data transmission chain The constraint anomaly flag is calculated using the following formula:

[0064]

[0065] in, For connecting edges The actual data transmitted on the platform For the output constraint predicates corresponding to the upstream software modules, These are the input constraint predicates for the corresponding downstream software modules;

[0066] The data transmission chain is first satisfied according to the topological execution order. The connecting edge is determined to be the failed connecting edge;

[0067] When the actual transmitted data does not satisfy the output constraint predicate of the upstream software module, the upstream output constraint predicate with a false value is identified as a violated constraint; when the actual transmitted data satisfies the output constraint predicate of the upstream software module but does not satisfy the input constraint predicate of the downstream software module, the downstream input constraint predicate with a false value is identified as a violated constraint.

[0068] Furthermore, the scenario-based connection constraint is expressed by the following formula:

[0069]

[0070] in, To identify the scene characteristics of the target business scenario. and These are the upstream software module identifier and version of the failed connection edge, respectively. and These are the downstream software module identifier and version of the failed connection edge, respectively. For the violated constraint identifier, A trigger data predicate generated based on the actual transmitted data that caused the constraint violation;

[0071] When the scenario feature identifier of the business scenario to be assembled, the identifier and version of the software module to be connected match the scenario-based connection constraint, and the data constraint of the connection edge to be established and the conjunction result of the triggering data predicate can be satisfied, the scenario-based connection constraint takes effect and restricts the establishment of the corresponding connection edge.

[0072] Select software modules from the module library that meet the functional requirements of the target business scenario, do not trigger the scenario-based connection constraints, and whose output constraints of the upstream software module can deduce the input constraints of the candidate software module, and whose output constraints of the candidate software module can deduce the input constraints of the downstream software module, to form a candidate module set;

[0073] For candidate software modules The cost of local assembly adjustment is calculated using the following formula:

[0074]

[0075] in, To add candidate software modules The number of connected edges that were not covered by reusable verification evidence. To add candidate software modules The total number of connecting edges in the final module assembly diagram. This represents the number of nodes that have changed relative to the target module assembly diagram. To add candidate software modules The total number of nodes in the final module assembly diagram;

[0076] The candidate software module with the lowest local assembly adjustment cost is selected as the replacement software module, and a retest is performed on the affected local path. When the retest passes, a new historical verification record is generated. When the retest fails, the scenario-based connection constraints are updated according to the re-determined failed connection edges and the violated constraints. The replacement software module is then reselected from the candidate software modules that have not yet been excluded by the scenario-based connection constraints.

[0077] A software module dynamic assembly and automated testing system supporting cross-business scenarios includes:

[0078] An assembly diagram construction module is used to obtain scenario constraint information of the target business scenario and construct a target module assembly diagram based on the scenario constraint information and the module description information of the software module.

[0079] The verification evidence reuse module is used to acquire historical verification records, determine the common assembly subgraph between the target module assembly diagram and the historical module assembly diagram, and determine reusable verification evidence based on the coverage relationship between the target boundary conditions and the verification boundary conditions.

[0080] The local testing module is used to determine the connection edges to be verified based on the coverage of reusable verification evidence, generate test data and local test paths, and execute automated tests.

[0081] The connection constraint generation module is used to determine failed connection edges and violated constraints based on the actual transmitted data, field transmission relationships, and the input and output constraints of the software module when automated tests fail, and to generate scenario-based connection constraints; and

[0082] The local reassembly module is used to select and replace software modules according to the scenario-based connection constraints, form an adjusted module assembly diagram, perform retesting on the affected local paths, and generate new historical verification records based on the test pass results.

[0083] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method steps.

[0084] Compared with the prior art, the present invention has the following beneficial effects:

[0085] 1. This invention determines the common assembly subgraph based on the structural correspondence between the target module assembly diagram and the historical module assembly diagram, and determines whether the historical test results can be reused by the coverage relationship between the target boundary conditions and the historical verification boundary conditions. This can avoid directly reusing test results based solely on module name or interface form, and improve the reliability of reusing verification evidence across business scenarios.

[0086] 2. The present invention determines the connection edge to be verified based on the coverage of reusable verification evidence, and forms a local test path between the boundaries of the verified assembly subgraph, so that the test scope is focused on the connection relationship of newly added, changed or unverified modules, reducing the repeated testing of the verified assembly structure.

[0087] 3. This invention combines actual data transmission, field transmission relationships, and input and output constraints of upstream and downstream software modules to determine failed connection edges and specific constraints that are violated. Compared with only locating abnormal test cases or abnormal modules, it can improve the accuracy of locating test failure locations and the causes of constraint conflicts.

[0088] 4. This invention generates scenario-based connection constraints based on the target business scenario, failed connection edges, and violated constraints. It then uses these connection constraints to select replacement software modules and determine affected local retest paths, thereby reducing the probability of the same incompatible connection relationships being repeatedly assembled. After the retest is passed, a new historical verification record is formed, creating a closed loop between module assembly, automated testing, and verification evidence updates. Attached Figure Description

[0089] Figure 1 This is a schematic diagram of the method flow of the present invention;

[0090] Figure 2 This is a schematic diagram of the system modules of the present invention. Detailed Implementation

[0091] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0092] Example 1

[0093] like Figure 1-2 As shown, a method for dynamic assembly and automated testing of software modules that supports cross-business scenarios is described. In this embodiment, a business scenario refers to a software operation process jointly defined by business objectives, data conditions, module call order, and state conditions. A software module refers to a software unit that can independently provide preset functions and connect to other software modules through an interface. It can be a component, plugin, microservice, or an independently callable program unit.

[0094] The module assembly diagram is represented as a directed graph. ,in, It is a set of nodes, and each node corresponds to a software module; It is a set of connecting edges, each connecting edge representing a calling relationship or data transfer relationship between two software modules.

[0095] Each software module has corresponding module description information, including at least a function identifier, version information, input constraints, output constraints, and state prerequisites. Input constraints are used to limit the data types, fields, value ranges, and state conditions that the software module can receive. Output constraints are used to limit the type, fields, and value range of the data output by the software module. State prerequisites are used to limit the business or operational states that the software module must meet before it can run.

[0096] In this embodiment, we will use a regular order processing scenario and a marketing order processing scenario as examples for illustration. The historical business scenario is a regular order processing scenario, and its module call order is as follows:

[0097] Authentication module Risk assessment module Payment module Notification module .

[0098] The target business scenario is a marketing order processing scenario, and the module call order is as follows:

[0099] Authentication module Risk assessment module Discount Calculation Module Payment module Notification module .

[0100] S1. Construct the target module assembly diagram

[0101] Obtain scenario constraint information for the marketing order processing scenario. The scenario constraint information includes: completing user identity verification, completing order risk assessment, calculating the discount amount according to marketing rules, executing order payment, and sending payment notification; the order amount is denominated in RMB, the payment amount is a non-empty value, and the data precision does not exceed two decimal places; before executing payment, the order status is pending payment, and the risk status is passed.

[0102] Based on the scenario constraints, select an authentication module from the module library. Risk assessment module Discount Calculation Module Payment module and notification module And construct the target module assembly diagram according to the data transmission relationship.

[0103] For example, the discount calculation module The output fields include the discounted amount, currency, and discount type; Payment module The input fields include payment amount, currency, order identifier, and payment status. The discounted amount is mapped to the payment amount, the currency field is passed directly, and the order identifier is passed from the context.

[0104] The module's input and output constraints are stored in a structured manner. For example, the input constraint for the payment amount field can be represented as:

[0105] The data type is decimal; the value range is greater than or equal to 0.01 and less than or equal to 100000; the data precision does not exceed two decimal places; the data unit is RMB yuan; empty values ​​are not allowed.

[0106] For string fields, constraints can be represented by length ranges, enumeration sets, or regular expressions; for JSON or XML structured data, the structured data can be split into multiple field constraints, and the relationships between fields can be recorded through cross-field constraints.

[0107] S2. Determine the common assembly subgraph

[0108] Retrieve historical verification records corresponding to typical order processing scenarios. These historical verification records are structured data records and can be stored in a relational database, a graph database, or a verification evidence base formed by a combination of both.

[0109] A historical verification record must include at least:

[0110] Historical module assembly diagram identifier; node set and module version information; connection edge set; verification status of each connection edge; verification boundary conditions; test result identifier; test execution trajectory identifier.

[0111] The verification status of a connection edge includes unverified, verified, and verified failed. A verified assembly subgraph is formed by connections with a verified status of "verified" and their associated nodes. Therefore, the verified assembly subgraph is part of the historical module assembly graph, not a separate assembly graph stored independently of the historical module assembly graph.

[0112] For nodes in the target module assembly diagram Nodes in the historical module assembly diagram Calculate node matching degree:

[0113]

[0114] in, For functional matching degree, the value is 1 when the standardized functional identifiers of the two software modules are the same, and 0 otherwise. The intersection-union ratio of the input interface field set; This is the intersection-union ratio of the output interface field set.

[0115] For example, if the risk assessment module function identifier is the same in the target module assembly diagram and the historical module assembly diagram, the input interface fields are exactly the same, and there are 4 identical fields in the output interface fields, and the target module has an additional optional field, then:

[0116] , ,

[0117] The matching degree of the corresponding node is:

[0118]

[0119] Since the node matching degree is greater than 0.85, the two risk assessment modules are identified as candidate matching nodes.

[0120] Setting the node matching threshold to 0.85 requires that, when the function identifiers are the same, the average value of the input interface matching degree and the output interface matching degree must reach 0.70 or higher, thereby excluding modules with the same function name but significantly different interfaces.

[0121] Candidate matching node pairs are used as candidate edges in the bipartite graph, and the node matching degree is used as the corresponding weight. The maximum weighted bipartite matching algorithm is used to obtain one-to-one matching nodes. The direction and type of the connecting edges between matching nodes are further compared to obtain matching connecting edges. The interconnected matching nodes and matching connecting edges form a common assembled subgraph.

[0122] In this embodiment, the authentication module and risk assessment module This constitutes the first common assembly sub-graph, the payment module. and notification module This forms the second common assembly subgraph. A discount calculation module has been added due to the target business scenario. In historical business scenarios, the direct connection edge between the risk assessment module and the payment module does not belong to the matching connection edge in the target module assembly graph.

[0123] Module version information is not involved in the initial matching of functional nodes. For example, versions 2.1 and 2.2 of the same functional module can be identified as matching nodes first, and then it can be determined whether the two satisfy the version compatibility relationship during the evidence reuse verification stage.

[0124] S3. Identify reusable verification evidence

[0125] For the shared assembly subgraph, target boundary fingerprints and historical boundary fingerprints are generated separately. The boundary fingerprints are represented as follows:

[0126]

[0127] in, For the entry constraint feature sequence, For export constraint feature sequences, For module version feature sequences, For the state premise feature sequence, , , and These are the summary values ​​for the corresponding feature sequences.

[0128] When generating boundary fingerprints, input and output constraints are converted into constraint feature terms. Each constraint feature term records the field identifier, data type, value constraints, precision, unit, null value attribute, and source location identifier. The source location identifier indicates which software module or connection edge the constraint feature term originates from, providing a mapping basis for subsequent segmentation and reuse.

[0129] For example, the constraint feature term of the payment amount can be represented as:

[0130] "payment_amount, decimal, [0.01, 100000], 2, CNY, not-null, E53".

[0131] E53 represents the discount calculation module. To payment module The connecting edge.

[0132] Perform SHA-256 digest operation on each feature sequence to obtain the corresponding digest value. The digest value is mainly used for quickly retrieving historical verification records and verifying whether the feature sequence has changed. It is not used as the final basis for verifying evidence reuse based solely on identical digest values. Even if the digest values ​​are the same, it is still necessary to determine the coverage relationship between the target boundary conditions and the historical verification boundary conditions.

[0133] Calculate the candidate boundary matching degree based on the target boundary fingerprint and historical boundary fingerprints:

[0134]

[0135] The weights for both entry and exit matching are set to 0.35 because whether the module assembly result can be used in the target business scenario depends mainly on the data that the entry point of the assembly subgraph can receive and the data that the exit point can provide; the weight for version matching is set to 0.20 to reflect the impact of module version changes; and the weight for state matching is set to 0.10 to perform candidate filtering for state premises.

[0136] The threshold of 0.90 is only used to screen candidate validation evidence and does not directly determine whether historical test results can be reused. In practical applications, historical samples marked as reusable and non-reusable can be used to select a parameter combination that can control the false reuse rate and has a high candidate recall rate by traversing candidate weights and thresholds. This embodiment uses the above-mentioned weights and 0.90 as the candidate screening threshold.

[0137] For example, if the entry matching degree of the first common assembly subgraph is 1, the exit matching degree is 0.95, the version matching degree is 1, and the state matching degree is 1, then:

[0138]

[0139] Therefore, this historical verification record was identified as candidate verification evidence.

[0140] Boundary condition coverage is then determined. The target ingress constraint is converted into a target ingress constraint predicate. Convert historically verified entry constraints into historical entry constraint predicates. To determine whether the target ingress data range is included within the historically verified ingress data range, we can check if the following conjunctive expression is unsatisfactory:

[0141]

[0142] When the expression cannot be satisfied, it indicates that the data that satisfies the target entry constraint also satisfies the historically verified entry constraint, that is, the target entry data range is included in the historically verified entry data range.

[0143] Similarly, historically proven export constraints can be transformed into... The input constraints of the target downstream software module are converted into target receiving constraint predicates. When the current expression cannot be satisfied:

[0144]

[0145] This indicates that historically verified export data can be received by the target downstream software module.

[0146] Version compatibility can be determined using a preset version compatibility table. In this embodiment, when module versions are completely identical, or the major version number is the same and the module description information is marked as backward compatible, the module versions are determined to satisfy the version compatibility relationship. For example, when version 2.2 declares compatibility with the interfaces and status rules of version 2.1, the verification evidence corresponding to version 2.1 can be reused; when the major version number changes and compatibility is not declared, the corresponding verification evidence is not reused.

[0147] The initial state of the target is obtained from the context state of the target business scenario or a runtime snapshot. For example, the risk assessment module requires the order status to be pending review before execution, and the payment module requires the order status to be pending payment and the risk status to be approved before execution. When the initial state of the target meets the prerequisite of the verified status in the historical verification record, the state coverage judgment passes.

[0148] When the entry scope, exit scope, version relationship, and state premise all meet the requirements, the candidate verification evidence is determined as reusable verification evidence.

[0149] When the overall assembled subgraph does not meet the coverage condition, it is mapped to the corresponding module or connecting edge based on the source location identifier carried by the inconsistency feature, and the corresponding connecting edge or the ingress and egress connecting edges of the corresponding module are determined as split edges. After removing the split edges, each connected component constitutes a non-overlapping assembled segment.

[0150] For each assembled segment, the connection edges pointing from the outside of the segment to the inside are determined as segment entry edges, and the connection edges pointing from the inside of the segment to the outside are determined as segment exit edges. Then, segment boundary fingerprints are generated based on the segment entry edges, segment exit edges, module version, and state prerequisites. Thus, intermediate assembled segments also have clearly defined entry and exit conditions. Assembled segments that meet the coverage conditions are determined as reusable assembled segments, while split edges and other uncovered connection edges are determined as connection edges to be verified.

[0151] When there are no historical verification records that meet the conditions, all connecting edges in the target module assembly diagram are determined as connecting edges to be verified.

[0152] S4. Generate and execute local tests.

[0153] In this embodiment, the assembly segments from the identity verification module to the risk assessment module and from the payment module to the notification module have reusable verification evidence. Therefore, the connection edge E25 from the risk assessment module to the discount calculation module and the connection edge E53 from the discount calculation module to the payment module are connection edges to be verified.

[0154] Extending upstream from E25 and E53 to the exit edge of the first reusable assembly segment, and downstream to the entry edge of the second reusable assembly segment, a local test path is obtained:

[0155] Risk assessment module Discount Calculation Module Payment module .

[0156] For edge E53, the output constraints of the preferential calculation module are converted into upstream output constraint predicates: Transform the input constraints of the payment module into downstream input constraint predicates:

[0157] The constraint predicates may include data type predicates, numeric range predicates, enumeration predicates, string pattern predicates, null value predicates, and cross-field constraint predicates.

[0158] Normal test constraints and conflict test constraints are as follows:

[0159]

[0160]

[0161] The constraint solver is used to determine the satisfiability of the above constraints. The constraint solver can be a satisfiability modular theory solver, or it can call a numerical range solver, an enumeration solver, or a string pattern solver based on the field type.

[0162] Taking the discounted amount field as an example, the discount calculation module allows output of amounts from 0 to 500 yuan with a precision of no more than three decimal places, while the payment module allows receiving amounts from 0.01 to 100,000 yuan with a precision of no more than two decimal places. The constraint solver can generate 88.88 as normal test data and 88.888 as conflict test data.

[0163] For continuous numerical ranges, at least the lower boundary value, upper boundary value, representative value within the range, and value differing from the boundary by one minimum data precision unit should be selected; for enumerated fields, representative values ​​should be selected from the values ​​that satisfy and do not satisfy the enumeration set respectively; for string pattern fields, regular expressions can be used to generate strings that satisfy and do not satisfy the corresponding pattern; for structured data, the predicates of each field and cross-field predicates should be combined and solved uniformly.

[0164] When executing a local test path, a test trajectory identifier is generated for each test, and the actual transmitted data, data field mapping relationship, module version and running status are recorded at each connection edge.

[0165] S5. Identify failed connection edges and generate scenario-based connection constraints.

[0166] When executing the conflict test case, the discount calculation module outputs a discounted amount of 88.888 yuan. This data satisfies the output constraints of the discount calculation module itself, but does not meet the input constraint of the payment module that the payment amount must not exceed two decimal places.

[0167] Based on the interface mapping information and runtime trajectory, establish the following field transmission relationships:

[0168] Original order amount, discount calculation input amount, discounted amount, and payment amount.

[0169] This field passes a relationship that forms a data transmission chain corresponding to the test failure result.

[0170] For the connection edge in the data transmission chain Calculate constraint anomaly indicators:

[0171]

[0172] In this embodiment, the actual data transmitted on connection edge E53 satisfies the output constraints of the discount calculation module, but does not satisfy the input constraints of the payment module. Therefore... Edge E53 is the first connection edge in the data transmission chain to exhibit a constraint anomaly according to the topology execution order. Therefore, E53 is identified as a failed connection edge, and the constraint "payment amount precision does not exceed two decimal places" in the payment module input constraints is identified as a violated constraint.

[0173] If the actual transmitted data does not meet the output constraints of the upstream software module itself, the corresponding upstream output constraint is identified as a violated constraint; if the actual transmitted data meets the upstream output constraints but does not meet the downstream input constraints, the corresponding downstream input constraint is identified as a violated constraint. This allows for the differentiation between module-specific output anomalies and incompatibility between module connection edge interfaces.

[0174] Generate scenario-based connection constraints based on the target business scenario, failed connection edges, and violated constraints:

[0175]

[0176] In this embodiment:

[0177] To identify the scene characteristics of the target business scenario. and These are the identifier for the discount calculation module and version 1.3, respectively. and These are the payment module identifier and version 2.2, respectively. For payment amount precision constraint identifier, To trigger the data predicate.

[0178] The triggering data predicate can be represented as: the discount type is a percentage discount, the currency is RMB, and the discounted amount includes three decimal places.

[0179] In this embodiment, the "data constraints of the connection edge to be established" specifically refers to the constraint predicate formed by the output constraints of the upstream software module of the connection edge to be established and the data constraints added by the target business scenario. This constraint predicate is joined with the triggering data predicate, and it is determined whether they can be satisfied.

[0180] The scenario-based connection constraint takes effect only when the scenario feature identifier, module identifier, and version of the scenario to be assembled all match the scenario-based connection constraint, and the connection edge to be established may generate data that satisfies the triggering data predicate. Therefore, this constraint does not permanently prohibit the connection between the discount calculation module and the payment module. For example, if another business scenario has already set up amount rounding processing after the discount calculation module, making it impossible for three-decimal-point amounts to be transmitted to the payment module, the conjunction result of the triggering data predicate and the data constraint of the connection edge to be established cannot be satisfied, and the scenario-based connection constraint will not take effect.

[0181] S6, Partial Reassembly and Retesting

[0182] After the scenario-based connectivity constraints take effect, a replacement software module is selected from the module library. The candidate software module must meet the following requirements:

[0183] Provides the same business functions as the discount calculation module; does not trigger existing scenario-based connection constraints; the output constraints of the upstream risk judgment module can derive the input constraints of the candidate software module; the output constraints of the candidate software module can derive the input constraints of the downstream payment module; the state prerequisites of the candidate software module can be satisfied by the current business scenario state.

[0184] For candidate software modules Calculate the cost of local assembly adjustment:

[0185]

[0186] in, This represents the number of connection edges that are not covered by reusable verification evidence after being added to the candidate software module. To adjust the total number of connecting edges in the module assembly diagram, This represents the number of nodes that have changed relative to the target module assembly diagram before adjustment. This represents the total number of nodes in the adjusted module assembly diagram.

[0187] Normalizing the number of connected edges and the number of changed nodes is to avoid the calculation results being affected by differences in their values. A weight of 0.70 is used to prioritize reducing newly added connected edges to be verified, thereby controlling the scope of retesting; a weight of 0.30 is used to reduce changes in the module assembly structure.

[0188] For example, if the first candidate module is the discount calculation module version 1.4, and the adjusted module assembly graph has 4 connecting edges and 5 nodes, of which 2 connecting edges need to be re-verified and 1 node has changed, then:

[0189]

[0190] The second candidate module is the discount calculation module version 2.0. This version requires replacing an associated adaptation module. After adjustment, it has 4 connecting edges and 5 nodes, of which 3 connecting edges need to be re-verified, and 2 nodes have changed. Therefore:

[0191]

[0192] Therefore, the preferential calculation module version 1.4, which has a lower cost for local assembly and adjustment, was chosen as the replacement software module.

[0193] The discount calculation module version 1.4 performs rounding processing according to the smallest payment unit of RMB before outputting the amount, and its output constraint limits the precision of the discounted amount to no more than two decimal places.

[0194] After replacing version 1.3 with version 1.4 of the discount calculation module, the process extends downstream from the boundary of the verified assembly subgraph corresponding to the risk assessment module to the boundary of the verified assembly subgraph corresponding to the payment module, identifies the affected local paths, and re-executes normal test cases and conflict test cases.

[0195] During the retest, the discount calculation module output 88.89 yuan, satisfying its output constraints and the input constraints of the payment module, thus passing the partial retest. The adjusted partial assembly subgraph, entry boundary conditions, exit boundary conditions, module version information, state prerequisites, connection edge verification status, test case identifiers, and test pass results are associated and stored to form a new historical verification record.

[0196] New historical verification records can be used for subsequent business scenarios. When a subsequent business scenario has the same or similar assembly structure as the record, the record is first filtered using the boundary candidate matching degree, and then its reuse is determined by verifying the boundary condition coverage.

[0197] If the retest fails, the scenario-based connection constraints are updated based on the new actual transmitted data, field transmission relationships, and violated constraints. A replacement software module is then selected from the remaining candidate software modules. When the candidate module set is empty, local reassembly is stopped, and the current target module assembly graph is marked as having no assembly result that satisfies the constraints.

[0198] System Implementation

[0199] This embodiment also provides a software module dynamic assembly and automated testing system that supports cross-business scenarios, including an assembly diagram construction module, a verification evidence reuse module, a local testing module, a connection constraint generation module, and a local reassembly module.

[0200] The assembly diagram construction module is used to read scene constraint information and module description information, select software modules, and create target module assembly diagrams.

[0201] The verification evidence reuse module is used to read historical verification records from the verification evidence library and perform joint assembly subgraph matching, boundary fingerprint generation, candidate verification evidence screening, and verification boundary condition coverage judgment.

[0202] The local testing module is used to identify the connection edges to be verified, generate normal test data and conflict test data through the constraint solver, determine the local test path, and execute automated tests.

[0203] The connection constraint generation module is used to collect actual transmitted data and field transmission relationships, determine failed connection edges, violated constraints and triggering data predicates, and form scenario-based connection constraints.

[0204] The local reassembly module is used to filter candidate software modules based on scenario-based connectivity constraints, calculate the local assembly adjustment cost, select replacement software modules and perform local retesting, and update historical verification records based on the retesting results.

[0205] The system described above can be deployed on servers, cloud computing nodes, or test management platforms. Each module in the system can be implemented by an independent program, or by one or more processors executing a computer program stored in memory.

[0206] This embodiment also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the above-mentioned method for dynamic assembly and automated testing of software modules supporting cross-business scenarios.

[0207] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A method for dynamic assembly and automated testing of software modules supporting cross-business scenarios, characterized in that, Includes the following steps: S1. Obtain the scenario constraint information of the target business scenario, select software modules from the module library according to the scenario constraint information, and construct the target module assembly diagram; wherein, the software module has module description information, which includes at least function identifier, version information, input constraints, output constraints and state premises, and the nodes in the target module assembly diagram represent software modules, and the connecting edges represent the calling relationship or data transmission relationship between software modules; S2. Obtain historical verification records corresponding to historical business scenarios, and determine a common assembly subgraph based on the structural correspondence between the target module assembly diagram and the historical module assembly diagram in the historical verification records; wherein, the historical verification records include at least the verification status, verification boundary conditions and test pass results of each connecting edge in the historical module assembly diagram, and the verified assembly subgraph is composed of the connecting edges with the verification status of pass and their associated nodes. S3. Determine the target boundary conditions of the common assembly subgraph in the target business scenario, and compare the target boundary conditions with the verification boundary conditions of the corresponding verified assembly subgraph; when the target boundary conditions are covered by the verification boundary conditions, determine the test pass result of the verified assembly subgraph as reusable verification evidence of the common assembly subgraph; the coverage at least indicates that the ingress data range defined by the target boundary conditions is included in the verified ingress data range defined by the verification boundary conditions, the egress data range defined by the verification boundary conditions is included in the data range that the target downstream software module can receive, and the target initial state satisfies the premise of the verified state; S4. Based on the coverage of the reusable verification evidence, determine the connection edges in the target module assembly diagram that are not covered by the reusable verification evidence as connection edges to be verified; for the connection edges to be verified, generate test data based on the output constraints of the upstream software module and the input constraints of the downstream software module, and extend upstream from the connection edges to be verified to the nearest verified assembly subgraph boundary or the input node of the target module assembly diagram, and extend downstream to the nearest verified assembly subgraph boundary or the output node of the target module assembly diagram to form a local test path and execute automated testing; S5. When the automated test fails, the failed connection edge and the violated constraint are determined based on the actual transmitted data, field transmission relationship, output constraint of the upstream software module and input constraint of the downstream software module of each connection edge in the local test path, and a scenario-based connection constraint is generated based on the target business scenario, the failed connection edge and the violated constraint. S6. When the automated test passes, the tested assembly subgraph, verification boundary conditions, connection edge verification status, and test pass result corresponding to the local test path are associated and stored to form a new historical verification record. When the automated test fails, a replacement software module is selected from the module library according to the scenario-based connection constraints. The replacement software module is used to replace the software module associated with the failed connection edge. An adjusted module assembly diagram is obtained while retaining other assembly structures in the target module assembly diagram. The affected local path is determined by extending upstream from the replacement software module to the nearest verified assembly subgraph boundary or input node and downstream to the nearest verified assembly subgraph boundary or output node. A retest is performed, and when the retest passes, the corresponding tested assembly subgraph, verification boundary conditions, connection edge verification status, and test pass result are associated and stored to form a new historical verification record.

2. The method for dynamic assembly and automated testing of software modules supporting cross-business scenarios as described in claim 1, characterized in that, The historical verification record is a structured record, including historical module assembly diagram identifiers, node sets, connection edge sets, verification status of each connection edge, version information of each software module, verification boundary conditions, and test result identifiers. The determination of the common assembly subgraph includes: For the nodes in the target module assembly diagram Nodes in the historical module assembly diagram The node matching degree is calculated according to the following formula: in, The function matching degree is set to 1 when the function identifiers of the corresponding software modules of the two nodes are the same, and 0 otherwise. The ratio of the number of elements in the intersection to the number of elements in the union of the input interface field sets of two nodes; The ratio of the number of elements in the intersection to the number of elements in the union of the output interface field sets of two nodes; Will satisfy and The node pairs are identified as candidate matching node pairs; Using the node matching degree as the weight of the candidate matching node pair, perform maximum weighted binary matching to obtain a one-to-one matching node; The connecting edges that match the nodes at both ends of the two module assembly graphs, have the same connection direction, and are of the same type are identified as matching connecting edges. The connected subgraphs formed by the mutually connected matching nodes and matching connecting edges are identified as candidate common assembly subgraphs. The candidate common assembly subgraph containing the largest number of matching nodes is determined as the common assembly subgraph; In this context, the version information of the software module is not used as a matching condition for functional nodes, but is used to determine the coverage relationship of the verification boundary conditions.

3. The method for dynamic assembly and automated testing of software modules supporting cross-business scenarios as described in claim 1, characterized in that, Boundary fingerprints are generated for the verification boundary conditions and the target boundary conditions, respectively, and the boundary fingerprints are represented by the following boundary fingerprint model: in, For the entry constraint feature sequence, For export constraint feature sequences, For module version feature sequences, For the state premise feature sequence, , , and These are the summary values ​​for the corresponding feature sequences; The generation of the boundary fingerprint includes: The input constraints and output constraints are converted into constraint feature terms. Each constraint feature term includes at least a field identifier, data type, value constraint, precision, unit, null value attribute, and source location identifier. The source location identifier is used to indicate the corresponding software module or connection edge. The constraint feature items are sorted and standardized according to the field identifiers to obtain the inlet constraint feature sequence and the outlet constraint feature sequence, respectively. The module identifier, major version number, and minor version number are encoded according to the calling order of the software modules to obtain the module version feature sequence; The state premises are sorted and encoded according to the state variable identifiers to obtain the state premise feature sequence; and Perform SHA-256 digest operation on each feature sequence to obtain the corresponding digest value; The summary value is used for retrieving historical verification records and verifying the integrity of feature sequences. The reuse of verification evidence also requires determining the coverage relationship of verification boundary conditions based on the corresponding feature sequences.

4. The method for dynamic assembly and automated testing of software modules supporting cross-business scenarios as described in claim 3, characterized in that, Determining candidate verification evidence from the historical verification records includes: The entry matching degree, exit matching degree, version matching degree, and state matching degree are calculated based on the corresponding feature sequences of the target boundary fingerprint and the historical boundary fingerprint, respectively. Specifically, the ratio of the number of identical constraint feature items in two entry constraint feature sequences to the number of the union of constraint feature items is determined as the entry matching degree; the ratio of the number of identical constraint feature items in two exit constraint feature sequences to the number of the union of constraint feature items is determined as the exit matching degree; and the ratio of the number of identical state feature items in two state premise feature sequences to the number of the union of state feature items is determined as the state matching degree. The longest common subsequence of two module version feature sequences is determined, and the ratio of the number of software modules with the same module identifier and version number in the longest common subsequence to the number of software modules in the longer module version feature sequence is determined as the version matching degree. The boundary candidate matching degree is calculated according to the following formula: in, For boundary candidate matching degree, For entry matching degree, For export matching degree, For version compatibility, State matching degree; Historical verification records with a boundary candidate matching degree greater than or equal to 0.90 are identified as candidate verification evidence; For the candidate verification evidence, the target entry constraint is converted into a target entry constraint predicate, the historically verified entry constraint is converted into a historical entry constraint predicate, the historically verified exit constraint is converted into a historical exit constraint predicate, and the input constraint of the target downstream software module is converted into a target receiving constraint predicate. When the target entry constraint predicate can derive the historical entry constraint predicate, the historical exit constraint predicate can derive the target receiving constraint predicate, the target initial state satisfies the premise of the historical verified state, and the module version satisfies the preset version compatibility relationship, it is determined that the target boundary condition is covered by the verification boundary condition, and the candidate verification evidence is determined as reusable verification evidence.

5. The method for dynamic assembly and automated testing of software modules supporting cross-business scenarios according to claim 4, characterized in that, When the target boundary condition of the common assembly subgraph is not covered by the corresponding verification boundary condition, the common assembly subgraph is segmented and reused, including: Based on the target boundary fingerprint and the historical boundary fingerprint, inconsistency constraint features are determined, and based on the source location identifier carried by the inconsistency constraint features, the inconsistency constraint features are mapped to the corresponding software module or connection edge. The corresponding connecting edge or the entry and exit connecting edges of the corresponding software module are determined as the splitting edge; Remove the dividing edge from the common assembly subgraph, and determine each connected component formed after removing the dividing edge as an assembly segment, so that there is no overlap between different assembly segments; The connecting edge pointing from the outside of the assembled segment to the inside of the assembled segment is defined as the segment entry edge, and the connecting edge pointing from the inside of the assembled segment to the outside of the assembled segment is defined as the segment exit edge. Based on the segment entry edge, segment exit edge, module version and state premise in the assembled segment, a segment boundary fingerprint is generated in accordance with the manner described in claim 3, and it is determined in accordance with the manner described in claim 4 whether the target segment boundary condition corresponding to the assembled segment is covered by the historical segment boundary condition. The assembled fragments whose target fragment boundary conditions are covered by the historical fragment boundary conditions are identified as reusable assembled fragments, and the segmentation edges and connection edges not covered by reusable assembled fragments are identified as the connection edges to be verified.

6. The method for dynamic assembly and automated testing of software modules supporting cross-business scenarios according to claim 5, characterized in that, Test data is generated based on the upstream output constraints and downstream input constraints of the connection edge to be verified, including: Convert the output constraints of the upstream software module into upstream output constraint predicates. The input constraints of downstream software modules are converted into downstream input constraint predicates. The constraint predicate consists of at least one of the following: data type predicate, numeric range predicate, enumeration predicate, string pattern predicate, null value predicate, and cross-field constraint predicate. Construct normal test constraints and conflict test constraints according to the following formula: in, For the connection edge to be verified Normal test constraints, For the connection edge to be verified Conflict test constraints; The satisfiability of the normal test constraints and conflict test constraints is solved separately. When the normal test constraints are satisfiable, normal test data is generated using the solutions that satisfy the normal test constraints; when the conflict test constraints are satisfiable, conflict test data is generated using the solutions that satisfy the conflict test constraints. Specifically, for numerical range predicates, at least the boundary value, the representative value within the range, and the value that differs from the boundary by one minimum precision unit are selected for solving; for enumerated predicates or string pattern predicates, representative values ​​that satisfy and do not satisfy the corresponding predicates are generated respectively.

7. The method for dynamic assembly and automated testing of software modules supporting cross-business scenarios according to claim 6, characterized in that, The determination of local test paths and failed connection edges includes: Starting from the connection edge to be verified, traverse upstream to the nearest reusable assembly segment's exit edge or the target module assembly diagram's input node, and traverse downstream to the nearest reusable assembly segment's entry edge or the target module assembly diagram's output node. The traversed connection edges are then arranged into the local test path according to the topology execution order. When executing the local test path, the actual transmitted data on each connection edge is collected, and the field transmission relationship of each field in the actual transmitted data from the upstream software module output to the test failure position is recorded to form a data transmission chain corresponding to the test failure result. For the connection edge in the data transmission chain The constraint anomaly flag is calculated using the following formula: in, For connecting edges The actual data transmitted on the platform For the output constraint predicates corresponding to the upstream software modules, These are the input constraint predicates for the corresponding downstream software modules; The data transmission chain is first satisfied according to the topological execution order. The connecting edge is determined to be the failed connecting edge; When the actual transmitted data does not satisfy the output constraint predicate of the upstream software module, the upstream output constraint predicate with a false value is identified as a violated constraint; when the actual transmitted data satisfies the output constraint predicate of the upstream software module but does not satisfy the input constraint predicate of the downstream software module, the downstream input constraint predicate with a false value is identified as a violated constraint.

8. The method for dynamic assembly and automated testing of software modules supporting cross-business scenarios according to claim 7, characterized in that, The scenario-based connection constraint is expressed by the following formula: in, To identify the scene characteristics of the target business scenario. and These are the upstream software module identifier and version of the failed connection edge, respectively. and These are the downstream software module identifier and version of the failed connection edge, respectively. For the violated constraint identifier, A trigger data predicate generated based on the actual transmitted data that caused the constraint violation; When the scenario feature identifier of the business scenario to be assembled, the identifier and version of the software module to be connected match the scenario-based connection constraint, and the data constraint of the connection edge to be established and the conjunction result of the triggering data predicate can be satisfied, the scenario-based connection constraint takes effect and restricts the establishment of the corresponding connection edge. Select software modules from the module library that meet the functional requirements of the target business scenario, do not trigger the scenario-based connection constraints, and whose output constraints of the upstream software module can deduce the input constraints of the candidate software module, and whose output constraints of the candidate software module can deduce the input constraints of the downstream software module, to form a candidate module set; For candidate software modules The cost of local assembly adjustment is calculated using the following formula: in, To add candidate software modules The number of connected edges that were not covered by reusable verification evidence. To add candidate software modules The total number of connecting edges in the final module assembly diagram. This represents the number of nodes that have changed relative to the target module assembly diagram. To add candidate software modules The total number of nodes in the final module assembly diagram; The candidate software module with the lowest local assembly adjustment cost is selected as the replacement software module, and a retest is performed on the affected local path. When the retest passes, a new historical verification record is generated. When the retest fails, the scenario-based connection constraints are updated according to the re-determined failed connection edges and the violated constraints. The replacement software module is then reselected from the candidate software modules that have not yet been excluded by the scenario-based connection constraints.

9. A software module dynamic assembly and automated testing system supporting cross-business scenarios, characterized in that, include: An assembly diagram construction module is used to obtain scenario constraint information of the target business scenario and construct a target module assembly diagram based on the scenario constraint information and the module description information of the software module. The verification evidence reuse module is used to acquire historical verification records, determine the common assembly subgraph between the target module assembly diagram and the historical module assembly diagram, and determine reusable verification evidence based on the coverage relationship between the target boundary conditions and the verification boundary conditions. The local testing module is used to determine the connection edges to be verified based on the coverage of reusable verification evidence, generate test data and local test paths, and execute automated tests. The connection constraint generation module is used to determine failed connection edges and violated constraints based on the actual transmitted data, field transmission relationships, and the input and output constraints of the software module when automated tests fail, and to generate scenario-based connection constraints; and The local reassembly module is used to select and replace software modules according to the scenario-based connection constraints, form an adjusted module assembly diagram, perform retesting on the affected local paths, and generate new historical verification records based on the test pass results.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1 to 8.

Images