Dynamic test case generation method and device based on API (Application Program Interface), equipment and medium

Abstract

The invention provides an API-based test case dynamic generation method and device, equipment and a medium, and the method comprises the steps: building a target URL based on a plurality of target parameters of a target API, obtaining response JSON data from the target API, and then calling a recursive function to traverse an interface field and a field path; based on any interface field, a verification variable is constructed based on the corresponding field path and the target verification information; and based on the selected target field, inputting the target parameter and the verification variable into a test case template to generate an interface test case of the target API. According to the technical scheme provided by the embodiment of the invention, the target URL carrying the target parameter can be automatically constructed, the feedback response JSON data can be automatically acquired by utilizing interaction with the target API, the interface field can be automatically acquired by utilizing data analysis of the recursive function, and the field acquisition efficiency is improved; after the target field is determined, the verification variable is dynamically constructed, and the interface test case is automatically generated in combination with the test case template, so that the generation efficiency of the test case is improved.

Description

Technical Field

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

[0002] In the software development process, the testing of the Application Programming Interface (API) is an important part of ensuring the system functionality and performance. Traditional API testing often requires manual writing of test cases, designing verification logic one by one according to the API response data, and the writing efficiency of test cases is low.

[0003] Some related technologies have proposed some systems for automatically generating test cases, which automatically generate test cases after inputting the interface fields and response rules of the API into the case template. However, testers still need to manually filter out the target fields from the historical interaction data of the API or the API code. The number of target fields is very large, and some target fields will be added when the API is updated. When there are many test cases, testers need to spend a lot of time collecting target fields and updating test cases, which affects the efficiency of test case generation. Summary of the invention

[0004] The present invention aims to solve at least one of the technical problems existing in the prior art. To this end, the present invention proposes a method, device, equipment and medium for dynamically generating test cases based on an API, which can automatically obtain response data based on interaction with an API, dynamically construct test cases based on the response data, and improve 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 an API, which is applied to a test platform, wherein the test platform is preset with multiple candidate fields, and the method includes: In response to a user selecting a target API in an API list of a test interface, constructing a target URL based on a plurality of target parameters of the target API, and acquiring response JSON data from the target API based on the target URL, wherein the API list includes a plurality of preset candidate APIs; Traversing the data nodes of the response JSON data based on a preset recursive function, and determining the recursive path as the field path of the traversed interface field based on any traversed target node, wherein, when the target node includes a child node, the node path of the child node is added to the recursive path and then the target node is recursively called, or, when the target node does not include the child node, the recursive path is cleared and then the response JSON data is recursively called; Constructing a verification variable of the interface field based on the field path and target verification information, wherein the target verification information includes a data comparison rule, a data type, and an expected value that were set last time or by default; The field list constructed in the test interface displays each of the interface fields and the corresponding verification variables, and the selected interface field is determined as a target field; The target parameter 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.

[0006] According to some embodiments of the present invention, the test platform presets a preset request header for each candidate API, the preset request header carries a preset authentication token, and the preset authentication token is used to pass the legitimacy verification of the corresponding candidate API; 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, including: Convert each of the target parameters into a target string, obtain a preset reference URL, and write each of the target strings into the query parameters of the reference URL to obtain the target URL; Obtain a target request header of the target API, and construct a first HTTP request based on the target URL and the target request header, wherein the first HTTP request is a GET request or a POST request; The first HTTP request is sent to the target API, so that the target API feeds back the response JSON data based on each of the target strings.

[0007] According to some embodiments of the present invention, the test platform records self-description information of each candidate API, and the corresponding content of 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 the string into the target URL; Build a field list in the test interface, including: When the self-description information of the target API is traversed 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; The field list is generated based on the comparison result of the target parameter and the interface parameter.

[0008] According to some embodiments of the present invention, generating the field list based on the comparison result of the target parameter and the interface parameter includes: When the target parameter and the interface parameter completely match, generating the field list based on the target parameter; Alternatively, when at least one of the target parameters does not match the interface parameters, an abnormal prompt message is generated on the test interface, and the field list is generated based on each of the target parameters that match the interface parameters, wherein the abnormal prompt message records the target parameters that do not match the interface parameters; Alternatively, when at least one candidate parameter is determined, a first option and a second option are generated on the test interface, wherein the candidate parameter is the interface parameter that does not belong to the target parameter; When the first option is selected, generating the field list based on the target parameter; Alternatively, when the second option is selected, a second HTTP request is generated based on the candidate parameters and the reference URL, new response JSON data is obtained from the target API based on the second HTTP request, supplementary fields and corresponding field paths are obtained from the new response JSON data based on the recursive function, and the field list is constructed based on the interface fields and the supplementary fields.

[0009] According to some embodiments of the present invention, the test platform is connected to a plurality of optional systems, each of the optional systems is associated with a plurality of the candidate APIs, and the target parameters and the verification variables corresponding to the target fields are input 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 a 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; Writing the use case name, the use case URL and the target parameter into the test case template, and constructing the test logic statement of the test case template based on each of the verification variables to obtain the interface test case; The interface test case is associated with the corresponding target system based on the use case name.

[0010] According to some embodiments of the present invention, after associating the interface test case to the corresponding target system based on the use case name, the method further includes: Acquire API update information from system update information of any target system, wherein 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 a user operation, 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.

[0011] According to some embodiments of the present invention, traverse the 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 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 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; 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 nodes to the recursive path, and determine the target node as the next recursive call object of the recursive function.

[0012] In a second aspect, an embodiment of the present invention provides an API-based test case dynamic generation device, comprising at least one control processor and a memory for communicating with the at least one control processor; the memory stores instructions executable by the at least one control processor, and 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 as described in the first aspect above.

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

[0014] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the API-based test case dynamic generation method as described in the first aspect above.

[0015] The method for dynamically generating test cases based on an API according to an embodiment of the present invention has at least the following beneficial effects: in response to a user selecting a target API in an API list of 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, wherein the API list includes multiple preset candidate APIs; data nodes of the response JSON data are traversed based on a preset recursive function, and based on any traversed target node, a recursive path is determined as a field path of the traversed interface field, wherein when the target node includes a child node, the node path of the child node is added to the recursive path; The target node is recursively called after the path, or, when the target node does not include the child node, the response JSON data is recursively called after the recursive path is cleared; the verification variable of the interface field is constructed based on the field path and the target verification information, wherein the target verification information includes the data comparison rule, data type and expected value set last time or defaulted; the field list constructed in the test interface displays each of the interface fields and the corresponding verification variables, and the selected interface field is determined as the target field; the target parameters and the verification variables corresponding to the target field are input into the preset test case template to generate the interface test case of 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 a target parameter, automatically obtain the feedback response JSON data by interacting with the target API, and obtain the field path of each target field by using a recursive function to perform data parsing, thereby realizing dynamic acquisition of the interface field of the target API, without manually obtaining the interface field, and improving the field acquisition efficiency; after determining the target field, the verification variable is dynamically constructed, and then the interface test case is automatically generated in combination with the test case template, thereby realizing the dynamic construction of the test case and improving the generation efficiency of the test case. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 is a schematic diagram of generating a test case provided by an embodiment of the present invention; Figure 2 is a flowchart of a method for dynamically generating test cases based on an API provided by another embodiment of the present invention; Figure 3 is a complete flow chart of a method for dynamically generating test cases based on an API provided by another embodiment of the present invention; Figure 4 It is a structural diagram of an API-based test case dynamic generation device provided by another embodiment of the present invention. DETAILED DESCRIPTION

[0017] Embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and cannot be understood as limiting the present invention.

[0018] In the description of the present invention, it should be understood that descriptions involving orientations, such as up, down, front, back, left, right, etc., and orientations or positional relationships indicated are based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply 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 understood as a limitation on the present invention.

[0019] In the description of the present invention, "several" means one or more, "more" means more than two, "greater than", "less than", "exceed" etc. are understood as not including the number itself, and "above", "below", "within" etc. are understood as including the number itself. If there is a description of "first" or "second", it is only used for the purpose of distinguishing the technical features, and cannot be understood as indicating or implying the relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the order of the indicated technical features.

[0020] In the description of the present invention, unless otherwise clearly defined, terms such as setting, installing, connecting, etc. should be understood in a broad sense, and technicians in the relevant technical field can reasonably determine the specific meanings of the above terms in the present invention in combination with the specific content of the technical solution.

[0021] The embodiment of the present invention provides a method, apparatus, device and medium for dynamically generating test cases based on an API, wherein the method for dynamically generating test cases based on an API includes: In response to a user selecting a target API in an API list of 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, wherein the API list includes multiple preset candidate APIs; the data nodes of the response JSON data are traversed based on a preset recursive function, and based on any traversed target node, the recursive path is determined as the field path of the traversed interface field, wherein when the target node includes a child node, the node path of the child node is added to the recursive path and then the target node is recursively called, or, when the target node does not include the child node, the recursive path is cleared and then the response JSON data is recursively called; the verification variable of the interface field is constructed based on the field path and target verification information, wherein the target verification information includes a data comparison rule, a data type and an expected value that were set last time or defaulted; the field list constructed in the test interface displays each of the interface fields and the corresponding verification variables, and the selected interface field is determined as the target field; the target parameter 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 embodiment of the present invention, it is possible to automatically construct a target URL carrying target parameters, automatically obtain feedback response JSON data by interacting with the target API, and obtain the field path of each target field by using a recursive function to parse the data, thereby dynamically obtaining the interface fields of the target API without manually obtaining the interface fields, thereby improving the field acquisition efficiency; after determining the target field, the verification variable is dynamically constructed, and then the interface test case is automatically generated in combination with the test case template, thereby realizing the dynamic construction of the test case and improving the test case generation efficiency.

[0022] The following is based on the Figure 1 The schematic diagram shown further illustrates the technical solution of the embodiment of the present invention.

[0023] Reference Figure 2 , Figure 2 A flowchart of a method for dynamically generating test cases based on an API is provided in an embodiment of the present invention. The method for dynamically generating test cases based on an API is applied to a test platform. The test platform is preset with multiple candidate fields. The method includes but is not limited to the following steps: S10, in response to a user selecting a target API in an API list of a test interface, constructing a target URL based on multiple target parameters of the target API, and acquiring response JSON data from the target API based on the target URL, wherein the API list includes multiple preset candidate APIs; S20, traversing the data nodes of the response JSON data based on a preset recursive function, and determining the recursive path as the field path of the traversed interface field based on any traversed target node, wherein, when the target node includes a child node, the node path of the child node is added to the recursive path and then the target node is recursively called, or, when the target node does not include a child node, the recursive path is cleared and then the response JSON data is recursively called; S30, constructing a verification variable of the interface field based on the field path and the target verification information, wherein the target verification information includes the data comparison rule, data type and expected value that was set last time or by default; S40, displaying each interface field and its corresponding verification variable in the field list constructed in the test interface, and determining the selected interface field as the target field; S50, inputting the target parameters and verification variables corresponding to the target fields into a preset test case template to generate an interface test case for the target API.

[0024] It should be noted that the tester can log in to the test system through a computer or other device, thereby deploying a test interface in the computer device, and displaying an API list in the test interface. The API list displays various candidate APIs that need to be tested, such as Figure 1 As shown, the API list displays candidate APIs such as the first API, the second API, and the third API. 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-select form. It is worth noting that the candidate APIs in the API list can be displayed as API names or as custom names. For example, the first API is the API name. After selecting the first API, the API configuration options can be displayed in the test interface to customize the name, so that testers can quickly distinguish APIs. Of course, Figure 1 As shown, after selecting the target API in the API list, a use case list can be displayed, in which the existing interface test cases of the target API are displayed. A trigger button for adding a new use case can also be displayed in the use case list. Clicking it will trigger the step of building a new interface test case in this embodiment.

[0025] It should be noted that the target parameters are the input parameters of the target API, such as time, location, cost or account, etc. Testers have the ability to develop programs, so they can determine the input parameters of each target API according to the needs of the test case, and can also configure the same multiple target parameters for all candidate APIs. The target API will construct a response value based on the target parameters carried in the target URL, and the response value is usually in JSON format, which records all interface fields and corresponding contents corresponding to each target parameter in JSON format.

[0026] 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 by the target URL as query conditions. If the target API can query the corresponding target parameters, the corresponding API data is carried in the response JSON data. If the target API does not have the corresponding target parameters, a null value is returned, thereby achieving flexible configuration of the response JSON data through flexible selection of target parameters.

[0027] For example, Figure 1 As shown, this embodiment displays all preset target parameters in the test interface. When the function of testing the first API to calculate the incremental budget for the current year is needed, the tester can directly choose to generate a target URL, and the test platform will write all 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 target URL can be generated after selecting the above parameters in the test interface. The test platform will only write the target parameters selected by the tester into the target URL, and the JSON data returned by the first API in response to the target URL carries the interface fields and field data corresponding to the above target parameters. This embodiment implements the selectability and configurability of the target API and target parameters through a visual test interface, and implements flexible configuration of the target URL, thereby implementing flexible configuration of the response JSON data.

[0028] It should be noted that each target parameter in the response JSON data carries multiple interface fields. This embodiment can use Extract_Data in the Python language as a recursive function. Extract_Data can traverse the data of the JSON structure, identify the interface fields therefrom and extract data. This embodiment does not need to perform the data extraction step, but only needs to identify the interface fields and then use the traversed path as the field path.

[0029] It should be noted that after completing the traversal of 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, so that the Extract_Data function continues to call 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 node and continue to extract data based on the candidate field as the extraction index. After extracting the interface field, the recursive path of the child node is written into the recursive path, thereby realizing the adaptive increase of the recursive path, thereby automatically determining the field path of each interface field.

[0030] It is worth noting that for the same system, fields with the same functions of different APIs can use the same naming rules during development. For example, the fields of object names are defined as "subjectName", and the fields of summary data are defined as "Total". Based on this, this embodiment does not extract all fields in the response JSON data, but pre-sets multiple candidate fields on the test platform. In the process of traversing using Extract_Data, each field traversed is matched with the candidate field. If it is a candidate field, it is recorded as an excuse field. If it is not a candidate field, the field traversed this time is abandoned and the next field is traversed. The candidate field is used as a screening condition, combined with Extract_Data to traverse the interface fields and corresponding field paths that need to be used in the response JSON data, and the position of the fields that the test case needs to use in the target API is quickly located. This embodiment does not need to ensure that all candidate fields are included in the response JSON data, but uses candidate fields to represent the field requirements of the test case, and only records the configured candidate fields as interface fields during the traversal process.

[0031] For example, Figure 1 As shown, the field list of the test platform records the candidate fields "subjectCode", "subjectName" and "Total". After traversing the response JSON data, when the traversed field is "subjectNum", it is not recorded because it does not belong to the candidate field. After continuing to traverse to "subjectCode", it is determined to be an interface field and the corresponding field path is recorded.

[0032] It should be noted that after determining multiple interface fields, this embodiment can construct each interface field in the test interface. The tester can enter the field configuration interface after clicking the interface field in the test interface, and configure the target configuration information in the field configuration interface. The target verification information of this embodiment includes data comparison rules (Comparator), data types (Type) and expected values ​​(Value). The data comparison rules (Comparator) are the data comparison methods that need 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 the Comparator can be set to "equal", or the Comparator can be set to end with a specific string (end with), or start with a specific string (start with), etc., according to actual needs; the data type can be a common string (string), integer (Int), etc., which is not limited here; the expected value can be a pre-set value, such as 0 or 100, etc. The target verification information of this embodiment can be pre-set with default values, so that the interface test case can be quickly constructed without the tester entering the field configuration interface for configuration. For example, the default value of Comparator is set to equal, the default value of data type is set to string, and the default value of expected value is set to 0. The above default values ​​are directly applied to construct verification variables, thereby improving the efficiency of test case construction.

[0033] It should be noted that the verification variable is a variable defined in the interface test case for obtaining test data and performing test judgment. 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 target verification information can be used to perform data comparison on the field data.

[0034] It should be noted that this embodiment constructs a verification variable based on each interface field, and then constructs a field list in the test interface, such as Figure 1 As shown in the figure, the field list displays the interface field, field address, and verification variable. The tester 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, thereby automatically adjusting the corresponding value in the verification variable. For example, Figure 1 As shown in the figure, 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 any, for example Figure 1As shown, after the three interface fields, subjectCode, subjectName and Total, are displayed in the field list, you can select subjectName and Total as the target fields without further restrictions.

[0035] It should be noted that after determining the target field, since each target field is obtained based on a target parameter request, this embodiment first determines the target parameters corresponding to each target field, and then combines the verification variables to input into the test case template to generate an interface test case. The specific template application is a technology well known to those skilled in the art, and will not be elaborated here.

[0036] For example, the target field is Figure 1 Taking the subjectName, subjectCode and Total shown in the figure 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 an input parameter, and the verification variables corresponding to subjectName and subjectCode are used as template test data and test rules. The second template input records Cost as an input parameter, and the verification variable of Total is used as template test data and test rules.

[0037] In addition, in one embodiment, referring to Figure 3 The test platform presets a preset request header for each candidate API, and the preset request header carries a preset authentication token, which is used to pass the legitimacy verification of the corresponding candidate API; step S10 specifically includes but is not limited to the following steps: S11, converting each target parameter into a target string, obtaining a preset reference URL, and writing each target string into the query parameter of the reference URL to obtain the target URL; S12, obtaining a target request header of a target API, and constructing a first HTTP request based on the target URL and the target request header, wherein the first HTTP request is a GET request or a POST request; S13, sending the first HTTP request to the target API, so that the target API feeds back response JSON data based on each target character string.

[0038] It should be noted that the target parameters are the information pre-entered by the tester in the test platform. In order to facilitate the carrying of the target URL, this embodiment can use the Fstring function in Python to convert the target parameters into a target string, maintain a reference URL with an empty query parameter on the test platform, and write each target string into the query parameter of the reference URL to obtain the target URL.

[0039] It should be noted that the target API does not belong to the test platform, but is connected to the test platform in communication. Therefore, the test platform needs to perform legitimacy verification when requesting data from the target API. In this embodiment, the test platform presets the request headers of each candidate API, and after selecting the target API, the corresponding request header is called as the target request header, for example, the target request header carries the authentication token (Bearer Token) of the target API to ensure the legitimacy of the request. According to the target URL and the target request header, the first HTTP request is constructed using the HTTP GET or POST method. Taking HTTP GET as an example, the HTTP GET request can be sent to the target API through the get method of the requests library, 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 of the URL in the HTTP GET request, that is, after the target API obtains the first HTTP request, it will obtain data according to each target parameter, and then assemble all the obtained data into a response JSON data and return it to the test platform.

[0040] In addition, in one embodiment, referring to Figure 3 ,The test platform records the self-description information of each candidate API, and the corresponding content of the self-description information in the candidate API is all the interface parameters of the corresponding candidate API; Before executing step S13, the method further includes: 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; In step S40, a field list is constructed in the test interface, which specifically includes but is not limited to the following steps: S41, when the self-description information of the target API is traversed 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 interface parameters are extracted from the response JSON data; S42, generating a field list based on the comparison result of the target parameters and the interface parameters.

[0041] It should be noted that, according to the description of the above embodiment, this embodiment represents the test requirements of the tester by means of preset target parameters, and with the update of the target API, new target parameters are likely to be added, resulting in omission of the data of the newly added parameters when requesting data. Based on this, in step S131, this embodiment writes the self-description information of the target API into the target URL, and maintains a self-description information for each candidate API, and its corresponding content is all the interface parameters, so that the target API can carry all the interface parameters in the response JSON data.

[0042] It should be noted that, in the target API, the interface field corresponding to the self-description information can use 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. Unlike the interface field recording the field path, when the self-description information is identified in the response JSON data, the self-description information is not recorded as an interface field, nor the corresponding field address is recorded. Instead, the specific data content is extracted, that is, the interface parameters set in the target API.

[0043] 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, and to ensure that the generated field list contains the verification variables constructed by all interface fields of the target API to avoid missing data.

[0044] In addition, in one embodiment, referring to Figure 3 Step S42 specifically includes but is not limited to the following steps: S421, when the target parameters and the interface parameters completely match, a field list is generated based on the target parameters; S422, when at least one target parameter does not match the interface parameter, an abnormal prompt message is generated on the test interface, and a field list is generated based on each target parameter that matches the interface parameter, wherein the abnormal prompt message records the target parameter that does not match the interface parameter; S423, when at least one candidate parameter is determined, generating a first option and a second option on the test interface, wherein the candidate parameter is an interface parameter that does not belong to the target parameter; S424, when the first option is selected, generating a field list based on the target parameter; S425, when the second option is selected, a second HTTP request is generated based on the candidate parameters and the reference URL, new response JSON data is obtained from the target API based on the second HTTP request, supplementary fields and corresponding field paths are obtained from the new response JSON data based on a recursive function, and a field list is constructed based on the interface fields and the supplementary fields.

[0045] It should be noted that when the target parameters and the interface parameters completely match, it can be determined that the target API has not updated the input parameters, and the fields obtained based on the target parameters are complete. You can generate a field list to perform subsequent operations.

[0046] It should be noted that the interface parameters are all supportable input parameters in the target API, and the number of interface parameters should be greater than or equal to the target parameters. Therefore, the target parameters must at least be recorded in the interface parameters. If the target parameters do not match the interface parameters, it can be determined that an error has occurred in the target parameters. For example, incorrect target parameters are configured in the test platform, or some interface parameters are deleted due to the update of the target API, resulting in inconsistency between the character string corresponding to the target parameter and the interface parameter. This embodiment uses the interface parameters as a benchmark, generates an exception prompt message in the test interface to inform the tester, and generates a field list with each target parameter that matches the interface parameters. The field list is not designed to be generated for the unmatched target parameters because there is no feedback data from the target API.

[0047] It should be noted that this embodiment determines the interface parameters that are not target parameters as candidate parameters, for example Figure 1 As shown in the figure, the target parameters include Time, Account and Cost, and a new personnel rank (Rank) is added to the interface parameters. At this time, Rank is determined as a candidate parameter, and the first option and the second option are displayed in the test interface. The two different options represent different compensation strategies for the candidate parameters.

[0048] It should be noted that since the testers are aware of the specific data corresponding to each interface parameter, the present embodiment also provides a first option for the testers to directly trigger the generation of interface test cases when they determine that there is no need to add candidate parameters. For example, taking the above-mentioned Rank as an example, if when constructing a test case to count the budget usage of each department, it is not necessary to distinguish the budget by personnel rank, then the data corresponding to the 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 testers may not select them as target fields. The selection of the first option improves the efficiency of generating interface test cases.

[0049] It should be noted that the second option is used when the tester uses candidate parameters. After knowing the candidate parameters, if the tester determines that the test platform has not synchronized the parameter updates of the API in time, the tester can directly click the second option. The test platform automatically constructs a second HTTP request based on the candidate parameters, and 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. The supplementary fields are obtained by traversing 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, the 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 full coverage of the target parameters when the target URL is constructed next time.

[0050] In addition, in one embodiment, referring to Figure 3 The test platform is connected to a plurality of optional systems, each optional system is associated with a plurality of candidate APIs, and step S50 specifically includes but is not limited to the following steps: S51, determining the target parameter corresponding to the target field as a use case parameter, and constructing a use case URL based on the use case parameter and the reference URL; S52, constructing a use case name based on the selected target system, target API, target parameter, and target field; S53, writing the test case name, the test case URL and the target parameters into the test case template, and constructing the test logic statement of the test case template based on each verification variable to obtain the interface test case; S54, associating the interface test case with the corresponding target system based on the use case name.

[0051] It should be noted that the test platform of this embodiment can be connected to multiple optional systems, such as Figure 1 As shown, the optional systems include budget system, human resources system, database, property asset system, etc. Each optional system includes its own corresponding candidate API. 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 candidate API and the optional system can be a many-to-many or many-to-one relationship.

[0052] It should be noted that in this embodiment, when selecting a target API, the target system is selected first, and after the target system is selected, all candidate APIs associated with the target system are displayed in the API list, such 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.

[0053] It should be noted that the target field of this embodiment is selected by the tester in the field list, so not all interface fields will be determined as target fields. Since each target parameter may correspond to multiple target fields, if the target fields of the target parameter are not selected, it can be determined that the target parameter does not involve this test case. Based on this, the target URL cannot be directly used as the test case URL of the test case. In this embodiment, the target parameter corresponding to the target field is the test case parameter. 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, the target parameter corresponding to the subjectName and subjectCode described in the above example is Account, and the target parameter corresponding to Total is Cost. The target URL includes Account, Cost and Time, but the use case URL only includes Account and Cost, which is different from the target URL.

[0054] It should be noted that in order to distinguish different interface test cases, this embodiment uses the target system, target API, target parameters and target fields to construct the case name when naming the test case, which can characterize the specific data source and function of the interface test case.

[0055] It should be noted that the test case template usually records the format code of the test case, which includes the definition code and test code of the test case. This embodiment dynamically fills in the definition code of the test case template after obtaining the use case name, use case URL and target parameters. The tester can determine the name of the test case based on the above definition code in the interface test case, the use case URL for obtaining data from the target API when building the interface test case, and the target parameters that need to be entered in the interface test case.

[0056] It should be noted that the verification variables of this embodiment include target fields, field addresses and corresponding target verification information. This embodiment constructs the test logic statements of the test case template based on the verification variables. For example, the address reference statement and the test execution statement are recorded in the test code, and the field address of the verification variable is filled in the address reference statement of the test code. The data comparison rule, data type and expected value recorded in the target verification information are filled in the test execution statement, so that 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, and then determine whether the data type is in compliance based on the test execution statement, and then use the expected value and data comparison rule to test the data returned by the target API to obtain an interface test case that can complete data testing.

[0057] It should be noted that after the interface test case is obtained, it is associated with the corresponding target system, and then the case name is used as an identifier to facilitate testers to quickly distinguish different interface test cases from the target system.

[0058] In addition, in one embodiment, referring to Figure 3 After executing step S54, the following steps are also included but not limited to: S541, acquiring API update information from system update information of any target system, wherein the API update information records at least one updated API; S542, when the update API includes at least one newly added candidate field, and the update API includes a full-field test case, obtaining updated response JSON data from the update API based on the case URL of the full-field test case, determining the field address of the candidate field from the updated response JSON data according to a recursive function, and constructing a newly added verification variable corresponding to the candidate field, constructing a new test case based on the newly added verification variable and the full-field test case, and retaining the full-field test case, wherein the full-field test case is an interface test case including each candidate field; S543, when the update API includes at least one deleted candidate field, determining associated test cases from all interface test cases of the update API based on the deleted candidate field, and removing the verification variable corresponding to the deleted candidate field in the associated test case; 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, all interface test cases of the associated API are copied to the updated API, and each interface test case is updated based on the name of the updated API and the name of the target system; S545, when the update API is a deleted API, delete all interface test cases corresponding to the update API.

[0059] 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, after obtaining the system update information of the target system, this embodiment extracts the API update information therefrom and determines the API recorded in the API update information as the updated API.

[0060] It should be noted that, based on the description of the above embodiment, when constructing an interface test case, the target field is selected from the field list, so the interface test case does not necessarily include all interface fields. After the present embodiment determines to update the API based on the API update information to add a candidate field, for the interface test case that does not include all interface fields, there is not necessarily a need to add candidate fields. However, for the full-field test case including all target fields, it is likely that all interface fields need to be covered. Therefore, after detecting the addition of new candidate fields, the present embodiment automatically determines the full-field test case from the interface test case of the target system. Since each interface test case has a test case URL, the response JSON data can be re-requested based on the test case URL recorded in the full-field test case. The specific method can refer to the description of the above embodiment, which will not be repeated here.

[0061] It should be noted that after obtaining the updated response JSON data, this embodiment queries according to the candidate fields based on a 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 new 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 previous full-field test case. Through the technical solution of this embodiment, in the case of having a full-field test case, a new full-field test case can be automatically generated on the test platform after detecting the addition of an API field. The tester does not need to perform related operations, and the tester can directly obtain the new full-field test case in the test interface for use.

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

[0063] 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 under the same enterprise configure budget systems respectively, after the interface test case configuration of the relevant API of the budget system of subsidiary A is completed, when the budget system of subsidiary B is introduced into the test platform, the architecture of the budget systems of different subsidiaries should be similar. When the number and functions of APIs under the budget system are similar, the interface fields and data structures can refer to the associated API. Therefore, this embodiment provides an association option in the API configuration interface. After adding a new API, you can select an associated API through the association option, copy all interface test cases of the associated API directly to the update API, and update the interface test cases based on the name of the updated API, so that the updated API can quickly deploy multiple interface test cases, greatly saving the test case generation time.

[0064] It is worth noting that for different optional systems, the target verification information in the interface test case can be a universal rule. The only difference is how to obtain data from the API according to the field address. In order to facilitate the copying of interface test cases from the associated API, this embodiment uses the same data structure and the field address of the interface field is obtained by traversing the recursive function. Therefore, the field address actually represents the position of the interface field in the API data structure. Therefore, it can be determined that if the function and data structure of the updated API and the associated API are the same, after the use case URL is adjusted to point to the correct API, the correct data can be obtained directly using the same field address. Of course, if the data structure of the API is different, do not select the associated API and Figure 2 The steps of the illustrated embodiment can be used to reconstruct the interface test case.

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

[0066] In addition, in one embodiment, referring to Figure 3 Step S20 specifically includes but is not limited to the following steps: S21, constructing a recursive path in the recursive function, and determining the response JSON data as a recursive call object of the recursive function, wherein the initial value of the recursive path is empty; S22, whenever a target node is traversed, the node path of the target node is written into the recursive path, and data is extracted at the target node using each candidate field as an extraction index. When the interface field is successfully extracted, the current recursive path is determined as the field path of the interface field; S23, when the target node does not include a child node, clear the recursive path and determine the response JSON data as the next recursive call object; S24, when the target node includes a child node, the node path of the child node is added to the recursive path, and the target node is determined as the next recursive call object of the recursive function.

[0067] It should be noted that, according to the description of the above embodiment, the recursive function can use the Extract_Data function. In order to determine the field path, this embodiment uses the response JSON data as the default calling 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 reads its root node for data extraction, so the node path is the root node path, writes the recursive path, and uses the candidate field as the data index to extract data from the data to which the root node belongs. If the 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 field when acquiring data.

[0068] It should be noted that if the target node does not include a child node, the recursive path is cleared, and the default calling object continues to be used as the recursive calling object, so that the Extract_Data function traverses from the response JSON data to the next root node.

[0069] For example, Figure 1 As 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}". After extracting the interface field from it, the recursive address is updated to "Content.result.bodyList{i}".

[0070] If the i-th target node has no child nodes, record Content.result.bodyList{i} and update the recursive address to "Content.result.". Continue to call the response JSON function to traverse to the i+1-th target node. The node path is "bodyList{i+1}". Similarly, the obtained field address is "Content.result.bodyList{i+1}".

[0071] If the i-th target node includes child nodes, the i-th target node is the recursive call object of the Extract_Data function, thereby traversing to its lower-level child nodes. Taking the j-th (i is a positive integer) child node as an example, when the interface field is extracted, the node address of the child node is added on the basis of the recursive address being updated 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.

[0072] like Figure 4 As shown, Figure 4 The present invention also provides a test case dynamic generation device based on an API, including: The processor 401 may be implemented by a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application; The memory 402 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). The memory 402 can store an operating system and other application programs. When the technical solution provided in the embodiment of this specification is implemented by software or firmware, the relevant program code is stored in the memory 402, and the processor 401 calls and executes the API-based test case dynamic generation method of the embodiment of this application; Input / output interface 403, used to implement information input and output; Communication interface 404, used to realize communication interaction between the device and other devices, which can be realized through wired mode (such as USB, network cable, etc.) or wireless mode (such as mobile network, WIFI, Bluetooth, etc.); A bus 405 that transmits information between various components of the device (e.g., processor 401, memory 402, input / output interface 403, and communication interface 404); The processor 401 , the memory 402 , the input / output interface 403 and the communication interface 404 are connected to each other in communication within the device via the bus 405 .

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

[0074] An embodiment of the present application also provides a storage medium, which is a computer-readable storage medium and stores a computer program. When the computer program is executed by a processor, the above-mentioned API-based test case dynamic generation method is implemented.

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

[0076] It will be appreciated by those skilled in the art that all or some of the steps and systems in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. Some or all physical components may 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 may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or transient medium). As 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 instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically include computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0077] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the above implementation mode. Technical personnel familiar with the field can also make various equivalent deformations or substitutions under the shared conditions without violating the spirit of the present invention. These equivalent deformations or substitutions are all included in the scope defined by the claims of the present invention.

Claims

1. A method for dynamically generating test cases based on an API, characterized in that: Applied to a test platform, the test platform is preset with multiple candidate fields, and the method includes: In response to a user selecting a target API in an API list of a test interface, constructing a target URL based on a plurality of target parameters of the target API, and acquiring response JSON data from the target API based on the target URL, wherein the API list includes a plurality of preset candidate APIs; Traversing the data nodes of the response JSON data based on a preset recursive function, and determining the recursive path as the field path of the traversed interface field based on any traversed target node, wherein, when the target node includes a child node, the node path of the child node is added to the recursive path and then the target node is recursively called, or, when the target node does not include the child node, the recursive path is cleared and then the response JSON data is recursively called; Constructing a verification variable of the interface field based on the field path and target verification information, wherein the target verification information includes a data comparison rule, a data type, and an expected value that were set last time or by default; The field list constructed in the test interface displays each of the interface fields and the corresponding verification variables, and the selected interface field is determined as a target field; The target parameter 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.

2. The method for dynamically generating test cases based on an API according to claim 1, characterized in that: The test platform is preset with a preset request header of each candidate API, and the preset request header carries a preset authentication token, and the preset authentication token is used to pass the legitimacy verification of the corresponding candidate API; Building 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, including: Convert each of the target parameters into a target string, obtain a preset reference URL, and write each of the target strings into the query parameters of the reference URL to obtain the target URL; Obtain a target request header of the target API, and construct a first HTTP request based on the target URL and the target request header, wherein the first HTTP request is a GET request or a POST request; The first HTTP request is sent 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 an API according to claim 2, characterized in that: The test platform records the self-description information of each candidate API, and the corresponding content of the self-description information in the candidate API is all the 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 the string into the target URL; Build a field list in the test interface, including: When the self-description information of the target API is traversed 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; The field list is generated based on the comparison result of the target parameter and the interface parameter.

4. The method for dynamically generating test cases based on an API according to claim 3, characterized in that: Generating the field list based on the comparison result of the target parameter and the interface parameter includes: When the target parameter and the interface parameter completely match, generating the field list based on the target parameter; Alternatively, when at least one of the target parameters does not match the interface parameters, an abnormal prompt message is generated on the test interface, and the field list is generated based on each of the target parameters that match the interface parameters, wherein the abnormal prompt message records the target parameters that do not match the interface parameters; Alternatively, when at least one candidate parameter is determined, a first option and a second option are generated on the test interface, wherein the candidate parameter is the interface parameter that does not belong to the target parameter; When the first option is selected, generating the field list based on the target parameter; Alternatively, when the second option is selected, a second HTTP request is generated based on the candidate parameters and the reference URL, new response JSON data is obtained from the target API based on the second HTTP request, supplementary fields and corresponding field paths are obtained from the new response JSON data based on the recursive function, and the field list is constructed based on the interface fields and the supplementary fields.

5. The method for dynamically generating test cases based on an API according to claim 2, characterized in that: The test platform is connected to a plurality of optional systems, each of which is associated with a plurality of candidate APIs, and the target parameters and the verification variables corresponding to the target fields are input 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 a 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; Writing the use case name, the use case URL and the target parameter into the test case template, and constructing the test logic statement of the test case template based on each of the verification variables to obtain the interface test case; The interface test case is associated with the corresponding target system based on the use case name.

6. The method for dynamically generating test cases based on an API according to claim 5, characterized in that: After associating the interface test case with the corresponding target system based on the use case name, the method further includes: Acquire API update information from system update information of any target system, wherein the API update information records at least one updated API; When the update API includes at least one newly added candidate field, and the update API includes a full-field test case, the updated response JSON data is obtained from the update API based on the case URL of the full-field test case, the field address of the candidate field is determined from the updated response JSON data according to the recursive function, and a newly added verification variable corresponding to the candidate field is constructed, and a newly added test case is constructed based on the newly added verification variable and the full-field test case, and the full-field test case is retained, wherein the full-field test case is the interface test case including each of the candidate fields; When the update API includes at least one deleted candidate field, determining an associated test case from all interface test cases of the update API based on the deleted candidate field, and removing the verification variable corresponding to the deleted candidate field from the associated test case; When the update API is a newly added API, and an associated API is determined in the API list based on a user operation, all the interface test cases of the associated API are copied to the update API, and each interface test case is updated based on the name of the update API and the name of the target system; When the update API is a deleted API, all interface test cases corresponding to the update API are deleted.

7. The method for dynamically generating test cases based on an API according to claim 1, characterized in that: Traversing the data nodes of the response JSON data based on a preset recursive function, and determining the recursive path as the field path of the traversed interface field based on any traversed target node, including: Constructing the recursive path in the recursive function, and determining the response JSON data as a recursive call object of the recursive function, wherein an initial value of the recursive path is empty; Whenever a target node is traversed, the node path of the target node is written into the recursive path, and data is extracted at the target node using each of the candidate fields as an extraction index. When the interface field is successfully extracted, the current recursive path is determined as the field path of the interface field; When the target node does not include a child node, clear the recursive path, and determine the response JSON data as the next recursive call object; When the target node includes a child node, the node path of the child node is added to the recursive path, and the target node is determined 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 coupling with the at least one control processor; The memory stores instructions that can be executed by the at least one control processor, and 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 as described in any one of claims 1 to 7.

9. An electronic device, characterized in that: It includes the API-based test case dynamic generation device as described in claim 8.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the API-based test case dynamic generation method as described in any one of claims 1 to 7.

Images