Function verification method, device and equipment and readable storage medium
By acquiring interface feature test cases and field rule information, and automatically constructing and sending exception requests, the problem of large workload and error-proneness in interface exception verification functions is solved, and efficient and reliable interface exception parameter verification is achieved.
Patent Information
- Application Number
- CN202511141317.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-15
- Publication Date
- 2025-11-14
AI Technical Summary
Existing technologies, when faced with a large number of interfaces and parameters, make the interface anomaly detection function labor-intensive, error-prone, and difficult to perform efficiently.
By acquiring the characteristic test cases and field rule information of the target interface, the reference request is automatically modified to construct an exception request, and the exception request is sent during the test to verify the interface's exception parameter detection function.
It has achieved automated verification of abnormal interface parameters, reduced manual operation, ensured that all request parameter rules are tested one by one, and improved the reliability of verification results.
Smart Images
Figure CN120950366A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer application technology, and in particular to functional verification methods, apparatus, devices and readable storage media. Background Technology
[0002] During API calls, request exception checks are typically performed. Request parameter exceptions fall into two categories: one is for validating required request parameters, and the other is for validating request parameter values that are not valid.
[0003] The anomaly detection function of an interface can be verified by setting up test cases. However, when there are a large number of interfaces and a large number of parameters that need to be verified for anomaly detection, it often leads to a large workload for verification and is prone to errors.
[0004] In summary, how to verify the abnormal parameter detection function of the interface is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention
[0005] The purpose of this application is to provide a functional verification method, apparatus, device, and readable storage medium that can automatically verify the abnormal parameter detection function of an interface.
[0006] To solve the above-mentioned technical problems, this application provides the following technical solution:
[0007] A functional verification method, comprising:
[0008] Obtain the feature use cases corresponding to the target interface; wherein, the feature use cases include reference requests;
[0009] Retrieve the field rule information of the request string from the rule information table corresponding to the interface request parameters;
[0010] By modifying the fields in the reference request using the field rule information, an abnormal request is obtained;
[0011] During the testing of the target interface using the feature test cases, the exception request is sent to the target interface, and the exception information fed back by the target interface is received.
[0012] The abnormal information is used to verify the abnormal parameter detection function of the target interface.
[0013] Preferably, modifying fields in the reference request using the field rule information to obtain an abnormal request includes:
[0014] The field rule information is classified according to the number of the feature use case to obtain the required field information and the compliance field information;
[0015] The required fields are stored in the required field set, and the fields and values corresponding to the compliance field information are stored in the compliance array;
[0016] If a field in the reference request matches the required field set, the matched field is modified to obtain a required field exception request.
[0017] If a field in the reference request matches a key-value pair in the compliance array, the value corresponding to the matched field is modified to obtain a compliance exception request.
[0018] The required exception request and the compliance exception request are identified as the exception request.
[0019] Preferably, the matched fields are modified to obtain a required field exception request, including:
[0020] Delete the fields that hit the required set in the reference request to obtain the required exception request.
[0021] Preferably, the value corresponding to the hit field is modified to obtain a compliance exception request, including:
[0022] If the value corresponding to the hit field is consistent with the value of the key-value pair, then the value in the reference request is changed to a value that is not in the key-value pair, and the compliance exception request is obtained.
[0023] If the value corresponding to the hit field is inconsistent with the value of the key-value pair, the reference request will be identified as a compliance exception request.
[0024] Preferably, the field rule information of the request string is obtained from the rule information table corresponding to the interface request parameters, including:
[0025] Use the configuration file class to obtain the address of the rule information table;
[0026] Using the interface request parameter rule class, the rule information table is read from the address, and the field rule information is read from the rule information table.
[0027] Preferably, obtaining the feature test cases corresponding to the target interface includes:
[0028] The feature test cases are read from the table storing feature test cases using a test case interface class; wherein the test case interface class is associated with the feature test cases through annotations.
[0029] Preferably, the abnormal parameter detection function of the target interface is verified using the abnormal information, including:
[0030] Create an interface verification table; the verification table includes number, functional module, test case characteristics, abnormal request, actual request result, and test time.
[0031] Fill the abnormal information into the interface verification table;
[0032] The abnormal parameter detection function is verified using the interface verification table.
[0033] A functional verification device, comprising:
[0034] The test case acquisition module is used to acquire the feature test cases corresponding to the target interface; wherein, the feature test cases include reference requests;
[0035] The information acquisition module is used to retrieve field rule information of the request string from the rule information table corresponding to the interface request parameters;
[0036] The request modification module is used to modify the fields in the reference request using the field rule information to obtain an abnormal request;
[0037] An exception testing module is used to send the exception request to the target interface and receive the exception information fed back by the target interface during the testing of the target interface using the feature test cases.
[0038] An anomaly verification module is used to verify the anomaly parameter detection function of the target interface using the anomaly information. An electronic device includes:
[0039] Memory, used to store computer programs;
[0040] A processor is used to implement the steps of the above-described functional verification method when executing the computer program.
[0041] A readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described functional verification method.
[0042] Using the method provided in the embodiments of this application, feature test cases corresponding to the target interface are obtained; wherein, the feature test cases include a reference request; the field rule information of the request string is obtained from the rule information table corresponding to the interface request parameters; the fields in the reference request are modified using the field rule information to obtain an abnormal request; during the testing of the target interface using feature test cases, an abnormal request is sent to the target interface and the abnormal information fed back by the target interface is received; the abnormal parameter detection function of the target interface is verified using the abnormal information.
[0043] In this application, feature test cases are obtained for testing the target interface. These feature test cases include a reference request. Field rule information for the request string is obtained from a rule information table, which specifies the requirements for the interface request parameters. When testing the interface's abnormal parameter detection function, an abnormal request needs to be constructed. Therefore, the reference request in the feature test case needs to be modified to become an abnormal request. Specifically, changing the reference request to an abnormal request is not arbitrary; rather, it involves modifying the fields in the reference request based on the field rule information to obtain the abnormal request. In other words, the abnormal request is a modification of the field rule information corresponding to the rule information table. Thus, during the testing of the target interface using feature test cases, an abnormal request can be sent to the target interface, and the abnormal information returned by the target interface can be received. Based on this abnormal information, it can be verified whether the target interface's abnormal parameter detection function corresponds to the field rule information, i.e., whether the target interface's abnormal parameter detection function strictly conforms to the rule information table for abnormal detection.
[0044] This application eliminates manual operation by automatically modifying the reference requests in test cases. Furthermore, since the abnormal requests are modified based on the field rule information corresponding to the rule information table, all request parameter rules can be tested one by one without omission, making the final verification results more reliable.
[0045] Accordingly, embodiments of this application also provide a functional verification apparatus, device, and readable storage medium corresponding to the above-described functional verification method, which have the above-described technical effects, and will not be described in detail here. Attached Figure Description
[0046] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0047] Figure 1 This is a flowchart illustrating the implementation of a functional verification method in an embodiment of this application.
[0048] Figure 2 This is a flowchart illustrating a specific implementation of a functional verification method in this application.
[0049] Figure 3 This is a schematic diagram of the structure of a functional verification device according to an embodiment of this application;
[0050] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application;
[0051] Figure 5 This is a schematic diagram of the specific structure of an electronic device in an embodiment of this application. Detailed Implementation
[0052] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0053] Please refer to Figure 1 , Figure 1 This is a flowchart of a functional verification method according to an embodiment of this application. The method includes the following steps:
[0054] S101. Obtain the feature test cases corresponding to the target interface.
[0055] Among them, the feature use cases include reference requests.
[0056] The target interface can be any interface that performs abnormal parameter detection. When there are a large number of interfaces to be tested, these interfaces can be identified as target interfaces one by one in sequence.
[0057] To make it easier to understand, the following is a brief explanation of the situation where the request parameters are abnormal.
[0058] Request parameter exceptions fall into two categories: one is exception validation for required request parameters, and the other is exception validation for non-compliant request parameter values.
[0059] Required request parameters mean that the request parameter must exist in the JSON string of the request and have a valid value. Specifically, they can be divided into three categories:
[0060] ① The request parameter must exist: The request parameter must be present in the JSON string of the request. If the request parameter is deleted from the JSON, the interface will return an error message and will not execute the corresponding logic operation.
[0061] ② Request parameters cannot be empty: The request parameter must exist in the JSON string of the request and its value cannot be empty. If the value of the request parameter in the JSON of the request is empty, the interface will return an error message and will not execute the corresponding logic operation of the interface.
[0062] ③ Request parameters cannot be null: The request parameter must exist in the request JSON string (JavaScript Object Notation, which is the transmission object of the interface, transmitted in the form of a JSON string) and its value cannot be null. If the value of the request parameter in the request JSON is null, the interface will return an error message and will not execute the corresponding logic operation of the interface.
[0063] Request parameter compliance means that the request parameter exists in the JSON string of the request and its value conforms to the rules in the interface design document.
[0064] The characteristic use cases of the interface under test include JSON strings that can successfully connect to the interface, and the data in these JSON strings conforms to the main branch characteristics of the interface. The JSON can be provided by the developers or created by the testers.
[0065] In this embodiment, the feature test cases can be stored in an Excel spreadsheet for easy access. The typical JSON (i.e., the string in the reference request, which includes several fields) of the feature test cases for the mapped interface under test is placed in a single sheet of Excel. As shown in Table 1, the information recorded in the table includes: caseId, interface, test case feature (title), request header (requestHeader), interface address (url), and input (inputParams, i.e., the JSON string corresponding to the request).
[0066] Table 1 is an Excel spreadsheet containing test cases.
[0067]
[0068] In one specific embodiment of this application, obtaining the feature test cases corresponding to the target interface includes: reading the feature test cases from a table storing feature test cases using a test case interface class; wherein the test case interface class is associated with the feature test cases through annotations. That is, a test case interface class can be defined, and the feature test cases of the interface to be tested can be placed in an Excel spreadsheet, and the test case interface class and the feature test cases can be associated through annotation mapping.
[0069] S102. Obtain the field rule information of the request string from the rule information table corresponding to the interface request parameters.
[0070] The rules for API request parameters are organized and stored in an Excel spreadsheet according to the detailed design requirements of the API. These rules include the name of the request parameter, whether it is required, and the rules for filling in the parameter value.
[0071] The rules for the interface request parameters can be derived from the interface design document, as shown in Table 2. The interface request parameter rules can be placed in another sheet of Excel and record the number (caseId), type (types), name (names), parameter name (parameterName), attribute (attribute), required (required), rule (rule), and rule remark (Remark).
[0072] Table 2 is a table of rule information corresponding to interface request parameters.
[0073]
[0074] In this context, the caseId corresponds to the caseId in the request parameter rule document. That is, the caseId values entered in Table 2 should correspond to the caseId values in the typical JSON in Table 1. In other words, the correspondence between interface request rules and feature test cases is represented by numbers. For example, caseIds 1-1, 1-2, 1-3... in Table 2 correspond to caseId 1 in Table 1. This design is due to the requirement of encoding mapping to facilitate personalized validation based on different fields in different JSON formats.
[0075] Rule: This field is for validity validation and requires you to specify the range of values that can be used. Validable rules include:
[0076] ① Out of range: 1|2|3|9; This can be verified as being less than the minimum value and greater than the maximum value;
[0077] ② No more than xx characters: This can be used to verify that a field exceeds xx characters;
[0078] ③ For values equal to YYYY-MM-DDThh:mi:ss: This can verify whether the time is compliant. `entime` only needs to be written as 2024. This can verify that the time is non-compliant in February. For example: if this year is 2024, the time will be changed to 2024-02-30; if 2025 is 2025-02-29.
[0079] ④ Verify if vehicleid is compliant (***_1|2): You can verify that this field is filled with only the license plate color or only the license plate number when making a request;
[0080] ⑤ Greater than or equal to xx: This verifies that the field input is less than this number;
[0081] ⑥ Equal to YYYYMMDD: Can be verified as non-compliant (month and day exceed range 20241655);
[0082] ⑦ Equal to YYYYMMDDHH: Can be verified as non-compliant (month, day, hour exceed range 2024165599);
[0083] ⑧. Equal to YYYY-MM-DD: Can be verified as non-compliant (month, day, hour out of range 2024-16-55);
[0084] Required fields: These are fields that require a field to be filled in. You need to fill in either Yes (Y) or No (N) to indicate whether the field is required or not.
[0085] Other columns can be filled in according to the interface design document. If there is corresponding content in the design document, fill it in; otherwise, leave it blank.
[0086] In one specific embodiment of this application, the field rule information of the request string is obtained from the rule information table corresponding to the interface request parameters, including:
[0087] Use the configuration file class to obtain the address of the rule information table;
[0088] Using the rule class of interface request parameters, read the rule information table from the address, and then read the field rule information from the rule information table.
[0089] In other words, in this embodiment, if the interface parameter rules are stored in a table, the address of the rule information table can be explicitly specified using a configuration file class. For example, a .properties file can be loaded via annotations to obtain the address of the Excel spreadsheet. Then, using the interface request parameter rule class, the rule information can be read from this address, and the field rule information can be read from the rule information table. The request parameter rule class and the interface request parameter rules are associated through annotation mapping.
[0090] It should be noted that in practical applications, steps S101 and S102 can be performed in any order, as shown below. Figure 2 The parallel execution is shown.
[0091] S103. Modify the fields in the reference request using the field rule information to obtain the abnormal request.
[0092] It should be noted that since the main purpose of this application embodiment is to verify the abnormal parameter detection function of the interface, it is necessary to construct an abnormal request in order to test the abnormal detection capability of the interface.
[0093] To ensure targeted verification and comprehensive anomaly detection, this embodiment utilizes field rule information to modify fields in the reference request, thereby generating an anomaly request. In other words, by modifying fields in the reference request based on the field rule information, a deliberately corrected anomaly request is obtained.
[0094] Since the API's exception detection function mainly detects parameter anomalies, the fields in the reference request can be modified, such as deleting required fields or changing the parameter values corresponding to compliant fields to non-compliant ones.
[0095] In one specific embodiment of this application, modifying fields in a reference request using field rule information to obtain an abnormal request includes:
[0096] The field rule information is classified according to the feature use case number to obtain the required field information and the compliance field information;
[0097] Store required fields in a required field collection, and store the fields and values corresponding to the compliance field information in a compliance array;
[0098] If a field in the reference request matches the required field set, then the matched field is modified to generate a required field exception request.
[0099] If a field in the reference request matches a key-value pair in the compliance array, the value corresponding to the matched field is modified, resulting in a compliance exception request.
[0100] Required exception requests and compliant exception requests are identified as exception requests.
[0101] To make it easier to understand, the above steps will be explained in combination below.
[0102] In this embodiment, the feature test case number can be associated with request parameter rules. Therefore, based on the feature test case number, the field rule information can be classified to obtain required field information and compliant field information. For ease of operation and processing, in this embodiment, required fields are stored in a required field set, and the fields and values corresponding to the compliant field information are stored in a compliant array. If a field in the reference request matches the required field set, the matched field is modified to make it an abnormal request with a missing required field. If a field in the request parameter matches a key-value pair in the compliant array, the value corresponding to the name field is modified to obtain an abnormal request with a non-compliant parameter value.
[0103] Specifically, the fields in the field rule information are categorized according to the feature test case number. Required fields are stored in a List type collection (i.e., the required field collection), while fields and values with rule validation are stored in a Map type array (i.e., the compliance array). For example, the fields numbered (caseId) 1-1, 1-2... in Table 2 correspond to the feature test case with caseId 1 in Table 1, and are categorized as follows: keylist (stores required fields): Username, password; valuemap (fields and values with rule validation): Username: 12345678901.
[0104] In one specific embodiment of this application, modifying the hit fields to obtain a required field exception request includes: deleting fields from the required field set hit in the reference request to obtain a required field exception request. That is, by modifying the JSON class, when a required field is hit in the reference request, the required field in the reference request can be directly deleted, thereby obtaining a required field exception request with missing required parameters.
[0105] In one specific implementation of this application, modifying the value corresponding to the hit field to obtain a compliance exception request includes:
[0106] If the value of the hit field matches the value of the key-value pair, the value in the reference request will be changed to the value in the non-key-value pair, resulting in a compliance exception request.
[0107] If the value of the hit field does not match the value of the key-value pair, the reference request will be identified as a compliance exception request.
[0108] In other words, by using a class that modifies parameter values, when a field in the request parameter hits a required field, it can be further determined whether the value of the field that hits the request parameter, i.e. the compliant field, is consistent with the value of the key-value pair that hits the field. If they are consistent, the value in the reference request can be changed to the value in the non-key-value pair, so that the parameter value of the request parameter is non-compliant, and a compliant exception request can be obtained.
[0109] S104. During the testing of the target interface using feature test cases, send an exception request to the target interface and receive the exception information returned by the target interface.
[0110] For ease of description, steps S103 and S104 will be explained together. Regarding the exception verification of required request parameters: the fields stored in the step categories are compared sequentially with the fields in the JSON of the reference request in the feature use case. If the stored field can be successfully compared with the field in the JSON, it means that the JSON contains this request parameter. In this case, the field is modified, and the modified field is put into the original JSON and the request is made again. Otherwise, no modification is made. For example: the request JSON is {"Username": "123456789", "23456789":2345678", "linkPhone":13035644756}, and the keylist (stores required fields): Username, password. If the fields in the keylist correspond to the fields in the JSON, the JSON is modified to {"password": "123456", "linkPhone":13035644756} and the modified JSON is used to make the request.
[0111] like Figure 2 As shown, the exception verification for non-compliant request parameter values is as follows: The fields stored in the category are compared sequentially with the fields in the JSON input from the feature test cases. If a stored field successfully matches a field in the JSON, it means the JSON contains the request parameter. Therefore, the field is illegally modified, and the modified field and value are added to the original JSON for a new request. Otherwise, no modification is made. For example, the request JSON is {"Username":"123456789","password":"123456","linkPhone":13035644756}, and the valuemap (fields and values with rules for validation) shows: Username: 12345678901. If the fields in the keylist correspond to the fields in the JSON, the JSON is modified to {"Username":"12345678901","password":"123456","linkPhone":13035644756}, and the modified JSON is used for the request.
[0112] S105. Utilize abnormal information to verify the abnormal parameter detection function of the target interface.
[0113] After the target interface receives an abnormal request, the abnormal parameter detection function should return abnormal information for all such requests. If no abnormal information is returned, it indicates that the abnormal parameter detection function has not been detected and there is a functional defect. If the returned abnormal information corresponds to the abnormality in the abnormal request, it means that the abnormal parameter detection function is indeed functioning correctly; if the abnormal information does not correspond to the abnormality in the abnormal request, it means that the abnormal parameter detection function is indeed abnormal. The verification standard is whether it conforms to the design document requirements.
[0114] Therefore, based on whether or not abnormal information is fed back, and the content of the abnormal information fed back, the abnormal parameter detection function of the target interface can be effectively verified.
[0115] In one specific embodiment of this application, the abnormal parameter detection function of the target interface is verified using abnormal information, including:
[0116] Create an interface verification table; the verification table includes number, functional module, test case characteristics, abnormal request, actual request result, and test time;
[0117] Fill the exception information into the interface verification form;
[0118] The abnormal parameter detection function is verified using an interface verification table.
[0119] In this embodiment, the verification results can be output to Excel. Each time the `newRegressionTest` method is called, the `Create` method is called, and the caseId, interface, test case characteristics, inputParams, actual request result, test time, and tester information are entered into the document. This interface verification table is shown in Table 3.
[0120] Table 3 is an interface verification table.
[0121]
[0122] In other words, in this embodiment, the verification standard is based on the parameters in the interface design document. By modifying a normal JSON request to an abnormal JSON and then making the request again, the interface is tested for exceptions. This verifies whether the request program can intercept the abnormal JSON content and provide the corresponding exception message. In this way, the abnormal parameter detection function of the interface can be clearly determined based on the exception information.
[0123] Using the method provided in the embodiments of this application, feature test cases corresponding to the target interface are obtained; wherein, the feature test cases include a reference request; the field rule information of the request string is obtained from the rule information table corresponding to the interface request parameters; the fields in the reference request are modified using the field rule information to obtain an abnormal request; during the testing of the target interface using feature test cases, an abnormal request is sent to the target interface and the abnormal information fed back by the target interface is received; the abnormal parameter detection function of the target interface is verified using the abnormal information.
[0124] In this application, feature test cases are obtained for testing the target interface. These feature test cases include a reference request. Field rule information for the request string is obtained from a rule information table, which specifies the requirements for the interface request parameters. When testing the interface's abnormal parameter detection function, an abnormal request needs to be constructed. Therefore, the reference request in the feature test case needs to be modified to become an abnormal request. Specifically, changing the reference request to an abnormal request is not arbitrary; rather, it involves modifying the fields in the reference request based on the field rule information to obtain the abnormal request. In other words, the abnormal request is a modification of the field rule information corresponding to the rule information table. Thus, during the testing of the target interface using feature test cases, an abnormal request can be sent to the target interface, and the abnormal information returned by the target interface can be received. Based on this abnormal information, it can be verified whether the target interface's abnormal parameter detection function corresponds to the field rule information, i.e., whether the target interface's abnormal parameter detection function strictly conforms to the rule information table for abnormal detection.
[0125] This application eliminates manual operation by automatically modifying the reference requests in test cases. Furthermore, since the abnormal requests are modified based on the field rule information corresponding to the rule information table, all request parameter rules can be tested one by one without omission, making the final verification results more reliable.
[0126] Corresponding to the above method embodiments, this application also provides a functional verification device. The functional verification device described below can be referred to in correspondence with the functional verification method described above.
[0127] See Figure 3 As shown, the device includes the following modules:
[0128] The test case acquisition module 101 is used to acquire the feature test cases corresponding to the target interface; wherein, the feature test cases include reference requests;
[0129] The information acquisition module 102 is used to obtain the field rule information of the request string from the rule information table corresponding to the interface request parameters;
[0130] The request modification module 103 is used to modify fields in the reference request using field rule information to obtain an abnormal request;
[0131] The exception testing module 104 is used to send exception requests to the target interface and receive exception information from the target interface during the testing of the target interface using feature test cases.
[0132] The anomaly verification module 105 is used to verify the anomaly parameter detection function of the target interface using anomaly information.
[0133] Using the apparatus provided in the embodiments of this application, feature test cases corresponding to a target interface are obtained; wherein, the feature test cases include a reference request; field rule information of the request string is obtained from the rule information table corresponding to the interface request parameters; the field rule information is used to modify the fields in the reference request to obtain an abnormal request; during the testing of the target interface using feature test cases, an abnormal request is sent to the target interface and the abnormal information fed back by the target interface is received; the abnormal information is used to verify the abnormal parameter detection function of the target interface.
[0134] In this application, feature test cases are obtained for testing the target interface. These feature test cases include a reference request. Field rule information for the request string is obtained from a rule information table, which specifies the requirements for the interface request parameters. When testing the interface's abnormal parameter detection function, an abnormal request needs to be constructed. Therefore, the reference request in the feature test case needs to be modified to become an abnormal request. Specifically, changing the reference request to an abnormal request is not arbitrary; rather, it involves modifying the fields in the reference request based on the field rule information to obtain the abnormal request. In other words, the abnormal request is a modification of the field rule information corresponding to the rule information table. Thus, during the testing of the target interface using feature test cases, an abnormal request can be sent to the target interface, and the abnormal information returned by the target interface can be received. Based on this abnormal information, it can be verified whether the target interface's abnormal parameter detection function corresponds to the field rule information, i.e., whether the target interface's abnormal parameter detection function strictly conforms to the rule information table for abnormal detection.
[0135] This application eliminates manual operation by automatically modifying the reference requests in test cases. Furthermore, since the abnormal requests are modified based on the field rule information corresponding to the rule information table, all request parameter rules can be tested one by one without omission, making the final verification results more reliable.
[0136] In one specific embodiment of this application, the request modification module is specifically used to classify field rule information according to the feature use case number to obtain required field information and compliance field information; store the required fields in a required set, and store the fields and values corresponding to the compliance field information in a compliance array; if a field in the reference request matches the required set, the matched field is modified to obtain a required field exception request; if a field in the reference request matches a key-value pair in the compliance array, the value corresponding to the matched field is modified to obtain a compliance exception request; and the required field exception request and the compliance exception request are identified as exception requests.
[0137] In one specific embodiment of this application, the request modification module is specifically used to delete fields of the required set hit in the reference request, thereby obtaining a required field exception request.
[0138] In one specific embodiment of this application, the request modification module is specifically used to change the value in the reference request to the value in the non-key-value pair if the value corresponding to the hit field is consistent with the value of the key-value pair, thereby obtaining a compliance exception request; if the value corresponding to the hit field is inconsistent with the value of the key-value pair, the reference request is determined to be a compliance exception request.
[0139] In one specific embodiment of this application, the information acquisition module is specifically used to obtain the address of the rule information table using a configuration file class; to read the rule information table from the address using an interface request parameter rule class; and to read field rule information from the rule information table.
[0140] In one specific embodiment of this application, the test case acquisition module is specifically used to read feature test cases from a table storing feature test cases using a test case interface class; wherein, the test case interface class is associated with the feature test cases through annotations.
[0141] In one specific embodiment of this application, the exception verification module is specifically used to create an interface verification table; the verification table includes a number, functional module, test case characteristics, exception request, actual request result, and test time; exception information is filled into the interface verification table; and the interface verification table is used to verify the exception parameter detection function.
[0142] Corresponding to the above method embodiments, this application also provides an electronic device. The electronic device described below and the functional verification method described above can be referred to each other.
[0143] See Figure 4 As shown, the electronic device includes:
[0144] Memory 332 is used to store computer programs;
[0145] The processor 322 is used to implement the steps of the functional verification method of the above method embodiment when executing a computer program.
[0146] For details, please refer to Figure 5 , Figure 5 This is a schematic diagram of the specific structure of an electronic device provided in this embodiment. The electronic device can vary significantly due to differences in configuration or performance. It may include one or more central processing units (CPUs) (e.g., one or more processors) and a memory 332. The memory 332 stores one or more computer programs 342 or data 344. The memory 332 can be temporary or permanent storage. The program stored in the memory 332 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the data processing device. Furthermore, the processor 322 may be configured to communicate with the memory 332 and execute the series of instruction operations stored in the memory 332 on the electronic device 301.
[0147] Electronic device 301 may also include one or more power supplies 326, one or more wired or wireless network interfaces 350, one or more input / output interfaces 358, and / or one or more operating systems 341.
[0148] The steps in the functional verification method described above can be implemented by the structure of the electronic device.
[0149] Corresponding to the above method embodiments, this application also provides a readable storage medium. The readable storage medium described below and the functional verification method described above can be referred to each other.
[0150] A readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the functional verification method described in the above method embodiments.
[0151] The readable storage medium can specifically be a USB flash drive, external hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, or any other readable storage medium capable of storing program code.
[0152] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.
[0153] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0154] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.
[0155] Finally, it should be noted that in this document, relationships such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "include," "contain," or any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.
[0156] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A functional verification method, characterized in that, include: Obtain the feature use cases corresponding to the target interface; wherein, the feature use cases include reference requests; Retrieve the field rule information of the request string from the rule information table corresponding to the interface request parameters; By modifying the fields in the reference request using the field rule information, an abnormal request is obtained; During the testing of the target interface using the feature test cases, the exception request is sent to the target interface, and the exception information fed back by the target interface is received. The abnormal information is used to verify the abnormal parameter detection function of the target interface.
2. The method according to claim 1, characterized in that, Modifying fields in the reference request using the aforementioned field rule information to obtain an abnormal request includes: The field rule information is classified according to the number of the feature use case to obtain the required field information and the compliance field information; The required fields are stored in the required field set, and the fields and values corresponding to the compliance field information are stored in the compliance array; If a field in the reference request matches the required field set, the matched field is modified to obtain a required field exception request. If a field in the reference request matches a key-value pair in the compliance array, the value corresponding to the matched field is modified to obtain a compliance exception request. The required exception request and the compliance exception request are identified as the exception request.
3. The method according to claim 2, characterized in that, Modify the selected fields to obtain a required field exception request, including: Delete the fields that hit the required set in the reference request to obtain the required exception request.
4. The method according to claim 2, characterized in that, Modifying the values corresponding to the hit fields generates a compliance exception request, including: If the value corresponding to the hit field is consistent with the value of the key-value pair, then the value in the reference request is changed to a value that is not in the key-value pair, and the compliance exception request is obtained. If the value corresponding to the hit field is inconsistent with the value of the key-value pair, the reference request will be identified as a compliance exception request.
5. The method according to claim 1, characterized in that, Retrieve the field rule information of the request string from the rule information table corresponding to the interface request parameters, including: Use the configuration file class to obtain the address of the rule information table; Using the interface request parameter rule class, the rule information table is read from the address, and the field rule information is read from the rule information table.
6. The method according to claim 1, characterized in that, Obtain the feature test cases corresponding to the target interface, including: The feature test cases are read from the table storing feature test cases using a test case interface class; wherein the test case interface class is associated with the feature test cases through annotations.
7. The method according to any one of claims 1 to 6, characterized in that, The abnormal parameter detection function of the target interface is verified using the abnormal information, including: Create an interface verification table; the verification table includes number, functional module, test case characteristics, abnormal request, actual request result, and test time. Fill the abnormal information into the interface verification table; The abnormal parameter detection function is verified using the interface verification table.
8. A functional verification device, characterized in that, include: The test case acquisition module is used to acquire the feature test cases corresponding to the target interface; wherein, the feature test cases include reference requests; The information acquisition module is used to retrieve field rule information of the request string from the rule information table corresponding to the interface request parameters; The request modification module is used to modify the fields in the reference request using the field rule information to obtain an abnormal request; An exception testing module is used to send the exception request to the target interface and receive the exception information fed back by the target interface during the testing of the target interface using the feature test cases. An anomaly verification module is used to verify the anomaly parameter detection function of the target interface using the anomaly information.
9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the functional verification method as described in any one of claims 1 to 7.
10. A readable storage medium, characterized in that, The readable storage medium stores a computer program that, when executed by a processor, implements the steps of the functional verification method as described in any one of claims 1 to 7.