A method for generating a scenario interface test link

Abstract

The application discloses a kind of scene interface test link generation methods, solve the interface dependence matching accuracy when field naming is inconsistent is lower, the problem of insufficient stability of link generation under complex message position scene, comprising: obtaining and analyzing recording playback file, extract the field level description data of interface;Initial candidate field set is generated based on field level structured information and preliminary screening is carried out;For each candidate field pair after preliminary screening, build joint features and carry out correlation score calculation, and carry out hard constraint filtering, obtain effective candidate field pair;Based on the correlation score, the effective candidate field pair is judged, and the parameter dependence relationship is established according to the judgment result;Interface dependence relationship diagram is constructed according to parameter dependence relationship, and scene interface test link is generated combined with interface calling timing information.It reduces the workload of manual field-by-field configuration of interface dependence relationship and the mis-matching probability between different named fields, and improves the stability of interface parameter dependence identification.

Description

Technical Field

[0001] This invention relates to the field of software testing and interface automation processing technology, and in particular to a method for generating scenario-based interface testing links. Background Technology

[0002] In API automation testing scenarios, testers typically need to orchestrate multiple APIs sequentially according to business processes and explicitly configure the transmission relationship between upstream API output parameters and downstream API input parameters. In actual engineering, API recording tools can save request and response messages in the business process, but existing recording results are usually only used for single playback or manual reference, making it difficult to directly form reusable link-level test assets.

[0003] In existing technologies, software testing and interface automation solutions can be mainly divided into the following categories, but each has its own drawbacks: (1) Solutions that directly generate interface test cases or scripts based on traffic collection or packet capture results. For example, patent CN115629967A describes a method and system for generating and executing automated interface test cases based on traffic collection. This involves monitoring and recording business traffic, parsing traffic information, and assembling automated interface test cases. This type of solution can reduce the cost of writing scripts for a single interface. However, it mainly focuses on extracting basic traffic information such as request path, request method, and request parameters, and assembling scripts. For implicit parameter dependencies between upstream response fields and downstream request fields in multi-interface business processes, manual configuration, simple name matching, or preset rule support are usually still required.

[0004] (2) Interface dependency analysis-based solutions. For example, patent CN117389908A describes a method, system, and medium for analyzing the dependency relationship of automated interface test cases. This method improves the efficiency of dependency analysis by generating the minimum test dependency scenario corresponding to the test task based on the dependency topology. Although this type of solution can describe interface-level dependencies, it usually assumes existing test scenarios, test cases, explicit parameter passing information, or pre-configured scenarios as prerequisites. It analyzes the dependency relationship between interfaces and further generates topology relationships or test scenarios. For scenarios where only recorded playback files exist and field dependency relationships are not explicitly labeled, its automatic identification capability is limited.

[0005] (3) Schemes that generate test cases based on interface description documents or semantic models. For example, patent CN115098389A, a method for generating REST interface test cases based on a dependency model, parses the OpenAPI document and combines it with a semantic model to establish parameter dependencies, and then generates interface test cases. This type of scheme is highly dependent on the completeness of the interface document, the standardization of parameter descriptions, and the availability of semantic information; however, in actual engineering, many existing systems do not have complete, real-time synchronized interface description documents. In most cases, only recorded playback files, packet capture records, or historical request and response samples exist. Therefore, this type of scheme still has limitations when directly applied to recorded playback file scenarios. Summary of the Invention

[0006] The purpose of this invention is to solve the problems in the prior art, such as the reliance on manual configuration for interface dependency identification, low dependency matching accuracy when field names are inconsistent, and insufficient stability of link generation in complex message location scenarios. This invention provides a scenario-based interface test link generation method that can reduce the workload of manually configuring interface dependencies field by field, reduce the probability of mismatch between different named fields, and improve the stability of interface parameter dependency identification.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: A method for generating scenario-based interface test links includes the following steps: S1: Obtain and parse the recording and playback files corresponding to the business process, and extract field-level description data from multiple interfaces; S2: For the target fields to be matched in the downstream interface, an initial candidate field set is generated only from the output fields of the upstream interface that are called before it. The initial candidate field set is then screened based on data type compatibility, message position flow rules, business identifier relevance, and field category consistency. S3: For each candidate field pair after initial screening, construct joint features and calculate association scores, and perform hard constraint filtering on the candidate field pairs to obtain effective candidate field pairs; S4: Combine the correlation score to determine the results of the valid candidate field pairs, and establish parameter dependencies based on the determination results; S5: Construct an interface dependency graph based on parameter dependencies, and generate a scenario-based interface test chain by combining interface call timing information.

[0008] For each candidate field pair after initial screening, a joint feature is constructed, consisting of field name lexical features, field data type features, field location in the message, field hierarchical path, interface name, business identifier, and interface call context features. Based on the joint feature, a semantic representation of the candidate field pair is generated, and an association score is calculated based on the semantic similarity of field names, compatibility of field data types, matching degree of message location, legality of interface call sequence, consistency of field flow path, and relevance of the business identifier.

[0009] The scenario-based interface test link generation method provided by this invention reduces the computational load of invalid matches and improves the stability of field dependency identification through preliminary screening of candidate fields, joint feature scoring, and hard constraint filtering. It can automatically construct interface dependency graphs and scenario-based interface test links based on parameter dependency relationships, and can further generate test scripts and assertion configurations, improving the executability, stability, and subsequent reusability of the generated links, and increasing the executability of the test link construction results and the first-time execution success rate of the scripts.

[0010] Preferably, S5 includes: If there is only one valid candidate field pair after hard constraint filtering for the same downstream target field, and the association score of the valid candidate field pair is greater than or equal to the preset score threshold, the parameter dependency relationship corresponding to the valid candidate field pair is directly established. If multiple valid candidate field pairs exist for the same downstream target after hard constraint filtering, they are sorted from high to low according to the association score. If the highest association score is greater than or equal to the preset difference threshold, and the difference between the highest association score and the second highest association score is greater than or equal to the preset difference threshold, then the candidate field pair with the highest association score is selected to establish a parameter dependency relationship. If, after filtering by hard constraints, there are no valid candidate field pairs for the same downstream target, or there is only one valid candidate field pair but its association score is lower than the preset score threshold, or there are multiple valid candidate field pairs but the highest association score is lower than the preset score threshold, or the difference between the highest association score and the second highest association score is lower than the preset difference threshold, then pending confirmation mapping processing and result feedback update are performed.

[0011] As a preferred approach, hard constraint filtering is performed before sorting the association scores. The hard constraint filtering includes field data type compatibility, interface call sequence legality, and field flow path consistency. When any one of the three is below a preset lower limit, the candidate field pair is directly determined to be an invalid candidate pair and will not enter the final association score sorting process.

[0012] Preferably, a preset compatibility rule is used to initially screen the initial candidate field set, and the compatibility rule includes: When the target field is the identity credential field in the request header, the credential-type output field from the response body or header of the upstream interface is preferred to be retained. When the target field is a business object identifier field in the request body, the object identifier class output field from the upstream interface response body will be retained first. When the candidate field and the target field are fully compatible in terms of field type, the highest field type compatibility score is assigned; when the candidate field and the target field are compatible through preset conversion rules, the second highest field type compatibility score is assigned; when the two are incompatible, they are directly eliminated. When the interface business identifier of a candidate field is unrelated to the interface business identifier of the target field, its priority is reduced or it is directly eliminated. If the candidate field and the target field do not belong to the same field category, they are directly eliminated.

[0013] Preferably, the mapping to be confirmed process includes: Record the target field for which no parameter dependency relationship has been established; Output at least one recommended candidate field pair or a state indicator indicating no valid candidate corresponding to the target field, along with the association score or null value indicator of the recommended candidate field pair; Output the reason identifier that led to the pending mapping result; After receiving the user's confirmation, the confirmed field mapping will be updated to at least one of the following: field mapping sample set, thesaurus, business identifier association rules, or candidate field matching rule library; When processing fields with the same or similar structures in subsequent steps, the confirmed field mapping results should be called first.

[0014] Preferably, the consistency of the field flow path is determined according to one or more of the following: message location rules, hierarchical path rules, field category rules, and nested structure rules; the nested structure rule is to compare the parent node path, child node order, or index position of the field when the field is located in an object nested structure or array structure.

[0015] Preferably, the association score is a weighted sum of the semantic similarity of field names, the compatibility of field data types, the matching degree of the message location of the field, the legality of the interface call sequence, the consistency of the field flow path, and the relevance of the business identifier to which the field belongs.

[0016] Preferably, the interface concatenation order is generated by combining the interface call sequence. When a conditional branch identifier or a duplicate call identifier is detected, a branch node or a loop node is generated in the interface dependency graph, respectively. The conditional branch identifier is determined based on one or more of the following: Status code fields, business result fields, or condition fields in the response from the same upstream interface; Under the same session identifier, multiple mutually exclusive subsequent interface request paths are pointed to by the same preceding interface; The same target interface triggers different parameter dependencies under different values ​​of the condition field; The repeat call flag is determined based on one or more of the following: The same interface identifier appears repeatedly in adjacent call sequences; The request paths are the same, but the page number parameters, cursor parameters, or index parameters are different; The same parent interface node can correspond to multiple structurally isomorphic sub-requests.

[0017] Preferably, the scenario-based interface test chain is converted into an intermediate representation object independent of the target programming language, and the target test script is generated based on the intermediate representation object, asserting configuration items and parameter passing logic. The generation of the target test script includes: parsing the interface response message and constructing a response field hierarchical structure model; generating field existence assertions, field type consistency assertions, and field format assertions based on the response field hierarchical structure model; generating business result assertions based on status code fields or business result fields; and writing the business result assertions into the target test script.

[0018] Preferably, the field-level description data includes interface identifier, request method, request header field, query parameter field, request body field, response field, field data type, message location of the field, hierarchical path of the field, and interface call sequence information.

[0019] Preferably, the method further includes standardizing the field-level description data generated in S1 to obtain standardized field descriptions; the standardization process includes field naming splitting, synonym normalization, field type normalization, message location annotation, and business identifier extraction; the standardization process also includes labeling the fields with field categories based on field terms, message locations, and historical confirmation mapping samples, and the field categories include identity credential fields, identifier fields, and business object fields.

[0020] Therefore, the present invention has the following beneficial effects: 1. Based on recorded playback files, this invention identifies interface parameter dependencies and generates scenario-based interface test links by using field semantic association, message position constraints, field flow path constraints, and call timing constraints. This reduces the computational load of invalid candidate matching, improves the stability of parameter dependency identification between different named fields, and enhances the executability of the test link construction results.

[0021] 2. It can automatically identify implicit parameter dependencies between upstream output fields and downstream input fields when only recorded playback files exist, or when complete interface documentation or explicit dependency annotations are lacking; it improves the reusability of similar scenarios by using closed-loop result determination in single-candidate, multi-candidate, and no-candidate scenarios, as well as a backflow update mechanism for pending mapping results. Attached Figure Description

[0022] Figure 1 This is a flowchart of the steps in the scenario-based interface test link generation method in Example 1.

[0023] Figure 2 This is a schematic diagram of the system architecture for the scenario-based interface test link generation method in Example 1.

[0024] Figure 3 This is a schematic diagram of the scenario-based interface test link generated based on the interface dependency graph in Example 2.

[0025] Figure 4 This is a schematic diagram illustrating the generation of candidate field sets, joint scoring, and conflict resolution in Example 3.

[0026] Figure 5 This is a schematic diagram illustrating the consistency determination of field flow paths in Example 4.

[0027] Figure 6 This is a schematic diagram of the identification of conditional branch identifier and repeated call identifier in Example 5. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this application will be further described in detail below through embodiments and in conjunction with the accompanying drawings. It should be understood that the specific embodiments described herein are only one preferred embodiment of this application and are only used to explain this application. They do not limit the scope of protection of this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0029] Software testing and interface automation solutions have at least the following problems: 1. Dependency identification still relies heavily on human experience or pre-existing structured input.

[0030] Some existing solutions are based on existing test cases, parameter passing information, interface documentation, or rule engines. When only recorded playback files are available, the dependencies between upstream interface output fields and downstream interface input fields are often not explicitly given. Testers still need to manually judge each field, which is inefficient and prone to errors.

[0031] 2. Insufficient support for implicit field dependencies.

[0032] Many existing solutions establish dependencies solely based on identical field names, fixed field paths, documentation descriptions, or pre-defined rule tables. When interface naming is inconsistent, abbreviations or synonyms exist, field names differ across modules, or fields move between request headers, query parameters, request bodies, and response bodies, existing solutions are prone to missing or false detections.

[0033] 3. Lack of a joint determination mechanism for field flow constraints.

[0034] Existing technologies typically do not combine and filter factors such as field data type, message location, hierarchical path, field category, and interface call sequence. If the parameter dependencies between interfaces cannot be reliably identified, the subsequent interface call order, parameter injection, and link integrity will all be affected, resulting in unexecutable test links or requiring extensive manual correction.

[0035] 4. Insufficient ability to process and reuse low-confidence results.

[0036] In existing solutions, when multiple candidate fields may be dependent on the target field, or when there are no obviously high-confidence candidate fields, there is often a lack of mechanisms for resolving the difference of conflicting candidates, outputting pending confirmation, and feeding back the confirmation results. This results in script generation, assertion supplementation, and subsequent reuse in similar scenarios still relying on a lot of manual intervention.

[0037] Based on the above technical problems, this invention provides a technical solution that can automatically extract field-level information from recorded playback files and identify implicit parameter dependencies between interfaces by combining field semantics, call sequence, message location, and flow path constraints, thereby automatically generating scenario-based interface test links; to solve the problems in the prior art where interface dependency identification relies on manual configuration, dependency matching accuracy is low when field names are inconsistent, link generation stability is insufficient in complex message location scenarios, and the generation script is difficult to execute directly.

[0038] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0039] Example 1: This embodiment provides a method for generating scenario-based interface test links, such as... Figure 1 As shown, the operation process is as follows: Step 1: Obtain the recording and playback file corresponding to the business process, and parse the recording and playback file to extract field-level description data of multiple interfaces.

[0040] The field-level description data includes interface identifier, request method, request header fields, query parameter fields, request body fields, response fields, field data type, field location in the message, field hierarchical path, and interface call sequence information.

[0041] The recorded playback file can further provide session identifier, transaction identifier, request path, name of the service to which the interface belongs, response status code, timestamp, and response result fields to facilitate subsequent extraction of business identifiers, identification of conditional branches, and identification of repeated calls.

[0042] Step two: Standardize the field-level descriptive data to obtain standardized field descriptions.

[0043] The standardization process includes field naming splitting, synonym normalization, field type normalization, message location marking, and business identifier extraction.

[0044] Specifically: (1) Field naming splitting.

[0045] Field naming splitting includes one or more of the following: camelCase splitting, underscore splitting, abbreviation expansion, and compound word segmentation.

[0046] (2) Synonym normalization.

[0047] Synonym normalization involves mapping semantically identical or similar field terms to a preset term set based on a pre-defined thesaurus, historical confirmation mapping samples, or a business terminology table.

[0048] (3) Field type normalization.

[0049] Field type normalization includes normalizing int, long, and decimal to numeric types, varchar, text, and string to string types, boolean and bool to boolean types, nested objects to object types, and list structures to array types.

[0050] (4) Message location marking.

[0051] Message location annotation includes labeling a field as at least one of the following locations: request header, query parameter, request body, response header, or response body.

[0052] (5) Extraction of business identifiers.

[0053] Business identifier extraction includes generating interface business tags based on at least one of the following: interface path segmentation, interface name lexical, service name, operation verb, response result field, and high-frequency business field lexical. Interface business tags with similar semantics are then normalized to a preset business identifier set.

[0054] The preset set of business identifiers may include business identifiers such as login, authorization, product query, order placement, payment, pagination query, or message confirmation.

[0055] In this embodiment, the fields can also be categorized based on field terms, message location, and historical confirmation mapping samples. The field categories include at least identity credential fields, identifier fields, and business object fields.

[0056] Step 3: For the target fields to be matched in the downstream interface, generate a set of candidate fields from the output fields of the upstream interface whose call sequence is earlier than that of the downstream interface, and perform initial screening based on the field data type compatibility relationship, message position flow rules, business identifier relevance and field category consistency.

[0057] Step three is the key foundation that distinguishes this invention from simply performing name matching, interface-level dependency analysis, or generating test cases solely based on interface documentation.

[0058] First, an initial set of candidate fields is generated from the output fields of the upstream interface that are in the same session identifier or the same business process instance as the target field, and then preliminary screening is performed according to the field data type, the message position of the field, the business identifier to which it belongs, and the field category.

[0059] The data types of the fields include at least strings, numbers, booleans, objects, and arrays; the message locations of the fields include at least request headers, query parameters, request bodies, response headers, and response bodies.

[0060] In this embodiment, a preset compatibility rule is used to perform initial screening on the initial candidate field set.

[0061] Preset compatibility rules include: (1) When the target field is the identity credential field in the request header, the credential class output field from the response body or response header of the upstream interface should be retained first.

[0062] (2) When the target field is the business object identifier field in the request body, the object identifier class output field from the upstream interface response body should be retained first.

[0063] (3) When the candidate field and the target field are fully compatible in terms of field type, a higher field type compatibility is given; when the candidate field and the target field can be made compatible through preset conversion rules, a second higher field type compatibility is given; when the two are incompatible, they are directly eliminated.

[0064] (4) When the interface business identifier of the candidate field is not related to the interface business identifier of the target field, reduce its priority or remove it directly.

[0065] (5) When the candidate field and the target field do not belong to the same field category, they are directly eliminated.

[0066] Step 4: For each candidate field pair after initial screening, construct joint features and calculate the association score.

[0067] This invention does not use semantic similarity in isolation, but rather uses a combination of field name lexical features, field data type features, message location features, hierarchical path features, interface name features, business identifier features, and interface call context features to calculate the association score. Furthermore, before ranking the association scores, candidate field pairs are subjected to hard-constraint filtering, achieving an identification path of "structural filtering first, then association scoring."

[0068] Specifically, this includes: performing field naming splitting on candidate fields and target fields respectively to obtain field name lexical sequences; and extracting field data type, field location in the message, field hierarchical path, interface name, business identifier, and call context as structured context features.

[0069] In this embodiment, the field name lexical sequence and the structured context features are input into a pre-trained semantic coding model to obtain the field semantic representations of the candidate field and the target field; or, the field name lexical sequence is vectorized and then concatenated with the structured context features to obtain the field semantic representations of the candidate field and the target field; the field name semantic similarity is calculated based on the two field semantic representations.

[0070] Based on the above, further calculations are performed on the following: field data type compatibility; field location in the message matching degree; interface call sequence legality; field flow path consistency; and business identifier relevance.

[0071] Among them, the data type compatibility of the field, the matching degree of the message location of the field, the consistency of the field flow path, and the relevance of the business identifier can all be normalized to a value between 0 and 1; the legality of the interface call sequence can be represented by a binary result or a confidence level between 0 and 1.

[0072] In this embodiment, the association score is the sum of the product of the semantic similarity of the field name with the first weight coefficient, the product of the compatibility of the field data type with the second weight coefficient, the product of the matching degree of the message location of the field with the third weight coefficient, the product of the legality of the interface call sequence with the fourth weight coefficient, the product of the consistency of the field flow path with the fifth weight coefficient, and the product of the relevance of the business identifier with the sixth weight coefficient.

[0073] The first to sixth weight coefficients, as well as the preset score threshold, preset difference threshold, and preset lower limit conditions in step five, are determined based on the statistical results of the historical field mapping sample set, manual experience rules, or a combination of both, and can be configured separately according to business scenarios or field categories.

[0074] Field data type compatibility, API call sequence validity, and field flow path consistency are used as hard constraints for filtering. Specifically, if any one of these criteria is lower than a preset lower limit, the candidate field pair is directly determined to be an invalid candidate pair and will not be included in the final score ranking process, thereby reducing the amount of invalid calculations.

[0075] In this embodiment, the consistency of the field flow path is determined based on at least one or more of the following rules: (1) Message position rules: used to limit the allowed flow of fields between the response body, response header, request header, query parameters and request body.

[0076] (2) Hierarchical path rules: used to limit whether the parent path of the source field and the parent path of the target field meet the preset mapping relationship.

[0077] (3) Field category rules: used to limit the different flow methods applicable to identity credential fields, object identifier fields and business object fields.

[0078] (4) Nested structure rules: When a field is located in an object nested structure or array structure, further compare its parent node path, child node order or index position.

[0079] For example, authentication token fields can be transferred from the upstream interface response body or response header to the downstream interface request header; object identifier fields can be transferred from the upstream interface response body to the downstream interface request body; while fields that only indicate the status result are usually not used as target input parameters for subsequent interfaces.

[0080] The rules for determining the consistency of field flow paths describe the allowed flow relationships between different field categories at different message locations. For example, identity credential fields flow from the upstream response body or response header to the downstream request header, and object identifier fields flow from the upstream response body to the downstream request body. Furthermore, in array structures or nested object structures, consistency determination is further based on parent paths, child paths, or index positions. This helps differentiate the system from existing solutions that establish dependencies solely based on names or document text.

[0081] Step 5: Combine the correlation scores to determine the results of the valid candidate fields, and establish parameter dependencies based on the determination results.

[0082] In this embodiment, in low-confidence scenarios, instead of simply discarding candidate results, recommended candidate field pairs or a status indicator indicating no valid candidates are output. Upon receiving confirmation, the confirmed mapping relationship is updated in the field mapping sample set, the thesaurus, business identifier association rules, or candidate field matching rule base. This demonstrates the invention's ability to be reused and continuously improved.

[0083] Specifically, the closed-loop result determination logic of this invention in single-candidate, multi-candidate, and no-candidate scenarios is as follows: (1) When there is only one valid candidate field pair after the same downstream target field is filtered by hard constraints, and the association score of the valid candidate field pair is greater than or equal to the preset score threshold, the parameter dependency relationship corresponding to the valid candidate field pair is directly established.

[0084] (2) When there are multiple valid candidate field pairs for the same downstream target field, conflict resolution is performed based on the highest score, the second highest score, and the difference threshold of the association score. Conflict resolution is specifically manifested as follows: the valid candidate field pairs are sorted according to the association score; if the highest association score is greater than or equal to the preset score threshold, and the difference between the highest association score and the second highest association score is greater than or equal to the preset difference threshold, then the candidate field pair with the highest score is selected to establish a parameter dependency relationship.

[0085] (3) When there are no valid candidate field pairs, or only one valid candidate field pair exists but its association score is lower than the preset score threshold, or multiple valid candidate field pairs exist but the highest association score is lower than the preset score threshold, or the difference between the highest association score and the second highest association score is lower than the preset difference threshold, the pending confirmation mapping process is executed. This closed-loop logic is an important feature of this invention in terms of engineering executability.

[0086] The mapping process to be confirmed includes: (1) Record the target field for which no parameter dependency relationship has been established.

[0087] (2) Output at least one recommended candidate field pair or no valid candidate status identifier corresponding to the target field, along with the associated score or null value identifier of the recommended candidate field pair.

[0088] (3) Output the reason identifier that leads to the pending mapping result, the reason identifier includes at least insufficient score, close score, no valid candidate or insufficient historical sample.

[0089] (4) After receiving the user's confirmation result, update the confirmed field mapping to at least one of the field mapping sample set, the thesaurus, business identifier association rules or candidate field matching rule library.

[0090] (5) When processing the same or similar field structures in the future, the confirmed field mapping results should be called first.

[0091] Step 6: Construct an interface dependency graph based on the established parameter dependencies, and generate a scenario-based interface test chain by combining the interface call timing information.

[0092] The interface call sequence is generated by combining the interface call sequence, and when a conditional branch flag or a repeated call flag is detected, a branch node or a loop node is generated in the interface dependency graph respectively to improve the expressive ability of complex business processes.

[0093] Specifically, the conditional branch identifier is determined based on one or more of the following: Status code fields, business result fields, or condition fields in the response from the same upstream interface; Under the same session identifier, multiple mutually exclusive subsequent interface request paths are pointed to by the same preceding interface; Alternatively, the same target interface may trigger different parameter dependencies depending on the values ​​of different condition fields.

[0094] The repeat call flag is determined based on one or more of the following: The same interface identifier appears repeatedly in adjacent call sequences; The request paths are the same, but the page number parameters, cursor parameters, or index parameters are different; Alternatively, the same parent interface node may correspond to multiple structurally isomorphic sub-requests.

[0095] In this embodiment, the method further includes converting the scenario-based interface test link into an intermediate representation object that is independent of the target programming language.

[0096] The intermediate representation objects include: interface node set, node call order, parameter dependency edges between nodes, field mapping relationship, branch node type, loop node type, request configuration items, and assertion configuration items.

[0097] Based on the aforementioned intermediate representation object, the target test script, assertion configuration items, and parameter passing logic are generated. The target test script includes the interface call order, parameter passing relationship, request configuration, branch control, and loop control.

[0098] The generation of target test scripts also includes: Parse the interface response message and construct a hierarchical structure model of the response fields; Generate field existence assertions, field type consistency assertions, and field format assertions based on the response field hierarchy model; Generate business result assertions based on the status code field or the business result field; Write the business result assertions into the target test script.

[0099] This embodiment also provides a scenario-based interface test link generation system, such as Figure 2 As shown, it includes a parsing module, a standardization processing module, a candidate generation module, an association determination module, a hard constraint filtering module, a result determination module, a backflow update module, a dependency graph construction module, and a link generation module. The parsing module is connected to the standardization processing module and the result determination module, respectively. The standardization processing module is connected to the candidate generation module, the candidate generation module is connected to the association determination module, the association determination module is connected to the hard constraint filtering module, and the hard constraint filtering module is connected to the dependency graph construction module. The result determination module is connected to the link generation module.

[0100] In this embodiment, the scenario-based interface test link generation system further includes a script generation module and an assertion generation module, which are used to further generate target test scripts and assertions based on the scenario-based interface test link. The link generation module is connected to the script generation module, and the script generation module and the dependency graph construction module are both connected to the assertion generation module. The assertion generation module outputs results, including interface dependency graph, scenario-based link, test script and assertion configuration.

[0101] During operation, the parsing module acquires and parses the recorded playback files, extracting field-level descriptive data from them. The recorded playback files include JSON / HAR / XML formats, containing request messages, response messages, and call sequences.

[0102] The standardization processing module receives a thesaurus and business identifier association rules from the auxiliary knowledge base and performs standardization processing on the field-level description data sent by the parsing module. This standardization processing includes: name splitting, type normalization, message location annotation, business knowledge extraction, and field category annotation.

[0103] The candidate generation module generates a candidate set of upstream output fields and performs preliminary screening. The association determination module receives the historical sample set, constructs joint features, and calculates the association score of candidate field pairs. The historical sample set includes field mapping samples, threshold configurations, and empirical rules.

[0104] The hard constraint filtering module eliminates invalid candidates based on type, timing, and path consistency, while the dependency graph construction module constructs an interface dependency graph based on parameter dependency associations.

[0105] The result determination module determines the results for valid candidate field pairs. If the correlation score of a single candidate reaches the preset score threshold, a dependency is directly established. For multiple candidates, conflicts are resolved according to the correlation score and the difference threshold.

[0106] The link generation module generates scenario-based interface test links based on the call sequence, while the script generation module generates target test scripts based on intermediate representation objects. The assertion generation module generates assertions for field existence, type consistency, format, and business results.

[0107] The feedback update module receives the confirmation result and updates the sample set, dictionary, and rules in the historical sample set, improving the automatic recognition capability of similar scenarios in the future. The user confirmation result is fed back to the historical sample set to support subsequent candidate generation and threshold configuration.

[0108] Therefore, the scenario-based interface test link generation method and system provided in this embodiment have the following beneficial effects: 1. By first screening the upstream output fields according to data type, message location, and business identifier dimensions, the size of the candidate fields participating in the subsequent association determination can be reduced, thus reducing the amount of invalid matching calculations.

[0109] 2. By jointly utilizing semantic similarity of field names, compatibility of field data types, matching degree of message location, legality of interface call sequence, consistency of field flow path, and relevance of business identifiers to calculate association scores, the probability of mismatch between different named fields can be reduced, and the stability of interface parameter dependency identification can be improved.

[0110] 3. By performing conflict resolution processing based on score sorting and difference threshold on multiple candidate fields corresponding to the same downstream target field, the consistency of parameter mapping results in multi-candidate scenarios can be improved, and the risk of erroneous dependencies being propagated to subsequent link construction processes can be reduced.

[0111] 4. By outputting the mapping result to be confirmed in low-confidence scenarios and feeding the confirmation result back to the field mapping sample set or matching rule base, the automatic recognition capability in subsequent similar interface scenarios can be improved, and the engineering reusability of the solution can be enhanced.

[0112] 5. By generating scenario-based interface test links based on parameter dependency graphs, and further generating test scripts and assertions, the executability of the test link construction results and the success rate of script execution on the first attempt can be improved.

[0113] 6. By identifying conditional branch identifiers and repeated call identifiers in the recorded playback file, the generated test link can cover branch nodes and loop nodes, improving the completeness of the expression of complex business processes.

[0114] Example 2: Based on Embodiment 1, this embodiment provides a method for generating scenario-based interface test links, which can be combined with specific application scenarios to achieve scenario-based interface test link generation.

[0115] This embodiment takes the e-commerce order placement process as an example. The recorded playback file includes login interface, token acquisition interface, product query interface and order submission interface.

[0116] like Figure 3 As shown, taking the e-commerce order placement business process as an example, this demonstrates the transformation of the dependency graph into a scenario graph-based test interface link, specifically including the following steps: Step 1: File parsing.

[0117] After obtaining the HAR format recording and playback file, the system parses it to obtain the following field-level descriptive data: 1. Input parameter fields for the login interface include: username (username), password (password); Output parameter fields include: userId (user ID), auth_code (authorization code), loginStatus (login status).

[0118] 2. The input parameters of the token acquisition interface include userId and credential (user credentials), and the output parameters include validToken (valid token).

[0119] 3. The input parameter fields of the product query interface include goodsName (product name), the request header field includes validToken, and the output parameter fields include goodsId (product ID), goodsPrice (product price), and stock (inventory).

[0120] 4. The input parameters of the order submission interface include userId, goodsId, and buyNum (purchase quantity). The request header field includes validToken. The output parameters include orderId (order number) and orderStatus (order status).

[0121] Simultaneously, the call sequence information of each interface in the recording and playback file was extracted, and the call order was found to be: login interface, token acquisition interface, product query interface, and order submission interface.

[0122] Step 2: Standardization process.

[0123] Standardize the field-level descriptive data, including: 1. Split auth_code into auth and code.

[0124] 2. Split userId into user and id.

[0125] 3. Keep the credential as a single token, and combine the interface path / token / get, the interface name getToken, and the operation verb get to extract the business description "authorization" of the interface to which it belongs.

[0126] 4. Standardize the description of field types. For example, unify varchar (variable length string type) and string as string type, and unify int (integer type) and long (long integer data type) as numeric type.

[0127] 5. Mark the location of the field in the message, including the response body, request header, and request body.

[0128] 6. Extract the interface business identifiers, such as "Login", "Authorization", "Product Inquiry", and "Order Submission".

[0129] 7. Classify fields based on field terms and message location. For example, label auth_code and validToken as identity credential fields, and label userId and goodsId as identifier fields.

[0130] Step 3: Generate the candidate field set.

[0131] For the target field credential of the token acquisition interface, a set of candidate fields is generated from the output fields of the upstream interface that precedes it in the call sequence. The candidate fields include userId, auth_code, and loginStatus.

[0132] Then, an initial screening was conducted: 1. Fields that clearly did not match the credential type were removed based on data type compatibility.

[0133] 2. Retain fields related to the "authorization" scenario based on business identifier relevance.

[0134] 3. Based on the message location rules, priority is given to retaining the credential-type output fields from the login interface response body.

[0135] 4. Eliminate candidate fields that do not belong to the identity credential category based on field category rules.

[0136] After the initial screening, auth_code enters the next stage of association determination. userId is downgraded or removed due to inconsistent field categories, and loginStatus is removed due to the business result field attributes.

[0137] Step 4: Calculate the correlation score.

[0138] For the auth_code -> credential candidate field pair, extract the field name tokens, data type, message location, hierarchical path, interface name, business description text, and interface context information, and input them into the pre-trained semantic encoding model to obtain the semantic representation of the field.

[0139] The semantic similarity of field names is calculated based on the semantic representation of the fields, and an association score is generated by combining the following constraints: 1. Call sequence validity: The login interface is located before the token acquisition interface.

[0140] 2. Consistency of field flow path: auth_code is the output parameter of the login interface response body, and credential is the input parameter of the authorization interface request body, which satisfies the path rule of identity credential fields flowing from the response body to the request body.

[0141] 3. Data type compatibility: Both fields can be classified as string type.

[0142] 4. Business Identifier Relevance: The "login" scenario to which auth_code belongs is related to the "authorization" scenario to which credential belongs.

[0143] In this embodiment, ScoreThreshold can be set to 0.72 and DiffThreshold to 0.08. When only one valid candidate field pair, auth_code -> credential, remains after hard constraint filtering, and its association score is, for example, 0.81, the system directly establishes the parameter dependency relationship; if the association score of the only valid candidate field pair is lower than 0.72, the target field is marked as a mapping result to be confirmed.

[0144] Step 5: Construct the interface dependency graph.

[0145] The system constructs an interface dependency graph based on the identified parameter dependencies, which includes at least the following edge relationships: 1. login.userId (login user ID) -> getToken.userId (verify user ID).

[0146] 2. login.auth_code (login authorization code) -> getToken.credential (verify user credentials).

[0147] 3. getToken.validToken -> queryGoods.header.validToken.

[0148] 4. getToken.validToken -> submitOrder.header.validToken.

[0149] 5. queryGoods.goodsId -> submitOrder.goodsId.

[0150] 6. login.userId -> submitOrder.userId.

[0151] Step Six: Generate a scenario-based interface test link.

[0152] Based on the interface dependency graph and interface call sequence information in step five, generate a scenario-based interface test chain: login interface -> token acquisition interface -> product query interface -> order submission interface.

[0153] At the same time, based on the interface business identifier, scenario tags such as "login scenario", "authorization scenario", "product query scenario" and "order submission scenario" are assigned to each interface.

[0154] Step 7: Target test script generation.

[0155] In one alternative implementation, the system converts the scenario-based interface test chain into an intermediate representation object that is independent of the target programming language, and generates test scripts based on the target language.

[0156] The test script should include at least: 1. Interface call code arranged in the order of the link.

[0157] 2. Parameter transfer relationship from upstream output parameters to downstream input parameters.

[0158] 3. Configuration of request headers, request method and interface address.

[0159] 4. Use parameterized configuration with global variables, environment variables, or data-driven variables.

[0160] 5. Assertion configuration items and exception handling logic.

[0161] Step 8: Assertion generation.

[0162] In this embodiment, the system parses the interface response message, constructs a hierarchical structure model of the response fields, and generates the following assertions: 1. Field existence assertion.

[0163] 2. Field type consistency assertion.

[0164] 3. Field format assertions.

[0165] 4. Business result assertions based on status code fields or business result fields.

[0166] Step 9: Downgrade processing.

[0167] When there are no valid candidate field pairs, or the association score of the only valid candidate field pair is lower than the preset score threshold, or the difference between the highest and second-highest association scores of multiple valid candidate field pairs is lower than the preset difference threshold, the system performs pending confirmation mapping processing: 1. Record the target fields for which parameter dependencies were not established and the reason identifier.

[0168] 2. Output recommended candidate field pairs or a status indicator indicating no valid candidates for user confirmation, and display the associated score or null value indicator for the recommended candidate field pairs.

[0169] 3. After receiving the user's confirmation, write the corresponding mapping into the field mapping sample set, the thesaurus, or the matching rule base for subsequent candidate matching.

[0170] Example 3: Based on Embodiment 1, this embodiment provides a scenario-based interface test link generation method, which combines specific application scenarios to achieve conflict resolution of multiple candidate fields and determination of path constraints.

[0171] In this embodiment, the request header of downstream interface A contains the target field accessToken (interface call identity credential), and the two upstream interfaces that are called before it output the fields token, sessionToken (user login status credential), and statusCode (status code), respectively.

[0172] The token is located in the login interface response body, the sessionToken is located in the authorization interface response body, and the statusCode is located in the login interface response body.

[0173] Specifically, such as Figure 4 As shown, taking the downstream target field accessToken as an example, the process of candidate generation, scoring, and conflict resolution is demonstrated: Step 1: The system first generates an initial set of candidate fields based on the compatibility of field data types.

[0174] Since accessToken is a string type and a request header field, token and sessionToken, which are both string types, are retained, while statusCode, which is a numeric type, is removed.

[0175] Step 2: The system performs further initial screening based on message location rules and field category rules.

[0176] Since accessToken is an identity credential field in the request header, the system prioritizes retaining credential fields from the upstream interface response body. Therefore, both token and sessionToken enter the association determination stage.

[0177] Step 3: Calculate the association score of candidate field pairs.

[0178] The system constructs joint features for token -> accessToken and sessionToken -> accessToken respectively, and calculates the association scores of the two sets of candidate field pairs.

[0179] in: 1. The field names of token and accessToken have high semantic similarity, but the correlation between the business identifier of the interface to which they belong and the business identifier of the downstream interface is moderate.

[0180] 2. The semantic similarity of the field names of sessionToken -> accessToken is slightly lower than that of the former, but the business identifier of the interface to which it belongs is more related to the business identifier of the downstream interface, and the call sequence is closer to the downstream interface.

[0181] Step 4: Combine the correlation scores to determine the results of the valid candidate field pairs, and establish parameter dependencies based on the determination results.

[0182] If the final association score of sessionToken -> accessToken is higher than that of token -> accessToken, then a parameter dependency relationship of sessionToken -> accessToken is established.

[0183] If both scores meet the preset conditions, and the difference between the highest and second-highest scores is less than the preset difference threshold, the system will not directly establish a dependency relationship, but will output both token -> accessToken and sessionToken -> accessToken as the mapping results to be confirmed.

[0184] After receiving confirmation from the user that they have selected sessionToken -> accessToken, the system writes the mapping result into the field mapping sample set. Subsequently, when encountering field matching tasks with the same business identifier, the same message location, and similar field structures, the system prioritizes reusing the already confirmed mapping, thereby reducing duplicate confirmations.

[0185] Example 4: Based on Embodiment 2, this embodiment provides a scenario-based interface test link generation method, which combines specific application scenarios to realize field flow between different message locations.

[0186] like Figure 5 As shown, the determination of whether a field is allowed to flow from upstream to downstream is based on the field type, message location, hierarchical path, and nested structure. Specifically, in this embodiment, the response body of the product query interface outputs the field goodsId, the request body of the order submission interface contains the target field goodsId, the response body of the token acquisition interface outputs the field validToken, and the request header of the order submission interface contains the target field validToken.

[0187] For the field pair goodsId -> goodsId, the system calculates the association score based on the semantic similarity of the field names, the compatibility of the field types, and the field category rules. Based on the path rules that allow object identifier fields to flow from the response body to the request body, the system determines that the consistency of the field flow path is valid.

[0188] For field pairs of validToken -> validToken, the system determines that the consistency of the field transfer path is valid based on the path rules that allow identity credential fields to flow from the response body to the request header.

[0189] If another candidate field, goodsPrice, is involved in matching the target field, goodsId, even though they may have the same data type, the system determines that the consistency of the field flow path is not met because goodsPrice is a business numerical field and does not meet the path rules of object identifier fields. Therefore, it is removed.

[0190] The key points for path consistency judgment are: to consider field type, message location, and parent path, child path and index position in object nesting / array structure.

[0191] Therefore, this application can distinguish the flow of different field categories between different message locations, thereby reducing mismatches caused by relying solely on field names or data types.

[0192] Example 5: Based on Embodiment 1, this embodiment provides a scenario-based interface test link generation method, which, combined with specific application scenarios, enables the identification of conditional branches and repeated calls.

[0193] like Figure 6As shown, this includes identifying pagination query loops and branch paths based on condition fields, and generating loop nodes and branch nodes in the chain. Specifically, in this embodiment, the recorded playback file corresponds to a business process of pagination query and order confirmation. The product list query interface is called three times consecutively, with the same request path, carrying pageNo=1, pageNo=2, and pageNo=3 respectively; when the order confirmation interface returns the field needPay=true, the payment interface is subsequently called; when the returned field needPay=false, the completion interface is subsequently called.

[0194] During the parsing phase, the system records the session identifier, request path, call sequence, and key condition fields for each request. For three product list query requests, since they have the same interface identifier, the same request path, and only the page number parameter is different, the system identifies them as duplicate calls and generates a circular node in the interface dependency graph.

[0195] For two different subsequent paths after the order confirmation interface, the system identifies the conditional branch identifier based on the needPay conditional field in the response of the same upstream interface and the two mutually exclusive subsequent interface request paths under the same session identifier, and generates a branch node in the scenario-based interface test link.

[0196] The identification rules can be summarized as follows: Duplicate call identifier: unified interface identifier, same request path, page number / cursor / index parameter changes; Conditional branch identifier: unified upstream response condition field, status code field or business end result field triggers mutually exclusive subsequent paths.

[0197] Based on this, the system-generated link not only includes the linear order of interfaces, but also the pagination loop structure and payment branch structure, thereby improving the completeness of the generated test script in expressing the real business process.

[0198] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any way. Other variations and modifications are possible without departing from the technical solutions described in the claims.

Claims

1. A method for generating scenario-based interface test links, characterized in that, include: S1: Obtain and parse the recorded playback file, and extract field-level descriptive data; S2: For the target fields to be matched in the downstream interface, generate an initial candidate field set from the output fields of the upstream interface that is called earlier in the time sequence, and perform preliminary screening on the initial candidate field set; S3: For each candidate field pair after initial screening, construct joint features and calculate association scores, and perform hard constraint filtering to obtain effective candidate field pairs; S4: Determine the results of valid candidate field pairs based on the association score, and establish parameter dependencies based on the determination results; S5: Construct an interface dependency graph based on parameter dependencies, and generate a scenario-based interface test chain by combining interface call timing information.

2. The method for generating a scenario-based interface test link according to claim 1, characterized in that, For the same downstream target field: If there is only one valid candidate field pair: if the association score of the valid candidate field pair is greater than or equal to the preset score threshold, the parameter dependency relationship is directly established; otherwise, the pending mapping process is executed. If there are multiple valid candidate field pairs: if the highest association score of a valid candidate field pair is greater than or equal to a preset score threshold, and the difference between the highest association score and the second highest association score is greater than or equal to a preset difference threshold, then select the candidate field pair with the highest association score to establish a parameter dependency relationship; otherwise, perform pending mapping processing. If no valid candidate field pair exists, proceed with the pending confirmation mapping process.

3. A method for generating a scenario-based interface test link according to claim 1 or 2, characterized in that, Hard constraint filtering includes field data type compatibility, API call sequence validity, and field flow path consistency.

4. The method for generating a scenario-based interface test link according to claim 1, characterized in that, The initial screening of the initial candidate field set includes: If the target field is the identity credential field in the request header, prioritize retaining the credential-type output field from the response body or header of the upstream interface; If the target field is a business object identifier field in the request body, the output field of the object identifier class from the response body of the upstream interface will be retained first. If the candidate field and the target field are fully compatible in terms of field type, the highest field type compatibility score is assigned. If the candidate field and the target field are compatible through preset conversion rules, the second highest field type compatibility score is assigned. If the two are incompatible, they are directly eliminated. If the interface business identifier of the candidate field is unrelated to the interface business identifier of the target field, its priority should be reduced or it should be eliminated directly. If the candidate field and the target field do not belong to the same field category, they are directly eliminated.

5. The method for generating a scenario-based interface test link according to claim 2, characterized in that, The mapping process to be confirmed includes: Record the target field for which no parameter dependency relationship has been established; Output at least one recommended candidate field pair corresponding to the target field or a status indicator indicating that there are no valid candidates, along with the association score or null value indicator of the recommended candidate field pair; Output the reason identifier that led to the pending mapping result; After receiving the user's confirmation result, update the confirmed field mapping to at least one of the following: field mapping sample set, thesaurus, business identifier association rule or candidate field matching rule library; When processing fields with the same or similar structures in subsequent steps, the confirmed field mapping results should be called first.

6. The method for generating a scenario-based interface test link according to claim 3, characterized in that, Field flow path consistency is determined based on message location rules, hierarchical path rules, field category rules, and nested structure rules; The nested structure rule is that when a field is located in an object nested structure or array structure, the parent node path, child node order, or index position of the field are compared.

7. A method for generating a scenario-based interface test link according to claim 1, 2, 4, or 5, characterized in that, The association score is a weighted sum of the semantic similarity of field names, the compatibility of field data types, the matching degree of the message location of the field, the legality of the interface call sequence, the consistency of the field flow path, and the relevance of the business identifier to which the field belongs.

8. The method for generating a scenario-based interface test link according to claim 1, characterized in that, If a conditional branch flag or a duplicate call flag is detected, a branch node or a loop node is generated in the interface dependency graph, respectively; the conditional branch flag is determined based on one or more of the following: Status code fields, business result fields, or condition fields in the response from the same upstream interface; Under the same session identifier, multiple mutually exclusive subsequent interface request paths are pointed to by the same preceding interface; The same target interface triggers different parameter dependencies under different values ​​of the condition field; The repeat call flag is determined based on one or more of the following: The same interface identifier appears repeatedly in adjacent call sequences; The request paths are the same, but the page number parameters, cursor parameters, or index parameters are different; The same parent interface node can correspond to multiple structurally isomorphic sub-requests.

9. A method for generating a scenario-based interface test link according to claim 1 or 8, characterized in that, The scenario-based interface test chain is converted into an intermediate representation object that is independent of the target programming language, and the target test script is generated based on the intermediate representation object: parsing the interface response message and building a hierarchical structure model of the response field; Generate field existence assertions, field type consistency assertions, and field format assertions based on the response field hierarchy model; Generate business result assertions based on the status code field or business result field; write the business result assertions into the target test script.

10. A method for generating a scenario-based interface test link according to claim 1, 2, 4, 5, or 8, characterized in that, Field-level descriptive data includes interface identifier, request method, request header fields, query parameter fields, request body fields, response fields, field data type, field location in the message, field hierarchy path, and interface call sequence information.

Images