Interface test case generation method, electronic device and storage medium

Abstract

The embodiment of the present application provides an interface test case generation method, an electronic device, and a storage medium, the method comprising: obtaining an interface call log and an interface definition file; performing data conversion on the interface call log and the interface definition file according to a preset data conversion rule to obtain a mapping set of each interface and interface information, the interface information including at least one of an interface name definition, an interface request method, an interface request path, an interface belonging product, an interface request parameter, and an interface request response; generating a test case for the interface according to the mapping set. The embodiment of the present application avoids inaccurate interface test cases caused by untimely maintenance of interface definition files, and automatically generates a full amount of test cases through interface call logs and interface definition files, thereby improving the efficiency of test case writing.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of electronic information technology, and in particular to an interface test case generation method, an electronic device, and a storage medium. Background Art

[0002] With the rapid development of cloud computing, more and more cloud products have emerged, bringing more and more application value to customers. As cloud products are rapidly produced and iterated, the pressure on cloud product quality assurance is also increasing. How to use automation to improve the efficiency and stability of cloud product quality assurance has become particularly urgent. Summary of the invention

[0003] In view of this, an embodiment of the present application provides an interface test case generation method, an electronic device and a storage medium to at least partially solve the above-mentioned problems.

[0004] According to the first aspect of an embodiment of the present application, a method for generating an interface test case is provided, the method comprising: obtaining an interface call log and an interface definition file; performing data conversion on the interface call log and the interface definition file according to preset data conversion rules to obtain a mapping set of interfaces and interface information, wherein the interface information comprises at least one of an interface name definition, an interface request method, an interface request path, an interface belonging product, an interface request parameter, and an interface request response; and generating a test case for the interface according to the mapping set.

[0005] In a possible implementation, the interface request parameter includes: at least one of a parameter name definition, a parameter type, whether the parameter is required, a parameter initial value, and a parameter fillable option of at least one parameter.

[0006] In one possible implementation, determining whether the parameter is required includes: obtaining interface call logs of the interface in multiple environments within a preset time period; performing set processing of union and intersection on the parameters of the interface in the interface call logs; if the parameter of the interface appears in the intersection, determining that the parameter is a required parameter; if the parameter of the interface appears in the union, determining that the parameter is an optional parameter.

[0007] In a possible implementation, the interface test case generation method further includes: if the interface call log is not obtained and only the interface definition file is obtained, determining that the parameters of the interface are optional parameters.

[0008] In a possible implementation, the interface test case generation method further includes: if the parameter value of the same interface parameter in the interface call log has limited values, marking the parameter value of the parameter as limited in the parameter fillable option of the parameter.

[0009] In a possible implementation, generating a test case for the interface according to the mapping set includes: traversing the mapping set to generate a request entity class, a response entity class and at least one test case data corresponding to the interface, wherein the request entity class and the response entity class are used for scenario-based test case calls; mapping each of the test case data to the request entity class respectively to obtain an initial test case corresponding to each test case data; and updating the initial test case according to the interface request parameters to generate a test case for the interface.

[0010] In one possible implementation, traversing the mapping set to generate at least one test case data for the interface includes: generating mandatory test case data including each mandatory parameter according to the interface request parameters, and generating full test case data including each optional parameter.

[0011] In one possible implementation, traversing the mapping set to generate at least one test case data for the interface includes: combining some parameters of the interface according to the data processing logic represented by some parameters in the interface to generate multiple groups of test case data representing different data processing scenarios.

[0012] In a possible implementation, the test case data is managed via a yaml file.

[0013] In a possible implementation, updating the initial test case according to the interface request parameters to generate a test case for the interface includes: replacing parameters of the initial test case through a parameter responsibility chain to generate the test case.

[0014] In a possible implementation, the interface test case generation method further includes: according to the mapping relationship between the interface and the role, and the operation authority of the role corresponding to the interface on the interface, using corresponding verification logic to run multiple test cases of the interface.

[0015] In a possible implementation, the interface test case generation method further includes: executing multiple test cases of the interface according to the interface calling form.

[0016] According to the second aspect of an embodiment of the present application, there is provided an electronic device comprising: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, and the executable instruction enables the processor to perform operations corresponding to the interface test case generation method of the first aspect.

[0017] According to a third aspect of an embodiment of the present application, a storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the interface test case generation method of the first aspect is implemented.

[0018] According to a fourth aspect of an embodiment of the present application, a computer program product is provided. When the computer program product is executed by a processor, the interface test case generation method of the first aspect is implemented.

[0019] The interface test case generation scheme provided by the embodiment of the present application performs data conversion according to preset data conversion rules through the interface call log and the interface definition file, obtains a mapping set of interfaces and interface information, and then generates a test case for the interface according to the mapping set. The embodiment of the present application avoids the inaccuracy of interface test cases caused by untimely maintenance of interface definition files, and automatically generates a full amount of test cases through interface call logs and interface definition files, thereby improving the efficiency of test case writing. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of the present application. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0021] Figure 1 A schematic diagram of a scenario in which an interface test case generation method provided in an embodiment of the present application is applied;

[0022] Figure 2 A flowchart of a method for generating an interface test case provided in an embodiment of the present application;

[0023] Figure 3 An interface schematic diagram of an interface test case generation method provided in an embodiment of the present application;

[0024] Figure 4 A data conversion flow chart of a test case generation method provided in an embodiment of the present application;

[0025] Figure 5 A flowchart of step 203 of a method for generating an interface test case provided in an embodiment of the present application;

[0026] Figure 6 A flowchart of step 203 of another method for generating an interface test case provided in an embodiment of the present application;

[0027] Figure 7 A flowchart of step 203 of another interface test case generation method provided in an embodiment of the present application;

[0028] Figure 8 A flowchart of step 203 of another interface test case generation method provided in an embodiment of the present application;

[0029] Fig. 9 A flowchart of step 203 of another interface test case generation method provided in an embodiment of the present application;

[0030] Fig.10 A flowchart of step 203 of another interface test case generation method provided in an embodiment of the present application;

[0031] Fig.11 A flowchart of another method for generating interface test cases provided in an embodiment of the present application;

[0032] Fig.12 A schematic diagram of the structure of an interface test case generation device provided in an embodiment of the present application;

[0033] Fig.13 A structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0034] In order to enable those skilled in the art to better understand the technical solutions in the embodiments of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments in the embodiments of the present application should fall within the scope of protection of the embodiments of the present application.

[0035] A common method for generating an interface automation framework is for testers to generate interface test data based on the field types in the interface definition file, and use fixed templates to generate test cases. However, if the interface definition file is not maintained in a timely manner, the generated test cases will be inaccurate. This method only considers the generation of full interface test cases, and cannot provide automatically generated test cases for incremental interfaces. In addition, the use of fixed templates to generate test cases is inconvenient for later expansion. For custom types of interfaces using Java, the generated test case code is prone to errors. And this method does not extract the interface capabilities for scenario-based test case writing. This method is suitable for read interfaces or single product services. For read and write interfaces involving multiple systems and services, since only interface definition files are used to generate test cases, and real data is not used, the generated automated test cases are less effective.

[0036] The interface test case generation scheme provided by the embodiment of the present application performs data conversion according to preset data conversion rules through the interface call log and the interface definition file, obtains a mapping set of each interface and interface information, and then generates a test case for the interface according to the mapping set. The embodiment of the present application avoids the inaccuracy of the interface test case caused by the untimely maintenance of the interface definition file, and automatically generates a full amount of test cases through the interface call log and the interface definition file, thereby improving the efficiency of test case writing.

[0037] It should be noted that in the interface test case generation scheme provided in the embodiment of the present application, the interface refers to an application programming interface (Application Programming Interface, API), which is used to implement the interaction between different parts of a software program. In the embodiment of the present application, a test case is a set of test case data, execution conditions, and expected response results compiled for a specific interface, which is used to verify a specific function of the interface.

[0038] The specific implementation of the embodiment of the present application is further explained below in conjunction with the accompanying drawings of the embodiment of the present application.

[0039] The present application embodiment provides an interface test case generation method, which is applied to an electronic device. For ease of understanding, the application scenario of the interface test case generation method provided in the first embodiment of the present application is described. Figure 1 As shown, Figure 1 A scenario diagram of an interface test case generation method provided in an embodiment of the present application, wherein the interface test case generation method is applied to an electronic device 101, and the electronic device 101 may be a device for executing the interface test case generation method provided in an embodiment of the present application.

[0040] The electronic device 101 may be a terminal device such as a smart phone, a tablet computer, a laptop computer, a vehicle-mounted terminal, etc. The electronic device 101 may also be a network device such as a server. Of course, this is only an exemplary description and does not mean that the present application is limited to this.

[0041] The electronic device 101 can access the network, connect to the cloud through the network, and interact with data, or the electronic device 101 can be a device in the cloud. In the present application, the network includes a local area network (English: Local Area Network, LAN), a wide area network (English: Wide Area Network, WAN), and a mobile communication network; such as the World Wide Web (English: World Wide Web, WWW), a long-term evolution (English: Long Term Evolution, LTE) network, a 2G network (English: 2th Generation Mobile Network), a 3G network (English: 3th Generation Mobile Network), a 5G network (English: 5th Generation Mobile Network), etc. The cloud can include various devices connected through the network, for example, servers, relay devices, end-to-end (English: Device-to-Device, D2D) devices, etc. Of course, this is only an exemplary description and does not mean that the present application is limited to this.

[0042] Combination Figure 1 The system shown in the figure details the interface test case generation method provided by the embodiment of the present application. It should be noted that: Figure 1 This is just one application scenario of the interface test case generation method provided in the embodiment of the present application, and does not mean that the interface test case generation method must be applied to Figure 1 The application scenario shown.

[0043] Reference Figure 2 , an interface test case generation method provided by an embodiment of the present application includes:

[0044] Step 201: Obtain interface call log and interface definition file.

[0045] Specifically, the interface call log is real data generated during the operation of the interface, which can be obtained through the user historical behavior database and traffic packet capture.

[0046] In the embodiment of the present application, even if the interface has not been called and therefore there is no interface call log, the interface definition file can be obtained.

[0047] Step 202: Perform data conversion on the interface call log and the interface definition file according to a preset data conversion rule to obtain a mapping set of interfaces and interface information.

[0048] The embodiment of the present application uses interfaces as units, parses interface call logs and interface definition files according to preset data conversion rules, and stores the interfaces and interface information in correspondence as a mapping set.

[0049] In some specific implementations of the embodiments of this application, see Figure 3 ,The interface information includes: interface name definition, interface request method, interface request path, interface belonging product, interface request parameters, and interface request response.

[0050] The interface request parameters include: at least one of the parameter name definition, parameter type, whether the parameter is required, parameter initial value, and parameter fillable options of at least one parameter.

[0051] In some specific implementations of the embodiments of the present application, the preset data conversion rules are set as needed. To further illustrate the preset data conversion rules, specific examples are listed below for illustration.

[0052] See also Figure 4 , whether a parameter is required includes:

[0053] Step 401: Obtain interface call logs of interfaces in multiple environments within a preset time period.

[0054] Specifically, the preset time period is set according to needs, and the multiple environments refer to multiple different operating environments in which the interface is called.

[0055] The service to be tested is deployed on a private cloud environment, and each private cloud environment is an isolated environment. For scenarios where private clouds are used in factories (i.e., TOB scenarios), during testing and acceptance, one or more private cloud test environments are provided for testing and acceptance. After delivery to customers, a private cloud environment will be deployed for each customer, and customers can use cloud services in this environment. In order to obtain more and more detailed call data for the test interface, the data of the interfaces on each set of private cloud environments of the same version are collected and gathered together for analysis and processing. Therefore, there will be many environments for service deployment. For consumer-oriented scenarios such as public clouds or self-built computer rooms (i.e., TOC scenarios), multiple environments can refer to test environments and production environments.

[0056] Step 402: Perform union and intersection set processing on the parameters of the interface in the interface call log.

[0057] Exemplarily, each request log parameter of the same interface is recorded as a set Pk = (Pk1, Pk2, Pk3...) k <= n, where Pk represents the set of n parameters of the interface, Pk1, Pk2, Pk3... respectively represent n parameters of the interface, and k and n are positive integers. Intersection = P1∩P2...∩Pn, and union = P1∪P2...∪Pn.

[0058] Step 403: If the parameter of the interface appears in the intersection, the parameter is determined to be a required parameter.

[0059] Step 404: If the parameter of the interface appears in the union, the parameter is determined to be an optional parameter.

[0060] In the preset data conversion rules in the embodiment of the present application, the parameter appearing in the intersection indicates that the parameter appears in multiple request logs and is set as a required parameter; the parameter appearing in the sum indicates that the parameter appears in one request log and is set as an optional parameter. Whether the parameter is a required parameter can be set according to the situation in which the parameter appears, so that the parameter can be managed and called more accurately.

[0061] Optionally, if the interface call log is not obtained and only the interface definition file is obtained, the parameters of the interface are determined to be optional parameters.

[0062] In the preset data conversion rules in the embodiment of the present application, no interface call log is obtained, only the interface definition file is obtained, indicating that the parameter did not appear in the previous request log. Setting the interface parameters as optional parameters can further manage and call the parameters more accurately.

[0063] If the parameter value of the same interface parameter in the interface call log is limited, the parameter value of the parameter is marked as limited in the parameter fillable option of the parameter.

[0064] The parameter value of the same interface parameter in the embodiment of the present application is limited, indicating that the parameter is a discrete random variable with a fixed value. In this case, the parameter value of the parameter is marked as limited in the fillable parameter option of the parameter for reference when generating multiple test cases so as to manage and call the parameters more accurately.

[0065] Step 203: Generate test cases for the interface according to the mapping set.

[0066] When generating test cases for an interface according to a mapping set, an automation framework base may be used to operate and process the mapping set to generate test cases for the interface.

[0067] Specifically, the automation framework base of the embodiment of the present application is generated using the JavaPoet framework. JavaPoet is an open source project for dynamically generating code, and the JavaPoet is a Java API for generating .java source files.

[0068] The automation framework base generates a public class (BaseTest), which integrates the Spring test framework and the testNG plug-in.

[0069] Therefore, the public class of the embodiment of the present application organically combines the Spring test framework with the testNG plug-in by inheriting AbstractTestNGSpringContextTests and referencing the SpringBootTest annotation. As the base of the entire automation framework, it not only has the container management and powerful integration capabilities of the Spring test framework, but also reuses the multi-threading, scenario-based and rich listener capabilities of the testNG plug-in.

[0070] In some specific implementations of the embodiments of this application, see Figure 5 , step 203, comprising:

[0071] Step 2031, traverse the mapping set, extract the basic capabilities of each interface, and generate the request entity class and response entity class corresponding to each interface.

[0072] Traverse the mapping set processed by the preset data conversion rule conversion service, and generate a request entity class assembled by all parameters and a corresponding response entity class for each interface. The request entity class and response entity class are the basic capabilities extracted from the interface, which can be called by other scenario-based test cases, and can quickly parse the interface response data, making the interface verification more accurate and convenient.

[0073] The request entity class is a call mapping of interfaces and parameters in Java. The test case data needs to be mapped to the request entity class to obtain the test case that can request the corresponding interface. The generated test case includes the code that can actually run. After the test case requests the interface to make the interface generate a response, the response maps the interface's response data to the response entity class to obtain the interface's response data to verify the legitimacy and accuracy of the interface.

[0074] After the request entity class and the response entity class are generated, the request entity class and the response entity class can be called by scenario test cases, which is convenient for scenario-based and service orchestration. In addition, an interface function component is generated based on the request entity class and the response entity class, which can facilitate the use of scenario-based and service orchestration.

[0075] Step 2032: traverse the mapping set to generate at least one test case data corresponding to each interface.

[0076] The mapping set records the mapping relationship between the interface and the interface information. The interface information includes the interface request parameters. The interface request parameters record whether the parameters are required, that is, whether each parameter is a required parameter or an optional parameter. For a certain interface, by traversing the mapping set, the full test case data and required test case data corresponding to the interface are obtained, wherein the full test case data includes the optional parameters corresponding to the interface, and the required test case data includes the required parameters corresponding to the interface.

[0077] It should be understood that when the full test case data is the same as the required test case data, at least one test case data is generated by traversing the mapping set. When the full test case data is different from the required test case data, at least two test case data are generated by traversing the mapping set.

[0078] Optionally, the generated test case data is managed using a yaml file so that the test case data can be run quickly. It is more convenient to use a yaml file to manage the test case data of a single interface and is easier to integrate with the Spring test framework.

[0079] In some specific implementations of the embodiments of this application, see Figure 6 , step 203, further comprising:

[0080] Step 2033: Generate a test case entry marked with test annotations for each interface.

[0081] For each interface, a test case entry with test annotations is generated for the interface, and the test case entry can load the test case data managed by the yaml file. Since a service may include multiple interfaces, a corresponding test case entry is generated for each interface, and each interface can be tested separately through the test case entry, which improves the convenience of interface testing.

[0082] In some specific implementations of the embodiments of this application, see Figure 7 , step 203, further comprising:

[0083] Step 2034: According to the data processing logic represented by some parameters in the interface, some parameters of the interface are combined to generate multiple groups of test case data representing different service scenarios.

[0084] Specifically, since some parameters of the interface represent different service logics, and these service logics can be combined to form different service scenarios, some parameters in the test case data can be combined according to the service logics they represent to generate multiple groups of test case data representing different service scenarios.

[0085] Based on the test case data managed by the yaml file, all the values ​​in each parameter are combined and the original test case data is replaced, thereby generating multiple groups of test case data representing different data processing scenarios for the interface.

[0086] Specifically, the initial test case data of the interface is P3=A, P4=B, where P4 can take three values: B, C, and D. After loading the test case data, all values ​​of P4 are taken out and combined with the P3 parameters by Cartesian product to form multiple test case data (test case data 1: P3=A, P4=B, test case data 2: P3=A, P4=C, test case data 3: P3=A, P4=D).

[0087] For example, test case data 1 is: name = (name), time = 1000, test case data 2 is: name = (name), time = 1000, version = 1.0, and the possible values ​​of the parameter version include 1.0 and 2.0. Three test case data can be obtained by combining the parameters, namely the above test case data 1, the above test case data 2 and the following test case data 3. Test case data 3 is: name = (name), time = 1000, version = 2.0.

[0088] The embodiment of the present application can combine some parameters of the interface according to the service logic of the service scenario to generate more test cases representing different service scenarios.

[0089] In some specific implementations of the embodiments of this application, see Figure 8 , step 203 further includes:

[0090] Step 2035: Map each test case data to the request entity class respectively to obtain the initial test case corresponding to each test case data.

[0091] For each interface, after generating the request entity class, response entity class and at least one test case data corresponding to the interface, each test case data is mapped to the request entity class to obtain an initial test case corresponding to the interface. Since an interface corresponds to at least one full test case data and one required test case data, when the full test case data is the same as the required test case data, at least one initial test case can be obtained after mapping the test case data to the request entity class. When the full test case data is different from the required test case data, at least two initial test cases can be obtained after mapping the test case data to the request entity class, one of which corresponds to the full test case data and the other corresponds to the required test case data.

[0092] In some specific implementations of the embodiments of this application, see Fig. 9 , step 203, further comprising:

[0093] Step 2036: Update the initial test case according to the interface request parameters to generate a test case for the interface.

[0094] When the initial test case is updated according to the interface request parameters, the test case parameters can be replaced through the parameter responsibility chain to regenerate the test case.

[0095] For example, for some writing interfaces, the required parameter values ​​are real in the system. However, the parameters in the test cases generated by the automated testing framework may become invalid, so it is necessary to use the parameter responsibility chain. If the parameters in the interface call log change during the process of processing various service logics, the parameters in the initial test case will be dynamically changed.

[0096] Specifically, if there are multiple parameters that need to be changed in the interface, search for the parameters that need to be changed in the parameter responsibility chain. If a service logic in the parameter responsibility chain hits the corresponding parameter, generate an available parameter value and replace the parameters that need to be changed in the initial test case with the parameters hit in the parameter responsibility chain; otherwise, continue to search in the subsequent service logic in the parameter responsibility chain. If all the parameters that need to be changed have been replaced, exit the search of the parameter responsibility chain.

[0097] Exemplarily, the initial test case of interface A is P1 (name=test, time=10000000000000), where the two parameter data of name and time can be universal, but the service logic needs to be generated in real time, so a specific variable (name) and (time) can be abstracted to update the initial test case P1 (name=(name), time=(time)).

[0098] Implement the corresponding Name processor and Time processor logic to process the parameters with values ​​of (name) and (time) respectively. When running test case P1, the parameters of the initial test case in the yaml file will be loaded, and the parameter responsibility chain service will be entered. The name and time parameter values ​​processed by the service logic of the Name processor and Time processor in the parameter responsibility chain will replace the (name) and (time) variable values ​​in the initial test case, so that the test case uses real system data to improve the simulation effect of the test case.

[0099] It should be noted that the above name and time are examples given to illustrate the test case generation process. The request entity class is a call mapping of the interface and parameters in Java. YAML is used to manage test data. The test data needs to be mapped to a specific Java class (i.e., the request entity class) before the actual code can be run. Finally, the interface response of the request also needs to be mapped to the response entity class to verify the legitimacy and accuracy of the interface return.

[0100] For example, if the test case of interface A is:

[0101] P=(name=(name), time=(time), version=1.0, field1=t), where there are four parameters: name, time, version and field1.

[0102] When the initial test case P is run, the initial test case P is loaded into the parameter responsibility chain service. According to the parameter responsibility chain, the variables (name) and variables (time) in the initial test case P are replaced to generate a new test case P1 to achieve the simulation of the real system data. The new test case P1 is:

[0103] P1=(name=autotest_newname1, time=1000000000001, version=1.0, field1=t).

[0104] In addition, if there are parameter changes in the new iteration log, code, or interface document, the base will sense the changes in the interface during the version iteration, and add parameters based on the initial test case to obtain a new test case.

[0105] For example, in the new interface call log, the parameters of interface A change as follows:

[0106] LogA(name=name1, time=10001, version=2.0, field2=r), where LogA represents the call log of interface A.

[0107] Specifically, according to the parameter responsibility chain, the variables (name) and (time) are replaced; the update service specifies version as the monitoring parameter, and the value of the version parameter has changed from 1.0 to 2.0; field1 does not appear in the new log, so the parameter field1 is deleted; field2 is a new parameter, so the variable value of field2 is added. Interface A generates a new test case as follows:

[0108] P2=(name=(name), time=(time), version=2.0, field2=r).

[0109] It should be noted that when an interface version is iterated, the request entity class, response entity class and test case data of the interface can be updated based on the new mapping set. When the request entity class and response entity class are fully updated, if the parameters have changed, the corresponding update is performed, and if the parameters have not changed, the update remains unchanged, so that the updated request entity class, response entity class and test case data are applicable to the new version of the interface, and other related data generated for the interface are used in the new version of the interface, thereby improving the speed and efficiency of interface testing.

[0110] In some specific implementations of the embodiments of this application, see Fig.10 , step 203, further comprising:

[0111] Step 2037: According to the mapping relationship between the interface and the role, the role's operation authority for the interface is obtained, and the verification logic corresponding to the operation authority is used to run multiple test cases of the interface.

[0112] Specifically, according to the service logic of the service scenario, the mapping relationship between the interface and the role is inherited. When the test case of the interface is run, it will determine whether the specified role has the permission to operate the interface based on the mapping relationship between the interface and the role; if it has permission, the permission verification logic will be performed, otherwise the non-permission verification logic will be performed.

[0113] For example, role A has the read interface permission for object a, but does not have the write interface permission for object a. When a user runs a read interface test case for object a as role A, normal service verification logic will be performed; when running a write interface test case for object a, service verification logic for interfaces that do not have access permissions will be performed.

[0114] The embodiment of the present application runs multiple test cases of the interface according to the roles, which is flexible to use and easy to expand.

[0115] In some specific implementations of the embodiments of this application, see Fig.11 , the method further comprising:

[0116] Step 204: According to the interface calling form, implement the running of multiple test cases of the interface.

[0117] Specifically, if the interface call form is an http interface, the interface execution logic of the http request is implemented; if the interface call form is an rpc interface, the interface execution logic of the rpc request is implemented.

[0118] The embodiment of the present application can run multiple test cases of the interface according to the calling form of the interface, making its use more flexible.

[0119] The embodiments of the present application avoid inaccurate interface test cases caused by untimely maintenance of interface definition files, and automatically generate a full set of test cases through interface call logs and / or interface definition files, thereby improving the efficiency of test case writing.

[0120] Corresponding to the above method embodiment, in order to further illustrate the implementation of the present application, the present application embodiment also provides an interface test case generation device. Fig.12 , the interface test case generating device comprises:

[0121] The log file obtaining module 121 is used to obtain the interface call log and the interface definition file.

[0122] The data conversion module 122 is used to perform data conversion on the interface call log and the interface definition file according to a preset data conversion rule to obtain a mapping set of interfaces and interface information.

[0123] The test case generation module 123 is used to generate test cases for the interface according to the mapping set.

[0124] Specifically, when the test case generation module 123 in the embodiment of the present application generates a test case, the test case can be generated by an automated framework base, which is generated using a javapoet framework. Javapoet is an open source project for dynamically generating code, and the javapoet is a java API for generating .java source files.

[0125] The automation framework base generates a public class (BaseTest), which integrates the Spring test framework and the testNG plug-in.

[0126] Therefore, the public class of the embodiment of the present application organically combines the Spring test framework with the testNG plug-in by inheriting AbstractTestNGSpringContextTests and referencing the SpringBootTest annotation. As the base of the entire automation framework, it not only has the container management and powerful integration capabilities of the Spring test framework, but also reuses the multi-threading, scenario-based and rich listener capabilities of the testNG plug-in.

[0127] In the specific implementation of the embodiment of the present application, the test case generation module 123 includes:

[0128] The basic assembly unit 1231 is used to traverse the mapping set using the automation framework base, extract the basic capabilities of each interface, and generate a request entity class and a corresponding response entity class for assembling all parameters.

[0129] The scenario reuse unit 1232 is used to request that the entity class and the response entity class can be reused for scenario-based test case calls.

[0130] The file management unit 1233 is used to manage multiple test cases automatically generated for each interface using a yaml file.

[0131] The use case generation unit 1234 is used to generate a test case entry marked with test annotations for each interface, and the yaml file loads the parameters of the initial test case through the test case entry.

[0132] The parameter processing module 1235 is used to replace parameters of multiple test cases generated by the yaml file according to the parameter responsibility chain.

[0133] The permission obtaining unit 1236 is used to obtain the operation permission of the role on the interface according to the mapping relationship between the interface and the role.

[0134] The authority determination unit 1237 is used to determine whether the specified role has the authority to operate the interface.

[0135] The first verification unit 1238 is used to perform authorization verification logic when authorization is granted.

[0136] The second verification unit 1239 is used to perform unauthorized verification logic when there is no authority.

[0137] The embodiments of the present application avoid inaccurate interface test cases caused by untimely maintenance of interface definition files, and automatically generate a full set of test cases through interface call logs and / or interface definition files, thereby improving the efficiency of test case writing.

[0138] Based on the method described in the above embodiment, the present application embodiment provides an electronic device for executing the method described in the above embodiment, referring to Fig.13 , shows a schematic diagram of the structure of an electronic device according to an embodiment of the present application. The specific embodiment of the present application does not limit the specific implementation of the electronic device.

[0139] like Fig.13 As shown, the electronic device 130 may include: a processor (processor) 1302 , a communication interface (Communications Interface) 1304 , a memory (memory) 1306 , and a communication bus 1308 .

[0140] in:

[0141] The processor 1302 , the communication interface 1304 , and the memory 1306 communicate with each other via a communication bus 1308 .

[0142] The communication interface 1304 is used to communicate with other electronic devices or servers.

[0143] The processor 1302 is used to execute the program 1310, and specifically can execute the relevant steps in the above-mentioned interface test case generation method embodiment.

[0144] Specifically, the program 1310 may include program codes, which include computer operation instructions.

[0145] The processor 1302 may be a processor CPU, or an application specific integrated circuit ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of the present application. The one or more processors included in the smart device may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0146] The memory 1306 is used to store the program 1310. The memory 1306 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0147] Program 1310 can be specifically used to enable processor 1302 to execute to implement the interface test case generation method described in Example 1. The specific implementation of each step in program 1310 can refer to the corresponding descriptions in the corresponding steps and units in the above-mentioned interface test case generation method embodiment, which will not be repeated here. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working process of the above-described devices and modules can refer to the corresponding process description in the above-mentioned method embodiment, which will not be repeated here.

[0148] Based on the method described in the above embodiments, an embodiment of the present application provides a computer storage medium on which a computer program is stored. When the program is executed by a processor, the method described in Embodiment 1 is implemented.

[0149] Based on the method described in the above embodiments, an embodiment of the present application provides a computer program product, which implements the method described in Embodiment 1 when executed by a processor.

[0150] It should be pointed out that, according to the needs of implementation, the various components / steps described in the embodiments of the present application can be split into more components / steps, or two or more components / steps or partial operations of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of the present application.

[0151] The above-mentioned method according to the embodiment of the present application can be implemented in hardware, firmware, or implemented as software or computer code that can be stored in a recording medium (such as a CD ROM, RAM, floppy disk, hard disk or magneto-optical disk), or implemented as a computer code originally stored in a remote recording medium or a non-temporary machine-readable medium downloaded through a network and to be stored in a local recording medium, so that the method described herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor or programmable or dedicated hardware (such as an ASIC or FPGA). It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code, and when the software or computer code is accessed and executed by a computer, a processor or hardware, the navigation method described herein is implemented. In addition, when a general-purpose computer accesses the code for implementing the navigation method shown herein, the execution of the code converts the general-purpose computer into a dedicated computer for executing the navigation method shown herein.

[0152] Those of ordinary skill in the art will appreciate that the units and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of the present application.

[0153] The above implementation methods are only used to illustrate the embodiments of the present application, and are not limitations on the embodiments of the present application. Ordinary technicians in the relevant technical field can make various changes and modifications without departing from the spirit and scope of the embodiments of the present application. Therefore, all equivalent technical solutions also belong to the scope of the embodiments of the present application. The scope of patent protection of the embodiments of the present application should be limited by the claims.

Claims

1. A method for generating an interface test case, the method comprising: Obtain interface call logs and interface definition files; The interface call log and the interface definition file are data converted according to a preset data conversion rule to obtain a mapping set of interfaces and interface information, wherein the interface information includes at least one of an interface name definition, an interface request method, an interface request path, an interface attribute product, an interface request parameter, and an interface request response; the interface request parameter includes at least one of a parameter name definition, a parameter type, whether the parameter is required, a parameter initial value, and a parameter fillable option of at least one parameter; Generate a test case for the interface according to the mapping set; The determination of whether the parameter is required includes: Obtaining interface call logs of the interface in multiple environments within a preset time period; Performing set processing of union and intersection on the parameters of the interface in the interface call log; If a parameter of the interface appears in the intersection, the parameter is determined to be a required parameter; If a parameter of the interface appears in the union, the parameter is determined to be an optional parameter.

2. The method according to claim 1, wherein: The method further comprises: If the interface call log is not obtained and only the interface definition file is obtained, it is determined that the parameters of the interface are optional parameters.

3. The method according to claim 2, wherein: Generating a test case for the interface according to the mapping set includes: Traversing the mapping set, generating a request entity class, a response entity class and at least one test case data corresponding to the interface, wherein the request entity class and the response entity class are used for being called by the scenario test case; Mapping each of the test case data to the request entity class respectively to obtain an initial test case corresponding to each of the test case data; The initial test case is updated according to the interface request parameters to generate a test case for the interface.

4. The method according to claim 3, wherein: The traversing the mapping set to generate at least one test case data of the interface includes: According to the interface request parameters, mandatory test case data including each mandatory parameter is generated, and full test case data including each optional parameter is generated.

5. The method according to claim 3, wherein: The traversing the mapping set to generate at least one test case data of the interface includes: According to the data processing logic represented by some parameters in the interface, some parameters of the interface are combined to generate multiple groups of test case data representing different data processing scenarios.

6. The method according to any one of claims 3 to 5, wherein: The updating of the initial test case according to the interface request parameter to generate a test case for the interface includes: The initial test case is parameter-replaced through a parameter responsibility chain to generate the test case.

7. An electronic device comprising: A processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other via the communication bus; The memory is used to store at least one executable instruction, and the executable instruction enables the processor to perform an operation corresponding to the method according to any one of claims 1 to 6.

8. A storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

9. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images