Method and device for generating test case of interface, equipment and storage medium
By obtaining the interface data format and generating relevant information, directly generating test cases, the problems of low interface testing efficiency and complex permission management in the existing technology are solved, and a more efficient test case generation and simplified test process is achieved.
Patent Information
- Application Number
- CN202510147705.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-10
- Publication Date
- 2025-05-30
AI Technical Summary
The prior art relies on external platform docking during interface testing, resulting in inefficient testing and complex permission management, which increases the complexity and time cost of the test process.
By obtaining the interface data format, generating interface data specifications, obtaining the basic information used to build test requests, generating interface parameters and test case descriptions, and finally generating test cases.
Improve the efficiency of test case generation, reduce dependence on external platforms, simplify permission management, and reduce the complexity and time cost of the test process.
Smart Images
Figure CN120066965A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of interface testing, and particularly relates to a method, device, equipment and storage medium for generating test cases of an interface. Background Art
[0002] In various fields, for example, in the field of medical and health, when the diagnosis and treatment information of patients is transmitted online, an interface is required to transmit the diagnosis and treatment information data. In order to ensure the normal operation of the interface, it is necessary to test the interface. For example, when testing the server side, the design of test cases for interface boundary value equivalence class testing is of utmost importance. It is related to the verification of each field and is an important guarantee to ensure the accuracy, stability of the interface function and correct data interaction. For example, in the financial field, when processing banking business and transmitting the business information that users need to handle online, an interface is required to transmit the business information data. In order to ensure that the interface can transmit the business information data normally, it is also necessary to test the interface.
[0003] Currently, in the related art, when testing an interface, the test platform adopts a scheme of docking with an external platform to obtain interface information. However, in actual applications, it exposes the problem of lack of flexibility. Specifically, when testing an interface, the interface needs to be uploaded to a specific platform, and then corresponding test cases are generated according to the relevant rules and mechanisms of the external platform. This process is rather cumbersome and greatly restricts the timeliness and convenience of writing test cases.
[0004] In addition, such external platforms often also have a permission management mechanism. This means that before writing test cases, the relevant logged-in users must ensure that they have the corresponding permissions, otherwise they simply cannot smoothly carry out the work of writing test cases. This undoubtedly adds additional complexity and restrictive conditions to the entire test process, making testers spend more time and effort to coordinate matters related to permissions when working. Summary of the Invention
[0005] The present invention provides a method, device, equipment and storage medium for generating test cases of an interface to solve the technical problem of too low efficiency of interface testing due to using an external platform docking in the related art.
[0006] In a first aspect, the present invention provides a method for generating test cases of an interface, including:
[0007] Obtain the data format of the interface;
[0008] Generate an interface data specification for describing the data format according to the data format of the interface;
[0009] Obtain the basic information for constructing the interface of the test request according to the specification corresponding to the data format;
[0010] Generate interface input parameters and a test case description of the interface according to the basic information of the interface, where the test case description is used to describe the test purpose of the test request;
[0011] Generate test cases according to the interface input parameters and the test case description of the interface.
[0012] In a second aspect, the present invention provides a device for generating test cases of an interface, including:
[0013] An acquisition module, configured to acquire the data format of the interface;
[0014] A first generation module, configured to generate an interface data specification for describing the data format according to the data format of the interface;
[0015] A basic information acquisition module, configured to obtain the basic information of the interface for constructing the test request according to the specification corresponding to the data format;
[0016] A second generation module, configured to generate interface input parameters and a test case description of the interface according to the basic information of the interface, where the test case description is used to describe the test purpose of the test request;
[0017] A third generation module, configured to generate test cases according to the interface input parameters and the test case description of the interface.
[0018] In a third aspect, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the above method for generating test cases of the interface are implemented.
[0019] In a fourth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above method for generating test cases of the interface are implemented.
[0020] In the solution implemented by the above method, device, equipment, and storage medium for generating test cases of the interface, after obtaining the data format of the interface, interface input parameters and a test case description of the interface can be finally generated step by step. Furthermore, based on the interface input parameters and the test case description, the required test cases can be obtained. Obviously, in the process of generating test cases in the present invention, only the data format of the interface itself needs to be concerned, and a series of information for generating test cases can be obtained. Compared with the related art in which the interface is uploaded to an external platform to generate test cases, the generation efficiency of test cases can be effectively improved. Description of the Drawings
[0021] To more clearly illustrate the technical solutions of the embodiments of the present invention, the following will briefly introduce the accompanying drawings required for the description of the embodiments of the present invention. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can be obtained based on these drawings.
[0022] Figure 1 It is a schematic flowchart of a method for generating test cases for an interface in an embodiment of the present invention;
[0023] Figure 2 is Figure 1 A schematic flowchart of a specific implementation manner of step S120 in;
[0024] Figure 3 is Figure 1 A schematic flowchart of a specific implementation manner of step S140 in;
[0025] Figure 4 is Figure 1 Another schematic flowchart of a specific implementation manner of step S140 in;
[0026] Figure 5 is Figure 1 A schematic flowchart of a specific implementation manner of step S150 in;
[0027] Figure 6 is Figure 1 Another schematic flowchart of a specific implementation manner of step S150 in;
[0028] Figure 7 It is a schematic structural diagram of a device for generating test cases for an interface in an embodiment of the present invention;
[0029] Figure 8 It is a schematic structural diagram of a computer device in an embodiment of the present invention;
[0030] Figure 9 It is another schematic structural diagram of a computer device in an embodiment of the present invention. Detailed implementation manner
[0031] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts belong to the scope of protection of the present invention.
[0032] Figure 1The flowchart of the method for generating test cases for the interface provided by the embodiments of the present invention is as follows. Figure 1 As shown, the method for generating test cases for the interface provided by the embodiments of the present invention includes the following steps.
[0033] Step S110, obtain the data format of the interface.
[0034] In this step, the data format information of the interface can be obtained through various channels. For example, look for the corresponding descriptions in the design documents of the interface. These documents usually clearly define the data structures received and returned by the interface. Professional network packet capture tools can also be used to capture the data packets during the actual operation of the interface, and then analyze to obtain its specific data format, view the types, orders of each field, and possible nested relationships, etc. In addition, if there is an instruction document for the interface, the details of the data format of the interface will also be clearly presented in the instruction document, laying a foundation for subsequent work. Step S120, generate an interface data specification for describing the data format according to the data format of the interface.
[0035] First, determine the specific format adopted by the interface data. Different formats have different structural characteristics and parsing methods.
[0036] As a specific example, assume a data format of an interface, its object structure can be parsed, and further, the number of key-value pairs it contains, the attribute meanings represented by each key, and the data types of the corresponding values (such as strings, numbers, booleans, arrays, objects, etc.) can be viewed. For example, for an interface data format representing user information, it may contain attributes such as "name" (string type, representing the username) and "age" (number type, representing the age). For each attribute, it can be checked whether there are mandatory requirements. For example, the "name" attribute in the above user information interface can be specified as mandatory. Further, the value range limit can be clarified. For example, the "age" attribute may be limited to a value range between 0 and 150 (theoretically reasonable age range). Further, the precision requirements of the data format can be considered. For example, for a numeric type field involving an amount, it may be specified to retain two significant digits after the decimal point. By specifying and describing each attribute one by one in this way, a complete interface data specification is finally summarized to accurately and comprehensively describe the data format requirements and constraints of the interface. As a specific example, for example, when an interface is for user information in a medical and health insurance system or an interface in financial business systems such as banks and securities, when transmitting user information for medical and health insurance, bank, and securities fund management, the data format of the interface may include "name" (username, such as Wang Wu) and "age" (age, such as 45 years old).
[0037] In an alternative implementation, as Figure 2As shown, step S120 includes:
[0038] Step S121, obtaining each attribute information of the data of the interface according to the data format of the interface.
[0039] Step S122, generating a specification describing each attribute information of the data to obtain a specification corresponding to the described data format.
[0040] For step S121, the obtained interface data format can be analyzed, and the same or different analysis methods can be adopted for different data structure types. Exemplarily, assuming a preset interface data format, parsing its key-value pairs can determine the attribute name corresponding to each key, judge the data type of the value (such as string, number, boolean, array, or object, etc.), and at the same time pay attention to whether there are attribute-related limiting conditions such as default values and value ranges.
[0041] For step S122, based on the attribute information sorted out in step S121, it is described and integrated according to the unified specification requirements. Clearly list the key information such as the name, type, value range, and whether it is required of each attribute.
[0042] As a specific example, assuming the interface is a medical health insurance claim query interface, each attribute information of the data obtained according to its data format can be the name of the insured, the type of insurance, the insurance amount, the start date of insurance, and the end date of insurance, etc. Further, for the attribute information of the name of the insured, the specification for describing this attribute information can be the attribute name value, data type value, and value range value, etc.; assuming the interface is a banking business management interface, each attribute information of the data obtained according to its data format can be the name of the customer, the type of business handled by the customer in the bank, the amount involved in the customer's business type, the start date and end date of the customer's business, etc. Further, for the attribute information of the name of the customer, the specification for describing this attribute information can be the attribute name value, data type value, and value range value, etc.
[0043] Step S130, obtaining the basic information of the interface for constructing a test request according to the specification corresponding to the data format.
[0044] Specifically, according to the already generated interface data format specification, various basic information required for constructing test requests can be extracted from it. For example, from the specification, clarify the request method of the interface, whether it is using a data acquisition request to obtain data or a data submission request to submit data, etc.; determine the preconditions of the interface, such as whether certain interfaces require users to log in and authenticate first before being called, or whether specific system status and other prerequisite requirements need to be met; carefully sort out the field definitions of the interface, understand the specific meanings, format requirements, etc. of each field in the request and return data; at the same time, figure out the structural form of the interface return data, whether it is a simple single-layer structure or a complex multi-layer nested structure, so as to accurately verify the return results later. These basic information will serve as an important basis for the subsequent generation of relevant content of test cases.
[0045] As a specific example, assume that the interface is a medical health insurance claim application interface. According to the specification corresponding to the interface data format, the basic information of the interface for constructing test requests can be that the request method of the interface is to send a request, the preconditions are that a valid identity token needs to be obtained and the insurance policy needs to be in a valid state. The request field definitions of the interface can further include policy identification, claim type, claim amount, claim application date, and user identification, etc., and the return field definitions of the interface can further include the current status of the claim application and the approved claim amount, etc.; assume that the interface is a bank account transfer interface. According to the specification corresponding to the interface data format, the basic information of the interface for constructing test requests can be that the request method of the interface is to send a request, the preconditions are that the user needs to obtain a valid session token and the transfer-out account needs to have sufficient funds to pay the transfer amount and the account status is normal. The request field definitions of the interface can further include the initiating account of the transfer, the target account receiving the transfer, the transfer amount, and the transfer operation date, etc., and the return field definitions of the interface can further include the current status of the transfer transaction and the identification of the transfer transaction.
[0046] Step S140, according to the basic information of the interface, generate interface input parameters and a test case description of the interface, where the test case description is used to describe the test purpose of the test request.
[0047] Optionally, the basic information of the interface includes the request method of the interface, the preconditions of the interface, the field definitions of the interface, and the structural form of the interface return data.
[0048] Specifically, starting from the request method of the interface, if it is a data acquisition request, the test scenarios may include verifying the impact of different combinations of query parameters on the results. For example, verifying whether the data returned by the interface is correct when different filtering conditions (such as by date range, by product category, etc.) are passed in. If it is a data submission request, consider the impact of different request body contents on the interface function, such as how the interface handles when form data of different formats or contents is submitted.
[0049] Specifically, according to the preconditions of the interface, such as the interface requires logging in first to access, then it is necessary to set the corresponding login state to simulate the logged-in scenario for testing. At the same time, it is also necessary to test whether the interface correctly returns an unauthorized prompt when accessing directly without logging in.
[0050] Specifically, for the field definitions of the interface, for required fields, design test cases to verify whether the interface can give accurate error prompts when required fields are missing; for optional fields, test the interface's response when different values (including legal values, boundary values, illegal values, etc.) are passed in. For example, for an interface that contains a "mobile phone number" (required field) and "remark information" (optional field), test the feedback of the interface when the "mobile phone number" is empty, and the processing results in different situations such as when an extremely long string is passed in for "remark information".
[0051] Furthermore, based on the structural form of the data returned by the interface, the key points for verifying the return results can be determined. If it is a complex nested structure, test whether the hierarchical relationship of the returned data is correct and whether the data within each level meets the expectations.
[0052] For each determined test scenario and requirement, write clear and detailed test case descriptions. For example, for the test scenario of verifying the query by date range in the data acquisition request, the test case description can be: "This test case aims to verify that when the interface receives a data acquisition request and different date range parameters are passed in (such as the start date is earlier than the end date, the start date is equal to the end date, the start date is later than the end date, etc.), whether the interface can correctly return the data that meets the conditions within the corresponding date range, and the returned data structure meets the expectations, and the status code is 200. If an illegal date format or an illogical date range is passed in, the interface should return the corresponding error prompt message and the status code is 400".
[0053] Another example is for the test scenario of verifying the required field "mobile phone number". The test case description is: "This test case is used to verify that when the 'mobile phone number' field is empty in the data submission request, whether the interface can accurately return the prompt message that 'the mobile phone number cannot be empty', and the returned status code should be 400; when a legal mobile phone number format is passed in, the interface should process the request normally, return a status code of 200 and the corresponding processing result data".
[0054] Construct specific interface input parameter data according to different test scenarios and requirements. For the above test scenario of querying by date range, multiple different date range parameters need to be constructed as input parameters. For example, one set of input parameters is "start_date=2024-01-01&end_date=2024-01-10" (representing a normal date range), and another set of input parameters is "start_date=2024-01-10&end_date=2024-01-01" (representing an illegal date order), etc.
[0055] For the scenario of required field verification, construct different input parameter examples with and without required fields. For example, for the verification of the "mobile phone number" field, in one set of input parameters, the "mobile phone number" field is passed with a legal value of "13812345678", and in another set of input parameters, the "mobile phone number" field is an empty value, etc.
[0056] Specifically, for the test of optional fields, construct input parameters with optional field values of different types and different value ranges. For example, for the "remark information" field, pass input parameter data in different cases such as an empty string, a string of normal length, and an overly long string, etc., to comprehensively cover various possible test cases and ensure that the functionality of the interface under different inputs can be effectively verified.
[0057] As a specific example, assume that the interface is an interface for obtaining insured person information in the field of medical health insurance. The basic information of the interface can be the following: the request method of the interface is a get request, the precondition of the interface is that the user has the permission to view the insured person information, the field definition of the interface can include required fields, such as the insured person identification number, and can also include optional fields, such as the insured person name and the insured date range. The structure form of the data returned by the interface is an object structure containing the basic information and insured information of the insured person. Further, based on the above basic information of the interface, the description of the required fields in the test case description of the generated interface can be "This test case is used to verify that in the request for obtaining insured person information, when the insured person identification number field is empty, whether the interface can accurately return a prompt message indicating that the insured person identification number cannot be empty, and the returned status code should be 400; when a legal identification number format is passed in, the interface should process the request normally, return a status code of 200 and the corresponding insured person information, and the information structure meets the expectations." Further, the interface input parameters can be two sets of input parameters. One set of input parameters is "insured person identification number =", and the other set of input parameters is "insured person identification number = xxxxxxxxxxxxxxxx". Assume that the interface is an interface for querying account balance. The basic information of the interface can be the following: the request method of the interface is a get request, the precondition of the interface can be that the account status is normal, the field definition of the interface can include required fields, such as the bank card number, and can also include optional fields, such as the account type, etc. The structure form of the data returned by the interface can be an object structure containing information such as the account balance. Further, based on the above basic information of the interface, the description of the required fields in the test case description of the generated interface can be "This test case is used to verify that in the request for querying account balance, when the 'bank card number' field is empty, whether the interface can accurately return a prompt message indicating that the bank card number cannot be empty, and the returned status code should be 400; when a legal bank card number format is passed in, the interface should process the request normally, return a status code of 200 and the corresponding account balance and other information, and the information structure meets the expectations." Further, the interface input parameters can be two sets of input parameters. One set of input parameters is "bank card number =", and the other set of input parameters is "bank card number = xxxxxxxxxxxxxxx".
[0058] In an alternative implementation, as Figure 3 shown, step S140 includes the following steps.
[0059] Step S1411, generate various test requirements for the interface and the test case descriptions corresponding to the test requirements according to the basic information of the interface;
[0060] Step S1412, generate interface input parameters that meet the test requirements according to the basic information of the interface and the test requirements.
[0061] For step S1411, different test scenarios and test requirements can be analyzed in combination with the basic information of the interface. For example, for the mandatory fields of the interface, there can be a test requirement to verify that the interface returns the corresponding error prompt when a mandatory field is missing; for the value range of the field, there can be a requirement to test whether the interface response is correct when inputting boundary values and values beyond the boundary. Further, for each test requirement, a detailed test case description can be written to clearly explain the specific content that the test case wants to verify. For example, "This test case aims to verify that when the 'username' field is input with a length exceeding the specified length (greater than 20 characters), whether the interface can correctly return the error prompt message 'The username length does not meet the requirements'". In this way, a set of test case descriptions covering various test requirements can be generated.
[0062] For step S1412, specific interface input parameter data is constructed based on the basic information of the interface and various test requirements determined previously. For example, for the test requirement of verifying mandatory fields, an example of input parameter data that only lacks mandatory fields can be constructed; for the boundary value test requirement, input parameter data that is just at the boundary values (minimum value, maximum value) and beyond the boundary values can be constructed respectively. According to different test scenarios, carefully prepare the interface input parameter content that meets the corresponding test requirements to ensure that all possible situations can be comprehensively covered, providing effective input data for subsequent accurate interface testing.
[0063] Optionally, as Figure 4 shown, step S140 includes the following steps.
[0064] Step S1421, generate the identity information of the interface;
[0065] Step S1422, generate interface input parameters and the test case description of the interface according to the basic information of the interface and the identity information of the interface, and both the interface input parameters and the test case description of the interface carry the identity information of the interface.
[0066] For step S1421, relevant information that can uniquely identify the identity of the interface can be generated according to factors such as the project, module to which the interface belongs, and its corresponding permission system. This may include the system name to which the interface belongs, the business module identifier where it is located, the unique number of the interface, etc. For example, in a medical and health insurance business system, the identity information of the "major disease insurance query interface" can be "Medical and Health Insurance Business System - Major Disease Insurance Module - Interface Number 001". For example, in a banking business system, the identity information of the "balance query interface" can be "Banking Business System - Balance Query Module - Interface Number 001". Through such clear and unique identity information, it is convenient to accurately distinguish and track this interface in the subsequent entire test process and possibly involved project management.
[0067] Regarding step S1422, when constructing the interface input parameters and writing the test case description, the previously generated interface identity information can be incorporated. In the interface input parameters, a specific field can be added to store the identity information so that the interface can accurately identify the source when receiving requests and perform corresponding processing; in the test case description, the specific identity of the interface targeted by the test case is also noted, such as "This test case is for the critical illness insurance query interface 'Medical and Health Insurance Business System - Critical Illness Insurance Module - Interface No. 001', aiming to verify...", or "This test case is for the balance query interface 'Banking Business System - Balance Query Module - Interface No. 001', aiming to verify...". In this way, all links in the entire test process can be closely associated with the specific interface, avoiding confusion, and at the same time facilitating accurate statistics and analysis of the test results later to clarify the test situation of each interface.
[0068] Step S150, generate test cases according to the interface input parameters and the test case description of the interface.
[0069] Specifically, interface input parameters refer to the data passed to a software interface when calling it. These data are the input information required for the interface to complete its functions. The interface will perform corresponding operations based on these inputs and return results. And the test cases of the interface are used to test the functions of the interface. Therefore, after determining the interface input parameters and the test case description of the interface (i.e., the test purpose of the interface), test cases for achieving the test purpose can be generated based on the interface input parameters and the test case description.
[0070] As Figure 5 shown, step S150 includes the following steps.
[0071] Step S1511, generate the test steps of the interface and the expected output according to the interface input parameters and the test case description of the interface;
[0072] Step S1512, send a test request according to the test steps;
[0073] Step S1513, after sending the test request, obtain the actual output returned by the interface;
[0074] Step S1514, compare the expected output and the actual output to obtain the test result;
[0075] Step S1515, generate test cases according to the test steps, the expected output, the test request, the actual output, and the test result.
[0076] For step S1511, based on the interface input parameters and test case descriptions, detailed test steps can be sorted out. For example, first describe how to construct and send a test request (including specific operations such as which tool to use and which request header information to set), and then explain how long to wait to obtain the response after sending the request and other specific process steps. At the same time, according to the functional requirements of the interface and business logic, combined with the understanding of the interface data format specifications and test requirements, determine the corresponding expected output results for each test scenario. For example, for a test case that verifies that the user name length does not meet the requirements, the expected output is that the interface returns a specific error prompt message, such as a clear content like "The user name length does not meet the requirements, please re-enter". Organize these test steps and expected outputs one by one to prepare for subsequent test execution and result verification.
[0077] For step S1512, according to the previously generated test steps, select a suitable test tool to actually send the test request. When sending the request, strictly follow the request method set in the steps, accurately fill in the interface input parameter data, and configure the corresponding request header information to ensure that the request can be sent accurately to the corresponding interface address, triggering the corresponding processing logic of the interface.
[0078] For step S1513, after sending the test request, wait for the interface to complete processing and return the corresponding response data, and capture the actual returned data content through a test tool or by writing corresponding code logic. Ensure that all information returned by the interface is obtained completely, including the returned status code, specific data in the response body, etc., so as to accurately compare and analyze with the expected output later.
[0079] For step S1514, conduct a detailed comparison and analysis of the actual output of the interface obtained and the previously determined expected output. For example, check whether the returned status code meets the expectations (such as expecting a return of 200 indicating success, and whether the actual return is also 200), and then compare the specific data content in the response body to see if it is exactly the same as the expected format, value, etc. If the actual output matches the expected output in all key aspects, then the test result of this test case passes; otherwise, if there are any inconsistencies, it is determined that the test case fails, and record the specific differences as the basis for subsequent problem troubleshooting and interface optimization.
[0080] For step S1515, integrate all the previously involved content, including test steps, expected outputs, sent test requests, obtained actual data, and finally derived test results, and generate a complete test case document or record it in the test management system according to certain formats and specification requirements. Specifically, the detailed situation of each link should be clearly presented in the test case document. Through such complete and standardized records, it is convenient to review and statistically analyze the test situation later and provide an accurate reference basis for subsequent regression testing and other work.
[0081] As a specific example, assume that the interface is the interface for obtaining insured person information. The interface input parameters corresponding to the required field "insured person identity number" can be "insured person identity number =" and "insured person identity number = xxxxxxxxxxx", and the corresponding test case description can be "Verify that when the field "insured person identity number" is empty in the request for obtaining insured person information, whether the interface can accurately return the prompt message "insured person identity number cannot be empty", and the returned status code should be 400; when a legal identity number format is passed in, the interface should process the request normally, return a status code of 200 and the corresponding insured person information, and the information structure should meet the expectations". Furthermore, the generated test steps for the interface can be "First step, call the interface and pass in an empty "insured person identity number"; second step, check the interface return information to confirm whether it contains the prompt "insured person identity number cannot be empty" and whether the status code is 400; third step, call the interface and pass in the legal identity number "xxxxxxxxxxxx"; fourth step, check whether the interface return status code is 200 and whether the returned insured person information structure meets the expectations". The further generated expected output of the interface is "After the first and second operations, the interface returns a prompt containing "insured person identity number cannot be empty" and the status code is 400. After the third and fourth operations, the interface returns a status code of 200, and the insured person information structure meets the expectations". Further, a real test request can be sent to the server according to the test steps to obtain the actual output returned by the interface. For example, the actual output can be no status code, no identity number is returned, and no prompt message of "insured person identity number cannot be empty" is returned. Comparing this actual output with the expected output, the test result can be obtained as the test fails. Then, combine the above test steps, expected output, test request, actual output, and test result to generate a test case.
[0082] Assume the interface is the interface for querying account balance. The interface input parameter corresponding to the required field "bank card number" can be "bank card number =" and "bank card number = xxxxxxxxxxx", and the corresponding test case description can be "Verify that when the "bank card number" field is empty in the query account balance request, whether the interface can accurately return the prompt message "bank card number cannot be empty", and the returned status code should be 400; when a legal bank card number format is passed in, the interface should process the request normally, return the status code 200 and corresponding account balance and other information, and the information structure meets the expectations". Furthermore, the generated test steps for the interface can be "First step, call the interface and pass in an empty "bank card number"; Second step, check whether the interface return contains the prompt "bank card number cannot be empty" and whether the status code is 400; Third step, call the interface and pass in the legal bank card number "6222021001000000000"; Fourth step, check whether the interface return status code is 200 and whether the information structure such as the account balance meets the expectations". The further generated expected output of the interface is "After the first and second operations, the interface return contains the prompt "bank card number cannot be empty" and the status code is 400. After the third and fourth operations, the interface return status code is 200 and the information structure such as the account balance meets the expectations". Further, send real test requests to the server according to the test steps, and obtain the actual output returned by the interface. When the actual output is the same as the expected output, the test result can be obtained as the test passes. When the actual output is different from the expected output, the test result can be obtained as the test fails. Furthermore, combine the above test steps, test output, test requests, actual output, and test results to generate test cases.
[0083] As Figure 6 shown, step S150 includes the following steps.
[0084] Step S1521, obtain the project information corresponding to the interface;
[0085] Step S1522, generate the preset information required when obtaining the test case according to the influence of the project information on the test case;
[0086] Step S1523, generate test cases according to the interface input parameter, the use case description of the interface, and the preset information of the interface.
[0087] For step S1521, find the overall project information associated with this interface, which can cover the project name, the business area it belongs to (such as finance, medical, etc.), the project version number, the composition of the main functional modules of the project, etc.
[0088] Regarding step S1522, analyze the associations and influencing factors between project information and test cases to determine the relevant information that needs to be pre-set. For example, if the project is in different version stages, there may be different requirements for certain functional characteristics of the interface. In this case, it is necessary to pre-set the corresponding test environment configuration information (such as database connection parameters, specific system configuration switches, etc.) according to the function change situation corresponding to the specific version. Or, if the business area to which the project belongs has its own industry-specific regulatory requirements, then some default values or verification rules that comply with these regulations need to be pre-set in the test cases. In this way, the key pre-set information that will affect the execution and result judgment of test cases due to project information can be prepared in advance.
[0089] Regarding step S1523, finally, organically integrate the interface input parameters, the already written interface test case descriptions, and the pre-set information generated above. A complete test case can be generated according to a unified test case template or the format agreed upon within the team. Ensure that the test case covers all aspects, including input data (interface input parameters), test purpose (case description), and key configurations affected by the project environment (pre-set information), so that the generated test case can not only accurately verify the interface function but also fully consider various factors in the actual project operation environment, providing strong guarantee for high-quality interface testing work.
[0090] As a specific example, assume that the interface is the claim submission interface. The project information corresponding to the interface is that the project name is the medical health insurance claim management system, the business area it belongs to is medical health insurance, the version number of the project can be V2.0, the main functional modules of the project consist of the insured information management module, the claim application acceptance module, the claim review module, and the claim payment module, etc. The V2.0 version can add a risk assessment function to the claim submission interface, and additional risk reviews can be performed when the claim amount exceeds a certain threshold. On this basis, the pre-set information needs to set the database connection parameters so that relevant risk assessment data can be queried during testing. Further, when generating test steps, test steps for the pre-set information can be generated, and then test cases can be generated.
[0091] As a specific example, assume that the interface is a fund transfer interface. The project information corresponding to the interface is that the project name is the banking comprehensive business system - fund transfer module, the business area it belongs to is banking business, the version number of the project is V3.1, the main functional modules of the project include an account management module, a fund transfer business processing module, a fund clearing module, a transaction record query module, etc. The V3.1 version adds a real-time exchange rate conversion function to the fund transfer interface, which is applicable to cross-border fund transfer business. On this basis, connection parameters of the exchange rate service can be correspondingly set in the preset information so as to obtain the real-time exchange rate when testing cross-border fund transfers. At the same time, the configuration switch for real-time exchange rate conversion in the system can be turned on. In addition, banking business requires that the transfer amount must be within the available balance of the account and there is a daily transfer limit regulation. Therefore, the preset information needs to include the initial balance of the account and the daily transfer limit to verify whether the transfer operation is compliant. Further, when generating test steps, test steps for the preset information can be generated, and then test cases can be generated. In this way, after obtaining the data format of the interface in the embodiment of the present invention, the interface input parameters and the test case description of the interface can be finally generated step by step. Then, based on the interface input parameters and the test case description, the required test cases can be obtained. Obviously, in the process of generating test cases in the embodiment of the present invention, only by paying attention to the data format of the interface itself, a series of information for generating test cases can be obtained. Compared with the related art of uploading the interface to an external platform and using the external platform to generate test cases, the generation efficiency of test cases can be effectively improved.
[0092] It should be understood that the magnitudes of the sequence numbers of the steps in the above embodiments do not mean the order of execution is prior or posterior. The execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention. The non-company software tools or components appearing in the embodiments of the present application are only introduced by way of example and do not represent actual use.
[0093] In one embodiment, a device for generating test cases of an interface is provided, and this generating device corresponds one-to-one with the method for generating test cases of the interface in the above embodiment. As Figure 7 shown, this generating device includes an obtaining module 710, a first generating module 720, a basic information obtaining module 730, a second generating module 740, and a third generating module 750. The detailed description of each functional module is as follows:
[0094] The obtaining module 710 is used to obtain the data format of the interface;
[0095] The first generating module 720 is used to generate an interface data specification for describing the data format according to the data format of the interface;
[0096] The basic information acquisition module 730 is configured to obtain the basic information for constructing the interface of the test request according to the specification corresponding to the data format;
[0097] The second generation module 740 is configured to generate interface input parameters and a test case description of the interface according to the basic information of the interface, and the test case description is used to describe the test purpose of the test request;
[0098] The third generation module 750 is configured to generate test cases according to the interface input parameters and the test case description of the interface.
[0099] In one embodiment, the first generation module 720 is specifically configured to:
[0100] Obtain the attribute information of each piece of data of the interface according to the data format of the interface;
[0101] Generate a specification for describing the attribute information of each piece of data to obtain a specification corresponding to the data format.
[0102] In one embodiment, the second generation module 740 is specifically configured to:
[0103] Generate various test requirements of the interface and the test case description corresponding to the test requirements according to the basic information of the interface;
[0104] Generate interface input parameters that meet the test requirements according to the basic information of the interface and the test requirements.
[0105] In one embodiment, the second generation module 740 is specifically configured to:
[0106] Generate the test steps of the interface according to the interface input parameters and the test case description of the interface, and generate the expected output of the interface;
[0107] Send a test request according to the test steps;
[0108] After sending the test request, obtain the actual output returned by the interface;
[0109] Compare the expected output and the actual output to obtain a test result;
[0110] Generate test cases according to the test steps, the expected output, the test request, the actual output, and the test result.
[0111] In one embodiment, the third generation module 750 is specifically configured to:
[0112] Obtain the project information corresponding to the interface;
[0113] Generate the preset information required when obtaining the test case according to the impact of the project information on the test case;
[0114] Generate a test case according to the interface input parameter, the use case description of the interface, and the preset information of the interface.
[0115] In one embodiment, the basic information of the interface includes the request method of the interface, the preconditions of the interface, the field definitions of the interface, and the structural form of the interface return data.
[0116] In one embodiment, the third generation module 750 is specifically configured to:
[0117] Generate the identity information of the interface;
[0118] Generate the interface input parameter and the use case description of the interface according to the basic information of the interface and the identity information of the interface, and both the interface input parameter and the use case description of the interface carry the identity information of the interface.
[0119] The present invention provides a device for generating a test case of an interface. After obtaining the data format of the interface, it can finally generate the interface input parameter and the use case description of the interface step by step. Then, based on the interface input parameter and the use case description, the required test case can be obtained. Obviously, in the process of generating the test case, only the data format of the interface itself needs to be concerned, and a series of information for generating the test case can be obtained. Compared with the related technology of uploading the interface to an external platform and using the external platform to generate the test case, the generation efficiency of the test case can be effectively improved.
[0120] For the specific limitations on the device for generating the test case of the interface, reference can be made to the limitations on the method for generating the test case of the interface in the above text, which will not be elaborated here. Each module in the above device for generating the test case of the interface can be implemented in whole or in part by software, hardware, and their combination. The above modules can be embedded in the processor of the computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to the above modules.
[0121] Based on the above method for generating the test case of the interface, as Figure 8 shown, an embodiment of the present invention further provides a schematic structural diagram of a device for generating a test case of an interface. The generating device includes a processor 81 and a memory 82 coupled to the processor 81. The memory 82 stores a computer program, and when the computer program is executed by the processor 81, the processor 81 is caused to execute the steps of the method for generating the test case of the interface in the above embodiment.
[0122] For other details of the implementation of the above technical solution by the processor 81 in the test case generation device for the above interface, reference may be made to the description in the method for generating test cases for the interface provided in the above invention embodiments, which will not be elaborated here.
[0123] Among them, the processor 81 can also be called a CPU (Central Processing Unit), and the processor 81 may be an integrated circuit chip with signal processing capabilities; the processor 91 can also be a general-purpose processor, DSP (Digital Signal Process), ASIC (Application Specific Integrated Circuit), FPGA (Field Programmable Gate Array), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The general-purpose processor can be a microprocessor, or the processor 81 can also be any conventional processor, etc.
[0124] As Figure 9 shown, the embodiment of the present invention also provides a schematic structural diagram of a computer-readable storage medium, on which a readable computer program 91 is stored; among them, the computer program 91 can be stored in the above storage medium in the form of a software product, including several instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of the methods described in various embodiments of the present invention. The foregoing storage medium includes: various media that can store program codes such as USB flash drives, mobile hard disks, magnetic disks or optical discs, ROM (Read-Only Memory), RAM (Random Access Memory), etc., or terminal devices such as computers, servers, mobile phones, and tablets.
[0125] In several embodiments provided by the present invention, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules is only a logical function division, and there can be other division methods in actual implementation. For example, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of the devices or modules can be in electrical, mechanical, or other forms.
[0126] The module described as a separation component may or may not be physically separated. The component shown as a module may or may not be a physical module, that is, it may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0127] In addition, each functional module in various embodiments of the present invention may be integrated into a processing module, may exist separately physically as individual modules, or two or more modules may be integrated into one module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of a software functional module. When the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium.
[0128] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product.
[0129] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present invention are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from a website, computer, server, or data center to another website, computer, server, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line) or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium, or a semiconductor medium (such as an SSD (solid state disk)).
[0130] The technical solutions provided by the present invention have been introduced in detail above. Specific examples are used in the present invention to elaborate on the principles and implementation manners of the present invention. The descriptions of the above embodiments are only used to help understand the method and its core idea of the present invention; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manners and application scopes. In summary, the content of this specification should not be construed as a limitation to the present invention.
[0131] Those skilled in the art will understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, optical storage, etc.) that contain computer-usable program code.
[0132] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to the present invention. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, can be realized by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate means for realizing the functions specified in one Figure 1 flow or multiple flows and / or blocks Figure 1 block or multiple blocks.
[0133] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured article including instruction means, and the instruction means realizes the functions specified in one Figure 1 flow or multiple flows and / or blocks Figure 1 block or multiple blocks.
[0134] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for realizing the functions specified in one Figure 1 flow or multiple flows and / or blocks Figure 1 block or multiple blocks.
[0135] Obviously, those skilled in the art can make various modifications and variations to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention also intends to include these modifications and variations.
Claims
1. A method for generating a test case for an interface, characterized in that: include: Get the data format of the interface; According to the data format of the interface, generating an interface data specification for describing the data format; According to the specification corresponding to the data format, basic information of the interface for constructing the test request is obtained; Generate interface input parameters and a test case description of the interface according to the basic information of the interface, wherein the test case description is used to describe the test purpose of the test request; Generate a test case based on the interface input parameters and the test case description of the interface.
2. The method for generating a test case for an interface according to claim 1, characterized in that: The step of generating an interface data specification for describing the data format according to the data format of the interface comprises: According to the data format of the interface, obtain the attribute information of the interface data; Generate a specification describing each attribute information of the data to obtain a specification corresponding to the data format.
3. The method for generating a test case for an interface according to claim 1, characterized in that: The step of generating interface input parameters and interface test case descriptions according to the basic information of the interface includes: Generate various test requirements of the interface and test case descriptions corresponding to the test requirements according to the basic information of the interface; Generate interface input parameters that meet the test requirements based on the basic information of the interface and the test requirements.
4. The method for generating a test case for an interface according to any one of claim 1, characterized in that: The generating of the test case according to the interface input parameter and the test case description of the interface includes: Generate test steps for the interface and expected output of the interface according to the interface input parameters and the test case description of the interface; According to the test steps, send a test request; After sending the test request, get the actual output returned by the interface; Comparing the expected output with the actual output to obtain a test result; A test case is generated according to the test steps, the expected output, the test request, the actual output and the test result.
5. The method for generating a test case for an interface according to any one of claim 1, characterized in that: The generating of a test case according to the interface input parameter and the use case description of the interface includes: Obtain project information corresponding to the interface; generating preset information required when obtaining the test case according to the influence of the project information on the test case; Generate a test case based on the interface input parameters, the use case description of the interface and the preset information of the interface.
6. The method for generating a test case for an interface according to claim 1, characterized in that: The basic information of the interface includes the request mode of the interface, the preconditions of the interface, the field definition of the interface and the structural form of the data returned by the interface.
7. The method for generating a test case for an interface according to claim 1, characterized in that: The step of generating interface input parameters and interface test case descriptions according to the basic information of the interface includes: Generate the identity information of the interface; According to the basic information of the interface and the identity information of the interface, interface input parameters and a test case description of the interface are generated, and both the interface input parameters and the test case description of the interface carry the identity information of the interface.
8. A device for generating test cases for an interface, characterized in that: include: The acquisition module is used to obtain the data format of the interface; A first generating module, used for generating an interface data specification for describing the data format according to the data format of the interface; A basic information acquisition module, used to obtain basic information of an interface for constructing a test request according to the specification corresponding to the data format; A second generating module is used to generate interface input parameters and a test case description of the interface according to the basic information of the interface, wherein the test case description is used to describe the test purpose of the test request; The third generation module is used to generate a test case according to the interface input parameters and the test case description of the interface.
9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method for generating a test case for the interface as claimed in any one of claims 1 to 7 are implemented.
10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method for generating a test case for the interface as claimed in any one of claims 1 to 7 are implemented.