An interface testing method and apparatus

Abstract

The application discloses an interface test method and device, and relates to the technical field of computers. A specific implementation of the method comprises the following steps: acquiring a general interface contract file, wherein the general interface contract file indicates a selected abnormality check type of a to-be-tested interface and a dynamic generation rule of interface parameters; generating an abnormality test case of the to-be-tested interface according to the selected abnormality check type in the general interface contract file, so as to be used for executing interface test; wherein the interface parameters used by the abnormality test case are generated according to the dynamic generation rule. The implementation can improve the construction efficiency of the abnormality test case, reduce the error rate and the missing test rate, and improve the efficiency and the accuracy of the test.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an interface testing method and apparatus. Background Technology

[0002] Interface parameter exception testing in API functional testing refers to a type of test scenario generated based on the interface parameter attributes defined in the interface definition document. Basic interface parameter attributes mainly include: parameter data type, parameter length, and whether the parameter is required. In designing test cases for interface parameter exception scenarios, 0-3 general exception test cases can be designed based on each interface parameter attribute setting: incorrect interface input parameter data type, excessively long interface input parameter, and missing required interface parameter. Existing commonly used interface testing tools include Postman (an extensible API development and testing collaboration platform tool) and JMeter (a pure Java open-source project). During interface testing, testers need to manually construct exception test cases for each interface input parameter according to the interface definition parameter attributes.

[0003] In the process of realizing this invention, the inventors discovered at least the following problems in the prior art:

[0004] The construction of abnormal test cases is inefficient, with high error and missed test rates, resulting in low testing efficiency and accuracy. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide an interface testing method and apparatus that can improve the efficiency of constructing abnormal test cases, reduce the error rate and missed test rate, and improve the efficiency and accuracy of testing.

[0006] To achieve the above objectives, according to one aspect of the present invention, an interface testing method is provided.

[0007] An interface testing method includes: obtaining a general interface contract file, wherein the general interface contract file indicates a selected exception verification type and dynamic generation rules for interface parameters of the interface to be tested; generating exception test cases for the interface to be tested according to the selected exception verification type in the general interface contract file, for use in executing interface testing; wherein the interface parameters used in the exception test cases are generated according to the dynamic generation rules.

[0008] Optionally, before obtaining the general interface contract file, the process includes: constructing the general interface contract file, which includes: passing in the basic information of the interface to be tested, the basic information including the interface call address, call type, and request header of the interface to be tested.

[0009] Optionally, constructing the general interface contract file further includes: passing in the attribute information, data type, and dynamic generation rules of the interface parameters of the interface to be tested, wherein the attribute information is used to select the exception verification type of the interface parameters.

[0010] Optionally, the step of passing in the attribute information, data type, and dynamic generation rule of the interface parameter to be tested includes: concatenating the attribute information, data type, and dynamic generation rule into a string and passing it in the form of the concatenated string. The attribute information includes information indicating whether each item in whether the interface parameter is required, whether type validation is performed, and whether data validation is performed is selected.

[0011] Optionally, the number of interfaces to be tested can be one or more; generating exception test cases for the interfaces to be tested according to the selected exception verification type in the general interface contract file includes: generating general test parameters for each interface according to the parameter name, data type, and dynamic generation rules of each interface parameter in the general interface contract file; obtaining the general input parameters of the interfaces to be tested from the set of general test parameters that are required for the corresponding interface parameters in the attribute information; changing the general input parameters according to the attribute information of each interface parameter to generate exception test input parameters for each interface to be tested; and obtaining the set of exception test cases for each interface to be tested based on each exception test input parameter.

[0012] Optionally, the execution of interface testing includes: for each of the abnormal test parameters in the set of abnormal test cases, testing the interface to be tested using the abnormal test parameter, and comparing the attribute information of each interface parameter corresponding to the abnormal test parameter with the return result of the interface to be tested to obtain the test result of the abnormal test parameter; and generating a test report of the interface to be tested based on the test results of all the abnormal test parameters.

[0013] Optionally, the general interface contract file is a JSON file.

[0014] According to another aspect of the present invention, an interface testing apparatus is provided.

[0015] An interface testing apparatus includes: a general interface contract file acquisition module, configured to acquire a general interface contract file, wherein the general interface contract file indicates a selected exception verification type and dynamic generation rules for interface parameters of the interface to be tested; and an exception test case generation module, configured to generate exception test cases for the interface to be tested based on the selected exception verification type in the general interface contract file, for use in executing interface testing; wherein the interface parameters used in the exception test cases are generated according to the dynamic generation rules.

[0016] Optionally, it also includes a general interface contract file construction module, used to: construct the general interface contract file, including: inputting the basic information of the interface to be tested, the basic information including the interface call address, call type, and request header of the interface to be tested.

[0017] Optionally, the general interface contract file construction module is further used to: input the attribute information, data type and dynamic generation rule of the interface parameters of the interface to be tested, wherein the attribute information is used to select the exception verification type of the interface parameters.

[0018] Optionally, the general interface contract file construction module is further configured to: concatenate the attribute information, the data type, and the dynamic generation rule into a string and pass it in as a concatenated string, wherein the attribute information includes information indicating whether each item in the interface parameter is required, whether type validation is performed, and whether data validation is performed is selected.

[0019] Optionally, the number of interfaces to be tested can be one or more; the abnormal test case generation module is further configured to: generate general test parameters for each interface according to the parameter name, data type, and dynamic generation rules of each interface parameter in the general interface contract file; obtain the general input parameters of the interface to be tested from the set of general test parameters that are required for the corresponding interface parameters in the attribute information; modify the general input parameters according to the attribute information of each interface parameter to generate abnormal test input parameters for each interface to be tested; and obtain the set of abnormal test cases for each interface to be tested based on each abnormal test input parameter.

[0020] Optionally, it also includes an interface testing module, configured to: test the interface to be tested using each of the abnormal test parameters in the set of abnormal test cases, and compare the attribute information of each interface parameter corresponding to the abnormal test parameter with the return result of the interface to be tested to obtain the test result of the abnormal test parameter; and generate a test report of the interface to be tested based on the test results of all the abnormal test parameters.

[0021] Optionally, the general interface contract file is a JSON file.

[0022] According to another aspect of the present invention, an electronic device is provided.

[0023] An electronic device includes: one or more processors; and a memory for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the interface testing method provided in the embodiments of the present invention.

[0024] According to another aspect of the present invention, a computer-readable medium is provided.

[0025] A computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the interface testing method provided in the embodiments of the present invention.

[0026] One embodiment of the above invention has the following advantages or beneficial effects: A general interface contract file is obtained, which indicates the selected exception verification type and dynamic generation rules for interface parameters of the interface to be tested; based on the selected exception verification type in the general interface contract file, exception test cases for the interface to be tested are generated for executing interface tests; wherein the interface parameters used in the exception test cases are generated according to the dynamic generation rules. This improves the efficiency of constructing exception test cases, reduces the error rate and missed test rate, and improves the efficiency and accuracy of testing.

[0027] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0028] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0029] Figure 1 This is a schematic diagram of the main steps of an interface testing method according to an embodiment of the present invention;

[0030] Figure 2 This is a flowchart illustrating the generation of abnormal test cases according to an embodiment of the present invention;

[0031] Figure 3 This is a flowchart illustrating an interface testing process according to an embodiment of the present invention;

[0032] Figure 4 This is a schematic diagram of the main modules of an interface testing device according to an embodiment of the present invention;

[0033] Figure 5 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied;

[0034] Figure 6 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation

[0035] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0036] Figure 1 This is a schematic diagram of the main steps of an interface testing method according to an embodiment of the present invention.

[0037] like Figure 1 As shown, an interface testing method according to an embodiment of the present invention mainly includes the following steps S101 to S102.

[0038] Step S101: Obtain the general interface contract file, which indicates the selected exception verification type and dynamic generation rules of the interface parameters of the interface to be tested.

[0039] Before obtaining the general interface contract file, the process may include: constructing the general interface contract file, which may include: passing in the basic information of the interface to be tested, including the interface call address, call type, and request headers of the interface to be tested.

[0040] The general interface contract file can also include: attribute information, data type, and dynamic generation rules of the interface parameters passed to the interface to be tested. The attribute information is used to select the exception verification type of the interface parameters.

[0041] The interface parameters passed to the interface to be tested include attribute information, data type, and dynamic generation rules. This can include concatenating the attribute information, data type, and dynamic generation rules into a string and passing it as the concatenated string. The attribute information includes information indicating whether each item in the options for mandatory interface parameters, type validation, and data validation is selected. Whether the interface parameters are mandatory, type validation, and data validation are examples of exception validation types (or exception types). The information indicating whether an exception validation type is selected can be specific characters, such as "Y" indicating selection and "N" indicating non-selection. Therefore, the concatenated string "Y_N_N_int_0_10" means: the interface parameter is mandatory (Y), no type validation (N) and no data validation (N), the data type is int, and the dynamic generation rule is to generate a random integer between 0 and 10.

[0042] The number of interfaces to be tested can be one or more. This embodiment of the invention can support simultaneous batch testing of multiple interfaces.

[0043] The general interface contract file can be a JSON file.

[0044] Step S102: Generate exception test cases for the interface to be tested based on the exception verification type selected in the general interface contract file, so as to execute interface tests; wherein, the interface parameters used in the exception test cases are generated according to dynamic generation rules.

[0045] Based on the exception verification type selected in the general interface contract file, generate exception test cases for the interface to be tested. This may include: generating general test parameters for each interface based on the parameter name, data type, and dynamic generation rules of each interface parameter in the general interface contract file. The general test parameters are the specific parameter values ​​generated for the interface parameters according to the dynamic generation rules; obtaining the general input parameters of the interface to be tested from the set of general test parameters that are required for the corresponding interface parameters in the attribute information; modifying the general input parameters according to the attribute information of each interface parameter to generate exception test input parameters for each interface to be tested. Modifying the general input parameters specifically involves changing the values ​​of the general test parameters in the general input parameters. For example, when the values ​​of one or more general test parameters in the general input parameters are changed, the resulting set of new general test parameters is called the exception test input parameters; and obtaining a set of exception test cases for each interface to be tested based on the exception test input parameters.

[0046] Performing interface testing may include: for each abnormal test parameter in the set of abnormal test cases, testing the interface to be tested using the abnormal test parameter, comparing the attribute information of each interface parameter corresponding to the abnormal test parameter with the return result of the interface to be tested to obtain the test result corresponding to the abnormal test parameter; and generating a test report for the interface to be tested based on the test results of all abnormal test parameters.

[0047] In one embodiment, a generic interface contract file is constructed, including: basic information of the interface to be tested, attribute information, data type, and dynamic generation rules of the interface parameters of the interface to be tested, whereby the attribute information is used to select the exception verification type of the interface parameters. Specifically, the generic interface contract file is a JSON file (a lightweight data exchange format). Testers store the basic information of the interface to be tested in the generic interface contract file in key-value format. The basic information may include the interface call address, call type, request headers, etc., of the interface to be tested. The call type can be the method that calls the interface, and the request headers may include the requested method, URI (Generic Resource Identifier), protocol version, and request modifiers, client information, etc. The attribute information, data type, and dynamic generation rules of the interface parameters can be placed in the form of a sub-JSON, with the format key-json. The sub-JSON is filled in according to the input parameter format, where the key is the interface parameter name and the value is a string concatenated with the input parameter attributes. The concatenation rule of key-json can be: "interface parameter name": "required (Y (yes) / N (no))_type validation (Y / N)_data validation (Y / N)_data type of interface parameter_dynamic generation rule (generation rule defined for data type)". The data validation of the interface parameter can be data length validation or data size validation. The data type of the interface parameter can be string, int, float, etc. For example, input parameter 1 is named inputParam1, is a required parameter, requires type validation but does not require data validation, is a string type, and has a dynamic generation rule of 06_APN, meaning the dynamically generated value of input parameter 1 is APN + current timestamp. APN can be a custom string. Input parameter 2 is named inputParam2, is a required parameter, does not require type validation or data validation, is an integer type, and has a dynamic generation rule of 0_10, meaning the dynamically generated value of input parameter 2 is a random integer value between 0 and 10. Input parameter 3 is named inputParam3, is a required parameter, does not require type validation or data validation, is a single-precision floating-point type, and has a dynamic generation rule of 0_100_2, meaning the dynamically generated value of input parameter 3 is a random value between 0 and 100, accurate to two decimal places. Examples of the attribute information, data type, and dynamic generation rules for each input parameter are as follows:

[0048] {"inputParam1":"Y_Y_N_String_06_APN";

[0049] "inputParam2":"Y_N_N_int_0_10";

[0050] "inputParam3":"Y_N_N_float_0_100_2";

[0051] Figure 2 This is a schematic diagram of the process for generating abnormal test cases according to an embodiment of the present invention.

[0052] like Figure 2 As shown, in one embodiment, general test parameters for each interface are generated based on the parameter names, data types, and dynamic generation rules of each interface parameter in the general interface contract file. The general input parameters of the interface to be tested are obtained from the set of general test parameters that are mandatory for the corresponding interface parameters in the attribute information. Based on the attribute information of each interface parameter, the general input parameters are modified to generate abnormal test input parameters for each interface to be tested. A set of abnormal test cases for each interface to be tested is obtained based on the abnormal test input parameters. Specifically, the general interface contract file can be parsed by repeatedly calling the data parsing function (dataParse) to obtain the attribute information, data types, and dynamic generation rules of each interface parameter. Based on the parsed attribute information, data types, and dynamic generation rules of each interface parameter, general test parameters are dynamically generated. A general input parameter for the interface to be tested is generated using the mandatory general test parameters of each interface corresponding to the interface to be tested, serving as the normal input parameter of the interface to be tested (relative to abnormal input parameters). Based on the attribute information of each interface parameter, the common test parameters in the common input parameters are modified. For required parameters, exception test parameters are generated for missing parameters; for parameters requiring type validation, exception test parameters for abnormal data types are generated; for parameters requiring data length validation, exception test parameters for abnormal data length are generated; and for parameters requiring data size validation, exception test parameters for abnormal data value size are generated. For example, if input parameter 1 is "inputParam1":"Y_Y_N_String_06_APN", then two exception test parameters can be generated for input parameter 1: an exception test parameter for missing inputParam1 and an exception test parameter for inputParam1 being of a type other than String. Based on these exception test parameters, a set of exception test cases for each interface under test can be obtained, and the set of exception test cases includes one or more exception test parameters.

[0053] In one embodiment, for each abnormal test parameter in the set of abnormal test cases, the interface to be tested is tested using the abnormal test parameter, and the attribute information of each interface parameter corresponding to the abnormal test parameter and the return result of the interface to be tested are compared to obtain the test result of the abnormal test parameter; based on the test results of all abnormal test parameters, a test report of the interface to be tested is generated. Specifically, an automated API testing framework can be built using unittest (a unit testing framework based on Python), request (an HTTP request invocation module based on Python), and httprunner (a general testing framework for the HTTP(S) protocol based on Python). Parameterized (a parameterization library based on Python) is used to dynamically assemble the exception test parameters from the automatically generated set of exception test cases. Based on the call address, call type, and request headers of the API under test, each exception test parameter is used to test the API. The API responds to the exception test parameter by returning its return code (i.e., the return result). The return codes of each exception test parameter are compared with the exception return codes defined for the API under test. If the return code of the exception test parameter matches the exception return code defined for the API under test, the test for that exception test parameter passes; otherwise, the test for that exception test parameter fails. Based on the test results of all exception test parameters corresponding to the API under test, a test report for the API under test is generated.

[0054] Figure 3 This is a schematic diagram of the interface testing process according to an embodiment of the present invention.

[0055] like Figure 3 As shown, in one embodiment, testers construct a general interface contract file. Based on this general interface contract file, the present invention recursively calls the general parameter generation function (generalParamGenerate), which generates general interface parameters according to dynamic parameter generation rules. It also recursively calls the exception case generation function (exceptionCaseGenerate), which generates corresponding exception test parameters (i.e., exception test cases) based on parameter attribute information. The interface is then tested using these exception test parameters, and a test report is generated based on the test results. This significantly reduces the error rate and missed test rate, improves the testing efficiency for interface parameter exception scenarios, ensures the robustness of the interface, and allows testers to better dedicate their limited time to verifying the core business logic of the interface.

[0056] In one embodiment, a generic interface contract file can be a file that identifies attributes such as interface parameter types, whether they are required, and data lengths according to a specific format, based on the interface documentation. An example of a generic interface contract file could be:

[0057]

[0058]

[0059] "applyNo":"Y_N_N_String_06_APN", # Parameter attribute identifier: whether required, whether type validation is required, whether length validation is required, data type, dynamically generated rule

[0060]

[0061] Figure 4 This is a schematic diagram of the main modules of an interface testing device according to an embodiment of the present invention.

[0062] like Figure 4 As shown, an interface testing device 400 according to an embodiment of the present invention mainly includes: a general interface contract file acquisition module 401 and an abnormal test case generation module 402.

[0063] The general interface contract file acquisition module 401 is used to acquire the general interface contract file, which indicates the selected exception verification type and dynamic generation rules of the interface parameters of the interface to be tested.

[0064] The exception test case generation module 402 is used to generate exception test cases for the interface to be tested based on the exception verification type selected in the general interface contract file, so as to execute interface testing; wherein, the interface parameters used in the exception test cases can be generated according to dynamic generation rules.

[0065] In one embodiment, a general interface contract file construction module may be included, for: constructing a general interface contract file, which may include: basic information of the interface to be tested, including the interface call address, call type, and request header of the interface to be tested.

[0066] In one embodiment, the general interface contract file construction module is specifically used to: input the attribute information, data type, and dynamic generation rules of the interface parameters of the interface to be tested, wherein the attribute information is used to select the exception verification type of the interface parameters.

[0067] In one embodiment, the general interface contract file construction module is specifically used to: concatenate attribute information, data type, and dynamically generated rules into a string and pass it in as a concatenated string. The attribute information may include information indicating whether each item in the interface parameter is required, whether type validation is performed, and whether data validation is performed is selected.

[0068] In one embodiment, the number of interfaces to be tested can be one or more; the exception test case generation module 402 is specifically used to: generate general test parameters for each interface according to the parameter name, data type and dynamic generation rules of each interface parameter in the general interface contract file; generate general input parameters for the interface to be tested from the general test parameters whose corresponding interface parameters are required in the attribute information; modify the general input parameters according to the attribute information of each interface parameter to generate exception test input parameters for each interface to be tested; and obtain a set of exception test cases for each interface to be tested based on each exception test input parameter.

[0069] In one embodiment, it may further include an interface testing module, configured to: for each abnormal test parameter in the set of abnormal test cases, test the interface to be tested using the abnormal test parameter, compare the attribute information of each interface parameter corresponding to the abnormal test parameter with the return result of the interface to be tested, and obtain the test result of the abnormal test parameter; and generate a test report of the interface to be tested based on the test results of all abnormal test parameters.

[0070] In one embodiment, the generic interface contract file can be a JSON file.

[0071] Furthermore, the specific implementation details of the interface testing device in this embodiment of the invention have been described in detail in the interface testing method above, so they will not be repeated here.

[0072] Figure 5 An exemplary system architecture 500 is shown that can be applied to the interface testing method or interface testing apparatus of the present invention.

[0073] like Figure 5 As shown, system architecture 500 may include terminal devices 501, 502, and 503, a network 504, and a server 505. Network 504 serves as the medium for providing communication links between terminal devices 501, 502, and 503 and server 505. Network 504 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0074] Users can use terminal devices 501, 502, and 503 to interact with server 505 via network 504 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 501, 502, and 503, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0075] Terminal devices 501, 502, and 503 can be various electronic devices with displays that support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0076] Server 505 can be a server that provides various services, such as a backend management server that supports shopping websites browsed by users using terminal devices 501, 502, and 503 (for example only). The backend management server can analyze and process data such as received product information query requests, and feed back the processing results (such as target push information, product information - for example only) to the terminal device.

[0077] It should be noted that the interface testing method provided in this embodiment of the invention is generally executed by server 505, and correspondingly, the interface testing device is generally set in server 505.

[0078] It should be understood that Figure 5 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0079] The following is for reference. Figure 6 It shows a schematic diagram of the structure of a computer system 600 suitable for implementing terminal devices or servers of the present invention. Figure 6 The terminal device or server shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0080] like Figure 6 As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 602 or programs loaded from storage section 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of the system 600. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0081] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0082] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs the functions defined above in the system of this invention.

[0083] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0084] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0085] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor may be described as including a general interface contract file acquisition module and an exception test case generation module. The names of these modules do not necessarily limit the module itself; for example, the general interface contract file acquisition module may also be described as "a module for acquiring a general interface contract file."

[0086] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to: acquire a general interface contract file, the general interface contract file indicating a selected exception verification type and dynamic generation rules for interface parameters of the interface to be tested; generate exception test cases for the interface to be tested according to the exception verification type selected in the general interface contract file, for performing interface testing; wherein the interface parameters used in the exception test cases are generated according to the dynamic generation rules.

[0087] According to the technical solution of this invention, a general interface contract file is obtained, which indicates the selected exception verification type and dynamic generation rules of interface parameters for the interface to be tested. Based on the selected exception verification type in the general interface contract file, exception test cases for the interface to be tested are generated for executing interface tests. The interface parameters used in the exception test cases are generated according to the dynamic generation rules. This improves the efficiency of constructing exception test cases, reduces the error rate and missed test rate, and improves the efficiency and accuracy of testing.

[0088] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. An interface testing method, characterized in that, include: Obtain a general interface contract file, which indicates the selected exception verification type, attribute information of interface parameters, data type, and dynamic generation rules of interface parameters for the interface to be tested. The attribute information, data type, and dynamic generation rules are passed in as concatenated strings. The attribute information includes selected information indicating whether interface parameters are required, whether type validation is performed, and whether data validation is performed. Based on the selected exception verification type in the general interface contract file, and in conjunction with the data type of the interface parameters and the dynamic generation rules, exception test cases for the interface to be tested are generated for use in executing interface tests; wherein, the interface parameters used in the exception test cases are generated according to the dynamic generation rules; The number of interfaces to be tested is one or more; generating abnormal test cases for the interfaces to be tested according to the selected abnormal verification type in the general interface contract file includes: generating general test parameters for each interface according to the parameter name, data type, and dynamic generation rules of each interface parameter in the general interface contract file; obtaining the general input parameters of the interfaces to be tested from the set of general test parameters that are required for the corresponding interface parameters in the attribute information; changing the general input parameters according to the attribute information of each interface parameter to generate abnormal test input parameters for each interface to be tested; and obtaining the set of abnormal test cases for each interface to be tested based on each abnormal test input parameter.

2. The method according to claim 1, characterized in that, Before obtaining the general interface contract file, the following steps are included: Construct the general interface contract file, which includes: inputting the basic information of the interface to be tested, including the interface call address, call type, and request header of the interface to be tested.

3. The method according to claim 2, characterized in that, The construction of the general interface contract file also includes: The interface parameters of the interface to be tested are passed in with attribute information, data type, and dynamic generation rules. The attribute information is used to select the exception verification type of the interface parameters.

4. The method according to claim 3, characterized in that, The attribute information, data type, and dynamic generation rules of the interface parameters passed to the interface to be tested include: The attribute information, the data type, and the dynamically generated rules are concatenated into a string and passed in as a concatenated string. The attribute information includes information indicating whether each item in the interface parameters is required, whether type validation is required, and whether data validation is required is selected.

5. The method according to claim 1, characterized in that, The execution interface test includes: For each abnormal test parameter in the set of abnormal test cases, the interface to be tested is tested using the abnormal test parameter, and the attribute information of each interface parameter corresponding to the abnormal test parameter and the return result of the interface to be tested are compared to obtain the test result of the abnormal test parameter. Based on the test results of all the aforementioned abnormal test input parameters, a test report is generated for the interface to be tested.

6. The method according to claim 1, characterized in that, The general interface contract file is a JSON file.

7. An interface testing device, characterized in that, include: A general interface contract file acquisition module is used to acquire a general interface contract file. The general interface contract file indicates the selected exception verification type, interface parameter attribute information, data type, and dynamic generation rules of the interface to be tested. The attribute information, data type, and dynamic generation rules are passed in the form of concatenated strings. The attribute information includes selection information indicating whether the interface parameters are required, whether type validation is performed, and whether data validation is performed. An exception test case generation module is used to generate exception test cases for the interface to be tested based on the selected exception verification type in the general interface contract file, combined with the data type of the interface parameters and dynamic generation rules, for the purpose of executing interface testing; wherein, the interface parameters used in the exception test cases are generated according to the dynamic generation rules; The number of interfaces to be tested is one or more; generating abnormal test cases for the interfaces to be tested according to the selected abnormal verification type in the general interface contract file includes: generating general test parameters for each interface according to the parameter name, data type, and dynamic generation rules of each interface parameter in the general interface contract file; obtaining the general input parameters of the interfaces to be tested from the set of general test parameters that are required for the corresponding interface parameters in the attribute information; changing the general input parameters according to the attribute information of each interface parameter to generate abnormal test input parameters for each interface to be tested; and obtaining the set of abnormal test cases for each interface to be tested based on each abnormal test input parameter.

8. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-6.

9. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-6.

Images