Interface Testing Method, Device, Computing Device, and Computer Storage Medium

Abstract

Embodiments of the present invention disclose an interface testing method, apparatus, computing device, and computer storage medium. The method includes: when a test case of a target interface is executed, obtaining a default request of the target interface pre-generated, where the default request contains all request parameters required by the target interface and first parameter values of each request parameter; parsing a test case document of the target interface to determine whether there are business parameters in the currently executed test case in the test case document; if so, using second parameter values of the business parameters in the currently executed test case to replace the first parameter values of the corresponding business parameters in the default request to generate an updated request, and performing interface testing using the updated request; if not, performing interface testing using the default request. With this solution, when the test case is executed, it is no longer necessary to splice all request parameters, thereby improving the testing efficiency; and significantly streamlining the test case, reducing the maintenance difficulty of the test case and the maintenance cost.

Description

Technical Field

[0001] Embodiments of the present invention relate to the technical field of automated testing, and particularly to an interface testing method, apparatus, computing device, and computer storage medium. Background Art

[0002] With the continuous development of technology and society, the emergence of various Internet products has greatly enriched people's work and life. In order to enable Internet products to better serve users, it is usually necessary to test the Internet products before they are launched or before a certain function of the Internet products is launched, so as to timely discover the loopholes in the Internet products.

[0003] Interface testing is an important part of Internet product testing, which can test loopholes in data exchange, transmission, management, control, and logical relationships. The currently adopted interface testing method is: writing all request parameters and corresponding parameter values in the test case. When the test case is executed, each request parameter is extracted from the test case and concatenated to generate an interface request, and then the interface test is performed based on the interface request.

[0004] However, the inventor found in the implementation process that there are the following defects in the prior art: when using the existing interface testing method, when the request parameter structure is complex and / or the number of request parameters is large, concatenating the request parameters will consume a lot of time, resulting in low interface testing efficiency; moreover, the test case contains a large number of request parameters, making the maintenance of the test case difficult and the dimension cost high. Summary of the Invention

[0005] In view of the technical problems of low interface testing efficiency, difficult maintenance of test cases, and high dimension cost in the prior art, embodiments of the present invention are proposed to provide an interface testing method, apparatus, computing device, and computer storage medium that overcome the above problems or at least partially solve the above problems.

[0006] According to a first aspect of embodiments of the present invention, an interface testing method is provided, including:

[0007] When any test case of the target interface is executed, obtain the default request of the target interface pre-generated; wherein, all request parameters required by the target interface and the first parameter value of each request parameter are included in the default request; the request parameters include service parameters;

[0008] Parse the test case document of the target interface, and determine whether there are service parameters in the currently executed test case in the test case document;

[0009] If so, use the second parameter value of the service parameter in the currently executed test case to replace the first parameter value of the corresponding service parameter in the default request to generate an updated request, and use the updated request to perform an interface test; wherein, the second parameter value of the same service parameter is different from the first parameter value.

[0010] If not, use the default request to perform an interface test.

[0011] In an alternative embodiment, before parsing the test case document of the target interface, the method further includes:

[0012] Obtain the written candidate test cases.

[0013] Extract the parameter values of each service parameter in the candidate test cases.

[0014] Compare the parameter values of each service parameter in the candidate test cases with the first parameter values of each service parameter in the default request to identify the target service parameter; the parameter value of the target service parameter in the candidate test case is the same as the first parameter value in the default request.

[0015] Delete the target service parameter and its parameter value in the candidate test case to generate a test case, and load the generated test case into the test case document.

[0016] In an alternative embodiment, the test case document contains multi-scenario test cases.

[0017] Among them, the multi-scenario test case contains n test steps; the first n - 1 test steps are test steps common to multiple test scenarios, and the nth test step contains service parameters in each test scenario.

[0018] In an alternative embodiment, before parsing the test case document of the target interface, the method further includes:

[0019] Obtain the written candidate test cases.

[0020] Extract multiple candidate test cases with the same first n - 1 test steps from the written candidate test cases.

[0021] Record the first n - 1 test steps of the multiple candidate test cases, and record the service parameters in the multiple candidate test cases in the nth test step to generate the multi-scenario test cases of the multiple candidate test cases, and load the generated multi-scenario test cases into the test case document.

[0022] In an alternative embodiment, after performing the interface test using the update request, or after performing the interface test using the default request, the method further includes:

[0023] Generating an interface request log for the test case that has undergone the interface test; the interface request log contains the interface request information when the test case performs the interface test.

[0024] In an alternative embodiment, the method further includes:

[0025] Comparing the interface request log of any test case that has undergone the interface test with the test case in the test case document and / or the default request for information to determine whether there is an interface request anomaly in the test case.

[0026] In an alternative embodiment, the request parameters further include at least one of the following non-business parameters: URL, request header, and request method.

[0027] According to the second aspect of the embodiments of the present invention, there is provided an interface test device, including:

[0028] An acquisition module, configured to acquire the default request of the target interface pre-generated when any test case of the target interface is executed; wherein, the default request contains all the request parameters required by the target interface and the first parameter values of each request parameter; the request parameters include business parameters.

[0029] A parsing module, configured to parse the test case document of the target interface.

[0030] A judgment module, configured to judge whether there are business parameters in the currently executed test case in the test case document.

[0031] A request module, configured to, if the judgment result of the judgment module is yes, replace the first parameter value of the corresponding business parameter in the default request with the second parameter value of the business parameter in the currently executed test case to generate an update request, and perform an interface test using the update request; wherein, the second parameter value of the same business parameter is different from the first parameter value; if the judgment result of the judgment module is no, perform an interface test using the default request.

[0032] In an alternative embodiment, the device further includes: a use case generation module, configured to acquire the written candidate test cases.

[0033] Extracting the parameter values of each business parameter in the candidate test cases.

[0034] Compare the parameter values of each service parameter in the candidate test case with the first parameter values of each service parameter in the default request to identify the target service parameter; the parameter value of the target service parameter in the candidate test case is the same as the first parameter value in the default request.

[0035] Delete the target service parameter and its parameter value in the candidate test case to generate a test case, and load the generated test case into the test case document.

[0036] In an alternative embodiment, the test case document includes multi-scenario test cases.

[0037] Among them, the multi-scenario test case includes n test steps; the first n - 1 test steps are test steps common to multiple test scenarios, and the nth test step includes service parameters under each test scenario.

[0038] In an alternative embodiment, the device further includes: a use case generation module for obtaining the written candidate test cases.

[0039] Extract multiple candidate test cases with the same first n - 1 test steps from the written candidate test cases.

[0040] Record the first n - 1 test steps of the multiple candidate test cases, and record the service parameters in the multiple candidate test cases in the nth test step to generate the multi-scenario test cases of the multiple candidate test cases, and load the generated multi-scenario test cases into the test case document.

[0041] In an alternative embodiment, the device further includes: a log module for generating an interface request log of the test cases that have undergone interface testing; the interface request log includes the interface request information when the test cases perform interface testing.

[0042] In an alternative embodiment, the device further includes: a log verification module for comparing the interface request log of any test case that has undergone interface testing with the test case document of the test case and / or the default request to determine whether there is an interface request anomaly in the test case.

[0043] In an alternative embodiment, the request parameters further include at least one of the following non-service parameters: URL, request header, and request method.

[0044] According to a third aspect of an embodiment of the present invention, a computing device is provided, including: a processor, a memory, a communication interface, and a communication bus, and the processor, the memory, and the communication interface complete communication with each other through the communication bus;

[0045] The memory is used to store at least one executable instruction, and the executable instruction causes the processor to perform operations corresponding to the above interface test method.

[0046] According to a fourth aspect of an embodiment of the present invention, a computer storage medium is provided, and at least one executable instruction is stored in the storage medium, and the executable instruction causes the processor to perform operations corresponding to the above interface test method.

[0047] The embodiment of the present invention pre-generates a default request for a target interface, and all request parameters required by the target interface are spliced in the default request. Thus, subsequently, only the parameter values of the service parameters in the default request need to be updated based on the test cases in the test case document to generate an interface request. Therefore, when the test case is executed, it is not necessary to splice all request parameters again, thereby improving the test efficiency; moreover, only the parameter values of the service parameters that are updated compared with the service parameters in the default request need to be recorded in the test cases of the test case document, thereby greatly streamlining the test cases, reducing the maintenance difficulty of the test cases, and reducing the maintenance cost.

[0048] After obtaining the written candidate test cases, the embodiment of the present invention does not directly use the candidate test cases as the test cases in the final test case document, but verifies the candidate test cases to eliminate the target service parameters in the candidate test cases that are consistent with the parameter values of the default request, thereby further streamlining the test cases in the test case document. Moreover, on the one hand, it is convenient for maintaining the test cases, and on the other hand, it can avoid updating the service parameters that are consistent with the parameter values in the default request subsequently, thereby saving system resources and improving the test efficiency.

[0049] The embodiment of the present invention can merge multiple candidate test cases into multi-scenario test cases, thereby reducing the number of test cases and reducing the maintenance difficulty and maintenance cost of the test cases.

[0050] The embodiment of the present invention generates an interface request log of the test cases that have undergone interface testing. The interface request log contains interface request information when the test cases perform interface testing, and compares the interface request log of any test case that has undergone interface testing with the test case and / or the default request in the test case document to determine whether there is an interface request anomaly in the test case, thereby facilitating fault tracing by maintenance personnel.

[0051] In the embodiments of the present invention, non-business parameters and business parameters of a target interface are spliced to generate a default request for the target interface, and only the parameter values of the business parameters different from those in the default request are recorded in the test case. Thus, when non-business parameters such as the URL and / or request method of the target interface change, only the non-business parameters in the default request need to be adjusted, and there is no need to modify the test case, thereby improving the scalability of this test method.

[0052] The above description is only an overview of the technical solutions of the embodiments of the present invention. In order to be able to understand the technical means of the embodiments of the present invention more clearly, it can be implemented according to the content of the description. And in order to make the above and other purposes, features and advantages of the embodiments of the present invention more obvious and understandable, the following specifically describes the specific embodiments of the present invention. Description of the Drawings

[0053] By reading the following detailed description of the preferred embodiments, various other advantages and benefits will become clear to those of ordinary skill in the art. The drawings are only for the purpose of showing the preferred embodiments and are not considered to be a limitation of the embodiments of the present invention. And throughout the drawings, the same reference numerals are used to represent the same components. In the drawings:

[0054] Figure 1 A flowchart showing a method for testing an interface provided by an embodiment of the present invention is shown;

[0055] Figure 2 A flowchart showing another method for testing an interface provided by an embodiment of the present invention is shown;

[0056] Figure 3 A flowchart showing still another method for testing an interface provided by an embodiment of the present invention is shown;

[0057] Figure 4 A flowchart showing a method for generating a test case for interface testing provided by an embodiment of the present invention is shown;

[0058] Figure 5 A flowchart showing another method for generating a test case for interface testing provided by an embodiment of the present invention is shown;

[0059] Figure 6 A structural diagram showing an interface testing device provided by an embodiment of the present invention is shown;

[0060] Figure 7 A structural diagram showing a computing device provided by an embodiment of the present invention is shown. Detailed Embodiments

[0061] Exemplary embodiments of the embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the embodiments of the present invention are shown in the drawings, it should be understood that the embodiments of the present invention can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided so that the present invention can be more thoroughly understood and the scope of the present invention can be completely conveyed to those skilled in the art.

[0062] Figure 1 The flowchart of an interface test method provided by an embodiment of the present invention is shown. As Figure 1 shown, the method includes the following steps:

[0063] Step S110, when any test case of the target interface is executed, obtain the default request of the target interface pre-generated; wherein, the default request contains all request parameters required by the target interface and the first parameter value of each request parameter, and the request parameter includes service parameters.

[0064] The currently tested interface is the target interface. Different from the prior art, in the embodiment of the present invention, the default request of the target interface is pre-generated before testing the target interface. Specifically, according to the request parameter splicing structure and request parameter requirements of the target interface, etc., all request parameters required by the target interface are spliced, and the parameter values of each request parameter are configured. Among them, the parameter value of the request parameter in the default request is the first parameter value of the request parameter, and this first parameter value can also be called the default value.

[0065] The request parameter specifically includes service parameters, which refer to the parameters associated with the service during the test, such as the number of query data, the start time point, etc.

[0066] Step S120, parse the test case document of the target interface, and determine whether there are service parameters in the currently executed test case of the test case document; if so, execute step S130; if not, execute step S140.

[0067] The test case document of the target interface stores at least one test case of the target interface. The test case can only record the service parameters different from the first parameter value of the service parameters in the default request, and the parameter values of the different service parameters. The parameter value of the service parameter in the test case of the test case document is the second parameter value, so that the second parameter value of the same service parameter is different from the first parameter value. In addition, the embodiment of the present invention does not limit the specific type of the test case document. For example, the test case document can be a table document, or a YAML document, etc.

[0068] In the embodiment of the present invention, when a test case is executed, the test case document of the target interface is parsed, and business parameters are searched for in the currently executed test case of the test case document. If business parameters can be found in the currently executed test case of the test case document, it indicates that there are differences in business parameters between the real interface request corresponding to the currently executed test case and the default request, and then the subsequent step S130 is executed; if business parameters cannot be found in the currently executed test case of the test case document, it indicates that the real interface request corresponding to the currently executed test case is consistent with the default request, and then the subsequent step S140 is executed.

[0069] In an optional implementation manner, to facilitate quickly determining whether there are business parameters in the currently executed test case of the test case document, when generating the test case, the business parameters existing in the test case need to be configured under the preset parameters of the test case, where the preset parameters can be params, etc. Therefore, when making this judgment in this step, specifically, it is to determine whether there are business parameters under the preset parameters of the currently executed test case in the test case document.

[0070] Step S130: Use the second parameter value of the business parameter in the currently executed test case to replace the first parameter value of the corresponding business parameter in the default request to generate an updated request, and use the updated request to perform interface testing.

[0071] If there are business parameters in the currently executed test case of the test case document, it indicates that the parameter value of this business parameter in the default request needs to be updated. Therefore, the second parameter value of the business parameter in the currently executed test case is used to replace the first parameter value of the corresponding business parameter in the default request. For example, if there are business parameters P1 and P2 in the currently executed test case, the second parameter value of P1 is 10, the second parameter value of P2 is 20, the first parameter value of business parameter P1 in the default request is 20, the first parameter value of P2 is 30, and the first parameter value of business parameter P3 is 40, then the business parameter P1 in the default request is changed from 20 to 10, the business parameter P2 is changed from 30 to 20, and the business parameter P3 remains unchanged.

[0072] The request generated after replacing the parameter values of the default request is the updated request, and this updated request is the real interface request of the currently executed test case. Therefore, finally, the updated request is used to perform interface testing.

[0073] Step S140: Use the default request to perform interface testing.

[0074] If there are no business parameters in the currently executed test case of the test case document, it indicates that there is no need to update the parameter values of the business parameters in the default request, and then the default request is directly used to perform interface testing.

[0075] It can be seen that in the embodiment of the present invention, a default request for the target interface is pre-generated, and all request parameters required by the target interface are concatenated in the default request. Subsequently, only the parameter values of the service parameters in the default request need to be updated based on the test cases in the test case document to generate an interface request. Therefore, when the test cases are executed, it is not necessary to concatenate all request parameters, thereby improving the test efficiency; moreover, only the parameter values of the service parameters that are updated compared to the service parameters in the default request need to be recorded in the test cases of the test case document, thereby greatly streamlining the test cases, reducing the maintenance difficulty of the test cases and reducing the maintenance cost.

[0076] Figure 2 FIG. shows a schematic flow chart of another interface testing method provided by the embodiment of the present invention. As Figure 2 shown, the method includes the following steps:

[0077] Step S210, concatenate the non-service parameters and service parameters of the target interface to generate a default request for the target interface.

[0078] All request parameters required by the target interface are concatenated in the default request. Among them, the request parameters include non-service parameters unrelated to the service and service parameters related to the service, etc.

[0079] Among them, the non-service parameters include at least one of the following parameters: URL, request header, and request method. Among them, the URL is the resource path of the target interface, the request header contains information such as Cookie, Referer, Host, etc., and the request method can be GET or POST, etc. Each non-service parameter is concatenated in the corresponding format. It can be seen from this that the non-service parameters in the default request are determined based on the attributes of the interface (such as URL and request method, etc.). Therefore, when the interface remains unchanged, its non-service parameters are relatively fixed, and subsequently, when the test cases are executed, the non-service parameters will not be modified based on the test case document.

[0080] The service parameters can specifically be any parameters related to the service. The parameter values of the service parameters are related to the actual service scenario. Therefore, the parameter values of the service parameters are not fixed, and there are differences in the parameter values of the service parameters corresponding to each test case. In an optional embodiment, in order to reduce the number of subsequent modifications to the default request and streamline the test cases, the embodiment of the present invention can determine the first parameter value of the service parameter in the default request based on historical service test data. For example, the mode of the parameter values corresponding to each service parameter within a preset time period can be obtained and used as the first parameter value of the service parameter in the default request.

[0081] In an alternative embodiment, the generation of the default request can be completed during the interface definition process. Specifically, each interface can be named after the request method and URL of the interface. For example, if the interface URL is " / launch / cpc / campaign / detail" and the request method is "GET", then the interface is named "get_launch_cpc_campaign_detail". After the interface is named, the complete URL and the request body are spelled out. The request body contains various business parameters required by the interface, and the parameter values of each business parameter are the default first parameter values, and the request body is configured to be changeable based on the test cases in the test case document.

[0082] Step S220, when any test case of the target interface is executed, obtain the pre-generated default request of the target interface.

[0083] Step S230, parse the test case document of the target interface, extract the expected result and determine whether there are business parameters in the currently executed test case in the test case document; if so, execute step S240; if not, execute step S250.

[0084] In the actual implementation process, if the business parameters that need to be updated are recorded under the params of the test case in the test case document, then in the implementation process of this step, methods such as the get_step_params method can be used to locate the test case number and step name of the currently executed test case in the test case document, and then extract the business parameters and the second parameter values under the corresponding test case number and step name.

[0085] In addition, after parsing the test case document of the target interface, the expected results and the like that match the test case number and step name of the currently executed test case are further extracted.

[0086] Step S240, use the second parameter value of the business parameter in the currently executed test case to replace the first parameter value of the corresponding business parameter in the default request to generate an updated request, and use the updated request to make an interface request.

[0087] Step S250, use the default request to make an interface request.

[0088] Step S260, obtain the return result and compare the return result with the expected result.

[0089] By comparing the return result with the expected result, the test result of this time can be determined, and each test result is recorded for finally generating a test report.

[0090] In an alternative embodiment, the test report includes a list of test cases with failed test results. The list of test cases records relevant information about the test cases, and the relevant information may include, but is not limited to: use case name, use case description, person in charge, time consumption, specific error message, etc. Thus, the test results are intuitively presented, facilitating the fault location and handling of Internet products. Moreover, the test report can also be sent to the corresponding processing end in the form of an email, etc., further improving the fault maintenance of Internet products. Among them, the specific display form of the report in the embodiments of the present invention is not limited. For example, it can visually display the proportion of failed test cases, successful test cases, and / or skipped test cases in a graphical manner such as a pie chart or a bar chart, thereby improving the acquisition efficiency of report information.

[0091] It can be seen that the embodiments of the present invention splice the non-business parameters and business parameters of the target interface to generate the default request of the target interface, and only record the parameter values of the business parameters different from those in the default request in the test case. Thus, when the non-business parameters such as the URL and / or request method of the target interface change, only the non-business parameters in the default request need to be adjusted, and there is no need to modify the test case, thereby improving the scalability of this test method.

[0092] Figure 3 The flowchart of still another interface test method provided by the embodiments of the present invention is shown. As Figure 3 shown, the method includes the following steps:

[0093] Step S310, when any test case of the target interface is executed, obtain the default request of the target interface pre-generated.

[0094] Step S320, parse the test case document of the target interface, and determine whether there are business parameters in the currently executed test case in the test case document; if so, execute Step S330; if not, execute Step S340.

[0095] Step S330, use the second parameter value of the business parameter in the currently executed test case to replace the first parameter value of the corresponding business parameter in the default request to generate an updated request, and use the updated request to perform interface testing.

[0096] Step S340, use the default request to perform interface testing.

[0097] Step S350, generate an interface request log of the test case that has performed interface testing; the interface request log contains the interface request information when the test case performs interface testing.

[0098] After performing interface testing using an update request or a default request, an interface request log of the test case for which interface testing has been performed is further generated. The interface request information during the interface testing of the test case is recorded in the interface request log, that is, the actual interface request information when the test case makes an interface request is recorded in the interface request log. The interface request information specifically includes non-business parameters and various business parameters when the test case performs interface testing, etc.

[0099] In an alternative embodiment, the interface request log is as follows:

[0100] {

[0101] "func_name": # Use case name

[0102] "api_name": # Specific interface class name

[0103] "api": # Interface url information

[0104] "method" # Request method

[0105] "request" # Request body information (including various business parameters)

[0106] "return": # Interface return information

[0107] }。

[0108] Step S360, compare the interface request log of any test case for which interface testing has been performed with the test case and / or the default request in the test case document to determine whether there is an interface request exception for this test case.

[0109] Specifically, if the test case for which interface testing has been performed uses an update request for interface testing, during the information comparison process, specifically compare the interface request log of this test case with the second parameter value of the business parameters recorded in the test case document for this test case. If they are consistent, it indicates that the second parameter value has successfully replaced the first parameter value in the default request, which means the parameter update is successful; if they are inconsistent, it indicates that the second parameter value has not successfully replaced the first parameter value in the default request, which means the parameter update is not successful, thereby determining that there is an interface request exception for this test case.

[0110] Further optionally, after comparing the interface request log of the test case with the second parameter value of the business parameter recorded in the test case document for this test case, the interface request log of the test case can also be compared with the parameter values of other request parameters in the default request. If they are consistent, it indicates that there are no request parameters in the default request that have been incorrectly changed or tampered with. If they are inconsistent, it indicates that there are request parameters in the default request that have been incorrectly changed or tampered with, thereby determining that there is an interface request anomaly in this test case.

[0111] If the test case for which interface testing has been performed uses the default request for interface testing, then compare the interface request log of the test case with the parameter values of each request parameter in the default request. If they are consistent, it indicates that there are no request parameters in the default request that have been tampered with. If they are inconsistent, it indicates that the request parameters in the default request have been tampered with, thereby determining that there is an interface request anomaly in this test case.

[0112] In addition, the interface request log can also be reported to the corresponding processing end (such as the test middle platform, etc.), thereby facilitating the processing end to determine the success rate, stability, etc. of the interface through further analysis of the interface request log, thereby enriching the generated test report and improving the efficiency of troubleshooting.

[0113] Thus, it can be seen that the embodiment of the present invention generates the interface request log of the test case for which interface testing has been performed. The interface request log contains the interface request information when the test case performs interface testing, and compares the interface request log of any test case for which interface testing has been performed with the test case and / or the default request in the test case document to determine whether there is an interface request anomaly in this test case, thereby facilitating the maintenance personnel to perform fault tracing.

[0114] Figure 4 Shows a schematic flowchart of a method for generating a test case for interface testing provided by an embodiment of the present invention. As Figure 4 shown, the method includes the following steps:

[0115] Step S410, obtain the written candidate test cases.

[0116] In the prior art, test cases are manually written by testers, and a test case document is directly generated based on the written test cases. Different from the prior art, the test cases written in the embodiment of the present invention are not the final test cases, but are pre-candidate test cases, and the final test cases are generated only after being verified in subsequent steps.

[0117] Step S420, extract the parameter values of each business parameter in the candidate test cases.

[0118] Step S430 , comparing the parameter value of each business parameter in the candidate test case with the first parameter value of each business parameter in the default request to identify the target business parameter.

[0119] Through this step, the business parameter in the candidate test case that is consistent with the corresponding parameter value in the default request can be identified. This business parameter is the target business parameter, so the parameter value of the target business parameter in the candidate test case is the same as the first parameter value in the default request.

[0120] Step S440, deleting the target business parameter and the parameter value of the target business parameter in the candidate test case to generate a test case, and loading the generated test case into the test case document.

[0121] Since the parameter value of the target business parameter in the candidate test case is the same as the first parameter value in the default request, in order to avoid subsequent repeated updates of the target business parameter, the embodiment of the present invention deletes the target business parameter and the corresponding parameter value from the candidate test case after identifying the target business parameter. There is no business parameter consistent with the parameter value in the default request in the test case obtained after the deletion, and the test case generated after the deletion is stored as the final test case in the test case document.

[0122] It can be seen that after obtaining the written candidate test case, the embodiment of the present invention does not directly use the candidate test case as the test case in the final test case document, but verifies the candidate test case to eliminate the target business parameters in the candidate test case that are consistent with the parameter values ​​of the default request, thereby further streamlining the test cases in the test case document. On the one hand, it facilitates the maintenance of the test case, and on the other hand, it can avoid subsequent updates to the business parameters that are consistent with the parameter values ​​in the default request, thereby saving system resources and improving testing efficiency.

[0123] Figure 5 A schematic flow chart of another test case generation method for interface testing provided by an embodiment of the present invention is shown.

[0124] Among them, the embodiment of the present invention mainly provides a multi-scenario test case, that is, one test case contains multiple test scenarios. For example, the multi-scenario test case can be "creating a regular mutual selection order under an internal contract + creating a mutual selection order for investment projects under an internal contract + creating a commercial mutual selection order for up hosts / anchors under an internal contract" and so on. In order to ensure the stable execution of multi-scenario test cases, the embodiment of the present invention includes n test steps in the multi-scenario test case, the first n-1 test steps are common test steps for multiple test scenarios, and the nth test step includes the business parameters for each test scenario, that is, the business parameters for each test scenario are recorded in the last test step of the multi-scenario test case.

[0125] like Figure 5 As shown, the automatic generation method of multi-scenario test cases includes the following steps:

[0126] Step S510, obtaining the written candidate test cases.

[0127] Step S520, extracting multiple candidate test cases with the same first n-1 test steps from the compiled candidate test cases.

[0128] Wherein, n is a positive integer greater than 1. Multiple candidate test cases with the same first n-1 test steps are the basis for generating multi-scenario test cases.

[0129] Step S530, record the first n-1 test steps of multiple candidate test cases, and record the business parameters in the multiple candidate test cases in the nth test step to generate a multi-scenario test case for the multiple candidate test cases, and load the generated multi-scenario test case into the test case document.

[0130] The multiple candidate test cases are merged to generate a multi-scenario test case, in which the first n-1 steps are common test steps for the multi-scenario test cases, and the nth test step records the business parameters and parameter values ​​in each of the multiple candidate test cases. Only the generated multi-scenario test case is stored in the test case document, and the multiple candidate test cases are no longer written.

[0131] As shown in the multi-scenario test case below, the multi-scenario test case includes: multi-scenario test case number "case1", test scenario description applied by the multi-scenario test case "create regular mutual selection orders under internal contracts, create investment project mutual selection orders under internal contracts, create up master / anchor commercial mutual selection orders under internal contracts", step 1 "create internal contracts", step 2 "create 3 types of contract orders", where the business parameters of each test scenario are recorded under the "params" parameter in step 2:

[0132] {case1:

[0133] description:

[0134] - Create a regular mutual selection order under an internal contract (test scenario 1)

[0135] - Create a mutual selection order for investment projects under an internal contract (test scenario 2)

[0136] - Create a commercial mutual selection order for up hosts / anchors under an internal contract (test scenario 3)

[0137] create_contract: # Step 1, create an internal contract

[0138] params:

[0139] type: 2

[0140] name: test1

[0141] expected:

[0142] status_code: 200

[0143] status: "success"

[0144] create_order: # Step 2, create three types of contract orders

[0145] params: # Include business parameters for each test scenario

[0146] - attract_investment_type: 1

[0147] - attract_investment_type: 2

[0148] - attract_investment_type: 3

[0149] expected: # The corresponding expected results

[0150] - status_code: 200

[0151] status: "success"

[0152] - status_code: 200

[0153] status: "success"

[0154] - status_code: 200

[0155] status: "success"}。

[0156] It is understood here that the multi-scenario test case is only an optional test case in the embodiments of the present invention. The embodiments of the present invention can also adopt conventional generation methods to generate single-scenario test cases. As shown below, the single-scenario test case includes: the single-scenario test case number "case1", the test scenario description of the single-scenario test case "Create a mutual selection order under the contract of the marketing center", step 1 and step 2, and each step has corresponding business parameters and expected results (where if the expected result is empty, it is defaulted that the comparison of the expected result and the return result will not be performed subsequently).

[0157] {case2:

[0158] description: Create a mutual selection order under the contract of the marketing center

[0159] create_contract: # Step 1

[0160] params: # Business parameters in step 1

[0161] type: 3

[0162] name: test1

[0163] expected: # Expected result of step 1

[0164] status_code: 200

[0165] status: "success"

[0166] create_order: # Step 2

[0167] params: # Business parameters in step 2

[0168] attract_investment_type: 1

[0169] expected: # Expected result of step 2

[0170] status_code: 200

[0171] status: "success"}.

[0172] It can be seen that the embodiments of the present invention can combine multiple candidate test cases into multi-scenario test cases, thereby reducing the number of test cases and reducing the maintenance difficulty and maintenance cost of the test cases.

[0173] Figure 6 shows a schematic structural diagram of an interface test device provided by the embodiments of the present invention. As Figure 6As shown, the device 600 includes: an acquisition module 610, a parsing module 620, a judgment module 630, and a request module 640.

[0174] The acquisition module 610 is configured to obtain the default request of the target interface pre-generated when any test case of the target interface is executed; wherein, all request parameters required by the target interface and the first parameter values of each request parameter are included in the default request; the request parameters include service parameters.

[0175] The parsing module 620 is configured to parse the test case document of the target interface.

[0176] The judgment module 630 is configured to judge whether there are service parameters in the currently executed test case of the test case document.

[0177] The request module 640 is configured to, if the judgment result of the judgment module is yes, use the second parameter value of the service parameter in the currently executed test case to replace the first parameter value of the corresponding service parameter in the default request to generate an updated request, and perform interface testing using the updated request; wherein, the second parameter value of the same service parameter is different from the first parameter value; if the judgment result of the judgment module is no, perform interface testing using the default request.

[0178] In an alternative embodiment, the device further includes: a use case generation module, configured to obtain the written candidate test cases.

[0179] Extract the parameter values of each service parameter in the candidate test cases.

[0180] Compare the parameter values of each service parameter in the candidate test cases with the first parameter values of each service parameter in the default request to identify the target service parameter; the parameter value of the target service parameter in the candidate test case is the same as the first parameter value in the default request.

[0181] Delete the target service parameter and the parameter value of the target service parameter in the candidate test case to generate a test case, and load the generated test case into the test case document.

[0182] In an alternative embodiment, the test case document includes multi-scenario test cases.

[0183] Wherein, the multi-scenario test case includes n test steps; the first n - 1 test steps are test steps common to multiple test scenarios, and the nth test step includes service parameters under each test scenario.

[0184] In an alternative embodiment, the apparatus further includes: a use case generation module, configured to obtain the prepared candidate test cases;

[0185] Extract multiple candidate test cases with the same first n - 1 test steps from the prepared candidate test cases;

[0186] Record the first n - 1 test steps of the multiple candidate test cases, and record the service parameters in the multiple candidate test cases in the nth test step, so as to generate multi - scenario test cases for the multiple candidate test cases, and load the generated multi - scenario test cases into the test case document.

[0187] In an alternative embodiment, the apparatus further includes: a log module, configured to generate an interface request log of the test cases for which interface tests have been performed; the interface request log contains the interface request information when the test cases perform interface tests.

[0188] In an alternative embodiment, the apparatus further includes: a log verification module, configured to compare the interface request log of any test case for which an interface test has been performed with the test case and / or the default request in the test case document for information comparison, so as to determine whether there is an interface request anomaly for the test case.

[0189] In an alternative embodiment, the request parameters further include at least one of the following non - service parameters: URL, request header, and request method.

[0190] It can be seen that the embodiment of the present invention pre - generates a default request for the target interface, and all request parameters required for the target interface are concatenated in the default request. Subsequently, only the parameter values of the service parameters in the default request need to be updated based on the test cases in the test case document to generate an interface request. Therefore, when the test cases are executed, there is no need to concatenate all request parameters again, thereby improving the test efficiency; moreover, only the parameter values of the service parameters that are updated compared with the service parameters in the default request need to be recorded in the test cases of the test case document, thereby greatly streamlining the test cases, reducing the difficulty of test case maintenance and reducing the maintenance cost.

[0191] Figure 7 FIG. shows a schematic structural diagram of a computing device provided by an embodiment of the present invention. The specific embodiments of the present invention do not limit the specific implementation of the computing device.

[0192] As Figure 7 shown, the computing device may include: a processor 702, a communication interface 704, a memory 706, and a communication bus 708.

[0193] Among them: The processor 702, the communication interface 704, and the memory 706 communicate with each other through the communication bus 708. The communication interface 704 is used to communicate with network elements of other devices such as clients or other servers. The processor 702 is used to execute the program 710, and specifically can execute the relevant steps in the above-mentioned method embodiments for interface testing.

[0194] Specifically, the program 710 may include program code, and the program code includes computer operation instructions.

[0195] The processor 702 may be a central processing unit CPU, or a specific integrated circuit ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of the present invention. One or more processors included in the computing device may be of the same type of processor, such as one or more CPUs; or may be of different types of processors, such as one or more CPUs and one or more ASICs.

[0196] The memory 706 is used to store the program 710. The memory 706 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk memory. The program 710 is specifically used to cause the processor 702 to execute the method in any of the above-mentioned method embodiments.

[0197] The embodiments of the present invention provide a non-volatile computer storage medium, and the computer storage medium stores at least one executable instruction, and the computer executable instruction can execute the interface testing method in any of the above-mentioned method embodiments.

[0198] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings based herein. The structure required to construct such a system will be apparent from the above description. In addition, the embodiments of the present invention are not directed to any specific programming language. It should be understood that the content of the embodiments of the present invention described herein can be implemented using various programming languages, and the description of a specific language above is to disclose the best mode of the embodiments of the present invention.

[0199] In the specification provided herein, a large number of specific details are set forth. However, it can be understood that the embodiments of the present invention can be practiced without these specific details. In some instances, well-known methods, structures, and technologies have not been shown in detail so as not to obscure the understanding of this specification.

[0200] Similarly, it should be understood that, in order to streamline the embodiments of the present invention and assist in understanding one or more of the various inventive aspects, in the above description of the exemplary embodiments of the embodiments of the present invention, the various features of the embodiments of the present invention are sometimes grouped together into a single embodiment, figure, or description thereof. However, the disclosed method should not be construed as reflecting an intention that the claimed embodiments of the present invention require more features than are expressly recited in each claim. Rather, as reflected in the following claims, the inventive aspects lie in less than all of the features of the single embodiments disclosed previously. Thus, the claims following the detailed description are hereby expressly incorporated into the detailed description, where each claim stands on its own as a separate embodiment of the embodiments of the present invention.

[0201] Those skilled in the art can understand that the modules in the devices in the embodiments can be adaptively changed and disposed in one or more devices different from the embodiments. The modules or units or components in the embodiments can be combined into one module or unit or component, and in addition, they can be divided into multiple sub-modules or sub-units or sub-components. Except that at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all the features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all the processes or units of any method or device so disclosed. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) can be replaced by an alternative feature that provides the same, equivalent, or similar purpose.

[0202] In addition, those skilled in the art can understand that, although some of the embodiments herein include certain features included in other embodiments rather than other features, the combination of the features of different embodiments means that it is within the scope of the embodiments of the present invention and forms different embodiments. For example, in the following claims, any one of the claimed embodiments can be used in any combination.

[0203] Each component embodiment of the embodiments of the present invention may be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. Those skilled in the art should understand that a microprocessor or a digital signal processor (DSP) may be used in practice to implement some or all of the functions of some or all of the components according to the embodiments of the present invention. The embodiments of the present invention may also be implemented as a device or apparatus program (e.g., a computer program and a computer program product) for performing part or all of the methods described herein. Such a program implementing the embodiments of the present invention may be stored on a computer-readable medium, or may be in the form of one or more signals. Such signals may be downloaded from an Internet website, or provided on a carrier signal, or in any other form.

[0204] It should be noted that the above embodiments illustrate the embodiments of the present invention rather than limit the embodiments of the present invention, and those skilled in the art can design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in the claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The embodiments of the present invention may be implemented by means of hardware including several different elements and by means of a suitably programmed computer. In the unit claims listing several devices, several of these devices may be embodied by the same item of hardware. The use of the words first, second, and third, etc. does not denote any order. These words may be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. An interface testing method, characterized in that, Including: Obtain the written candidate test cases; Extract the parameter values of each business parameter in the candidate test cases; Compare the parameter values of each business parameter in the candidate test cases with the first parameter values of each business parameter in the default request to identify the target business parameter, where the parameter value of the target business parameter in the candidate test case is the same as the first parameter value in the default request; Delete the target business parameter and its parameter value in the candidate test case to generate a test case, and load the generated test case into the test case document; When any test case of the target interface is executed, obtain the default request of the target interface pre-generated; wherein, the default request contains all request parameters required by the target interface and the first parameter values of each request parameter; the request parameters include business parameters, and the business parameters are related to the actual business scenario but the parameter values are not fixed; Parse the test case document of the target interface, and determine whether there are business parameters in the currently executed test case in the test case document; If so, use the second parameter value of the business parameter in the currently executed test case to replace the first parameter value of the corresponding business parameter in the default request to generate an updated request, and use the updated request to perform interface testing; wherein, the second parameter value of the same business parameter is different from the first parameter value; If not, use the default request to perform interface testing.

2. The method according to claim 1, wherein The test case document contains multi-scenario test cases; Among them, the multi-scenario test case contains n test steps; the first n-1 test steps are test steps shared by multiple test scenarios, and the nth test step contains business parameters under each test scenario.

3. The method according to claim 2, wherein Before parsing the test case document of the target interface, the method further includes: Obtain the written candidate test cases; Extract multiple candidate test cases with the same first n-1 test steps from the written candidate test cases; Record the first n-1 test steps of the multiple candidate test cases, and record the business parameters in the multiple candidate test cases in the nth test step to generate the multi-scenario test cases of the multiple candidate test cases, and load the generated multi-scenario test cases into the test case document.

4. The method according to any one of claims 1-3, characterized in that After using the updated request to perform interface testing, or, after using the default request to perform interface testing, the method further includes: Generate an interface request log of the test case that has been subjected to interface testing; the interface request log contains the interface request information when the test case performs interface testing.

5. The method according to claim 4, characterized in that, The method further includes: Compare the interface request log of any test case that has been subjected to interface testing with the test case and / or the default request in the test case document to determine whether there is an interface request exception in the test case.

6. The method according to any one of claims 1 to 3, characterized in that, The request parameters further include at least one of the following non-business parameters: URL, request header, and request method.

7. An interface testing device, characterized in that, Including: A use case generation module for obtaining the written candidate test cases; Extract the parameter values of each business parameter in the candidate test cases; Compare the parameter values of each service parameter in the candidate test case with the first parameter values of each service parameter in the default request to identify the target service parameter, where the parameter value of the target service parameter in the candidate test case is the same as the first parameter value in the default request; Delete the target service parameter and its parameter value in the candidate test case to generate a test case, and load the generated test case into the test case document; An acquisition module, configured to acquire the default request of the target interface pre-generated when any test case of the target interface is executed; wherein, the default request includes all request parameters required by the target interface and the first parameter values of each request parameter; the request parameters include service parameters; the service parameters are related to the actual business scenario but the parameter values are not fixed; A parsing module, configured to parse the test case document of the target interface; A judgment module, configured to judge whether there are service parameters in the currently executed test case in the test case document; A request module, configured to, if the judgment result of the judgment module is yes, use the second parameter value of the service parameter in the currently executed test case to replace the first parameter value of the corresponding service parameter in the default request to generate an updated request, and perform interface testing using the updated request; wherein, the second parameter value of the same service parameter is different from the first parameter value; if the judgment result of the judgment module is no, perform interface testing using the default request.

8. A computing device, characterized in that, Comprising: A processor, a memory, a communication interface and a communication bus, and the processor, the memory and the communication interface complete communication with each other through the communication bus; The memory is used to store at least one executable instruction, and the executable instruction causes the processor to perform the operations corresponding to the interface testing method according to any one of claims 1-6.

9. A computer storage medium, characterized in that, At least one executable instruction is stored in the storage medium, and the executable instruction causes the processor to perform the operations corresponding to the interface testing method according to any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product performs the operations corresponding to the interface testing method according to any one of claims 1-6.

Images