Fuzzy testing method and device for RESTful API interface and computer equipment

Abstract

The invention relates to a fuzz testing method and device for a RESTful API interface, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: determining an API interface to be tested; determining a function type of each interface parameter corresponding to the to-be-tested API interface; and generating a test case based on a test case rule corresponding to the function type of each interface parameter, and inputting the test case into the to-be-tested API interface for fuzzy testing. By adopting the method, the test efficiency and the test effect can be effectively improved.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to a fuzzy testing method, apparatus, computer equipment, computer-readable storage medium, and computer program product for a RESTful API interface. Background Art

[0002] Systems that provide network services to the outside world generally provide services in the form of web pages combined with RESTful APIs. RESTful API (Representational State Transfer API) is a Web service design style based on HTTP (Hypertext Transfer Protocol) protocol, which is widely used in Web application and API (Application Programming Interface) design. The design of RESTful API follows the REST (Representational State Transfer) architectural style. Its core idea is to treat resources as entities on the network and operate through a unified interface to ensure efficient and clear interaction between clients and servers.

[0003] By performing fuzz testing on the RESTful API interface (hereinafter referred to as the API interface in the embodiments of this application), potential security risks can be discovered and resolved, the robustness and security of the system can be improved, thereby ensuring the stable operation of the system and reducing potential security risks.

[0004] In related technologies, the robustness and security of APIs can be tested by sending incorrect, abnormal or random data structures and inputs, thereby helping to discover potential vulnerabilities and security risks. In order to test more thoroughly, the tool will construct a large amount of abnormal data, usually in the tens of millions, so the test time is long and the test efficiency is low. Summary of the invention

[0005] Based on this, it is necessary to provide a fuzz testing method, device, computer equipment, computer-readable storage medium and computer program product for RESTful API interface that can improve testing efficiency in response to the above technical problems.

[0006] In a first aspect, the present application provides a fuzz testing method for a RESTful API interface, the method comprising:

[0007] Determine the API interface to be tested;

[0008] Determine the function type of each interface parameter corresponding to the API interface to be tested;

[0009] A test case is generated based on the test case rules corresponding to the functional type of each of the interface parameters, and the test case is input into the API interface to be tested for fuzz testing.

[0010] In one embodiment, the test case includes a basic test case and a valid test case, and the test case is generated based on the test case rules corresponding to the functional type of each interface parameter, including:

[0011] Obtain the test mode of the API interface to be tested;

[0012] When the test mode of the API interface to be tested is a simplified mode, generating the basic test case based on the test case rules corresponding to the function type of each of the interface parameters;

[0013] The preprocessor is called to dynamically modify the basic test case to obtain the valid test case.

[0014] In one embodiment, the generating of the test case based on the test case rule corresponding to the function type of each of the interface parameters includes:

[0015] Get the dependency relationship between each interface parameter;

[0016] Based on the dependency relationship between the interface parameters, the test case rules corresponding to the function type of each interface parameter are called to generate a test case.

[0017] In one embodiment, the generating of the test case based on the test case rule corresponding to the function type of each of the interface parameters includes:

[0018] Respectively calling the test case rules corresponding to the function type of each of the interface parameters to generate parameter values ​​of each of the interface parameters;

[0019] The parameter values ​​of the interface parameters are combined according to the combination rules to obtain test cases.

[0020] In one embodiment, before respectively calling the test case rules corresponding to the function types of the interface parameters to generate parameter values ​​of the interface parameters, the method further includes:

[0021] For any of the interface parameters, the initial test case rules corresponding to the functional type of the interface parameter are displayed in the display interface, and in response to the editing operation on the initial test case rules, the test case rules corresponding to the functional type of the interface parameter are determined.

[0022] In one embodiment, the step of inputting the test case into the API interface to be tested for fuzz testing includes:

[0023] In response to the test environment setting operation, determining a target test environment;

[0024] Building the target test environment based on the configuration file corresponding to the target test environment;

[0025] In the target test environment, the test case is input into the API interface to be tested for fuzz testing.

[0026] In a second aspect, the present application further provides a fuzzy testing device for a RESTful API interface, the device comprising:

[0027] The first determination module is used to determine the API interface to be tested;

[0028] The second determination module is used to determine the function type of each interface parameter corresponding to the API interface to be tested;

[0029] The test module is used to generate test cases based on the test case rules corresponding to the functional types of each of the interface parameters, and input the test cases into the API interface to be tested for fuzzy testing.

[0030] In one embodiment, the test case includes a basic test case and a valid test case, and the test module is further used to:

[0031] Obtain the test mode of the API interface to be tested;

[0032] When the test mode of the API interface to be tested is a simplified mode, generating the basic test case based on the test case rules corresponding to the function type of each of the interface parameters;

[0033] The preprocessor is called to dynamically modify the basic test case to obtain the valid test case.

[0034] In one embodiment, the test module is further used to:

[0035] Get the dependency relationship between each interface parameter;

[0036] Based on the dependency relationship between the interface parameters, the test case rules corresponding to the function type of each interface parameter are called to generate a test case.

[0037] In one embodiment, the test module is further used to:

[0038] Respectively calling the test case rules corresponding to the function type of each of the interface parameters to generate parameter values ​​of each of the interface parameters;

[0039] The parameter values ​​of the interface parameters are combined according to the combination rules to obtain test cases.

[0040] In one embodiment, the device further comprises:

[0041] An editing module is used to display, for any of the interface parameters, an initial test case rule corresponding to the functional type of the interface parameter in a display interface, and determine the test case rule corresponding to the functional type of the interface parameter in response to an editing operation on the initial test case rule.

[0042] In one embodiment, the test module is further used to:

[0043] In response to the test environment setting operation, determining a target test environment;

[0044] Building the target test environment based on the configuration file corresponding to the target test environment;

[0045] In the target test environment, the test case is input into the API interface to be tested for fuzz testing.

[0046] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0047] Determine the API interface to be tested;

[0048] Determine the function type of each interface parameter corresponding to the API interface to be tested;

[0049] A test case is generated based on the test case rules corresponding to the functional type of each of the interface parameters, and the test case is input into the API interface to be tested for fuzz testing.

[0050] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the following steps are implemented:

[0051] Determine the API interface to be tested;

[0052] Determine the function type of each interface parameter corresponding to the API interface to be tested;

[0053] A test case is generated based on the test case rules corresponding to the functional type of each of the interface parameters, and the test case is input into the API interface to be tested for fuzz testing.

[0054] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

[0055] Determine the API interface to be tested;

[0056] Determine the function type of each interface parameter corresponding to the API interface to be tested;

[0057] A test case is generated based on the test case rules corresponding to the functional type of each of the interface parameters, and the test case is input into the API interface to be tested for fuzz testing.

[0058] The above-mentioned fuzzy testing method, device, computer equipment, computer-readable storage medium and computer program product for RESTful API interface can determine the API interface to be tested and determine the functional type of each interface parameter corresponding to the API interface to be tested, and then generate test cases based on the test case rules corresponding to the functional type of each interface parameter, and input the test cases into the API interface to be tested for fuzzy testing. Using the fuzzy testing method, device, computer equipment, computer-readable storage medium and computer program product for RESTful API interface provided by the embodiment of the present application, corresponding test cases can be generated based on the functional type of interface parameters. Compared with randomly generating test cases or generating test cases based on parameter types, the number of constructed test cases can be greatly reduced, which can reduce test time and improve test efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0060] FIG1 is a schematic diagram of a flow chart of a fuzzy testing method for a RESTful API interface in one embodiment;

[0061] FIG2 is a schematic diagram of a flow chart of step 106 in one embodiment;

[0062] FIG3 is a schematic diagram of a flow chart of step 106 in another embodiment;

[0063] FIG4 is a schematic diagram of a flow chart of step 106 in another embodiment;

[0064] FIG5 is a schematic diagram of a combination rule in one embodiment;

[0065] FIG6 is a schematic diagram of a flow chart of step 106 in another embodiment;

[0066] FIG7 is a structural block diagram of a fuzzy testing device for a RESTful API interface in one embodiment;

[0067] FIG8 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0068] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0069] In one embodiment, as shown in FIG1 , a fuzzy testing method for a RESTful API interface is provided. This embodiment uses the method applied to a terminal as an example. It is understandable that the method can also be applied to a server, and can also be applied to a system including a terminal and a server, and is implemented through the interaction between the terminal and the server. In this embodiment, the method includes the following steps 102 to 106, wherein:

[0070] Step 102: determine the API interface to be tested.

[0071] In an embodiment of the present application, a user can enter or select an API interface to be tested in the human-computer interaction interface. For example, a user can enter the interface name of the API interface to be tested in the human-computer interaction interface, or an API interface list can be displayed in the human-computer interaction interface, and the user can select the API interface to be tested in the API interface list.

[0072] Step 104: determine the function type of each interface parameter corresponding to the API interface to be tested.

[0073] In the embodiment of the present application, after determining the API interface to be tested, the user can set the function type of each interface parameter corresponding to the API interface to be tested in the human-computer interaction interface. Exemplarily, the user can manually enter the interface parameters corresponding to the API interface in the human-computer interaction interface and set the corresponding function type; or, the system can also read the configuration file of the API interface to be tested, parse the configuration file, obtain the interface parameters corresponding to the API interface to be tested, and display each interface parameter in the human-computer interaction interface, and the user can display the function type corresponding to each interface parameter in the human-computer interaction interface.

[0074] For example, the API interface can be statically and dynamically analyzed and counted in advance to obtain all the function types corresponding to the API interface. When the user sets the function type corresponding to each interface parameter, the user can obtain a function type list and select at least one function type for each interface parameter from the function type list.

[0075] Exemplarily, the function types corresponding to the API interface can be shown in Table 1 below.

[0076] Table 1

[0077]

[0078] Step 106, generating a test case based on the test case rules corresponding to the function type of each interface parameter, and inputting the test case into the API interface to be tested for fuzz testing.

[0079] In the embodiments of the present application, each function type is preset with a corresponding test case rule. Exemplarily, corresponding test case rules can be written for abnormal values, illegal values, and null values ​​of a single function type. For example: test case rules can be written based on the function types of the respective interface parameters and the data types of the interface parameters. The test case rules can take various forms, such as regular expressions, template filling, enumeration sets, etc., which are not specifically limited in the embodiments of the present application. Exemplarily, abnormal values, illegal values, and null values ​​of a single function type can be shown in Table 2 below.

[0080] Table 2

[0081]

[0082] After determining the function type corresponding to each interface parameter, the test case rules corresponding to the function type of each interface parameter can be called to generate parameter values ​​for each interface parameter. Test cases can be obtained based on the parameter value combinations corresponding to each interface parameter, and the API interface to be tested can be input for fuzzy testing to obtain the test results corresponding to the API interface to be tested.

[0083] The above-mentioned fuzzy testing method for RESTful API interface can determine the API interface to be tested and the functional type of each interface parameter corresponding to the API interface to be tested, and then generate test cases based on the test case rules corresponding to the functional type of each interface parameter, and input the test cases into the API interface to be tested for fuzzy testing. Using the fuzzy testing method for RESTful API interface provided by the embodiment of the present application, corresponding test cases can be generated based on the functional type of the interface parameters. Compared with randomly generating test cases or generating test cases based on parameter types, the number of constructed test cases can be greatly reduced, which can reduce test time and improve test efficiency.

[0084] In an exemplary embodiment, before respectively calling the test case rules corresponding to the function types of the interface parameters to generate the parameter values ​​of the interface parameters, the method may further include:

[0085] For any interface parameter, an initial test case rule corresponding to the function type of the interface parameter is displayed in the display interface, and in response to an editing operation on the initial test case rule, a test case rule corresponding to the function type of the interface parameter is determined.

[0086] In an embodiment of the present application, in the process of setting the function type corresponding to each interface parameter, the test case rules provided by the system can be directly used, or the test case rules provided by the system can be re-edited as needed to obtain test case rules with more precise generated test cases and smaller scope.

[0087] Exemplarily, in the process of setting the function type corresponding to each interface parameter, after the user selects the function type corresponding to the interface parameter, the test case rules corresponding to the function type and the editing controls for adjusting the test case rules can be displayed in the human-computer interaction interface. When the user triggers the editing control, a pop-up window can be displayed in the human-computer interaction interface, and the pop-up window can display the editable test case rules. The user can modify the test case rules in the pop-up window.

[0088] For example, for interface parameters that are both path parameters and string types, test case rules in the form of regular expressions can be used to generate path parameters that comply with the operating system path rules. At the same time, users can add some operating system sensitive paths to the regular expression to narrow the scope of the test cases. Alternatively, for parameters that are both paging type parameters and numeric type parameters, users can set a value range or a specific value in the regular expression to narrow the scope of the test cases.

[0089] In another example, the pop-up window may include a reference control. After the user triggers the reference control, the pop-up window may display a reference test case rule, which is a test case rule obtained after historical user editing, and the test accuracy or coverage of the fuzzy test executed using the test case rule reaches the reference standard. Exemplarily, the reference standard may be that the test accuracy reaches a preset accuracy threshold or the code coverage reaches a preset coverage threshold.

[0090] For example: Assume that user A edits the test case rule of the function type "path parameter" to obtain test case rule 1, and the code coverage of the fuzzy test performed by user A reaches the reference standard, then test case rule 1 can be used as a reference test case rule. When user B edits the test case rule of the function type "path parameter", test case rule 1 can be displayed to user B for reference. User B can directly adopt test case rule 1 or edit the original test case rule or test case rule 1 to obtain the test case rule used for this test.

[0091] In an exemplary embodiment, the test case may include a basic test case and a valid test case. Referring to FIG. 2 , in step 106, generating a test case based on a test case rule corresponding to a function type of each interface parameter may include the following steps 202 to 206, wherein:

[0092] Step 202, obtaining the test mode of the API interface to be tested;

[0093] Step 204: when the test mode of the API interface to be tested is the simplified mode, generate a basic test case based on the test case rules corresponding to the function type of each interface parameter;

[0094] Step 206, calling the preprocessor to dynamically modify the basic test case to obtain a valid test case.

[0095] In the embodiment of the present application, the user can configure the test mode through the human-computer interaction interface during the configuration of the test data. The test mode can include a standard mode and a simplified mode, wherein in the standard mode, the system can generate a corresponding number of parameter values ​​for each interface parameter based on the preset standards of each function type to ensure that all scenarios can be covered; in the simplified mode, the system can only generate a small number of basic test cases for each interface parameter, and obtain effective test cases by dynamically modifying the basic test cases to avoid the problem of repeated testing, reduce the number of test cases, and improve test efficiency.

[0096] For example, if the test mode currently selected by the user is the simplified mode, when performing fuzzy testing on the API interface, in order to simplify the variant use cases of the interface parameters and avoid repeated testing, a small number of basic parameters can be generated in advance based on the test case rules corresponding to the functional type of each interface parameter, and the basic test case can be obtained based on the basic parameter combination of each interface parameter. Furthermore, the preprocessor can be used to dynamically adjust the parameter values ​​in the basic test case, for example, assigning specific abnormal values, illegal values ​​or null values ​​to variables, which can reduce the number of hard-coded use cases and improve the flexibility and efficiency of the test.

[0097] At the same time, data-driven testing can also be used to obtain abnormal test cases that successfully hit the exception during the historical test process from the abnormal parameter history database, and use the abnormal test case as a valid test case to participate in the test of the API interface to be tested; or, each parameter value can be read from the abnormal test case, and the test case can be regenerated based on the read parameter value, and used as a valid test case to participate in the local test of the API interface to be tested. Among them, the abnormal parameter history database is used to record the test cases used in the historical test process, which contains various parameter values ​​corresponding to the interface parameters to be tested (including abnormal values, illegal values ​​and null values). The system generates test cases by reading this database to cover more scenarios.

[0098] In an exemplary embodiment, as shown in FIG. 3 , in step 106, generating a test case based on a test case rule corresponding to a function type of each interface parameter may include the following steps 302 to 304, wherein:

[0099] Step 302, obtaining the dependency relationship between the interface parameters;

[0100] Step 304: Based on the dependency relationship between the interface parameters, the test case rules corresponding to the function type of each interface parameter are called to generate a test case.

[0101] In the embodiment of the present application, when the user sets the function type of the interface parameter, the dependency relationship between the interface parameters can be set synchronously; or, when the system obtains the interface parameters of the API interface to be tested from the configuration file of the API interface to be tested, the mutually dependent interface parameters are displayed at the same time, and the user sets the dependency relationship between the interface parameters. In the embodiment of the present application, no specific limitation is made on the acquisition method of the dependency relationship. For example, assuming that interface parameter A and interface parameter B are dependent on each other, the function type corresponding to interface parameter A has two values: "0" and "1", and the function type corresponding to interface parameter B has two values: function type 1 and function type 2. Then the user can set the dependency relationship between the two as follows: when interface parameter A takes the value "0", interface parameter B corresponds to function type 1, and when interface parameter A takes the value "1", interface parameter B corresponds to function type 2. In this way, the scenarios of function type 2 corresponding to interface parameter B when the interface parameter takes the value "0" and function type 1 corresponding to interface parameter B when the interface parameter takes the value "1" can be avoided, which can effectively reduce the number of test cases while ensuring the coverage area of ​​the test cases.

[0102] When the interface parameters have dependencies, the test case rules corresponding to the function types of the interface parameters can be called based on the dependencies to generate test cases. Alternatively, when the interface parameters do not have dependencies, the test case rules corresponding to the function types of the interface parameters can be directly called to generate test cases.

[0103] In an exemplary embodiment, as shown in FIG. 4 , in step 106, generating a test case based on a test case rule corresponding to a function type of each interface parameter may include the following steps 402 to 404, wherein:

[0104] Step 402, respectively calling the test case rules corresponding to the function type of each interface parameter to generate parameter values ​​of each interface parameter;

[0105] Step 404, combining the parameter values ​​of the interface parameters according to the combination rules to obtain a test case.

[0106] In the embodiment of the present application, the test case rules corresponding to the function type of each interface parameter can be called respectively to generate the parameter value of each interface parameter. For multiple interface parameters with dependencies, what is finally obtained is a parameter subset, which includes the parameter values ​​generated by each interface parameter based on the dependency. In the subsequent process of combining test cases, the parameter subset will be combined as a whole.

[0107] In the embodiment of the present application, a plurality of combination rules are pre-set, and the parameter values ​​of the interface parameters can be combined according to each combination rule to obtain a test case.

[0108] In Figure 5, when the combination rule is a typical value, the typical parameter values ​​corresponding to the interface parameters can be obtained and combined to obtain a test case, and the typical parameter value can be a parameter value manually input by the user. When the combination rule is no parameter, a test case without parameters can be directly generated.

[0109] When the combination rule is that all fields are required, the following four test case combinations can be included: 1. For required interface parameters, all are set to empty values ​​(empty values ​​can include spaces, NULL, None, etc.); 2. For required interface parameters, all are set to abnormal values; 3. For required interface parameters, all are set to illegal values; 4. For required interface parameters, they are randomly combined according to abnormal values, empty values, illegal values ​​and typical parameter values.

[0110] When the combination rule is a single non-mandatory field, the following four test case combinations can be included: 1. For non-mandatory interface parameters, all are set to empty values ​​(empty values ​​can include spaces, NULL, None, etc.); 2. For non-mandatory interface parameters, all are set to abnormal values; 3. For non-mandatory interface parameters, all are set to illegal values; 4. For non-mandatory interface parameters, they are randomly combined according to abnormal values, empty values, illegal values ​​and typical parameter values.

[0111] When the combination rule is all parameters, the following four test case combinations can be included: 1. For all interface parameters, all are set to empty values ​​(empty values ​​can include spaces, NULL, None, etc.); 2. For all interface parameters, all are set to abnormal values; 3. For all interface parameters, all are set to illegal values; 4. For all interface parameters, they are randomly combined according to abnormal values, empty values, illegal values ​​and typical parameter values.

[0112] In this way, test cases corresponding to various scenarios can be obtained, which can greatly improve the test coverage and test effect.

[0113] In an exemplary embodiment, as shown in FIG. 6 , in step 106 , inputting the test case into the API interface to be tested for fuzz testing may include the following steps 602 to 606 , wherein:

[0114] Step 602, in response to the test environment setting operation, determining a target test environment;

[0115] Step 604, building a target test environment based on a configuration file corresponding to the target test environment;

[0116] Step 606: In the target test environment, the test case is input into the API interface to be tested for fuzz testing.

[0117] In the embodiment of the present application, corresponding configuration files can be pre-set for various types of test environments, and the configuration files include configuration parameters and policies for building the corresponding test environments. The test environments may include but are not limited to the following: high local network latency, high packet loss rate, unstable connection; excessive server load; abnormal test end system time; and frequent remote proxy access to the test end.

[0118] The user can select a target test environment from various test environments. The system can obtain a configuration file corresponding to the target test environment, obtain corresponding configuration parameters and strategies from the configuration file, build a target test environment based on the strategy and configuration parameters, and an environment building tool, and use the test cases generated in the aforementioned embodiments in the target test environment to perform fuzz testing on the API interface to be tested.

[0119] In the fuzzy testing method for RESTful API interfaces provided in the embodiment of the present application, users can use test case rules to generate more representative test cases, including various types of boundary conditions, abnormal inputs, etc. This helps to improve the coverage of the test, while reducing repeated test cases, and speeding up the testing process by parallel execution based on the generated test cases.

[0120] In order to enable those skilled in the art to better understand the embodiments of the present application, the embodiments of the present application are described below through specific examples.

[0121] First, it is necessary to define parameter type rules: the type of each parameter in the API interface needs to be clarified. The type here does not refer to the parameter data type, but to the function type of the parameter. The function type can refer to Table 1 of the aforementioned embodiment.

[0122] Then, it is necessary to handle single parameter mutation: When performing fuzz testing on API interfaces, in order to simplify the mutation cases of a single parameter and avoid repeated testing, the preprocessor can be used to dynamically generate or modify parameter values ​​in the interface test, and assign specific abnormal values, illegal values ​​or null values ​​to variables. This can reduce the number of hard-coded cases and improve the flexibility and efficiency of the test. At the same time, data-driven testing is used, based on the abnormal parameter history database, which contains various values ​​corresponding to some parameters to be tested (including abnormal values, illegal values ​​and null values). The database records some public data that has successfully discovered problems in other system testing processes. The system generates use cases by reading this database to cover more scenarios. After the test is executed, the postprocessor is used to parse or process the response results to confirm whether the abnormal values ​​and illegal values ​​are handled correctly. For example, extractors such as regular expressions are used to check the values ​​of specific fields in the response to ensure that they meet the expected behavior. Write generation rules for abnormal values, illegal values, and null values ​​of a single parameter: Generate rules based on the functional type of each parameter and the data type of the parameter, which can be written in various ways, such as regular expressions, template filling, enumeration sets, etc. For example, for parameters that are both path parameters and string types, regular expressions can be used to generate path parameters that comply with the path rules of the operating system, and some operating system sensitive paths can be added; for parameters that are both paging type parameters and numeric type parameters, a value range or a specific value can be set; for function switch parameters whose data type is Boolean, empty values ​​can be passed, and abnormal values ​​of the parameters can be referred to as shown in Table 2.

[0123] In the case of multiple parameters being interdependent, the system treats the interdependent parameters as a whole rather than testing them individually. This ensures that the dependencies between parameters are taken into account during testing and reduces the generation of invalid use cases. Before testing, the user builds the dependency, such as conditional parameter dependency, the value of parameter a corresponds to the internal type of parameter b; logical dependency, for example, the order status can only be updated to the paid status when the payment is successful.

[0124] Construct a combination rule for a multi-parameter test case. The combination rule can be specifically shown in FIG. 5 .

[0125] Automatically generate test cases: Test cases can be generated based on the above rules through relevant algorithms. For example, scripts or programming languages ​​can be used to implement these rules and generate test case data in JSON format that complies with the rules.

[0126] It should be noted that during the testing process based on the generated test cases, some environmental anomalies can be constructed, such as high local network latency, high packet loss rate, unstable connection; excessive server load; abnormal system time on the test end; and frequent remote proxy access on the test end.

[0127] That is, the fuzzy testing method for the RESTful API interface provided in the embodiment of the present application may include the following steps:

[0128] Step 1: Sort out the data type, parameter type, required and optional conditions, and parameter restrictions of each parameter based on the API documentation;

[0129] Step 2: Implement a use case combination generation system from the two aspects of parameter variation and parameter combination through scripts or other methods;

[0130] Step 3: Carry out testing based on the generated test cases and record the test process data;

[0131] Step 4: Analyze the test process data, adjust the parameter variation and parameter combination strategies, and then generate use cases and tests again.

[0132] By adopting the fuzz testing method for RESTful API interface provided by the embodiment of the present application, fuzz test cases of API interface can be generated through rule-based generation algorithm and fuzz test can be performed on API interface, and network protocol fuzz test assets can be constructed based on input and output use case sets, and network protocol fuzz test coverage evaluation can be constructed based on input and output use case sets. By analyzing the input parameters of the interface, test assets can be easily inherited and have good scalability; test cases generated by intelligent algorithms reduce the scope of massive test cases of traditional fuzz testing tools, improve test accuracy, and improve test efficiency; during the test process, the system records the problems found and the corresponding parameter strategies, including single parameter variation types and multi-parameter combination types. Apply the corresponding strategies to other interfaces, thereby increasing test cases and improving the utilization of test cases.

[0133] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0134] Based on the same inventive concept, the embodiment of the present application also provides a fuzzy testing device for a RESTful API interface for implementing the fuzzy testing method for a RESTful API interface involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in the embodiments of one or more fuzzy testing devices for a RESTful API interface provided below can be found in the above limitations on the fuzzy testing method for a RESTful API interface, and will not be repeated here.

[0135] In an exemplary embodiment, as shown in FIG. 7 , a fuzzy testing device for a RESTful API interface is provided, including: a first determination module 702, a second determination module 704 and a testing module 706, wherein:

[0136] The first determination module 702 is used to determine the API interface to be tested;

[0137] The second determination module 704 is used to determine the function type of each interface parameter corresponding to the API interface to be tested;

[0138] The testing module 706 is used to generate a test case based on the test case rules corresponding to the functional type of each of the interface parameters, and input the test case into the API interface to be tested for fuzzy testing.

[0139] The above-mentioned fuzzy testing device for RESTful API interface can determine the API interface to be tested and the functional type of each interface parameter corresponding to the API interface to be tested, and then generate test cases based on the test case rules corresponding to the functional type of each interface parameter, and input the test cases into the API interface to be tested for fuzzy testing. The fuzzy testing device for RESTful API interface provided by the embodiment of the present application can generate corresponding test cases based on the functional type of the interface parameters. Compared with randomly generating test cases or generating test cases based on parameter types, the number of constructed test cases can be greatly reduced, which can reduce test time and improve test efficiency.

[0140] In one embodiment, the test case includes a basic test case and a valid test case, and the test module 706 is further used to:

[0141] Obtain the test mode of the API interface to be tested;

[0142] When the test mode of the API interface to be tested is a simplified mode, generating the basic test case based on the test case rules corresponding to the function type of each of the interface parameters;

[0143] The preprocessor is called to dynamically modify the basic test case to obtain the valid test case.

[0144] In one embodiment, the testing module 706 is further configured to:

[0145] Get the dependency relationship between each interface parameter;

[0146] Based on the dependency relationship between the interface parameters, the test case rules corresponding to the function type of each interface parameter are called to generate a test case.

[0147] In one embodiment, the testing module 706 is further configured to:

[0148] Respectively calling the test case rules corresponding to the function type of each of the interface parameters to generate parameter values ​​of each of the interface parameters;

[0149] The parameter values ​​of the interface parameters are combined according to the combination rules to obtain test cases.

[0150] In one embodiment, the device further comprises:

[0151] An editing module is used to display, for any of the interface parameters, an initial test case rule corresponding to the functional type of the interface parameter in a display interface, and determine the test case rule corresponding to the functional type of the interface parameter in response to an editing operation on the initial test case rule.

[0152] In one embodiment, the testing module 706 is further configured to:

[0153] In response to the test environment setting operation, determining a target test environment;

[0154] Building the target test environment based on the configuration file corresponding to the target test environment;

[0155] In the target test environment, the test case is input into the API interface to be tested for fuzz testing.

[0156] Each module in the above-mentioned fuzzy testing device for RESTful API interface can be implemented in whole or in part by software, hardware and their combination. Each of the above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.

[0157] In an exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be shown in FIG8. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit, and an input device. The processor, the memory, and the input / output interface are connected via a system bus, and the communication interface, the display unit, and the input device are connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner may be implemented through WIFI, a mobile cellular network, near field communication (NFC) or other technologies. When the computer program is executed by the processor, a fuzzy testing method for a RESTful API interface is implemented. The display unit of the computer device is used to form a visually visible picture, which may be a display screen, a projection device, or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device shell, or an external keyboard, touchpad or mouse.

[0158] Those skilled in the art will understand that the structure shown in FIG. 8 is merely a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0159] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0160] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0161] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0162] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0163] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0164] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0165] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A fuzz testing method for a RESTful API interface, characterized in that: The method comprises: Determine the API interface to be tested; Determine the function type of each interface parameter corresponding to the API interface to be tested; A test case is generated based on the test case rules corresponding to the functional type of each of the interface parameters, and the test case is input into the API interface to be tested for fuzz testing.

2. The method according to claim 1, characterized in that The test cases include basic test cases and valid test cases, and the test case rules corresponding to the functional types of the interface parameters are used to generate test cases, including: Obtain the test mode of the API interface to be tested; When the test mode of the API interface to be tested is a simplified mode, generating the basic test case based on the test case rules corresponding to the function type of each of the interface parameters; The preprocessor is called to dynamically modify the basic test case to obtain the valid test case.

3. The method according to claim 1, characterized in that The generating of test cases based on the test case rules corresponding to the function types of the interface parameters includes: Get the dependency relationship between each interface parameter; Based on the dependency relationship between the interface parameters, the test case rules corresponding to the function type of each interface parameter are called to generate a test case.

4. The method according to claim 1, characterized in that: The generating of test cases based on the test case rules corresponding to the function types of the interface parameters includes: Respectively calling the test case rules corresponding to the function type of each of the interface parameters to generate parameter values ​​of each of the interface parameters; The parameter values ​​of the interface parameters are combined according to the combination rules to obtain test cases.

5. The method according to claim 4, characterized in that Before respectively calling the test case rules corresponding to the function types of the interface parameters to generate parameter values ​​of the interface parameters, the method further includes: For any of the interface parameters, the initial test case rules corresponding to the functional type of the interface parameter are displayed in the display interface, and in response to the editing operation on the initial test case rules, the test case rules corresponding to the functional type of the interface parameter are determined.

6. The method according to claim 1, characterized in that The step of inputting the test case into the API interface to be tested for fuzz testing includes: In response to the test environment setting operation, determining a target test environment; Building the target test environment based on the configuration file corresponding to the target test environment; In the target test environment, the test case is input into the API interface to be tested for fuzz testing.

7. A fuzzy testing device for a RESTful API interface, characterized in that: The device comprises: The first determination module is used to determine the API interface to be tested; The second determination module is used to determine the function type of each interface parameter corresponding to the API interface to be tested; The test module is used to generate test cases based on the test case rules corresponding to the functional types of each of the interface parameters, and input the test cases into the API interface to be tested for fuzzy testing.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images