Api interface input verification test method, test device and electronic equipment

Abstract

Embodiments of the present application provide an API interface input verification test method, a test device and an electronic device, wherein the method comprises: obtaining an interface document of a target interface, parsing the interface document to obtain request information; determining whether a first request parameter exists in the request information, and in the case where the first request parameter exists, obtaining error response information output by the target interface in the case where a second request parameter is input; constructing an abnormal data test set according to the request parameter, constructing at least an interface input test case according to the request information, performing input verification test on the target interface by using the interface input test case, and obtaining an abnormal data test result; determining whether the abnormal data test result contains the error response information, and in the case where the abnormal data test result contains the error response information, determining that the input verification test of the target interface succeeds, and in the case where the abnormal data test result does not contain the error response information, determining that the input verification test of the target interface fails. The problem of time and labor consumption caused by manually writing interface input test cases is solved.

Description

Technical Field

[0001] This application relates to the field of computers, and more specifically, to an API interface input verification test method, test apparatus, computer-readable storage medium, and electronic device. Background Technology

[0002] APIs (Application Programming Interfaces) are a key component of modern mobile, SaaS (Software as a Service), and web applications. In recent years, API usage has exploded, with API communication accounting for a vast majority of internet traffic. However, they also provide malicious hackers with multiple avenues to access data, becoming a source of numerous security problems. Compared to zero-day exploits, phishing, and supply chain risks, APIs are the most vulnerable to attackers. This is because APIs are inherently public and exposed, facilitating their access and location. Furthermore, APIs carrying large amounts of important data and authentication information often directly interface with core systems, offering high potential gains for attackers who successfully breach them. When software products use numerous APIs, it's difficult to validate input parameters or implement fine-grained access control, making it easy for attackers to find vulnerabilities to bypass boundary defenses, thus hindering prevention. Therefore, API testing is essential in software development, encompassing both functional and security testing. Implementing API input parameter validation testing typically requires comprehensive interface documentation and corresponding test cases.

[0003] Existing API asset inventory methods require manual identification and organization or the use of API generation tools. APIDOC is a simple RESTful API documentation generation tool that can extract formatted content from code comments to generate documentation. Interface documentation varies in format, but generally includes API request methods, parameter templates, and response templates. However, existing APIDOC tools can only generate interface documentation, requiring manual organization of the documentation and writing of corresponding test cases. Some test cases, while testing different objects, involve repetitive test logic, resulting in low coding efficiency. Therefore, each test case is written manually, which is time-consuming, labor-intensive, and inefficient.

[0004] Therefore, there is an urgent need for a method that can efficiently perform interface input validation testing. Summary of the Invention

[0005] This application provides an API interface input validation test method, test device, computer-readable storage medium, and electronic device to at least solve the problem of time-consuming and labor-intensive manual writing of interface input test cases in related technologies.

[0006] According to one embodiment of this application, an API interface input validation test method is provided, comprising: obtaining an interface document of a target interface; parsing the interface document to obtain request information, wherein the interface document contains the request information, the request information including at least one of a request location, a request method, and a first request parameter, the request information being information input to the target interface; determining whether the first request parameter exists in the request information; if the first request parameter exists, obtaining error response information output by the target interface when a second request parameter is input, wherein the second request parameter is an incorrect request parameter and is different from the first request parameter; constructing an abnormal data test set based on the request parameter; constructing interface input test cases at least based on the request information; performing input validation tests on the target interface using the interface input test cases; obtaining abnormal data test results, wherein the abnormal data test results are output by the target interface when elements in the abnormal data test set are input; determining whether the abnormal data test results contain the error response information; if they contain it, determining that the input validation test of the target interface is successful; if they do not contain it, determining that the input validation test of the target interface is unsuccessful.

[0007] In one exemplary embodiment, obtaining the error response information output by the target interface when the second request parameter is input includes: obtaining the error response information output by the target interface when the target interface outputs error response information after the second request parameter is input to the target interface.

[0008] In one exemplary embodiment, if the target interface does not output the error response information, the target interface is marked as having no failure response.

[0009] In one exemplary embodiment, constructing an abnormal data test set based on the request parameters includes: constructing a first abnormal data test set based on multiple data of different types from the request parameters and within the range of the request parameters; constructing a second abnormal data test set based on multiple data of the same type as the request parameters but not within the range of the request parameters; and constructing a third abnormal data test set based on multiple SQL injection statements.

[0010] In one exemplary embodiment, constructing interface input test cases based on the request information includes: constructing a first interface input test case based on the request information and a first abnormal data test set; constructing a second interface input test case based on the request information and a second abnormal data test set; and constructing a third interface input test case based on the request information and a third abnormal data test set.

[0011] In an exemplary embodiment, the interface input test case is used to perform input validation testing on the target interface to obtain abnormal data test results, including: constructing a test interface corresponding to the interface input test case based on the interface input test case, inputting the elements of the abnormal data test set into the test interface respectively, obtaining the output results of the test interface, and obtaining the abnormal data test results.

[0012] In an exemplary embodiment, determining whether the abnormal data test result contains the error response information includes: determining whether the interface input test case is successfully parsed based on the response content and status code in the abnormal data test result; if the parsing is successful, matching the abnormal data test set corresponding to the response content; matching the corresponding request parameters based on the abnormal data test set; and matching the corresponding response content based on the request parameters; and determining whether the abnormal data test result contains the error response information.

[0013] In one exemplary embodiment, if parsing fails, it is determined whether the status code is in a predetermined format; if the status code is not in the predetermined format, it is determined that the input validation test of the target interface is abnormal; if the status code is in the predetermined format, it is determined whether the abnormal data test result contains the error response information; if it does, it is determined that the input validation test of the target interface is successful; if it does not, it is determined that the input validation test of the target interface is failed.

[0014] In an exemplary embodiment, after performing input validation testing on the target interface using the interface input test case, the method further includes: determining whether all the abnormal data test sets corresponding to the request parameters have been validated; if all validations are completed, outputting the abnormal data test results; if not all validations are completed, inputting the elements of the abnormal data test sets corresponding to the unvalidated request parameters into the interface input test case.

[0015] In an exemplary embodiment, after determining whether the first request parameter exists in the request information, the method further includes: if the first request parameter does not exist, marking the target interface as not requiring testing.

[0016] According to another embodiment of this application, an API interface input validation testing device is provided, comprising: an execution module, configured to acquire an interface document of a target interface, parse the interface document to obtain request information, wherein the interface document contains the request information, and the request information includes at least one of a request location, a request method, and a first request parameter, wherein the request information is information input to the target interface; a first acquisition module, configured to determine whether the first request parameter exists in the request information, and if the first request parameter exists, acquire error response information output by the target interface when a second request parameter is input, wherein the second request parameter is an incorrect request parameter and is different from the first request parameter; a second acquisition module, configured to construct an abnormal data test set according to the request parameter, construct interface input test cases at least according to the request information, perform input validation testing on the target interface using the interface input test cases, and acquire abnormal data test results, wherein the abnormal data test results are output by the target interface when elements in the abnormal data test set are input; and a determination module, configured to determine whether the abnormal data test results contain the error response information, and if they do, determine that the input validation test of the target interface is successful, and if they do not, determine that the input validation test of the target interface is unsuccessful.

[0017] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0018] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0019] This application parses the interface documentation of the target interface to obtain request information, then retrieves the error response information output by the target interface when a second request parameter is input, constructs an exception data test set based on the first request parameter in the request information, and constructs interface input test cases based on the request information and the exception data test set. The above interface input test cases automatically complete the input validation test of the target interface, then obtain the exception data test results, and determine whether the exception data test results contain the aforementioned error response information, thereby determining whether the target interface can undergo input validation testing. Compared with existing methods that require manually writing interface input test cases, this application eliminates the need for manual writing of interface input test cases. It automatically constructs exception data test sets and interface input test cases based on the interface documentation and request information within the interface documentation, thus automatically performing interface input validation testing on the target interface. Therefore, it solves the time-consuming and labor-intensive problem caused by manually writing interface input test cases, achieving efficient interface input validation testing. Attached Figure Description

[0020] Figure 1 This is a hardware structure block diagram of a mobile terminal for an API interface input verification test method according to an embodiment of this application;

[0021] Figure 2 This is a flowchart of an API interface input validation test method according to an embodiment of this application;

[0022] Figure 3 This is a flowchart of a specific API interface input verification test method according to an embodiment of this application;

[0023] Figure 4 This is a flowchart of another specific API interface input verification test method according to an embodiment of this application;

[0024] Figure 5 This is a schematic diagram of the structure of an API interface input verification test device according to an embodiment of this application.

[0025] The above figures include the following reference numerals:

[0026] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device. Detailed Implementation

[0027] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0028] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0029] The methods and embodiments provided in this application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for an API interface input verification test method according to an embodiment of this application. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0030] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the API interface input verification test method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0031] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0032] For ease of description, the following explains some of the nouns or terms used in the embodiments of this application:

[0033] API: Application Programming Interface, abbreviated as API.

[0034] APIDOC is a tool that can automatically generate API interface documentation directly from comments in source code.

[0035] This embodiment provides an API interface input validation test method running on the aforementioned mobile terminal. Figure 2 This is a flowchart of an API interface input validation test method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0036] Step S202: Obtain the interface document of the target interface, parse the interface document to obtain the request information, wherein the interface document contains the request information, and the request information includes at least one of the following: request location, request method and first request parameter, and the request information is the information input to the target interface;

[0037] Specifically, when performing input validation tests on interfaces during software functional testing, APIDOC-generated interface documentation is typically used to organize the system APIs. APIDOC tools extract content in a specific format from code comments to generate documentation. The format of interface documentation varies, but it generally includes API request methods, request parameter templates, and response templates. By parsing the interface documentation, the request information can be obtained. The request information includes the API request URL (request location), request method, request parameter type, request parameter boundary values, and the number of request parameters. The first request parameter is the parameter in the interface documentation that matches the request parameter type and is within the request parameter boundary values, and is about to be input to the target interface.

[0038] Step S204: Determine whether the first request parameter exists in the above request information. If the first request parameter exists, obtain the error response information output by the target interface when the second request parameter is input. The second request parameter is an incorrect request parameter and is different from the first request parameter.

[0039] Specifically, since this application validates the input to the target interface, it first needs to determine whether a request parameter, i.e., a first request parameter, exists in the request information obtained from parsing the interface documentation of the target interface. Only if the first request parameter exists is it necessary to perform input validation testing on the target interface. The presence of the first request parameter indicates that input validation testing of the target interface is required. Therefore, the second request parameter, which does not conform to the template of the request parameter in the request information, is first input to the target interface. It is then determined whether the target interface outputs an error response. If the target interface outputs an error response, the error response information is obtained for subsequent input validation testing of the target interface.

[0040] Step S206: Based on the above request parameters, construct an abnormal data test set, construct interface input test cases based at least on the above request information, use the above interface input test cases to perform input verification tests on the above target interface, and obtain abnormal data test results, wherein the above abnormal data test results are the output of the above target interface when elements in the abnormal data test set are input;

[0041] Specifically, assuming the number of request parameters in the request information parsed from the target interface's documentation is x, an exception data test set is constructed based on the request parameters. Each time, the number of elements in the exception data test set is y+1, where y+1 ≤ x, and y is initially set to 0. This means that after validating a single input parameter, it is also necessary to validate combinations of multiple parameters. This avoids situations where the target interface cannot recognize incorrect parameters when multiple parameters are input simultaneously, thus comprehensively validating the target interface. Based on the request information and the exception data test set, interface input test cases can be constructed to perform input validation tests on the target interface. Based on the exception data test results, it can be determined whether the target interface can recognize incorrect input information.

[0042] Step S208: Determine whether the above abnormal data test result contains the above error response information. If it does, determine that the input validation test of the above target interface is successful. If it does not, determine that the input validation test of the above target interface is unsuccessful.

[0043] Specifically, after performing input validation tests on the target interface using the aforementioned interface input test cases and obtaining abnormal data test results, it is necessary to determine whether the abnormal data test results contain the error response information mentioned above. If they do, it indicates that the target interface can recognize the erroneous input information and output response information to indicate that the input information is incorrect, thus confirming that the input validation test of the target interface is successful. If they do not, it indicates that the target interface cannot recognize the erroneous input information, thus confirming that the input validation test of the target interface has failed, i.e., the target interface has not passed the validation.

[0044] Through the above steps, the request information is obtained by parsing the target interface's documentation. Then, the error response information output by the target interface when the second request parameter is input is obtained. An exception data test set is constructed based on the first request parameter in the request information, and interface input test cases are constructed based on the request information and the exception data test set. The above interface input test cases are used to automatically complete the input validation test of the target interface. Then, the exception data test results are obtained, and it is determined whether the exception data test results contain the aforementioned error response information, thereby determining whether the target interface can undergo input validation testing. Compared with existing methods that require manually writing interface input test cases, this application eliminates the need for manual writing of interface input test cases. It automatically constructs exception data test sets and interface input test cases based on the target interface's documentation and the request information within the documentation, automatically performing interface input validation testing on the target interface. Therefore, it solves the time-consuming and labor-intensive problem caused by manually writing interface input test cases, achieving efficient interface input validation testing.

[0045] The entity performing the above steps can be a server, but is not limited to this.

[0046] In some embodiments of this application, obtaining the error response information output by the target interface when the second request parameter is input includes: after the second request parameter is input to the target interface, if the target interface outputs error response information, obtaining the error response information output by the target interface. Through the above steps, it can be determined whether the target interface can recognize the incorrect input parameter and record the error response information. This allows subsequent interface input validation tests to determine whether the target interface has successfully validated based on the error response information.

[0047] Specifically, the second request parameter of the template that does not conform to the request parameters in the request information is input to the target interface. It is then determined whether the target interface outputs an error response. When the target interface outputs an error response, it means that the target interface can recognize the incorrect input parameter information. The error response information is then obtained for subsequent interface input verification tests.

[0048] In one exemplary embodiment, if the target interface does not output the aforementioned error response information, the target interface is marked as having no failure response. Through the above steps, target interfaces that cannot recognize error input information can be marked, facilitating subsequent processing of those target interfaces.

[0049] Specifically, the second request parameter of the template that does not conform to the request parameters in the request information is input to the target interface. It is then determined whether the target interface outputs an error response. If the target interface does not output an error response, it means that the target interface cannot recognize the incorrect input parameter information, and therefore the target interface is marked as having no failure response.

[0050] In one exemplary embodiment, constructing an abnormal data test set based on the aforementioned request parameters includes: constructing a first abnormal data test set based on multiple data items of a different type from the aforementioned request parameters but within the range of the aforementioned request parameters; constructing a second abnormal data test set based on multiple data items of the same type as the aforementioned request parameters but outside the range of the aforementioned request parameters; and constructing a third abnormal data test set based on multiple SQL injection statements. Through these steps, multiple types of abnormal data test sets are constructed, allowing for validation of the target interface under multiple different input parameter conditions, thereby improving the accuracy of the validation.

[0051] Specifically, request parameters can be categorized into characters, numbers, and special symbols. The range of request parameters is their length range, for example, 5 to 30 characters. Based on multiple data sets that differ in type from the above request parameters but fall within the above request parameter range, a first abnormal data test set is constructed. For example, if the request parameter type is required to be English characters "a~z, A~Z" and the request parameter range is required to be 5 to 30 characters, then the first abnormal data test set can be data consisting of integers "0~9" for 5 to 30 characters, or special characters such as "!@#$ / ?|\." for 5 to 30 characters. If the request parameter type is required to be Chinese characters (e.g., requiring a name input) and the request parameter range is required to be less than 20 characters, then the first abnormal data test set can be data consisting of numbers less than 20 characters, such as "0123", or special characters less than 20 characters, such as "??!!*". In other words, the first abnormal data test set is a collection of data that differs in type from the request parameters but meets the request parameter range requirements. A second abnormal data test set is constructed based on multiple data of the same type as the above request parameters but outside the range of the above request parameters. For example, if the request parameter type is required to be English letters "a~z, A~Z" and the length of the request parameter is required to be 5~30 characters, then the second abnormal data test set can be data of 1~4 characters and greater than 30 characters composed of the characters "a~z, A~Z", such as two "Aa" and / or 100 characters "aaaaaa……a". If the request parameter type is required to be numbers "0~9" and the range of the request parameter is required to be greater than 10 characters, then the second abnormal data test set can be data of less than 10 characters composed of "0~9", such as "67954". This can test whether the target interface performs input validation tests on the data boundary length range of the request parameters. Finally, commonly used SQL injection statements are used as elements in the third abnormal data test set. This application does not impose specific restrictions on the composition of the above first, second, and third abnormal data test sets.

[0052] In one exemplary embodiment, constructing interface input test cases based on the aforementioned request information includes: constructing a first interface input test case based on the aforementioned request information and a first abnormal data test set; constructing a second interface input test case based on the aforementioned request information and a second abnormal data test set; and constructing a third interface input test case based on the aforementioned request information and a third abnormal data test set. Through these steps, interface input test cases are constructed, thus automatically generating interface input test cases to validate the input of the target interface.

[0053] Specifically, interface input test cases are constructed based on the request information and the abnormal data test set. Specifically, a first interface input test case is constructed based on the first abnormal data test set. Since the first abnormal data test set consists of multiple data sets of different types than the aforementioned request parameters but within the range of the aforementioned request parameters, the first interface input test case is used to test whether the target interface validates the parameter type of the input parameters. A second interface input test case is constructed based on the second abnormal data test set. Since the second abnormal data test set consists of multiple data sets of the same type as the aforementioned request parameters but outside the range of the aforementioned request parameters, the second interface input test case is used to test whether the target interface validates the length of the input parameters. A third interface input test case is constructed based on the third abnormal data test set. Since the third abnormal data test set is constructed based on multiple SQL injection statements, the third interface input test case is used to test whether the target interface validates the injected characters to avoid injection vulnerabilities. It should be noted that in practical applications, abnormal data test sets and corresponding interface input test cases can be constructed according to specific data. For example, the test parameters can be modified to other test items, such as API permission testing. Based on different permission levels of API requests, the above abnormal data test sets can be constructed to quickly detect whether each API has unauthorized access security risks. This application does not restrict the specific application scenarios of the aforementioned abnormal data test set and interface test cases.

[0054] In one exemplary embodiment, the target interface is subjected to input validation testing using the aforementioned interface input test cases to obtain abnormal data test results. This includes: constructing a test interface corresponding to the aforementioned interface input test cases; inputting the elements of the aforementioned abnormal data test set into the aforementioned test interface; obtaining the output results of the aforementioned test interface; and thus obtaining the aforementioned abnormal data test results. Through this method, a test interface is constructed to test the elements in the abnormal data test set.

[0055] Specifically, a test interface is constructed based on the request address in the request information. The test interface is used to output the response information after inputting the elements of the abnormal data test set, that is, to obtain the abnormal data test results.

[0056] In an exemplary embodiment, determining whether the above-mentioned abnormal data test result contains the above-mentioned error response information includes: determining whether the above-mentioned interface input test case was successfully parsed based on the response content and status code in the above-mentioned abnormal data test result; if the parsing is successful, matching the above-mentioned abnormal data test set corresponding to the above-mentioned response content; matching the corresponding above-mentioned request parameters based on the above-mentioned abnormal data test set; and matching the corresponding above-mentioned error response information based on the above-mentioned request parameters; and determining whether the above-mentioned abnormal data test result contains the above-mentioned error response information. Through this method, matching the corresponding request parameters based on the abnormal data test set, and further matching the corresponding error response information, it is possible to determine whether the target interface can recognize the erroneous input parameter information and output error response information.

[0057] Specifically, the response content and status code in the abnormal data test results can be JSON / text / html, etc. After the interface input test case is successfully parsed, the abnormal data test set corresponding to the above response content is matched. The above request parameters are matched according to the above abnormal data test set, and the above error response information is matched according to the above request parameters. That is, the response content of the first interface input test case is matched with the request parameters, and the corresponding error response information is matched according to the request parameters. The response content of the second interface input test case is matched with the request parameters, and the corresponding error response information is matched according to the request parameters. The response content of the third interface input test case is matched with the request parameters, and the corresponding error response information is matched according to the request parameters. It is then determined whether the response content of the first interface input test case contains error response information. If the response content contains error response information, it indicates that the target interface can recognize the input erroneous parameter information, so the verification can be determined to be successful, that is, the target interface passes the verification. If the response content does not contain error response information, it indicates that the target interface cannot recognize the input erroneous parameter information, so the verification can be determined to be unsuccessful, that is, the target interface does not pass the verification.

[0058] In one exemplary embodiment, if parsing fails, it is determined whether the status code is in a predetermined format. If the status code is not in the predetermined format, the input validation test of the target interface is determined to be abnormal. If the status code is in the predetermined format, it is determined whether the abnormal data test result contains the error response information. If it does, the input validation test of the target interface is determined to be successful; otherwise, the input validation test of the target interface is determined to be unsuccessful. Through the above steps, when the interface input test case parsing fails, the status code is used to further determine whether the validation was successful.

[0059] Specifically, the predefined format can be "2xx series". The system checks whether the status code is "2xx series". If the status code is "2xx series", the system continues to check whether the above abnormal data test result contains the above error response information. If it contains the information, the system can be determined to be successful. If it does not contain the information, the system is determined to be unsuccessful. If the status code is not "2xx series", the system is determined to be a verification exception for the target interface.

[0060] In one exemplary embodiment, after performing input validation testing on the target interface using the aforementioned interface input test cases, the method further includes: determining whether all the abnormal data test sets corresponding to the aforementioned request parameters have been validated; if all validations are complete, outputting the abnormal data test results; if not all validations are complete, inputting the elements from the abnormal data test sets corresponding to the unvalidated request parameters into the aforementioned interface input test cases. Through these steps, abnormal data test cases corresponding to multiple request parameters can be validated, improving the completeness of the validation.

[0061] Specifically, since the abnormal test dataset is constructed based on the request parameters, and the number of elements in the abnormal test dataset is y+1≤x, it is necessary to determine whether all x request parameters have been validated to ensure that no request parameters are missed and to improve the completeness of the validation.

[0062] In one exemplary embodiment, after determining whether the first request parameter exists in the request information, the method further includes: if the first request parameter does not exist, marking the target interface as not requiring testing. This method determines whether testing of the target interface is necessary based on the presence or absence of the request parameter.

[0063] Specifically, since this application validates the input of the interface, when the interface does not have input parameters, i.e., request parameters, there is no need to validate the interface. Therefore, the target interface is marked as not requiring testing. However, there may be cases where the request parameters are parsed incorrectly when the interface documentation obtains the request information, resulting in the absence of request parameters. Therefore, in order to more comprehensively represent the cases where request parameters are not present, it can be marked as not requiring testing or as cases where the interface documentation parses parameters incorrectly.

[0064] To enable those skilled in the art to better understand the technical solution of this application, the implementation process of the API interface input verification test method of this application will be described in detail below with reference to specific embodiments.

[0065] This embodiment relates to a specific API interface input validation test method, such as... Figure 3 and Figure 4 As shown, it includes the following steps:

[0066] Step S1: Input the APIDOC interface documentation and traverse and parse the API interfaces;

[0067] Step S2: Detect the API method field and output the HTTP request type (get / put / post / patch / delete, etc.), which is used to build HTTP requests for testing after generating test cases;

[0068] Step S3: Parse and obtain the required parameters param (request parameters) for the API request, and check if they exist; if they exist, obtain the number of input parameters and their respective data types and data ranges; if they do not exist, mark this interface as not requiring testing or as having incorrect documentation.

[0069] Step S4: Parse and retrieve the error response when the API request fails, such as error message, and check if it exists; if it exists, retrieve the response information when the API fails to send data to determine whether it is a normal failure response; if it does not exist, mark this interface as having no failure response.

[0070] Step S5: Parse APIDOC to obtain the URL (request address), request method, request parameter type, request parameter boundary value and number of request parameters x of the API request to be tested, obtain the number of input parameters and their respective data types, pass them to the exception test data construction module, and generate input validation test cases (interface input test cases), that is, construct the request request using the request method of the Python development language;

[0071] Step S6: Extract y+1 parameters using abnormal data (abnormal data test set) (y is initially equal to 0), generate abnormal request parameter data according to the following three rules and put it into the request to perform different types of input validation tests;

[0072] Step S7: The three types of abnormal data test cases (interface input test cases) are as follows: The first type of abnormal data test case is a non-data type but meets the data boundary requirements, testing whether this interface validates the data type of the input parameter; the second type of abnormal data test case is the same data type but exceeds the data boundary value requirements, testing whether this interface validates the length of the input data; the third type of abnormal data test case is a common SQL injection statement, testing whether this interface validates the injection characters / avoids injection vulnerabilities.

[0073] Step S8: Construct a request test interface using abnormal data test cases;

[0074] Step S9: Obtain all system responses (abnormal data test results) after the request is sent, obtain the HTTP status code and response content (json / text / html, etc.), and extract the response content;

[0075] Step S10: Determine whether the API parsing of this abnormal data test case is successful. If the parsing is successful, match the data type input in the API parsing data to the response data when the verification test fails, match the data length boundary input in the API parsing data to the response data when the verification test fails, and match the injection vulnerability statement input in the API parsing data to the response data when the verification test fails.

[0076] Step S11: Determine whether the response content contains an error message. If it does, determine that the interface input validation test was successful and return the test result. If the response content does not contain an error message, determine that the interface input validation test failed and return the test result.

[0077] Step S12: If the API parsing of the abnormal data test case fails, treat it as a normal interface request. Check if the HTTP status code is in the 2xx series. If it is, check if the response content contains an error message. If it does, consider the interface input validation test successful and report the test result. If the response content does not contain an error message, consider the interface input validation test failed and report the test result. If not, consider the interface input validation test abnormal and report the test result.

[0078] Step S13: Finally, summarize the output results of this solution, automatically parse the APIDOC interface document, obtain the abnormal data input validation test cases corresponding to all interfaces, and the input validation test results of all interfaces, and quickly perform input validation tests on the API assets of the system under test to ensure the security of the system API assets.

[0079] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0080] This embodiment also provides an API interface input verification and testing device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0081] Figure 5 This is a schematic diagram of the structure of an API interface input verification test device according to an embodiment of this application, such as... Figure 5 As shown, the verification device includes:

[0082] Execution module 22 is used to obtain the interface document of the target interface, parse the interface document, and obtain request information, wherein the interface document contains the request information, and the request information includes at least one of the following: request location, request device, and first request parameter, and the request information is information input to the target interface;

[0083] Specifically, when performing input validation tests on interfaces during software functional testing, APIDOC-generated interface documentation is typically used to organize the system's APIs. APIDOC tools extract content in a specific format from code comments to generate documentation. While the format of interface documentation varies, it generally includes the API request mechanism, request parameter templates, and response templates. Parsing the interface documentation reveals the request information, including the API request URL (request location), request mechanism, request parameter types, request parameter boundary values, and the number of request parameters. The first request parameter is the parameter in the interface documentation that matches the request parameter type and is within the request parameter boundary values, and is the parameter to be input into the target interface.

[0084] The first acquisition module 24 is used to determine whether the first request parameter exists in the above request information. If the first request parameter exists, the module acquires the error response information output by the target interface when the second request parameter is input. The second request parameter is an incorrect request parameter and is different from the first request parameter.

[0085] Specifically, since this application validates the input to the target interface, it first needs to determine whether a request parameter, i.e., a first request parameter, exists in the request information obtained from parsing the interface documentation of the target interface. Only if the first request parameter exists is it necessary to perform input validation testing on the target interface. The presence of the first request parameter indicates that input validation testing of the target interface is required. Therefore, the second request parameter, which does not conform to the template of the request parameter in the request information, is first input to the target interface. It is then determined whether the target interface outputs an error response. If the target interface outputs an error response, the error response information is obtained for subsequent input validation testing of the target interface.

[0086] The second acquisition module 26 is used to construct an abnormal data test set according to the above request parameters, construct interface input test cases at least according to the above request information, perform input verification tests on the above target interface using the above interface input test cases, and obtain abnormal data test results, wherein the above abnormal data test results are the output of the above target interface when elements in the abnormal data test set are input;

[0087] Specifically, assuming the number of request parameters in the request information parsed from the target interface's documentation is x, an exception data test set is constructed based on the request parameters. Each time, the number of elements in the exception data test set is y+1, where y+1 ≤ x, and y is initially set to 0. This means that after validating a single input parameter, it is also necessary to validate combinations of multiple parameters. This avoids situations where the target interface cannot recognize incorrect parameters when multiple parameters are input simultaneously, thus comprehensively validating the target interface. Based on the request information and the exception data test set, interface input test cases can be constructed to perform input validation tests on the target interface. Based on the exception data test results, it can be determined whether the target interface can recognize incorrect input information.

[0088] The determination module 28 is used to determine whether the above abnormal data test results contain the above error response information. If they do, the input validation test of the above target interface is determined to be successful; if they do not, the input validation test of the above target interface is determined to be unsuccessful.

[0089] Specifically, after performing input validation tests on the target interface using the aforementioned interface input test cases and obtaining abnormal data test results, it is necessary to determine whether the abnormal data test results contain the error response information mentioned above. If they do, it indicates that the target interface can recognize the erroneous input information and output response information to indicate that the input information is incorrect, thus confirming that the input validation test of the target interface is successful. If they do not, it indicates that the target interface cannot recognize the erroneous input information, thus confirming that the input validation test of the target interface has failed, i.e., the target interface has not passed the validation.

[0090] Through the above steps, the interface documentation of the target interface is parsed to obtain the request information. Then, the error response information output by the target interface when the second request parameter is input is obtained. An abnormal data test set is constructed based on the first request parameter in the request information, and interface input test cases are constructed based on the request information and the abnormal data test set. The above interface input test cases are used to automatically complete the input validation test of the target interface. Then, the abnormal data test results are obtained, and it is determined whether the abnormal data test results contain the above error response information, thereby determining whether the target interface can perform input validation testing. Compared with the prior art, which requires manual writing of interface input test cases, this application eliminates the need for manual writing of interface input test cases. It automatically constructs an abnormal data test set and interface input test cases based on the interface documentation of the target interface and the request information in the interface documentation, and automatically performs interface input validation testing on the target interface. Therefore, it can solve the problem of time-consuming and labor-intensive manual writing of interface input test cases, achieving the effect of efficient interface input validation testing.

[0091] In some embodiments of this application, the first acquisition module includes an acquisition submodule, used to acquire the error response information output by the target interface after the target interface outputs the second request parameter and the second request parameter is input to the target interface. Through the above steps, it can be determined whether the target interface can recognize the erroneous input parameter and record the error response information. This allows subsequent interface input verification tests to determine whether the target interface has successfully verified based on the error response information.

[0092] Specifically, the second request parameter of the template that does not conform to the request parameters in the request information is input to the target interface. It is then determined whether the target interface outputs an error response. When the target interface outputs an error response, it means that the target interface can recognize the incorrect input parameter information. The error response information is then obtained for subsequent interface input verification tests.

[0093] In one exemplary embodiment, the first acquisition module further includes a first marking submodule, used to mark the target interface as having no failure response when the target interface does not output the aforementioned error response information. Through the above steps, target interfaces that cannot recognize error input information can be marked, facilitating subsequent processing of the target interface.

[0094] Specifically, the second request parameter of the template that does not conform to the request parameters in the request information is input to the target interface. It is then determined whether the target interface outputs an error response. If the target interface does not output an error response, it means that the target interface cannot recognize the incorrect input parameter information, and therefore the target interface is marked as having no failure response.

[0095] In one exemplary embodiment, the second acquisition module includes a first construction submodule, a second construction submodule, and a third construction submodule. The first construction submodule is used to construct a first abnormal data test set based on multiple data sets of different types from the request parameters but within the range of the request parameters. The second construction submodule is used to construct a second abnormal data test set based on multiple data sets of the same type as the request parameters but outside the range of the request parameters. The third construction submodule is used to construct a third abnormal data test set based on multiple SQL injection statements. Through these steps, multiple types of abnormal data test sets are constructed, allowing for validation of the target interface under multiple different input parameter conditions, thus improving the accuracy of the validation.

[0096] Specifically, request parameters can be categorized into characters, numbers, and special symbols. The range of request parameters is their length range, for example, 5 to 30 characters. Based on multiple data sets that differ in type from the above request parameters but fall within the above request parameter range, a first abnormal data test set is constructed. For example, if the request parameter type is required to be English characters "a~z, A~Z" and the request parameter range is required to be 5 to 30 characters, then the first abnormal data test set can be data consisting of integers "0~9" for 5 to 30 characters, or special characters such as "!@#$ / ?|\." for 5 to 30 characters. If the request parameter type is required to be Chinese characters (e.g., requiring a name input) and the request parameter range is required to be less than 20 characters, then the first abnormal data test set can be data consisting of numbers less than 20 characters, such as "0123", or special characters less than 20 characters, such as "??!!*". In other words, the first abnormal data test set is a collection of data that differs in type from the request parameters but meets the request parameter range requirements. A second abnormal data test set is constructed based on multiple data of the same type as the above request parameters but outside the range of the above request parameters. For example, if the request parameter type is required to be English letters "a~z, A~Z" and the length of the request parameter is required to be 5~30 characters, then the second abnormal data test set can be data of 1~4 characters and greater than 30 characters composed of the characters "a~z, A~Z", such as two "Aa" and / or 100 characters "aaaaaa……a". If the request parameter type is required to be numbers "0~9" and the range of the request parameter is required to be greater than 10 characters, then the second abnormal data test set can be data of less than 10 characters composed of "0~9", such as "67954". This can test whether the target interface performs input validation tests on the data boundary length range of the request parameters. Finally, commonly used SQL injection statements are used as elements in the third abnormal data test set. This application does not impose specific restrictions on the composition of the above first, second, and third abnormal data test sets.

[0097] In one exemplary embodiment, the second acquisition module further includes a fourth construction submodule, a fifth construction submodule, and a sixth construction submodule. The fourth construction submodule is used to construct a first interface input test case based on the aforementioned request information and the first abnormal data test set; the fifth construction submodule is used to construct a second interface input test case based on the aforementioned request information and the second abnormal data test set; and the sixth construction submodule is used to construct a third interface input test case based on the aforementioned request information and the third abnormal data test set. Through the above steps, interface input test cases are constructed, thus automatically generating interface input test cases to validate the input of the target interface.

[0098] Specifically, interface input test cases are constructed based on the request information and the abnormal data test set. Specifically, a first interface input test case is constructed based on the first abnormal data test set. Since the first abnormal data test set consists of multiple data sets of different types than the aforementioned request parameters but within the range of the aforementioned request parameters, the first interface input test case is used to test whether the target interface validates the parameter type of the input parameters. A second interface input test case is constructed based on the second abnormal data test set. Since the second abnormal data test set consists of multiple data sets of the same type as the aforementioned request parameters but outside the range of the aforementioned request parameters, the second interface input test case is used to test whether the target interface validates the length of the input parameters. A third interface input test case is constructed based on the third abnormal data test set. Since the third abnormal data test set is constructed based on multiple SQL injection statements, the third interface input test case is used to test whether the target interface validates the injected characters to avoid injection vulnerabilities. It should be noted that in practical applications, abnormal data test sets and corresponding interface input test cases can be constructed according to specific data. For example, the test parameters can be modified to other test items, such as API permission testing. Based on different permission levels of API requests, the above abnormal data test sets can be constructed to quickly detect whether each API has unauthorized access security risks. This application does not restrict the specific application scenarios of the aforementioned abnormal data test set and interface test cases.

[0099] In one exemplary embodiment, the second acquisition module further includes an execution submodule, configured to construct a test interface corresponding to the interface input test cases based on the aforementioned interface input test cases, input the elements of the aforementioned abnormal data test set to the aforementioned test interface respectively, acquire the results output by the aforementioned test interface, and obtain the aforementioned abnormal data test results. Through this device, a test interface is constructed to test the elements in the abnormal data test set.

[0100] Specifically, a test interface is constructed based on the request address in the request information. The test interface is used to output the response information after inputting the elements of the abnormal data test set, that is, to obtain the abnormal data test results.

[0101] In an exemplary embodiment, the determining module includes a matching submodule and a judging submodule. The matching submodule is used to determine whether the interface input test case was successfully parsed based on the response content and status code in the abnormal data test results. If parsing is successful, it matches the abnormal data test set corresponding to the response content, matches the corresponding request parameters based on the abnormal data test set, and matches the corresponding error response information based on the request parameters. The judging submodule is used to determine whether the abnormal data test results contain the error response information. Through this device, by matching the corresponding request parameters based on the abnormal data test set and further matching the corresponding error response information, it is possible to determine whether the target interface can recognize erroneous input parameter information and output error response information.

[0102] Specifically, the response content and status code in the abnormal data test results can be JSON / text / html, etc. After the interface input test case is successfully parsed, the abnormal data test set corresponding to the above response content is matched. The above request parameters are matched according to the above abnormal data test set, and the above error response information is matched according to the above request parameters. That is, the response content of the first interface input test case is matched with the request parameters, and the corresponding error response information is matched according to the request parameters. The response content of the second interface input test case is matched with the request parameters, and the corresponding error response information is matched according to the request parameters. The response content of the third interface input test case is matched with the request parameters, and the corresponding error response information is matched according to the request parameters. It is then determined whether the response content of the first, second, and third interface input test cases contains error response information. If the response content contains error response information, it indicates that the target interface can recognize the input erroneous parameter information, and therefore the verification is successful, that is, the target interface passes the verification. If the response content does not contain error response information, it indicates that the target interface cannot recognize the input erroneous parameter information, and therefore the verification fails, that is, the target interface does not pass the verification.

[0103] In an exemplary embodiment, the determining module further includes a first determining submodule and a second determining submodule. The first determining submodule is configured to, if parsing fails, determine whether the status code is in a predetermined format; if the status code is not in the predetermined format, determine that the input validation test of the target interface is abnormal. The second determining submodule is configured to, if the status code is in the predetermined format, determine whether the abnormal data test result contains the error response information; if it does, determine that the input validation test of the target interface is successful; if it does not, determine that the input validation test of the target interface has failed. Through the above steps, in the case where parsing of the interface input test case fails, the status code is further used to determine whether the validation was successful.

[0104] Specifically, the predefined format can be "2xx series". The system checks whether the status code is "2xx series". If the status code is "2xx series", the system continues to check whether the above abnormal data test result contains the above error response information. If it contains the information, the system can be determined to be successful. If it does not contain the information, the system is determined to be unsuccessful. If the status code is not "2xx series", the system is determined to be a verification exception for the target interface.

[0105] In one exemplary embodiment, the second acquisition module further includes an output submodule and an input submodule. The output submodule is used to determine whether all the abnormal data test sets corresponding to the aforementioned request parameters have been verified. If all verifications are completed, the output submodule outputs the abnormal data test results. The input submodule is used to input the elements of the abnormal data test sets corresponding to the unverified request parameters into the interface input test case if not all verifications are completed. Through the above steps, abnormal data test cases corresponding to multiple request parameters can be verified, improving the completeness of the verification.

[0106] Specifically, since the abnormal test dataset is constructed based on the request parameters, and the number of elements in the abnormal test dataset is y+1≤x, it is necessary to determine whether all x request parameters have been validated to ensure that no request parameters are missed and to improve the completeness of the validation.

[0107] In one exemplary embodiment, the first acquisition module further includes a second marking submodule, used to mark the target interface as not requiring testing if the first request parameter is not present. This device determines whether testing of the target interface is necessary based on the presence or absence of the request parameter.

[0108] Specifically, since this application validates the input of the interface, when the interface does not have input parameters, i.e., request parameters, there is no need to validate the interface. Therefore, the target interface is marked as not requiring testing. However, there may be cases where the request parameters are parsed incorrectly when the interface documentation obtains the request information, resulting in the absence of request parameters. Therefore, in order to more comprehensively represent the cases where request parameters are not present, it can be marked as not requiring testing or as cases where the interface documentation parses parameters incorrectly.

[0109] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0110] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when it is run.

[0111] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0112] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0113] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0114] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0115] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0116] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for API interface input validation testing, characterized in that, include: Obtain the interface document of the target interface, parse the interface document to obtain request information, wherein the interface document contains the request information, and the request information includes at least one of request location, request method and first request parameter, the request information is the information to be input to the target interface, and the first request parameter is the parameter in the interface document that conforms to the type of request parameter and is within the boundary value of request parameter and is about to be input to the target interface; Determine whether the first request parameter exists in the request information. If the first request parameter exists, obtain the error response information output by the target interface when the second request parameter is input, wherein the second request parameter is an incorrect request parameter and is different from the first request parameter. Based on the request parameters, construct an abnormal data test set, construct interface input test cases based at least on the request information, use the interface input test cases to perform input validation tests on the target interface, and obtain abnormal data test results, wherein the abnormal data test results are the output of the target interface when elements in the abnormal data test set are input; Determine whether the abnormal data test result contains the error response information. If it does, determine that the input validation test of the target interface is successful; otherwise, determine that the input validation test of the target interface is unsuccessful. Based on the request parameters, an abnormal data test set is constructed, including: constructing a first abnormal data test set based on multiple data of different types from the request parameters but within the range of the request parameters; constructing a second abnormal data test set based on multiple data of the same type as the request parameters but not within the range of the request parameters; and constructing a third abnormal data test set based on multiple SQL injection statements. At least the interface input test cases are constructed based on the request information, including: constructing a first interface input test case based on the request information and a first abnormal data test set; constructing a second interface input test case based on the request information and a second abnormal data test set; and constructing a third interface input test case based on the request information and a third abnormal data test set.

2. The method according to claim 1, characterized in that, Obtain the error response information output by the target interface when the second request parameter is input, including: If the target interface outputs an error response after the second request parameter is input to the target interface, the error response information output by the target interface is obtained.

3. The method according to claim 2, characterized in that, Also includes: If the target interface does not output the error response information, the target interface is marked as having no failure response.

4. The method according to claim 1, characterized in that, The target interface is subjected to input validation tests using the interface input test cases, and abnormal data test results are obtained, including: Based on the test cases input from the interface, construct the test interface corresponding to the test cases input from the interface, input the elements of the abnormal data test set into the test interface respectively, obtain the output results of the test interface, and obtain the abnormal data test results.

5. The method according to claim 4, characterized in that, Determining whether the abnormal data test result contains the error response information includes: Based on the response content and status code in the abnormal data test results, determine whether the interface input test case is successfully parsed. If the parsing is successful, match the abnormal data test set corresponding to the response content, match the corresponding request parameters based on the abnormal data test set, and match the corresponding error response information based on the request parameters. Determine whether the abnormal data test results contain the error response information.

6. The method according to claim 5, characterized in that, Also includes: If parsing fails, determine whether the status code is in a predetermined format. If the status code is not in the predetermined format, determine that the input validation test of the target interface is abnormal. If the status code is in the predetermined format, determine whether the abnormal data test result contains the error response information. If it does, determine that the input validation test of the target interface is successful; if it does not, determine that the input validation test of the target interface is unsuccessful.

7. The method according to claim 1, characterized in that, After performing input validation testing on the target interface using the interface input test cases, the process further includes: Determine whether all the abnormal data test sets corresponding to the request parameters have been verified. If all verifications have been completed, output the abnormal data test results. If not all validations are completed, the elements in the abnormal data test set corresponding to the unvalidated request parameters are input into the interface input test case.

8. The method according to claim 1, characterized in that, After determining whether the first request parameter exists in the request information, the method further includes: If the first request parameter is not present, the target interface is marked as not requiring testing.

9. An API interface input verification and testing device, characterized in that, include: An execution module is used to obtain the interface document of the target interface, parse the interface document, and obtain request information. The interface document contains the request information, which includes at least one of a request location, a request method, and a first request parameter. The request information is information for inputting the target interface, and the first request parameter is a parameter in the interface document that conforms to the type of request parameter and is within the boundary value of the request parameter and is about to be input to the target interface. The first acquisition module is used to determine whether the first request parameter exists in the request information. If the first request parameter exists, the module acquires the error response information output by the target interface when the second request parameter is input, wherein the second request parameter is an incorrect request parameter and is different from the first request parameter. The second acquisition module is used to construct an abnormal data test set according to the request parameters, construct interface input test cases at least according to the request information, perform input verification tests on the target interface using the interface input test cases, and acquire abnormal data test results, wherein the abnormal data test results are the output of the target interface when elements in the abnormal data test set are input; The determination module is used to determine whether the abnormal data test result contains the error response information. If it does, the input validation test of the target interface is determined to be successful; if it does not, the input validation test of the target interface is determined to be unsuccessful. The second acquisition module includes: a first construction submodule, used to construct a first abnormal data test set based on multiple data that are of a different type than the request parameters and are within the range of the request parameters; a second construction submodule, used to construct a second abnormal data test set based on multiple data that are of the same type as the request parameters but are not within the range of the request parameters; and a third construction submodule, used to construct a third abnormal data test set based on multiple SQL injection statements. The second acquisition module further includes: a fourth construction submodule, used to construct a first interface input test case based on the request information and the first abnormal data test set; a fifth construction submodule, used to construct a second interface input test case based on the request information and the second abnormal data test set; and a sixth construction submodule, used to construct a third interface input test case based on the request information and the third abnormal data test set.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of claims 1 to 8.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 8.

Images