A method, device, equipment, medium and product for generating an interface test script

Abstract

The embodiment of the application provides a kind of interface test script generation method, device, equipment, medium and product, it is related to software testing field, the method is by converting interface test requirement into the IDL description conforming to the preset IDL syntax specification, then the uniform information extraction is carried out to the IDL description, obtains the script data object including interface call sequence, parameter rule and check logic, the test information that originally relies on artificial understanding, scattered and disordered is converted into the structured data that machine can directly process, finally, according to the script data object, the interface test script of adapting preset test framework is automatically generated, the automation construction of interface call and result check is completed, the whole process no longer depends on test personnel manual analysis interface document, comb interface call relationship, write test data and design check rule, shorten the generation cycle of interface test script, solve the problem of low efficiency in prior art interface test script generation.

Description

Technical Field

[0001] This application relates to the field of software testing, and more particularly to a method, apparatus, device, medium, and product for generating interface test scripts. Background Technology

[0002] In environments where distributed services and micro-interface architectures are widely used, business functions are typically implemented collaboratively by multiple interfaces. The correctness, stability, and execution reliability of these interfaces directly determine the overall operational quality of the system. As business scenarios become increasingly complex and the number of interfaces continues to grow, it is necessary to verify various interfaces through standardized and automated methods to ensure the correctness of system logic, the reliability of data interaction, and the stable operation of business processes. Therefore, the generation of interface test scripts has become a key step in ensuring the quality of system development and delivery efficiency.

[0003] In existing technologies, testers typically write test cases and verification logic manually based on the address, parameters, request methods, and other information defined in the interface documentation. They then generate interface test scripts that can run in the corresponding test framework according to the preset interface call order to complete the verification of the interface functions.

[0004] However, existing technologies suffer from low efficiency in generating interface test scripts. Because writing interface test scripts heavily relies on testers' in-depth understanding of business logic and technical implementation, testers need to spend a significant amount of time manually analyzing interface documentation, clarifying the call relationships between interfaces, writing test data, and designing validation rules. This results in long script generation cycles and difficulty in reusing the scripts. Summary of the Invention

[0005] This application provides a method, apparatus, device, medium, and product for generating interface test scripts, in order to solve the problem of low efficiency in generating interface test scripts in the prior art.

[0006] In a first aspect, embodiments of this application provide a method for generating interface test scripts, comprising:

[0007] Obtain the interface testing requirements and convert them into an IDL description that conforms to the preset IDL syntax specification; wherein, the interface testing requirements are used to represent the test content of the interface to be tested by the testers;

[0008] Information is extracted from the IDL description to obtain a script data object; wherein, the script data object is a data structure extracted from the IDL description, including interface call sequence, parameter rules and verification logic, and the script data object is used to represent the structured information of the interface testing requirements;

[0009] The interface test script required for the interface test is generated based on the script data object; wherein, the interface test script is used to execute interface calls and result verification in a preset test framework to test the interface to be tested.

[0010] In one possible design, the acquisition of interface testing requirements includes:

[0011] Obtain the initial natural language requirements input by the testers, and calculate the intent confidence of the initial natural language requirements;

[0012] When the confidence level of the intent is greater than or equal to a preset confidence threshold, the initial natural language requirement is determined as the interface test requirement; wherein, the interface test requirement includes a natural language description of the test scenario, interface call order, and verification rules;

[0013] When the confidence level of the intent is less than the preset confidence threshold, the missing semantic slots of the initial natural language requirement are obtained, and a reverse lookup question is generated based on the missing semantic slots.

[0014] Obtain feedback information from testers regarding the reverse query, and semantically complete the initial natural language requirements based on the feedback information to obtain the interface test requirements.

[0015] In one possible design, the step of converting the interface testing requirements into an IDL description conforming to a preset IDL syntax specification includes:

[0016] Feature extraction is performed on the interface testing requirements to obtain an initial structured representation; wherein, the initial structured representation refers to intermediate data initially extracted from the interface testing requirements and organized in a structured form;

[0017] The initial structured representation is input into a preset transformation model to obtain an initial IDL description that conforms to the preset IDL syntax specification and reverse verification data corresponding to the initial structured representation;

[0018] Based on the reverse verification data, the initial IDL description is converted into verification text, and the semantic similarity between the verification text and the initial structured representation is calculated.

[0019] When the semantic similarity is greater than a preset similarity threshold, the initial IDL description is confirmed as the IDL description.

[0020] In one possible design, the step of extracting information from the IDL description to obtain a script data object includes:

[0021] Multiple historical scripts are obtained and classified to obtain positive and negative datasets; wherein, the multiple historical scripts refer to the set of scripts generated by executing historical test tasks on the interface to be tested within a preset first time period, and the end time of the first time period is earlier than the current time.

[0022] Positive constraints are generated based on the positive dataset, and negative constraints are generated based on the negative dataset; wherein, the positive dataset refers to the set of scripts that were successfully tested from the plurality of historical scripts, and the negative dataset refers to the set of scripts that failed to test from the plurality of historical scripts;

[0023] Based on the positive and negative constraints, information is extracted from the IDL description to obtain the script data object; wherein, the positive constraints are used to limit the interface parameter associations and validation rules that should be included in the script data object, and the negative constraints are used to limit the interface call patterns and parameter configuration methods that should be avoided in the script data object.

[0024] In one possible design, after generating the interface test script required for the interface test based on the script data object, the method further includes:

[0025] In response to the current time reaching a preset detection time, the interface change information of the interface to be tested is obtained; wherein, the interface change information is used to represent the interface definition of the interface to be tested obtained at the preset detection time, and the difference between the interface definition and the historical baseline interface definition, wherein the historical baseline interface definition is the interface definition of the interface to be tested obtained at the previous detection time of the preset detection time.

[0026] The script data object is updated according to the interface change information to obtain the updated script data object, and an updated interface test script is generated based on the updated script data object.

[0027] In one possible design, updating the script data object based on the interface change information to obtain the updated script data object includes:

[0028] Acquire multiple historical interaction records and current environment variables; wherein, the multiple historical interaction records are used to represent the historical behavior patterns and calling rules of the interface to be tested, and the current environment variables are used to represent the environmental characteristics when testing the interface to be tested;

[0029] Based on the multiple historical interaction records and the current environment variables, the preset generation logic of the script data object is optimized to obtain the optimized generation logic;

[0030] Based on the optimized generation logic, the script data object is updated according to the interface change information to obtain the updated script data object.

[0031] In one possible design, updating the script data object based on the interface change information to obtain the updated script data object includes:

[0032] The interface change information is analyzed for change type identification and change impact domain to obtain change type and impact domain; wherein, the change type includes parameter addition, parameter obsolescence, parameter type change, parameter constraint change and interface call path change;

[0033] Based on the change type and the influence domain, the target fields and target logic in the script data object that are affected by the change type and the influence domain are determined, and the target fields and target logic are updated to obtain the updated script data object.

[0034] In one possible design, generating the interface test script required for the interface test based on the script data object includes:

[0035] The script data object is parsed to obtain the interface call sequence contained in the script data object and the dependency relationships between multiple preset interfaces;

[0036] Based on the aforementioned dependencies, the concurrent execution path of the interface call sequence is deduced to identify potential failure scenarios under preset concurrency pressure.

[0037] At least one compensatory test case is generated based on the potential failure scenario; wherein, the compensatory test case includes verification logic for verifying the interface under test under the potential failure scenario;

[0038] The compensatory test cases and the basic test script generated based on the script data object are integrated so that when the interface test script is executed in the preset test framework, it performs functional verification of the interface to be tested and simulates concurrent conflicts to trigger the potential failure scenario, thus obtaining the interface test script.

[0039] Secondly, embodiments of this application provide an apparatus for generating interface test scripts, comprising:

[0040] The first acquisition module is used to acquire interface testing requirements and convert the interface testing requirements into an IDL description that conforms to a preset IDL syntax specification; wherein, the interface testing requirements are used to represent the test content of the interface to be tested by the testers;

[0041] An extraction module is used to extract information from the IDL description to obtain a script data object; wherein, the script data object is a data structure extracted from the IDL description, including interface call sequence, parameter rules and verification logic, and the script data object is used to represent the structured information of the interface testing requirements;

[0042] The generation module is used to generate the interface test script required by the interface test requirements based on the script data object; wherein, the interface test script is used to execute interface calls and result verification in a preset test framework to test the interface to be tested.

[0043] In one possible design, the first acquisition module includes:

[0044] The first acquisition unit is used to acquire the initial natural language requirements input by the tester and calculate the intent confidence of the initial natural language requirements.

[0045] The first determining unit is configured to determine the initial natural language requirement as the interface test requirement when the confidence level of the intent is greater than or equal to a preset confidence threshold; wherein the interface test requirement includes a natural language description of the test scenario, the interface call order, and the verification rules;

[0046] The second acquisition unit is used to acquire the missing semantic slots of the initial natural language requirement when the confidence of the intent is less than the preset confidence threshold, and generate a reverse lookup question based on the missing semantic slots.

[0047] The completion unit is used to obtain feedback information from testers regarding the reverse query, and to semantically complete the initial natural language requirements based on the feedback information to obtain the interface test requirements.

[0048] In one possible design, the first acquisition module includes:

[0049] The feature extraction unit is used to extract features from the interface testing requirements to obtain an initial structured representation; wherein, the initial structured representation refers to intermediate data initially extracted from the interface testing requirements and organized in a structured form;

[0050] The input unit is used to input the initial structured representation into a preset transformation model to obtain an initial IDL description that conforms to the preset IDL syntax specification and reverse verification data corresponding to the initial structured representation;

[0051] A conversion unit is configured to convert the initial IDL description into verification text based on the reverse verification data, and calculate the semantic similarity between the verification text and the initial structured representation;

[0052] The second determining unit is used to confirm the initial IDL description as the IDL description when the semantic similarity is greater than a preset similarity threshold.

[0053] In one possible design, the extraction module includes:

[0054] The third acquisition unit is used to acquire multiple historical scripts and classify the multiple historical scripts to obtain positive datasets and negative datasets; wherein, the multiple historical scripts refer to the set of scripts generated by executing historical test tasks on the interface to be tested within a preset first time period, and the end time of the first time period is earlier than the current time.

[0055] The first generation unit is configured to generate positive constraints based on the positive dataset and negative constraints based on the negative dataset; wherein the positive dataset refers to the set of scripts that have been successfully tested from the plurality of historical scripts, and the negative dataset refers to the set of scripts that have failed to be tested from the plurality of historical scripts.

[0056] The information extraction unit is used to extract information from the IDL description based on the positive constraints and the negative constraints to obtain the script data object; wherein, the positive constraints are used to limit the interface parameter associations and validation rules that should be included in the script data object, and the negative constraints are used to limit the interface call patterns and parameter configuration methods that should be avoided in the script data object.

[0057] In one possible design, the interface test script generation device further includes:

[0058] The second acquisition module is used to acquire interface change information of the interface to be tested in response to the current time reaching a preset detection time; wherein, the interface change information is used to represent the difference between the interface definition of the interface to be tested acquired at the preset detection time and the historical baseline interface definition, wherein the historical baseline interface definition is the interface definition of the interface to be tested acquired at the previous detection time of the preset detection time.

[0059] The update module is used to update the script data object according to the interface change information to obtain the updated script data object, and generate an updated interface test script based on the updated script data object.

[0060] In one possible design, the update module includes:

[0061] The fourth acquisition unit is used to acquire multiple historical interaction records and current environment variables; wherein, the multiple historical interaction records are used to represent the historical behavior patterns and calling rules of the interface to be tested, and the current environment variables are used to represent the environmental characteristics when testing the interface to be tested;

[0062] The optimization unit is used to optimize the preset generation logic of the script data object based on the multiple historical interaction records and the current environment variables to obtain the optimized generation logic.

[0063] The update unit is used to update the script data object based on the optimized generation logic and the interface change information to obtain the updated script data object.

[0064] In one possible design, the update unit includes:

[0065] An analysis component is used to identify the change type and analyze the impact domain of the interface change information to obtain the change type and impact domain; wherein, the change type includes parameter addition, parameter obsolescence, parameter type change, parameter constraint change and interface call path change;

[0066] An update component is used to determine the target fields and target logic in the script data object that are affected by the change type and the influence domain according to the change type and the influence domain, and update the target fields and the target logic to obtain the updated script data object.

[0067] In one possible design, the generation module includes:

[0068] The parsing unit is used to parse the script data object to obtain the interface call sequence contained in the script data object and the dependency relationship between multiple preset interfaces;

[0069] The deduction unit is used to perform concurrent execution path deduction on the interface call sequence based on the dependency relationship, so as to identify potential failure scenarios under preset concurrency pressure;

[0070] The second generation unit is configured to generate at least one compensating test case based on the potential failure scenario; wherein the compensating test case includes verification logic for verifying the interface under test in the potential failure scenario;

[0071] The fusion unit is used to fuse the compensatory test cases and the basic test script generated based on the script data object, so that when the interface test script is executed in the preset test framework, it performs functional verification of the interface to be tested and simulates concurrent conflicts to trigger the potential failure scenario, thereby obtaining the interface test script.

[0072] Thirdly, embodiments of this application provide an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0073] The memory stores computer-executed instructions;

[0074] When the processor executes the computer execution instructions stored in the memory, it is used to implement the method for generating interface test scripts as described in any of the first aspects.

[0075] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method for generating an interface test script as described in any of the first aspects.

[0076] Fifthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, is used to implement the method for generating interface test scripts as described in any of the first aspects.

[0077] This application provides a method, apparatus, device, medium, and product for generating interface test scripts. By transforming interface test requirements into IDL descriptions conforming to preset IDL syntax specifications, it achieves standardized and structured expression of test requirements. Then, it performs unified information extraction on the IDL description to obtain a script data object containing interface call sequences, parameter rules, and verification logic. This transforms the previously fragmented and disorganized test information, which relied on manual understanding, into structured data that can be directly processed by machines. Finally, based on this script data object, it automatically generates interface test scripts adapted to a preset test framework, completing the automated construction of interface calls and result verification. The entire process no longer relies on testers manually analyzing interface documents, sorting out interface call relationships, writing test data, and designing verification rules, reducing reliance on human experience, shortening the interface test script generation cycle, and improving the reusability of test logic and scripts. It solves the problems of low efficiency, long cycle, and difficulty in reusing interface test scripts in the prior art. Attached Figure Description

[0078] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0079] Figure 1 A schematic diagram illustrating an application scenario of the method for generating interface test scripts provided in this application embodiment;

[0080] Figure 2 A flowchart illustrating the method for generating interface test scripts provided in this application embodiment. Figure 1 ;

[0081] Figure 3 A flowchart illustrating the method for generating interface test scripts provided in this application embodiment. Figure 2 ;

[0082] Figure 4 A flowchart illustrating the automated generation and iterative closed-loop process of interface test scripts provided in this application embodiment;

[0083] Figure 5 A layered architecture diagram of the interface automation script generation system provided in the embodiments of this application;

[0084] Figure 6 A flowchart illustrating the bidirectional conversion architecture of the AI ​​large model script description parsing module provided in this application embodiment;

[0085] Figure 7 A five-in-one intelligent agent architecture diagram for generating intelligent agents using AI interface automated scripts provided in this application embodiment;

[0086] Figure 8 System architecture diagram of the big data intelligent analysis module provided in the embodiments of this application;

[0087] Figure 9 A schematic diagram of the structure of the interface test script generation device provided in the embodiments of this application;

[0088] Figure 10 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application.

[0089] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0090] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0091] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0092] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply difference. It should be noted that in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner. In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more.

[0093] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation. The embodiments of this application do not specifically limit this. In addition, the method, apparatus, device, medium, and product for generating interface test scripts provided in the embodiments of this application are only examples. The method, apparatus, device, medium, and product for generating interface test scripts may also include more or less content.

[0094] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0095] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0096] To clearly understand the technical solution of this application, we will first provide a detailed introduction to the solutions in the prior art. In environments where distributed services and micro-interface architectures are widely used, business functions are typically implemented collaboratively by multiple interfaces. The correctness, stability, and execution reliability of these interfaces directly determine the overall operational quality of the system. As business scenarios become increasingly complex and the number of interfaces continues to grow, it is necessary to verify various interfaces through standardized and automated methods to ensure the correctness of system logic, the reliability of data interaction, and the stable operation of business processes. Therefore, the generation of interface test scripts has become a key link in ensuring the quality of system development and delivery efficiency.

[0097] In existing technologies, testers typically manually write test cases and validation logic based on the addresses, parameters, and request methods defined in the interface documentation. Following a pre-defined interface call order, they generate interface test scripts that can run within the corresponding test framework to verify the interface functionality. Because writing interface test scripts heavily relies on testers' in-depth understanding of the business logic and technical implementation, testers need to spend a significant amount of time manually analyzing interface documentation, clarifying the call relationships between interfaces, writing test data, and designing validation rules. This results in a long script generation cycle and makes the scripts difficult to reuse. Therefore, existing technologies suffer from low efficiency in generating interface test scripts.

[0098] Therefore, addressing the low efficiency of interface test script generation in existing technologies, this research found that to solve this problem, testers' experiential testing needs can be transformed into standardized interface description languages, and structured information can be automatically extracted to generate executable test scripts. This transforms the script writing process from manual operation to automated construction: ① Testers' original testing intentions, expressed through natural language or fragmented documents, can be transformed into machine-readable, structured, and unified description files, eliminating test information biases caused by differences in individual testers' understanding. This ensures that subsequent automated processing is based on standardized and consistent semantics, thereby reducing reliance on manual document analysis. ② For standardized test requirement descriptions, core elements related to interface testing can be automatically extracted using preset parsing rules or models. These elements include interface call relationships, input data constraints, and result verification standards. This transforms the scattered test logic in the text into a data structure that the computer can directly manipulate, providing precise and unambiguous building blocks for subsequent script generation. ③ After obtaining structured data containing test logic, a mapping relationship between the data and multiple test frameworks can be established, and the data can be translated into executable scripts that conform to the syntax specifications of specific frameworks. This decouples the test logic from the underlying execution framework, allowing the same set of test descriptions to adapt to different test environments, improving the script generation speed and cross-platform reusability.

[0099] Specifically, the testers' testing intentions for interface functions can be transformed into structured descriptions that follow preset specifications, thereby achieving formal unification of scattered test requirements. Then, by parsing this structured description, key test elements, including interface interaction logic, data constraints, and verification conditions, can be automatically extracted. Based on these elements, a test execution body that can be directly run in the target test framework can be generated. This transforms the script writing process, which originally relied on manual analysis, sorting, and coding, into a standardized construction process that can be completed automatically by machines.

[0100] This application discloses a method, apparatus, device, medium, and product for generating interface test scripts. By transforming interface test requirements into IDL descriptions conforming to preset IDL syntax specifications, it achieves standardized and structured expression of test requirements. Then, it performs unified information extraction on the IDL description to obtain a script data object containing interface call sequences, parameter rules, and verification logic. This transforms the previously fragmented and disorganized test information, which relied on manual understanding, into structured data that can be directly processed by machines. Finally, based on this script data object, it automatically generates interface test scripts adapted to a preset test framework, completing the automated construction of interface calls and result verification. The entire process no longer relies on testers manually analyzing interface documents, sorting out interface call relationships, writing test data, and designing verification rules, reducing reliance on human experience, shortening the interface test script generation cycle, and improving the reusability of test logic and scripts. This solves the problems of low efficiency, long cycle, and difficulty in reusing interface test scripts in the prior art.

[0101] Based on the above-mentioned inventive discovery, the technical solution of this application is proposed.

[0102] The following describes the application scenarios of the interface test script generation method provided in the embodiments of the present invention. Figure 1 This is a schematic diagram illustrating an application scenario of the method for generating interface test scripts provided in this application embodiment. For example... Figure 1 As shown, the application scenario includes a mobile terminal 101 and a server 102. The mobile terminal 101 collects interface testing requirements and sends them to the server 102. The server 102 extracts information from the IDL description to obtain a script data object. The server 102 then generates the interface test scripts required for the interface testing requirements based on the script data object.

[0103] The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0104] Figure 2 A flowchart illustrating the method for generating interface test scripts provided in this application embodiment. Figure 1 .like Figure 2As shown, in this embodiment, the execution entity of this invention is a server. Therefore, the method for generating the interface test script provided in this embodiment includes the following steps:

[0105] S201. Obtain the interface testing requirements and convert them into an IDL description that conforms to the preset IDL syntax specification; wherein, the interface testing requirements are used to represent the test content of the interface to be tested by the testers.

[0106] Specifically, the system can receive test intentions input by testers in a visual interactive interface by selecting interfaces, dragging and dropping components, and filling in parameter tables. These intentions serve as interface test requirements. This step transforms the testers' scattered test ideas into preliminary electronic records. Then, a syntax parsing engine is called to perform lexical analysis and syntax checks on the electronic records, reorganizing them into code descriptions that conform to the preset interface description language specifications. This step enables test requirements that originally relied on manually written documents to be accurately identified and processed by computers, providing a standardized data foundation for subsequent automated parsing and execution.

[0107] For example, testers might need to test the "Create Group Chat" API in an instant messaging application. In the visual interface, testers select the "Create Group Chat" API from the left-hand API list. Then, they drag a "User Login" component from the center of the interface before the "Create Group Chat" component to indicate that a login operation is required first. Next, testers fill in the API input parameters in the parameter table on the right. For example, they enter "Discussion Group" in the "Group Chat Name" field and select pre-imported test accounts user1 and user2 in the "Initial Members" field. After completing this, the tester clicks the "Generate" button. The system then converts the above operations into a preliminary electronic record. Subsequently, the background's syntax parsing engine parses this record, checks its logical order and parameter format for completeness, and reassembles it into a text description conforming to the preset Interface Description Language (IDL) syntax specification.

[0108] Interface testing requirements refer to the specific test content and requirements proposed by testers for the interface to be tested. It covers information such as which interfaces need to be tested, in what order they are called, what parameters are input, and what results are expected. For example, if testers need to verify whether the "create group chat" function is working properly, the test requirements can be described as follows: Under the premise that the user is logged in, call the create group chat interface, the group chat name is "discussion group", the members include user1 and user2, and the expected status code returned after the interface call is successful is 200.

[0109] The default IDL syntax specification is a set of predefined standardized syntax rules for writing interface descriptions. It specifies how to express the call order, input parameters, and verification conditions of the interface in a structured way to ensure the machine readability and format consistency of the description. For example, the specification can specify the use of the "pre-operation:" tag to indicate operations that must be performed first, the use of the "test steps:" tag to describe the interface to be tested and its parameters, and the use of the "expected result:" tag to define the verification logic.

[0110] An IDL description is a textual expression of interface testing requirements written according to a predefined IDL syntax specification. It is an intermediate form between human natural language and machine code, and can be accurately parsed and processed by computer programs. For example, according to the above specification, a complete IDL description can be written as: Pre-operation: User login; Test steps: Create a group chat, the group name is discussion group, and the members include user1 and user2; Expected result: Return status code 200.

[0111] S202. Extract information from the IDL description to obtain a script data object. The script data object is a data structure extracted from the IDL description, including the interface call sequence, parameter rules, and validation logic. The script data object is used to represent the structured information of the interface testing requirements.

[0112] Specifically, a syntax parser can be invoked to traverse and scan the IDL description that conforms to the preset IDL syntax specification, identify the interface call sequence labels, parameter constraints and assertion statements defined therein, and fill these identified contents into a predefined data container to generate a script data object containing interface call sequence, parameter rules and validation logic. This step is used to transform the text form of the IDL description into structured data that can be directly accessed and processed in computer memory.

[0113] For example, the system calls the syntax parser to traverse and scan the IDL description text generated in the previous step. Suppose the IDL description content is: "Pre-operation: User login; Test step: Create a group chat, group name 'Discussion Group', members include user1 and user2; Expected result: Return status code 200". The syntax parser identifies "User login" after the "Pre-operation" tag as the first call in the interface call sequence, identifies "Create group chat" and its parameters after the "Test step" tag as the second call and its corresponding parameter rules, and identifies "Return status code 200" after the "Expected result" tag as validation logic. The parser fills the identified content into pre-defined data containers in memory. For example, in a structure named Script Data Object, the interface call sequence field is assigned the value ["login", "createGroup"], the parameter rule field is assigned the value {"createGroup": {"name": "discussion group", "members": ["user1", "user2"]}}, and the validation logic field is assigned the value {"createGroup": "response.code==200"}, generating a script data object that can be directly read and processed by subsequent steps.

[0114] Script data objects refer to structured data collections extracted from IDL descriptions and stored in computer memory. They systematically organize the core elements of interface testing requirements in the form of key-value pairs, arrays, or objects, including the calling order of interfaces, the input parameters required for each interface, and the validation rules that each interface should meet. For example, a script data object extracted from an IDL description can be represented as: calling order is [user login, create group chat], parameter rules are {create group chat: {group chat name: discussion group, members: [user1, user2]}}, and validation logic is {create group chat: response status code equals 200}.

[0115] S203. Generate the interface test script required for the interface test based on the script data object; wherein, the interface test script is used to execute interface calls and result verification in the preset test framework to realize the testing of the interface to be tested.

[0116] Specifically, a code generation engine can be invoked, taking the interface call sequence, parameter rules, and validation logic contained in the script data object as input. By traversing the data object and matching the preset test framework code template, interface call statements, parameter assignment statements, and assertion statements that conform to the syntax of the target test framework are generated line by line, and finally combined to form a complete interface test script file. This step is used to convert the structured data in memory into program code that can actually run in the specified test environment.

[0117] For example, the script data object generated in the previous step is passed to the code generation engine. The engine first reads the interface call sequence in the script data object and identifies that the two operations of user login and group chat creation need to be executed in sequence. Then, the engine obtains the parameter information required for the group chat creation operation from the parameter rule field, namely the group name and member list. Then, the engine finds the corresponding interface call code template according to the preset template matching rules. The engine generates the code line by line: first, it generates the statement to call the user login interface, then it generates the statement to call the group chat creation interface with the group name and member list parameters, and finally it obtains the condition of the expected status code 200 from the validation logic field and generates the corresponding assertion statement. After all the code is generated, the engine writes it into a new file starting with "test", forming a complete interface test script that can be run directly.

[0118] Interface test scripts are program code files written according to the syntax specifications of a specific testing framework and can be run directly. They use specific statements in a programming language to transform the test logic in the script data object into machine-executable instructions, realizing the actual invocation and automated verification of the interface. For example, an interface test script generated based on a testing framework might contain the following code: first, it calls the user login interface; then, it calls the create group chat interface with the group chat name and member list parameters; finally, it uses an assert statement to check if the returned status code is 200.

[0119] An API call refers to the process of sending a network request to an API under test programmatically and receiving the response data returned by the API. It simulates the real interaction between a client and a server. Result verification involves analyzing and judging the response data returned after the API call to verify whether it meets the pre-set expected results. For example, an API call might send a POST request via Hypertext Transfer Protocol (HTTP) to the Uniform Resource Locator (URL) of the group chat creation API, carrying the group chat name and member information. Result verification would then check whether the status code field in the server's response is 200. If it is not 200, the test case is considered to have failed.

[0120] The method for generating interface test scripts can be widely applied in technical fields such as backend service development testing, IoT device interface debugging, enterprise internal management system interface verification, and cloud service interface integration testing. Specifically, it is suitable for technical scenarios such as batch iterative testing of interfaces, multi-interface linkage function verification, rapid reuse and batch generation of test scripts, and standardized execution of cross-team interface tests. It can specifically solve the problems of manual writing of interface test scripts, excessive time consumption in test requirement sorting, difficulty in structured reuse of interface call relationships and verification rules, inconsistent script formats written by different testers, low script generation efficiency caused by machines' inability to directly parse scattered test requirements, long test cycles, and poor test logic reusability in various technical scenarios. At the same time, it is compatible with various general interface testing frameworks, ensuring the efficiency and standardization of interface function verification and reducing the excessive reliance on manual business and technical experience in the interface testing process.

[0121] This embodiment provides a method for generating interface test scripts. By transforming interface test requirements into IDL descriptions conforming to preset IDL syntax specifications, it achieves standardized and structured expression of test requirements. Then, it performs unified information extraction on the IDL description to obtain a script data object containing interface call sequences, parameter rules, and validation logic. This transforms the originally fragmented and disorganized test information, which relied on manual understanding, into structured data that can be directly processed by machines. Finally, based on the script data object, it automatically generates interface test scripts adapted to the preset test framework, completing the automated construction of interface calls and result validation. The entire process no longer relies on testers manually analyzing interface documents, sorting out the call relationships between interfaces, writing test data, and designing validation rules. This reduces reliance on human experience, shortens the interface test script generation cycle, and improves the reusability of test logic and scripts. It solves the problems of low efficiency, long cycle, and difficulty in reusing interface test scripts in the prior art.

[0122] In one possible design, interface testing requirements are obtained in S201, including:

[0123] S2011. Obtain the initial natural language requirements input by the testers and calculate the intent confidence of the initial natural language requirements.

[0124] Specifically, the system can receive sentence text entered by testers in a natural language input box as the initial natural language requirement. This text is then input into the intent recognition model, which consists of three interconnected components: a word segmenter, a vectorization layer, and a classifier. The word segmenter first segments the input sentence into independent lexical units. Then, the vectorization layer maps each lexical unit to a corresponding word vector and combines the word vectors of the entire sentence into a sentence vector. The classifier receives this sentence vector as input and calculates its matching probability with each predefined intent category through a multi-layer neural network. Finally, it outputs the result with the highest probability value as the intent confidence score. This step is used to determine whether the original sentence entered by the tester is semantically clear enough to be accurately classified by the system and directly converted into standardized interface test requirements.

[0125] For example, a tester enters the sentence "I want to test the group chat creation function to see if it works" into the natural language input box. The system takes this sentence as the initial natural language requirement and inputs it into the intent recognition model. The word segmenter in the model first segments the sentence into independent lexical units such as "I", "want", "test", "a little", "create group chat", "function", and "success". Then, the vectorization layer maps these lexical units into corresponding word vectors and combines all the word vectors of the whole sentence into a sentence vector. The classifier receives this sentence vector as input and calculates its matching probability with each predefined intent category through a multi-layer neural network. Assuming that the predefined intents include "scenario test", "single interface test", and "sequential test", the sentence has the highest matching probability of matching the "single interface test" category, reaching 0.92. The classifier outputs this probability value of 0.92 as the intent confidence.

[0126] Initial natural language requirements refer to the raw test ideas initially entered by testers in natural language sentences without any processing. These may include colloquial expressions, incomplete information, or semantic ambiguity. For example, "Test file upload" entered by a tester is an initial natural language requirement. Although this sentence expresses the test intention, it lacks key information such as the specific interface name and expected results. Interface test requirements, on the other hand, are structured descriptions that have been identified, filtered, or completed by the system and contain clear test elements (such as test scenarios, interface call order, and verification rules). They can be directly used for subsequent standardized conversion processing.

[0127] Intent confidence is a quantitative value calculated by an intent recognition model to measure the degree of match between an initial natural language requirement and a predefined test intent category. It is usually represented by a probability value between 0 and 1. The higher the value, the clearer the semantic meaning of the sentence and the easier it is for the system to classify it accurately. For example, if a tester enters "I want to test the group chat creation function", the intent recognition model calculates that its matching probability with the "single interface test" category is 0.92. This 0.92 is the intent confidence, indicating that the system is 92% confident that the user wants to test a single interface.

[0128] S2012. When the confidence level of the intent is greater than or equal to the preset confidence threshold, the initial natural language requirements are determined as interface test requirements; wherein, the interface test requirements include natural language descriptions of test scenarios, interface call order and verification rules.

[0129] Specifically, the intent confidence value output by the intent recognition model can be read and compared with a pre-set confidence threshold in the system, such as 0.85. If the confidence value is greater than or equal to the threshold, a requirement confirmation instruction is triggered, and the initial natural language requirement along with its corresponding intent tag is stored in the requirement cache as an interface test requirement for subsequent processing. This step is used to filter out valid requirements from the original statements input by testers that are semantically clear and can proceed to the next processing stage without further questioning.

[0130] For example, if the intent confidence score output by the intent recognition model is 0.92, this score is compared with the pre-set confidence threshold of 0.85. Since 0.92 is greater than 0.85, the triggering condition is met, and a requirement confirmation instruction is triggered. The initial natural language requirement entered by the tester, "I want to test the group chat creation function to see if it can be successful," along with its corresponding "single interface test" intent tag, is stored in the requirement cache. At this point, although the interface test requirement stored in the cache is still a natural language description, it has been marked with a clear test intent, which implicitly includes the "create group chat" interface involved in this test and the expected focus on the verification rule of "whether it can be successful."

[0131] The pre-set reliability threshold is a pre-defined numerical standard used to determine whether the initial natural language requirement is clear enough to be directly adopted. It represents the system's minimum acceptable level of accuracy in understanding user intent. For example, setting the pre-set reliability threshold to 0.85 means that only when the confidence value of the intent recognition model's output reaches or exceeds 0.85 will the system consider the current input sufficiently clear and can be directly accepted as a valid requirement for subsequent processing without further questioning. The pre-set reliability threshold can be determined by collecting historical test requirement data, selecting semantically clear and information-complete samples as positive examples, conducting batch tests on the intent recognition model, determining the model's accuracy and recall at different thresholds, and selecting the value that balances the two or meets specific business requirements as the final threshold. For example, when 1,000 historical test requirements were selected to test the model, it was found that when the threshold was set to 0.85, the accuracy reached 95% and the recall reached 90%. However, when the threshold was set to 0.90, the accuracy increased to 97% but the recall decreased to 80%. After comprehensive consideration, 0.85 was selected as the preset reliability threshold.

[0132] Natural language descriptions of test scenarios, API call order, and validation rules refer to specific explanations of the three core elements of API testing activities, expressed in everyday language. The test scenario describes the background or conditions under which the test occurs; the API call order specifies the sequence in which multiple APIs are called; and the validation rules indicate the expected results for determining whether the test passes or fails. For example, a complete natural language description could be: "In a scenario where the user is already logged in, first call the 'Create Group Chat' API, then call the 'Invite Members' API, and finally verify that the 'Create Group Chat' API returns a non-empty group ID and the 'Invite Members' API returns a success status code."

[0133] S2013. When the confidence level of the intent is less than the preset confidence threshold, obtain the missing semantic slots of the initial natural language requirements, and generate a reverse lookup question based on the missing semantic slots.

[0134] Specifically, dependency parsing can be performed on initial natural language requests with intent confidence below a threshold to identify whether there is any specific content to fill in the required semantic slots corresponding to the core predicate verbs in the sentence. For the identified empty slots, the module selects the corresponding rhetorical question from a pre-set question template library and fills the name of the empty slot into the sentence placeholder to generate a complete natural language question. This step is used to locate the specific location where the information in the tester's original description is incomplete and generate targeted follow-up questions to guide the tester to supplement the missing key test information.

[0135] For example, a tester enters the sentence "Test file upload" into the natural language input box. The calculated intent confidence score of this sentence is only 0.65, lower than the preset threshold of 0.85. Therefore, the system performs dependency parsing on the sentence, identifying the required semantic slots corresponding to the core predicate verb "upload," including "upload interface," "target path," and "expected result." The analysis reveals that the sentence only contains the action description of "file upload," but details such as which interface is being used for "upload," which directory is being used for "target path," and what the "expected result" should be are missing. For these missing slots, the module selects corresponding rhetorical questions from a pre-set question template library. For example, for the "upload interface" slot, it selects "Which upload interface do you want to test?", and for the "expected result" slot, it selects "What is your expected successful result?" The system combines these rhetorical questions to generate a complete natural language question: "Which upload interface do you want to test? What is your expected successful result?" and displays it on the interactive interface.

[0136] In this context, missing semantic slots refer to the gaps in key information that are not present in the sentence but are required by grammatical rules or business logic, identified during semantic analysis of the initial natural language requirements. These gaps typically correspond to core elements in the test requirements, such as the name of the interface to be tested, input parameters, or expected results. For example, if a tester inputs "test file upload," semantic analysis reveals that the sentence lacks two key pieces of information: "which specific upload interface is being tested" and "what is the expected result." These two gaps are the missing semantic slots.

[0137] Reverse lookup questions refer to natural language questions that the system automatically generates and sends to testers to guide them in filling in the missing information for identified missing semantic slots. These questions typically use an interrogative structure to explicitly point to the specific content that needs to be filled in. For example, for a missing semantic slot identified in "Test file upload," the system generates a reverse lookup question: "Which upload interface do you want to test? What is your expected success result?"

[0138] S2014. Obtain feedback from testers regarding reverse query questions, and semantically complete the initial natural language requirements based on the feedback to obtain the interface test requirements.

[0139] Specifically, the system can receive supplementary text entered by testers in the dialogue input box in response to reverse lookup questions as feedback information. This feedback information is then combined with the original initial natural language requirement text. Subsequently, entity recognition and intent re-analysis are performed on the combined complete text to extract key information such as previously missing interface names, parameter values, or expected results. This information is then filled into the corresponding slots in the pre-built requirement template to form a complete interface test requirement. This step is used to supplement the key test elements missing in the testers' initial description through human-computer interaction and question-and-answer, making the originally vague and incomplete requirements clear and usable.

[0140] For example, the system displays a reverse query: "Which upload interface do you want to test? What is your expected success result?" The tester enters supplementary text in the dialog input box: "Test file upload interface, expected return status code 200." After receiving this feedback, the system concatenates it with the original initial natural language requirement "Test file upload," forming the complete text "Test file upload, test file upload interface, expected return status code 200." Subsequently, the system calls the semantic filling module to perform entity recognition on the concatenated text, extracting key information: the interface name is "file upload interface," and the expected result is "return status code 200." The module fills this extracted information into the corresponding slots in the pre-built interface test requirement template. For example, "file upload interface" is filled into the "interface to be tested" slot, and "return status code 200" is filled into the "validation rule" slot, ultimately forming a complete interface test requirement.

[0141] The technical effect of this solution in this embodiment is as follows: By calculating the intent confidence of the initial natural language requirements input by testers, it can automatically determine whether the intent of the requirements is clear and explicit. When the confidence meets the threshold, it is directly identified as an interface test requirement. When the confidence is insufficient, it identifies missing semantic slots and generates reverse lookup questions. Combined with the feedback information from testers, the initial requirements are semantically completed, thereby obtaining complete and accurate interface test requirements that include test scenarios, interface call order, and verification rules. This achieves intelligent parsing and completion of test requirements in natural language form, reduces the requirements for the standardization of tester input, and avoids errors in subsequent IDL description conversion and script generation due to unclear requirement expression and incomplete information. It solves the problem that vague, incomplete, and inaccurate intent recognition of natural language test requirements affects the accuracy and reliability of interface test script generation.

[0142] In one possible design, S201 translates interface testing requirements into IDL descriptions that conform to a predefined IDL syntax specification, including:

[0143] S2015. Extract features from the interface test requirements to obtain an initial structured representation; where the initial structured representation refers to the intermediate data initially extracted from the interface test requirements and organized in a structured form.

[0144] Specifically, a natural language processing pipeline can be invoked to perform sequence labeling on the interface test requirement text. This pipeline consists of three components: a word segmenter, a part-of-speech tagger, and an entity recognizer. The word segmenter first divides the input requirement text into independent lexical units. The part-of-speech tagger labels the part-of-speech role of each lexical unit in the sentence. Based on the part-of-speech tagging results and a predefined entity dictionary, the entity recognizer extracts key information such as test scenarios, interface names, parameter values, and verification conditions from the lexical sequence and fills this information according to a predefined slot structure to form intermediate data in the form of key-value pairs. This step is used to transform unstructured natural language descriptions into a preliminary structured form that is computer-operable and based on key information units.

[0145] For example, the interface test requirement text is: "In a scenario where the user is already logged in, test the interface to create a group chat. The group chat name is 'Discussion Group,' and the members include user1 and user2. The expected return status code is 200." The natural language processing pipeline processes this text. The word segmenter divides the text into lexical units such as "in," "user," "logged in," "of," "scenario," "under," "test," "create group chat," "interface," "group chat name," "for," "discussion group," "members," "including," "user1," "and," "user2," "expected," "return," "status code," and "200." The part-of-speech tagger labels each lexical unit with a part of speech; for example, "user" is labeled as a noun, "logged in" as a verb phrase, and "create group chat" as the interface name. The entity recognizer extracts key information from the lexical sequence based on the part-of-speech tagging results and a predefined entity dictionary: the test scenario is "user is logged in," the interface name is "create group chat interface," the parameter values ​​include "group chat name is 'Discussion Group'" and "members include user1 and user2," and the validation condition is "return status code 200." The entity recognizer fills this information according to a predefined slot structure to form an initial structured representation in the form of key-value pairs.

[0146] The initial structured representation refers to the intermediate data extracted from the interface test requirement text using natural language processing technology and organized in the form of key-value pairs or objects. It transforms the unstructured natural language description into computer-recognizable information units, including core elements such as test scenarios, interface names, parameter values, and verification rules.

[0147] A natural language processing (NLP) pipeline is a data processing flow consisting of multiple NLP components connected in a specific order. Each component is responsible for completing a specific text analysis task, with the output of one component serving as the input of the next, ultimately achieving automated parsing and information extraction from unstructured text. For example, in an interface testing requirement processing scenario, this pipeline consists of three components: a tokenizer, a part-of-speech tagger, and an entity recognizer. The tokenizer first segments the input requirement text into independent lexical units. The part-of-speech tagger labels each lexical unit with its part-of-speech role in the sentence. The entity recognizer, based on the part-of-speech tagging results and a predefined entity dictionary, extracts key information such as the test scenario, interface name, parameter values, and verification conditions from the lexical sequence and fills this information according to a predefined slot structure, forming intermediate data in key-value pair format. This transforms the unstructured natural language description into a computer-operable, preliminary structured form based on key information units.

[0148] S2016. Input the initial structured representation into the preset transformation model to obtain the reverse verification data corresponding to the initial IDL description and the initial structured representation that conform to the preset IDL syntax specification.

[0149] Specifically, a pre-trained sequence-to-sequence conversion model can be invoked, and the key-value pairs in the initial structured representation can be passed as input sequences to the model's encoder. The encoder transforms each key-value pair into a context vector, and the decoder generates a text sequence that conforms to the preset IDL syntax specification word by word based on the context vector, which is then used as the initial IDL description output. At the same time, the model retains the attention weight distribution and internal state parameters used in each generation step during the decoding process, and combines these parameters into reverse verification data corresponding to the initial structured representation and outputs them together. This step is used to automatically translate the initially organized structured information into standardized interface description language text and record the intermediate computational traces of this translation process so that the accuracy of the translation results can be traced and verified later.

[0150] For example, the initial structured representation is: {Test Scenario: User is logged in, Interface Name: Create Group Chat Interface, Parameters: {Group Chat Name: Discussion Group, Members: [user1, user2]}, Validation Rule: Return Status Code 200}. This key-value pair data is passed as the input sequence to a pre-trained sequence-to-sequence conversion model. The model's encoder converts key-value pairs such as "Test Scenario: User is logged in", "Interface Name: Create Group Chat Interface", "Group Chat Name: Discussion Group", "Members: user1, user2", and "Validation Rule: Return Status Code 200" into context vectors one by one. The decoder generates a text sequence that conforms to the preset IDL syntax specification word by word based on these context vectors. For example, it generates: "Preconditions: User is logged in; Test Interface: Create Group Chat, Parameters: Group Chat Name = Discussion Group, Member List = [user1, user2]; Validation: Response Status Code equals 200". Meanwhile, during the decoding process, the model retains the attention weight distribution and internal state parameters used in each generation step. For example, when recording the generation of the phrase "group chat name", the attention weights are mainly focused on the key-value pair "group chat name: discussion group" in the input sequence. These parameters are combined and packaged into reverse validation data corresponding to the initial structured representation, and output together with the generated initial IDL description.

[0151] The initial IDL description refers to the interface description text generated after inputting the initial structured representation into the preset transformation model. It conforms to the preset IDL syntax specification but has not yet undergone semantic verification. It is a transformation result from structured information to standardized description, and may still have issues with semantic inconsistency with the original requirements. The IDL description, on the other hand, is a standardized interface description text that has undergone semantic verification and has finally been confirmed to be effective. It is a version selected from the initial IDL description that is highly consistent with the semantics of the original requirements.

[0152] Reverse validation data refers to the intermediate data recorded by the preset transformation model during the process of converting the initial structured representation into the initial IDL description. It mainly includes the attention weight distribution and internal state parameters used in each generation step. This data is used to trace the correspondence between each syntactic unit in the initial IDL description and each information slot in the initial structured representation. For example, the reverse validation data records that when generating the word "group chat name", the attention weight was mainly concentrated on the key-value pair "group chat name: discussion group" in the input sequence.

[0153] A pre-trained transformation model is a machine learning model that can convert structured representations into text sequences that conform to specific grammatical rules. It typically employs a sequence-to-sequence architecture, consisting of an encoder and a decoder. The encoder understands the structured information of the input, while the decoder generates the target text word by word. A pre-trained transformation model can be trained by collecting a large amount of historical test requirements and their corresponding standard IDL descriptions as training data. A neural network architecture containing an encoder and decoder can be constructed, and the model is trained using supervised learning. By continuously adjusting the model parameters to minimize the difference between the generated IDL description and the standard description, a model capable of accurately completing the transformation task is obtained. For example, collecting 10,000 historical test requirements, each accompanied by a standard IDL description manually written by experienced testers, and training a Transformer model with this data, a pre-trained transformation model is obtained after multiple rounds of iterative optimization. When a new structured representation is input, the model can output a compliant IDL description.

[0154] S2017. Based on the reverse verification data, convert the initial IDL description into verification text and calculate the semantic similarity between the verification text and the initial structured representation.

[0155] Specifically, a reverse mapping table can be established, which pre-records the correspondence between each syntactic unit in the IDL syntax specification and each information slot in the structured representation. The attention weight distribution recorded in the reverse verification data is read, and the corresponding structured information slot name is found from the reverse mapping table according to the position index of the highest weight. Then, each syntactic unit in the initial IDL description is replaced with the natural language description fragment represented by the slot name, and recombined into a complete natural language text as the verification text. Subsequently, the generated verification text and the initial structured representation are respectively split into keyword sets. By calculating the ratio of the number of overlapping words between the two keyword sets to the total number of words, the semantic similarity value is obtained. This step is used to translate the generated standardized description back into natural language through reverse mapping and quantify its semantic consistency with the original structured information by keyword comparison.

[0156] For example, the system reads the initial IDL description and obtains the attention weight distribution recorded in the reverse verification data. The system queries the pre-established reverse mapping table, which records the "test scenario" slot in the structured representation corresponding to the IDL syntax unit "preconditions", the "interface name" slot corresponding to "test interface", the "parameter: group chat name" slot corresponding to "group chat name", the "parameter: member list" slot corresponding to "parameter: member", and the "verification" slot corresponding to "verification rule". Based on the position index with the highest attention weight, the system replaces each syntactic unit in the initial IDL description with its corresponding natural language description fragment, recombining them into the validation text: "Test scenario: User login; Interface name: Create group chat; Parameter: Group chat name discussion group; Parameter: Members user1 and user2; Validation rule: Response status code 200". The generated validation text and the initial structured representation are then split into keyword sets. The keyword set for the validation text is {test scenario, user login, interface name, create group chat, parameter, group chat name, discussion group, parameter, member, user1, user2, validation rule, response status code, 200}, and the keyword set for the initial structured representation is {test scenario, user login, interface name, create group chat interface, parameter, group chat name, discussion group, member, user1, user2, validation rule, return status code, 200}. By calculating the ratio of the number of overlapping words between the two keyword sets to the total number of words (e.g., 13 overlapping words and 14 total words after deduplication), the semantic similarity is approximately 0.93.

[0157] Among them, the verification text refers to the natural language description that is recombined after replacing the syntactic units in the initial IDL description with the corresponding natural language fragments based on the reverse verification data. It is the result of translating the standardized description back into natural language form and is used to compare the semantics with the original initial structured representation to verify the accuracy of the conversion process.

[0158] Reverse verification data refers to the intermediate computational traces recorded by the pre-defined transformation model during the conversion of the initial structured representation into the initial IDL description. It mainly includes the attention weight distribution and internal state parameters used in each generation step. Its purpose is to trace the correspondence between each syntactic unit in the initial IDL description and each information slot in the initial structured representation; it belongs to the model's internal metadata. Verification text, on the other hand, is a natural language description text generated based on the reverse verification data. It is created by replacing each syntactic unit in the initial IDL description with its corresponding natural language description fragment through a reverse mapping table, and then recombining them. Its purpose is to translate the standardized description back into natural language form for semantic comparison and verification with the original initial structured representation. Reverse verification data is intermediate computational data generated during the transformation process, and verification text is readable text generated from this intermediate data. The former is used to trace mapping relationships, and the latter is used for semantic consistency verification.

[0159] S2018. When the semantic similarity is greater than the preset similarity threshold, the initial IDL description is confirmed as an IDL description.

[0160] Specifically, the semantic similarity can be compared with a pre-set similarity threshold in the system. If the value is greater than the threshold, an IDL confirmation instruction is triggered, transferring the initial IDL description currently in the temporary storage area to the formal IDL storage area and marking it with a "verified" status tag. This serves as input data for subsequent information extraction steps. This step is used to filter out the transformation results that are highly consistent with the original semantic requirements from multiple candidate or initially generated IDL descriptions, ensuring that the standardized descriptions entering the next processing stage are accurate and reliable.

[0161] For example, if the calculated semantic similarity value is 0.93 and the preset similarity threshold is 0.90, and 0.93 is compared with this threshold, the triggering condition is met since 0.93 is greater than 0.90. The system then triggers an IDL confirmation instruction, transferring the initial IDL description currently in the temporary storage area ("Preconditions: User login; Test interface: Create group chat, Parameters: Group chat name = Discussion group, Member list = [user1, user2]; Validation: Response status code equals 200") to the formal IDL storage area and marking it with a "Validated" status tag, which will then serve as input data for subsequent information extraction steps.

[0162] The technical effect of this solution in this embodiment is as follows: By calculating the intent confidence of the initial natural language requirements input by testers, the system can automatically determine whether the intent of the requirements is clear and explicit based on the semantic matching probability of the intent recognition model. When the confidence meets the threshold, it is directly identified as an interface test requirement, achieving rapid identification and admission of explicit requirements. When the confidence is insufficient, dependency parsing is used to identify missing semantic slots and generate reverse lookup questions to guide testers to supplement key information such as interface name and expected results. Then, combined with feedback information, the initial requirements are semantically completed, resulting in complete and accurate interface test requirements that include test scenarios, interface call order, and verification rules. This process, through the collaborative work of the intent recognition model and the slot filling mechanism, achieves intelligent parsing and progressive completion of test requirements in natural language form, reduces the requirements for the standardization of tester input, avoids errors in subsequent IDL description conversion and script generation due to unclear requirement expression and incomplete information, and solves the problem of vague, incomplete, and inaccurate intent recognition of natural language test requirements affecting the accuracy and reliability of interface test script generation.

[0163] In one possible design, S202, information is extracted from the IDL description to obtain a script data object, including:

[0164] S2021. Obtain multiple historical scripts and classify them to obtain positive and negative datasets. Among them, multiple historical scripts refer to the set of scripts generated by executing historical test tasks on the interface to be tested within a preset first time period. The deadline of the first time period is earlier than the current time.

[0165] Specifically, all script files generated by historical test tasks executed within a preset first time period and their corresponding execution result logs can be read from the preset test case library. After reading, each historical script is traversed and filtered according to the final test status label recorded in its execution result log: scripts marked as "pass" or "success" are assigned to the positive dataset, and scripts marked as "failure" or "abnormal" are assigned to the negative dataset. This step is used to collect existing scripts accumulated in historical test activities and divide them into two categories, successful cases and failed cases, according to their actual execution results, providing a data foundation for subsequent extraction of effective experience and error avoidance.

[0166] For example, the system reads all script files and their corresponding execution result logs generated from historical test tasks executed within the past three months from a preset test case library. After reading, it iterates through each historical script and finds a script named "test_create_group_v1.py" whose execution result log records a final test status label of "passed". The system classifies this script into the positive dataset. Another script named "test_upload_file_v2.py" has a final test status label of "failed" recorded in its execution result log. The system classifies this script into the negative dataset. After iterating through and filtering all historical scripts, the system collects a total of 150 scripts that successfully completed tests in the positive dataset and 30 scripts that failed tests in the negative dataset.

[0167] Among them, multiple historical scripts refer to the collection of all script files generated when historical test tasks were executed on the interface to be tested within a preset first time period. These scripts record the interface call logic, parameter configuration, and validation rules used in past testing activities, and are a complete record of historical testing practices. For example, 30 script files such as "test_login.py", "test_create_group_v1.py", "test_upload_file_v2.py", and "test_create_group_v2.py" generated in the past three months together constitute multiple historical scripts.

[0168] A positive dataset refers to a collection of scripts selected from multiple historical scripts that ultimately succeeded in testing. These scripts represent effective test cases that have been proven in practice, and the interface parameter relationships and validation rules they contain can serve as successful experiences for subsequent script generation. For example, selecting 20 scripts from 30 historical scripts that are marked "passed" in their execution logs, including "test_login.py" and "test_create_group_v1.py," constitutes a positive dataset. A negative dataset refers to a collection of scripts selected from multiple historical scripts that ultimately failed in testing. These scripts represent test cases that caused test failures, and the interface call patterns and parameter configuration methods they contain can serve as lessons learned for subsequent script generation to avoid. For example, selecting 10 scripts from 30 historical scripts that are marked "failed" in their execution logs, including "test_upload_file_v2.py" and "test_create_group_v2.py," constitutes a negative dataset.

[0169] S2022. Generate positive constraints based on the positive dataset and negative constraints based on the negative dataset; where the positive dataset refers to the set of scripts that have been successfully tested from multiple historical scripts, and the negative dataset refers to the set of scripts that have failed to be tested from multiple historical scripts.

[0170] Specifically, all scripts in the positive dataset can be scanned to extract the interface parameter relationships and validation rules used in each script. The frequency of these relationships and validation rules in the positive dataset is calculated. Relationships and validation rules with a frequency higher than a preset first frequency threshold are combined to generate a positive constraint rule set. At the same time, all scripts in the negative dataset are scanned to extract the interface call patterns and parameter configuration methods in each script. The correlation between these call patterns and parameter configuration methods and test failure results is analyzed. Call patterns and parameter configuration methods with a correlation higher than a preset second correlation threshold are combined to generate a negative constraint rule set. This step is used to extract effective experiences that can be learned from historical successful cases and to summarize error patterns that need to be avoided from historical failure cases, forming constraint rules to guide the generation of subsequent scripts.

[0171] For example, by traversing and scanning 150 successful scripts in the positive dataset, the relationships and validation rules of the interface parameters used in each script are extracted. During the scanning process, it was found that 120 scripts involving the "Create Group Chat" interface all contained the validation rule "Group chat name cannot be empty", and 100 scripts checked "The returned fileId field is not empty" after calling the "File Upload" interface. The frequency of these relationships and validation rules is calculated, and rules with a frequency higher than a preset first frequency threshold (e.g., 80 times) are combined to generate a positive constraint rule set, which includes: "Create Group Chat Interface: Group Chat Name Cannot Be Empty Validation Rule", "File Upload Interface: Returned fileId Not Empty Validation Rule", etc. Meanwhile, the system traversed and scanned the 30 failed scripts in the negative dataset, extracting the interface call patterns and parameter configurations of each script. It was found that 15 failed "create group chat" scripts had a call pattern of "not calling the user login interface first", and 10 failed "file upload" scripts had a parameter configuration of "uploaded file size exceeds 10MB". The correlation between these call patterns and parameter configurations and the test failure results was analyzed. Patterns with a correlation higher than the preset second correlation threshold (e.g., 0.6) were combined to generate a set of negative constraint rules, including: "create group chat interface: prohibit calling when not logged in" and "file upload interface: uploaded file size should not exceed 10MB".

[0172] Among them, positive constraints refer to the set of interface parameter relationships and validation rules extracted from the positive dataset that frequently appear in historical successful scripts. These relationships and validation rules represent effective testing experience that has been verified in practice, and are used to guide which elements should be included in subsequent script generation to ensure the effectiveness of the test. For example, positive constraints extracted from the positive dataset include: "The validation rules for the group chat creation interface should include a check that the group chat name is not empty" and "The validation rules for the file upload interface should include a check that the returned fileId field is not empty".

[0173] Negative constraints refer to a set of API call patterns and parameter configurations extracted from negative datasets that are highly correlated with test failure results. These patterns and configurations represent erroneous practices that need to be avoided, guiding subsequent script generation to prevent certain situations from occurring in order to reduce test failure issues. For example, negative constraints extracted from negative datasets include: "The group chat creation API should not be called when the user is not logged in" and "The file upload API should not upload files larger than 10MB."

[0174] S2023. Based on positive and negative constraints, information is extracted from the IDL description to obtain a script data object. Positive constraints are used to limit the interface parameter relationships and validation rules that should be included in the script data object, while negative constraints are used to limit the interface call patterns and parameter configuration methods that should be avoided in the script data object.

[0175] Specifically, the IDL description text can be read and a syntax parser can be invoked to scan it, initially identifying the interface call sequence, parameter rules, and validation logic as the raw extraction results. These raw extraction results are then compared with the positive constraint rule set to check if the interface parameter relationships and validation rules satisfy the valid experience patterns recorded in the positive constraints. Any parts that do not satisfy the requirements are adjusted and completed according to the positive constraints. Simultaneously, the adjusted results are compared with the negative constraint rule set to check for any interface call patterns or parameter configurations that need to be avoided, as recorded in the negative constraints. If such patterns exist, a correction instruction is triggered, modifying the corresponding call order or parameter configuration according to the avoidance requirements. The final adjusted structure is then filled into a predefined data container to generate a script data object. This step incorporates historical successes and failures into the information extraction process from the IDL description, ensuring that the generated script data object not only reflects current testing requirements but also inherits effective patterns and avoidance strategies from past testing practices.

[0176] For example, the system reads an IDL description text: "Test Interface: Create Group Chat, Parameter: Group Chat Name = abc; Validation: Return Status Code 200". It calls the syntax parser to scan the text, initially identifying the interface call sequence as "Create Group Chat", the parameter rule as "Group Chat Name = abc", and the validation logic as "Return Status Code 200". This is taken as the initial extraction result. The system then compares this result with the positive constraint rule set. It finds that the positive constraints include a "Create Group Chat Interface: Group Chat Name Cannot Be Empty Validation Rule", while the validation logic in the current extraction result only includes status code checks and lacks validation for a non-empty group chat name. Therefore, the system adjusts and completes the validation logic according to the positive constraints, adding "and group chat name..." to the validation logic. The system compares the adjusted result with the negative constraint rule set, which states that the rule "not empty" is applied. It finds that the negative constraint includes "Creating a group chat interface: Calling is prohibited when not logged in". However, the current extracted result only contains "Creating a group chat" in the interface call sequence, which lacks the prerequisite login operation. The system triggers a correction instruction to add "User Login" as a prerequisite step to the interface call sequence in accordance with the avoidance requirements. Finally, the system fills the adjusted structure into a predefined data container and generates a script data object. The interface call sequence field is assigned the value ["User Login", "Creating a group chat"], the parameter rule field contains "Group chat name = abc", and the validation logic field contains "Creating a group chat returns a status code of 200 and the group chat name is not empty".

[0177] The technical effect of this solution in this embodiment is as follows: By acquiring historical test scripts of the interface to be tested and dividing them into positive datasets of successful tests and negative datasets of failed tests, positive constraints and negative constraints are generated accordingly. Then, information is extracted from the IDL description based on the above two types of constraints to obtain script data objects. This allows the extraction process to draw on historical testing experience, ensuring that the script data objects contain reasonable and testable interface parameter relationships and verification rules, while actively avoiding interface call patterns and parameter configuration methods that led to test failures in the past. This improves the stability and test effectiveness of the extraction results, while reducing the workload of manually sorting out historical test cases. It solves the problems of lack of historical test data guidance when extracting information from IDL descriptions, insufficient reliability of extracted script data objects, and the easy occurrence of unreasonable or test-failure configuration and call logic.

[0178] In one possible design, S203 generates the interface test scripts required for the interface test requirements based on the script data object, including:

[0179] S2031. Parse the script data object to obtain the interface call sequence contained in the script data object and the dependency relationship between multiple preset interfaces.

[0180] Specifically, the interface call sequence field stored in the script data object can be read to extract the sequentially arranged list of interface names as the interface call sequence. The parameter rule field and validation logic field in the script data object can be traversed to analyze whether there is a reference relationship between the output parameter of one interface and the input parameter of another interface, or whether there is a logical constraint between the successful call of one interface and the precondition of the call of another interface. These reference relationships and logical constraints are extracted and combined to generate the dependencies between multiple preset interfaces. This step is used to sort out the execution order of the interfaces and the interrelationship between the interfaces in data transmission or logical conditions from the script data object, providing a foundation for subsequent concurrent execution path deduction.

[0181] For example, the system reads the interface call sequence field stored in the script data object and extracts a list of interface names arranged in order: ["User Login", "Create Group Chat", "Invite Members"]. As the interface call sequence, the system traverses the parameter rule field in the script data object and finds that the parameter rule of the "Create Group Chat" interface references the "token" field returned by the "User Login" interface as an authentication credential. Traversing the verification logic field, the system finds that there is an assertion statement in the verification logic of the "Invite Members" interface, requiring that the "Group ID" field returned by the successful call of the "Create Group Chat" interface must be passed as a required parameter when calling "Invite Members". The system extracts these reference relationships and logical constraints and combines them to generate a dependency relationship between multiple preset interfaces: User Login is followed by Create Group Chat (token passing), and Create Group Chat is followed by Invite Members (group ID passing).

[0182] The interface call sequence refers to the list of interface names extracted from the script data object and arranged in the order of execution. It defines which interfaces need to be called in sequence during the test and the order in which they are called. For example, the interface call sequence extracted from the script data object is: ["User Login", "Create Group Chat", "Invite Members"], which means that during the test, user login should be executed first, then group chat should be created, and finally members should be invited.

[0183] Dependency refers to the interrelationship between interfaces in terms of data transmission or logical conditions. This manifests as one interface's output parameter serving as another's input parameter, or one interface's successful call being a prerequisite for another's call. For example, analysis reveals that the "Create Group Chat" interface references the token field returned by the "User Login" interface as authentication credentials, while the "Invite Members" interface requires the group ID returned by the successful "Create Group Chat" interface as a mandatory parameter. These two associations constitute a dependency between the interfaces: user login leads to "Create Group Chat," and "Invite Members" follows.

[0184] S2032. Based on the dependency relationship, perform concurrent execution path deduction on the interface call sequence to identify potential failure scenarios under preset concurrency pressure.

[0185] Specifically, an execution dependency graph can be constructed based on the parsed interface call sequence and the dependencies between interfaces. Preset concurrency pressure parameters are set in the concurrent execution simulator. The simulator generates multiple concurrent execution paths based on the dependency graph. By traversing all possible concurrency interleaving situations, execution scenarios that may lead to dependency corruption, data inconsistency, or interface call failure under the preset concurrency pressure are identified. These scenarios are recorded as potential failure scenarios. This step is used to pre-simulate possible abnormal situations during concurrent execution in the script generation stage and discover concurrency-related defects that cannot be covered by serial testing.

[0186] For example, based on the parsed interface call sequence [user login, create group chat, invite members] and the dependencies between interfaces (user login is followed by creating group chat and passing a token, creating group chat is followed by inviting members and passing a group ID), the system constructs an execution dependency graph, where user login points to creating group chat, and creating group chat points to inviting members. Subsequently, in the concurrent execution simulator, preset concurrency pressure parameters are set: five virtual users are started simultaneously, each user executes according to the interface call sequence, and the interval between requests follows a random distribution with an average of 500 milliseconds. The simulator generates multiple concurrent execution paths based on the dependency graph and traverses all possible concurrency interleaving situations. During the traversal, the simulator discovers a scenario where user A and user B simultaneously execute the "create group chat" interface, and both read... The same token was returned for user login, but after user A successfully created a group chat, it returned group ID1, while after user B successfully created a group chat, it returned group ID2. Subsequently, both users simultaneously executed the "invite members" interface. User A used group ID1 to invite members, and user B used group ID2. However, because the dependency relationship did not explicitly restrict each token to only create one group chat, the two users' operations were independent, and no dependency relationship was broken. However, when the simulator traversed another intertwined situation, it found that user A started inviting members immediately after completing the creation of the group chat, while user B had not yet completed the creation of the group chat. However, user B mistakenly used group ID1 created by user A when inviting members, resulting in the member invitation interface call succeeding but data ownership being confused. This scenario was identified as a potential failure scenario.

[0187] Concurrent execution path deduction can employ a hybrid modeling approach combining colored Petri nets and Monte Carlo simulation. First, a colored Petri net model is constructed based on the interface call sequence and the dependencies between interfaces. Places represent the pending state of an interface or the availability of resources, transitions represent the execution events of interface calls, and the color attribute of tokens is used to distinguish different concurrent user sessions and their carried context data (such as user tokens or temporarily generated resource identifiers). This model can accurately describe the data transfer relationships, resource contention conditions, and execution order constraints between interfaces. Then, based on this Petri net model, Monte Carlo simulation is introduced to perform random sampling deduction of concurrent execution paths. According to preset concurrency pressure parameters, such as the number of concurrent users, request arrival interval distribution, and interface response time distribution, the model is run multiple times in random simulations. Each simulation generates a possible concurrent execution path, recording the triggering order of transitions, the color change of tokens, and possible conflict states along the path. Based on the accumulation of a large number of simulation samples, high-frequency abnormal interleaving patterns within a pre-defined confidence interval are identified, such as data race conditions, deadlock tendencies, resource overselling scenarios, or dependency violation paths. These patterns are marked as potential failure scenarios. Furthermore, simulation results can be verified using temporal logic to detect execution sequences that violate preconditions for interface calls. By combining colored Petri nets with Monte Carlo simulation, complex execution behaviors under concurrent pressure can be comprehensively rehearsed at a low cost during the script generation phase. This allows for the discovery of concurrent defect scenarios that cannot be covered by serial testing, providing precise scenario inputs for the generation of compensatory test cases.

[0188] Concurrent execution path simulation refers to the process of simulating multiple concurrent execution paths running simultaneously during the script generation phase, based on the interface call sequence and the dependencies between interfaces. This involves traversing various possible execution interleaving scenarios to analyze potential anomalies or conflicts under preset concurrency pressure. For example, based on the interface call sequence [user login, create group chat, invite members] and dependencies (creating a group chat depends on the token returned by user login, inviting members depends on the group ID returned by creating a group chat), five virtual users are set to execute simultaneously in the concurrent execution simulator. The simulator traverses all possible execution interleaving scenarios to analyze potential data races or logical conflicts that may occur when multiple users operate simultaneously.

[0189] Potential failure scenarios refer to specific combinations of execution conditions identified during concurrent execution path simulation that may lead to dependency corruption, data inconsistency, or API call failure under preset concurrency pressure. These scenarios will not be exposed during serial execution but may cause defects in a concurrent environment. For example, a scenario was discovered during concurrent execution path simulation: User A and User B execute simultaneously. User A immediately starts inviting members after creating a group chat, while User B has not yet completed creating a group chat. However, User B incorrectly uses the group ID created by User A when inviting members, resulting in the member invitation API call succeeding but members being added to the wrong group chat. This combination of execution conditions was identified as a potential failure scenario.

[0190] S2033. Generate at least one compensating test case based on the potential failure scenario; wherein the compensating test case includes verification logic for verifying the interface under test under the potential failure scenario.

[0191] Specifically, it can read each identified potential failure scenario, extract the interface name, concurrency conflict type, and specific behavior of the failure in that scenario. For each potential failure scenario, a template matching the conflict type is selected from a pre-set compensation test template library, such as a data race template, deadlock detection template, or timeout retry template. The extracted interface name, conflict type, and failure behavior are filled into the corresponding positions in the template to generate a compensation test case. This test case includes the startup logic for simulating concurrency conflicts, the operation steps for triggering the destruction of specific dependencies, and the verification logic for verifying whether the failure scenario is handled correctly. This step is used to automatically generate a dedicated test case for each potential failure scenario found in the concurrency simulation, so that the interface behavior under these scenarios can be actively triggered and verified in actual testing.

[0192] For example, the system reads the identified potential failure scenario: User A and User B simultaneously perform the operations of creating a group chat and inviting members, causing User B to incorrectly use the group ID created by User A to make the invitation. The system extracts the interface names involved in this scenario as "creating a group chat" and "inviting members", the concurrency conflict type as "data cross-contamination", and the specific manifestation of the failure is "the invitation member interface call is successful, but the member is added to the wrong group chat". The system selects a "resource isolation conflict test template" that matches the "data cross-contamination" type from the pre-set compensation test template library. This template contains the startup logic to simulate the concurrency conflict (starting two threads at the same time), the operation steps to trigger the destruction of specific dependencies (thread 1 creates a group chat and obtains the group ID, thread 2 directly uses thread 1's group ID to call the invite member call without completing its own group chat creation), and the verification logic to verify whether the failure scenario is handled correctly (checking whether the final member list appears in both group chats at the same time, or whether the interface returns a data ownership error message). The system fills the extracted interface name, conflict type and failure manifestation into the corresponding position of the template to generate a compensation test case.

[0193] Compensatory test cases are automatically generated test cases specifically designed to verify the behavior of the interface under test in potential failure scenarios identified during concurrent execution path simulation. These cases include startup logic simulating concurrent conflicts, operational steps that trigger the disruption of specific dependencies, and verification logic to confirm whether the failure scenario is handled correctly. For example, for the potential failure scenario of "User B incorrectly inviting members using a group ID created by User A," the generated compensatory test case includes: concurrent startup logic for starting two threads simultaneously; thread 1 creating a group chat and obtaining the group ID; thread 2 directly using thread 1's group ID to invite members before completing its own group chat creation; and verification logic to check whether the final member list contains data ownership errors or whether the interface returns an error message.

[0194] S2034. Integrate compensatory test cases and basic test scripts generated based on script data objects so that when the interface test script is executed in the preset test framework, it performs functional verification of the interface to be tested and simulates concurrent conflicts to trigger potential failure scenarios, thus obtaining the interface test script.

[0195] Specifically, the code structure of the basic test script can be read to identify the location of the main test function that executes the serial interface call sequence. Simultaneously, each generated compensatory test case is read and encapsulated into an independent concurrent execution function. Each function contains thread startup code simulating concurrent conflicts and corresponding verification logic. Concurrency control instructions, such as thread synchronization barriers or semaphores, are inserted into the main test function of the basic test script. When the main test function reaches an interface call related to a potential failure scenario, the corresponding compensatory test case function is launched, allowing it to execute concurrently with the interface call in the main test function. The verification logic of the compensatory test cases is merged with the assertion statements of the basic test script to ensure that the script can simultaneously verify functional correctness and exception handling capabilities under concurrent scenarios after execution. After fusion, the final interface test script is generated. This step integrates the regular functional test script with the specially designed concurrent conflict test cases, enabling the generated test script to perform basic interface function verification and actively simulate concurrent pressure to trigger potential failure scenarios and verify their handling results in a single execution.

[0196] For example, the system reads the code structure of the basic test script and finds that the main test function, which executes a serial interface call sequence, calls the user login, group chat creation, and member invitation interfaces in sequence. Simultaneously, the system reads the compensatory test case generated in the previous step for the "data cross-contamination" scenario and encapsulates it into an independent concurrent execution function named "test_concurrent_group_invite_conflict". This function contains code that starts two threads to simulate concurrent operations by user A and user B, as well as verification logic. Subsequently, in the main test function of the basic test script, the system inserts a thread synchronization barrier after calling the "group chat creation" interface and before calling the "invite member" interface. The system adds instructions and calls to the "test_concurrent_group_invite_conflict" function. When the main test function reaches this point, it triggers the concurrent execution function of the compensatory test case, allowing it to execute concurrently with the subsequent "invite members" interface call of the main test function. The system merges the validation logic in the compensatory test case (such as checking whether there are data ownership errors in the member list) with the original assertion statements in the basic test script. After merging, the system generates the final interface test script. When this script is executed, it will not only perform functional verification of user login, group chat creation, and member invitation, but also actively simulate concurrent conflict scenarios and verify the behavior of the interface under data cross-contamination.

[0197] The interface test script, when executed within the preset test framework, performs functional verification of the interface under test and simulates concurrent conflicts to trigger potential failure scenarios. This means that during execution, the generated final interface test script not only verifies the basic functions of the interface according to the normal interface call sequence (such as parameter passing and return value validation), but also actively initiates compensatory test cases through built-in concurrency control instructions to simulate simultaneous operations by multiple users or threads. This triggers potential failure scenarios discovered during the concurrent execution path deduction phase and verifies whether the interface behaves as expected in such scenarios. For example, when the generated interface test script is executed in the test framework, it first calls the user login, group chat creation, and member invitation interfaces sequentially, asserting that the return result of each step is correct. Subsequently, before executing the member invitation interface, the script actively starts a concurrent thread to simulate another user's simultaneous operation. Through thread synchronization barriers, it allows both threads to attempt to invite members simultaneously, triggering the potential failure scenario of "user B incorrectly using the group ID created by user A," and verifying whether the interface can correctly handle this data cross-contamination.

[0198] The technical effect of this solution in this embodiment is as follows: By parsing the script data object, the interface call sequence and the dependency relationship between interfaces are obtained. Then, based on the dependency relationship, the concurrent execution path of the interface call sequence is deduced to identify potential failure scenarios under preset concurrency pressure. Based on this, compensatory test cases containing corresponding verification logic are generated and integrated with the basic test script to form the final interface test script. This allows the test script to not only complete the verification of conventional functions, but also simulate the potential failure scenarios triggered by concurrent conflicts, thereby improving test coverage and the ability to verify complex operating scenarios. This enhances the sufficiency and effectiveness of the test and solves the problems of traditional interface test scripts that can only complete basic function verification, lack the ability to detect potential failure problems under interface dependencies and concurrent scenarios, and have incomplete test coverage.

[0199] Figure 3 A flowchart illustrating the method for generating interface test scripts provided in this application embodiment. Figure 2 In this embodiment, in Figure 2 Based on the provided embodiments, the method for generating interface test scripts is further explained. The method for generating interface test scripts includes:

[0200] S301. Obtain the interface test requirements and convert them into an IDL description that conforms to the preset IDL syntax specification; wherein, the interface test requirements are used to represent the test content of the interface to be tested by the testers.

[0201] S302. Extract information from the IDL description to obtain a script data object; wherein, the script data object is a data structure extracted from the IDL description, including the interface call sequence, parameter rules and validation logic, and the script data object is used to represent the structured information of the interface testing requirements.

[0202] S303. Generate the interface test script required for the interface test based on the script data object; wherein, the interface test script is used to execute interface calls and result verification in the preset test framework to realize the test of the interface to be tested.

[0203] S301-S303 are similar to S201-S203, and will not be described again in this embodiment.

[0204] S304. In response to the current time reaching the preset detection time, obtain the interface change information of the interface to be tested; wherein, the interface change information is used to indicate the interface definition of the interface to be tested obtained at the preset detection time, and the difference between the interface definition and the historical baseline interface definition. The historical baseline interface definition is the interface definition of the interface to be tested obtained at the previous detection time of the preset detection time.

[0205] Specifically, the system clock can be read to determine if the current time matches the preset detection time. If they match, an interface change detection command is triggered. The latest interface definition file of the interface to be tested is obtained from the interface document management server, and the historical baseline interface definition file of the interface saved during the last detection is read from the local cache. Then, the current interface definition file is compared line by line with the historical baseline interface definition file to identify the changed, added, or deleted fields. These differences are organized into structured interface change information. This step is used to periodically obtain the changes in the interface definition, providing an accurate basis for adjusting the test script according to the actual changes.

[0206] For example, if the preset detection time is set to 2:00 AM every Monday, when the system clock reaches 2:00 AM on Monday, the current time is read and matched with the preset detection time, triggering an interface change detection command. The system retrieves the latest interface definition file for the "Create Group Chat" interface from the interface document management server, which contains the definitions of the interface address, request parameters, and return fields. At the same time, it reads the historical baseline interface definition file for this interface saved last Monday from the local cache. The current interface definition file is compared line by line with the historical baseline interface definition file. It is found that a new request parameter field "Group Chat Announcement" has been added to the current interface definition, while this field is not present in the historical baseline interface definition. It is also found that the original "group Name" field in the return field has been changed to "name". The system organizes these differences into structured interface change information, including: the addition of the field "Group Chat Announcement" and the change of the field name from "group Name" to "name".

[0207] The preset detection time refers to a fixed time point pre-set by the system administrator to periodically trigger interface change detection tasks. It is usually set during off-peak business hours to ensure that the detection process does not affect normal services. It achieves continuous monitoring of interface definition changes through periodic execution. For example, the system administrator sets the preset detection time to 2:00 AM every Monday in the configuration file, and the system will automatically start the interface change detection process at that time.

[0208] Interface change information refers to the specific changes identified after comparing the current interface definition of the interface under test with the historical baseline interface definition obtained at a preset testing time. These changes are recorded in a structured format, detailing the differences such as changed fields, newly added fields, or deleted fields, to guide the adaptive adjustments of subsequent test scripts. For example, if the system detects that the current definition of the "Create Group Chat" interface has added the "Group Chat Announcement" request parameter field compared to the historical baseline definition, and the "group Name" field in the returned data has been changed to "name," then the information summarizing these differences constitutes the interface change information.

[0209] The preset detection time is not fixed but can be dynamically adjusted based on the historical change frequency and business importance of the interface. For example, the number of changes and the interval between changes to the interface under test within a preset historical time period can be recorded to calculate its change frequency. When the change frequency exceeds a preset frequency threshold, the system can adaptively shorten the detection cycle, for example, adjusting the detection from once a week to once every three days, to improve the response sensitivity to interfaces with high-frequency changes. Conversely, for interfaces that have not changed for a long time or have a low change frequency, the system can appropriately extend the detection cycle, for example, adjusting from once a week to once every two weeks, to reduce unnecessary detection overhead. In addition, weighted adjustments can be made based on the business importance tag of the interface, using a more intensive detection strategy for core business interfaces. In this way, the preset detection time can be dynamically optimized according to the actual change behavior and business attributes of the interface, further improving the timeliness of interface change detection and the efficiency of system resource utilization.

[0210] S305. Update the script data object according to the interface change information to obtain the updated script data object, and generate the updated interface test script based on the updated script data object.

[0211] Specifically, the system can read the changes recorded in the interface change information to identify specific entries involving changes in interface parameter names, parameter types, parameter additions or removals, or interface call addresses. Then, based on these identified changes, the corresponding parameter rule fields, interface call sequence fields, or validation logic fields in the currently stored script data object are synchronously modified. For example, old parameter names are replaced with new ones, obsolete parameter configurations are deleted, or default values ​​are added for newly added required parameters. After modification, an updated script data object is generated and passed to the code generation engine. The engine regenerates interface call statements, parameter assignment statements, and assertion statements based on the new script data object, combining them to form an updated interface test script file. This step ensures that existing test scripts can automatically adapt to changes in interface definitions, keeping test cases synchronized with the latest interface version and preventing script execution failures due to interface changes.

[0212] For example, the system reads the changes recorded in the interface change information: a new field "Group Chat Announcement" is added, and the field name is changed from "group Name" to "name". Based on these changes, the currently stored script data object is modified synchronously. The parameter rule field in the original script data object contains "group Name=discussion group", which the system changes to "name=discussion group". At the same time, since the interface definition has added the "Group Chat Announcement" field, which is not required, the system does not add mandatory validation to this field in the validation logic field, but adds a default empty value to this field in the parameter rule field to ensure that there will be no error due to missing parameters when calling. After the modification is completed, an updated script data object is generated, and then the updated script data object is passed to the code generation engine. The engine regenerates the interface call statement based on the new script data object: calling the group chat interface with the parameters "name=discussion group" and "announcement=", and generating the corresponding assertion statement. The updated interface test script file is then formed, replacing the original old version script.

[0213] The updated script data object refers to a new structured data set generated by synchronously modifying the original script data object based on interface change information. It reflects the latest test requirements after the interface definition changes, including adjusted interface call sequences, parameter rules, and validation logic, and is used to generate test scripts adapted to the latest interface version. The original script data object is structured information extracted from the initial IDL description, reflecting the original test requirements. The updated script data object, however, is a new version obtained by adaptively adjusting the script data object according to the actual changes in the interface definition. The difference lies in the fact that the parameter rules, call sequences, or validation logic in the latter have been synchronously updated to match the latest interface definition.

[0214] The technical effect of this solution in this embodiment is as follows: After generating the interface test script based on the script data object, the solution actively acquires the interface change information of the interface to be tested at a preset detection time, compares the current interface definition with the historical baseline interface definition, identifies the differences in interface changes, and updates the script data object based on the change information. Based on the updated script data object, the solution automatically generates the updated interface test script, realizing synchronous updates and adaptive maintenance between interface changes and test scripts. This eliminates the need for testers to manually monitor interface changes, manually modify and maintain test scripts, improving the adaptability and timeliness of test scripts. It ensures that the test scripts are consistent with the actual interface definition and solves the problems of test scripts not being able to be automatically updated when the interface changes, requiring manual maintenance leading to untimely updates, high maintenance costs, and easy incompatibility between scripts and interfaces.

[0215] In one possible design, S305 updates the script data object based on the interface change information to obtain the updated script data object, including:

[0216] S3051. Obtain multiple historical interaction records and current environment variables; wherein, multiple historical interaction records are used to represent the historical behavior patterns and calling rules of the interface to be tested, and the current environment variables are used to represent the environmental characteristics when testing the interface to be tested.

[0217] Specifically, all request and response data recorded when the interface under test was called within a preset second time period can be read from the interface call log library as multiple historical interaction records. These records contain the request parameters, return results, call timestamps, and caller identifiers for each call. At the same time, the test environment identifier currently set in the system configuration file, such as development environment, test environment, or pre-release environment, as well as the interface domain name, port number, and database connection string corresponding to that environment, can be read as current environment variables. This step is used to collect the past call behavior patterns of the interface and the context information of the current test environment, providing data support for intelligently adjusting the script update strategy according to the actual situation.

[0218] For example, the system reads all request and response data recorded when the "Create Group Chat" API was called within the past 30 days from the API call log library, as multiple historical interaction records. These records contain the request parameters (such as group chat name and member list), return results (such as status code and group ID), call timestamp (such as 2024-05-10 14:30:25), and caller identifier (such as automated test task and front-end application) for each call. At the same time, the system reads the currently set test environment identifier "test environment" from the configuration file, as well as the corresponding API domain name "test-api.example.com", port number "8080", and database connection string "jdbc:mysql: / / test-db:3306 / app", and uses this information as the current environment variables.

[0219] Among them, multiple historical interaction records refer to the collection of all request and response data recorded when the interface under test was called within a preset time period, obtained from the interface call log library. Each record contains information such as call time, request parameters, return result, and caller identifier, which is used to reconstruct the details of the interface's past call behavior. For example, 1,000 call records of the "Create Group Chat" interface in the past 30 days, each record contains the call time "2024-05-10 14:30:25", request parameter "Group Chat Name: Discussion Group", return result "Status Code: 200, Group ID: 12345" and caller identifier "Automated Test Task".

[0220] Current environment variables refer to the set of parameters currently set in the system configuration file that describe the characteristics of the environment in which the interface to be tested is located. These include environment type identifiers (such as development environment, testing environment, pre-release environment) and runtime configuration information such as the interface domain name, port number, and database connection string corresponding to that environment.

[0221] Historical behavior patterns refer to the collective term for the regular characteristics of an interface in past calls, extracted from multiple historical interaction records. These include abstract characteristics such as the frequency distribution of API calls across different time periods, common parameter value tendencies, typical return result types, and success rate trends. Call patterns refer to specific rules, repetitive and predictable, derived from analyzing multiple historical interaction records regarding the API's behavior when called. Examples include periodic fluctuations in call volume over specific time periods, the correlation between certain parameter values ​​and return results, or calling habits corresponding to specific caller identifiers. For instance, analyzing historical interaction records reveals one call pattern: Monday mornings from 9 AM to 11 AM are peak call times, during which API response times are significantly longer; another pattern is that when the group chat name parameter contains the word "test," the returned results frequently show an error message stating "name contains sensitive words."

[0222] S3052. Based on multiple historical interaction records and current environment variables, optimize the preset generation logic of the script data object to obtain the optimized generation logic.

[0223] Specifically, a multi-dimensional optimization algorithm based on rule matching and weighted fusion can be used to combine multiple historical interaction records with current environmental variables to generate optimized generation logic. First, time-series analysis and pattern mining are performed on multiple historical interaction records to extract behavioral patterns of the interface under test under different environmental characteristics. This includes, but is not limited to, clustering results of interface response time distribution, success rate fluctuations, parameter value preferences, and abnormal return patterns under different time periods and load conditions, forming an environment-aware historical behavior feature library. Second, current environmental variables are feature-encoded, converting environmental type identifiers, network latency levels, database connection status, etc., into quantifiable environmental feature vectors. Then, based on preset mapping rules or lightweight decision tree models, the environmental feature vectors are matched with similar scenarios in the historical behavior feature library to identify the historical operating mode closest to the current environment and extract effective testing strategies under this mode, such as timeout thresholds, retry counts, and parameter default value generation rules. Finally, a weighted fusion algorithm is used to combine and optimize the matched historical strategies with the baseline rules in the preset generation logic to generate optimized generation logic adapted to the current environmental characteristics. For example, if historical records show that the success rate of the interface drops and timeout exceptions occur at night during testing, the optimized generation logic will add a retry mechanism and extend the timeout threshold. If the current environment is a pre-release environment and historical records show that interface calls are stable under this environment, the optimized generation logic can appropriately tighten the verification rules to improve detection sensitivity. Through the above methods, a deep integration of historical behavior patterns and real-time environmental characteristics is achieved, enabling the generated optimized logic to have environmental awareness and adaptive capabilities.

[0224] For example, the system reads the historical interaction records of the "Create Group Chat" interface over the past 30 days and extracts historical behavioral characteristics: it finds that the success rate of this interface call between 0:00 and 6:00 AM is only 85%, lower than the 98% during other times. At the same time, it extracts the common parameter value distribution: the group chat name is mostly "Discussion Group", and the number of members is mostly between 2 and 10. The system also reads the current environment variables and identifies the current test environment type as "Test Environment". The historical behavioral characteristics and the current environment type are input into the preset logic optimizer. The optimizer adjusts the existing script data object generation logic according to the predefined optimization rules: for the feature of low call success rate at night, the optimized generation logic adds an automatic retry mechanism for failures, with a maximum of 2 retries. For the feature of the current test environment, the optimized generation logic adjusts the interface call timeout threshold from the default 3 seconds to 5 seconds to adapt to the actual situation of large network fluctuations in the test environment.

[0225] The default generation logic refers to the set of basic rules adopted by the system by default for extracting information from the IDL description and generating script data objects. These rules are usually based on common testing practices and fixed configuration parameter settings, and do not involve dynamic adaptation to historical call patterns and current environmental characteristics. For example, the default generation logic stipulates that the timeout threshold for all interface calls is uniformly set to 3 seconds, newly added request parameter fields are uniformly filled with empty strings as default values, and the script does not include a failure retry mechanism.

[0226] The optimized generation logic refers to a new set of rules obtained by dynamically adjusting the script generation process based on historical behavioral features extracted from multiple historical interaction records and current environment variables, building upon the preset generation logic. These rules enable the script generation process to better adapt to the actual call patterns of the API and the needs of specific testing environments. For example, the optimized generation logic stipulates that for APIs with a low success rate during nighttime calls as shown in historical records, a mechanism to retry a maximum of 2 times should be added to the script; in the current testing environment, the timeout threshold is adjusted from the default 3 seconds to 5 seconds; and for newly added parameter fields, a default value is automatically filled in based on historical common value distributions instead of an empty string.

[0227] S3053. Based on the optimized generation logic, update the script data object according to the interface change information to obtain the updated script data object.

[0228] Specifically, it can read the changes recorded in the interface change information, identify the specific entries involving changes in interface parameter names, parameter types, parameter additions or deletions, or interface call addresses, use the optimized generation logic as the processing rule, traverse and scan the currently stored script data object, and, based on the retry mechanism, timeout threshold, or parameter default value generation rule set in the optimized generation logic, combined with the identified change entries, synchronously modify the corresponding parameter rule fields, interface call sequence fields, or validation logic fields in the script data object. For example, the optimized generation logic specifies that default test values ​​should be added to newly added fields in the development environment. The system then automatically fills in a default value that matches the parameter type and is taken from common historical values ​​for the newly added required parameters according to this rule. The optimized generation logic also specifies that a retry mechanism should be added to interfaces with low success rates in historical nighttime calls. The system then adds retry-related configuration parameters to the validation logic fields. After the modification is completed, the updated script data object is generated. This step is used to incorporate historical call patterns and current environment characteristics during the process of updating the script data object according to interface change information. This ensures that the updated script data object not only adapts to changes in interface definition but also includes optimized configurations for actual running scenarios.

[0229] For example, by reading the changes recorded in the interface change information, the system identifies that the "Create Group Chat" interface has added a boolean request parameter field, "Allow Member Invite?". Simultaneously, the system uses the optimized generation logic as a processing rule to traverse and scan the currently stored script data object. The optimized generation logic specifies that a default value based on historically common values ​​should be added to the new field in the test environment. Based on this rule, the system extracts the distribution of common parameter values ​​from historical interaction records and finds that the field is "true" in 80% of calls. Therefore, the newly added "Allow Member Invite?" field is automatically filled with the default value "true". The optimized generation logic also specifies adding a retry mechanism for interfaces with low historical nighttime call success rates. The system adds a configuration to the validation logic field: if the call fails, automatically retry twice, with a 1-second interval between each retry. After the modification, the system generates an updated script data object, where the parameter rule field includes the original "name=Discussion Group" and the newly filled "allow Member Invite=true", and the validation logic field includes the original return status code check and the newly added retry mechanism configuration.

[0230] The script data object is a baseline version that is directly extracted from the initial IDL description and reflects the original test requirements. The updated script data object is a new version that is dynamically adjusted based on the actual changes in the interface, historical call patterns, and current environment characteristics. The difference between the two is that the parameter rules and validation logic in the latter have been updated to match the latest definition of the interface, and may have added retry mechanisms, timeout threshold adjustments, and other optimized configurations for actual operating scenarios.

[0231] The technical effect of this solution in this embodiment is as follows: During the process of updating the script data object according to the interface change information, by obtaining the historical interaction records and current environment variables of the interface to be tested, the preset generation logic of the script data object is optimized using historical behavior patterns and calling rules. Then, the script data object is updated based on the optimized generation logic. This makes the update process not only adapt to the interface change itself, but also dynamically adjust it by combining historical calling experience and real-time test environment characteristics. This makes the updated script data object more in line with the actual test scenario, avoiding the logical inconsistencies or environmental incompatibility caused by mechanical updates based solely on interface changes. This improves the intelligence and accuracy of interface test script updates and solves the problem that when updating scripts driven by interface changes, only relying on interface differences without considering historical interaction rules and current environmental factors leads to poor adaptability of the updated script data object, rigid generation logic, and insufficient test stability.

[0232] In one possible design, S3053 updates the script data object based on interface change information to obtain the updated script data object, including:

[0233] S30531. Identify the change type and analyze the impact domain of the interface change information to obtain the change type and impact domain; among which, the change type includes parameter addition, parameter obsolescence, parameter type change, parameter constraint change and interface call path change.

[0234] Specifically, a hybrid strategy combining a rule engine and a lightweight machine learning model can be adopted to identify change types and analyze the impact domain of interface change information. First, a change difference extractor based on abstract syntax tree parsing is constructed. This extractor performs a structured comparison between the current interface definition and historical baseline interface definitions, generating fine-grained change difference units. Each unit contains the location of the change, the original content, the target content, and the change context information. Then, these change difference units are input into a pre-defined change type classifier. This classifier uses a fast matching engine based on decision rules and a machine learning model based on gradient boosting trees in collaboration: for changes with standardized formats and fixed patterns, such as adding or deleting parameter fields or modifying names, the rule engine is prioritized for accurate matching and identification; for changes with complex semantics and strong contextual dependencies, such as logical changes in parameter constraints or adjustments to nested data structures, a pre-trained lightweight gradient boosting tree model performs classification and prediction based on historical change samples, outputting change type labels, including parameter addition, parameter obsolescence, parameter type change, parameter constraint change, and interface call path change. After identifying the change type, the system further performs impact domain analysis: based on the metadata model of the interface definition, it constructs an interface parameter dependency graph. Using the identified change type label as input, it performs a breadth-first traversal along the dependency graph to calculate the parameter levels, functional modules, and associated interface call steps that the change may affect. This ultimately generates a structured impact domain description, including the full path identifier of the affected parameter, its associated interface module, the sequence of test steps that may be affected, and a list of other interfaces that depend on the parameter. For example, when identifying a "parameter type change" type, the impact domain analysis will locate the nesting level of the parameter in the interface request body, identify all subsequent interface calls that reference the parameter, and mark the parameter assignment statements and response parsing assertions in the script data object that need to be adjusted synchronously. By combining these rules and models, the system achieves accurate classification and comprehensive definition of the impact scope of interface changes, providing a reliable basis for accurate updates to subsequent script data objects.

[0235] For example, the system reads the differences between the current interface definition and the historical baseline interface definition recorded in the interface change information and finds two differences: one is the addition of the "Whether to allow member invitations" field, and the other is the change of the original "groupName" field name to "name". The system inputs these two differences one by one into a preset change type classifier. The classifier identifies the following based on predefined matching rules: the addition of the "Whether to allow member invitations" field belongs to the "parameter addition" type; the change of the field name from "group Name" to "name" belongs to the "parameter type change" type. The system analyzes each identified change type: for the "parameter addition" type, it is analyzed that its parameter hierarchy in the interface definition is "request parameter root level", the corresponding interface function module is "group chat management", and the interface call process that may be affected includes the "parameter assembly step". For the "parameter type change" type, it is analyzed that the parameter involved is "group". The "Name / name" parameter belongs to the same "Group Chat Management" module. The interface call process that may be affected includes the "parameter assignment step" and the "response parsing step". The system combines these analysis results to generate an impact domain, which is recorded as follows: Impact domain 1 involves the parameter "whether member invitation is allowed", the functional module is "Group Chat Management", and the impact process is "parameter assembly"; Impact domain 2 involves the parameter "group Name / name", the functional module is "Group Chat Management", and the impact process is "parameter assignment and response parsing".

[0236] The change type refers to the category to which each specific change in the interface change information belongs. It is used to identify the nature of the change in the interface definition. Common change types include parameter addition, parameter obsolescence, parameter type change, parameter constraint change, and interface call path change. For example, if an interface definition adds a request field for "whether to allow member invitations", this change type is identified as "parameter addition".

[0237] The impact domain refers to the description of the specific scope of impact of each identified change type, derived from analysis. This includes the hierarchical structure of the parameters involved in the change within the interface definition, the corresponding interface functional module, and the potentially affected interface call process steps. For example, for a change of the "parameter addition" type, the impact domain is: the parameter "whether member invitations are allowed" is located at the root level of the request parameters, belongs to the "group chat management" functional module, and the potentially affected interface call process includes the "parameter assembly step."

[0238] S30532. Based on the change type and the affected domain, determine the target fields and target logic in the script data object that are affected by the change type and the affected domain, and update the target fields and target logic to obtain the updated script data object.

[0239] Specifically, it can read the detailed information of each change recorded in the change type and the affected domain. Based on the parameter hierarchy and functional module recorded in the affected domain, it can locate the corresponding parameter rule field, interface call sequence field, or validation logic field in the script data object and identify these fields as the target fields affected by the change. Based on the subsequent call steps that the change may affect, recorded in the affected domain, it can locate the corresponding interface call sequence or associated validation statement in the script data object and identify these logics as the target logic. Then, based on the change category recorded in the change type, it can perform corresponding update operations on the located target fields and target logic: if the change type is a parameter addition, it can add a default value for the added parameter in the parameter rule field; if the change type is a parameter obsolescence, it can delete the configuration of the obsolescence parameter from the parameter rule field; if the change type is a parameter type change, it can modify the data type declaration of the parameter in the parameter rule field to the new type; if the change type is an interface call path change, it can modify the corresponding interface address in the interface call sequence field. After all update operations are completed, an updated script data object is generated. This step is used to accurately modify the corresponding parts of the script data object based on the finely identified change type and scope of impact, ensuring that the update operations precisely match the actual changes in the interface.

[0240] For example, the system reads the specific information of each change recorded in the change type and the affected domain. For the first change (parameter addition, affected domain involving the parameter "whether to allow member invitation", functional module "group chat management", affected process "parameter assembly"), the system locates the parameter configuration part of the "create group chat" interface in the parameter rule field of the script data object according to the parameter hierarchy structure and functional module recorded in the affected domain, and determines this part as the target field. According to the affected process "parameter assembly", the system locates the logic part in the script data object responsible for generating request parameters, and determines this logic as the target logic. Then, according to the change type "parameter addition", the system adds a default value "false" to the "whether to allow member invitation" parameter in the located parameter rule field. For the second change (parameter type change, involving the parameter "groupName / name", functional module "group chat management", affected process "parameter assignment, response parsing"), the system locates the original "group" in the parameter rule field of the script data object according to the affected domain information. The "Name" parameter is configured and identified as the target field. Based on the affected process "parameter assignment and response parsing", the system locates the statements in the script data object that involve assigning this parameter and the validation logic that reads this field during response parsing. These are identified as the target logic. Based on the change type "parameter type change", the system changes the "group Name" name in the parameter rule field to "name" and synchronously changes the assertion statements in the validation logic field that involve reading "group Name" to read "name". After completing all update operations, the system generates the updated script data object.

[0241] In this context, the target field refers to the specific data item in the script data object that needs to be modified accordingly for the interface change, identified based on the change type and the location of the affected domain. It typically corresponds to a parameter configuration in the parameter rule field or an interface entry in the interface call sequence field. For example, in an interface change where the "group Name" field is changed to "name", the target field located by the system in the script data object is the parameter configuration item originally named "group Name" in the parameter rule field.

[0242] Target logic refers to the code logic or processing rules identified in the script data object based on the change type and affected domain, which require corresponding adjustments for interface changes. It typically corresponds to executable logical units such as the interface call order, parameter assignment statements, or validation assertion statements. For example, for an interface change where the "group Name" field name is changed to "name", the target logic located in the script data object includes: the statement responsible for assigning the "groupName" parameter, and the validation logic that reads the "group Name" field for assertion during response parsing.

[0243] The technical effect of this solution in this embodiment is as follows: When updating the script data object according to interface change information, by identifying the change type and analyzing the impact domain of the interface change information, and using a strategy combining rule engine and machine learning model, the structured comparison results of the interface definition are accurately classified into specific change types such as parameter addition, parameter obsolescence, parameter type change, parameter constraint change, and interface call path change. Based on the interface parameter dependency graph, a breadth-first traversal is performed to locate the parameter level, functional module, and related call steps affected by the change as the impact domain. Then, based on the identified change type and impact domain, the affected parameter configuration fields, parameter assignment statements, and response parsing assertions are accurately determined in the script data object, and targeted updates are performed. By leveraging the synergistic effects of change difference extraction, type classifiers, and dependency graphs, we achieve refined identification of interface changes and accurate delimitation of their impact scope. This avoids full modification or invalid updates to script data objects, making the update process more refined, efficient, and targeted. While ensuring update accuracy, it improves script update efficiency and solves the problems of inaccurate identification of change types and impact scope, excessively large update scope or omissions, and low update efficiency and poor reliability of script data objects when updating script data objects after interface changes.

[0244] This application combines big data analytics, the natural language processing capabilities of AI large-scale models, and interface automation testing to provide an intelligent solution capable of automatically generating high-quality interface automation test scripts. The main technologies used include:

[0245] First: The semantic analysis capability of the AI ​​big model uses language similar to natural language to describe the automated script. The AI ​​big model parses the content of the automated script description and sends the parsing results to the "interface automated script generation intelligent agent".

[0246] Second: Big data mining and analysis capabilities. Extract the accumulated interface automation script assets, and transform, process, analyze, and tag information such as interface data input and output relationships, check and verification points, and test data used in interface fields from historical scripts, as a basis for generating automated test scripts in the future.

[0247] Third: The AI ​​large-scale model agent has interactive capabilities, allowing real-time interaction with testers and providing automated script generation services to meet testers' immediate needs for automated script generation.

[0248] Fourth: The architecture deeply integrates AI large-scale models, big data technology, and automated testing. The "AI Automated Script Generation Intelligent Agent" integrates AI large-scale models, big data analysis, automated testing and other technologies to generate automated test scripts for scenario-level interfaces.

[0249] In the current field of software test automation, even with basic tools or platforms for developing automated interface test scripts that don't involve code, test engineers still primarily rely on assembling the interfaces and configuring the relevant scripts to complete the development of an automated script. This approach presents the following technical problems:

[0250] Technical threshold: Testers need to master technical knowledge such as testing frameworks and interface protocols, while non-technical personnel need to make a certain learning effort.

[0251] Inefficient: The complete process from requirements analysis to script development, debugging and verification usually takes 5-8 hours.

[0252] Unstable quality: Relying on personal experience, the quality of scripts varies greatly and is prone to omissions and errors.

[0253] High maintenance costs: When the interface changes, test scripts need to be maintained manually, and script updates are not timely.

[0254] Knowledge is difficult to accumulate: personal testing experience and practice are difficult to systematically accumulate and reuse.

[0255] Low level of intelligence: Most existing tools generate code using templates, lacking true intelligent understanding and context awareness.

[0256] While there are some test script generation tools in the existing technology, most of them are based on fixed templates or simple rules, and cannot understand business semantics, learn from historical data to optimize, or achieve intelligent conversion from natural language to executable code. Most existing technologies are used to generate automation scripts for single interfaces, and cannot generate scenario-level combined interface automation scripts.

[0257] Therefore, in the AI ​​era, a solution is needed that deeply integrates AI large-scale models and big data technologies to achieve the automatic and intelligent generation of scenario-level combined interface automation scripts. Once the automation scripts are generated, testers can focus their work on test case and script design, further showcasing their value in areas that AI cannot replace. The objective of this application is to create an "AI interface automation script generation intelligent agent":

[0258] First, it is based on an interface automation script development language similar to natural language, which allows testers to easily describe interface automation scripts, and the AI ​​big model completes the parsing of the script content.

[0259] Second: "AI Interface Automation Script Generation Intelligent Agent" quickly generates high-quality interface automation scripts based on the analysis results of the AI ​​large model, improving the efficiency of script development and maintenance.

[0260] Third: The "AI Interface Automation Script Generation Intelligent Agent" proactively maintains test data and other information of the interface automation script in the background, and promptly notifies testers to maintain and change interfaces, reducing the difficulty of script maintenance.

[0261] Fourth: Interface automation scripts can be converted into corresponding descriptive content, making it easy to quickly generate new scripts through modifications.

[0262] Fifth: Testers can summon the "AI Interface Automated Script Generation Intelligent Agent" front-end robot at any time to perform personalized development and maintenance of the current script.

[0263] Based on the testers' script development requirements, we proactively generate interface automation scripts for them. The main implementation idea is as follows:

[0264] Step 1: Introduce big data-related technologies to analyze historical interface automation test scripts. These scripts will serve as the basis for the "AI Interface Automation Script Generation Agent" to generate new scripts. The input and output data, verification points, and inter-interface relationships of the historical interface automation scripts will be the main references for the newly generated scripts.

[0265] The second step is to define a description language for interface automation scripts. This description language is similar to natural language and is used to describe the design information of the interface automation scripts. The AI ​​big data model can parse this language and pass the parsing results to the "AI Interface Automation Script Generation Agent". After processing, the "AI Interface Automation Script Generation Agent" generates interface automation scripts based on the big data analysis results from the first step (similar to the natural language of current user interface automation development scripts, but with more relaxed syntax requirements, making it easier to describe automation script development needs).

[0266] This application also provides an AI-based interface automation test script generation system. The system adopts a layered architecture and mainly includes four modules: an interface automation script description language module, an AI large model script description and parsing module, an AI interface automation script generation intelligent agent, and a big data intelligent analysis module.

[0267] Interface Automation Script Description Language Module: With the help of a custom language, the characteristics of interface automation scripts are described in a more standardized form, making it easier for large AI models to obtain the generation elements of interface automation scripts after parsing.

[0268] The AI ​​large-scale model script description parsing module parses the automated cases or script description information written by testers using the Interface Automation Script Description Language (IAMS), generates the main data structure object of the interface automation script, and passes this data structure object to the "AI Interface Automation Script Generation Agent," which can then generate interface automation scripts based on its content. Conversely, the "AI Interface Automation Script Generation Agent" can generate the main data structure object of the corresponding script based on the interface automation script, and the AI ​​large-scale model can then generate automated cases or script description information based on the interface automation script description language using this data structure object.

[0269] The AI ​​Interface Automation Script Generation Agent has five main functions: First, it generates automation scripts based on the main data structure objects of the interface automation scripts (the data used by the automation scripts is handled by the data preparation module, which is already available). After generation, it is associated with automation cases or script description information. Second, it checks and automatically maintains the automation scripts daily in the background and notifies the testers of the maintenance status (testers can manually maintain scripts that cannot be maintained). Third, it maintains the script test data regularly in the background, handling the preparation and maintenance of the test script data (the data preparation and maintenance work is handled by the data preparation module, which is already available), for example, maintaining the automation test script data every 3 months. Fourth, the front-end robot of the AI ​​Interface Automation Script Generation Agent can interact with the testers in real time, responding to the testers' needs for test script development and maintenance at any time. Fifth, it has learning capabilities and uses the big data intelligent analysis module to collect the data structure objects used in newly developed scripts as assets for big data analysis, serving as a data source for generating automation scripts.

[0270] The big data intelligent analysis module has two main functions: First, it uses big data technology to analyze historical automated scripts, serving as the basis for generating scripts in the "AI interface automated script generation intelligent agent" module. Second, it uses big data technology to analyze the development and execution of historical automated scripts, serving as the basis for the data preparation module to prepare automated script data.

[0271] The purpose of this application is to provide a system and method capable of understanding natural language descriptions, intelligently learning from historical script data, and automatically generating high-quality interface automation scripts, thereby solving the problems of low efficiency, high error rate, and lack of intelligence in existing manually developed scripts. To achieve the above objective, this application may adopt the following technical solutions:

[0272] Natural Language Interaction: By defining an Interface Description Language (IDL) that closely resembles natural language and leveraging large model capabilities, the barrier to entry for script generation is lowered, allowing testers to focus more on test logic rather than coding details.

[0273] Data-driven generation: By introducing big data technology, we analyze and mine massive amounts of historical test scripts to extract effective test patterns, data correlations, and verification points, making the generation of new scripts based on data.

[0274] Proactive Operation and Maintenance by Intelligent Agents: Building an AI agent with the capabilities of script generation, automatic maintenance, data preparation, real-time interaction, and learning, transforming passive response into proactive service.

[0275] Closed-loop learning evolution: Establish a complete closed loop from script generation, execution, feedback to knowledge accumulation, enabling the system to continuously optimize itself during operation.

[0276] Figure 4 The flowchart for the automated generation and iteration closed-loop process of interface test scripts provided in this application embodiment fully depicts the entire process from test requirement input to script generation, execution feedback, and knowledge accumulation: test requirements are first converted into IDL description language, parsed into script data structure objects by AI big model, processed by AI agent and input into script generation engine to generate executable scripts and provide feedback. The execution results are then accumulated into patterns and knowledge bases after big data analysis, and finally flow back to the AI ​​agent processing stage to form a continuously optimized automated test closed loop, clearly demonstrating the overall architecture and data flow logic of the system from requirements to implementation and self-learning.

[0277] Figure 5The layered architecture diagram of the interface automation script generation system provided in this application embodiment clearly illustrates the four-layer architecture design of the system and the interaction logic between modules: the system is divided into a user interaction layer, a core processing layer, an external integration layer, a data storage layer, and a data intelligence layer. Users input their requirements through the front-end interactive interface via an AI front-end robot or a description language editor. The requirements are transmitted to the AI ​​large model script description and parsing module and the AI ​​script generation agent in the core processing layer. At the same time, it can link with the external AI large model and data preparation module in the external integration layer. The generated scripts and assets are stored in the script and asset library in the data storage layer. Finally, the big data intelligent analysis module in the data intelligence layer completes the data processing and flows back to the core processing layer, realizing the complete process from requirement input to script generation, asset storage, and intelligent iteration. It intuitively presents the modular division of labor and data flow relationship of the system.

[0278] The Interface Automation Script Description Language module defines an abstract description language for interface automation that adopts a natural language style, structured templates, and is extensible. It allows testers to describe test scenarios, steps, and expected results in a manner close to Chinese expression habits. Its design goal is to act as a bridge connecting tester intent and AI generation capabilities. Through declarative syntax, structured expression, and extensible design, it enables testers to accurately describe test requirements without requiring specialized programming skills. This module provides a syntax standard manual and validation tools to ensure description standardization, supports automatic import of some information to reduce manual input, and assists in generating IDL descriptions through a visual editing interface. Ultimately, it provides standardized input for the analysis of large AI models, thereby lowering the barrier to entry.

[0279] The AI ​​large-scale model script description parsing module utilizes advanced AI large-scale models to achieve bidirectional parsing and conversion between interface automation script description languages ​​and script structures. It can parse natural language descriptions into structured script elements containing interface endpoints, parameters, assertions, and other elements, and conversely, it can generate corresponding description documents from existing scripts. Its design goal is to achieve high-precision bidirectional conversion between IDL descriptions and standardized script data structure objects. The core idea is to use the powerful understanding capabilities of large language models to accurately parse non-standard or semi-structured descriptions into structured data objects, while also having the ability to reverse translate code or data structure objects back into standard IDL descriptions. Technical innovations include achieving accurate mapping from natural language to script structures, supporting bidirectional parsing for easy script understanding and maintenance, and providing context-aware parsing results by combining big data analysis.

[0280] Figure 6The flowchart of the bidirectional conversion architecture of the AI ​​large model script description parsing module provided in this application embodiment illustrates the core processing path of the AI ​​large model in the script description parsing module. The left side of the diagram represents the forward parsing pipeline: natural language or IDL descriptions are parsed by the AI ​​large model and transformed into script data structure objects, then output as executable scripts through the script generation pipeline. The right side represents the reverse parsing pipeline: the executable scripts are reconstructed by the AI ​​large model and restored to standardized IDL descriptions, forming a complete bidirectional conversion closed loop. This demonstrates the system's bidirectional capability to both convert human-readable descriptions into machine-executable scripts and reverse-generate standardized documents from existing scripts. This module, by combining prompting engineering and domain knowledge bases, guides the large model to accurately extract key information such as interface addresses, parameters, assertion logic, and dependencies from natural language or IDL descriptions, generating standard script data structure objects (Script Data Objects). These objects serve as the carrier for internal system exchange, containing all necessary information such as test scenarios, interface sequences, data flows, and assertion rules. Simultaneously, the module possesses bidirectional conversion capabilities, supporting both forward generation of automated scripts from natural language or IDL and reverse parsing of existing scripts to generate standardized IDL descriptions.

[0281] The AI-powered automated script generation agent serves as the core of the system. Drawing inspiration from modern AI Agent architecture, it divides the entire script lifecycle management into five closely collaborative sub-modules: the script generation engine, based on Script DataObject, calls the data preparation module to generate executable scripts that conform to best practices; the automatic maintenance engine checks the script health status daily and attempts to automatically repair problems caused by interface changes or environmental fluctuations; the data maintenance engine periodically coordinates with the data preparation module to update test data, ensuring data validity and freshness, and supporting data-driven testing; the front-end interactive robot provides a natural language interface, responding in real time to the script development and maintenance needs of testers; and the self-learning engine collects the Script Data Object, execution results, and modification records of new scripts as assets, using big data analysis to discover high-frequency and efficient script patterns to optimize subsequent generation strategies, thus undertaking all intelligent tasks of script generation, maintenance, interaction, and learning.

[0282] Figure 7The five-in-one intelligent agent architecture diagram for the AI ​​interface automated script generation intelligent agent provided in this application embodiment illustrates the collaborative relationship and data flow path of the five core sub-modules within the intelligent agent. The script data structure object in the diagram serves as input, flowing to the script generator (outputting generated scripts), the automatic maintenance engine (outputting daily automatic maintenance and reports), the data maintenance engine (performing periodic data maintenance and outputting update reports), and the front-end interactive robot (providing real-time interaction and instant response). Simultaneously, the execution results of all sub-modules flow to the self-learning engine through asset accumulation, achieving knowledge enhancement and forming a complete closed loop from script generation, maintenance, interaction to learning.

[0283] The Big Data Intelligent Analysis module utilizes big data technology to perform multi-dimensional mining and analysis of historical automated scripts, providing data insights and decision support for script generation and data analysis. In historical script analysis, this module provides a basis for intelligently generating test data by analyzing the type, value range, and correlation of interface parameters. It also mines common interface call sequences and business scenario patterns as references for scripts in multi-interface combination scenarios, and calculates effective assertion methods and verification points to improve assertion accuracy. In development and execution analysis, the module analyzes the success rate, failure reasons, and performance bottlenecks of script execution to identify unstable scripts and interfaces. Simultaneously, it determines the frequency of script maintenance and modification points to discover system vulnerabilities and guide testing focus. Ultimately, it transforms historical experience into quantifiable knowledge and patterns, providing intelligent recommendations for script generation.

[0284] Figure 8 The system architecture diagram of the big data intelligent analysis module provided in this application embodiment illustrates the data processing flow from the historical script library to the final application service. Data in the diagram starts from the historical script library, passes through the data acquisition layer, and enters the data processing layer, where data cleaning, feature extraction, and relationship mining are performed sequentially. The processed data flows into the intelligent analysis layer for pattern mining, quality analysis, and trend prediction. Finally, at the application service layer, the analysis results are transformed into specific services such as script pattern recommendation, data strategy optimization, and quality evaluation, which are then output to the AI ​​script generation agent, the data preparation module, and the test personnel dashboard, forming a full-link support architecture from data acquisition to intelligent application.

[0285] Compared to existing technologies, this application defines a standardized interface automation script description language, transforming testers' natural language requirements into machine-parsable structured descriptions. Leveraging a large AI model, it accurately parses these requirements into script data structure objects, and an AI agent automatically generates high-quality scripts, reducing script development time from hours to minutes, thus improving efficiency. Simultaneously, based on big data analysis, it mines best practices and patterns from historical scripts to provide intelligent recommendations for script generation, effectively ensuring script quality and stability. The natural language interaction lowers the barrier to entry for non-professional testers, enabling more team members to participate in test development. All generated scripts and their execution data are consolidated into a reusable test asset library, promoting team knowledge accumulation and inheritance. The system also possesses continuous learning capabilities, constantly optimizing generation effects and achieving adaptive evolution.

[0286] Figure 9 This is a schematic diagram of the structure of the interface test script generation device provided in the embodiments of this application. Figure 9 As shown, the device for generating the interface test script includes:

[0287] The first acquisition module 901 is used to acquire interface test requirements and convert them into IDL descriptions that conform to the preset IDL syntax specifications; wherein, the interface test requirements are used to represent the test content of the interface to be tested by the testers.

[0288] Extraction module 902 is used to extract information from the IDL description to obtain script data objects. The script data objects are data structures extracted from the IDL description, including interface call sequences, parameter rules, and validation logic. The script data objects are used to represent structured information of interface testing requirements.

[0289] The generation module 903 is used to generate interface test scripts required for interface testing based on the script data object. The interface test scripts are used to execute interface calls and result verification in a preset test framework to test the interface to be tested.

[0290] In one possible design, the first acquisition module 901 includes:

[0291] The first acquisition unit is used to acquire the initial natural language requirements input by the testers and calculate the intent confidence of the initial natural language requirements.

[0292] The first determining unit is used to determine the initial natural language requirement as the interface test requirement when the intent confidence is greater than or equal to a preset confidence threshold; wherein, the interface test requirement includes a natural language description of the test scenario, the interface call order and the verification rules.

[0293] The second acquisition unit is used to acquire the missing semantic slots of the initial natural language requirement when the confidence of the intent is less than the preset confidence threshold, and to generate a reverse lookup question based on the missing semantic slots.

[0294] The completion unit is used to obtain feedback information from testers regarding reverse query questions, and to semantically complete the initial natural language requirements based on the feedback information to obtain the interface test requirements.

[0295] In one possible design, the first acquisition module 901 includes:

[0296] The feature extraction unit is used to extract features from the interface test requirements to obtain an initial structured representation; where the initial structured representation refers to the intermediate data initially extracted from the interface test requirements and organized in a structured form.

[0297] The input unit is used to input the initial structured representation into the preset transformation model to obtain the initial IDL description and the reverse verification data corresponding to the initial structured representation that conform to the preset IDL syntax specification.

[0298] The transformation unit is used to convert the initial IDL description into verification text based on the reverse verification data, and to calculate the semantic similarity between the verification text and the initial structured representation.

[0299] The second determining unit is used to confirm the initial IDL description as an IDL description when the semantic similarity is greater than a preset similarity threshold.

[0300] In one possible design, the extraction module 902 includes:

[0301] The third acquisition unit is used to acquire multiple historical scripts and classify them to obtain positive and negative datasets. Among them, multiple historical scripts refer to the set of scripts generated by executing historical test tasks on the interface to be tested within a preset first time period. The deadline of the first time period is earlier than the current time.

[0302] The first generation unit is used to generate positive constraints based on the positive dataset and negative constraints based on the negative dataset; wherein, the positive dataset refers to the set of scripts that have been successfully tested from multiple historical scripts, and the negative dataset refers to the set of scripts that have failed to be tested from multiple historical scripts.

[0303] The information extraction unit is used to extract information from the IDL description based on positive and negative constraints to obtain script data objects. Positive constraints are used to limit the interface parameter relationships and validation rules that should be included in the script data objects, while negative constraints are used to limit the interface call patterns and parameter configuration methods that should be avoided in the script data objects.

[0304] In one possible design, the interface test script generation device also includes:

[0305] The second acquisition module is used to acquire interface change information of the interface to be tested in response to the current time reaching the preset detection time. The interface change information is used to represent the interface definition of the interface to be tested acquired at the preset detection time, and the difference between the interface definition and the historical baseline interface definition. The historical baseline interface definition is the interface definition of the interface to be tested acquired in the previous detection before the preset detection time.

[0306] The update module is used to update the script data object according to the interface change information, obtain the updated script data object, and generate the updated interface test script based on the updated script data object.

[0307] In one possible design, the update module includes:

[0308] The fourth acquisition unit is used to acquire multiple historical interaction records and current environment variables. The multiple historical interaction records are used to represent the historical behavior patterns and calling rules of the interface to be tested, and the current environment variables are used to represent the environmental characteristics when testing the interface to be tested.

[0309] The optimization unit is used to optimize the preset generation logic of the script data object based on multiple historical interaction records and current environment variables, so as to obtain the optimized generation logic.

[0310] The update unit is used to update the script data object based on the optimized generation logic and the interface change information to obtain the updated script data object.

[0311] In one possible design, the update unit includes:

[0312] The analysis component is used to identify the change type and analyze the impact domain of interface change information to obtain the change type and impact domain; among which, the change type includes parameter addition, parameter obsolescence, parameter type change, parameter constraint change and interface call path change.

[0313] The update component is used to determine the target fields and target logic in the script data object that are affected by the change type and the affected domain, based on the change type and the affected domain, and update the target fields and target logic to obtain the updated script data object.

[0314] In one possible design, generation module 903 includes:

[0315] The parsing unit is used to parse the script data object to obtain the interface call sequence contained in the script data object and the dependency relationships between multiple preset interfaces.

[0316] The simulation unit is used to perform concurrent execution path simulation on the interface call sequence based on dependency relationships in order to identify potential failure scenarios under preset concurrency pressure.

[0317] The second generation unit is used to generate at least one compensating test case based on potential failure scenarios; wherein the compensating test case includes verification logic for verifying the interface under test in potential failure scenarios.

[0318] The fusion unit is used to merge compensatory test cases and basic test scripts generated based on script data objects, so that when the interface test script is executed in the preset test framework, it performs functional verification of the interface to be tested and simulates concurrent conflicts to trigger potential failure scenarios, thus obtaining the interface test script.

[0319] The interface test script generation device provided in this embodiment can execute... Figure 2 and Figure 3 The technical solution of the embodiment of the interface test script generation method shown herein, its implementation principle and technical effect are similar to Figure 2 and Figure 3 The method for generating interface test scripts shown is similar to the one illustrated in the example, and will not be described in detail here.

[0320] Figure 10 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application. Figure 10 As shown, the electronic device 100 includes at least one processor 1001 and a memory 1002. The electronic device 100 also includes a communication component 1003. The processor 1001, the memory 1002, and the communication component 1003 are connected via a bus 1004.

[0321] In a specific implementation, at least one processor 1001 executes computer execution instructions stored in memory 1002, causing at least one processor 1001 to implement a method for generating an interface test script according to the above embodiment.

[0322] The specific implementation process of processor 1001 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0323] In the above embodiments, it should be understood that the processor 1001 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0324] The memory 1002 may include high-speed RAM memory, and may also include non-volatile memory (NVM), such as at least one disk storage.

[0325] Bus 1004 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Bus 1004 can be divided into address bus, data bus, control bus, etc. For ease of illustration, bus 1004 in the accompanying drawings of this application is not limited to only one bus or one type of bus.

[0326] The above description of the functions implemented by electronic devices and main control devices has introduced the solutions provided by the embodiments of the present invention. It is understood that, in order to implement the above functions, the electronic device or main control device includes hardware structures and / or software modules corresponding to the execution of each function. By combining the units and algorithm steps of the various examples described in the embodiments of the present invention, the embodiments of the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the technical solutions of the embodiments of the present invention.

[0327] This application also provides a computer-readable storage medium storing computer-executable instructions. When executed by a processor, these instructions are used to implement a method for generating an interface test script as described in the above embodiments. In the specific implementation of the aforementioned method for generating an interface test script, each module can be implemented as a processor.

[0328] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0329] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in application-specific integrated circuits (ASICs). Alternatively, the processor and the readable storage medium can exist as discrete components in an electronic device or a host device.

[0330] This application also provides a computer program product, including a computer program, which, when executed by a processor, is used to implement a method for generating an interface test script as described in the above embodiments.

[0331] The computer program is stored in a readable storage medium, and at least one processor can read the computer program from the readable storage medium and execute the computer program to perform the scheme provided in any of the above embodiments.

[0332] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disk, or optical disk.

[0333] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it is readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. The above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for generating interface test scripts, characterized in that, include: Obtain the interface testing requirements and convert them into an IDL description that conforms to the preset IDL syntax specification; wherein, the interface testing requirements are used to represent the test content of the interface to be tested by the testers; Information is extracted from the IDL description to obtain a script data object; wherein, the script data object is a data structure extracted from the IDL description, including interface call sequence, parameter rules and verification logic, and the script data object is used to represent the structured information of the interface testing requirements; The interface test script required for the interface test is generated based on the script data object; wherein, the interface test script is used to execute interface calls and result verification in a preset test framework to test the interface to be tested.

2. The method for generating interface test scripts according to claim 1, characterized in that, The requirements for obtaining the interface test include: Obtain the initial natural language requirements input by the testers, and calculate the intent confidence of the initial natural language requirements; When the confidence level of the intent is greater than or equal to a preset confidence threshold, the initial natural language requirement is determined as the interface test requirement; wherein, the interface test requirement includes a natural language description of the test scenario, interface call order, and verification rules; When the confidence level of the intent is less than the preset confidence threshold, the missing semantic slots of the initial natural language requirement are obtained, and a reverse lookup question is generated based on the missing semantic slots. Obtain feedback information from testers regarding the reverse query, and semantically complete the initial natural language requirements based on the feedback information to obtain the interface test requirements.

3. The method for generating interface test scripts according to claim 1, characterized in that, The step of converting the interface testing requirements into an IDL description that conforms to a preset IDL syntax specification includes: Feature extraction is performed on the interface testing requirements to obtain an initial structured representation; wherein, the initial structured representation refers to intermediate data initially extracted from the interface testing requirements and organized in a structured form; The initial structured representation is input into a preset transformation model to obtain an initial IDL description that conforms to the preset IDL syntax specification and reverse verification data corresponding to the initial structured representation; Based on the reverse verification data, the initial IDL description is converted into verification text, and the semantic similarity between the verification text and the initial structured representation is calculated. When the semantic similarity is greater than a preset similarity threshold, the initial IDL description is confirmed as the IDL description.

4. The method for generating interface test scripts according to claim 1, characterized in that, The step of extracting information from the IDL description to obtain a script data object includes: Multiple historical scripts are obtained and classified to obtain positive and negative datasets; wherein, the multiple historical scripts refer to the set of scripts generated by executing historical test tasks on the interface to be tested within a preset first time period, and the end time of the first time period is earlier than the current time. Positive constraints are generated based on the positive dataset, and negative constraints are generated based on the negative dataset; wherein, the positive dataset refers to the set of scripts that were successfully tested from the plurality of historical scripts, and the negative dataset refers to the set of scripts that failed to test from the plurality of historical scripts; Based on the positive and negative constraints, information is extracted from the IDL description to obtain the script data object; wherein, the positive constraints are used to limit the interface parameter associations and validation rules that should be included in the script data object, and the negative constraints are used to limit the interface call patterns and parameter configuration methods that should be avoided in the script data object.

5. The method for generating interface test scripts according to claim 1, characterized in that, After generating the interface test script required for the interface test based on the script data object, the process further includes: In response to the current time reaching a preset detection time, the interface change information of the interface to be tested is obtained; wherein, the interface change information is used to represent the interface definition of the interface to be tested obtained at the preset detection time, and the difference between the interface definition and the historical baseline interface definition, wherein the historical baseline interface definition is the interface definition of the interface to be tested obtained at the previous detection time of the preset detection time. The script data object is updated according to the interface change information to obtain the updated script data object, and an updated interface test script is generated based on the updated script data object.

6. The method for generating interface test scripts according to claim 5, characterized in that, The step of updating the script data object according to the interface change information to obtain the updated script data object includes: Acquire multiple historical interaction records and current environment variables; wherein, the multiple historical interaction records are used to represent the historical behavior patterns and calling rules of the interface to be tested, and the current environment variables are used to represent the environmental characteristics when testing the interface to be tested; Based on the multiple historical interaction records and the current environment variables, the preset generation logic of the script data object is optimized to obtain the optimized generation logic; Based on the optimized generation logic, the script data object is updated according to the interface change information to obtain the updated script data object.

7. The method for generating interface test scripts according to claim 6, characterized in that, The step of updating the script data object according to the interface change information to obtain the updated script data object includes: The interface change information is analyzed for change type identification and change impact domain to obtain change type and impact domain; wherein, the change type includes parameter addition, parameter obsolescence, parameter type change, parameter constraint change and interface call path change; Based on the change type and the influence domain, the target fields and target logic in the script data object that are affected by the change type and the influence domain are determined, and the target fields and target logic are updated to obtain the updated script data object.

8. The method for generating interface test scripts according to claim 1, characterized in that, The step of generating the interface test script required for the interface test based on the script data object includes: The script data object is parsed to obtain the interface call sequence contained in the script data object and the dependency relationships between multiple preset interfaces; Based on the aforementioned dependencies, the concurrent execution path of the interface call sequence is deduced to identify potential failure scenarios under preset concurrency pressure. At least one compensatory test case is generated based on the potential failure scenario; wherein, the compensatory test case includes verification logic for verifying the interface under test under the potential failure scenario; The compensatory test cases and the basic test script generated based on the script data object are integrated so that when the interface test script is executed in the preset test framework, it performs functional verification of the interface to be tested and simulates concurrent conflicts to trigger the potential failure scenario, thus obtaining the interface test script.

9. An apparatus for generating interface test scripts, characterized in that, include: The first acquisition module is used to acquire interface testing requirements and convert the interface testing requirements into an IDL description that conforms to a preset IDL syntax specification; wherein, the interface testing requirements are used to represent the test content of the interface to be tested by the testers; An extraction module is used to extract information from the IDL description to obtain a script data object; wherein, the script data object is a data structure extracted from the IDL description, including interface call sequence, parameter rules and verification logic, and the script data object is used to represent the structured information of the interface testing requirements; The generation module is used to generate the interface test script required by the interface test requirements based on the script data object; wherein, the interface test script is used to execute interface calls and result verification in a preset test framework to test the interface to be tested.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; When the processor executes the computer execution instructions stored in the memory, it is used to implement the method for generating interface test scripts as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method for generating interface test scripts as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, It includes a computer program, which, when executed by a processor, is used to implement the method for generating interface test scripts as described in any one of claims 1 to 8.

Images