Test case generation method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a test case generation method and device, electronic equipment and a storage medium. The method can be used in financial field. The method comprises the following steps: firstly, responding to a main request initiated by a user, and determining main request information corresponding to the main request; then, determining request data and response data of the sub-call triggered by the main request; then, according to the request data and the response data of the sub-calls, virtual mock data is generated; and finally, determining a first test case according to the mock data, the main request information and a preset variable replacement rule. The method is used for achieving the effect of generating a test case which is rich in use scene and wide in data coverage.

Description

Technical Field

[0001] The present application relates to the financial field, and in particular to a test case generation method, device, electronic device and storage medium. Background Art

[0002] Traffic recording and playback (referred to as traffic playback) mainly records the real business traffic in the production environment, replays it in the test environment or quasi-production environment after application iteration, and compares the returned results of the recorded and replayed interfaces to ensure that the functions of the tested application are not affected. During the traffic recording process, traffic-based use cases need to be generated.

[0003] The existing technology usually adopts the method of manually designing test cases, manually performing demand analysis and understanding, and manually setting test cases through understanding of functional requirements and business logic.

[0004] However, existing use case generation methods have problems such as limited scenarios and incomplete data coverage. Summary of the invention

[0005] The embodiments of the present application provide a test case generation method, device, electronic device and storage medium to achieve the effect of generating a test case with rich usage scenarios and wide data coverage.

[0006] In a first aspect, an embodiment of the present application provides a verification method for a business system, including:

[0007] In response to a main request initiated by a user, determining main request information corresponding to the main request;

[0008] Determine request data and response data of the sub-call triggered by the main request;

[0009] Generate virtual mock data according to the request data and response data of the subcall;

[0010] A first test case is determined according to the mock data, the main request information, and a preset variable replacement rule.

[0011] In one or more embodiments, determining the first test case according to the mock data, the main request information, and a preset variable replacement rule includes:

[0012] Extracting the mock data and the first variable in the main request information;

[0013] The first variable in the mock data and the main request information is replaced with the second variable in the variable replacement rule to obtain the first test case.

[0014] In one or more embodiments, the method further comprises:

[0015] The first test case is filtered according to a preset blacklist to obtain a second test case that meets the specification, wherein the blacklist records at least one of sensitive data, a preset request path, and a preset field.

[0016] In one or more embodiments, after determining the main request information corresponding to the main request in response to the main request initiated by the user, the method further includes:

[0017] An assertion rule is determined according to the main request information.

[0018] In one or more embodiments, after determining the first test case according to the mock data, the main request information, and the preset variable replacement rule, the method further includes:

[0019] A third test case is generated according to the first test case and the assertion rule.

[0020] In one or more embodiments, the method further comprises:

[0021] extracting at least one second variable in the first test case;

[0022] The at least one second variable is saved in a variable maintenance table.

[0023] In a second aspect, an embodiment of the present application provides a test case generation device, comprising:

[0024] A response module, configured to respond to a main request initiated by a user and determine main request information corresponding to the main request;

[0025] A first determination module, used to determine the request data and response data of the sub-call triggered by the main request;

[0026] A generation module, used to generate virtual mock data according to the request data and response data of the sub-call;

[0027] The second determination module is used to determine the first test case according to the mock data, the main request information, and the preset variable replacement rule.

[0028] In one or more embodiments, the second determining module is specifically configured to:

[0029] Extracting the mock data and the first variable in the main request information;

[0030] The first variable in the mock data and the main request information is replaced with the second variable in the variable replacement rule to obtain the first test case.

[0031] In one or more embodiments, the second determining module is further configured to:

[0032] The first test case is filtered according to a preset blacklist to obtain a second test case that meets the specification, wherein the blacklist records at least one of sensitive data, a preset request path, and a preset field.

[0033] In one or more embodiments, after determining the main request information corresponding to the main request in response to the main request initiated by the user, the first determining module is further configured to:

[0034] An assertion rule is determined according to the main request information.

[0035] In one or more embodiments, after determining the first test case according to the mock data, the main request information, and the preset variable replacement rule, the second determination module is further used to:

[0036] A third test case is generated according to the first test case and the assertion rule.

[0037] In one or more embodiments, the second determining module is further configured to:

[0038] extracting at least one second variable in the first test case;

[0039] The at least one second variable is saved in a variable maintenance table.

[0040] In a third aspect, an embodiment of the present application provides an electronic device, including:

[0041] a processor, and a memory communicatively connected to the processor;

[0042] The memory stores computer-executable instructions;

[0043] The processor executes the computer-executable instructions stored in the memory to implement the method described in the first aspect and any one of the embodiments above.

[0044] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the method described in the first aspect and any one of the embodiments.

[0045] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, is used to implement a method for generating test cases as described in the first aspect and various possible implementations of the first aspect.

[0046] The test case generation method, device, electronic device and storage medium provided in the embodiment of the present application, by responding to the main request initiated by the user, determines the main request information corresponding to the main request, then determines the request data and response data of the sub-call triggered by the main request according to the main request information corresponding to the main request, then generates virtual mock data according to the request data and response data of the sub-call, and finally determines the first test case according to the mock data, the main request information, and the preset variable replacement rule. In the above method, according to the main request information corresponding to the main request, the request data and response data of the sub-call triggered by the main request can be determined, ensuring that the request data of the sub-call is consistent with the data of the main request, avoiding errors caused by inconsistent data, then, according to the request data and response data of the sub-call, virtual mock data is generated, which can improve the coverage of the test scenario and improve the efficiency of test case generation, and finally, according to the mock data, the main request information, and the preset variable replacement rule, the first test case is determined, which can effectively improve the efficiency of the first test case generation, and at the same time, improve the stability of the test. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0048] Figure 1 Schematic diagram of the process of generating the test case provided in the embodiment of the present application Figure 1 ;

[0049] Figure 2 Schematic diagram of the process of generating the test case provided in the embodiment of the present application Figure 2 ;

[0050] Figure 3 Schematic diagram of the process of generating the test case provided in the embodiment of the present application Figure 3 ;

[0051] Figure 4 Schematic diagram of the process of generating the test case provided in the embodiment of the present application Figure 4 ;

[0052] Figure 5 A schematic diagram of the structure of a test case generation device provided in an embodiment of the present application;

[0053] Figure 6A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0054] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0055] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0056] First, the terms involved in this application are explained:

[0057] Transaction: refers to a program execution unit that accesses and possibly updates various data items in a database;

[0058] Assertions: refers to a first-order logic in a program (e.g., a logical judgment with a true or false result) used to verify whether the code meets the expectations of the coder;

[0059] HTTP status code: refers to the 3-digit code that indicates the status of the hypertext protocol response of the web server;

[0060] Virtual mock data: refers to a type of simulated data used in the software development process to simulate the data of the real data source, with similar data structure and fields. It is usually used when the real data is not available or cannot be obtained, so as to provide available virtual data during development, testing and demonstration;

[0061] Application Programming Interface (API): refers to the rules for communication between different parts of a software system;

[0062] JavaScript Object Notation (JSON): refers to an open standard file format and lightweight data exchange format;

[0063] Uniform Resource Identifiers (URI): refers to the unique identifier for locating resources on the Internet, pointing to a specific website, web page or document;

[0064] GET request: refers to a request to a specified resource, which contains the resource URL and request parameters;

[0065] POST request: refers to submitting data to a specified resource, which usually causes a change in the state of the server;

[0066] PUT request: refers to updating the specified resources on the server, and can modify the resources on the server.

[0067] Traffic recording and playback (hereinafter referred to as traffic playback) is a commonly used technical means in modern software testing, especially in the process of application iteration and upgrade, which can effectively verify the impact of the new version on the system function. Its core principle is to record real business traffic in the production environment and record every detail of the user's interaction with the system (such as interface requests, response data, session status, etc.). Then, these recorded traffic are imported into the test environment or quasi-production environment for replay, and the interface return results of the recorded traffic and the replayed traffic are compared to ensure that the original functions are not damaged in the iterative application version. In the process of traffic recording and playback, generating complete and effective test cases is a very critical step.

[0068] The prior art generally adopts a method of manually designing test cases, which manually analyzes the recorded traffic data and formulates test cases based on the data, or adopts a method of automated test generation, which analyzes the recorded traffic data and uses an automated test tool framework to automatically generate script cases.

[0069] However, existing test case generation methods suffer from insufficient scenario diversity and incomplete data coverage.

[0070] The test case generation method, device and storage medium provided in the present application are intended to solve the above technical problems of the prior art. The inventive concept of the present application is as follows: First, for the main request information corresponding to the main request initiated by the user, the request data and response data of the sub-call triggered by the main request are confirmed. By extracting information from the main request, the sub-request data can be derived, reducing the workload of manually writing test cases. By generating virtual mock data according to the request and response data of the sub-call, it is possible to avoid relying on the real back-end service environment for testing, thereby improving the efficiency of test case generation, and then speeding up the test. At the same time, through the generated virtual mock data, various different test scenarios can be covered. Finally, the first test case can be determined according to the mock data, the main request information, and the preset variable replacement rules, thereby improving the generation efficiency of the first test case, and the obtained first test case has good stability in the test.

[0071] It should be noted that the test case generation method, device, electronic device and storage medium provided in the present application can be used in the financial field, and can also be used in any field other than the financial field. The application field of the test case generation method, device, electronic device and storage medium provided in the present application is not limited.

[0072] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0073] Figure 1 Schematic diagram of the process of generating a test case provided in the embodiment of the present application Figure 1 ,like Figure 1 As shown, the method includes:

[0074] S101. In response to a main request initiated by a user, determine main request information corresponding to the main request.

[0075] In this step, first, the user initiates a main request, then the main request is parsed, and then the main request information corresponding to the main request initiated by the user is determined.

[0076] Among them, the main request refers to the core request initiated by the user, corresponding to the user's initial behavior or operation, and the main request information refers to the core information for processing the request.

[0077] In a possible implementation, the main request information may include an identifier of the main request, request parameters of the main request, a calling interface of the main request, and the time of the main request. After responding to the main request initiated by the user, the data of the main request is first read. The data may be captured through a certain network request or interface call record. Specifically, the type of the main request is identified. Different types of main requests may carry different information and data, and implement different functions. Then, according to the path of the main request, the target resource or service interface of the main request can be determined. At the same time, key information such as the request header and request parameters are extracted and recorded from the main request as a basis for subsequent judgment and analysis. Finally, the main request information corresponding to the main request is determined according to the data of the main request. The main request information includes: an identifier of the main request, which is used to uniquely identify the main request, which may be a request ID or a transaction ID related to the request; request parameters of the main request, including all query parameters of the main request, request body content, user session information, etc.; calling interface of the main request, that is, the specific interface name or path called by the main request; main request time, that is, the timestamp of the interface call, which is used to track and determine whether the request has timed out or meets the timeliness requirements.

[0078] In a possible implementation manner, after the above step S101, the method further includes: determining an assertion rule according to the main request information.

[0079] Among them, the assertion rule refers to a specific rule that sets the execution condition to be true during the execution of the main request, and is used to verify whether the assumptions in the execution of the main request are valid.

[0080] In a possible implementation, the above-mentioned determination of assertion rules based on the main request information can be to analyze possible assertion rules based on the main request information. For example, verify whether the request parameters of the main request conform to a specific format, verify whether the path of the main request is correct; verify the legitimacy of the request data; verify whether the required parameters of the main request are passed and whether the parameter values ​​of the main request are valid (such as regular expression check); verify whether the interface returns within the specified time (for example, the response time should be less than 2 seconds); verify whether the HTTP status code returned by the interface conforms to expectations (for example, 200 indicates success); verify whether the data returned by the interface conforms to the expected format and contains the expected fields, etc.

[0081] S102: Determine the request data and response data of the sub-call triggered by the main request.

[0082] In this step, first, when the main request starts to execute, an interface call is made, and according to the sub-call triggered by the main request, the data record obtained by the sub-call is read to determine the request data and response data of the sub-call triggered by the main request in the data record.

[0083] Among them, the sub-call refers to the interface call triggered by the main request for further communication with other services or interfaces, the request data of the sub-call refers to the data sent in the sub-call, and the response data of the sub-call refers to the data returned by the sub-call.

[0084] In a possible implementation, the request data and response data of the sub-call triggered by the main request can be the request data and response data of the sub-call recorded using a log. When the main request is executed, the main interface is called, and when the main request triggers an operation, multiple sub-calls are usually triggered, that is, the main request will rely on other services or components to complete some tasks (such as database queries, external API requests, etc.). These sub-calls can be synchronous calls (such as REST API calls, database queries) or asynchronous calls (such as message queues, background tasks). The request data and response data of the sub-call triggered by the main request are recorded according to the log of the sub-call, where the request data of the sub-call can include the address of the target service, the request header, the request body, etc., and the response data of the sub-call can include the return code, the response body, etc.

[0085] S103: Generate virtual mock data according to the request data and response data of the sub-call.

[0086] In this step, the specific structure of the request is determined according to the request data of the sub-call, and the specific structure of the response is determined according to the response data of the sub-call, and finally virtual mock data is generated.

[0087] The virtual mock data refers to simulated data similar to the actual response structure generated according to the specific structure of the sub-call request and the specific structure of the sub-call response.

[0088] In a possible implementation, the response data (such as JSON object) of the subcall is extracted, and the response structure is designed according to the response data of the subcall, which may include the response status code, the response body content, etc., and virtual mock data similar to the actual response structure is generated as needed. For example, if a field is dynamically generated, random values, fake data or fixed patterns can be used to generate mock data.

[0089] S104: Determine a first test case according to the mock data, the main request information, and a preset variable replacement rule.

[0090] In this step, variable replacement rules are pre-set, and according to the variables involved in the mock data and the main request information, the variables are replaced according to the variable replacement rules, thereby determining the first test case.

[0091] The variable replacement rule refers to a rule for replacing the variable content in the main request with different content.

[0092] In a possible implementation, the above-mentioned determination of the first test case may be to define the test target, that is, to verify whether the function of a certain interface or system meets expectations, and then determine the interface path of the main request to be sent, the mode of the main request, and the parameters of the main request according to the main request information. Different test targets and test scenarios may correspond to different variables, so it is necessary to determine the variables that need to be replaced in the test according to the specific test targets and test scenarios, replace the variables according to the preset variable replacement rules, and generate the first test case based on the mock data and the corresponding interface response.

[0093] Further, the first test case is filtered according to a preset blacklist to obtain a second test case that meets the specification;

[0094] The blacklist records at least one of sensitive data, a preset request path, and a preset field.

[0095] In this step, a blacklist is preset, and the first test case is filtered according to the specific content of the preset blacklist, and the filtered first test case meets the specification, and the second test case that meets the specification is further obtained.

[0096] Among them, sensitive data refers to data records with sensitive content, the preset request path refers to a specific path that is preset and does not allow request execution, and the preset field refers to a field that does not comply with the specification.

[0097] In a possible implementation, the preset request path may be a request path without access rights, and the preset field may be a field containing sensitive information or privacy information. According to the preset blacklist, the first test case is filtered, and the preset request path in the blacklist may be replaced with a safe and effective request path, and the sensitive data and preset fields in the blacklist may be hidden or replaced with simulated values.

[0098] In a possible implementation, after the above step S104, the method further includes: generating a third test case according to the first test case and the assertion rule.

[0099] In this step, the specific information of the first test case and the specific content of the assertion rule are determined, and after the assertion rule is passed, the third test case is generated.

[0100] In a possible implementation, the third test case can be generated by expanding or changing the first test case. According to the specific content of the first test case, it can be the variables or execution conditions involved in the first test case, and the variables or execution conditions can be asserted through assertion rules, and the variables or execution conditions that meet the expectations are retained, and the variables or execution conditions that do not meet the expectations are deleted.

[0101] The method for generating a test case provided by an embodiment of the present application first determines the main request information corresponding to the main request by responding to the main request initiated by the user, then determines the request data and response data of the sub-call triggered by the main request according to the main request information corresponding to the main request, then generates virtual mock data according to the request data and response data of the sub-call, and finally determines the first test case according to the mock data, the main request information, and the preset variable replacement rule. In this embodiment, first, the main request is initiated by the user, and the request data and response data of the sub-call triggered by the main request can be determined according to the main request information corresponding to the main request, thereby improving the accuracy and efficiency of the request processing, and then, according to the request data and response data of the sub-call, virtual mock data is generated, and different test environments can be covered by the generated virtual mock data, and the first test case can be ensured to be stably tested in different test environments, and at the same time, the first test case is determined according to the mock data, the main request information, and the preset variable replacement rule, so as to ensure the diversity of the generated first test case, thereby meeting the needs of different multiple test scenarios.

[0102] Based on the above embodiments, Figure 2 Schematic diagram of the process of generating a test case provided in the embodiment of the present application Figure 2 ,like Figure 2 As shown, a possible implementation of the above step S104 includes the following steps:

[0103] S201, extracting the first variable in the mock data and the main request information.

[0104] In this step, the first variable included in the mock data is determined, and the first variable included in the main request information is determined, and then the first variables in the mock data and the main request information are extracted.

[0105] In a possible implementation, the main request information includes request data and response data of the main request, and the first variable included in the request data of the main request is searched and the first variable is extracted. At the same time, the first variable included in the response data of the main request is searched and the first variable is extracted and processed, and the first variable in the mock data is extracted.

[0106] For example, the request data of the main request contains the fields ("name1": 1; "age1": 13), the response data of the main request contains the fields ("status1": success; "name1": 1), and the mock data contains the fields ("password1": 10001; "id1": 005), then the first variable extracted from the mock data and the main request information is ("name1"; "age1"; "status1"; "password1"; "id1")

[0107] S202: Replace the first variable in the mock data and the main request information with the second variable in the variable replacement rule to obtain a first test case.

[0108] In this step, according to the specific content of the variable replacement rule, the first variable in the mock data and the main request information is replaced according to the variable replacement rule, and replaced with the corresponding second variable in the corresponding variable replacement rule, and the first test case is obtained based on the second variable.

[0109] In one possible implementation, the variable replacement rule may be to replace the value of the first variable accordingly according to the actual needs of different test scenarios. For example, according to the change of the time when the request is initiated, the value of the time variable is replaced with the value at the current moment; according to the change of the user who initiates the request, the user ID is replaced with the user ID that actually initiates the request.

[0110] For example, when the time when the request is initiated changes, the value of the time variable "time" is replaced from the previous moment "t1" to the current moment "t2"; when the user making the request changes, the value of the user ID "user" variable is replaced from the previous user ID "u1" to the currently logged-in user ID "u2".

[0111] The test case generation method provided in the embodiment of the present application obtains the first test case by extracting the first variable in the mock data and the main request information, and then replacing the first variable in the mock data and the main request information with the second variable in the variable replacement rule. In this embodiment, the first variable in the mock data and the main request information is firstly extracted, and efficient testing can be performed in the local test environment according to the first variable to reduce the consumption of test resources, and then the first variable in the mock data and the main request information is replaced with the second variable in the variable replacement rule to obtain the first test case, and the first variable can be replaced with the second variable that complies with the variable rule according to the variable replacement rule, and can be adjusted according to the specific test scenario, thereby realizing the generation of the first test case for multiple scenarios.

[0112] Based on the above embodiments, Figure 3 Schematic diagram of the process of generating a test case provided in the embodiment of the present application Figure 3 ,like Figure 3 As shown, the test case generation method also includes the following steps:

[0113] S301. Extract at least one second variable in a first test case.

[0114] In this step, a first test case is determined, a second variable in the first test case is identified, and then at least one second variable in the first test case is extracted.

[0115] In a possible implementation, at least one second variable involved in the specific information and specific content corresponding to the second variable can be identified based on the specific information of the first test case, and the identified at least one second variable and specific content corresponding to the second variable can be extracted.

[0116] In the first test case, there are three second variables, namely "user_id", "username", and "auth_token", and the first test case has a variable maintenance table, which provides the actual content of the second variables, among which the actual content of "user_id" is 123, the actual content of "username" is user1, and the actual content of "auth_token" is xyz456. Then, at least one second variable in the first test case can be extracted, such as extracting one of the second variables "username" and the corresponding actual content user1.

[0117] S302: Save at least one second variable to a variable maintenance table.

[0118] In this step, a variable maintenance table is preset, and the extracted at least one second variable is saved in the variable maintenance table.

[0119] The variable maintenance table refers to a table consisting of variables and specific contents corresponding to the variables.

[0120] In a possible implementation, the variable maintenance table may be in the form of a key-value pair, each variable is marked with a unique identifier, and each variable has corresponding specific content, and the variable can be identified according to the variable identifier and the specific content of the variable can be replaced or modified. The specific content of the variable can be replaced or modified by using curly brackets to represent placeholders, using specific symbols to mark, or using a key-value pair format to identify.

[0121] The test case generation method provided in the embodiment of the present application extracts at least one second variable in the first test case and saves at least one second variable to the variable maintenance table. In this embodiment, by extracting at least one second variable in the first test case and saving at least one second variable to the variable maintenance table, the second variables used in the first test case can be conveniently and centrally managed, thereby improving the maintenance efficiency of the test case. At the same time, based on the variable maintenance table, the value of the second variable can be adaptively adjusted, so that the test case can cover multiple data values, thereby increasing the comprehensiveness of the test.

[0122] Based on the above embodiments, Figure 4 The process of generating a test case provided in the embodiment of the present application Figure 4 .like Figure 4 As shown, a possible implementation of the method includes the following steps:

[0123] S401, reading the calling interface in the main request;

[0124] In this step, the main request is parsed, and the calling interface information is extracted by reading the data of the main request. The data of the main request can be captured through some network request or interface call record.

[0125] The main request may be an HTTP request, which includes a request header, a request body, and a request method (such as GET, POST, etc.). The request method refers to which HTTP method is used for the request. If it is a POST request, there is usually a request body and request parameters.

[0126] S402, according to the main request calling interface, identifying and recording the request information in the main call corresponding to the main request;

[0127] In a possible implementation, the request information recorded in the main call corresponding to the main request may be recorded in the main request: interface name, that is, the specific interface name or path called by the main request; request method, such as GET, POST, PUT, etc.; request parameters, that is, all parameters passed into the interface (including URL parameters, request body parameters); request header, such as authorization information, content type, accepted data type, etc.; request time, that is, the timestamp of the interface call; record format, that is, recording the request information in a preset format, usually stored in JSON, XML or database format.

[0128] S403, analyzing and setting assertion rules according to the request information in the main call corresponding to the main request;

[0129] In a possible implementation, possible assertion conditions can be analyzed based on the content in the main request, for example, verifying whether the request parameters conform to a specific format, verifying whether the path in the URL is correct, verifying the legitimacy of the request data, for example, verifying whether the required parameters are passed, whether the parameter values ​​are valid, and verifying whether the interface returns within the specified time.

[0130] S404, triggering a sub-request by the main request and identifying request data and return data in the sub-call corresponding to the sub-request;

[0131] In a possible implementation, further communication with other services or interfaces is triggered by the main request, that is, the sub-request corresponds to the sub-call. The request data for identifying the sub-request corresponding to the sub-call may be the interface path, request method, request parameters, etc. for reading the sub-request; the response data for identifying the sub-request corresponding to the sub-call may be the response data for obtaining the sub-call, which is usually JSON or XML data returned by the interface.

[0132] S405, generate mock data according to the request data and response data of the sub-call;

[0133] In a possible implementation, the request data and response data of the subcall are extracted, and simulated data similar to the actual response structure is generated according to the actual test needs. For example, if a field is dynamically generated, random values, fake data, or fixed patterns can be used to generate simulated data, and some data transformation rules may need to be set, such as dynamically replacing timestamps, generating random IDs, etc.

[0134] S406, setting variable replacement, variable extraction and rule judgment based on the generated mock data;

[0135] Among them, variable replacement refers to replacement based on the extracted variables, such as dynamically replacing the placeholder of the variable with an actual value in the generated mock data.

[0136] Variable extraction refers to extracting required variables from request data and response data according to the test scenario, and generating a variable maintenance table according to the variables in the request data and response data.

[0137] Rule judgment refers to judging whether the data meets expectations based on the rules. For example, adjusting the format of the field value according to requirements, or extracting new data from the returned data and replacing the original data.

[0138] S407. For the data that has undergone variable replacement, variable extraction, and rule judgment, set blacklist and whitelist rules, generate, and save test cases.

[0139] In a possible implementation, a blacklist and whitelist check is performed on the recorded request and response data to filter out requests that do not meet the specifications, wherein the blacklist and whitelist can be whitelist and blacklist rules for setting interface requests. For example, some requests should not contain specific sensitive data or request paths, or some response fields need to be filtered. The blacklist can be request / response data that does not meet expectations (such as illegal requests, sensitive fields). The whitelist can be data that meets the specified standards and rules.

[0140] Furthermore, when multiple main requests need to be executed, after the current main request is executed, the currently generated variable list will be used as the input of the next request, and the above steps will be continued until all main requests are executed or terminated due to traffic playback failure.

[0141] Among them, the test case generated by the first main request is actually applied and managed in the test scenario. After the traffic replay of the use case of the first main request is successfully implemented, its variable maintenance table is passed to the next main request. If the traffic replay fails, the execution of the next main request is terminated in sequence.

[0142] The method for generating test cases provided in the embodiment of the present application reads the calling interface in the main call, records the request information in the main call, sets the assertion rules, and then identifies it according to the content in the sub-call, generates mock data according to the request data and return data in these sub-calls, and finally generates test cases through rule judgments such as variable replacement and setting black and white list rules. In this embodiment, information is extracted from the main request and sub-request, analyzed, mock data is generated, variables are replaced, and rules are judged, and finally the processed use case data is filtered and saved through the black and white list, which ensures the correctness and testability of the interface call, and supports the generation of multi-scenario test cases.

[0143] Based on the above embodiments, the following are device embodiments involved in this application:

[0144] Figure 5 A schematic diagram of the structure of the test case generation device provided in this application, such as Figure 5 As shown, the test case generation device 50 provided in this embodiment includes:

[0145] A response module 501 is used to respond to a main request initiated by a user and determine main request information corresponding to the main request;

[0146] A first determination module 502, used to determine the request data and response data of the sub-call triggered by the main request;

[0147] A generating module 503 is used to generate virtual mock data according to the request data and response data of the sub-call;

[0148] The second determination module 504 is used to determine the first test case according to the mock data, the main request information, and the preset variable replacement rule.

[0149] In an optional embodiment, the second determining module 504 is specifically configured to:

[0150] Extract the first variable in the mock data and the main request information;

[0151] The first variable in the mock data and the main request information is replaced with the second variable in the variable replacement rule to obtain a first test case.

[0152] In an optional embodiment, the second determining module 504 is further configured to:

[0153] The first test case is filtered according to a preset blacklist to obtain a second test case that meets the specification, wherein the blacklist records at least one of sensitive data, a preset request path, and a preset field.

[0154] In an optional embodiment, after determining the main request information corresponding to the main request in response to the main request initiated by the user, the first determining module 502 is further configured to:

[0155] Determine the assertion rules based on the main request information.

[0156] In an optional embodiment, after determining the first test case according to the mock data, the main request information, and the preset variable replacement rule, the second determination module 504 is further used to:

[0157] A third test case is generated according to the first test case and the assertion rule.

[0158] In an optional embodiment, the second determining module 504 is further configured to:

[0159] extracting at least one second variable in the first test case;

[0160] At least one second variable is saved in the variable maintenance table.

[0161] The test case generation device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and this embodiment will not be described in detail here.

[0162] Based on the above embodiments, Figure 6 This is a schematic diagram of the structure of the electronic device provided in this application. Figure 5 As shown, the electronic device 60 provided in this embodiment includes: at least one processor 601 and a memory 602. Optionally, the device 60 also includes a communication component 603. The processor 601, the memory 602 and the communication component 603 are connected via a bus 604.

[0163] In a specific implementation process, at least one processor 601 executes the computer execution instructions stored in the memory 602, so that at least one processor 601 executes the above method.

[0164] The specific implementation process of the processor 601 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.

[0165] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0166] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (Non-volatile Memory, NVM), such as at least one disk memory.

[0167] The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application is not limited to only one bus or one type of bus.

[0168] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0169] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0170] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0171] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0172] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0173] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0174] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0175] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0176] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0177] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses or adaptations of the present invention, which follow the general principles of the present invention and include common knowledge or customary technical means in the art not disclosed by the present invention, are not limited to the precise structure described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A method for generating a test case, characterized in that: include: In response to a main request initiated by a user, determining main request information corresponding to the main request; Determine request data and response data of the sub-call triggered by the main request; Generate virtual mock data according to the request data and response data of the subcall; A first test case is determined according to the mock data, the main request information, and a preset variable replacement rule.

2. The method according to claim 1, characterized in that Determining a first test case according to the mock data, the main request information, and a preset variable replacement rule includes: Extracting the mock data and the first variable in the main request information; The first variable in the mock data and the main request information is replaced with the second variable in the variable replacement rule to obtain the first test case.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: The first test case is filtered according to a preset blacklist to obtain a second test case that meets the specification, wherein the blacklist records at least one of sensitive data, a preset request path, and a preset field.

4. The method according to claim 1 or 2, characterized in that: After determining the main request information corresponding to the main request in response to the main request initiated by the user, the method further includes: An assertion rule is determined according to the main request information.

5. The method according to claim 4, characterized in that After determining the first test case according to the mock data, the main request information, and the preset variable replacement rule, the method further includes: A third test case is generated according to the first test case and the assertion rule.

6. The method according to claim 2, characterized in that The method further comprises: extracting at least one second variable in the first test case; The at least one second variable is saved in a variable maintenance table.

7. A test case generation device, characterized in that: include: A response module, configured to respond to a main request initiated by a user and determine main request information corresponding to the main request; A first determination module, used to determine the request data and response data of the sub-call triggered by the main request; A generation module, used to generate virtual mock data according to the request data and response data of the sub-call; The second determination module is used to determine the first test case according to the mock data, the main request information, and the preset variable replacement rule.

8. An electronic device, characterized in that: include: a processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 6 when executed by a processor.

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

Images