Test case generation method and device, equipment and storage medium

Abstract

The embodiment of the invention provides a test case generation method and device, equipment and a storage medium, relates to the technical field of computers, is suitable for a test system, and comprises the following steps: screening a target request data set of each service module from each historical service data processed by a service system based on a preset parameter screening rule, the target request data comprises a request mode, a request parameter and a request processing result of a corresponding service module in a service request process, and for each piece of target request data associated with each service module, the following steps are respectively executed; the method comprises the steps of determining a preset rule template corresponding to a data type of a request processing result, setting the request processing result into the rule template, obtaining a verification rule, and obtaining a test case based on a request mode and request parameters in combination with the verification rule, so as to reduce the writing cost of the test case, improve the coverage rate of the test case on a use scene, and improve the test efficiency. The operation and maintenance efficiency is improved.

Description

Technical Field

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

[0002] Test case, also known as use case for short, is a description of how a system responds to external requests in software engineering or system engineering. It is a technique to obtain test requirements by using the usage scenarios of the objects. Each use case provides one or more usage scenarios, which can explain how the system interacts with the objects or other systems.

[0003] In related technologies, the method of manually writing use cases is generally adopted. For different usage scenarios of the business system, corresponding test cases are written to test the business processing performance of the business modules corresponding to the usage scenarios, and the business system is operated and maintained based on the obtained test results. Although this method can improve the operation and maintenance efficiency of the business system, it has high requirements on the professional ability of the development object of writing test cases. The reason is that in large-scale business systems, other subsystems are generally integrated with the development and change of the business, and the computer languages ​​used by these subsystems are likely to be different from the computer languages ​​used by the business system. This requires the development object of writing test cases to be proficient in using multiple computer languages ​​and have very high professional ability to maintain the normal operation of business systems with multiple computer languages. In actual applications, such development objects are extremely rare.

[0004] On the other hand, large business systems usually contain many business modules. In actual applications, not only can individual business modules realize usage scenarios, but business modules can also realize more usage scenarios through series and parallel connection. This leads to thousands of usage scenarios in some large business systems. However, the actual manual writing of use cases requires time and labor costs, and only a few hundred use cases can be written at most, which limits the improvement of the operation and maintenance efficiency of the business system. The reliability of the use scenarios without corresponding use cases in the business system cannot be guaranteed, and the business system is generally updated with business needs, so the use cases also need to be updated with the update of the business system, which will bring a serious burden to the subsequent operation and maintenance work.

[0005] Therefore, there is an urgent need to redesign a test case generation method and overcome the above defects. Summary of the invention

[0006] The embodiments of the present application provide a test case generation method, device, electronic device and storage medium to reduce the test case writing cost, increase the coverage of test cases for usage scenarios in business systems, and improve the business system operation and maintenance efficiency.

[0007] In a first aspect, an embodiment of the present application provides a test case generation method applicable to a test system, the method comprising:

[0008] Based on the preset parameter screening rules, a target request data set of each business module is screened out from each historical business data processed by the business system, wherein the target request data at least includes: a request method, request parameters and request processing result of the corresponding business module in a business request process; wherein the request method and the request parameters conform to the parameter screening rules;

[0009] For each target request data associated with each business module, perform the following steps respectively:

[0010] Based on a target request data of a business module, determine the data type of the request processing result contained in the target request data, obtain a rule template preset corresponding to the data type, and set the request processing result to the rule template to obtain a corresponding verification rule, wherein the verification rule is used to verify the execution result of the business logic of the business module;

[0011] Based on the request mode and request parameters of the target request data and in combination with the verification rules, a corresponding test case is obtained.

[0012] In a second aspect, an embodiment of the present application provides a test case generation device, which is applicable to a test system, and the device includes:

[0013] A data screening unit, configured to screen out a target request data set of each business module from each historical business data processed by the business system based on a preset parameter screening rule, wherein the target request data at least includes: a request method, request parameters and request processing result of the corresponding business module in a business request process; wherein the request method and the request parameters conform to the parameter screening rule;

[0014] The processing unit is used to perform the following steps for each target request data associated with each business module:

[0015] A rule generation unit, configured to determine, based on a target request data of a business module, a data type of a request processing result contained in the target request data, obtain a rule template preset corresponding to the data type, and set the request processing result to the rule template to obtain a corresponding verification rule, wherein the verification rule is used to verify the execution result of the business logic of the business module;

[0016] The use case generation unit is used to obtain a corresponding test case based on the request mode and request parameters of the target request data in combination with the verification rule.

[0017] Optionally, the use case generation unit is specifically used to obtain a corresponding test case based on the request method and request parameters of the target request data in combination with the verification rules and supplementary verification rules, and the supplementary verification rules are used to verify the data format of the corresponding request processing result.

[0018] Optionally, the processing unit is further configured to:

[0019] Sending the test case to the business system so that the management system obtains the test case and case information from the business system, wherein the case information includes a module name of the business module corresponding to the test case, a case identifier, and module names of other business modules associated with the corresponding business module;

[0020] The test case and the case information are displayed on a management page by the management system, so that the management system generates a scenario case group in response to a case selection operation and a case group generation operation, wherein the scenario case group includes a plurality of scenario test cases with a set execution order, and each scenario test case in the scenario case group corresponds to a business module, which is used to complete a processing process of a business scenario according to the set execution order;

[0021] The scenario use case group is sent to the business system through the management system.

[0022] Optionally, the processing unit is further configured to:

[0023] By means of the management system, the scenario use case group is displayed on a use case group page, so that the management system generates a change scenario use case group in response to the setting address operation;

[0024] The setting address operation is used to set a setting storage address in the change scenario use case group, so that when the change scenario use case group is executed, the setting request data in the upstream scenario test case that has been executed in the scenario use case group is stored in the setting storage address, and the downstream scenario test case in the scenario use case group obtains the setting request data from the setting storage address and executes it;

[0025] The change scenario use case group is sent to the business system through the management system.

[0026] Optionally, the data screening unit is further used to:

[0027] Based on the data screening rule, the historical business data are screened from the initial business data, and the data screening rule is: the business request process is complete and the execution status is a success status.

[0028] Optionally, the data screening unit is specifically used to:

[0029] For each of the business modules, perform the following steps respectively:

[0030] Extracting data parts that meet the parameter screening rules from each historical business data associated with a business module as corresponding historical request data;

[0031] Based on the obtained multiple historical request data, statistics are generated on the application of at least one existing request mode and request parameter, wherein the application includes: at least one of the value range of the request parameter with continuous values, the enumeration of the request parameter with discrete values ​​in the multiple historical request data, and the combination of multiple request parameters in one service request;

[0032] Based on the at least one request mode and the application situation, non-repetitive target request data are screened out from the plurality of historical request data to obtain a target request data set of the one business module.

[0033] Optionally, the data screening unit is specifically used to:

[0034] For each historical business data associated with the business module, perform the following operations respectively:

[0035] Extract a request data packet and a corresponding response data packet from a historical business data;

[0036] Filtering out the request mode and request parameters that meet the parameter screening rule from the packet header and the packet body of the request data packet respectively;

[0037] Filtering out request processing results that meet the parameter screening rules from the packet header and the packet body of the response data packet;

[0038] The obtained request method, request parameters and request processing results are used as historical request data.

[0039] Optionally, the data screening unit is further used to screen out new request data of a target business module from the latest business data processed by the business system based on the parameter screening rule, where the target business module is a business module that has existed in the business system from the beginning or a newly added business module;

[0040] The rule generation unit is further used to determine, based on the newly added request data of the target business module, the data type of the newly added processing result contained in the newly added request data, obtain a rule template preset corresponding to the data type of the newly added processing result, and set the newly added processing result to the rule template to obtain a corresponding newly added verification rule, wherein the newly added verification rule is used to verify the execution result of the business logic of the target business module;

[0041] The use case generation unit is also used to obtain corresponding new test cases based on the request mode and request parameters of the new request data in combination with the new verification rules.

[0042] Optionally, the use case generation unit is specifically used to:

[0043] Based on the request mode and request parameters of the target request data, combined with the verification rules and the preset protocol path, a corresponding test case is obtained. When the test case is executed, the preset protocol path is used to obtain the preset protocol from the business system and convert the test request generated by the test case into a format recognizable by the corresponding business module.

[0044] In a third aspect, an embodiment of the present application provides a computer device, comprising a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes any one of the test case generation methods in the first aspect above.

[0045] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which includes a computer program. When the computer program is run on a computer device, the computer program is used to enable the computer device to execute any one of the test case generation methods in the first aspect above.

[0046] In a fifth aspect, an embodiment of the present application provides a computer program product, which includes a computer program stored in a computer-readable storage medium; when a processor of a computer device reads the computer program from the computer-readable storage medium, the processor executes the computer program, so that the computer device executes any one of the test case generation methods in the above-mentioned first aspect.

[0047] The beneficial effects of this application are as follows:

[0048] The test case generation method, device, computer equipment and storage medium provided in the embodiment of the present application are applicable to the test system, including: the test system is provided with parameter screening rules, which can analyze the historical business data processed from the business system and screen out the historical request data set of each business module. That is to say, according to the request mode, request parameters and request processing results required by the test case, the parameter screening rules are designed, and the parameter screening rules are pre-set in the test system, so that the test system can automatically screen the historical request data of each business module from the historical business data of the business system. At this point, the data required for generating the test case has been obtained. Further, for the data type of the request processing result in each historical request data of each business module, the corresponding preset rule template is obtained, and the request processing result is set in the rule template to obtain the corresponding verification rule, so as to combine the request mode, request parameters and the corresponding verification rules obtained in the historical request data to obtain the test case.

[0049] From this, it can be seen that by using this method to analyze historical traffic and extract request data required for test cases, not only can test cases be automatically generated, but also request data from all historical usage scenarios of each business module in the business system can be automatically obtained. Based on the large amount of request data with high usage scenario coverage, a large number of test cases can be automatically generated, which effectively solves the problems in related technologies of high professional ability requirements for test case development objects, high test case writing costs, and low coverage of business system usage scenarios by manually written test cases.

[0050] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, the drawings described below are only the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0052] Figure 1 An optional schematic diagram of an application scenario provided in an embodiment of the present application;

[0053] Figure 2 An optional schematic diagram of another application scenario provided in an embodiment of the present application;

[0054] Figure 3 A flowchart of a test case generation method provided in an embodiment of the present application;

[0055] Figure 4 A flowchart of a method for obtaining a scenario use case group provided in an embodiment of the present application;

[0056] Figure 5 An optional schematic diagram of another application scenario provided in an embodiment of the present application;

[0057] Figure 6 An optional schematic diagram of another application scenario provided in an embodiment of the present application;

[0058] Figure 7 A schematic diagram of a use case management list page in a management page provided in an embodiment of the present application;

[0059] Figure 8 A schematic diagram of a use case management details page in a management page provided in an embodiment of the present application;

[0060] Fig. 9 A schematic diagram of a use case list page of a business module in a management page provided in an embodiment of the present application;

[0061] Fig.10 A schematic diagram of an update use case details page in a management page provided in an embodiment of the present application;

[0062] Fig.11 A schematic diagram of a use case group details page in a management page provided in an embodiment of the present application;

[0063] Fig.12 A schematic diagram of a use case group generation page in a management page provided in an embodiment of the present application;

[0064] Fig.13 A flow chart of a method for generating a change scenario use case group provided in an embodiment of the present application;

[0065] Fig.14 A schematic diagram of parameter and module dependency provided for an embodiment of the present application;

[0066] Fig.15 A schematic diagram of a method for obtaining parameters between test cases in a scenario test case group provided in an embodiment of the present application;

[0067] Fig.16 A schematic diagram of a method for obtaining parameters between test cases in a scenario test case group provided in an embodiment of the present application;

[0068] Fig.17A flowchart of a method for obtaining target request data provided by an embodiment of the present application;

[0069] Fig.18 A flowchart of a method for obtaining historical request data provided in an embodiment of the present application;

[0070] Fig.19 A schematic diagram of the structure of a request data packet provided in an embodiment of the present application;

[0071] Fig. 20 A schematic diagram of the structure of a response data packet provided in an embodiment of the present application;

[0072] Fig.21 A schematic diagram of a method for configuring relevant information of a test case provided in an embodiment of the present application;

[0073] Fig. 22 A schematic diagram of the architecture of a business system in a server provided in an embodiment of the present application;

[0074] Fig.23 An optional schematic diagram of another application scenario provided in an embodiment of the present application;

[0075] Fig.24 A schematic diagram of a test case generation device provided in an embodiment of the present application;

[0076] Fig.25 A schematic diagram of a hardware structure of a computer device to which an embodiment of the present application is applied;

[0077] Fig.26 A schematic diagram of the hardware composition structure of another computer device to which the embodiment of the present application is applied. DETAILED DESCRIPTION

[0078] In order to make the purpose, technical scheme and advantages of the present application clearer, the technical scheme in the embodiment of the present application will be clearly and completely described below in conjunction with the drawings in the embodiment of the present application. Obviously, the described embodiment is only a part of the embodiment of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application. In the absence of conflict, the embodiments in the present application and the features in the embodiments can be combined with each other arbitrarily. In addition, although the logical order is shown in the flow chart, in some cases, the steps shown or described can be performed in an order different from that here.

[0079] It is understandable that in the following specific implementations of the present application, data related to request methods, request parameters, and request processing results are involved. When the various embodiments of the present application are applied to specific products or technologies, relevant licenses or consents need to be obtained, and the collection, use, and processing of relevant data need to comply with relevant laws, regulations, and standards of relevant countries and regions. For example, when it is necessary to obtain relevant data, you can recruit relevant volunteers and sign relevant agreements for volunteer authorization data, and then use the data of these volunteers for implementation; or, by implementing it within the scope of the authorized organization, use the data of internal members of the organization to implement the following implementation methods to make relevant recommendations to internal members; or, the relevant data used in the specific implementation are all simulated data, such as simulated data generated in a virtual scene.

[0080] To facilitate understanding of the technical solutions provided in the embodiments of the present application, some key terms used in the embodiments of the present application are explained here:

[0081] Hyper Text Transfer Protocol (HTTP): is a simple request-response protocol that usually runs on top of TCP. It specifies what kind of request messages a client may send to a server and what kind of response messages it may get. The headers of the request and response messages are given in ASCII form, while the message content has a MIME-like format.

[0082] Remote Procedure Call (RPC): is an inter-process communication method, a protocol that requests services from a remote computer program over a network without having to understand the underlying network technology. RPC allows a program to call a procedure or function in another address space (usually another server on a shared network) without explicitly coding the details of the remote call in the development object. RPC hides the underlying communication details (no need to directly handle Socket communication or Http communication), that is, whether calling a local interface / service or a remote interface / service, the calling code written is essentially the same.

[0083] For example, there are two servers A and B. An application is deployed on server A and needs to call the function or method provided by the application on server B. Since the functions or methods are not in the same memory space, they cannot be called directly. At this time, the RPC framework needs to be used to solve the problem.

[0084] JavaScript Object Notation (JSON): is a lightweight data exchange format. It is based on a subset of ECMAScript (the js specification developed by the European Computer Manufacturers Association) and uses a text format that is completely independent of the programming language to store and represent data. The simplicity and clear hierarchical structure make JSON an ideal data exchange language. It is easy to read and write, and also easy for machines to parse and generate, and effectively improves network transmission efficiency. JSON syntax rules: JSON is a sequence of tags. This set of tags contains six constructs, strings, numbers, and three literals. JSON is a serialized object or array. A value can be an object, an array, a number, a string, or one of three literals (false, null, true). JSON is a string representation of a JS object. It uses text to represent the information of a JS object, which is essentially a string.

[0085] JSON Schema: It is a specification based on JSON format, which is used to define the structure of JSON data. It is a tool for validating JSON data structure. Schema can be understood as a pattern or rule. Generally, JsonSchema is used to validate the JSON data format, and the JSON format is validated before the data is submitted to the business level. JSON Schema (application / schema + JSON) has many uses, one of which is instance validation. The validation process can be interactive or non-interactive. For example, an application can use JSON schema to build a user interface, enable interactive content generation in addition to user input checking or verify data obtained from various sources.

[0086] Json Path, a syntax standard, can easily extract the content of Json data structure.

[0087] Uniform Resource Identifier (URI): is a string used to identify the name of an Internet resource. This identification allows users to interact with any resource (including local and Internet) through a specific protocol. URI is defined by a scheme that includes a certain syntax and related protocols. Every resource available on the Web - HTML documents, images, video clips, programs, etc. - is located by a universal resource identifier URI.

[0088] Uniform resource locator (URL): It is a method of indicating the location of information on the World Wide Web service program of the Internet. It has now been compiled by the World Wide Web Consortium as the Internet standard RFC1738.

[0089] Operator: Each instruction in the instruction system has an operator, which indicates the nature of the operation that the instruction should perform. Different instructions are represented by different codes in the operator field, and each code represents an instruction.

[0090] HTTP Status Code: A 3-digit code used to indicate the status of a web server's Hypertext Transfer Protocol response. It is defined by the RFC 2616 specification and extended by RFC 2518, RFC 2817, RFC 2295, RFC2774, and RFC 4918. The first digit of all status codes represents one of the five states of the response. The message phrases shown are typical, but any readable alternatives can be provided. Unless otherwise specified, status codes are part of the HTTP / 1.1 standard (RFC 7231).

[0091] Common Gateway Interface (CGI): It is the specification of external programs when the Web server is running. Programs written according to CGI can extend the server functions. CGI applications can interact with browsers and communicate with external data sources such as database servers through data APIs to obtain data from database servers. After being formatted into HTML documents, they are sent to browsers, and data obtained from browsers can also be placed in databases.

[0092] Literal value: It is data. Literal value is one of the components of Java source program, including identifiers and keywords, which are all components of Java source program. In Java source code, literal value is used to represent fixed value (fixed value). Numeric literal value is the most common. String literal value can be regarded as one kind. Of course, special null can also be regarded as literal value. Literal value can be roughly divided into integer literal value, floating point literal value, character and string literal value, special literal value.

[0093] XML: is a software and hardware independent tool for storing and transmitting data. XML stands for Extensible Markup Language, a markup language very similar to HTML, designed to store and transmit data, XML is designed to be self-describing, XML is a W3C recommendation.

[0094] Genson: is a lightweight Java library for processing JSON data, providing full data binding and Java generics support.

[0095] The following is a brief introduction to the design concept of the embodiment of the present application:

[0096] The business system includes multiple business modules, each of which has at least one business logic. When the business system receives a business request, it transmits the business request to the business module according to the interface identifier of the business module in the business request (multiple interfaces of a business module correspond to multiple business logics in this business module respectively), and the business module executes the corresponding business logic to process the business request, obtain the request processing result, and generate a request response based on the request processing result and send it to the initiating object of the business request. Among them, the use scenario of the business system is based on the execution of the business logic in one or more business modules. For example, the verification business logic in the corresponding business module can be used to verify the account information in the login request, and generate a request response based on the verification result and return it to the initiating object of the login request to realize the verification use scenario of the login request; for another example, the verification logic in a business module can be used to verify the identity account and password in the file read request. After the verification is passed, the reading logic in another business module is used to obtain the corresponding file based on the file identification information in the file read request, and return it to the initiating object of the file read request to realize the file reading use scenario of the file read request.

[0097] In the related art, in order to ensure the normal use of various usage scenarios of the business system, it is necessary to write test cases to test whether the business logic execution of each business module corresponding to the usage scenario is normal based on the test cases, so as to operate and maintain the business system. However, in large-scale business systems, each business module implements a large number of usage scenarios through a combination of one business module or multiple business modules, which can even reach thousands of usage scenarios. Manually writing test cases requires considering labor costs and time costs for writing test cases, so often only a few hundred usage scenarios can be written at most, which is far from meeting the operation and maintenance requirements. In addition, the business system will continue to integrate subsystems as the business changes. In many cases, the computer languages ​​used by the subsystem and the business system are not the same. This requires the development object to have very high professional capabilities and be proficient in various computer languages, but there are very few such development objects.

[0098] In view of this, a test case generation method, device, computer equipment and storage medium provided in an embodiment of the present application are suitable for a test system, including: a parameter screening rule is set in the test system, which can analyze the historical business data processed from the business system, and screen out the historical request data sets of each business module, wherein the historical request data is the data required to generate test cases, and further, for the data type of the request processing result in each historical request data of each business module, the corresponding preset rule template is obtained, the request processing result is set in the rule template, and the corresponding verification rule is obtained, so as to combine the request mode, request parameters and the corresponding verification rules obtained in the historical request data to obtain a test case. That is, according to the request data such as the request method, request parameters and request processing results required by the test case, parameter screening rules are designed, and the parameter screening rules are set in the test system in advance, so that the test system can automatically screen the request data required for the test case from the historical business data of the business system. In this way, historical traffic analysis can be used to extract the request data required for the test case, which can not only automatically generate test cases, but also automatically obtain the request data in all historical usage scenarios of each business module in the business system. Based on the large amount of request data with high coverage of usage scenarios, a large number of test cases can be automatically generated, which effectively solves the problems in related technologies such as high professional ability requirements for test case development objects, high test case writing costs, and low coverage of business system usage scenarios by manually written test cases.

[0099] The preferred embodiments of the present application are described below in conjunction with the drawings in the specification. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present application, and are not used to limit the present application. In addition, the embodiments and features in the embodiments of the present application may be combined with each other if there is no conflict.

[0100] like Figure 1 As shown, it is a schematic diagram of an application scenario of an embodiment of the present application. The application scenario diagram includes any one of the multiple servers 110 and any one of the multiple servers 120.

[0101] The test case generation method in the embodiment of the present application can be executed by a computer device, which can be a server 120. A test system is running in the server 120. The server 120 can obtain various historical business data processed by the business system from the server 110 running the business system, wherein a historical business data can include: information generated by the business system in the process of processing a business request, such as the generated information including module identification information of the business module (such as the interface identification of the interface on the business module or the name of the business module, etc.), a request data packet of the business request and a response data packet of the business request response; then the server 120 can filter out the target request data set of each business module from each historical business data based on the preset parameter screening rules, and the target request data at least includes: the request method, request parameters and request processing results of the corresponding business module in a business request process; wherein the request method and request parameters meet the parameter screening rules; then, the server 120 performs the following steps for each target request data associated with each business module:

[0102] Based on a target request data of a business module, determine the data type of the request processing result contained in the target request data, match each preset rule template according to the data type, obtain the rule template corresponding to the data type from each preset rule template, set the request processing result to the obtained rule template, obtain the verification rule for verifying the execution result of the business logic of a business module, and then combine the request mode and request parameters of a target request data with the verification rule to obtain the corresponding test case. Finally, multiple test cases for each business module are obtained, and the server 120 sends each obtained test case to the server 110, so that the test case in the server 110 tests the business logic of the corresponding business module in the business system after being triggered.

[0103] In addition, a piece of historical business data may include: information generated by the business system in the process of processing a business request, where the business request may be sent from other external systems to the business system of the server 110, or sent from the client of the business system of the server 110 to the business system of the server 110. There is no specific restriction on the way in which the business request is generated. In order to clearly explain this solution, this application provides another application scenario schematic diagram, such as Figure 2As shown, the application scenario diagram includes any terminal device 210 among multiple terminal devices, any server 220 among multiple servers, and any server 230 among multiple servers. Among them, the terminal device 210 can be installed with a client related to the service provided by the business system in the server 220 (such as reading service, shopping service and chat service, etc., and the service provided by the business system is not specifically limited here). The client can be software (such as browser, communication software, etc.), or a web page, applet, etc. The server 220 is a background service corresponding to the software or web page, applet, etc., or a background service specifically used to provide business services to the client, which is not specifically limited in this application, and the server 230 is a server of the test system, and the same Figure 1 The server 120 in the example is used to automatically generate test cases based on various historical business data processed by the business system in the server 220.

[0104] It should be noted that the above-mentioned terminal device 210 includes but is not limited to mobile phones, tablet computers, laptop computers, desktop computers, e-book readers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals and other devices, and this application does not make specific limitations. The terminal device 210 can be installed with a client related to the business provided by the business system in the server 220. Servers 110 and 120, as well as servers 220 and 230 can be independent physical servers, or server clusters or distributed systems composed of multiple physical servers, or cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0105] It should be noted that Figure 1 and Figure 2 What is shown is just an example. In fact, the number and communication mode of terminal devices and servers are not limited and are not specifically limited in the embodiments of the present application.

[0106] In addition, the test case generation method of the embodiment of the present application can be applied to various scenarios, such as changes in online business systems, daily operation and maintenance of online business systems, and offline business system upgrade testing.

[0107] The following describes the multimedia information recommendation method provided by the exemplary embodiment of the present application in combination with the application scenarios described above and with reference to the accompanying drawings. It should be noted that the above application scenarios are only shown to facilitate understanding of the spirit and principles of the present application, and the implementation of the present application is not limited in this respect.

[0108] See also Figure 3 As shown, it is a flow chart of the test case generation method provided in the embodiment of the present application. Here, the server is used as an example for illustration, which is applicable to the test system. The specific implementation process of the method is as follows:

[0109] Step 301: based on preset parameter screening rules, filter out the target request data set of each business module from the historical business data processed by the business system, where the target request data at least includes: the request method, request parameters and request processing result of the corresponding business module in a business request process; wherein the request method and request parameters meet the parameter screening rules;

[0110] In one embodiment, the parameter screening rule can be to screen the data in the historical business data that conforms to the set data type. Then, the parameter screening rule is used to screen the target request data that conforms to the set data type from the historical business data processed by the business system, and obtain multiple target request data of each business module. The set data type can be the data type of the request method, the parameter type of the request parameter, and the data type of the request processing result. For example, the data type of the request method can be the data type of the protocol identifier: HTTP or RPC, etc. The parameter type can be parameter item information such as age and gender, or parameter attribute information such as numerical parameter type and text parameter type, or a combination of parameter item information and parameter attribute information, etc. The data type of the request processing result can be text data, numerical data, and HTTP status code, etc.

[0111] In one embodiment, the parameter screening rule may be to screen the data in the historical business data that conforms to the set data structure. The parameter screening rule is then used to screen the target request data that conforms to the set data structure from the historical business data processed by the business system, and obtain multiple target request data for each business module. The set data structure may be a request data packet and a corresponding response data packet with the set data structure, and the request mode is screened from the header of the request data packet, the request parameters are screened from the body of the request data packet, and the request processing result is screened from the header and body of the response data packet (the descriptive information of the request processing result is screened from the header of the response data packet and the body of the request processing result is screened, etc., wherein the descriptive information may include the data type, data length, compression and decompression method, status code, etc. of the data in the body, and the specific result data of the request processing result is screened in the body, such as the body of the response data packet of the login response of the login request contains "login successful").

[0112] In one embodiment, based on the above two embodiments, the parameter screening rules may include screening rules composed of a set data type and a set data structure. The parameter screening rules are used to screen out request data packets and corresponding response data packets with a set data structure from various historical business data processed by the business system, filter the request mode of the set data type from the packet header of the request data packet, filter the request parameters of the set data type from the packet body of the request data packet, and filter the request processing results of the set data type from the packet body of the response data packet. The present application does not impose any specific restrictions on the parameter screening rules.

[0113] In one embodiment, the historical business data may be obtained from a log of a business system, or from an information collection tool of the business system. The present application does not impose any specific restrictions on the method of obtaining the historical business data.

[0114] Step 302: For each target request data associated with each business module, execute the following steps respectively:

[0115] Step 3021: Based on a target request data of a business module, determine the data type of the request processing result contained in the target request data, obtain the rule template preset for the corresponding data type, and set the request processing result to the rule template to obtain the corresponding verification rule. The verification rule is used to verify the execution result of the business logic of a business module.

[0116] Step 3022: Based on a request method and request parameters of a target request data and in combination with verification rules, a corresponding test case is obtained.

[0117] In one embodiment, the rule template may be in the form of a regular expression, a text, etc., and the form of the rule template is not specifically limited here.

[0118] In one embodiment, the rule template may be in the form of a regular expression. Assuming that the request processing result includes the verification status in the verification response corresponding to the verification request, and the response code for the verification status being the passing status is 400, the regular expression rule template may include “^…￥”. The request processing result - response code is 400, and is set to the corresponding “^…￥” in the rule template. Then, a verification rule including “^400￥” is obtained. The verification rule is then combined with the request method and request parameters to obtain a test case.

[0119] After the business system is triggered, the corresponding verification request for testing is generated based on the request method and request parameters in the test case, and after the verification response of the test is obtained, the test case adopts the verification rule containing "^400￥" to verify the verification response of the test. If the verification response of the test contains the response code 400, the verification passes, and it is determined that the business module processing the verification request of the test is operating normally. If the verification fails and the response code is not 400, it is determined that the business module processing the verification request of the test is operating abnormally.

[0120] Based on the above embodiments, in one embodiment, the packet header of the verification response contains "Cookie", indicating that the response status of the verification response of the verification request is a passed status, and the rule template of the regular expression may contain "*…*.", then the information Cookie in the request processing result-packet header is set to the corresponding "*…*." in the rule template, and a verification rule containing "*.Cookie*." is obtained, and the verification rule is combined with the request method and request parameters to obtain a test case.

[0121] After the business system is triggered, the corresponding verification request for testing is generated based on the request method and request parameters in the test case, and after the verification response of the test is obtained, the test case uses the verification rule containing "*.Cookie*." to verify the verification response of the test. If the packet header of the verification response of the test contains "Cookie", the verification passes, and it is determined that the business module processing the verification request of the test is operating normally. If the verification fails and the packet header does not contain "Cookie", it is determined that the business module processing the verification request of the test is operating abnormally.

[0122] Based on the above embodiments, in one embodiment, the packet header of the verification response contains the information "Cookie" and the response code "400", indicating pass, and the packet body contains "Verification successful", then the rule template of the regular expression may contain "^…￥"and"*…*."and"(?s)((?!).)*￥", then the request processing result: information "Cookie" and response code "400" and "Verification successful" are set to the corresponding "^…￥"and"*…*."and"(?s)((?!…).)*￥" in the rule template, then a verification rule containing "^400￥"and"*.Cookie*."and"(?s)((?!Verification successful).)*￥" is obtained, then the verification rule is combined with the request method and request parameters to obtain a test case.

[0123] After the business system is triggered, the corresponding verification request for testing is generated based on the request method and request parameters in the test case, and after the verification response of the test is obtained, the test case uses the verification rules to verify the verification response of the test. If the packet header of the verification response of the test contains "400" and "Cookie", and the packet body contains "Verification successful", the verification passes, and it is determined that the business module that processes the verification request of the test is operating normally. Otherwise, it is determined that the business module that processes the verification request of the test is operating abnormally.

[0124] In one embodiment, the rule template may be in text form. It is assumed that the request processing result includes the verification status in the verification response corresponding to the verification request, and the response code for the verification status being the passing status is 400. The text rule template may be "equal to...", and the request processing result-response code is 400, which is set to the corresponding "equal to..." in the rule template. Then, a verification rule including "equal to 400" is obtained. The verification rule is then combined with the request method and request parameters to obtain a test case.

[0125] After the business system is triggered, the corresponding verification request for testing is generated based on the request method and request parameters in the test case, and the verification response of the test is obtained. The test case uses the verification rule containing "equal to 400" to verify the verification response of the test. If the verification response of the test contains the response code 400, the verification passes.

[0126] Based on the above embodiments, in one embodiment, the rule template may be in text form, and the packet header of the verification response contains the response code "400" and the information "Cookie", indicating pass, and the packet body contains "Verification successful", then the text rule template may contain "equal to..." and "contains..." and "contains...", then the request processing result: response code "400" and information "Cookie" and "Verification successful" are set to the corresponding "equal to..." and "contains..." and "contains..." of the rule template, then a verification rule containing "equal to 400", "contains Cookie" and "contains verification successful" is obtained, then the verification rule is combined with the request method and request parameters to obtain a test case.

[0127] After the business system is triggered, the corresponding verification request for testing is generated based on the request method and request parameters in the test case, and after the verification response of the test is obtained, the test case uses the verification rules to verify the verification response of the test. If the packet header of the verification response of the test contains "400" and "Cookie", and the packet body contains "Verification successful", the verification passes, and it is determined that the business module that processes the verification request of the test is operating normally. Otherwise, it is determined that the business module that processes the verification request of the test is operating abnormally.

[0128] It can be learned from the above method and embodiments that by analyzing historical traffic and extracting request data required for test cases, not only can test cases be automatically generated, but also request data in all historical usage scenarios of each business module in the business system can be automatically obtained. Based on the large amount of request data with high usage scenario coverage, a large number of test cases can be automatically generated, which effectively solves the problems in related technologies of high professional ability requirements for test case development objects, high test case writing costs, and low coverage of business system usage scenarios by manually written test cases.

[0129] Based on the above Figure 3 In the method flow, the embodiment of the present application provides a method for supplementing the verification rules. In step 3022, based on the request mode and request parameters of the target request data, combined with the verification rules, a corresponding test case is obtained, including:

[0130] Based on a request method and request parameters of a target request data, a corresponding test case is obtained in combination with verification rules and supplementary verification rules. The supplementary verification rules are used to verify the data format of the corresponding request processing result.

[0131] In one embodiment, if the verification rule is used to verify whether the array in the request processing result is correct, the supplementary verification rule can verify the null value of the array in the request processing result. If there is a null value in the request processing result, an alarm can be generated. The business system will feedback the alarm to the set mailbox or display it on the setting page, etc. For example, the supplementary verification rule is that the array is greater than 1.

[0132] In one embodiment, if the verification rules are used to verify whether the characters in the request processing results are correct, the supplementary verification rules can verify the length of the characters in the request processing results. If the character length in the request processing results is incorrect, an alarm can be generated, and the business system will feed back the alarm to the set mailbox or display it on the setting page, etc.

[0133] Based on the above Figure 3 In the method flow, the embodiment of the present application provides a method for obtaining a scenario use case group. After the test system generates test cases for each business module, a scenario use case group for a combination of multiple business modules is further generated, such as Figure 4 As shown, in step 3022, based on a request mode and request parameters of a target request data, combined with the verification rule, after obtaining a corresponding test case, it also includes:

[0134] Step 401: Send the test case to the business system so that the management system obtains the test case and case information from the business system. The case information includes the module name of the business module corresponding to the test case, the case identifier, and the module names of other business modules associated with the corresponding business module.

[0135] In one embodiment, the present application embodiment provides a schematic diagram of an application scenario, such as Figure 5 As shown, the application scenario diagram includes any one of the multiple servers 510, any one of the multiple servers 520, and any one of the multiple servers 530, wherein the business system is running in the server 510, the test system is running in the server 520, and the management system is running in the server 530. The server 520 will use the above Figure 3 The test cases generated by the method flow in are sent to the server 510, and the server 530 collects the test cases and case information in the server 510.

[0136] In one embodiment, the present application embodiment provides a schematic diagram of an application scenario, such as Figure 6 As shown, the application scenario diagram includes any one of the multiple servers 610 and any one of the multiple servers 620, wherein the business system is run in the server 610, the management system is a subsystem in the test system, and the test system including the management system is run in the server 620. The server 620 may include the association relationship between the business modules in the business system, and then according to the above Figure 3 The test cases generated by the method flow in the analysis are used to obtain the use case information. For example, the server 620 may include the association between the verification module and the login module in the business system. When analyzing and obtaining the use case information of the test case of the login module, the module name and use case identifier of the login module and the module name of the verification module may be obtained.

[0137] Step 402: Through the management system, the test cases and use case information are displayed on the management page, so that the management system responds to the use case selection operation and the use case group generation operation to generate a scenario use case group, wherein the scenario use case group includes multiple scenario test cases with a set execution order, and each scenario test case in the scenario use case group corresponds to a business module, which is used to complete the processing of a business scenario according to the set execution order.

[0138] In one embodiment, the present application embodiment provides a schematic diagram of a use case management list page in a management page, such as Figure 7As shown, it includes: basic information of managing use cases - use case ID, use case management object, use case description information, number of retries and retry time interval after use case failure - retry delay, whether it is an internal use case of the use case group (whether it is only used for the use case group), the business module to which the use case belongs (module name), the associated business module of the business module to which the use case belongs (associated module name), the applied protocol (protocol identifier), the common gateway interface path of the business module to which the use case belongs, etc. For example, if the business system is a background system of a reading software, the use case ID is 103, the name of the use case management object is X, the use case description information is the annual dimension big data of the data center, the number of retries after the use case fails is 3 times and the retry time interval - the retry delay is 10s, whether it is an internal use case of the use case group - no, the business module to which the use case belongs - weread... - micro-reading service, the associated business module of the business module to which the use case belongs - weread... - related services of the micro-reading service, the application protocol - cgi, the common gateway interface path of the business module to which the use case belongs - readlogicsvr - reading service, and the operations can include the details of the test case (which can be clicked to display the specific data of the test case, including the request method, request parameters and verification rules), modify the test case, copy the test case and delete the test case, and there is also a test trigger button, which can trigger the corresponding test case to test the corresponding business module in the business system.

[0139] In one embodiment, the present application embodiment provides a schematic diagram of a use case management details page in a management page, such as Figure 8 As shown, the business request corresponding to the test case can be obtained in the test case details page, such as, Figure 8 If a new business request appears in the business module to which the test case belongs, a test case is generated for the historical business data of the new business request, which includes the request identifier-120 of the new business request, the use case identifier-117 of the request, the request resource identifier-183755902, the query resource-Vid=183755902, the JSON request, and the corresponding modification and deletion operations. Correspondingly, it can also include JSON Schema verification rules (new verification rules) and JSON PATH verification rules (new JSON information extraction tools), which respectively have information such as rule identifiers and use case identifiers.

[0140] Based on the above embodiments, the present application embodiment provides a schematic diagram of a use case list page of a business module in a management page, such as Fig. 9As shown, it includes: the module name of the business module to which the test case belongs - Weread..., the interface name of the business module - / article / list, the management object, read / write type, the number of test cases of the business module, the number of samples, the number of faults and related declaration information in each test case, as well as the deletion operation, modification operation, generation operation, operation details and test operation.

[0141] Based on the above embodiments, the present application embodiment provides a schematic diagram of an update use case details page in a management page, such as Fig.10 As shown, some relevant information of the test case is displayed, including optimization operations on verification rules, case replacement operations and case deletion operations, as well as request resource identifier, common gateway interface, interface response (html), interface response (json), query protocol, operating system, memory usage, protocol type, client service, rules, etc.

[0142] Based on the pages in the above embodiments, in one embodiment, the present application embodiment provides a schematic diagram of a use case group details page in a management page, such as Fig.11 As shown, assuming that the client is a reading software and the business system is the background system of the reading software, then on the management page (such as, Figure 7 , Figure 8 , Fig. 9 , Fig.10 ), you can enter the page for generating use case group details by setting the "scenario use case group" and "next page" operation keys. If you need to test the use scenario of reading progress reporting & reading, you can set "reading progress reporting & reading" as the name of the scenario use case group, set the execution order of each use case in the use case group, and choose whether to execute in sequence. The module name of the business module corresponding to each use case in the scenario use case group is: Were...svr; Were...mq; Were...icsvr. The corresponding use case information can be displayed in the newly added scenario use case group, including: use case identification, use case description, use case management object, execution order, use case delayed execution order, and corresponding details viewing operations and use case deletion operations.

[0143] In one embodiment, based on the above Fig.12 The scenario use case group in the present application embodiment provides a schematic diagram of a use case group generation page in a management page, such as Fig.11As shown, the use case selection option can be set in the corresponding use case information row in the above use case group generation page, then, in the execution order of the test case, the use case selection operation is executed: the first selection operation, the second selection operation and the third selection operation, and the use case group generation operation is executed: submit, then the scenario test case group is generated. It should be noted that in the embodiment of the present application, an input box for logic writing between use case groups can also be set in the use case group generation page for the development object to write relevant logic symbols, and a detailed customized plan is made for the execution of the scenario use case group. The specific generation page and generation method of the scenario use case group are not limited here.

[0144] Step 403: Send the scenario use case group to the business system through the management system.

[0145] Based on the above Figure 4 In the method flow, the embodiment of the present application provides a method for generating a change scenario use case group. Based on the scenario use case group obtained in the above step 402, the change scenario use case group can be edited, such as Fig.13 As shown, in step 403, before sending the scenario use case group to the business system through the management system, it also includes:

[0146] Step 1301: Display the scenario use case group on the use case group page through the management system, so that the management system generates a change scenario use case group in response to the address setting operation.

[0147] Among them, the setting address operation is used to set the setting storage address in the change scenario use case group, so that when the change scenario use case group is executed, the setting request data in the upstream scenario test case that has been executed in the scenario use case group is stored in the setting storage address, and the downstream scenario test case in the scenario use case group obtains the setting request data from the setting storage address and executes it.

[0148] Step 1302: Send the change scenario use case group to the business system through the management system.

[0149] In one embodiment, the setting request data is a parameter of a setting data type, or a character in a setting data structure. The present application does not impose any specific limitation on the setting request data.

[0150] In one embodiment, when the change scenario use case group is running, the setting storage address can be in the form of a parameter pool, and the parameters in the parameter pool can be stored in the form of key-value, where the key is the data identification information of the variable to be used, and the value is the value corresponding to the key, where the value can be either a literal value or a JSONPointer path, which can extract the variable value from the response data packet of the request response of the business request.

[0151] In one embodiment, the completion of many usage scenarios is realized by a link composed of multiple business modules. When the scenario use case group of this link is tested, there will usually be parameter dependencies between the test cases in the scenario use case group. The input parameters of a downstream test case may depend on a field value of the response data packet of the upstream test case request response. Therefore, it is necessary to extract the parameters and pass them to the test case of the next business module (that is, extract the parameters and pass them to the downstream test case, generate a business request and send it to the corresponding business module (the business module receives the business request based on its own interface)). Based on this, the embodiment of the present application provides a parameter and module dependency diagram, such as Fig.14 As shown, taking the book list creation scenario as an example, the downstream comment module of the book list creation module needs to obtain the book list ID (set request data) in the book list creation module and obtain the comment ID corresponding to the book list ID. The downstream comment deletion module of the comment module needs to obtain the book list ID and comment ID in the book list creation module. After the comment deletion module determines that the comment corresponding to the comment ID has a bad review, the book list deletion module downstream of the comment deletion module obtains the book list ID of the comment deletion module, executes the book list deletion operation, and completes the book list creation scenario. It can be seen that in the book list creation scenario, parameters need to be passed in each business module, which may result in parameter transmission errors or slow transmission, affecting the user experience of using the service. When testing the scenario use case group for the book list creation scenario, the embodiment of the present application provides a schematic diagram of a method for obtaining parameters between test cases in a scenario test case group, as shown in Fig.15 shown.

[0152] In one embodiment, the address setting operation may also include setting a transfer engine for setting request data in the change scenario use case group, which may also be called a template engine, for obtaining setting request parameters from the setting storage address and setting them in the test case when the test case needs setting request data, such as Fig.16 As shown, it is a schematic diagram of a method for obtaining parameters between test cases of a scenario test case group provided in an embodiment of the present application, wherein a storage address is set to exist in the form of a parameter pool when the test case is running, and a request parameter is set to be a parameter in the form of a key-value. Among them, after the execution of use case 1, use case 2, and use case 3, the set request data-parameters are placed in the parameter pool, and use case 4 receives the parameters from the parameter pool under the action of the template engine, and places the parameters into the parameter pool after execution.

[0153] Based on the above Figure 3 , Figure 4 , Fig.13In the method flow, when obtaining multiple business data including various historical business data in the business system, the multiple business data obtained are first preliminarily cleaned. The embodiment of the present application provides a data cleaning method. In step 301, based on a preset parameter screening rule, before filtering out the target request data set of each business module from the various historical business data processed by the business system, the method further includes:

[0154] Based on the data screening rule, the historical business data are screened from the initial business data, and the data screening rule is: the business request process is complete and the execution status is a success status.

[0155] In one embodiment, the data screening rule may be to delete the business data whose execution status of the business request is a failure status among the multiple business data.

[0156] In one embodiment, the data screening rule may be to delete the business data lacking a preset data structure from the multiple business data.

[0157] In one embodiment, if the header or body information in the request data packet in the business data is missing, the business data is deleted using a data screening rule.

[0158] Based on the above Figure 3 , Figure 4 , Fig.13 In the method flow, when obtaining each historical business data, each historical business data is analyzed to obtain each target request data. The embodiment of the present application provides a method for obtaining target request data, such as Fig.17 As shown, in step 301, based on the preset parameter screening rules, the target request data set of each business module is screened out from the historical business data processed by the business system, including:

[0159] For each of the business modules, perform the following steps respectively:

[0160] Step 1710: Extract the data parts that meet the parameter screening rules from each historical business data associated with a business module as the corresponding historical request data.

[0161] Step 1720: Based on the multiple historical request data obtained, statistics are collected on the application of at least one existing request method and request parameter, wherein the application includes: the value range of the request parameter with continuous values ​​in the multiple historical request data, the enumeration of the request parameter with discrete values, and at least one of the combinations of multiple request parameters in a business request.

[0162] Step 1730: Based on at least one request mode and application situation, non-repetitive target request data are screened out from multiple historical request data to obtain a target request data set of a business module.

[0163] In one embodiment, a request data packet of a service request and a response data packet of a request response are obtained by screening each piece of historical service data.

[0164] In one embodiment, assuming that there are 10 pieces of historical request data corresponding to a business module, among which the business requests in 4 pieces of historical request data are the same business request (the request mode and request parameters in the request data packet are the same), then only the request mode, request parameters and request processing response in one piece of historical request data among the 4 pieces of historical request data can be used as the target request data. It is not necessary to analyze the data in the response data packet of the request response of the business request in the 4 pieces of historical request data, and the request processing results in the request response of the successful status obtained by the same business request are likely to be the same.

[0165] In one embodiment, when analyzing actual historical business data, the amount of historical business data is very large, and may even reach tens of thousands of items. Therefore, by statistically analyzing the request methods and request parameters in multiple historical business data in a business module, all combinations of request methods and application conditions of request parameters that have appeared can be exhausted to obtain a target request data set. For example, there are two types of request methods for business requests in multiple historical business data of a business module, which are listed separately: HTTP and RPC. The value range of request parameter 1-age is (0-100), and the enumeration of request parameter 2-gender is male or female. The combination of request parameters is: gender: male, age: 80, gender: female, age: 80, etc. Based on the application of the obtained request parameters, the application of the request methods and request parameters that appear in each historical business data is exhaustively listed without duplication as the target data set of a business module. In addition, the request parameters may also include parameters that are not enumerated and do not have a value range, such as product IDs, book list IDs, etc. In this case, there is no need to exhaustively obtain the target request data for such request parameters, and the target request data can be randomly selected from the product IDs or book list IDs that already exist in the historical business data. In this way, all existing and non-repetitive request methods and request parameters are exhaustively enumerated in the above manner, so that the target request data set of each business module obtained can cover all the business logic executed by this business module. Assuming that there are only enumerable parameters, the interface valid use case = the enumerable values ​​of all enumerable parameters + the combination of all enumerable parameters, the interface coverage = the number of valid use cases covered (the test cases that already exist before the current test case generation process) / the number of valid use cases of the interface * 100%, the global coverage = the number of covered interfaces (the number of valid use cases covered + the number of valid use cases of the interface) / the total number of interfaces (the total number of interfaces of each business module in the business system) * 100%, wherein, when the interface coverage reaches 100%, it is considered that the interface has achieved use case coverage.

[0166] In one embodiment, a threshold value may be set for the request parameter, for example, a lower limit of 0 and an upper limit of 130 may be set for the request parameter of age.

[0167] In one embodiment, there is a business request whose url parameters are protocol: HTTP / HTTPS, server and client communication protocol type, listType=1&listMode=2, vid is 10000, platform is android, and version number is 7.2.0. Then, the protocol: HTTP / HTTPS, listType=1&listMode=2, vid is 10000, platform is android, and version number is 7.2.0 can be extracted from the url, and the book list Id=12345, operation information, etc. can also be extracted from the JSON data structure of the business request. JSON Pointer can be used to represent the path of the above parameters as the key value of the above parameters.

[0168] Based on the above Fig.17 In the method flow, for filtering out historical request data from various historical business data, the embodiment of the present application provides a method for obtaining historical request data, such as Fig.18 As shown, in step 1710, data parts that meet the parameter screening rules are extracted from each historical business data associated with a business module as corresponding historical request data, including:

[0169] For each historical business data associated with a business module, perform the following operations:

[0170] Step 1711: extract a request data packet and a corresponding response data packet from a historical business data.

[0171] Step 1712: Filter out the request mode and request parameters that meet the parameter screening rules from the packet header and packet body of the request data packet.

[0172] Step 1713: Filter out the request processing results that meet the parameter screening rules from the body of the response data packet.

[0173] Step 1714: The obtained request method, request parameters and request processing result are used as historical request data.

[0174] In one embodiment, if Fig.19 As shown, it is a structural diagram of a request data packet provided in an embodiment of the present application. The request method and request parameters that meet the parameter screening rules can be filtered out from the packet header and the packet body respectively, wherein the black part represents the storage location of the request method and the request parameters.

[0175] In one embodiment, if Fig. 20 As shown, it is a structural diagram of a response data packet provided in an embodiment of the present application, and the request processing results that meet the parameter screening rules can be filtered out from the packet header and the packet body, wherein the black part indicates the storage location of the request processing results.

[0176] In one embodiment, only request processing results that meet the parameter screening rules may be screened out from the packet body of the response data packet, such as verification passed or verification failed.

[0177] Based on the above Figure 3 , Figure 4 and Fig.13 In the method flow, the embodiment of the present application provides a method for adding test cases. After each test case is generated based on each historical business data, if a new business request and request response appear, a test case can be added to test the corresponding business logic of the business module to which the new business request and request response belong. In step 301, based on a preset parameter screening rule, after filtering out the target request data set of each business module from each historical business data processed by the business system, the method further includes:

[0178] Step 1: Based on parameter screening rules, newly added request data of a target business module is screened out from the latest business data processed by the business system. The target business module is a business module that has existed in the business system from the beginning or a newly added business module.

[0179] Step 2: Based on the new request data of the target business module, determine the data type of the new processing results contained in the new request data, obtain the rule template preset for the data type corresponding to the new processing results, and set the new processing results to the rule template to obtain the corresponding new verification rules. The new verification rules are used to verify the execution results of the business logic of the target business module.

[0180] Step 3: Based on the request method and request parameters of the newly added request data and in combination with the newly added verification rules, obtain the corresponding newly added test cases.

[0181] In one embodiment, real-time traffic can be collected for each business module in the business system. If the business system is upgraded, changed or added to a business and a new business module appears (it can also be a new business logic added to the business module in the original business system), if interface information that did not appear when the test case was generated appears in the real-time traffic, the new business request corresponding to this interface information and the latest business data of the corresponding request response can be obtained, and the parameter screening rules are used to screen out the newly added request data from the latest business data, and the request mode and request parameters are respectively obtained from the header and body of the request data packet of the newly added request data, and the newly added processing result is obtained from the header and body of the corresponding data packet, and the data type of the newly added processing result is determined, and a rule template for the data type of the newly added processing result is obtained, and the newly added processing result is set in the rule template to obtain the corresponding newly added verification rule, and the request mode and request parameter newly added verification rules are combined to obtain the corresponding new test case.

[0182] In one embodiment, real-time traffic can be collected for each business module in the business system. If interface information or request method or request parameters or request processing results that did not appear when the test case was generated appear in the real-time traffic, the latest business data of the new business request and the corresponding request response can be obtained. The parameter screening rules are used to screen out the newly added request data from the latest business data, and the request method and request parameters are respectively obtained from the header and body of the request data packet of the newly added request data, and the newly added processing results are obtained from the header and body of the corresponding data packet. The data type of the newly added processing result is determined, and a rule template for the data type of the newly added processing result is obtained. The newly added processing result is set in the rule template to obtain the corresponding newly added verification rule, and the newly added verification rules for the request method and request parameters are combined to obtain the corresponding newly added test case.

[0183] In one embodiment, if Fig.21 As shown, a method for configuring relevant information of a test case provided in an embodiment of the present application can also configure management objects for newly generated test cases, data types involved in related business modules and other management information, and send the test case to the business system.

[0184] Based on the above Figure 3 , Figure 4 and Fig.13 In the method flow, the embodiment of the present application provides a method for generating a test case. When each test case is generated based on each historical business data in the above-mentioned processes, in order to further improve the degree of automatic generation of the test case, the preset protocol path of the preset protocol that needs to be manually uploaded in the related art is added to the test case, so that the test case can obtain the preset protocol from the configuration file of the business system according to the preset protocol path. In step 303, the request mode and request parameters based on the one target request data are combined with the verification rule to obtain the corresponding test case, including:

[0185] Based on the request mode and request parameters of the target request data, combined with the verification rules and the preset protocol path, a corresponding test case is obtained. When the test case is executed, the preset protocol path is used to obtain the preset protocol from the business system and convert the test request generated by the test case into a format recognizable by the corresponding business module.

[0186] In one embodiment, if the preset protocol is a proto protocol or an XML protocol, when the test case is running, it can be obtained from the configuration file of the business system according to the preset protocol path, and even if the preset protocol in the business system is updated, there is no need for manual synchronization and upload.

[0187] The present application embodiment provides a schematic diagram of the architecture of a business system in a server, which may be the architecture of the business system in the above application scenario, such as Fig. 22 As shown, the business system includes a proxy layer, a logic layer, a service layer and a storage layer. If the business system is the background system of the reading software, the proxy layer may include a module for traffic forwarding, the logic layer may include interface logic, open logic, etc., the service layer may include query services, reading services, etc., and the storage layer may include various databases, such as Redis, Mysql and other types of databases.

[0188] based on Fig. 22 In the business system framework, the embodiment of the present application provides a test case running method. If the HTTP and RPC requests are unified in form, the description form is as follows:

[0189] HTTP access method: http: / / host:port / urlpath+reqbody.

[0190] RPC access method: hikit: / / ip:port / method+reqbody.

[0191] Through this unified description form, combined with the architecture of the business system, a universal access method can be designed. From the proxy layer downwards, all calls are to business modules of the business system. HTTP accesses the logic layer, and RPC accesses the service layer. Then you only need to configure the module to which the test case belongs. You can distinguish and address HTTP and RPC requests through the module name + Client configuration. When the test case is running, it determines whether the request method is HTTP protocol or RPC protocol; if it is HTTP protocol, the business module domain name is obtained from the configuration file of the business system through the module name of the business module, and the IP address and port address of the logic module are obtained through domain name query. Based on this, an HTTP request is initiated, and the request response is obtained. The processing result of the request response is verified according to the verification rules to obtain the test result; if it is RPC protocol, the service module configuration file is obtained from the business system through the module name of the business module, and the IP address and port address of the service module are obtained from it. The proto file is obtained and the reflection capability (data conversion capability, summoning the request data into a form supported by the protocol) is used to parse the protocol. Based on this, an RPC request is initiated, and the request response is obtained. The processing result of the request response is verified according to the verification rules to obtain the test result. In the test process of the RPC protocol, you only need to configure the module name, and you can get all the information of the RPC service through the module name, including its interface definition, request data packet definition, and response data packet definition. It can be expanded based on the business system architecture and online environment, which can improve the scalability of the RPC framework.

[0192] In the embodiment of the present application, the above verification rules can be assertion rules, which are generated by the JSON Schema and JSON Path integration tool, or the JSON Schema can be reversely generated based on the existing JSON assertion rules, and then a simple modification is made on the basis of this JSON Schema to obtain the final assertion rules, reducing the workload and time cost of editing use cases, wherein JSON Path is a supplement to the shortcomings of JSON Schema, and JSON Schema is a pattern constraint on JSON data, but it cannot extract fields in JSON data and compare two fields in JSON data. JSON Path is an information extraction tool for JSON data, which can extract specific values, objects or arrays from JSON data, as well as perform operations such as filtering, sorting and aggregation. It is worth noting that JSON Schema and JSON Path assertion verification are not two-choice, which can be verified at the same time, or any verification method can be selected according to the scenario. At the same time, if the protocol for the project client to interact with the business system is XML, proto or other protocols, in order to prevent the development of a similar set of tools for each serialized protocol, duplication of work, it can be uniformly converted to JSON format, JSON is easier to understand and more convenient for JSON Schema and JSON Path integration tools to process.

[0193] In an embodiment of the present application, if the test case fails, it is possible to check whether the interface in the corresponding business module is faulty. If so, the interface fault can be repaired. If it is not an interface fault, the test case can be removed, replaced and optimized, and then the test case obtained after removal, replacement and optimization can be re-executed to obtain the test result.

[0194] Among them, remove the test case, for example, if the request parameters are changed and the test case is invalid, delete the test case directly. Replace the test case, for example, if the test case does not meet the expected effect, select the business request and request response with the same business logic as this test case from the online, select the target request data, regenerate a new test case, and replace the test case that does not meet the expected effect.

[0195] Optimize the Schema, for example, some fields in the test case are not required fields, or are expected changes (for example, some fields are replaced when the user's unpurchased status changes to purchased status). The Schema generation tool used is genson, which can generate the corresponding JSON Schema for a JSON data. This tool has an important feature: it is a multi-input JSON Schema generation tool that can receive multiple JSON data or Schema as input parameters and generate a Schema that meets all input requirements without the need to manually edit the validation rules.

[0196] The present application embodiment provides an application scenario, such as Fig.23 As shown, the application scenario includes any server 2310 among multiple servers, any server 2320 among multiple servers, any server 2330 among multiple servers, any server 2340 among multiple servers, and any server 2350 among multiple servers, wherein the business system is run in server 2310, and when the business system runs the test case, the test task of the test case can be sent to server 2320, and the test task of the test case is obtained from server 2320 in turn for execution, and the test case operation pressure is relieved through the message queue service in server 2320. Server 2330 collects historical business data in the business system, automatically generates test cases and stores them in server 2310, and a management system is run in server 2350, which can obtain test cases and test case information from server 2310 or server 2330, based on which the case management page is displayed, and a scenario case group is generated. A change system is run in server 2340, which can be used for the change service of the business system. When server 2340 updates the business system in server 2310, server 2330 can be triggered to automatically generate test cases.

[0197] In an embodiment of the present application, after the test results are obtained by executing the above-mentioned method processes, a test report can also be generated, and the identification, test time and other related information of each test report can be displayed on the test report page of the management system. After triggering the information of a test report, you can jump to the test case execution details interface.

[0198] In a second aspect, the present application embodiment provides a test case generating device 2400, which is applicable to a test system, such as Fig.24 As shown, the device comprises:

[0199] The data screening unit 2410 is used to screen out the target request data set of each business module from each historical business data processed by the business system based on a preset parameter screening rule, wherein the target request data at least includes: the request mode, request parameters and request processing result of the corresponding business module in a business request process; wherein the request mode and the request parameters meet the parameter screening rule;

[0200] The processing unit 2420 is configured to execute the following steps respectively for each target request data associated with each business module:

[0201] The rule generating unit 2421 is used to determine the data type of the request processing result contained in a target request data of a business module, obtain a rule template preset corresponding to the data type, and set the request processing result to the rule template to obtain a corresponding verification rule, wherein the verification rule is used to verify the execution result of the business logic of the business module;

[0202] The use case generating unit 2422 is used to obtain a corresponding test case based on the request mode and request parameters of the target request data in combination with the verification rule.

[0203] Optionally, the use case generation unit 2422 is specifically used to obtain a corresponding test case based on the request method and request parameters of the target request data, combined with the verification rules and supplementary verification rules, and the supplementary verification rules are used to verify the data format of the corresponding request processing result.

[0204] Optionally, the processing unit 2420 is further configured to:

[0205] Sending the test case to the business system so that the management system obtains the test case and case information from the business system, wherein the case information includes a module name of the business module corresponding to the test case, a case identifier, and module names of other business modules associated with the corresponding business module;

[0206] The test case and the case information are displayed on a management page by the management system, so that the management system generates a scenario case group in response to a case selection operation and a case group generation operation, wherein the scenario case group includes a plurality of scenario test cases with a set execution order, and each scenario test case in the scenario case group corresponds to a business module, which is used to complete a processing process of a business scenario according to the set execution order;

[0207] The scenario use case group is sent to the business system through the management system.

[0208] Optionally, the processing unit 2420 is further configured to:

[0209] By means of the management system, the scenario use case group is displayed on a use case group page, so that the management system generates a change scenario use case group in response to the setting address operation;

[0210] The setting address operation is used to set a setting storage address in the change scenario use case group, so that when the change scenario use case group is executed, the setting request data in the upstream scenario test case that has been executed in the scenario use case group is stored in the setting storage address, and the downstream scenario test case in the scenario use case group obtains the setting request data from the setting storage address and executes it;

[0211] The change scenario use case group is sent to the business system through the management system.

[0212] Optionally, the data screening unit 2410 is further configured to:

[0213] Based on the data screening rule, the historical business data are screened from the initial business data, and the data screening rule is: the business request process is complete and the execution status is a success status.

[0214] Optionally, the data screening unit 2410 is specifically configured to:

[0215] For each of the business modules, perform the following steps respectively:

[0216] Extracting data parts that meet the parameter screening rules from each historical business data associated with a business module as corresponding historical request data;

[0217] Based on the obtained multiple historical request data, statistics are generated on the application of at least one existing request mode and request parameter, wherein the application includes: at least one of the value range of the request parameter with continuous values, the enumeration of the request parameter with discrete values ​​in the multiple historical request data, and the combination of multiple request parameters in one service request;

[0218] Based on the at least one request mode and the application situation, non-repetitive target request data are screened out from the plurality of historical request data to obtain a target request data set of the one business module.

[0219] Optionally, the data screening unit 2410 is specifically configured to:

[0220] For each historical business data associated with the business module, perform the following operations respectively:

[0221] Extract a request data packet and a corresponding response data packet from a historical business data;

[0222] Filtering out the request mode and request parameters that meet the parameter screening rule from the packet header and the packet body of the request data packet respectively;

[0223] Filtering out request processing results that meet the parameter screening rules from the packet body of the response data packet;

[0224] The obtained request method, request parameters and request processing results are used as historical request data.

[0225] Optionally, the data screening unit 2410 is further configured to screen out new request data of a target business module from the latest business data processed by the business system based on the preset parameter screening rule, where the target business module is a business module that has existed in the business system from the beginning or a newly added business module;

[0226] The rule generating unit 2421 is further configured to determine, based on the newly added request data of the target business module, a data type of a newly added processing result included in the newly added request data, obtain a rule template preset corresponding to the data type of the newly added processing result, and set the newly added processing result to the rule template to obtain a corresponding newly added verification rule, wherein the newly added verification rule is used to verify the execution result of the business logic of the target business module;

[0227] The use case generation unit 2422 is further configured to obtain a corresponding new test case based on the request mode and request parameters of the new request data in combination with the new verification rule.

[0228] Optionally, the use case generating unit 2422 is specifically used to:

[0229] Based on the request mode and request parameters of the target request data, combined with the verification rules and the preset protocol path, a corresponding test case is obtained. When the test case is executed, the preset protocol path is used to obtain the preset protocol from the business system and convert the test request generated by the test case into a format recognizable by the corresponding business module.

[0230] Based on the same inventive concept as the above method embodiment, the present application embodiment also provides a computer device. In one embodiment, the computer device may be a server, such as Figure 1 and Figure 2 The server 120 and the server 230 shown in FIG. 1 are shown in FIG. 1 . In this embodiment, the structure of the computer device can be as follows: Fig.25 As shown, it includes a memory 2501, a communication module 2503 and one or more processors 2502.

[0231] The memory 2501 is used to store computer programs executed by the processor 2502. The memory 2501 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and programs required for running the instant messaging function, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0232] The memory 2501 may be a volatile memory, such as a random-access memory (RAM); the memory 2501 may also be a non-volatile memory, such as a read-only memory, a flash memory, a hard disk drive (HDD) or a solid-state drive (SSD); or the memory 2501 may be any other medium that can be used to carry or store a desired computer program in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 2501 may be a combination of the above memories.

[0233] The processor 2502 may include one or more central processing units (CPU) or a digital processing unit, etc. The processor 2502 is used to implement the above test case generation method when calling the computer program stored in the memory 2501 .

[0234] The communication module 2503 is used to communicate with terminal devices and other servers.

[0235] The specific connection medium between the memory 2501, the communication module 2503 and the processor 2502 is not limited in the embodiment of the present application. Fig.25 In the embodiment, the memory 2501 and the processor 2502 are connected via a bus 2504. The bus 2504 is connected to the processor 2502 via a bus 2504. Fig.25 The connections between the other components are only for illustration and are not intended to be limiting. The bus 2504 can be divided into an address bus, a data bus, a control bus, etc. For ease of description, Fig.25 The diagram shows that only one thick line is used, but this does not mean that there is only one bus or only one type of bus.

[0236] The memory 2501 stores a computer storage medium, and the computer storage medium stores computer executable instructions, and the computer executable instructions are used to implement the test case generation method of the embodiment of the present application. The processor 2502 is used to execute the above test case generation method, such as Figure 3 or Figure 4 or Fig.13 or Fig.17 or Fig.18 shown.

[0237] In another embodiment, the computer device may also be other computer devices, such as Figure 2 The terminal device 210 shown in FIG. 1 is a terminal device 210 shown in FIG. 1 . In this embodiment, the structure of the computer device can be as follows: Fig.26 As shown, it includes: a communication component 2610, a memory 2620, a display unit 2630, a camera 2640, a sensor 2650, an audio circuit 2660, a Bluetooth module 2670, a processor 2680 and other components.

[0238] The communication component 2610 is used to communicate with the server. In some embodiments, a circuit wireless fidelity (Wireless Fidelity, WiFi) module may be included. The WiFi module belongs to a short-range wireless transmission technology. The computer device can help the user to send and receive information through the WiFi module.

[0239] The memory 2620 can be used to store software programs and data. The processor 2680 executes various functions and data processing of the terminal device 210 by running the software programs or data stored in the memory 2620. The memory 2620 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage device. The memory 2620 stores an operating system that enables the terminal device 210 to run. In the present application, the memory 2620 can store an operating system and various application programs, and can also store a computer program for executing the test case generation method in the embodiment of the present application.

[0240] The display unit 2630 can also be used to display information input by the user or information provided to the user and a graphical user interface (GUI) of various menus of the terminal device 210. Specifically, the display unit 2630 may include a display screen 2632 disposed on the front of the terminal device 210. The display screen 2632 may be configured in the form of a liquid crystal display, a light emitting diode, etc. The display unit 2630 may be used to display the test case generation user interface in the embodiment of the present application, etc.

[0241] The display unit 2630 can also be used to receive input digital or character information and generate signal input related to user settings and function control of the terminal device 110. Specifically, the display unit 2630 may include a touch screen 2631 arranged on the front of the terminal device 210, which can collect user touch operations on or near it, such as clicking a button, dragging a scroll box, etc.

[0242] The touch screen 2631 can be covered on the display screen 2632, or the touch screen 2631 and the display screen 2632 can be integrated to realize the input and output functions of the terminal device 210, and the integrated display screen can be referred to as a touch display screen. In this application, the display unit 2630 can display the application and the corresponding operation steps.

[0243] Camera 2640 can be used to capture still images, and users can post comments on images taken by camera 2640 through the application. Camera 2640 can be one or more. The object generates an optical image through the lens and projects it onto the photosensitive element. The photosensitive element can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, and then passes the electrical signal to the processor 2680 to convert it into a digital image signal.

[0244] The terminal device may further include at least one sensor 2650, such as an acceleration sensor 2651, a distance sensor 2652, a fingerprint sensor 2653, and a temperature sensor 2654. The terminal device may also be configured with other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, a light sensor, and a motion sensor.

[0245] The audio circuit 2660, the speaker 2661, and the microphone 2662 can provide an audio interface between the user and the terminal device 110. The audio circuit 2660 can transmit the electrical signal converted from the received audio data to the speaker 2661, which is converted into a sound signal for output. The terminal device 210 can also be configured with a volume button for adjusting the volume of the sound signal. On the other hand, the microphone 2662 converts the collected sound signal into an electrical signal, which is received by the audio circuit 2660 and converted into audio data, and then the audio data is output to the communication component 2610 to be sent to, for example, another terminal device 210, or the audio data is output to the memory 2620 for further processing.

[0246] The Bluetooth module 2670 is used to exchange information with other Bluetooth devices having Bluetooth modules through the Bluetooth protocol. For example, the terminal device can establish a Bluetooth connection with a wearable computer device (such as a smart watch) that also has a Bluetooth module through the Bluetooth module 2670 to exchange data.

[0247] The processor 2680 is the control center of the terminal device. It uses various interfaces and lines to connect various parts of the entire terminal. It executes various functions of the terminal device and processes data by running or executing software programs stored in the memory 2620 and calling data stored in the memory 2620. In some embodiments, the processor 2680 may include one or more processing units; the processor 2680 may also integrate an application processor and a baseband processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the baseband processor mainly processes wireless communications. It is understandable that the above-mentioned baseband processor may not be integrated into the processor 2680. In the present application, the processor 2680 can run the operating system, application programs, user interface display and touch response, as well as the test case generation method of the embodiment of the present application. In addition, the processor 2680 is coupled to the display unit 2630.

[0248] In some possible implementations, various aspects of the test case generation method provided by the present application may also be implemented in the form of a program product, which includes a computer program. When the program product is run on a computer device, the computer program is used to enable the computer device to execute the steps of the test case generation method according to various exemplary embodiments of the present application described above in this specification. For example, the computer device may execute the following steps: Figure 3 or Figure 4 or Fig.13 or Fig.17 or Fig.18 Follow the steps shown in .

[0249] The program product may use any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0250] The program product of the embodiment of the present application may adopt a portable compact disk read-only memory (CD-ROM) and include a computer program, and can be run on a computer device. However, the program product of the present application is not limited thereto, and in this document, a readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with a command execution system, apparatus, or device.

[0251] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, wherein a readable computer program is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. A readable signal medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with a command execution system, apparatus, or device.

[0252] The computer program embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0253] The computer program for performing the operations of the present application may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The computer program may be executed entirely on the user's computer device, partially on the user's device, as a separate software package, partially on the user's computer device and partially on a remote computer device, or entirely on a remote computer device or server. In the case of a remote computer device, the remote computer device may be connected to the user's computer device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer device (e.g., via the Internet using an Internet service provider).

[0254] It should be noted that, although several units or subunits of the device are mentioned in the above detailed description, this division is merely exemplary and not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided into multiple units to be embodied.

[0255] In addition, although the operations of the method of the present application are described in a specific order in the drawings, this does not require or imply that the operations must be performed in this specific order, or that all the operations shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0256] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0257] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0258] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0259] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0260] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A test case generation method, characterized in that: Applicable to a test system, the method comprises: Based on the preset parameter screening rules, a target request data set of each business module is screened out from each historical business data processed by the business system, wherein the target request data at least includes: a request method, request parameters and request processing result of the corresponding business module in a business request process; wherein the request method and the request parameters conform to the parameter screening rules; For each target request data associated with each business module, perform the following steps respectively: Based on a target request data of a business module, determine the data type of the request processing result contained in the target request data, obtain a rule template preset corresponding to the data type, and set the request processing result to the rule template to obtain a corresponding verification rule, wherein the verification rule is used to verify the execution result of the business logic of the business module; Based on the request mode and request parameters of the target request data and in combination with the verification rules, a corresponding test case is obtained.

2. The method according to claim 1, characterized in that The step of obtaining a corresponding test case based on the request mode and request parameters of the target request data in combination with the verification rule includes: Based on the request mode and request parameters of the target request data, a corresponding test case is obtained in combination with the verification rule and the supplementary verification rule, and the supplementary verification rule is used to verify the data format of the corresponding request processing result.

3. The method according to claim 1, characterized in that After obtaining a corresponding test case based on the request mode and request parameters of the target request data in combination with the verification rule, the method further includes: Sending the test case to the business system so that the management system obtains the test case and case information from the business system, wherein the case information includes a module name of the business module corresponding to the test case, a case identifier, and module names of other business modules associated with the corresponding business module; The test case and the case information are displayed on a management page by the management system, so that the management system generates a scenario case group in response to a case selection operation and a case group generation operation, wherein the scenario case group includes a plurality of scenario test cases with a set execution order, and each scenario test case in the scenario case group corresponds to a business module, which is used to complete a processing process of a business scenario according to the set execution order; The scenario use case group is sent to the business system through the management system.

4. The method according to claim 3, characterized in that Before sending the scenario use case group to the business system through the management system, the method further includes: By means of the management system, the scenario use case group is displayed on a use case group page, so that the management system generates a change scenario use case group in response to the setting address operation; The setting address operation is used to set a setting storage address in the change scenario use case group, so that when the change scenario use case group is executed, the setting request data in the upstream scenario test case that has been executed in the scenario use case group is stored in the setting storage address, and the downstream scenario test case in the scenario use case group obtains the setting request data from the setting storage address and executes it; The change scenario use case group is sent to the business system through the management system.

5. The method according to any one of claims 1 to 4, characterized in that: Before filtering out the target request data set of each business module from the historical business data processed by the business system based on the preset parameter screening rules, the method further includes: Based on the data screening rule, the historical business data are screened from the initial business data, and the data screening rule is: the business request process is complete and the execution status is a success status.

6. The method according to any one of claims 1 to 4, characterized in that: The method of filtering out the target request data set of each business module from the historical business data processed by the business system based on the preset parameter screening rules includes: For each of the business modules, perform the following steps respectively: Extracting data parts that meet the parameter screening rules from each historical business data associated with a business module as corresponding historical request data; Based on the obtained multiple historical request data, statistics are generated on the application of at least one existing request mode and request parameter, wherein the application includes: at least one of the value range of the request parameter with continuous values, the enumeration of the request parameter with discrete values ​​in the multiple historical request data, and the combination of multiple request parameters in one service request; Based on the at least one request mode and the application situation, non-repetitive target request data are screened out from the plurality of historical request data to obtain a target request data set of the one business module.

7. The method according to claim 6, characterized in that The extracting of data parts that meet the parameter screening rules from each historical business data associated with a business module as corresponding historical request data includes: For each historical business data associated with the business module, perform the following operations respectively: Extract a request data packet and a corresponding response data packet from a historical business data; Filtering out the request mode and request parameters that meet the parameter screening rule from the packet header and the packet body of the request data packet respectively; Filtering out request processing results that meet the parameter screening rules from the packet header and the packet body of the response data packet; The obtained request method, request parameters and request processing results are used as historical request data.

8. The method according to any one of claims 1 to 4, characterized in that: After filtering out the target request data set of each business module from the historical business data processed by the business system based on the preset parameter screening rules, the method further includes: Based on the parameter screening rule, newly added request data of a target business module is screened out from the latest business data processed by the business system, where the target business module is a business module that has existed in the business system from the beginning or a newly added business module; Based on the newly added request data of the target business module, determine the data type of the newly added processing result contained in the newly added request data, obtain a rule template preset corresponding to the data type of the newly added processing result, and set the newly added processing result to the rule template to obtain a corresponding newly added verification rule, wherein the newly added verification rule is used to verify the execution result of the business logic of the target business module; Based on the request method and request parameters of the newly added request data and in combination with the newly added verification rules, a corresponding newly added test case is obtained.

9. The method according to any one of claims 1 to 4, characterized in that: The step of obtaining a corresponding test case based on the request mode and request parameters of the target request data in combination with the verification rule includes: Based on the request mode and request parameters of the target request data, combined with the verification rules and the preset protocol path, a corresponding test case is obtained. When the test case is executed, the preset protocol path is used to obtain the preset protocol from the business system and convert the test request generated by the test case into a format recognizable by the corresponding business module.

10. A test case generating device, characterized in that: Suitable for a test system, the device comprises: A data screening unit, configured to screen out a target request data set of each business module from each historical business data processed by the business system based on a preset parameter screening rule, wherein the target request data at least includes: a request method, request parameters and request processing result of the corresponding business module in a business request process; wherein the request method and the request parameters conform to the parameter screening rule; The processing unit is used to perform the following steps for each target request data associated with each business module: A rule generation unit, configured to determine, based on a target request data of a business module, a data type of a request processing result contained in the target request data, obtain a rule template preset corresponding to the data type, and set the request processing result to the rule template to obtain a corresponding verification rule, wherein the verification rule is used to verify the execution result of the business logic of the business module; The use case generation unit is used to obtain a corresponding test case based on the request mode and request parameters of the target request data in combination with the verification rule.

11. The device according to claim 10, characterized in that The use case generation unit is specifically used to obtain a corresponding test case based on the request mode and request parameters of the target request data, combined with the verification rules and supplementary verification rules, and the supplementary verification rules are used to verify the data format of the corresponding request processing result.

12. The device according to claim 10, characterized in that The processing unit is further configured to: Sending the test case to the business system so that the management system obtains the test case and case information from the business system, wherein the case information includes a module name of the business module corresponding to the test case, a case identifier, and module names of other business modules associated with the corresponding business module; The test case and the case information are displayed on a management page by the management system, so that the management system generates a scenario case group in response to a case selection operation and a case group generation operation, wherein the scenario case group includes a plurality of scenario test cases with a set execution order, and each scenario test case in the scenario case group corresponds to a business module, which is used to complete a processing process of a business scenario according to the set execution order; The scenario use case group is sent to the business system through the management system.

13. A computer-readable non-volatile storage medium, characterized in that: The computer-readable non-volatile storage medium stores a program, and when the program is run on a computer, the computer is enabled to implement the method according to any one of claims 1 to 9.

14. A computer device, characterized in that: include: Memory for storing computer programs; A processor, configured to call a computer program stored in the memory, and execute the method according to any one of claims 1 to 9 according to the obtained program.

15. A computer program product, characterized in that The method comprises a computer program, wherein the computer program is stored in a computer-readable storage medium; when a processor of a computer device reads the computer program from the computer-readable storage medium, the processor executes the computer program, so that the computer device executes the method according to any one of claims 1 to 9.

Images