Automatic interface testing method and device and automatic interface testing system

Abstract

The invention provides an automatic interface testing method and device and an automatic interface testing system, and the method comprises the steps: obtaining all interface request sequences of a target business process, the interface request sequences comprising a request path, a request header, a request body, a response header and a response body; analyzing the source of a request field in each interface request sequence by adopting a large language model, wherein the source of the request field comprises custom input, database calling and precursor interface introduction; determining a request field with adjustable parameters and a source of custom input and a request field with adjustable parameters and a source of database calling as target request fields, and constructing a test script according to the target request fields, the test script being used for replacing parameter values of the target request fields; and generating a plurality of test requests according to the test script, and testing the target business process by adopting the plurality of test requests. The method solves the problem that in the prior art, the efficiency of writing the request parameters of the test request is low.

Description

Technical Field

[0001] The present invention relates to the field of automated testing, and more particularly, to an interface automated testing method, apparatus, computer-readable storage medium, and automated testing system. Background Art

[0002] With the rapid development of the software development and testing fields, especially the rise of the microservices architecture and the API economy, interface testing has become a key link in ensuring the quality of software systems. Traditional interface testing methods mainly rely on manually writing test scripts. This method is not only time-consuming and laborious, but also in scenarios of combined multiple interfaces, such as the business process testing after a login operation, testers need to understand and write the request sequences of each involved interface one by one, including the request path, request headers, request body, response headers, and response body, which greatly increases the difficulty of writing automated test scripts and the labor cost.

[0003] In scenarios of combined multiple interfaces, there are often complex dependency relationships in the interface request sequences. For example, the response data of one interface may be used as the parameter of a subsequent interface request. Manually handling such dependency relationships is error-prone, and the reusability and maintainability of the scripts are poor. In addition, testers usually need to judge based on experience which fields are suitable for parameterization to improve the comprehensiveness and flexibility of testing, but this manual judgment process is highly subjective and it is difficult to ensure the accuracy and automation level of the scripts. Summary of the Invention

[0004] The main purpose of this application is to provide an interface automated testing method, apparatus, computer-readable storage medium, and automated testing system, so as to at least solve the problem of low efficiency in writing the request parameters of test requests in the prior art. <**********

[0005] To achieve the above object, according to one aspect of this application, an interface automated testing method is provided, including: obtaining all interface request sequences of a target business process, where the interface request sequences include a request path, request headers, a request body, response headers, and a response body; using a large language model to analyze the sources of request fields in each of the interface request sequences, where the request fields are the fields carrying request parameters in the request path, the request headers, and the request body, and the sources of the request fields include custom input, database calls, and incoming from a predecessor interface; determining the request fields with adjustable parameters and a source of the custom input and the request fields with adjustable parameters and a source of the database calls as target request fields, and constructing a test script according to the target request fields, where the test script is used to replace the parameter values of the target request fields; generating multiple test requests according to the test script, and using the multiple test requests to test the target business process.

[0006] Optionally, determining the request fields with adjustable parameters and from the custom input and the request fields with adjustable parameters and from the database call as target request fields includes: determining the request fields from the custom input and the request fields from the database call as common request fields; forming a first preset prompt word with at least one request field with adjustable parameters and at least one request field with non-adjustable parameters; inputting the first preset prompt word and the common request fields into the large language model to obtain whether the common request fields are adjustable; and using the adjustable common request fields as the target request fields.

[0007] Optionally, using a large language model to analyze the sources of the request fields in each interface request sequence includes: forming a second preset prompt word with the request fields from multiple different sources; and training the large language model according to the second preset prompt word and the request fields in each interface request sequence to obtain the sources of the request fields in each interface request sequence.

[0008] Optionally, the method further includes: when the source of the request field is from the predecessor interface, determining the target predecessor interface, and determining the interface from which the source of the request field in the predecessor interface corresponding to the current interface is obtained from the custom input or the database call as the target predecessor interface, where the predecessor interface is the interface that directly or indirectly passes the request field to the current interface; and determining the request fields of the target predecessor interface as the common request fields.

[0009] Optionally, generating multiple test requests according to the test script includes: in each interface request sequence corresponding to the target request field, adjusting the parameter values of the target request field to obtain multiple preliminary request sequences; adding assertion request fields to each preliminary request sequence to obtain target request sequences, where the assertion request field is a field for verifying whether the expected result of the test request response is consistent with the actual result; and using the target request sequences as the test requests.

[0010] Optionally, testing the target business process using multiple of the test requests includes: when the parameter returned in the assertion request field of the test request indicates that the test request has been successfully processed and the returned data meets the expectations, determining that the current test request is a valid request; when the parameter returned in the assertion request field of the test request indicates that the test request has not been successfully processed or the returned data does not meet the expectations, determining that the current test request is an invalid request; when the test request is a valid request, recording the parameter values of each request field in the valid request; when the test request is an invalid request, determining the cause of invalidity, where the cause of invalidity includes interface logic errors, data processing exceptions, and network exceptions.

[0011] Optionally, obtaining all interface request sequences of the target business process includes: when executing the target business process, using a recording tool to record all the interface request sequences triggered during the execution of the target business process.

[0012] To achieve the above object, according to one aspect of the present application, there is provided an interface automation testing device, including: an obtaining unit, configured to obtain all interface request sequences of a target business process, where the interface request sequences include a request path, a request header, a request body, a response header, and a response body; an analysis unit, configured to analyze the sources of request fields in each of the interface request sequences using a large language model, where the request fields are the fields carrying request parameters in the request path, the request header, and the request body, and the sources of the request fields include custom input, database calls, and incoming fields from predecessor interfaces; a determination unit, configured to determine the request fields with adjustable parameters and a source of custom input and the request fields with adjustable parameters and a source of database calls as target request fields, and construct a test script based on the target request fields, where the test script is used to replace the parameter values of the target request fields; a construction unit, configured to generate multiple test requests based on the test script, and test the target business process using the multiple test requests.

[0013] According to another aspect of the present application, there is provided a computer-readable storage medium, where the computer-readable storage medium includes a stored program, and where, when the program runs, it controls any one of the methods in the device where the computer-readable storage medium is located.

[0014] According to yet another aspect of the present application, there is provided an interface automation testing system, including: one or more processors, a memory, and one or more programs, where the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs include those for executing any one of the methods.

[0015] Applying the technical solution of the present application, in the above-mentioned interface automation testing method, it includes: obtaining all interface request sequences of the target business process, where the above-mentioned interface request sequences include request paths, request headers, request bodies, response headers, and response bodies; using a large language model to analyze the sources of request fields in each of the above-mentioned interface request sequences, where the above-mentioned request fields are fields carrying request parameters in the above-mentioned request paths, the above-mentioned request headers, and the above-mentioned request bodies, and the sources of the above-mentioned request fields include custom input, database calls, and incoming fields from predecessor interfaces; determining the above-mentioned request fields with adjustable parameters and a source of the above-mentioned custom input and the above-mentioned request fields with adjustable parameters and a source of the above-mentioned database call as target request fields, and constructing a test script based on the above-mentioned target request fields, where the above-mentioned test script is used to replace the parameter values of the above-mentioned target request fields; generating multiple test requests according to the above-mentioned test script, and using the multiple above-mentioned test requests to test the above-mentioned target business process. The present application obtains all interface request sequences of the target business process, uses a large language model to analyze the sources of all request fields, determines the fields of database calls with adjustable parameters and the fields with adjustable parameters and a source of custom input as target request fields, and constructs a test script based on the target request fields, so that the test script replaces the parameter values of the target request fields to obtain multiple test requests for testing the target business process. Since the ultimate sources of the request fields are custom input or database calls, even if some request fields are from predecessor interfaces, their ultimate sources are still custom input or database calls. Therefore, only the target request fields determined by custom input and database calls need to be parameterized to fully cover and effectively test the entire target business process, avoiding the complex parameter writing process and solving the problem of low efficiency in writing request parameters for test requests in the prior art. Description of the Drawings

[0016] Figure 1 Shows a hardware structure block diagram of a mobile terminal for implementing an interface automation testing method provided in an embodiment of the present application;

[0017] Figure 2 Shows a flowchart of an interface automation testing method provided in an embodiment of the present application;

[0018] Figure 3 Shows a script generation diagram of an interface automation testing method provided in an embodiment of the present application;

[0019] Figure 4 Shows a structure block diagram of an interface automation testing device provided in an embodiment of the present application.

[0020] Among them, the above-mentioned drawings include the following reference numerals:

[0021] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device. Detailed implementation manners

[0022] It should be noted that, without conflict, the embodiments in the present application and the features in the embodiments may be combined with each other. The present application will be described in detail below with reference to the drawings and in conjunction with the embodiments.

[0023] In order to enable those skilled in the art to better understand the solution of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts shall fall within the protection scope of the present application.

[0024] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily need to be used to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances so as to describe the embodiments of the present application here. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0025] As introduced in the background art, in the prior art, it mainly relies on manually writing test scripts. This method not only takes time and effort, but also in the scenario of multi-interface combination, testers need to understand and write the request sequence of each involved interface one by one. To solve this technical problem, the embodiments of the present application provide an interface automation testing method.

[0026] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0027] The method embodiments provided in the embodiments of the present application can be executed on a mobile terminal, a computer terminal or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 is the hardware structure block diagram of a mobile terminal of an interface automation testing method according to an embodiment of the present invention. As Figure 1 shown, the mobile terminal may include one or more ( Figure 1Only one processor 102 is shown (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA), and a memory 104 for storing data. Among them, the above mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those of ordinary skill in the art can understand that Figure 1 The structure shown is only schematic and does not limit the structure of the above mobile terminal. For example, the mobile terminal may further include more or fewer components than Figure 1 shown in the figure, or have a different configuration from Figure 1 shown in the figure.

[0028] The memory 104 can be used to store computer programs. For example, software programs and modules of application software, such as the computer program corresponding to an interface automation test method in an embodiment of the present invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implements the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memories. In some instances, the memory 104 may further include a memory remotely set relative to the processor 102, and these remote memories can be connected to the mobile terminal through a network. Examples of the above network include, but are not limited to, the Internet, an enterprise intranet, a local area network, a mobile communication network, and their combinations. The transmission device 106 is used to receive or send data via a network. Specific examples of the above network may include a wireless network provided by a communication provider of the mobile terminal. In one instance, the transmission device 106 includes a network adapter (Network Interface Controller, abbreviated as NIC), which can be connected to other network devices through a base station and thus communicate with the Internet. In one instance, the transmission device 106 may be a radio frequency (Radio Frequency, abbreviated as RF) module, which is used to communicate with the Internet wirelessly.

[0029] In this embodiment, an interface automation test method running on a mobile terminal, a computer terminal, or a similar computing device is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order from here.

[0030] Figure 2 is a flowchart of an interface automation test method according to an embodiment of the present application. As Figure 2 shown, the method includes the following steps:

[0031] Step S201, obtain all interface request sequences of the target business process. The above interface request sequences include request paths, request headers, request bodies, response headers, and response bodies;

[0032] Specifically, all interface request sequences covered under the target business process can be captured through a page recording tool. That is, when executing multiple business processes, multiple requests will be triggered. By recording this process, detailed records of each interface call can be comprehensively collected, including request paths, request headers, request bodies, and corresponding response headers and response bodies. Through this comprehensive process of obtaining interface request sequences, this application can construct a complete and clear set of interface request sequences, providing a data basis for the subsequent generation of test scripts.

[0033] In a specific embodiment, taking the three steps of logging in, creating a certain document, and viewing the details of the document as an example, the interface request sequence for each step can be obtained through a recording tool. Only the key content of each interface request sequence is listed, and the non-key content is not listed, as shown in Table 1.

[0034] Table 1

[0035]

[0036] Step S202, use a large language model to analyze the sources of request fields in each of the above interface request sequences. The above request fields are the fields carrying request parameters in the above request paths, the above request headers, and the above request bodies. The sources of the above request fields include custom input, database calls, and incoming values from predecessor interfaces;

[0037] Specifically, use a large language model as the core technical means to analyze the sources of each request field in the interface request sequence, and analyze the sources of all request fields carrying request parameters in each interface request sequence, such as parameter values input externally through customization, return values of the previous interface, request parameter values of the previous interface, or values obtained through database calls. The values obtained through database calls also include values obtained from configuration files. The predecessor interfaces mentioned in the present invention can be either direct predecessor interfaces or indirect predecessor interfaces. A direct predecessor interface refers to the interface that was called immediately before the current interface in the business process, and an indirect predecessor interface is one of the multiple interfaces located before the current interface in the business process.

[0038] Step S203, determine the request fields with adjustable parameters and sources of the above custom input and the request fields with adjustable parameters and sources of the above database calls as target request fields, and construct a test script based on the above target request fields. The above test script is used to replace the parameter values of the above target request fields;

[0039] Specifically, filter out those request fields that can be parametrically adjusted and are clearly derived from custom inputs or database calls as the target request fields that the present invention focuses on core, and build test scripts based on the target request fields, so that the test scripts automatically replace the parameter values of the target request fields. The purpose of this step is that after analyzing the sources of all request fields, tracing each request field, ultimately all come from custom inputs and database calls. Although some request fields are derived from the incoming of the predecessor interface, we only need to generate multiple parameters corresponding to multiple target request fields. Because there are call relationships between multiple interfaces, therefore, by directly processing custom inputs and database calls, we can indirectly and efficiently manage the parameters of all interfaces in the entire business process, avoiding the complex process of repeatedly analyzing the responses of each predecessor interface and writing parameters, that is, reducing the maintenance cost of the test scripts and enhancing the comprehensiveness and accuracy of the test.

[0040] Step S204, generate multiple test requests according to the above test scripts, and use the multiple test requests to test the above target business process.

[0041] Specifically, according to the designed test scripts, we can batch generate a series of test requests, which form the cornerstone for comprehensively detecting the target business process. Through automated means, these test requests are sent one by one to deeply probe and verify the entire business process. During the test execution phase, these requests are sent to the system, and through the forward call of the interfaces, a series of business logic checks are triggered, ensuring the correct transfer and processing of data between different interfaces. Even though the test requests themselves are limited to parametric operations on the target request fields, due to the mutual calls between interfaces, the correctness of the subsequent interfaces associated with them can be indirectly verified, thus realizing the automated test of the entire target business process, making the entire test process efficient and fast.

[0042] Through this embodiment, in the above-mentioned interface automation testing method, all interface request sequences of the target business process are obtained. The above interface request sequences include request paths, request headers, request bodies, response headers, and response bodies. The large language model is used to analyze the sources of request fields in each of the above interface request sequences. The above request fields are fields carrying request parameters in the above request paths, the above request headers, and the above request bodies. The sources of the above request fields include custom input, database calls, and incoming fields from predecessor interfaces. The request fields with adjustable parameters and a source of the above custom input and the request fields with adjustable parameters and a source of the above database calls are determined as target request fields, and a test script is constructed based on the above target request fields. The above test script is used to replace the parameter values of the above target request fields. Multiple test requests are generated according to the above test script, and the above target business process is tested using the multiple above test requests. In this application, by obtaining all interface request sequences of the target business process, using the large language model to analyze the sources of all request fields, and determining the fields of database calls with adjustable parameters and the fields with adjustable parameters and a source of custom input as target request fields, and constructing a test script based on the target request fields, so that the test script replaces the parameter values of the target request fields to obtain multiple test requests to test the target business process. Since the ultimate sources of the request fields are custom input or database calls, even if some request fields are from predecessor interfaces, their ultimate sources are still custom input or database calls. Therefore, only the target request fields determined by custom input and database calls need to have their parameters replaced to comprehensively cover and effectively test the entire target business process, avoiding the complex parameter writing process and solving the problem of low efficiency in writing request parameters for test requests in the prior art.

[0043] In order to confirm the target request fields, in an optional implementation manner, the request fields with adjustable parameters and a source of the above custom input and the request fields with adjustable parameters and a source of the above database calls are determined as target request fields. The above step S203 includes:

[0044] Step S2031, determining the request fields with a source of the above custom input and the request fields with a source of the above database calls as common request fields;

[0045] Step S2032, forming a first preset prompt word with at least one adjustable-parameter request field and at least one non-adjustable-parameter request field;

[0046] Step S2033, inputting the above first preset prompt word and the above common request fields into the above large language model to obtain whether the above common request fields are adjustable-parameter;

[0047] Step S2034: Use the above-mentioned public request fields with adjustable parameters as the above-mentioned target request fields.

[0048] Specifically, by further screening the source of the request fields, the request fields from custom input and database calls are used as public request fields. On this basis, the public request fields are further processed. A large language model is used to identify which public request fields can have their parameters adjusted. First, we constructed a first preset prompt written by adjustable and non-adjustable request fields, and input it together with the public request fields into the large language model for intelligent analysis. The aim is to enable the large language model to learn how to better distinguish which public request fields are fields with adjustable parameters through the first preset prompt and the public request fields, that is, to explore which public request fields have the ability to adjust parameters. Finally, we determined the public request fields that are confirmed to have adjustable parameters as the target request fields, thus laying a foundation for the subsequent establishment of test scripts. The main goal of this process is to ensure that when processing request fields, the definition of public request fields enables the test script to focus on the interface parameters that are truly affected by custom input and database calls, avoiding excessive attention to static or irrelevant parameters, thereby improving the pertinence and efficiency of testing. Second, through the design of the first preset prompt, we can distinguish between adjustable and non-adjustable request fields, which optimizes the recognition ability of the large language model to distinguish request fields that can adjust parameters, making it more efficient and accurate, and enhancing the reliability of identifying public request fields with adjustable parameters. That is, by leveraging the reasoning ability of the large language model, we can identify which public request fields can have their parameters adjusted. This process greatly expands the boundaries of testing, enabling testing to not be limited to static scenarios and improving the coverage of testing. Finally, determining the public request fields with adjustable parameters as the target request fields clearly defines the object of the present invention in constructing the test script, providing a basis for the subsequent establishment of the test script. [[ID=?]]

[0049] In a specific embodiment, the input example of inputting the first preset prompt and the public request fields into the large language model is as follows: You are an interface automation testing expert and are writing an interface script. There are the following request fields in the interface. Please, based on your experience and the given first preset prompt, that is, examples of adjustable parameters and examples of non-adjustable parameters, determine which request fields are suitable for parameterization processing and output. The specific requirements are as follows:

[0050] It should be noted that there seems to be a formatting issue with the tag in the original text where it's not clear if it's a numbered list item or something else. I've left it as is in the translation. If it's a formatting error in the original, please correct it for a more accurate translation.Examples of adjustable parameters: username: can be changed in different test cases to simulate different user login attempts; password: similar to username, can be used to verify the impact of different passwords; randomNum: this field represents any randomly generated number, suitable for multiple calls in automated testing to check the system's ability to handle random data; consumerId: used to identify different consumers, and multiple IDs can be used in testing to check the system's consumer management function;

[0051] Examples of non - adjustable parameters: name: If it is not a custom input and there is no field marked as parameterized in the system, it is usually regarded as static information and should not be easily changed unless name changes are allowed in the system design; age: Similarly, if there is no clear parameterization requirement, the age field may be regarded as a fixed individual attribute and is not suitable for frequent adjustment; email: In most cases, the email address is regarded as a fixed and unique identifier. Unless the system design clearly supports scenarios where the email changes, this field should not be randomly changed during testing.

[0052] The common request fields include {input all common request fields}, only output the field names, separated by commas, and do not output any other explanatory information.

[0053] In order to confirm the sources of each request field, in an optional implementation manner, a large - language model is used to analyze the sources of the request fields in each of the above - mentioned interface request sequences. The above - mentioned step S202 includes:

[0054] Step S2021, forming the second preset prompt word by combining the above - mentioned request fields from multiple different sources;

[0055] Step S2022, inputting the above - mentioned second preset prompt word and the above - mentioned request fields in each of the above - mentioned interface request sequences into the above - mentioned large - language model for training to obtain the sources of the above - mentioned request fields in each of the above - mentioned interface request sequences.

[0056] Specifically, by obtaining request fields from multiple different sources to form a second preset prompt word, this prompt word together with all the request fields in each interface request sequence is input into a large language model for in-depth learning and training. After obtaining the second preset prompt word and all the request fields, the large language model can analyze the source of the request fields in each interface request sequence. Whether it is directly from the user's custom input, the parameters obtained from database calls, or the parameters obtained from the previous interface, through the analysis of the large language model, the specific source of each request field can be determined. The main objective of this process is the generation of the second preset prompt word, which integrates request fields from various sources, prompting the model to establish a comprehensive recognition standard during the training process, capable of capturing the internal connection between the fields and the data sources. This is crucial for improving the accuracy and reliability of model analysis, enabling it to effectively judge and output the source of the request fields.

[0057] In a specific embodiment, an example of inputting the second preset prompt word and request fields into the large language model is as follows: You are an interface automation testing expert and are writing interface scripts. You need to analyze the interface request sequences of {test scenario}, judge the source of each interface request field, and the source can be custom input, database call, or parameters passed from the previous interface. Please analyze the field source and output the results. The specific requirements are as follows: 1. The field names do not need to be exactly the same, and it is sufficient to judge the same meaning according to the context; 2. If the request path includes an id or UUID, the source also needs to be judged; 3. xxxx (can be filled in according to experience to better judge the source of the request fields).

[0058] The interface request sequence is {all interface request sequence information}.

[0059] The results are output in the form of a table, including four columns: step number, request field, source step number of the field, and field source, where xxxxx (specific explanations and format specifications for each field).

[0060] Taking "Login - Add a certain document - View document details" as an example, the results returned by the model are shown in Table 2.

[0061] Table 2

[0062] Step Serial Number Request Field Field Source Step Serial Number Field Source 1 body.username 1 Custom Input 1 body.password 1 Custom Input 2 header.token 1 response.header.token 2 body.ConsumerNm 1 request.body.username 3 header.token 1 response.header.token 3 body.orderNo 2 request.body.id

[0063] To process the request fields whose source is passed from the previous interface, in an optional implementation, the above method further includes:

[0064] Step S301, when the source of the above request field is passed in from the above predecessor interface, determine the target predecessor interface, and determine the source of the above request field in the predecessor interface corresponding to the current interface from the interface obtained by the above custom input or the above database call as the target predecessor interface. The above predecessor interface is the interface that directly or indirectly passes the above request field into the above current interface;

[0065] Step S302, determine the above request field of the above target predecessor interface as the above common request field.

[0066] Specifically, when the parameter source of a certain request field is passed in from the predecessor interface, that is, passed in from the previous interface, we need to further deeply judge the request field in the previous interface. First, through the analysis of the field transfer path, clearly confirm and find out the root source of the request field, that is, the target predecessor interface. Because we need to judge the root source of the request field to make the request field of its root source as the common request field, that is, the source of the request field in the predecessor interface corresponding to the current interface from the interface obtained by the custom input or the database call is the target predecessor interface. The direct predecessor interface refers to the interface that is called immediately before the current interface in the business process, and the indirect predecessor interface is one of the multiple interfaces before the current interface in the business process. By effectively identifying and sharing the common request field, the efficiency of writing parameters for the test script is effectively improved, because this avoids the waste of resources of repeatedly constructing the same field in different interface tests, reduces the complexity of the test script, and reduces the workload of maintenance and update.

[0067] In order to obtain multiple test requests that meet the test requirements, in an optional implementation manner, generate multiple test requests according to the above test script. The above step S204 includes:

[0068] Step S2041, in the interface request sequence corresponding to each of the above target request fields, adjust the parameter values of the above target request fields to obtain multiple preliminary request sequences;

[0069] Step S2042, add an assertion request field to each of the above preliminary request sequences to obtain a target request sequence. The above assertion request field is a field for verifying whether the expected result of the test request response is consistent with the actual result;

[0070] Step S2043, use the above target request sequence as the above test request.

[0071] Specifically, during the process of constructing test requests, we adjust the parameter values of those parameters marked as target request fields. This process involves changing the parameter values of the target request fields included in a series of related interface request sequences to obtain multiple preliminary request sequences. After that, in order to comprehensively verify the reliability of the interface response, we further add assertion request fields to each preliminary request sequence. These fields are specifically designed to compare the expected results with the actual response results, ensuring the accuracy of the test. Finally, these preliminary request sequences with assertion request fields added are used as the target request sequences, that is, the parameter values of the target request fields included in the interface request sequence are changed according to the test script, and multiple test requests are generated. The main purpose of this process is that by adjusting the parameter values of the target request fields, we can simulate various test requests, increasing the test coverage and improving the overall test quality of the system. Secondly, the addition of assertion request fields provides a systematic and effective verification mechanism, enabling the test script to more accurately reflect the real business process and accelerating the testing of test requests.

[0072] In a specific embodiment, taking logging in, adding a certain document, and viewing the document details as an example, assertions for the code and msg fields are set in the system. The assertions set by this script are shown in Table 3.

[0073] Table 3

[0074]

[0075] In order to generate test requests that are more in line with the current test environment in different test environments, the above step S2041 further includes:

[0076] Step S20411, obtain the environment information of the current test environment. The above environment information includes development environment, test environment, pre-production environment, and production environment;

[0077] Step S20412, according to the above environment information, combine with the large language model to predict the above parameter values of the above target request fields under different above environment information to obtain multiple environment parameter values that meet the above environment information;

[0078] Step S20413, use each of the generated above environment parameter values as the above parameter values of the above target request fields to obtain multiple above preliminary request sequences.

[0079] Specifically, when adjusting the parameter values of the target request fields, a dynamic environment variable adaptation mechanism is introduced. This mechanism enables the test script to automatically adjust the parameter values of the target request fields according to different test environments (such as development, testing, pre-production, production, etc.). When the test script generates a test request, not only is the parameter value of the target request field set to be adjustable, but it can also combine with the large model to predict the reasonable variation range of the parameters under different environment variables, thereby ensuring the effectiveness and accuracy of the generated test request in different environments. For example, when testing in the development environment, mock data is often used here, and its database configuration may be relatively simple, and the data distribution is also limited. For example, the commodity inventory may be set to infinity to avoid test interruption due to insufficient data. In the testing environment, it is usually a simulation laboratory close to the production environment. The database configuration is similar to that of the production environment, but the data volume is smaller, and there may be certain specific test data sets to simulate specific scenarios. For example, the inventory of a batch of sold-out commodities can be set to test the system's performance in extreme situations. In the pre-production environment, which is used for final performance and function testing, its database configuration is almost the same as that of the production environment, but the data may be real or desensitized to ensure that the test results can reflect the actual situation as much as possible. Its parameter adjustment may involve more complex data dependencies and real-time requirements. In the production environment, as the real operating environment of the system, its parameter adjustment needs to consider factors such as real-time user behavior, system load, and real-time data update. Predict the expected values of API call frequency and response time according to the load situation and user behavior pattern in the production environment, and generate parameter values that are more in line with the current test environment. The purpose of this process is to enable the test script to predict the reasonable variation of parameters in different environments with the help of the dynamic environment variable adaptation mechanism. In this way, even in case of emergencies in the production environment, such as a sudden increase in the number of users and data anomalies, the test script can quickly make adaptive adjustments to ensure the accuracy of the test results.

[0080] In an optional implementation manner, to determine the result of the test, multiple above-mentioned test requests are used to test the above-mentioned target business process. Step S204 further includes:

[0081] Step S2044, when the parameter returned by the assertion request field of the above-mentioned test request indicates that the above-mentioned test request is successfully processed and the returned data meets the expectation, determine that the current above-mentioned test request is a valid request;

[0082] Step S2045, when the parameter returned by the assertion request field of the above-mentioned test request indicates that the above-mentioned test request is not successfully processed or the returned data does not meet the expectation, determine that the current above-mentioned test request is an invalid request;

[0083] Step S2046, when the above test request is the above valid request, record the parameter values of each of the above request fields in the above valid request;

[0084] Step S2047, when the above test request is the above invalid request, determine the reason for invalidity, and the above reason for invalidity includes interface logic error, data processing exception, and network exception.

[0085] Specifically, when the parameters returned by the assertion request field indicate that the test request has been successfully executed and the feedback data is the same as expected, this test request is marked as a valid request. Conversely, if the parameters returned by the assertion request field indicate that the request processing fails to meet the expected standard or the returned data is inconsistent with the expected result, the test request is identified as an invalid request. For valid requests, we further record the parameter values of all request fields, and these data will become an important basis for subsequent test analysis and optimization. When faced with an invalid request, analyze the underlying reasons for invalidity, which may involve errors in interface logic, exceptions during data processing, or instability in network communication, providing accurate positioning information for subsequent system tuning and troubleshooting. By introducing the assertion request field as the criterion for determining the test result, the test system has achieved a high degree of automation, can quickly and accurately identify the correctness of the system response, and greatly improves the efficiency and accuracy of testing.

[0086] In order to perform invalid processing after an invalid request is generated, the above step S2047 further includes:

[0087] Step S20471, construct an exception analysis model, where the above exception analysis model is trained using multiple sets of training data, and each set of training data in the above multiple sets of training data includes a historical reason for invalidity and a corresponding solution strategy for the historical reason for invalidity;

[0088] Step S20472, input the above reason for invalidity into the exception analysis model to obtain an invalid solution strategy corresponding to the above reason for invalidity;

[0089] Step S20473, process the above reason for invalidity according to the above invalid solution strategy to make the above test request the above valid request.

[0090] Specifically, after determining the reason for invalidity, an exception analysis mechanism is also introduced. During the test process, when the test request fails to be successfully processed or the returned data does not meet the expectation, this mechanism will collect exception response information according to the reason for invalidity, including but not limited to interface logic errors, error messages, system logs, network delays, etc. These information will be input into the trained exception analysis model, and the exception analysis model will diagnose the reason for the exception according to the exception pattern library it has learned. The specific process is as follows:

[0091] S10: The model is pre-trained with a large number of historical invalid reasons and corresponding solution strategies, learning the characteristics of different invalid reasons (such as interface logic errors, data processing anomalies, and network anomalies) and the corresponding solution strategies. The model can identify the associations between specific error codes, error messages, log keywords, etc. and the anomaly types, thereby establishing an anomaly pattern library, enabling it not only to effectively identify the invalid reasons but also to generate effective solution strategies based on the invalid reasons.

[0092] S20: When the test request returns an invalid response, the system inputs all relevant invalid reasons of the abnormal response into the trained anomaly analysis model. The model will perform matching analysis based on the real-time input invalid reasons and the pre-trained anomaly pattern library to identify the possible reasons for the anomaly.

[0093] S30: Based on the matching analysis and context analysis, the anomaly analysis model will give the specific types of invalidity (such as interface logic errors, data processing anomalies, network anomalies, etc.). In addition, the model will also provide an anomaly diagnosis report, including the context information where the invalid reason occurs, possible triggering conditions, and recommended repair strategies, to help testers quickly locate the problem and take corresponding measures.

[0094] By introducing the anomaly analysis model, the blindness and speculation of testers when facing invalid requests are reduced, the accuracy and efficiency of problem location are improved. Through the analysis of the anomaly analysis model, it can automatically identify the categories of invalid reasons and give corresponding solution strategies, avoiding the cumbersome process of manually checking each invalid reason one by one, saving testing time, improving the automation level of testing, and the generation of the anomaly diagnosis report not only provides a detailed description of the anomaly but also gives potential repair strategies, providing direct guidance for developers and accelerating the process of defect repair.

[0095] In order to obtain all the interface request sequences involved in the target business process, in an alternative embodiment, all the interface request sequences of the target business process are obtained, and the above step S201 includes:

[0096] Step S2011, when executing the above target business process, use a recording tool to record all the above interface request sequences triggered during the execution of the above target business process.

[0097] Specifically, a recording tool is used to capture each interface request sequence triggered in the entire process. This process ensures that every interface request sequence involved in the interaction details from the start to the completion of the business process is recorded without omission. Extracting the required information directly from the recorded sequences saves a large amount of manpower and time costs.

[0098] It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. And although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0099] Figure 3 It is a script generation diagram of an interface automation testing method provided according to an embodiment of the present application. As Figure 3 shown, the specific steps include:

[0100] S1: Acquisition of the request sequence, by using a recording tool to completely capture all interface request sequences in the target business process, laying the data foundation for the generation of the automation testing script.

[0101] S2: Intelligent analysis, using large language model technology to deeply analyze the logical relationship between interfaces, obtaining the sources of request fields and analyzing all target request fields with adjustable parameters, providing guidance for script generation.

[0102] S3: Script generation, according to the results of the previous two stages, generating test scripts covering multi-interface combination scenarios, generating multiple test requests for testing, improving the testing efficiency and quality.

[0103] The embodiment of the present application also provides an interface automation testing device. It should be noted that an interface automation testing device in an embodiment of the present application can be used to execute the interface automation testing method provided in an embodiment of the present application. This device is used to implement the above-mentioned embodiment and the preferred implementation manner, and those that have been described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0104] The following introduces an interface automation testing device provided in an embodiment of the present application.

[0105] Figure 4 It is a structural block diagram of an interface automation testing device according to an embodiment of the present application. As Figure 4 shown, the device includes:

[0106] An acquisition unit 10, configured to acquire all interface request sequences of the target business process, where the interface request sequences include a request path, a request header, a request body, a response header, and a response body;

[0107] Specifically, all interface request sequences covered under the target business process can be captured through a page recording tool. That is, when executing multiple business processes, multiple requests will be triggered. By recording this process, detailed records of each interface call can be comprehensively collected, including the request path, request headers, request body, as well as the corresponding response headers and response body. Through this comprehensive process of obtaining interface request sequences, this application can construct a complete and clear set of interface request sequences, providing a data basis for the subsequent generation of test scripts.

[0108] An analysis unit 20, configured to analyze the sources of request fields in each of the above interface request sequences using a large language model. The above request fields are the fields carrying request parameters in the above request path, the above request headers, and the above request body. The sources of the above request fields include custom input, database calls, and incoming values from predecessor interfaces.

[0109] Specifically, using a large language model as the core technical means to analyze the sources of each request field in the interface request sequence, analyze the sources of all request fields carrying request parameters in each interface request sequence, such as parameter values from external custom input, return values of the previous interface, request parameter values of the previous interface, or values from database calls. The values from database calls also include values obtained from configuration files, etc. The predecessor interfaces mentioned in the present invention can be either direct predecessor interfaces or indirect predecessor interfaces. A direct predecessor interface refers to the interface that was called immediately before the current interface in the business process, and an indirect predecessor interface is one of the multiple interfaces located before the current interface in the business process.

[0110] A determination unit 30 determines the request fields with adjustable parameters and a source of the above custom input and the request fields with adjustable parameters and a source of the above database calls as target request fields, and constructs a test script based on the above target request fields. The above test script is used to replace the parameter values of the above target request fields.

[0111] Specifically, those request fields that can be parametrically adjusted and are clearly sourced from custom inputs or database calls are screened out as the target request fields that the present invention focuses on core, and test scripts are constructed based on the target request fields, so that the test scripts automatically replace the parameter values of the target request fields. The purpose of this step is that after analyzing the sources of all request fields, tracing each request field, ultimately all come from custom inputs and database calls. Although some request fields are sourced from the predecessor interfaces, we only need to generate multiple parameters corresponding to the multiple target request fields. Because there are call relationships among multiple interfaces, thus, by directly processing custom inputs and database calls, we can indirectly and efficiently manage the parameters of all interfaces in the entire business process, avoiding the complex process of repeatedly analyzing the responses of each predecessor interface and writing parameters, that is, reducing the maintenance cost of the test scripts and enhancing the comprehensiveness and accuracy of the tests.

[0112] The construction unit 40 generates multiple test requests according to the above test scripts and uses the multiple above test requests to test the above target business process.

[0113] Specifically, according to the designed test scripts, we can batch generate a series of test requests. This series of requests constitutes the cornerstone for comprehensively detecting the target business process. Through automated means, these test requests are sent one by one to deeply probe and verify the entire business process. During the test execution phase, these requests are sent to the system, and through the forward call of the interfaces, a series of business logic checks are triggered, ensuring the correct transfer and processing of data between different interfaces. Even though the test requests themselves are limited to parametric operations on the target request fields, due to the mutual calls between interfaces, the correctness of the subsequent interfaces associated with them can be indirectly verified, thus realizing the automated test of the entire target business process, making the entire test process efficient and fast.

[0114] In this embodiment, in the above interface automation testing device, an acquisition unit is configured to acquire all interface request sequences of a target business process, where the interface request sequences include request paths, request headers, request bodies, response headers, and response bodies; an analysis unit is configured to analyze the sources of request fields in each of the interface request sequences by using a large language model, where the request fields are the fields carrying request parameters in the request paths, the request headers, and the request bodies, and the sources of the request fields include custom input, database calls, and incoming fields from predecessor interfaces; a determination unit determines the request fields with adjustable parameters and a source of the custom input and the request fields with adjustable parameters and a source of the database calls as target request fields, and constructs a test script according to the target request fields, where the test script is used to replace parameter values of the target request fields; a construction unit generates multiple test requests according to the test script, and uses the multiple test requests to test the target business process. In this application, by acquiring all interface request sequences of a target business process, analyzing the sources of all request fields by using a large language model, and determining the fields of database calls with adjustable parameters and the fields with adjustable parameters and a source of custom input as target request fields, and constructing a test script according to the target request fields, so that the test script replaces the parameter values of the target request fields to obtain multiple test requests for testing the target business process. Since the ultimate sources of the request fields are custom input or database calls, even if some request fields are from predecessor interfaces, their ultimate sources are still custom input or database calls. Therefore, only the target request fields determined by custom input and database calls need to be parameter-replaced to comprehensively cover and effectively test the entire target business process, avoiding the complex parameter writing process and solving the problem of low efficiency in writing request parameters of test requests in the prior art.

[0115] In an alternative embodiment, to confirm the target request fields, the request fields with adjustable parameters and a source of the custom input and the request fields with adjustable parameters and a source of the database calls are determined as target request fields, and the determination unit includes:

[0116] A first determination module is configured to determine the request fields with a source of the custom input and the request fields with a source of the database calls as common request fields;

[0117] A second determination module is configured to form a first preset prompt word by using at least one request field with adjustable parameters and at least one request field with non-adjustable parameters;

[0118] A third determination module is configured to input the first preset prompt word and the common request fields into the large language model to obtain whether the common request fields are adjustable in parameters;

[0119] A fourth determination module, configured to use the above-mentioned public request fields with adjustable parameters as the above-mentioned target request fields.

[0120] Specifically, by further screening the sources of the request fields, the request fields whose sources are custom input and database calls are used as public request fields. On this basis, the public request fields are further processed. A large language model is used to identify which public request fields can have their parameters adjusted. First, we constructed a first preset prompt word composed of adjustable and non-adjustable request fields, and input it together with the public request fields into the large language model for intelligent analysis, aiming to enable the large language model to learn how to better distinguish which public request fields are fields with adjustable parameters through the first preset prompt word and the public request fields, that is, to explore which of the public request fields have the ability to adjust parameters. Finally, we determined the public request fields that are confirmed to have adjustable parameters as the target request fields, thus laying a foundation for the subsequent establishment of test scripts. The main goal of this process is that when processing request fields, the definition of public request fields ensures that the test script can focus on the interface parameters that are truly affected by custom input and database calls, avoiding excessive attention to static or irrelevant parameters, thereby improving the pertinence and efficiency of testing. Secondly, through the design of the first preset prompt word, we can distinguish between adjustable and non-adjustable request fields, which optimizes the recognition ability of the large language model to distinguish request fields that can have their parameters adjusted, making it more efficient and accurate, and enhancing the reliability of identifying public request fields with adjustable parameters. That is, by relying on the reasoning ability of the large language model, we can identify which public request fields can have their parameters adjusted. This process greatly expands the boundaries of testing, making the testing not limited to static scenarios and improving the coverage of testing. Finally, determining the public request fields with adjustable parameters as the target request fields clearly defines the object of the present invention in constructing the test script and provides a basis for the subsequent establishment of the test script.

[0121] In order to confirm the sources of the respective request fields, in an optional implementation manner, a large language model is used to analyze the sources of the request fields in each of the above-mentioned interface request sequences. The above-mentioned analysis unit includes:

[0122] A first analysis module, configured to form a second preset prompt word from the above-mentioned request fields with multiple different sources;

[0123] A second analysis module, configured to input the second preset prompt word and the above-mentioned request fields in each of the above-mentioned interface request sequences into the large language model for training to obtain the sources of the above-mentioned request fields in each of the above-mentioned interface request sequences.

[0124] Specifically, by obtaining request fields from multiple different sources, a second preset prompt word is constructed. This prompt word, together with all the request fields in each interface request sequence, is input into the large language model for in-depth learning and training. After obtaining the second preset prompt word and all the request fields, the large language model can analyze the source of each request field in the interface request sequence, whether it is directly from the user's custom input, the parameters obtained from database calls, or the parameters obtained from the previous interface. Through the analysis of the large language model, the specific source of each request field can be determined. The main objective of this process is the generation of the second preset prompt word, which integrates request fields from various sources, prompting the model to establish a comprehensive recognition standard during the training process, being able to capture the internal connection between the fields and the data sources, which is crucial for improving the accuracy and reliability of model analysis, enabling it to effectively judge and output the source of the request fields.

[0125] In order to process the request fields whose source is the request fields passed in from the previous interface, in an optional implementation manner, the above device further includes:

[0126] A first processing unit, configured to determine a target previous interface when the source of the above request field is the request field passed in from the above previous interface, and determine the source of the above request field in the previous interface corresponding to the current interface from the above custom input or the interface obtained by the above database call as the target previous interface, where the previous interface is the interface that directly or indirectly passes the above request field into the above current interface;

[0127] A second processing unit, configured to determine the above request field of the above target previous interface as the above common request field.

[0128] Specifically, when the parameter source of a certain request field is the request field passed in from the previous interface, that is, the request field passed in from the previous interface, we need to further deeply judge the request field in the previous interface. First, through the analysis of the field transfer path, clearly confirm and find out the root source of the request field, that is, the target previous interface, because we need to judge the root source of the request field to make the request field of its root source as the common request field, that is, the source of the request field in the previous interface corresponding to the current interface from the custom input or the interface obtained by the database call is the target previous interface. Among them, the direct previous interface refers to the interface that is called immediately before the current interface in the business process, and the indirect previous interface is one of the multiple interfaces located before the current interface in the business process. By effectively identifying and sharing the common request fields, the efficiency of writing test script parameters is effectively improved, because this avoids the waste of resources caused by repeatedly constructing the same fields in different interface tests, reduces the complexity of the test script, and reduces the workload of maintenance and update.

[0129] In an alternative implementation, to obtain multiple test requests that meet the test requirements, multiple test requests are generated according to the above test script. The above construction unit includes:

[0130] A first construction module for adjusting the parameter values of the above target request fields in the interface request sequences corresponding to each of the above target request fields to obtain multiple preliminary request sequences;

[0131] A second construction module for adding assertion request fields to each of the above preliminary request sequences to obtain target request sequences. The above assertion request fields are fields for verifying whether the expected result of the test request response is consistent with the actual result;

[0132] A third construction module for using the above target request sequences as the above test requests.

[0133] Specifically, during the process of constructing test requests, we adjust the parameter values of those parameters marked as target request fields. This process involves changing the parameter values of the target request fields included in a series of related interface request sequences to obtain multiple preliminary request sequences. After that, in order to comprehensively verify the reliability of the interface response, we further add assertion request fields to each preliminary request sequence. These fields are specifically designed to compare the expected result with the actual response result, ensuring the accuracy of the test. Finally, these preliminary request sequences with assertion request fields added are used as target request sequences, that is, the parameter values of the target request fields included in the interface request sequence are changed according to the test script, and multiple test requests are generated. The main purpose of this process is that by adjusting the parameter values of the target request fields, we can simulate various test requests, increasing the test coverage and improving the overall test quality of the system. Secondly, the addition of assertion request fields provides a systematic and effective verification mechanism, enabling the test script to more accurately reflect the real business process and accelerating the testing of test requests.

[0134] In an alternative implementation, to determine the test results, the above target business process is tested using multiple above test requests. The above construction unit further includes:

[0135] A fourth construction module for determining that the current above test request is a valid request when the parameter returned by the above assertion request field of the above test request indicates that the above test request has been successfully processed and the returned data meets the expectations;

[0136] A fifth construction module for determining that the current above test request is an invalid request when the parameter returned by the above assertion request field of the above test request indicates that the above test request has not been successfully processed or the returned data does not meet the expectations;

[0137] A sixth construction module, configured to record the parameter values of each of the above request fields in the above valid request when the above test request is the above valid request;

[0138] A seventh construction module, configured to determine the cause of invalidity when the above test request is the above invalid request, where the cause of invalidity includes interface logic errors, data processing exceptions, and network exceptions.

[0139] Specifically, when the parameters returned by the assertion request field indicate that the test request has been successfully executed and the feedback data is the same as expected, this test request is marked as a valid request. Conversely, if the parameters returned by the assertion request field indicate that the request processing fails to meet the expected standard or the returned data is inconsistent with the expected result, the test request is marked as an invalid request. For valid requests, we further record the parameter values of all request fields, and these data will become an important basis for subsequent test analysis and optimization. When faced with an invalid request, we analyze the underlying cause of invalidity, which may involve errors in interface logic, exceptions during data processing, or instability in network communication, providing accurate positioning information for subsequent system tuning and fault troubleshooting. By introducing the assertion request field as the criterion for determining the test result, the test system achieves a high degree of automation, can quickly and accurately identify the correctness of the system response, and greatly improves the efficiency and accuracy of testing.

[0140] In order to obtain all the interface request sequences involved in the target business process, in an alternative implementation, all the interface request sequences of the target business process are obtained, and the above obtaining unit includes:

[0141] A first obtaining module, configured to use a recording tool to record all the above interface request sequences triggered during the execution of the above target business process when the above target business process is executed.

[0142] Specifically, a recording tool is used to capture each interface request sequence triggered during the entire process. This process ensures that every interface request sequence involved in the interaction details from the start to the completion of the business process is recorded without omission. Directly extracting the required information from the recorded sequences saves a large amount of human and time costs.

[0143] The above interface automation test device includes a processor and a memory. The above obtaining unit, analysis unit, determination unit, construction unit, etc. are all stored in the memory as program units, and the processor executes the above program units stored in the memory to implement corresponding functions. The above modules are all located in the same processor; or, the above each module is located in different processors in any combination form.

[0144] The processor contains a kernel, which retrieves the corresponding program units from the memory. One or more kernels can be set, and by adjusting the kernel parameters, the efficiency of writing test requests for test scripts can be improved.

[0145] The memory may include non-permanent memory in a computer-readable medium, forms such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM), and the memory includes at least one storage chip.

[0146] An embodiment of the present invention provides a computer-readable storage medium. The above computer-readable storage medium includes a stored program. When the above program runs, it controls the device where the above computer-readable storage medium is located to execute the above interface automation test method.

[0147] Specifically, an interface automation test method includes:

[0148] Step S201, obtaining all interface request sequences of the target business process. The above interface request sequences include request paths, request headers, request bodies, response headers, and response bodies;

[0149] Step S202, using a large language model to analyze the sources of request fields in each of the above interface request sequences. The above request fields are the fields carrying request parameters in the above request paths, the above request headers, and the above request bodies. The sources of the above request fields include custom input, database calls, and incoming from predecessor interfaces;

[0150] Step S203, determining the request fields with adjustable parameters and a source of the above custom input and the request fields with adjustable parameters and a source of the above database calls as target request fields, and constructing a test script according to the above target request fields. The above test script is used to replace the parameter values of the above target request fields;

[0151] Step S204, generating multiple test requests according to the above test script, and using the multiple above test requests to test the above target business process.

[0152] An embodiment of the present invention provides a processor. The above processor is used to run a program. When the above program runs, it executes the above interface automation test method.

[0153] Specifically, an interface automation test method includes:

[0154] Step S201, obtaining all interface request sequences of the target business process. The above interface request sequences include request paths, request headers, request bodies, response headers, and response bodies;

[0155] Step S202: Analyze the sources of the request fields in each of the above interface request sequences using a large language model. The above request fields are the fields carrying request parameters in the above request path, the above request headers, and the above request bodies. The sources of the above request fields include custom input, database calls, and incoming fields from predecessor interfaces.

[0156] Step S203: Determine the target request fields with adjustable parameters and sources of the above custom input and the target request fields with adjustable parameters and sources of the above database calls, and construct a test script based on the above target request fields. The above test script is used to replace the parameter values of the above target request fields.

[0157] Step S204: Generate multiple test requests according to the above test script, and use the multiple above test requests to test the above target business process.

[0158] The embodiment of the present application also provides an interface automation test system, including: one or more processors, a memory, and one or more programs. Among them, the above one or more programs are stored in the above memory and are configured to be executed by the above one or more processors, including executing any one of the above methods in the above interface automation test method.

[0159] Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general-purpose computing device. They can be concentrated on a single computing device or distributed on a network composed of multiple computing devices. They can be implemented by program codes executable by the computing device. Thus, they can be stored in a storage device and executed by the computing device. And in some cases, the steps shown or described can be executed in a different order than here, or they can be separately made into individual integrated circuit modules, or multiple modules or steps among them can be made into a single integrated circuit module for implementation. In this way, the present invention is not limited to any specific combination of hardware and software.

[0160] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0161] This application is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present application. It should be understood that each flow and / or block in the flowchart and / or block diagram, as well as the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing device generate means for implementing the functions specified in one Figure 1 flow or multiple flows and / or blocks Figure 1 or means for implementing the functions specified in one block or multiple blocks.

[0162] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means that implement the functions specified in one Figure 1 flow or multiple flows and / or blocks Figure 1 or means for implementing the functions specified in one block or multiple blocks.

[0163] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one Figure 1 flow or multiple flows and / or blocks Figure 1 or means for implementing the functions specified in one block or multiple blocks.

[0164] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and a memory.

[0165] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash memory. The memory is an example of computer-readable media.

[0166] A computer-readable medium includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), or other optical storage, magnetic cassette tapes, magnetic disk storage, or other magnetic storage devices, or any other non-transitory medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer-readable medium does not include transitory computer-readable media, such as modulated data signals and carrier waves.

[0167] It should also be noted that the term "comprising", "including", or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that includes a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the statement "including a..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0168] From the above description, it can be seen that the above embodiments of the present application achieve the following technical effects:

[0169] 1) In an interface automation testing method of the present application, by obtaining all interface request sequences of a target business process, using a large language model to analyze the sources of all request fields, and determining the fields of database calls with adjustable parameters and the fields with adjustable parameters and a custom input source as target request fields, and constructing a test script based on the target request fields, so that the test script replaces the parameter values of the target request fields to obtain multiple test requests for testing the target business process. Since the ultimate sources of the request fields are custom input or database calls, even if some request fields are from predecessor interfaces, their ultimate sources are still custom input or database calls. Therefore, only the parameter replacement of the target request fields determined by the custom input and database calls is required to comprehensively cover and effectively test the entire target business process, avoiding the complex parameter writing process and solving the problem of low efficiency in writing request parameters of test requests in the prior art.

[0170] 2) An interface automation testing device of the present application obtains all interface request sequences of a target business process, analyzes the sources of all request fields using a large language model, determines the fields of database calls with adjustable parameters and the fields with adjustable parameters and a custom input source as target request fields, and constructs a test script based on the target request fields, so that the test script replaces the parameter values of the target request fields to obtain multiple test requests for testing the target business process. Since the ultimate sources of the request fields are custom input or database calls, even if some request fields are from predecessor interfaces, their ultimate sources are still custom input or database calls. Therefore, only the parameter replacement of the target request fields determined by custom input and database calls is required to comprehensively cover and effectively test the entire target business process, avoiding the complex parameter writing process and solving the problem of low efficiency in writing request parameters of test requests in the prior art.

[0171] The foregoing are only the preferred embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the protection scope of the present application.

Claims

1. An interface automation testing method, characterized in that, Including: Obtain all interface request sequences of the target business process, where the interface request sequence includes a request path, request headers, a request body, response headers, and a response body; Use a large language model to analyze the sources of request fields in each of the interface request sequences. The request fields are the fields carrying request parameters in the request path, the request headers, and the request body, and the sources of the request fields include custom input, database calls, and incoming from a predecessor interface; Determine the target request fields as the request fields with adjustable parameters and a source of the custom input and the request fields with adjustable parameters and a source of the database call, and construct a test script based on the target request fields. The test script is used to replace the parameter values of the target request fields; Generate multiple test requests according to the test script, and use the multiple test requests to test the target business process.

2. The method according to claim 1, wherein Determine the target request fields as the request fields with adjustable parameters and a source of the custom input and the request fields with adjustable parameters and a source of the database call, including: Determine the request fields with a source of the custom input and the request fields with a source of the database call as common request fields; Form a first preset prompt word with at least one request field with adjustable parameters and at least one request field with non-adjustable parameters; Input the first preset prompt word and the common request fields into the large language model to obtain whether the common request fields are adjustable; Use the adjustable common request fields as the target request fields.

3. The method according to claim 1, wherein Use a large language model to analyze the sources of request fields in each of the interface request sequences, including: Form a second preset prompt word with the request fields from multiple different sources; Train the large language model according to the second preset prompt word and the request fields in each of the interface request sequences to obtain the sources of the request fields in each of the interface request sequences.

4. The method according to claim 2, wherein The method further includes: In the case where the source of the request field is incoming from a predecessor interface, determine the target predecessor interface, and determine the interface obtained by the source of the request field in the predecessor interface corresponding to the current interface from the custom input or the database call as the target predecessor interface. The predecessor interface is the interface that directly or indirectly passes the request field to the current interface; Determine the request fields of the target predecessor interface as the common request fields.

5. The method according to claim 1, wherein Generate multiple test requests according to the test script, including: In each of the interface request sequences corresponding to the target request fields, adjust the parameter values of the target request fields to obtain multiple preliminary request sequences; Add assertion request fields to each of the preliminary request sequences to obtain target request sequences. The assertion request fields are the fields for verifying whether the expected result of the test request response is consistent with the actual result; Use the target request sequences as the test requests.

6. The method according to claim 5, wherein Use the multiple test requests to test the target business process, including: When the parameter returned in the assertion request field of the test request indicates that the test request has been successfully processed and the returned data meets the expectations, determine that the current test request is a valid request; When the parameter returned in the assertion request field of the test request indicates that the test request has not been successfully processed or the returned data does not meet the expectations, determine that the current test request is an invalid request; When the test request is the valid request, record the parameter values of each request field in the valid request; When the test request is the invalid request, determine the reason for invalidity, and the reason for invalidity includes interface logic error, data processing exception, and network exception.

7. The method according to claim 1, characterized in that, Obtain all interface request sequences of the target business process, including: When executing the target business process, use a recording tool to record all the interface request sequences triggered during the execution of the target business process.

8. An interface automated test device, characterized in that, Including: An acquisition unit, configured to obtain all interface request sequences of a target business process, where the interface request sequences include a request path, a request header, a request body, a response header, and a response body; An analysis unit, configured to analyze the sources of request fields in each interface request sequence by using a large language model, where the request fields are the fields carrying request parameters in the request path, the request header, and the request body, and the sources of the request fields include custom input, database call, and predecessor interface input; A determination unit, configured to determine the request fields with adjustable parameters and a source of the custom input and the request fields with adjustable parameters and a source of the database call as target request fields, and construct a test script according to the target request fields, where the test script is used to replace the parameter values of the target request fields; A construction unit, configured to generate multiple test requests according to the test script, and use the multiple test requests to test the target business process.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, where, when the program runs, it controls the device where the computer-readable storage medium is located to execute the method according to any one of claims 1 to 7.

10. An interface automated testing system, characterized in that, Including: One or more processors, a memory, and one or more programs, where the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs include the method for executing any one of claims 1 to 7.

Images