API-Based Dynamic Test Case Generation Method, Device, Equipment, and Medium

Abstract

The present invention provides a method, apparatus, device, and medium for dynamically generating test cases based on APIs. The method includes: constructing a target URL based on multiple target parameters of a target API, and after obtaining response JSON data from the target API, calling a recursive function to traverse interface fields and field paths; constructing a verification variable based on any interface field, the corresponding field path, and target verification information; and inputting the target parameters and the verification variable into a test case template based on the selected target field to generate an interface test case for the target API. According to the technical solution of the embodiments of the present invention, it is possible to automatically construct a target URL carrying target parameters, automatically obtain feed response JSON data by interacting with the target API, and automatically obtain interface fields by using a recursive function for data parsing, improving the efficiency of field acquisition; after determining the target field, automatically construct a verification variable, and then automatically generate an interface test case in combination with the test case template, improving the generation efficiency of the test case.

Description

Technical Field

[0001] The present invention relates to the technical field of interface testing, and particularly relates to a method, device, equipment and medium for dynamically generating test cases based on APIs. Background Art

[0002] In the process of software development, the testing of application programming interfaces (APIs) is an important link to ensure the system function and performance. Traditional API testing often requires manually writing test cases and designing verification logics one by one according to the response data of the APIs, and the writing efficiency of test cases is relatively low.

[0003] In some related technologies, some systems for automatically generating test cases are proposed. After inputting the interface fields and response rules of the input API into the case template, test cases are automatically generated. However, testers still need to manually screen out target fields from the historical interaction data of the API or the code of the API. The number of target fields is very large, and some target fields will also be newly added when the API is updated. In the case of a large number of test cases, testers need to spend a lot of time collecting target fields and updating test cases, which affects the generation efficiency of test cases. Summary of the Invention

[0004] The present invention aims to at least solve one of the technical problems existing in the prior art. For this purpose, the present invention provides a method, device, equipment and medium for dynamically generating test cases based on APIs, which can automatically obtain response data based on the interaction with the API, and dynamically construct test cases based on the response data, thereby improving the generation efficiency of test cases.

[0005] In a first aspect, an embodiment of the present invention provides a method for dynamically generating test cases based on APIs, which is applied to a test platform. The test platform is preset with a plurality of candidate fields. The method includes:

[0006] In response to a user selecting a target API from an API list on a test interface, constructing a target URL based on a plurality of target parameters of the target API, and obtaining response JSON data from the target API based on the target URL, where the API list includes a plurality of preset candidate APIs;

[0007] Traversing data nodes of the response JSON data based on a preset recursive function, and based on any traversed target node, determining the recursive path as the field path of the traversed interface field. When the target node includes child nodes, adding the node paths of the child nodes to the recursive path and then recursively calling the target node, or when the target node does not include the child nodes, clearing the recursive path and then recursively calling the response JSON data;

[0008] Construct a verification variable for the interface field based on the field path and the target verification information, where the target verification information includes the previously set or default data comparison rule, data type, and expected value;

[0009] In the field list constructed on the test interface, display each interface field and its corresponding verification variable, and determine the selected interface field as the target field;

[0010] Input the target parameter corresponding to the target field and the verification variable into a preset test case template to generate an interface test case for the target API.

[0011] According to some embodiments of the present invention, the test platform presets preset request headers for each candidate API, and the preset request headers carry a preset authentication token, and the preset authentication token is used to verify the legality of the corresponding candidate API; construct a target URL based on multiple target parameters of the target API, and obtain response JSON data from the target API based on the target URL, including:

[0012] Convert each target parameter into a target string, obtain a preset reference URL, and write each target string into the query parameter of the reference URL to obtain the target URL;

[0013] Obtain the target request header of the target API, and construct a first HTTP request based on the target URL and the target request header, where the first HTTP request is a GET request or a POST request;

[0014] Send the first HTTP request to the target API so that the target API feeds back the response JSON data based on each target string.

[0015] According to some embodiments of the present invention, the test platform records self-description information for each candidate API, and the content corresponding to the self-description information in the candidate API is all interface parameters of the corresponding candidate API;

[0016] Before sending the first HTTP request to the target API, the method further includes:

[0017] Obtain the self-description information of the target API, convert the self-description information of the target API into the target string and write it into the target URL;

[0018] Construct a field list on the test interface, including:

[0019] When traversing the self-description information of the target API in the response JSON data based on the recursive function, do not determine the self-description information of the target API as the interface field, and extract all the interface parameters from the response JSON data;

[0020] Generate the field list based on the comparison result between the target parameter and the interface parameter.

[0021] According to some embodiments of the present invention, generating the field list based on the comparison result between the target parameter and the interface parameter includes:

[0022] When the target parameter and the interface parameter are exactly matched, generate the field list based on the target parameter;

[0023] Or, when at least one of the target parameters does not match the interface parameter, generate an exception prompt message on the test interface, and generate the field list based on each target parameter that matches the interface parameter, where the exception prompt message records the target parameter that does not match the interface parameter;

[0024] Or, when at least one candidate parameter is determined, generate a first option and a second option on the test interface, where the candidate parameter is an interface parameter that does not belong to the target parameter;

[0025] When the first option is selected, generate the field list based on the target parameter;

[0026] Or, when the second option is selected, generate a second HTTP request based on the candidate parameter and the reference URL, obtain new response JSON data from the target API based on the second HTTP request, obtain supplementary fields and corresponding field paths from the new response JSON data based on the recursive function, and construct the field list based on the interface field and the supplementary fields.

[0027] According to some embodiments of the present invention, the test platform is connected to multiple optional systems, and each optional system is associated with multiple candidate APIs. Inputting the target parameter corresponding to the target field and the verification variable into a preset test case template to generate an interface test case for the target API includes:

[0028] Determine the target parameter corresponding to the target field as the use case parameter, and construct a use case URL based on the use case parameter and the reference URL;

[0029] Construct a use case name based on the selected target system, the target API, the target parameter, and the target field;

[0030] Write the use case name, the use case URL, and the target parameters into the test case template, and construct test logic statements of the test case template based on each of the verification variables to obtain the interface test case;

[0031] Associate the interface test case with the corresponding target system based on the use case name.

[0032] According to some embodiments of the present invention, after associating the interface test case with the corresponding target system based on the use case name, the method further includes:

[0033] Obtain API update information from the system update information of any target system, where the API update information records at least one updated API;

[0034] When the updated API includes at least one newly added candidate field and the updated API includes a full-field test case, obtain updated response JSON data from the updated API based on the use case URL of the full-field test case, determine the field address of the candidate field from the updated response JSON data according to the recursive function, and construct a newly added verification variable corresponding to the candidate field. Construct a new test case based on the newly added verification variable and the full-field test case, and retain the full-field test case, where the full-field test case is an interface test case including each candidate field;

[0035] When the updated API includes at least one deleted candidate field, determine associated test cases from all interface test cases of the updated API based on the deleted candidate field, and remove the verification variable corresponding to the deleted candidate field in the associated test cases;

[0036] When the updated API is a newly added API and an associated API is determined in the API list based on a user operation, copy all interface test cases of the associated API to the updated API, and update each interface test case based on the name of the updated API and the name of the target system;

[0037] When the updated API is a deleted API, delete all interface test cases corresponding to the updated API.

[0038] According to some embodiments of the present invention, traverse data nodes of the response JSON data based on a preset recursive function, and based on any traversed target node, determine the field path of the traversed interface field, including:

[0039] Construct the recursive path in the recursive function, and determine the response JSON data as the recursive call object of the recursive function, where the initial value of the recursive path is empty;

[0040] Whenever a target node is traversed, write the node path of the target node into the recursive path, extract data from the target node using each candidate field as the extraction index. When the interface field is successfully extracted, determine the current recursive path as the field path of the interface field;

[0041] When the target node does not include child nodes, clear the recursive path and determine the response JSON data as the next recursive call object;

[0042] When the target node includes child nodes, add the node path of the child nodes to the recursive path and determine the target node as the next recursive call object of the recursive function.

[0043] In a second aspect, an embodiment of the present invention provides a dynamic test case generation device based on API, including at least one control processor and a memory communicatively connected to the at least one control processor; the memory stores instructions executable by the at least one control processor, and when the instructions are executed by the at least one control processor, the at least one control processor is enabled to execute the dynamic test case generation method based on API as described in the first aspect above.

[0044] In a third aspect, an embodiment of the present invention provides an electronic device, including the dynamic test case generation device based on API as described in the second aspect above.

[0045] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium storing computer-executable instructions for executing the dynamic test case generation method based on API as described in the first aspect above.

[0046] The method for dynamically generating test cases based on API according to the embodiments of the present invention has at least the following beneficial effects: in response to a user selecting a target API from an API list on a test interface, a target URL is constructed based on multiple target parameters of the target API, and response JSON data is obtained from the target API based on the target URL, where the API list includes multiple preset candidate APIs; a preset recursive function is used to traverse data nodes of the response JSON data, and based on any traversed target node, the recursive path is determined as the field path of the traversed interface field. When the target node includes child nodes, the node path of the child nodes is added to the recursive path and then the target node is recursively called, or when the target node does not include the child nodes, the recursive path is cleared and then the response JSON data is recursively called; a verification variable for the interface field is constructed based on the field path and target verification information, where the target verification information includes data comparison rules, data types, and expected values that were set or defaulted last time; each interface field and its corresponding verification variable are displayed in a field list constructed on the test interface, and the selected interface field is determined as the target field; the target parameters and the verification variable corresponding to the target field are input into a preset test case template to generate an interface test case for the target API. According to the technical solution of the embodiments of the present invention, a target URL carrying target parameters can be automatically constructed, response JSON data can be automatically obtained through interaction with the target API, and the field paths of each target field can be obtained through data parsing using a recursive function, thereby realizing dynamic acquisition of interface fields of the target API without manual acquisition of interface fields and improving the field acquisition efficiency; after determining the target field, a verification variable is dynamically constructed, and then combined with the test case template, an interface test case is automatically generated, thereby realizing dynamic construction of the test case and improving the test case generation efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 FIG. is a schematic diagram of generating a test case provided by an embodiment of the present invention;

[0048] Figure 2 FIG. is a flowchart of a method for dynamically generating test cases based on API provided by another embodiment of the present invention;

[0049] Figure 3 FIG. is a complete flowchart of a method for dynamically generating test cases based on API provided by another embodiment of the present invention;

[0050] Figure 4 FIG. is a structural diagram of a device for dynamically generating test cases based on API provided by another embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0051] Embodiments of the present invention will be described in detail below. Examples of the embodiments are shown in the accompanying drawings, where the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention and should not be construed as a limitation of the present invention.

[0052] In the description of the present invention, it should be understood that the orientation or positional relationship indicated by terms such as up, down, front, back, left, right, etc. is based on the orientation or positional relationship shown in the accompanying drawings. It is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention.

[0053] In the description of the present invention, the meaning of "several" is one or more, the meaning of "multiple" is two or more, "greater than", "less than", "exceeding", etc. are understood to not include the recited number, and "above", "below", "within", etc. are understood to include the recited number. If there is a description of "first" and "second", it is only for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance or implicitly indicating the quantity of the indicated technical features or implicitly indicating the sequence of the indicated technical features.

[0054] In the description of the present invention, unless otherwise clearly defined, terms such as "set", "installed", "connected", etc. should be understood in a broad sense, and those skilled in the art can reasonably determine the specific meanings of the above terms in the present invention in combination with the specific content of the technical solution.

[0055] The embodiments of the present invention provide a method, device, equipment, and medium for dynamically generating API-based test cases. Among them, the method for dynamically generating API-based test cases includes:

[0056] In response to a user selecting a target API from the API list on the test interface, a target URL is constructed based on multiple target parameters of the target API, and response JSON data is obtained from the target API based on the target URL, where the API list includes multiple preset candidate APIs; traverse the data nodes of the response JSON data based on a preset recursive function, and based on any traversed target node, determine the recursive path as the field path of the traversed interface field. When the target node includes child nodes, add the node path of the child nodes to the recursive path and then recursively call the target node. Or, when the target node does not include the child nodes, clear the recursive path and then recursively call the response JSON data; construct a verification variable for the interface field based on the field path and target verification information, where the target verification information includes a data comparison rule, data type, and expected value that were set last time or are default; display each interface field and its corresponding verification variable in the field list constructed on the test interface, and determine the selected interface field as the target field; input the target parameters and the verification variable corresponding to the target field into a preset test case template to generate an interface test case for the target API. According to the technical solution of the embodiment of the present invention, it is possible to automatically construct a target URL carrying target parameters, automatically obtain feed response JSON data through interaction with the target API, and use a recursive function to perform data parsing to obtain the field paths of each target field, thereby realizing dynamic acquisition of the interface fields of the target API without manual acquisition of interface fields and improving the field acquisition efficiency; after determining the target field, dynamically construct a verification variable, and then automatically generate an interface test case in combination with the test case template, thereby realizing dynamic construction of the test case and improving the generation efficiency of the test case.

[0057] The following is based on the attached Figure 1 schematic diagram shown to further elaborate on the technical solution of the embodiment of the present invention.

[0058] Refer to Figure 2 , Figure 2 which is a flowchart of a method for dynamically generating test cases based on APIs provided by an embodiment of the present invention. This method for dynamically generating test cases based on APIs is applied to a test platform, and the test platform presets multiple candidate fields. The method includes but is not limited to the following steps:

[0059] S10, In response to a user selecting a target API from the API list on the test interface, a target URL is constructed based on multiple target parameters of the target API, and response JSON data is obtained from the target API based on the target URL, where the API list includes multiple preset candidate APIs;

[0060] S20. Traverse the data nodes of the response JSON data based on a preset recursive function. Based on any traversed target node, determine the recursive path as the field path of the traversed interface field. Among them, when the target node includes child nodes, add the node path of the child nodes to the recursive path and then recursively call the target node. Or, when the target node does not include child nodes, clear the recursive path and then recursively call the response JSON data;

[0061] S30. Construct a verification variable for the interface field based on the field path and the target verification information. Among them, the target verification information includes the data comparison rule, data type, and expected value that were set last time or are default;

[0062] S40. Display each interface field and its corresponding verification variable in the field list constructed on the test interface, and determine the selected interface field as the target field;

[0063] S50. Input the target parameter and verification variable corresponding to the target field into a preset test case template to generate an interface test case for the target API.

[0064] It should be noted that testers can log in to the test system through devices such as computers, so as to deploy a test interface in the computer device. An API list is displayed in the test interface. The API list shows each candidate API that needs to be tested, such as Figure 1 As shown, the first API, the second API, and the third API and other candidate APIs are displayed in the API list. Since the test cases for each candidate API are different, in this embodiment, the target API can be selected from the API list in a single-choice form. It should be noted that the candidate APIs in the API list can be displayed by API name or custom name. For example, the first API is the API name, or after selecting the first API, configuration options of the API can be displayed on the test interface for name customization, which is convenient for testers to quickly distinguish APIs. Of course, as Figure 1 shown, after selecting the target API in the API list, a use case list can be displayed. The existing interface test cases of the target API are displayed in the use case list, or a trigger button for adding a new use case can be displayed in the use case list. Clicking it triggers the steps of constructing a new interface test case in this embodiment.

[0065] It should be noted that the target parameters are the input parameters of the target API. For example, they are Time, Location, Cost, or Account, etc. The testers have the ability of program development. Therefore, they can determine the input parameters of each target API according to the requirements of the test cases, or configure the same multiple target parameters for all candidate APIs. The target API constructs the response value based on the target parameters carried in the target URL, and the response value is usually in JSON format, which records all the interface fields and corresponding content corresponding to each target parameter through the JSON format.

[0066] It is worth noting that in this embodiment, all target parameters are written when constructing the target URL. The target API uses the target parameters carried in the target URL as the query conditions. If the target API can query the corresponding target parameters, the corresponding API data will be carried in the response JSON data. If the target API does not have the corresponding target parameters, an empty value will be returned. Thus, the flexible configuration of the response JSON data is realized through the flexible selection of the target parameters.

[0067] Exemplarily, as Figure 1 shown, in this embodiment, all preset target parameters are displayed in the test interface. When testing the function of the first API to calculate the annual incremental budget, the tester can directly select to generate the target URL, and the test platform will write all the target parameters into the target URL to perform subsequent operations; or, when the tester knows that the required target parameters include Time, Account, and Cost, the tester can select the above parameters in the test interface and then trigger the generation of the target URL. Then the test platform only writes the target parameters selected by the tester into the target URL, and the first API carries the interface fields and field data corresponding to the above target parameters in the JSON data returned in response to the target URL. This embodiment realizes the selectability and configurability of the target API and target parameters through the visual test interface, realizes the flexible configuration of the target URL, and thus realizes the flexible configuration of the response JSON data.

[0068] It should be noted that each target parameter in the response JSON data carries multiple interface fields. In this embodiment, Extract_Data in the Python language can be used as a recursive function. Extract_Data can traverse the data in the JSON structure, identify the interface fields from it and perform data extraction. In this embodiment, there is no need to perform the data extraction step, only the interface fields need to be identified, and then the traversed path is used as the field path.

[0069] It should be noted that after traversing a data node, the Extract_Data function determines whether the data node includes child nodes. If it does, the target node is used as the recursive call object, causing the Extract_Data function to continue calling the target node. During the recursive process, the Extract_Data function will traverse to the next-level node in the recursive call object, so it can traverse to the child nodes and continue to extract data based on the candidate fields as the extraction index. After extracting the interface fields, the recursive path of the child nodes is written into the recursive path, thus realizing the adaptive increase of the recursive path and automatically determining the field path of each interface field.

[0070] It is worth noting that for the same system, fields with the same function in different APIs can adopt the same naming rule during development. For example, fields for object names are all defined as "subjectName", and fields for summarizing data are all defined as "Total". Based on this, in this embodiment, not all fields in the response JSON data are extracted. Instead, multiple candidate fields are preset in the test platform. During the process of traversing using Extract_Data, each traversed field is matched with the candidate fields. If it is a candidate field, it is recorded as an interface field. If it is not a candidate field, the traversed field is discarded and the next field is traversed. Thus, using the candidate fields as the screening condition, combined with Extract_Data traversing the required interface fields and corresponding field paths in the response JSON data, the position of the fields required by the test cases in the target API can be quickly located. This embodiment does not need to ensure that all candidate fields are included in the response JSON data, but uses the candidate fields to represent the field requirements of the test cases, and only records the configured candidate fields as interface fields during the traversal process.

[0071] Exemplarily, as Figure 1 shown, in the field list of the test platform, there are candidate fields "subjectCode", "subjectName", and "Total" recorded. After traversing the response JSON data, when the traversed field is "subjectNum", it is not recorded because it does not belong to the candidate fields. After continuing to traverse to "subjectCode", it is determined as an interface field and the corresponding field path is recorded.

[0072] It should be noted that after determining multiple interface fields, in this embodiment, each interface field can be constructed on the test interface. Testers can click on the interface field in the test interface to enter the field configuration interface, and configure the target configuration information in the field configuration interface. The target verification information in this embodiment includes a data comparison rule (Comparator), a data type (Type), and an expected value (Value). The data comparison rule (Comparator) is the data comparison method that needs to be executed in the test case. For example, if it is necessary to determine whether the data is equal in the test case, the value of Comparator can be set to "equal", or Comparator can be set to end with a specific string, or start with a specific string, etc., which can be set according to actual needs; the data type can be common types such as string and integer (Int), and will not be further limited here; the expected value can be a pre-set value, such as 0 or 100, etc. The target verification information in this embodiment can be pre-set with default values, so as to quickly construct interface test cases without testers entering the field configuration interface for configuration. For example, the default value of Comparator is set to equal, the default value of the data type is set to string, and the default value of the expected value is set to 0. The above default values are directly applied to construct verification variables, improving the construction efficiency of test cases.

[0073] It should be noted that the verification variable is a variable defined in the interface test case for obtaining test data and performing test judgments. The field path and target verification information can be recorded in the verification variable, so that when the verification variable is called, the field data can be obtained according to the field path, and then the data comparison is performed on the field data using the target verification information.

[0074] It should be noted that in this embodiment, a verification variable is constructed based on each interface field, and then a field list is constructed on the test interface, as Figure 1 shown. The field list displays the interface field, the field address, and the verification variable. Testers can select the target field in the field list and enter the field configuration interface of the target field to adjust the corresponding target verification information, so as to automatically adjust the corresponding value in the verification variable. For example, Figure 1 as shown, after selecting "Total" as the target field, enter the field configuration interface and configure the value of Value to 1000; or after selecting subjectCode as the target field, enter the field configuration interface and configure Comparator to end with. The number of target fields can be arbitrary, for example, Figure 1As shown, after displaying the three interface fields of subjectCode, subjectName, and Total in the field list, subjectName and Total can be selected as target fields, and no further limitations are imposed here.

[0075] It should be noted that after determining the target fields, since each target field is obtained based on a target parameter request, in this embodiment, the target parameters corresponding to each target field are first determined, and then combined with the verification variables and input into the test case template to generate interface test cases. The specific template application is a technique well-known to those skilled in the art and will not be elaborated here.

[0076] Exemplarily, taking the target fields of Figure 1 subjectName, subjectCode, and Total shown as an example, the target parameters corresponding to subjectName and subjectCode are Account, and the target parameter corresponding to Total is Cost. Then, two template inputs are constructed in the test case template. The first template input records Account as the input parameter, and the verification variables corresponding to subjectName and subjectCode respectively as the template test data and test rules. The second template input records Cost as the input parameter, and the verification variable of Total as the template test data and test rules.

[0077] In addition, in one embodiment, referring to Figure 3 , the test platform presets preset request headers for each candidate API. The preset request headers carry preset authentication tokens, and the preset authentication tokens are used to verify the legality of the corresponding candidate APIs; step S10 specifically includes but is not limited to the following steps:

[0078] S11, convert each target parameter into a target string, obtain the preset reference URL, and write each target string into the query parameters of the reference URL to obtain the target URL;

[0079] S12, obtain the target request header of the target API, and construct a first HTTP request based on the target URL and the target request header, where the first HTTP request is a GET request or a POST request;

[0080] S13, send the first HTTP request to the target API so that the target API feeds back response JSON data based on each target string.

[0081] It should be noted that the target parameter is the information pre-entered by the tester in the test platform. To facilitate the target URL to carry it, in this embodiment, the Fstring function in Python can be used to convert the target parameter into a target string. A reference URL with an empty query parameter is maintained in the test platform, and each target string is written into the query parameter of the reference URL to obtain the target URL.

[0082] It should be noted that the target API does not belong to the test platform but is communicatively connected to the test platform. Therefore, the test platform needs to perform legality verification when requesting data from the target API. In this embodiment, the request headers of each candidate API are preset in the test platform. After selecting the target API, the corresponding request header is retrieved as the target request header. For example, the authentication token (Bearer Token) of the target API is carried in the target request header to ensure the legality of the request. According to the target URL and the target request header, a first HTTP request is constructed using the HTTP GET or POST method. Taking HTTP GET as an example, the requests library can be used to send an HTTP GET request to the target API through the get method, and the response data can be captured from the target API. The data fed back by the target API is determined based on the query parameters in the URL of the HTTP GET request. That is, after the target API receives the first HTTP request, it will obtain data according to each target parameter, and then form all the obtained data into a response JSON data and return it to the test platform.

[0083] In addition, in one embodiment, referring to Figure 3 , the test platform records the self-description information of each candidate API, and the content corresponding to the self-description information in the candidate API is all the interface parameters of the corresponding candidate API;

[0084] Before executing step S13, the method further includes:

[0085] S131, obtaining the self-description information of the target API, converting the self-description information of the target API into a target string and writing it into the target URL;

[0086] In step S40, a field list is constructed in the test interface, which specifically includes but is not limited to the following steps:

[0087] S41, when traversing the self-description information of the target API in the response JSON data based on the recursive function, the self-description information of the target API is not determined as an interface field, and all the interface parameters are extracted from the response JSON data;

[0088] S42, generating a field list based on the comparison result between the target parameter and the interface parameter.

[0089] It should be noted that according to the description of the above embodiments, in this embodiment, the test requirements of the tester are characterized by presetting target parameters. However, with the update of the target API, it is very likely that new target parameters will be added, resulting in the omission of data of the newly added parameters when requesting data. Based on this, in step S131 of this embodiment, the self-description information of the target API is written into the target URL, and a self-description information is maintained for each candidate API, and its corresponding content is all interface parameters, so that the target API can carry all interface parameters in the response JSON data.

[0090] It should be noted that in the target API, the interface field corresponding to the self-description information can adopt the same string as the self-description information, so that when the recursive function traverses the response JSON data, it can directly use the target string corresponding to the self-description information for comparison. Different from the interface field record field path, when the self-description information is recognized in the response JSON data, the self-description information is not recorded as an interface field, nor is the corresponding field address recorded, but the specific data content is extracted, that is, the interface parameters set in the target API.

[0091] It should be noted that after obtaining the interface parameters, the interface parameters are compared with the target parameters to determine whether any interface parameters are omitted, so as to ensure that the generated field list records the verification variables constructed by all interface fields of the target API and avoid omitting data.

[0092] In addition, in one embodiment, referring to Figure 3 , step S42 specifically includes but is not limited to the following steps:

[0093] S421, when the target parameters and the interface parameters match completely, generate a field list based on the target parameters;

[0094] S422, when at least one target parameter does not match the interface parameter, generate an exception prompt message on the test interface, and generate a field list based on each target parameter that matches the interface parameter, where the exception prompt message records the target parameter that does not match the interface parameter;

[0095] S423, when at least one candidate parameter is determined, generate a first option and a second option on the test interface, where the candidate parameter is an interface parameter that does not belong to the target parameter;

[0096] S424, when the first option is selected, generate a field list based on the target parameters;

[0097] S425, when the second option is selected, generate a second HTTP request based on the candidate parameter and the reference URL, obtain new response JSON data from the target API based on the second HTTP request, obtain supplementary fields and their corresponding field paths from the new response JSON data based on a recursive function, and construct a field list based on the interface fields and the supplementary fields.

[0098] It should be noted that when the target parameter and the interface parameter are exactly matched, it can be determined that the target API has not updated the input parameter, and the fields obtained based on the target parameter are complete. Just generate the field list and perform subsequent operations.

[0099] It should be noted that the interface parameter is all the supported input parameters in the target API, and the number of interface parameters should be greater than or equal to the target parameter. Therefore, among the interface parameters that the target parameter needs to record at least, if the target parameter does not match the interface parameter, it can be determined that the target parameter is incorrect. For example, an incorrect target parameter is configured in the test platform, or some interface parameters are deleted due to the update of the target API, resulting in the string corresponding to the target parameter being inconsistent with the interface parameter. In this embodiment, taking the interface parameter as the benchmark, an exception prompt message is generated on the test interface to inform the tester, and at the same time, a field list is generated for each target parameter that matches the interface parameter. The un-matched target parameters do not generate a field list because there is no feedback data from the target API.

[0100] It should be noted that in this embodiment, the interface parameters that do not belong to the target parameter are determined as candidate parameters. For example Figure 1 As shown, the target parameters include Time, Account, and Cost, and the personnel rank (Rank) is newly added to the interface parameters. At this time, Rank is determined as the candidate parameter, and the first option and the second option are displayed on the test interface, representing different compensation strategies for the candidate parameter through two different options.

[0101] It should be noted that since the tester knows the specific data corresponding to each interface parameter, this embodiment also sets the first option for the tester to directly trigger the generation of interface test cases when determining that no candidate parameter needs to be added. For example, taking the above Rank as an example, when constructing a test case for counting the budget usage of each department, there is no need to distinguish the budget by the personnel rank. Then the data corresponding to Rank has no reference value in the interface test case constructed this time. Even if the relevant interface fields are displayed in the field list, the tester may not select it as the target field. The selection of the first option improves the generation efficiency of the interface test case.

[0102] It should be noted that the second option is used when the tester uses the candidate parameters. After the tester knows the candidate parameters, if it is determined that the test platform has not synchronized the parameter update of the API in a timely manner, the tester can directly click the second option, and the test platform automatically constructs a second HTTP request according to the candidate parameters, obtains the supplementary fields and field paths corresponding to the candidate parameters from the target API. The tester does not need to perform repeated HTTP request operations, but can be automatically completed by the test platform. The construction method of the second HTTP request can refer to the first HTTP request, and the supplementary fields are obtained by traversing with a recursive function, which will not be repeated here. After obtaining the supplementary fields, after obtaining the verification variables in the same way as the target fields, a field list can be constructed together with the target fields. At the same time, the candidate parameters can also be added to the target parameters of the test platform to ensure comprehensive coverage of the target parameters when constructing the target URL next time.

[0103] In addition, in one embodiment, referring to Figure 3 , the test platform is connected to multiple optional systems, and each optional system is associated with multiple candidate APIs. Step S50 specifically includes but is not limited to the following steps:

[0104] S51, determine the target parameters corresponding to the target fields as the use case parameters, and construct a use case URL based on the use case parameters and the reference URL;

[0105] S52, construct a use case name based on the selected target system, target API, target parameters, and target fields;

[0106] S53, write the use case name, use case URL, and target parameters into the test case template, and construct the test logic statements of the test case template based on each verification variable to obtain the interface test case;

[0107] S54, associate the interface test case to the corresponding target system based on the use case name.

[0108] It should be noted that the test platform in this embodiment can be connected to multiple optional systems. For example Figure 1 shown, the optional systems include a budget system, a human resources system, a database, a property asset system, etc. Each optional system includes its corresponding candidate APIs. Of course, if multiple optional systems are subsystems of the same system, multiple candidate APIs can also be shared by multiple optional systems, that is, the relationship between candidate APIs and optional systems can be many-to-many or many-to-one.

[0109] It should be noted that in this embodiment, the target system is selected first when selecting the target API. After selecting the target system, all candidate APIs associated with the target system are displayed in the API list, as Figure 1As shown, after selecting the budget system as the target system, the first API, the second API, and the third API associated with the budget system are displayed in the API list. If the selected target system is the human resources system, the first API, the third API, and the fourth API associated with the human resources system are displayed in the API list.

[0110] It should be noted that the target fields in this embodiment are selected by the tester in the field list. Therefore, not all interface fields will necessarily be determined as target fields. Since each target parameter may correspond to multiple target fields, if none of the target fields of a target parameter are selected, it can be determined that this target parameter is not involved in this test case. Based on this, the target URL cannot be directly used as the test case URL for the test case. In this embodiment, the target parameter corresponding to the target field is used as the test case parameter, and the test case parameter is converted into a string through Fstring and then written into the reference URL to construct the test case URL. For example, in the above example, the target parameters corresponding to subjectName and subjectCode are Account, and the target parameter corresponding to Total is Cost. The target URL includes Account, Cost, and Time, but the test case URL only includes Account and Cost, which is different from the target URL.

[0111] It should be noted that in order to distinguish different interface test cases in this embodiment, the target system, the target API, the target parameter, and the target field are used to construct the test case name when naming the test case, as long as it can represent the specific data source and function of the interface test case.

[0112] It should be noted that the test case template usually records the format code of the test case, and the format code includes the definition code and the test code of the test case. In this embodiment, after obtaining the test case name, the test case URL, and the target parameter, they are dynamically filled into the definition code of the test case template. The tester can determine the name of the test case, the test case URL for obtaining data from the target API when constructing this interface test case, and the target parameter that the interface test case needs to input based on the above definition code from the interface test case.

[0113] It should be noted that the verification variables in this embodiment include the target field, the field address, and the corresponding target verification information. Based on these verification variables, the test logic statements of the test case template are constructed. For example, in the test code, it is recorded that through the address reference statement and the test execution statement, the field address of the verification variable is filled into the address reference statement of the test code, and the data comparison rule, data type, and expected value recorded in the target verification information are filled into the test execution statement. When the test code is run, it can request the data corresponding to the target field from the target API based on the field address, then determine whether the data type conforms based on the test execution statement, and then use the expected value and the data comparison rule to test the data returned by the target API, obtaining an interface test case that can complete the data test.

[0114] It should be noted that after obtaining the interface test case, it is associated with the corresponding target system, and then using the use case name as the identifier, which facilitates testers to quickly distinguish different interface test cases from the target system.

[0115] In addition, in one embodiment, referring to Figure 3 , after step S54 is executed, it further includes but is not limited to the following steps:

[0116] S541, Obtain the API update information from the system update information of any target system, where the API update information records at least one updated API;

[0117] S542, When the updated API includes at least one newly added candidate field and the updated API includes a full-field test case, obtain the updated response JSON data from the updated API based on the use case URL of the full-field test case, determine the field address of the candidate field from the updated response JSON data according to the recursive function, and construct the newly added verification variable corresponding to the candidate field. Based on the newly added verification variable and the full-field test case, construct a new test case, and retain the full-field test case, where the full-field test case is an interface test case including each candidate field;

[0118] S543, When the updated API includes at least one deleted candidate field, determine the associated test cases from all the interface test cases of the updated API based on the deleted candidate field, and remove the verification variable corresponding to the deleted candidate field from the associated test cases;

[0119] S544, When the updated API is a newly added API and an associated API is determined in the API list based on the user operation, copy all the interface test cases of the associated API to the updated API, and update each interface test case based on the name of the updated API and the name of the target system;

[0120] S545. When the updated API is a deleted API, delete all interface test cases corresponding to the updated API.

[0121] It should be noted that when an API is updated, for example, the fields, input parameters, etc. in the API are changed, system update information will inevitably be generated in the corresponding target system, and the specific update content will be recorded in the system update information. Therefore, in this embodiment, after obtaining the system update information of the target system, the API update information is extracted therefrom, and the API recorded in the API update information is determined as the updated API.

[0122] It should be noted that based on the description of the above embodiment, when constructing the interface test cases in this embodiment, the target fields are selected from the field list. Therefore, the interface test cases do not necessarily include all interface fields. After this embodiment determines the updated API based on the API update information and adds a candidate field, for the interface test cases that do not include all interface fields, there may not necessarily be a need to add the candidate field. However, for the full-field test cases that include all target fields, it is very likely that all interface fields need to be covered. Therefore, after this embodiment detects a newly added candidate field, it automatically determines the full-field test cases from the interface test cases of the target system. Since each interface test case has a use case URL, the response JSON data can be re-requested based on the use case URL recorded in the full-field test cases. The specific method can refer to the description of the above embodiment and will not be repeated here.

[0123] It should be noted that after obtaining the updated response JSON data, this embodiment queries according to the candidate fields based on the recursive function, without repeatedly traversing other interface fields. After determining the field address of the candidate field, a new verification variable is constructed according to the method of the above embodiment, and a new full-field test case is copied. The newly added verification variable is added to the copied full-field test case to obtain a new full-field test case. At the same time, this embodiment also retains the prior full-field test cases. Through the technical solution of this embodiment, in the case of having full-field test cases, when a new field is added to the API, new full-field test cases can be automatically generated on the test platform without the need for testers to perform relevant operations. Testers can directly obtain the new full-field test cases in the test interface for use.

[0124] It should be noted that when the updated API includes candidate fields to be deleted, since each interface test case is constructed based on verification variables, the field address of the target field is recorded in each interface test case. Based on the candidate field, the corresponding field address can be directly determined in the field list. The interface test case recording this field address is determined as the associated test case. In the associated test case, the corresponding verification variable is directly deleted, and the associated test case of the updated API is automatically synchronized. Testers do not need to update the interface test cases one by one, saving development time.

[0125] It should be noted that in step S544, the test platform is connected to multiple optional systems. If two similar optional systems need to be configured, for example, two subsidiaries of the same enterprise configure budget systems respectively. After the interface test case configuration of the relevant API is completed in the budget system of subsidiary A, when introducing the budget system of subsidiary B into the test platform, the architectures of the budget systems of different subsidiaries should be similar. When the number and functions of the APIs under the budget system are similar, the interface fields and data structures can refer to the associated APIs. Therefore, in this embodiment, an association option is provided in the API configuration interface. After adding a new API, an associated API can be selected through the association option, and all the interface test cases of the associated API are directly copied to the updated API, and the interface test cases are updated based on the name of the updated API, etc., so that the updated API can quickly deploy multiple interface test cases, greatly saving the generation time of test cases.

[0126] It is worth noting that for different optional systems, the target verification information in the interface test case can be a general rule, and the difference lies only in how to obtain data from the API according to the field address. In this embodiment, in order to facilitate copying the interface test case from the associated API, since the data structures are the same and the field address of the interface field is obtained by traversing with a recursive function, the field address actually represents the position of the interface field in the API data structure. Therefore, it can be determined that if the functions and data structures of the updated API and the associated API are the same, after adjusting the use case URL to point to the correct API, the correct data can also be obtained directly using the same field address. Of course, if the data structures of the APIs are different, do not select the associated API and Figure 2 re - construct the interface test case according to the steps of the illustrated embodiment.

[0127] It should be noted that when the updated API is a deleted API, directly batch - match and delete the interface test cases according to the API string associated with the use case name.

[0128] In addition, in one embodiment, referring to Figure 3 , step S20 specifically includes but is not limited to the following steps:

[0129] S21. Build a recursive path in the recursive function, and determine the response JSON data as the recursive call object of the recursive function, where the initial value of the recursive path is empty;

[0130] S22. Whenever a target node is traversed, write the node path of the target node into the recursive path, extract data from the target node using each candidate field as the extraction index. When an interface field is successfully extracted, determine the current recursive path as the field path of the interface field;

[0131] S23. When the target node does not include child nodes, clear the recursive path, and determine the response JSON data as the next recursive call object;

[0132] S24. When the target node includes child nodes, add the node path of the child nodes to the recursive path, and determine the target node as the next recursive call object of the recursive function.

[0133] It should be noted that according to the description of the above embodiments, the recursive function can adopt the Extract_Data function. In order to determine the field path, this embodiment uses the response JSON data as the default call object of the Extract_Data function and maintains a recursive path with an initial value of empty. When the Extract_Data function calls the response JSON function, it will read its root node for data extraction. Therefore, the node path is the root node path, which is written into the recursive path, and data is extracted from the data to which the root node belongs using the candidate field as the data index. If an interface field is successfully extracted, the root node path is used as the field path of the interface field. If there are multiple interface fields, the field paths of multiple interface fields are the same, and they can be distinguished according to the interface fields when obtaining data.

[0134] It should be noted that if the target node does not include child nodes, clear the recursive path, and continue to use the default call object as the recursive call object, so that the Extract_Data function traverses to the next root node from the response JSON data.

[0135] Exemplarily, as Figure 1 shown, the initial value of the recursive address is empty "Content.result.". Taking the response JSON structure including multiple parallel root nodes as an example, when recursing to the i-th (i is a positive integer) target node, the node path is "bodyList{i}", and after extracting the interface field from it, the recursive address is updated to "Content.result.bodyList{i}".

[0136] If the i-th target node has no child nodes, after recording Content.result.bodyList{i}, update the recursive address to "Content.result.", and continue to call the response JSON function to traverse to the (i + 1)-th target node. The node path is "bodyList{i+1}", and the obtained field address is "Content.result.bodyList{i+1}" in the same way.

[0137] If the i-th target node includes child nodes, use the i-th target node as the recursive call object of the Extract_Data function to traverse to its lower-level child nodes. Taking the j-th (i is a positive integer) child node as an example, when extracting the interface field, add the node address of the child node on the basis of updating the recursive address to "Content.result.bodyList{i}". Therefore, the field address corresponding to the j-th child node is "Content.result.bodyList.{i}.childList.{j}", and so on.

[0138] Such as Figure 4 shown, Figure 4 FIG. is a structural diagram of a dynamic test case generation device based on API provided by an embodiment of the present invention. The present invention also provides a dynamic test case generation device based on API, including:

[0139] A processor 401, which can be implemented by using a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, etc., and is used to execute relevant programs to implement the technical solutions provided by the embodiments of the present application;

[0140] A memory 402, which can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM), etc. The memory 402 can store an operating system and other application programs. When implementing the technical solutions provided by the embodiments of this specification through software or firmware, the relevant program codes are stored in the memory 402 and are called by the processor 401 to execute the API-based test case dynamic generation method of the embodiments of the present application;

[0141] An input / output interface 403, which is used to implement information input and output;

[0142] A communication interface 404 is used to implement communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.);

[0143] A bus 405 transmits information between various components of the device (such as a processor 401, a memory 402, an input / output interface 403, and a communication interface 404);

[0144] Among them, the processor 401, the memory 402, the input / output interface 403, and the communication interface 404 achieve communication connections with each other inside the device through the bus 405.

[0145] An embodiment of this application also provides an electronic device, including the API-based test case dynamic generation device described above.

[0146] An embodiment of this application also provides a storage medium. The storage medium is a computer-readable storage medium. This storage medium stores a computer program, and when the computer program is executed by a processor, it implements the above-mentioned API-based test case dynamic generation method.

[0147] As a non-transitory computer-readable storage medium, the memory can be used to store non-transitory software programs and non-transitory computer-executable programs. In addition, the memory can include high-speed random access memory, and can also include non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some embodiments, the memory can optionally include a memory remotely set relative to the processor, and these remote memories can be connected to the processor through a network. Examples of the above networks include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0148] Those of ordinary skill in the art will understand that all or some of the steps and systems disclosed in the above methods can be implemented as software, firmware, hardware, and appropriate combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include a computer storage medium (or non-transitory medium) and a communication medium (or transitory medium). As is well known to those of ordinary skill 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 instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, as is well known to those of ordinary skill in the art, communication media typically includes computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and can include any information delivery medium.

[0149] The above is a specific description of the preferred embodiments of the present invention, but the present invention is not limited to the above embodiments. Those skilled in the art can also make various equivalent deformations or substitutions without departing from the spirit of the present invention, and these equivalent deformations or substitutions are all included within the scope defined by the claims of the present invention.

Claims

1. A method for dynamically generating test cases based on API, characterized in that, Applied to a test platform, which pre-sets multiple candidate fields, the method includes: In response to a user selecting a target API in an API list on a test interface, constructing a target URL based on multiple target parameters of the target API, and obtaining response JSON data from the target API based on the target URL, where the API list includes multiple pre-set candidate APIs; Traversing data nodes of the response JSON data based on a pre-set recursive function, and based on any traversed target node, determining a recursive path as a field path of the traversed interface field. Wherein, when the target node includes sub-nodes, adding the node paths of the sub-nodes to the recursive path and then recursively calling the target node, or, when the target node does not include the sub-nodes, clearing the recursive path and then recursively calling the response JSON data; Constructing a verification variable of the interface field based on the field path and target verification information, where the target verification information includes a data comparison rule, data type, and expected value that were set last time or are default; Displaying each of the interface fields and their respective corresponding verification variables in a field list constructed on the test interface, and determining the selected interface field as a target field; Inputting the target parameters and the verification variables corresponding to the target field into a pre-set test case template to generate an interface test case for the target API.

2. The API-based test case dynamic generation method according to claim 1, wherein, The test platform pre-sets pre-set request headers for each of the candidate APIs, and the pre-set request headers carry pre-set authentication tokens, which are used to pass the legitimacy verification of the corresponding candidate APIs; Constructing a target URL based on multiple target parameters of the target API, and obtaining response JSON data from the target API based on the target URL, includes: Converting each of the target parameters into a target string, obtaining a pre-set reference URL, and writing each of the target strings into query parameters of the reference URL to obtain the target URL; Obtaining a target request header of the target API, and constructing a first HTTP request based on the target URL and the target request header, where the first HTTP request is a GET request or a POST request; Sending the first HTTP request to the target API, so that the target API feeds back the response JSON data based on each of the target strings.

3. The method for dynamically generating test cases based on API according to claim 2, wherein The test platform records self-description information for each of the candidate APIs, and the content corresponding to the self-description information in the candidate API is all interface parameters of the corresponding candidate API; Before sending the first HTTP request to the target API, the method further includes: Obtaining the self-description information of the target API, converting the self-description information of the target API into the target string and writing it into the target URL; Constructing a field list on the test interface, includes: When traversing the self-description information of the target API in the response JSON data based on the recursive function, the self-description information of the target API is not determined as the interface field, and all the interface parameters are extracted from the response JSON data; Generate the field list based on the comparison result between the target parameter and the interface parameter.

4. The method for dynamically generating test cases based on API according to claim 3, wherein Generating the field list based on the comparison result between the target parameter and the interface parameter includes: When the target parameter and the interface parameter match exactly, generate the field list based on the target parameter; Or, when at least one of the target parameters does not match the interface parameter, generate an exception prompt message on the test interface, and generate the field list based on each target parameter that matches the interface parameter, where the exception prompt message records the target parameter that does not match the interface parameter; Or, when at least one candidate parameter is determined, generate a first option and a second option on the test interface, where the candidate parameter is an interface parameter that does not belong to the target parameter; When the first option is selected, generate the field list based on the target parameter; Or, when the second option is selected, generate a second HTTP request based on the candidate parameter and the reference URL, obtain new response JSON data from the target API based on the second HTTP request, obtain supplementary fields and corresponding field paths from the new response JSON data based on the recursive function, and construct the field list based on the interface field and the supplementary fields.

5. The method for dynamically generating test cases based on API according to claim 2, characterized in that, The test platform is connected to multiple optional systems, and each optional system is associated with multiple candidate APIs. Inputting the target parameter corresponding to the target field and the verification variable into a preset test case template to generate an interface test case for the target API, including: Determine the target parameter corresponding to the target field as the use case parameter, and construct a use case URL based on the use case parameter and the reference URL; Construct a use case name based on the selected target system, the target API, the target parameter, and the target field; Write the use case name, the use case URL, and the target parameter into the test case template, and construct the test logic statement of the test case template based on each verification variable to obtain the interface test case; Associate the interface test case to the corresponding target system based on the use case name.

6. The method for dynamically generating test cases based on API according to claim 5, wherein After associating the interface test case to the corresponding target system based on the use case name, the method further includes: Obtain API update information from the system update information of any target system, where the API update information records at least one updated API; When the update API includes at least one of the newly added candidate fields, and the update API includes full-field test cases, obtain the updated response JSON data from the update API based on the use case URL of the full-field test cases, determine the field address of the candidate field from the updated response JSON data according to the recursive function, and construct a newly added verification variable corresponding to the candidate field. Construct a newly added test case based on the newly added verification variable and the full-field test cases, and retain the full-field test cases, where the full-field test cases are interface test cases including each of the candidate fields; When the update API includes at least one of the deleted candidate fields, determine the associated test cases from all the interface test cases of the update API based on the deleted candidate fields, and remove the verification variable corresponding to the deleted candidate field in the associated test cases; When the update API is a newly added API, and an associated API is determined in the API list based on user operations, copy all the interface test cases of the associated API to the update API, and update each interface test case based on the name of the update API and the name of the target system; When the update API is a deleted API, delete all the interface test cases corresponding to the update API.

7. The method for dynamically generating test cases based on API according to claim 1, wherein Traverse the data nodes of the response JSON data based on a preset recursive function. Based on any traversed target node, determine the field path of the traversed interface field as the recursive path, including: Construct the recursive path in the recursive function, and determine the response JSON data as the recursive call object of the recursive function, where the initial value of the recursive path is empty; Whenever a target node is traversed, write the node path of the target node into the recursive path, extract data in the target node with each candidate field as the extraction index. When the interface field is successfully extracted, determine the current recursive path as the field path of the interface field; When the target node does not include child nodes, clear the recursive path, and determine the response JSON data as the next recursive call object; When the target node includes child nodes, add the node path of the child node to the recursive path, and determine the target node as the next recursive call object of the recursive function.

8. A test case dynamic generation device based on API, characterized in that Comprising at least one control processor and a memory for communicatively connecting with the at least one control processor; The memory stores instructions executable by the at least one control processor. The instructions are executed by the at least one control processor, so that the at least one control processor can execute the API-based test case dynamic generation method according to any one of claims 1 to 7.

9. An electronic device, characterized in that, Comprising the API-based test case dynamic generation device according to claim 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer to execute the API-based test case dynamic generation method according to any one of claims 1 to 7.

Images