Interface test method and device, electronic equipment and readable storage medium

Abstract

The present disclosure provides an interface test method and device, electronic equipment and readable storage medium, which are used to improve the accuracy of interface test. The method comprises: receiving interface test data; the interface test data comprises request type data, extraction type data and assertion type data; generating and sending a request data packet according to the request object and the request mode contained in the request type data; the request data packet is used to call the interface to be tested, so that the interface to be tested accesses the request object according to the request mode to obtain access result data; obtaining the access result data obtained by the interface to be tested; determining an extractor corresponding to the extraction type data, and extracting the effective data information contained in the access result data through the extractor; determining an assertor corresponding to the assertion type data, and generating an assertion result corresponding to the effective data information through the assertor; wherein, the assertion result is used to represent whether the function of the interface to be tested is abnormal.

Description

Technical Field

[0001] This disclosure relates to the field of testing technology, and in particular to an interface testing method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] An Application Programming Interface (API) is a set of conventions that govern the interaction between different components of a software system. As software has grown increasingly large in recent years, it is often necessary to divide complex systems into smaller components; therefore, the design of programming interfaces is crucial. In programming practice, the first step in designing a programming interface is to ensure a reasonable division of responsibilities within the software system.

[0003] In particular, good interface design can reduce the interdependence of different parts of the system, increase the cohesion of the constituent units, and reduce the coupling between the constituent units, thereby improving the maintainability and scalability of the system. Therefore, business systems typically contain a large number of application programming interfaces (APIs). To avoid data errors caused by API malfunctions, it is necessary to test these APIs.

[0004] In related technologies, implementing API testing functionality requires testers to manually write test code. Since API testing involves multiple steps, testers must write code for each step, resulting in a tedious, time-consuming, and error-prone process. Furthermore, in collaborative development projects, the lack of standardized coding and calling conventions can easily lead to disorganized API testing, increasing later maintenance costs. Summary of the Invention

[0005] This disclosure provides an interface testing method, apparatus, electronic device, and readable storage medium to improve the efficiency and accuracy of interface testing.

[0006] Firstly, this disclosure provides an interface testing method, including the following steps:

[0007] The interface test data is received by the user through the data call template set in the interface testing tool; wherein, the data call template includes: request class call template, extraction class call template and assertion class call template, and the interface test data includes: request type data received through request class call template, extraction type data received through extraction class call template and assertion type data received through assertion class call template;

[0008] Based on the request object and request method contained in the request type data, a request data message is generated and sent; wherein, the request data message is used to call the interface to be tested, so that the interface to be tested accesses the request object according to the request method and obtains access result data;

[0009] Obtain the access result data obtained from accessing the interface to be tested;

[0010] Determine the extractor corresponding to the data type being extracted, and use the extractor to extract the valid data information contained in the access result data;

[0011] An assertion corresponding to the assertion type data is determined, and an assertion result corresponding to the valid data information is generated through the assertion, and the test result of the interface to be tested is determined based on the assertion result; the test result is used to characterize whether there is an anomaly in the function of the interface to be tested.

[0012] Secondly, this disclosure provides an interface testing apparatus, comprising:

[0013] The receiving module is adapted to receive user-inputted interface test data through a data call template set in the interface testing tool; wherein, the data call template includes: a request class call template, an extraction class call template, and an assertion class call template, and the interface test data includes: request type data received through the request class call template, extraction type data received through the extraction class call template, and assertion type data received through the assertion class call template;

[0014] The sending module is adapted to generate and send a request data message based on the request object and request method contained in the request type data; wherein, the request data message is used to call the interface to be tested, so that the interface to be tested accesses the request object according to the request method and obtains access result data;

[0015] The acquisition module is adapted to acquire the access result data obtained from accessing the interface to be tested;

[0016] An extraction module is adapted to determine an extractor corresponding to the data of the extraction type, and to extract valid data information contained in the access result data through the extractor.

[0017] An assertion module is adapted to determine an assertor corresponding to the assertion type data, generate an assertion result corresponding to the valid data information through the assertor, and determine the test result of the interface to be tested based on the assertion result; the test result is used to characterize whether there is an anomaly in the function of the interface to be tested.

[0018] Thirdly, this disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the above-described method.

[0019] Fourthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the above-described method when executed by a processor / processor core.

[0020] The embodiments provided in this disclosure, upon receiving interface test data input by the user, firstly, generate and send a request data message based on the request object and request method contained in the request type data; then, obtain the access result data returned after the interface to be tested accesses the request object, and extract the valid data information contained in the access result data through an extractor corresponding to the extraction type data; finally, generate an assertion result corresponding to the valid data information through an assertion type data, thereby determining whether the function of the interface to be tested is abnormal based on the assertion result. Thus, in this method, the user can directly input interface test data through the data call template set in the interface testing tool; specifically, request type data can be input through the request class call template, extraction type data through the extraction class call template, and assertion type data through the assertion class call template. In short, by setting multiple data call templates corresponding to different data types, users can conveniently and quickly input various types of data required during the testing process. This method can automatically encapsulate and send the corresponding request data message based on the interface test data input by the user, and automatically determine the corresponding extractor based on the extraction type data, so as to extract the valid data information contained in the access result data through the extractor. Furthermore, it can automatically determine the corresponding assertion based on the assertion type data, so as to generate assertion results corresponding to the valid data information through the assertion. In summary, in this method, users only need to input the interface test data necessary for the testing process, and the subsequent test steps can be automatically implemented through the pre-configured test process, thereby significantly reducing the amount of code writing, avoiding errors that may occur during manual coding, and improving the accuracy of testing.

[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0022] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the detailed description of exemplary embodiments with reference to the accompanying drawings, in which:

[0023] Figure 1 A flowchart illustrating an interface testing method provided in one embodiment of this disclosure;

[0024] Figure 2 A flowchart illustrating an interface testing method as a specific example of this disclosure;

[0025] Figure 3 A block diagram of an interface testing apparatus provided in an embodiment of this disclosure;

[0026] Figure 4 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0027] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0028] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0029] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0030] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0031] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0032] The interface testing method according to embodiments of this disclosure can be executed by electronic devices such as terminal devices or servers. Terminal devices can be in-vehicle devices, user equipment (UE), mobile devices, user terminals, terminals, cellular phones, cordless phones, personal digital assistants (PDAs), handheld devices, computing devices, in-vehicle devices, wearable devices, etc. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Specifically, the method can be implemented by a processor calling a computer program stored in memory.

[0033] In related technologies, implementing interface testing functionality requires testers to manually write test code. Since interface testing involves multiple steps, testers must write code for each step, resulting in a tedious, time-consuming, and error-prone process. To address these issues, this application proposes an interface testing method. In this method, users only need to input the necessary interface test data, and the system automatically executes subsequent test steps through a pre-configured test flow. This significantly reduces the amount of code required, avoids errors that may occur during manual coding, and improves test accuracy.

[0034] Figure 1 A flowchart illustrating an interface testing method provided as an embodiment of this disclosure. (See also...) Figure 1 The method includes:

[0035] Step S110: Receive the interface test data input by the user through the data call template set in the interface testing tool.

[0036] The data call templates include: request class call template, extraction class call template and assertion class call template, and the interface test data includes: request type data received through the request class call template, extraction type data received through the extraction class call template and assertion type data received through the assertion class call template.

[0037] Interface test data refers to parameter or configuration data necessary for the interface testing process. This embodiment does not limit the specific content of interface test data. Typically, interface test data includes at least: request type data, extraction type data, and assertion type data.

[0038] The request type data is used to define the request parameters required when calling the interface under test, including, for example, the request object, request method, and request data format. In short, the request type data is used to trigger the request data message; anything required to generate the request data message can be used as the request type data. The extract type data is used to characterize the type of extractor, for use during the extractor's extraction of valid data information. The assertion type data is used to characterize the type of assertor, for use during the assertion process.

[0039] In summary, this step involves collecting all types of data required for subsequent processes to ensure the smooth operation of automated testing.

[0040] To facilitate user input of interface test data and avoid problems caused by non-standard user input, this embodiment uses data call templates set in the interface testing tool to receive user-inputted interface test data. These data call templates include various templates corresponding to different types of interface test data. The number of data input interfaces, interface names, and input format specifications in each type of data call template are configured according to the characteristics of the corresponding interface test data. Therefore, users can easily and accurately complete the input process without needing complex programming skills, reducing the complexity of user operations and the error rate.

[0041] In one optional implementation, the aforementioned interface test data are received through a visual test interface. This test interface includes multiple input fields for inputting various types of interface test data. Specifically, when receiving user-inputted interface test data, the test interface uses the request type input field to receive request-type data, the extraction type input field to receive extraction-type data, and the assertion type input field to receive assertion-type data.

[0042] In practice, the request class call template receives request type data input by the user, which is entered by the user through the request type input entry in the test interface of the interface testing tool; the extraction class call template receives extraction type data input by the user, which is entered by the user through the extraction type input entry in the test interface of the interface testing tool; and the assertion class call template receives assertion type data input by the user, which is entered by the user through the assertion type input entry in the test interface of the interface testing tool.

[0043] Each input field can be implemented in various ways, such as dropdown lists or input boxes. For example, if the range of input data values ​​is relatively fixed, a dropdown list can be used to receive the corresponding data, allowing users to select within the specified range and avoiding invalid data input. Conversely, if the range of input data values ​​is flexible, an input box can be used to receive the corresponding data, ensuring users can flexibly input various possible content. In short, by configuring a visual testing interface, on the one hand, the range of user input values ​​can be constrained to improve the accuracy of input data; on the other hand, it provides users with intuitive convenience, avoiding obstacles caused by users' lack of coding skills.

[0044] In one optional implementation, different storage containers are allocated for different types of interface test data to achieve categorized data storage. Considering that the various types of data contained in the interface test data are used in different test steps, and since the test steps corresponding to each type of interface test data are different, multiple storage containers need to be pre-set to quickly distinguish the data needed in each step during subsequent testing. Each storage container is used to store the corresponding type of interface test data. Accordingly, after receiving request type data from the user-input interface test data, the request type data is further stored in the request type container; after receiving extraction type data from the user-input interface test data, the extraction type data is further stored in the extraction type container; and after receiving assertion type data from the user-input interface test data, the assertion type data is further stored in the assertion type container.

[0045] Therefore, this application includes at least a request type container, an extraction type container, and an assertion type container, which respectively store the data content required in the request data message sending step, the result data extraction step, and the assertion step. Since the data content required in different test steps is stored in different containers, it facilitates quick retrieval and avoids confusion.

[0046] Step S120: Generate and send a request data message based on the request object and request method contained in the request type data; wherein, the request data message is used to call the interface to be tested, so that the interface to be tested accesses the request object according to the request method and obtains the access result data.

[0047] Request type data refers to data used to characterize relevant parameters in the request data message. A request data message is a message sent to the interface under test to control the interface to access a specified request object according to a specified request method. The specified request method may include query, change, and delete requests, etc. Request objects typically include URLs, servers, and other similar objects.

[0048] Accordingly, when generating and sending a request data message based on the request object and request method contained in the request type data, it can be achieved in the following way: First, obtain the request object and request method contained in the request type data from the request type container; then, based on the request object and request method, encapsulate the corresponding message request header and message data content; finally, assemble the message request header and message data content into a request data message and send the request data message to the interface to be tested.

[0049] Step S130: Obtain the access result data obtained from the interface to be tested.

[0050] The interface to be tested can be various application programming interfaces (APIs), and this application aims to test whether the functions of these APIs are normal. Accordingly, after the interface to be tested receives a request data message, it will access the corresponding request object according to the request method specified in the request data message, thereby obtaining the access result data. Correspondingly, the execution subject of this embodiment (for example, the execution subject can be an interface automation testing tool) will receive the access result data returned after the interface to be tested accesses the request object. The access result data includes various forms, such as data read from a specified database.

[0051] Step S140: Determine the extractor corresponding to the data type to be extracted, and extract the valid data information contained in the access result data through the extractor.

[0052] The extraction type data is used to characterize the type of extractor. Accordingly, when determining the extractor corresponding to the extraction type data, the extraction type data is obtained from the extraction type container. Based on the correspondence between multiple sets of extractors and extraction type data, the extractor corresponding to the extraction type data is determined from a pre-configured pool of extractors. For example, based on a first mapping relationship, the extractor corresponding to the extraction type data is determined from a pre-configured pool of extractors; where the first mapping relationship characterizes the correspondence between multiple extractors and extraction type data. Specifically, the extractors include various types such as regular expression-based extractors, XML-based extractors, and JSON Path-based extractors.

[0053] Step S150: Determine the assertor corresponding to the assertion type data, generate assertion results corresponding to the valid data information through the assertor, and determine the test results of the interface to be tested based on the assertion results; the test results are used to characterize whether there are any abnormalities in the functionality of the interface to be tested.

[0054] The assertion type data is used to characterize the type of assertion. Accordingly, when determining the assertion corresponding to the assertion type data, the assertion type data is retrieved from the assertion type container. Based on the correspondence between multiple sets of assertions and assertion type data, the assertion corresponding to the assertion type data is determined from a pre-configured pool of assertions. For example, based on a second mapping relationship, the assertion corresponding to the assertion type data is determined from a pre-configured pool of assertions; where the second mapping relationship characterizes the correspondence between multiple assertions and assertion type data. Specifically, the assertions include various types such as assertions based on regular expressions, assertions based on XML format, and assertions based on JSON Path.

[0055] In addition, to facilitate users' flexible configuration of global variables used during testing, a variable type container can be set up to store global variable data. Correspondingly, the interface test data also includes: global variable data; when receiving user-inputted interface test data, the global variable type data contained in the interface test data is further received through the variable type input entry in the test interface, and the global variable type data is stored in the variable type container; wherein, the global variable type data contained in the interface test data is used to represent the global variables required during the interface testing process. Thus, by calling the variable class call template, the global variable type data contained in the user-input interface test data is received, and the global variable type data is stored in the variable type container; the global variable type data is input by the user through the variable type input entry in the test interface of the interface testing tool. The global variable type data contained in the interface test data is used to represent the mapping relationship between global variables and placeholders required during the interface testing process. Placeholders are symbols in code that correspond to local variables. A placeholder can be understood as a symbol that places a space in a variable's space. Common placeholders include integer placeholders (%d), floating-point placeholders (%f), string placeholders (%s), and hexadecimal integer placeholders (%x). Different types of placeholders correspond to different global variables; for example, integer placeholders correspond to integer-type global variables, and floating-point placeholders correspond to floating-point-type global variables.

[0056] During program execution, placeholders need to be replaced with specified global variables. Correspondingly, the global variable type data records the mapping relationship between global variables and placeholders required during interface testing, so that replacement can be performed conveniently and quickly in subsequent processes.

[0057] Accordingly, when extracting valid data information from the access result data using the extractor, if the code segment corresponding to the extractor includes a first placeholder, the first global variable corresponding to the first placeholder is retrieved from the variable type container, and the first placeholder is replaced by the first global variable to obtain the replaced code segment corresponding to the extractor. The replaced code segment corresponding to the extractor is then run, and the valid data information contained in the access result data is extracted based on the running result. The first placeholder is usually corresponding to the first global variable.

[0058] Similarly, when generating assertion results corresponding to valid data information through the assertioner, if the code segment corresponding to the assertioner includes a second placeholder, the second global variable corresponding to the second placeholder is obtained from the variable type container, and the second placeholder is replaced by the second global variable to obtain the replaced code segment corresponding to the assertioner; the replaced code segment corresponding to the assertioner is run, and the assertion result corresponding to the valid data information is generated based on the running result. The second placeholder is usually corresponding to a second local variable. It should be noted that the first placeholder and the second placeholder are two common types of placeholders in code programs, and the specific placeholder can be set according to actual needs; this application embodiment does not limit this.

[0059] Therefore, this method allows users to directly input interface test data through data call templates set in the interface testing tool. Specifically, users can input request type data through request class call templates, extraction type data through extraction class call templates, and assertion type data through assertion class call templates. In short, by setting multiple data call templates corresponding to different data types, users can conveniently and quickly input various types of data required during the testing process. This method automatically encapsulates and sends corresponding request data messages based on the user-input interface test data, and automatically determines the corresponding extractor based on the extraction type data to extract valid data information contained in the access result data. Furthermore, it automatically determines the corresponding assertor based on the assertion type data to generate assertion results corresponding to the valid data information. In conclusion, this method only requires users to input the necessary interface test data for the testing process, and the subsequent test steps are automatically implemented through a pre-configured test flow. This significantly reduces the amount of code writing, avoids errors that may occur during manual coding, and improves the accuracy of the tests. In addition, the number, types, and input data specifications of the data input interfaces included in each type of data call template are pre-set according to the characteristics of the corresponding data type. Therefore, it can speed up data input efficiency and reduce data error rate.

[0060] To facilitate understanding, the following example will be used to explain in detail the implementation details of the interface testing method in this application:

[0061] Current testing trends necessitate both manual and automated methods to assist in regression testing. Interface automation is one such method. However, most testers lack the skills to write automation code. Faced with numerous API calls across various scenarios, testers are forced to write extensive and complex code (involving data assembly, request sending, result extraction, assertions, logging, etc.), making automation tasks difficult for many. Even for those with coding skills, differences in coding habits can lead to code clutter, poor management, and maintenance difficulties. Therefore, a framework integrating all the necessary API automation functionalities is needed to address these issues. This framework would eliminate the need for testers to write extensive low-level code; they could simply input the required API data according to the framework's template rules to complete the task. Furthermore, it would standardize API call rules and facilitate code submission management.

[0062] In related technologies, the requests code from a third-party library is used to implement API requests. When sending request messages, users need to assemble messages and request headers according to different API request types. Furthermore, when extracting results, different extraction methods need to be written for each returned result. Moreover, when asserting results, different assertion logic methods need to be written based on the assertion logic, such as greater than, less than, equal to, and inclusive. Additionally, developers need to write logging code to trace the API request and response. In this approach, API automation developers need to assemble and send various API request messages, extract data, process data, implement various assertion logics, and perform log tracing, requiring a significant amount of time to complete the underlying code implementation. This presents a high level of difficulty for testers, hindering the progress of automation. Furthermore, for collaborative development projects, the lack of unified coding and calling standards can easily lead to a chaotic and disorganized API project, increasing later maintenance costs.

[0063] To address the aforementioned issues, this example provides a simple, easy-to-use, and fully functional API automation development tool and its implementation method. It offers various API request methods, result extraction methods, and result logic processing methods required for API automation development. API test case developers only need to load the API-related data into the implemented API testing tool according to the template specifications. This tool will then handle all API development tasks: the framework first categorizes and stores all parameters for the request to be sent, as well as the assertions and extracted data required after sending the request. Then, it assembles the API data, sends the request, extracts the response content and assertions, and records the entire request-response log for users to track issues. This simplifies the cost of user API automation development, enables rapid API automation development, and achieves unified and standardized processes. Figure 2 A detailed flowchart of this example is shown.

[0064] In practice, firstly, call templates are defined for users to input data of different types and purposes, allowing users to select the appropriate template to populate the data according to their needs. Then, the program is started, and according to the user template rules, interface request data (i.e., request type data) is placed into the specified request type container. Global variables are placed into the specified global variable data container (i.e., variable type container) according to the user template rules. Assertion type data is placed into the specified assertion type container according to the user template rules. Extraction type data is placed into the specified extraction type container according to the user template rules.

[0065] Next, the parameters of the request type container are assembled: the request header and request content format are automatically encapsulated according to the request type, all data in the container are replaced with global variable parameters according to placeholders, and the execution results are replaced according to the method mapping list.

[0066] Assemble the parameters of the extracted type container: replace all data in the container with global variable parameters based on placeholders, and replace them with the execution results based on the method mapping list.

[0067] Assemble the parameters of the assertion type container: replace all data in the container with global variable parameters based on placeholders, and replace them with the execution results based on the method mapping list.

[0068] Then, all data in the request type container is converted into a dictionary and passed through to requests to send the request. After sending the request, the request's response result object is encapsulated, and key information in the response is extracted: response code, response content, cookies, and request headers. Based on the configured extraction type container, the corresponding extractor is selected, and content is extracted from the encapsulated response result object (i.e., access result data) using this extractor. The extracted data is then stored in a specified location (e.g., a global variable). Based on the configured assertion type container, the corresponding assertor is selected, and assertions are performed on the encapsulated response result object using this assertor. After the above process is completed, the entire interface request process is finished, and a result set is returned to store information such as the interface's global variables and Session objects.

[0069] The specific details of the above process are described below:

[0070] First, define call templates for users to pass in data of different types and purposes. Then, the interface requests data, and the user's request data is placed into the instance variable of the HttpReuqst class. The data template is defined as shown in Table 1:

[0071] Table 1

[0072]

[0073] Global variable mapping: Global variables are added by calling the VarMapping method, the parent class of HttpReuqst. These can be used to define public variables and assign values. The data template definition is shown in Table 2.

[0074] Table 2

[0075] Method parameters illustrate name global variable name value global variable value

[0076] Method mapping list: A method mapping list can be added by calling the method of VarMapping, the parent class of HttpReuqst. Methods in the method mapping list can be called in the interface data based on specific string expressions for special processing.

[0077] Assertion type data: Assertions are added by calling methods of JmesValidator, the parent class of HttpReuqst. The data template definition is shown in Table 3.

[0078] Table 3

[0079] Instance variables illustrate type Types of assertions expr Expressions for extracting response data expected_value Expected value message Assertion failure information is_throw Does the assertion fail and throw an exception?

[0080] Extract type data: Add extract type data by calling the method of JmesExtractor, the parent class of HttpReuqst. The data template definition is shown in Table 4.

[0081] Table 4

[0082] Instance variables illustrate type Extractor type var_name Name of the data type to be extracted expr Expressions for extracting response result data

[0083] Users select the corresponding template to populate data according to their needs, that is, calling different class methods to write data according to the template definition. After the program starts, that is, after the program runs, the subsequent data classification, storage and assembly begin. Specifically, according to the user template rules, the interface request data is placed into the specified request data template (also called the request type container). That is, after receiving the interface request data (i.e., interface test data) passed by the user, it is stored in the HttpReuqst instance variable request object. According to the user template rules, global variables are placed into the specified global variable data container. That is, after receiving multiple global variable data passed by the user, they are stored in the instance variable dictionary of the HttpReuqst parent class VarMapping.

[0084] Then, according to the user template rules, the assertion data is placed into the specified assertion type container. That is, after receiving multiple assertion data from the user, it is stored in the instance variable collection dictionary of the HttpReuqst parent class JmesValidator. Similarly, according to the user template rules, the extraction type data is placed into the specified extraction data container. That is, after receiving multiple extraction data from the user, it is stored in the instance variable dictionary of the HttpReuqst parent class JmesExtractor.

[0085] Next, the request container parameters are assembled: request headers and content formats are automatically encapsulated based on the request type. All data within the container is replaced with global variable parameters based on placeholders, and the execution results are replaced based on the method mapping list. In other words, the stored request interface data is extracted from the `request` instance and processed into the request data required by the Python third-party library `requests`. The seven data items—url, method, cookies, timeout, allow_redirects, verify, and params—are directly passed to `requests`. Request headers: If the user uses the `upload` field in `Request`, the request header is set to `multipart / form-data` type. Other request headers are automatically set internally by `requests` (based on the `data` and `json` fields). Request body data: If the user uses the `upload` field in `Request` to pass request body data, it means the interface data type is `Content-Type = multipart / form-data`. The complex data format definition for file upload parameters is simplified. The standard format requires filename, file type, and file path; now only the filename is needed. If the passed data is a dictionary type, it is automatically converted to a `MultipartEncoder` object. If the user passes request body data using the JSON field in the Request object, it is directly passed to the Python third-party library requests. Cookies: The HttpRequest response object stores the requests session and passes it to the next API call; this is how cookies are passed.

[0086] Next, the parameters of the extracted type container are assembled: all data in the container is replaced with global variable parameters based on placeholders, and also with the results of execution based on the method mapping list. That is: the extracted data stored above is extracted from the Validator extractor instance, the entire data is traversed for global variable parameter replacement and replacement based on the results of execution based on the method mapping list, and then it is passed to the HttpResponse response object.

[0087] Assemble the parameters of the assertion type container: Replace all data in the container with global variable parameters based on placeholders, and replace them with the execution results based on the method mapping list. That is: extract the above-stored assertion data from the Assertor instance, traverse the entire data to replace global variable parameters and the execution results of the method mapping list, and wait to pass it to the HttpResponse response object.

[0088] Convert all data in the request type container into a dictionary and pass it through to the requests object. That is, convert the assembled request interface parameters into a dictionary and pass it to requests to send the request. When calling the third-party library requests to send the request, if a Session object from the previous interface exists, use that Session object directly to send the request.

[0089] The response result object of requests is encapsulated, and key information in the response is extracted: response code, response content, cookies, and request headers. Specifically, after sending the request, the following key information is extracted from the original Response object and stored in a dictionary-like variable. This dictionary-like variable is then encapsulated together with the original Response object into a new HttpResponse object. This facilitates subsequent data extraction and assertions via dictionary path searching. The extracted response content is shown in Table 5.

[0090] Table 5

[0091] Parameter name illustrate status_code Response code headers Response header cookies Cookies body Response content

[0092] Record detailed request and response logs. Select the corresponding extractor based on the configured extraction type container, and extract content from the encapsulated response result object using that extractor. Store the extracted data in a global variable. Specifically: First, pass the assembled extracted data as a parameter to the extraction method of the HttpResponse object. Internally, the method finds the corresponding extractor based on the user-input extraction method, performs extraction based on the response content encapsulated in the HttpResponse, and returns all extracted data as a dictionary. The built-in extractors are shown in Table 6 below:

[0093] Table 6

[0094]

[0095]

[0096] Then, set the extracted results into a global variable.

[0097] Finally, the corresponding assertion is selected based on the configured assertion type container, and the extracted results are asserted based on this assertion. That is, the assembled assertion data is passed as a parameter to the assertion method of the HttpResponse object. Internally, the method finds the corresponding assertion based on the user-input assertion method, and performs assertions based on the response content encapsulated by the HttpResponse. If the assertion data "is_throw" is true, an exception is thrown directly if the assertion fails; otherwise, a detailed log of the assertion failure is recorded. The built-in assertions are shown in Table 7.

[0098] Table 7

[0099] assertion name illustrate Regular assertion Assertions based on regular expressions XML assertion Assertions based on XPath Jmes assertion Assertions based on JSON Path Global Variable Assertion Assertions based on global variable values

[0100] API request post-processing: After the above process is completed, the entire API request process is finished. Finally, a result set will be returned to store the API's global variables and Session objects.

[0101] If the assertion succeeds, post-processing is executed; otherwise, the program is interrupted. The data returned by post-processing is mainly used for information exchange between multiple interfaces. The return results are shown in Table 8.

[0102] Table 8

[0103] Returned data illustrate response Encapsulated response HttpResponse object session Requests' Session object var_mapping global variables

[0104] For example, taking the exemption application interface as an example, the interface information captured is shown in Table 9:

[0105] Table 9

[0106]

[0107]

[0108] Users define their API based on the interface template and pass in the interface data sequentially through the following method calls. The following is a detailed explanation of the user-called methods: The relevant parameters for the interface request are assigned values ​​in the `request` variable of the `HttpRequest` class: the `url` field is assigned the current request address + request path; `method` is the current request method; since the current request's `Content-Type` is "multipart / form-data", the current request's `body` data is assigned to the `upload` field; the relevant parameters for global variables are set by calling the `add_variable` method. Taking "baseUrl" as an example: in this method, the actual URL address is assigned to the variable "baseUrl". In the diagram, the first parameter passed is `baseUrl`, and the second parameter is its assigned value. The `transfer_session` method is used to receive the Session object of user-generated requests. Because this interface can only be called after the user logs in, the user needs to call the `transfer_session` method to pass user cookies. The response data is extracted by calling the "extract" method. Since the target data is the response data, the first parameter is the extractor type "Jmes", the second parameter is the expression for the extracted content "body.data", and the third parameter is the variable to store it. Asserting the response result is done by calling the "assert_equals" method. Since the target success value is to be "true", the first parameter is the assertion type "jmes", the second parameter is the assertion expression "body.success", and the third parameter is the expected value of the assertion, True. After these methods are called, the interface data is categorized and stored.Interface request data is stored in the `request` instance variable of `HttpReuqst`. Global variables are stored in the instance variable dictionary of the `VarMapping` parent class of `HttpReuqst`. Taking `baseUrl` as an example, the stored data is represented as `{"baseUrl": "http: / / ljgcolo-famrd-citest3-8080.msxfcloud.test"}`. Extracted type data is stored in the instance variable dictionary of the `Extractor` parent class of `HttpReuqst`. Taking the extracted `data` data from the response content as an example, the stored data is represented as `{"data": "body.data"}`. Assertion type data is stored in the instance variable collection dictionary of the `Validator` parent class of `HttpReuqst`. Taking the assertion that the response content `success` is "true" as an example, the stored data is represented as `{'jmes':[{'equal':['status_code',200,'Interface request failed'],'is_throw':False}]}`, where "'equal'" represents the method alias of the assertion mapping, used to obtain the assertion method. When the "do_request" method is called, the API data is assembled. During the assembly of the request API parameters, placeholders in the parameter URL are first replaced with the actual values ​​of global variables. That is, "$baseUrl / gcoll / d / internalExemption / saveExemptionApply" is replaced with "http: / / ljgcolo-famrd-citest3-8080.msxfcloud.test".

[0109] ` / gcoll / d / internalExemption / saveExemptionApply`. The request body data is encapsulated into a `MultipartEncoder` object, and the `files` parameter becomes the filename, file type, and file path. The assembly of extracted type data iterates through the entire data, replacing global variable parameters and the execution results of the method mapping list, equivalent to placeholder replacement in the URL. Asserting the assembly of type data is equivalent to the assembly of the extracted data described above. Taking the extracted data as an example, the extractor selects the Jmes extractor based on the extractor type, extracts the data "PH7Nbmdg1I7LSNN70" from the response content encapsulated in the above `HttpResponse` using the expression "body.data", and assigns it to the variable `applyId`. The assertor uses the asserted data `{'jmes':[{'equal'`. For example, in the code `['body.success','true','API request failed'],'is_throw':False}]`, firstly, 'jmes' indicates the type of assertion. Since there may be multiple assertion data sets, a list is used to store the data. In the data, 'equal' represents the method alias of the assertion mapping, 'body.success' indicates that the data extracted from the response content encapsulated by the above `HttpResponse` is "true". 'true' in the assertion data represents the expected assertion value, and 'is_throw' being False indicates that no exception is thrown if the assertion fails. After calling the `do_request` method, an `HttpResponse` object is returned, which stores the requests' Session object, the original response object, the assertion result set, and the encapsulated response content. This object is used for concatenating multiple APIs.

[0110] In summary, the interface automation tool in this example integrates the functionality of the entire interface request process. Users only need to load the interface-related data into the tool according to the template specifications defined by the framework, and the tool will complete all the tasks of interface development for them: the framework first classifies and stores all the parameters that need to be sent for the request, as well as the assertions and extracted data required after sending the request, and then extracts the stored data to complete the assembly of interface request parameters, extracted result data, assertion data, etc., and then sends the interface request, extracts response fields and stores and transmits them, and performs special data processing, assertions, and logging.

[0111] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0112] In addition, this disclosure also provides an interface testing apparatus, an electronic device, and a computer-readable storage medium, all of which can be used to implement any of the interface testing methods provided in this disclosure. The corresponding technical solutions and descriptions are described in the relevant section of the method and will not be repeated here.

[0113] Figure 3 A block diagram of an interface testing device provided in this disclosure embodiment.

[0114] Reference Figure 3 This disclosure provides an interface testing apparatus 20, which includes:

[0115] The receiving module 21 is adapted to receive interface test data input by the user through a data call template set in the interface testing tool; wherein, the data call template includes: a request class call template, an extraction class call template and an assertion class call template, and the interface test data includes: request type data received through the request class call template, extraction type data received through the extraction class call template and assertion type data received through the assertion class call template;

[0116] The sending module 22 is adapted to generate and send a request data message according to the request object and request method contained in the request type data; wherein, the request data message is used to call the interface to be tested, so that the interface to be tested accesses the request object according to the request method and obtains access result data.

[0117] The acquisition module 23 is adapted to acquire the access result data obtained from the access to the interface to be tested;

[0118] Extraction module 24 is adapted to determine an extractor corresponding to the extracted data type, and to extract valid data information contained in the access result data through the extractor;

[0119] The assertion module 25 is adapted to determine the assertion corresponding to the assertion type data, generate an assertion result corresponding to the valid data information through the assertion, and determine the test result of the interface to be tested based on the assertion result; the test result is used to characterize whether there is an anomaly in the function of the interface to be tested.

[0120] Optionally, the receiving module is specifically adapted to:

[0121] The request class calls the template to receive request type data input by the user, wherein the request type data is input by the user through the request type input entry included in the test interface of the interface testing tool;

[0122] The extraction class call template receives extraction type data input by the user, where the extraction type data is input by the user through the extraction type input entry included in the test interface of the interface testing tool;

[0123] The assertion class call template receives assertion type data input by the user, which is input by the user through the assertion type input entry included in the test interface of the interface testing tool.

[0124] Optionally, the receiving module is further adapted to: store the request type data in a request type container;

[0125] After receiving the extraction type data input by the user, the method further includes: storing the extraction type data in an extraction type container;

[0126] After receiving the assertion type data input by the user, the method further includes storing the assertion type data in an assertion type container.

[0127] Optionally, the sending module is specifically adapted to:

[0128] Retrieve the request object and request method contained in the request type data from the request type container;

[0129] Based on the requested object and the request method, the corresponding message request header and message data content are encapsulated.

[0130] The message request header and the message data content are assembled into a request data message.

[0131] Optionally, the extraction module is specifically adapted to:

[0132] Obtain the extraction type data from the extraction type container;

[0133] Based on the correspondence between multiple sets of extractors and extraction type data, the extractor corresponding to the extraction type data is determined from a pre-configured set of extractors;

[0134] The assertion module is specifically suitable for:

[0135] Obtain the assertion type data from the assertion type container;

[0136] Based on the correspondence between multiple sets of assertions and assertion type data, the assertion corresponding to the assertion type data is determined from a pre-configured set of assertions.

[0137] Optionally, the interface test data further includes: global variable data; the receiving module is also adapted to:

[0138] The variable class call template receives global variable type data contained in the interface test data input by the user, and stores the global variable type data in the variable type container; the global variable type data is input by the user through the variable type input entry contained in the test interface of the interface testing tool;

[0139] The global variable type data included in the interface test data is used to characterize the mapping relationship between global variables and placeholders required during the interface testing process.

[0140] Optionally, the extraction module is specifically adapted to:

[0141] If the code segment corresponding to the extractor includes a first placeholder, then the first global variable corresponding to the first placeholder is obtained from the variable type container, and the first placeholder is replaced by the first global variable to obtain the replaced code segment corresponding to the extractor.

[0142] Run the replaced code segment corresponding to the extractor, and extract the valid data information contained in the access result data based on the running results; and / or,

[0143] The step of generating an assertion result corresponding to the valid data information through the assertioner includes:

[0144] If the code segment corresponding to the assertion includes a second placeholder, a second global variable corresponding to the second placeholder is obtained from the variable type container, and the second placeholder is replaced by the second global variable to obtain the replaced code segment corresponding to the assertion.

[0145] Run the replaced code segment corresponding to the assertion, and generate an assertion result corresponding to the valid data information based on the running result.

[0146] Therefore, this interface testing device allows users to directly input interface test data using data call templates set within the interface testing tool. Specifically, users can input request type data via request class templates, extraction type data via extraction class templates, and assertion type data via assertion class templates. In short, by setting multiple data call templates corresponding to different data types, users can conveniently and quickly input various types of data required during the testing process. This method automatically encapsulates and sends corresponding request data messages based on the user-input interface test data, and automatically determines the corresponding extractor based on the extraction type data to extract valid data information contained in the access result data. Furthermore, it automatically determines the corresponding assertor based on the assertion type data to generate assertion results corresponding to the valid data information. In conclusion, this method only requires users to input the necessary interface test data, and the pre-configured test process automatically completes subsequent test steps, significantly reducing the amount of code writing and avoiding errors that may occur during manual coding, thus improving test accuracy. In addition, the number, types, and input data specifications of the data input interfaces included in each type of data call template are pre-set according to the characteristics of the corresponding data type. Therefore, it can speed up data input efficiency and reduce data error rate.

[0147] Figure 4 This is a block diagram of an electronic device provided in an embodiment of the present disclosure.

[0148] Reference Figure 4 This disclosure provides an electronic device, which includes: at least one processor 501; at least one memory 502; and one or more I / O interfaces 503 connected between the processor 501 and the memory 502; wherein the memory 502 stores one or more computer programs that can be executed by the at least one processor 501, and the one or more computer programs are executed by the at least one processor 501 to perform the interface testing method described above.

[0149] This disclosure also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor / processor core, implements the interface testing method described above. The computer-readable storage medium may be volatile or non-volatile.

[0150] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device executes the above-described interface testing method.

[0151] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0152] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable program instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0153] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0154] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0155] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0156] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0157] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0158] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0159] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0160] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. An interface testing method, characterized in that, include: The interface testing tool receives user-inputted interface test data through data call templates corresponding to different data types set in the interface testing tool; wherein, the data call templates include: request class call template, extraction class call template and assertion class call template, and the interface test data includes: request type data received through request class call template, extraction type data received through extraction class call template and assertion type data received through assertion class call template; Based on the request object and request method contained in the request type data, a request data message is generated and sent; wherein, the request data message is used to call the interface to be tested, so that the interface to be tested accesses the request object according to the request method and obtains access result data. Obtain the access result data obtained from accessing the interface to be tested; Determine the extractor corresponding to the extracted data type, and extract the valid data information contained in the access result data using the extractor; An assertion corresponding to the assertion type data is determined, and an assertion result corresponding to the valid data information is generated through the assertion, and the test result of the interface to be tested is determined based on the assertion result; the test result is used to characterize whether there is an anomaly in the function of the interface to be tested.

2. The method according to claim 1, characterized in that, The process of receiving user-inputted interface test data through a data call template set in the interface testing tool includes: The request class calls the template to receive request type data input by the user, wherein the request type data is input by the user through the request type input entry included in the test interface of the interface testing tool; The extraction class call template receives extraction type data input by the user, where the extraction type data is input by the user through the extraction type input entry included in the test interface of the interface testing tool; The assertion class call template receives assertion type data input by the user, which is input by the user through the assertion type input entry included in the test interface of the interface testing tool.

3. The method according to claim 2, characterized in that, After receiving the request type data input by the user, the method further includes: storing the request type data in a request type container; After receiving the extraction type data input by the user, the method further includes: storing the extraction type data in an extraction type container; After receiving the assertion type data input by the user, the method further includes storing the assertion type data in an assertion type container.

4. The method according to claim 3, characterized in that, The step of generating and sending a request data message based on the request object and request method contained in the request type data includes: Retrieve the request object and request method contained in the request type data from the request type container; Based on the requested object and the request method, the corresponding message request header and message data content are encapsulated. The message request header and the message data content are assembled into a request data message.

5. The method according to claim 3, characterized in that, The step of determining the extractor corresponding to the extracted data type includes: Obtain the extraction type data from the extraction type container; Based on the correspondence between multiple sets of extractors and extraction type data, the extractor corresponding to the extraction type data is determined from a pre-configured set of extractors; The step of determining the assertion corresponding to the assertion type data includes: Obtain the assertion type data from the assertion type container; Based on the correspondence between multiple sets of assertions and assertion type data, the assertion corresponding to the assertion type data is determined from a pre-configured set of assertions.

6. The method according to any one of claims 1-5, characterized in that, The interface test data also includes: global variable data; the method also includes: The variable class call template receives global variable type data contained in the interface test data input by the user, and stores the global variable type data in the variable type container; the global variable type data is input by the user through the variable type input entry contained in the test interface of the interface testing tool; The global variable type data included in the interface test data is used to characterize the mapping relationship between global variables and placeholders required during the interface testing process.

7. The method according to claim 6, characterized in that, The step of extracting valid data information contained in the access result data through the extractor includes: If the code segment corresponding to the extractor includes a first placeholder, then the first global variable corresponding to the first placeholder is obtained from the variable type container, and the first placeholder is replaced by the first global variable to obtain the replaced code segment corresponding to the extractor. Run the replaced code segment corresponding to the extractor, and extract the valid data information contained in the access result data based on the running results; and / or, The step of generating an assertion result corresponding to the valid data information through the assertioner includes: If the code segment corresponding to the assertion includes a second placeholder, a second global variable corresponding to the second placeholder is obtained from the variable type container, and the second placeholder is replaced by the second global variable to obtain the replaced code segment corresponding to the assertion. Run the replaced code segment corresponding to the assertion, and generate an assertion result corresponding to the valid data information based on the running result.

8. An interface testing device, characterized in that, include: The receiving module is adapted to receive interface test data input by the user through data call templates corresponding to different data types set in the interface testing tool; wherein, the data call templates include: request class call template, extraction class call template and assertion class call template, and the interface test data includes: request type data received through request class call template, extraction type data received through extraction class call template and assertion type data received through assertion class call template; The sending module is adapted to generate and send a request data message based on the request object and request method contained in the request type data; wherein, the request data message is used to call the interface to be tested, so that the interface to be tested accesses the request object according to the request method and obtains access result data; The acquisition module is adapted to acquire the access result data obtained from accessing the interface to be tested; An extraction module is adapted to determine an extractor corresponding to the data of the extraction type, and to extract valid data information contained in the access result data through the extractor. An assertion module is adapted to determine an assertor corresponding to the assertion type data, generate an assertion result corresponding to the valid data information through the assertor, and determine the test result of the interface to be tested based on the assertion result; the test result is used to characterize whether there is an anomaly in the function of the interface to be tested.

9. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores one or more computer programs that can be executed by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program, when executed by a processor, implements the method as described in any one of claims 1-7.

Images