Test code generation method and related equipment

Abstract

The invention relates to a test code generation method and related equipment. The method comprises the following steps: monitoring communication information between a terminal and a server; generating a test code with a three-layer structure based on the communication information; wherein the test code of the three-layer structure comprises an entry layer, an assertion layer and an interface layer, the entry layer is used for organizing test logic, the assertion layer is used for forwarding request data transmitted by the entry layer and receiving request result data returned by the interface layer, and data verification is carried out through an expected result transmitted by the entry layer and the request result data returned by the interface layer; and the interface layer is used for recording a request url path and triggering a request through a request tool to return request result data to the interface layer. Therefore, the test code with a three-layer structure can be generated by monitoring the communication information between the terminal and the server, so that a tester can quickly complete automatic case code writing through the generated test code.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software testing, in particular to a test code generation method and related equipment. BACKGROUND

[0002] With the continuous development of technology, the scale of software in the development process is getting larger and larger, and the structure is more and more complex, so that the testing of software system becomes more and more difficult. Therefore, in order to reduce the difficulty of software testing and simplify the process of software testing, and reduce the human error caused by the complex repetitive work in manual testing, automated test cases emerge as the times require.

[0003] In the related art, the test case is usually written by the tester, and the tester needs to have a certain understanding of the business involved in the software to be tested. With the accumulation of time, the size of the test case gradually becomes larger, and the execution of the test case consumes more human and time costs, so it is necessary to quickly automate the test case written by the tester to improve the efficiency of software regression testing. However, the related art has high requirements for the tester when generating the test case, which leads to low efficiency of generating the test case. SUMMARY

[0004] The embodiments of the present application provide a test code generation method and related equipment, which can quickly complete the automatic case code writing and support the ability of automatic case execution in multiple environments.

[0005] According to the first aspect of the present application, a test code generation method is provided, which comprises:

[0006] listening to the communication information between the terminal and the server;

[0007] generating a test code with a three-layer structure based on the communication information; wherein the test code with the three-layer structure comprises: an entry layer, an assertion layer and an interface layer, the entry layer is used to organize test logic, the assertion layer is used to forward the request data transmitted by the entry layer and receive the request result data returned by the interface layer, and the expected result transmitted by the entry layer and the request result data returned by the interface layer are verified, and the interface layer is used to record the request url path, and the request result data is returned to the interface layer by triggering the request through the request tool.

[0008] The scheme can generate a test code with a three-layer structure by listening to the communication information between the terminal and the server, so that the tester can quickly generate a test case through the test code, can quickly complete the automatic case code writing, and can greatly improve the processing efficiency.

[0009] In a possible implementation, the test code with the three-layer structure is generated based on the communication information, comprising:

[0010] Obtaining query parameters in a request method, a request type, a request body, and a request path in the communication information;

[0011] Uniformly formatting the query parameters in the request method, the request type, the request body, and the request path into a json format to obtain test code with a three-layer structure; wherein, an entry layer includes a class name, a method name, and test logic; an interface layer includes a class name, a method name, and a url path in a request path; and an assertion layer includes a class name, a method name, and assertion logic.

[0012] The scheme can clearly organize test case logic in the entry layer, is responsible for return result verification based on the assertion layer, and is used to record request url and provide reference examples of request input parameters based on the interface layer by generating a three-layer structure with three-layer calling logic.

[0013] In a possible implementation, the method further includes:

[0014] The request data and the expected result are transmitted through the entry layer, and the assertion layer is reused.

[0015] The entry layer calls the assertion layer, the assertion layer calls the interface layer, and the interface layer calls the request tool; the assertion layer receives the request data and the expected result, and generates structured code according to the test code according to different request methods and request types.

[0016] In a possible implementation, the method further includes:

[0017] The request data is transmitted through the entry layer, and the assertion layer is called.

[0018] The request data transmitted by the entry layer is forwarded through the assertion layer, and the request result returned by the interface layer is asserted; wherein, the request result needs to be returned to the entry layer for the normal scenario to organize scene test cases through the entry layer; the interface layer only includes a url path and does not include environment information; and the test code with the three-layer structure only includes business related information.

[0019] In the scheme, the interface layer only includes a url path and does not include environment information; and the test code with the three-layer structure only includes business related information, so that the quick reuse of code examples can be realized.

[0020] In a possible implementation, the assertion layer includes normal assertion and abnormal assertion, and the method further includes:

[0021] For the normal assertion of the expected operation success, if no trigger data verification error occurs, the result after the operation is returned.

[0022] For the abnormal assertion of the expected operation failure, the returned result and the expected error code value, and the input expected result are reused through the data verification logic of the assertion layer.

[0023] If no data verification error is triggered in the scheme, the result after operation is returned, so as to organize a complex test scene or organize a tool for the entry layer. When a verification error is triggered, an error log and returned error information can be recorded.

[0024] In a possible implementation, the method further includes:

[0025] extracting a business module and a sub-business module from an interface feature of the request path;

[0026] generating class names in the entry layer, the assertion layer and the interface layer respectively based on preset markers, the business module and the sub-business module.

[0027] The scheme forms class names in a unified format, facilitating the calling between the three layers.

[0028] In a possible implementation, the method further includes:

[0029] generating a method name of the entry layer based on a preset prefix, a request method and a preset formatted request path;

[0030] generating method names of the assertion layer and the interface layer based on the request method and the preset formatted request path.

[0031] The scheme forms method class names in a unified format, facilitating the calling between the three layers.

[0032] According to the second aspect of the present application, a test code generation device is provided, which includes:

[0033] a listening module configured to listen to communication information between a terminal and a server;

[0034] a test code generation module configured to generate test code with a three-layer structure based on the communication information; wherein the test code with the three-layer structure includes an entry layer, an assertion layer and an interface layer, the entry layer is configured to organize test logic, the assertion layer is configured to forward request data transmitted by the entry layer and receive request result data returned by the interface layer, and perform data verification on the request result data returned by the interface layer through expected results transmitted by the entry layer, and the interface layer is configured to record a request url path, and return request result data to the interface layer through a request triggered by a request tool.

[0035] According to the third aspect of the present application, a server is provided. The server includes a memory and a processor, the memory stores a computer program, and the processor executes the program to realize the method as described above.

[0036] According to a fourth aspect of the present application, a computer readable storage medium is provided, having stored thereon a computer program which, when executed by a processor, implements the above method of the present application.

[0037] According to a fifth aspect of the present application, a computer program product is provided, comprising a computer program which, when executed by a processor, implements the above method of the present application. BRIEF DESCRIPTION OF DRAWINGS

[0038] In the following description of the example embodiments, with reference to the accompanying drawings, more details, features and advantages of the present application are disclosed, in which:

[0039] Figure 1 A system architecture schematic diagram is provided for an example embodiment of the present application;

[0040] Figure 2 An assertion layer reusability scheme schematic block diagram is provided for an example embodiment of the present application;

[0041] Figure 3 An assertion layer reusability scheme schematic block diagram is provided for another example embodiment of the present application;

[0042] Figure 4 An assertion layer reusability scheme schematic block diagram is provided for yet another example embodiment of the present application;

[0043] Figure 5 A multi-environment execution scheme schematic block diagram is provided for an example embodiment of the present application;

[0044] Figure 6 A test code generation method flowchart schematic diagram is provided for an example embodiment of the present application;

[0045] Figure 7 A test code generation device functional module schematic block diagram is provided for an example embodiment of the present application;

[0046] Figure 8 A server structure block diagram is provided for an example embodiment of the present application. DETAILED DESCRIPTION

[0047] Embodiments of the present application will be described in more detail by referring to the attached drawings. Although certain embodiments of the present application are shown in the drawings, it is understood that the present application can be implemented in various forms and should not be interpreted as being limited to the embodiments set forth herein, but rather these embodiments are provided to make the present application more thorough and complete. It is understood that the drawings and embodiments of the present application are for exemplary purposes only and should not be construed as limiting the scope of protection of the present application.

[0048] The term "include," and derivations thereof, is an open term that means "including, but not limited to." The term "based on" means "based at least in part on." The term "one embodiment" means "at least one embodiment;" the term "another embodiment" means "at least one additional embodiment;" the term "some embodiments" means "at least some embodiments." Related terms shall be construed accordingly. It should be noted that the use of "a" or "an" in the application is intended to mean "one or more" unless explicitly indicated to the contrary.

[0049] It should be noted that the use of "one", "multiple", "some" or "another" in the application is illustrative and not limiting, and it should be understood that, unless explicitly indicated to the contrary, "one" or "another" should be interpreted as "one or more".

[0050] The names of the messages or information exchanged between the devices in the embodiments of the present application are only for illustrative purposes, and are not intended to limit the scope of the messages or information.

[0051] It can be understood that, before using the technical solutions disclosed in the embodiments of the present application, the type, scope of use, use scenario, etc. of the personal information involved in the present application should be informed to the user and the authorization of the user should be obtained in accordance with relevant laws and regulations.

[0052] In order to improve the efficiency of test case writing, as shown in Figure 1 , the test case writing method comprises the following steps. Figure 1A system architecture scenario diagram is provided for implementation of the present application. The system can include a proxy device 10, a server 20, and a terminal 30. A tester can add the proxy device 10 between the server 20 and the terminal 30 when the tester interacts with the terminal 30 and the server 20. The proxy device 10 can be a proxy server or a proxy module on the server. The proxy device 10 can capture request data between the terminal 30 and the server 20 and response result data returned by the server. After customization of the proxy tool, there are three layers of structured interface code generation rules inside. The business and sub-business can be extracted from the url (uniform resource locator), the formatted url path and request method can be used as the method name, the formatted url can also extract the QueryParam parameter and convert it into json format; the request method (Method) + request content type + request body can parse the request body in the request data into json format; the entry layer class name is Test + business module, the assertion layer class name is Assert + business module, the interface layer class name is Api + business module, and a unified format class name is formed; the entry layer method name is test_ + case number, which needs to be adjusted by the tester, the default is test_ + request method + url path after Snack, the assertion layer method and the interface layer method are both the url path after Snack, and the formatted url path forms a call relationship (for example Figure 1 ), the generated code entry layer calls the assertion layer, the assertion layer calls the interface layer, and the interface layer calls the request tool.

[0053] Specifically, the above request data can include: request header (content-type), request path, request body, and request method. The proxy device 10 will preprocess the request path and request method in the test request, and convert the request body into JSON format.

[0054] In the embodiment, the request path can be a url, for example, the url can be / api / business / v1 / module / query-list?module=123, and the url can be preprocessed as follows:

[0055] (1) Extract the first business identifier: business, which is usually used to mark the class name.

[0056] (2) Extract the second business identifier: module. If it matches the configuration file, it is extracted as the second business, which is usually used with the first business to mark the class name, and the user can more clearly understand the interface module.

[0057] (3) Request type + url path after Snack formatting:

[0058] For example, get_module_query_list, post_module_query_list, which are usually used to mark the method name, add the request method in front, and can clearly know the type of backend request.

[0059] (4) Query parameter preprocessing:

[0060] For example, convert module = 123 to {“module”: 123}, and unify the global parameter passing mode, so that the Api layer is more easily adapted to dynamic parameters.

[0061] The embodiments of the application can generate a test case template with a three-layer structure, namely a Test layer, an Assert layer and an Api layer. Among them, the Test layer is the entry layer, used to organize the use case logic, the Assert layer is the assertion layer used to verify the return result, and the Api layer is the interface layer used to record the request path and record the parameter request example.

[0062] In the Test layer, class name construction, method name construction, request data generation and triggering assertion layer call are included.

[0063] (1) Class name construction.

[0064] The first-level business identifier (such as business) and the second-level business identifier (such as module) are extracted from the preprocessed request path, and the class name is generated by combination: Test + first-level business identifier + second-level business identifier (example: TestBusinessModule).

[0065] (2) Method name construction.

[0066] The fixed prefix test_ + request method + Snack after url path (test personnel need to associate specific use cases later) is used.

[0067] Add case labels through function decorators: such as environment, business, use case level and other refined differentiated labels, etc., which can quickly filter case execution.

[0068] (3) Request data generation.

[0069] The captured original request body is converted into JSON (javascript object notation) format as a test data input example.

[0070] (4) Triggering assertion layer call.

[0071] According to the generation assertion layer rule, through the class name AssertBusinessModule. static method, the static method is the method name in the Assert layer which will be introduced in the next part.

[0072] Note: complex scenarios are usually composed of multiple interfaces, one interface will depend on the data returned by another interface as the incoming parameters of the next interface. The entry layer is more to organize request data and trigger requests, and finally verify the scenario results.

[0073] In the Assert layer, including class name construction, method name construction, recording interface operation log, triggering interface layer call to get returned request result, request result verification, returned request result (complex scenario use case logic organization needs):

[0074] (1) Class name construction.

[0075] From the preprocessed request path, extract the first business identifier (such as business) and the second business identifier (such as module), and combine to generate the class name: Assert + first business identifier + second business identifier (example: AssertBusinessModule).

[0076] (2) Method name construction.

[0077] Use the request method + Snick after the url path as the method name, for example: url_path = / api / business / v1 / module / detail, the request method is POST type, and the Content-Type is application / json type, and the formatted method name is post_module_detail.

[0078] (3) Record interface operation log.

[0079] Record the interface corresponding page position, interface function. Record the operation log in the assertion layer, so you don't need to write operation log logic in all the entry layer organization logic that uses this interface. This way, the use case log executed can clearly record the interface call order, and can be audited in reverse through the log to find missing test points in automation, or unreasonable call logic. When the problem is reproduced, you can quickly find the corresponding module to reproduce the problem.

[0080] (4) Trigger interface layer call.

[0081] According to the generation interface layer rule, through the class name ApiBusinessModule. static method, trigger interface layer call, get interface layer call result.

[0082] (5) Request result verification.

[0083] The returned request result and the expected result of the incoming request layer are verified.

[0084] (6) The request result of the return interface layer.

[0085] The verified request result is returned to the entry layer. In complex use case scenarios, multiple interfaces need to be called, and the latter interface may depend on the data returned by the former interface.

[0086] In the Api layer, the class name construction, method name construction, request data example, request path url path, and trigger request tool call are included.

[0087] (1) Class name construction.

[0088] The first-level business identifier (such as business) and the second-level business identifier (such as module) are extracted from the preprocessed request path, and the class name is generated by combining them: Api+first-level business identifier+second-level business identifier (example: ApiBusinessModule).

[0089] (2) Method name construction.

[0090] The request method+Snecked url path is used as the method name, which is consistent with the assertion layer method name.

[0091] (3) Request parameter example.

[0092] In the embodiment, the request parameter example is generated when generating the test code, which is displayed below the interface layer in the form of a note in the interface layer. One function is that when writing test cases, testers can refer to the existing message body, adjust the parameters, and organize their own test scenarios. The second function is to record the interface input parameters at that time, so that after the subsequent interface changes, the interface parameter differences can be quickly found.

[0093] (4) Request path url path.

[0094] The request path url path is the part of the path after removing the domain name and the following parameters. Only the path is retained, such as:

[0095] https: / / localhost / api / business / v1 / datacenter / query-list?module="123", only:

[0096] api / business / v1 / datacenter / query-list, globally unique. The interface layer does not reflect the environment information, only the url path.

[0097] (5) Trigger request by request tool.

[0098] Interface layer dynamically matches request tool according to request type and request message content type. For example, if request type is POST and request message body type is application / json, call request tool of post type and get result data after request to return to calling assertion layer.

[0099] Request tool is a layer of tool encapsulated according to business characteristics, including class name, static method, conversion and organization of complete url, request data, etc., mainly to perfect the interface call lacking content:

[0100] (1) Method name accepts: request handle, request path, request body, and other default parameters.

[0101] a) Request handle: a kind of login user information obtained in the entry layer, which is mainly used in the scene where users frequently switch. For example, in the warehouse management scene, a process needs to be completed by multiple roles. For the scene where only one role is needed, it is actually more convenient to use the default user. Request handle contains cookies or session and environment basic information.

[0102] b) Request path: path only contains url path.

[0103] c) Request body: uniformly formatted json format, which is processed according to request method and type in request tool.

[0104] d) Other default parameters: such as timeout, whether to verify the book, use proxy, etc.

[0105] Note: If no handle is passed in, request handle will be automatically obtained according to the running time environment and user identification.

[0106] (2) Request path recovery:

[0107] a) get query class: if there is QueryParam, request path urlencode recovers QueryParam.

[0108] b) post creation class: adapt to the corresponding processing method according to the request Content-Type.

[0109] c) put update class: adapt to the corresponding processing method according to the request Content-Type.

[0110] d) delete class: adapt to the corresponding processing method according to the request Content-Type.

[0111] (3) Extension: such as statistical interface calls (used later for statistical execution of automated interface coverage), log output request path and request body (convenient for problem positioning and auditing), etc.

[0112] In the implementation case of the assertion layer reusability scheme:

[0113] In the Assert layer, normal assertions such as Figure 2 and Figure 4 , as well as exception assertions such as Figure 3 , can be included.

[0114] For assertions that expect successful operations such as updates, deletions, creations, and non-list class queries: such as Figure 2 , if no data validation errors are triggered, the result (response) after the operation is returned to facilitate the organization of complex test scenarios or the use of tools by the entry layer. When a validation error occurs, an error log is recorded and the error information is returned.

[0115] For assertions that expect all operations to fail: such as Figure 3 , assertions are made on the returned result and the expected error code value and error description. The advantage of this approach is that all entry layers only need to organize request data and input expected results, and the entry layer does not need to write data validation logic, and the data validation logic can be reused in the assertion layer.

[0116] Query class assertions: such as Figure 4 , assertions are made on each piece of returned data in the assertion layer; if the scenario being validated is a name query, the input name is not empty, then the returned name is verified to be the queried name; if the scenario being validated is a status query, no name is input at this time, then if name is false, the name will not be verified, only the returned status will be verified. For multi-page data, the current page number is automatically calculated, and the input page number is automatically changed to recursively call the content verification of the subsequent page numbers. The last page is verified by default. In addition to reusing the above assertion logic, the amount of data returned per page and the page size are compared, and the last page calculates the remaining number of data and the actual returned amount for comparison. If a combined query is used in the query, both name and status are queried at the same time, then if name and if status are both true, the name and status will be verified. Through this reuse logic, the automation efficiency is extremely high for table class query data, and the verification data dimension is fine enough. If a new query condition is added, the assertion layer only needs to add an if new condition, and the combined query only needs to be triggered in the entry layer. The efficiency improvement is particularly obvious.

[0117] Through the above three examples, by multiplexing assertions in the assertion layer, the code amount of the entry layer can be reduced, the entry layer can pay more attention to the business calling logic, the correspondence between the entry layer and the use case is more obvious, and the logic is clearer; for some special scenarios, the data verification granularity can be more fine.

[0118] In the implementation of the multi-environment execution scheme of the automated code, the following is provided:

[0119] The embodiments provided in the present application (such as Figure 5 ), through the three-layer code structure generated by the embodiments, the entry layer, the assertion layer, and the interface layer. In the three-layer structure, there is no environment-related information, which provides convenience for quickly supporting multi-environment execution, and by passing in the environment and the user tag at runtime, the target environment can be switched to execute;

[0120] Specific implementation: for each environment to be executed, there is a set of configurations, including environment access address, database information, and multiple automation user information, and the user to be used can be quickly obtained through the tag. The advantage of using the tag instead of directly using the specific user+password is that the internal user can modify and adjust the password without the need for the execution user to be aware of it, and only the identification of the corresponding user needs to be known; in this way, during the automation execution process, only the execution environment and the user tag need to be known, and the corresponding environment automation can be quickly run;

[0121] As shown in Figure 5 , if the alpha+userTag tag is passed in at runtime, the runtime environment is obtained in the request tool layer, then the environment configuration is searched according to the environment identification, and the user to be used by the environment is searched according to the user tag, and the login environment information and the user information are all stored in the operation handle (op: singleton mode) in the form of encapsulation, so that the environment information can be quickly obtained through the op. Then send the request to the alpha environment for execution; if the environment set at runtime is the bete and beta environment login user identification, then the beta environment configuration information and the user information to be used are searched, and the obtained information is stored in the operation handle, and in the actual request, the request is sent to the beta environment;

[0122] Based on the above embodiments, in another embodiment provided in the present application, as shown in Figure 6 , the present application further provides a test code generation method, which can be applied to the above-mentioned proxy device 10, and the method can further include the following steps:

[0123] In step S610, the communication information between the terminal and the server is listened to.

[0124] In the embodiments, the following can be combined Figure 1As shown, the agent device 10 can listen to the communication information between the terminal and the server, which is the interaction data between the terminal and the server, for example, when a user performs interface testing on a page of the terminal, the terminal sends a test request to the server, and the server sends response information to the terminal, and the like, and the embodiments are not limited thereto.

[0125] In step S620, the test code with a three-layer structure is generated based on the communication information.

[0126] The test code with a three-layer structure includes an entry layer, an assertion layer, and an interface layer. The entry layer is used to organize test logic. The assertion layer is used to forward incoming request data from the entry layer and receive request result data returned from the interface layer, and perform data verification on the expected result from the entry layer and the request result data returned from the interface layer. The interface layer is used to record request url paths and return request result data to the interface layer by triggering requests through a request tool.

[0127] The embodiments generate test code with a three-layer structure to generate code examples, and then expand the description. New test code for direct use can be generated each time a request is made. In this way, test personnel can quickly complete automated use case code writing through the generated test code, and can greatly improve processing efficiency.

[0128] In the embodiments, the agent device 10 and the pre-customized code generation rules can generate entry layer, assertion layer, and interface layer automation code examples with call relationships. Among the entry layer, the assertion layer, and the interface layer, the assertion layer and the interface layer are unique from a global perspective, and the entry layer can organize request data and expected results according to specific test case descriptions of scenarios, to achieve the purpose of reusing the assertion layer and the interface layer. Since the generated code has certain rules and specifications, test personnel can directly call the assertion layer to organize use case scenarios according to the rules and specifications. The entry layer, the assertion layer, and the interface layer only have business-related information, and no environment-related information, so according to the runtime incoming environment markers and pre-configured environment information, the purpose of multi-environment execution can be achieved.

[0129] In the embodiment, the terminal device is monitored through a customized agent to generate a structured three-layer code example; the three-layer structure includes an entry layer, an assertion layer and an interface layer; the entry layer calls the assertion layer, the assertion layer calls the interface layer, and the interface layer calls a request tool; the entry layer includes a class name, a method name and test logic; the entry layer is mainly used to organize test logic, and can quickly cover the logic described in a test case by passing in different request parameters and expected results; the assertion layer includes a class name, a method name and assertion logic; the assertion layer is globally unique, and is mainly used to forward the request data passed in by the entry layer and accept the request result data returned by the interface layer, and then perform necessary data verification by using the expected result passed in by the entry layer and the request result data returned by the interface layer; multiple entry layers reuse the same assertion layer to achieve the purpose of assertion layer reuse.

[0130] The interface layer includes a class name, a method name and a url path in a request path; the interface layer is globally unique, and mainly records the url path in the request path; the interface layer triggers a request through the request tool and returns the request result to the assertion layer.

[0131] The class name generation rule is: a marker + a business module + a sub-business module; for example, the entry layer class name is TestBusinessSubModule, the assertion layer class name is AssertBusinessSubModule, and the interface layer class name is ApiBusinessSubModule.

[0132] The entry layer method name is: test + a request method + a request path formatted in the Snack format; however, in order to facilitate the correspondence between a platform case and a case, the case layer method name is test_ + a case number, which is mainly used to correspond to a case and update the case execution state after the case is executed.

[0133] The assertion layer and the interface layer method name generation rule is: a request method + a request path formatted in the Snack format; the assertion layer and the interface layer example are: get_business_url_path and post_business_url_path.

[0134] The entry layer includes request data + expected return results; the entry layer triggers the assertion layer to call, and when a complex scene case is organized, the scene case logic is quickly organized by passing in data and corresponding assertion layer methods;

[0135] The assertion layer includes request interface function description log recording, triggering interface layer calling, interface layer return result and entry layer passing in expected result verification function;

[0136] The interface layer includes: an annotated request data example (convenient for organizing test case logic reference), a urlpath of a request path, triggering a request tool call and returning assertion layer request result data;

[0137] Business module and sub-business module: mainly extracted from request path according to interface characteristics.

[0138] In the embodiments provided in the application, in the process of generating test code with a three-layer structure based on communication information, the request method, the request type, the request body, and the query parameter in the request path in the communication information can be obtained; the request method, the request type, the request body, and the query parameter in the request path are uniformly formatted into a json format, and test code with a three-layer structure is obtained; wherein the entry layer includes: a class name, a method name, and test logic; the interface layer includes: a class name, a method name, and a urlpath in a request path; and the assertion layer includes: a class name, a method name, and assertion logic.

[0139] Specifically, the entry layer request data: is uniformly formatted into a json format according to the request method, the request type, the request body, and the QueryParam parameter after the request url path; the request body or the QueryParam after the url path is formatted into a json format (for example: business=123 is formatted into {“business”:123}) according to the request method and the request type, and the complete url information can be restored in the request tool according to the request method and the type; in this way, various requests can be treated without difference, and the parameters transmitted in the entry layer are flexible json formats; the assertion layer and the interface layer only forward the request to the request tool; thereby a three-layer structure with three-layer calling logic is generated, the entry layer organizes test case logic, the assertion layer is responsible for returning result verification, and the interface layer is used to record the request url and provide a request parameter reference example.

[0140] In the embodiments provided in the application, the method can also transmit request data and expected results through the entry layer, and reuse the assertion layer; wherein the entry layer calls the assertion layer, the assertion layer calls the interface layer, and the interface layer calls the request tool; the assertion layer receives the request data and the expected results, and generates structured code according to the test code according to the request method and the request type.

[0141] In the embodiments, the assertion layer can include normal assertion and abnormal assertion. For assertions of expected operations such as update, delete, creation, and non-list class query, if no data verification error is triggered, the result after the operation is returned, so that the entry layer organizes a complex test scene or organizes tool use. When a verification error is triggered, an error log and returned error information are recorded.

[0142] For all assertions of expected operation failures, reference can be made toFigure 3 As shown, assertions are made for returned results and expected error code values and error descriptions, so all entry layers only need to organize request data and input expected results, and the entry layers do not need to write data verification logic, and the data verification logic can be reused in the assertion layer.

[0143] In an embodiment, when the assertion layer is reused, normal scenario execution success verification and abnormal scenario execution failure verification are included.

[0144] The normal scenario is further divided into list query, detail query, update, creation, deletion, and the like. Normal execution success scenario verification: the entry layer inputs request data and expected results, and if the framework is uniform, a default expected result can be set, and if each operation has different expected results, the expected results can be input in the entry layer to overwrite the default expected results, so that the assertion layer can be reused.

[0145] Abnormal scenario: abnormal scenarios cause execution interruption, and if the entry layer is verified, there is a lot of repeated content in the entry layer for interface testing, and the assertions need to be repeatedly written. If the assertions can be handled in the assertion layer, the entry layer becomes a trigger entry, and only request data and expected results need to be input to trigger, and the entry layer does not need to perform data verification.

[0146] Normal scenario list query verification: generally, a single query needs to be covered first to ensure that each query function is available, and the query returned result content is the query condition content. In addition, there are some common assertions, such as the return state being in the existing state, the return time format being a specified format, and if there is multiple page data returned, how to automatically verify other page returned data. The assertion layer can be reused to quickly improve the test case writing efficiency. When the assertion layer generates a query type assertion, it generates a condition assertion according to the parameters input by the interactive operation; at the same time, it also structurally generates a page turning verification logic, and some common assertions need to be manually identified and added. When the condition assertion is implemented, if the input parameter exists, the input parameter is asserted, so that the combined parameters can also be asserted without changing the assertion logic. If there is multiple page data, the assertion layer can automatically turn the pages to verify the subsequent data according to the input page size and the total amount of returned data (self-calling, increasing the page number according to the calculation until the last page, and asserting the amount of returned data for each page to ensure that the amount of returned data and the input page size remain consistent, and the last page remainder and the remainder amount are consistent).

[0147] Normal scenario non-list type assertion: for example, file download, data details, creation, update, modification, only the input parameters and expected results need to be controlled in the entry layer, and the assertion layer can be reused according to different scenarios; and some scenarios are updated and verified by querying, and the updated parameters and queried data can be compared and verified.

[0148] In an embodiment, the assertion layer can include normal assertion and exception assertion, and the method can further include:

[0149] For the normal assertion of the expected operation success, if no data verification error is triggered, the result after the operation is returned.

[0150] For the exception assertion of the expected operation failure, the returned result and the expected error code value, and the input expected result are multiplexed by the assertion layer data verification logic.

[0151] In an embodiment, for the assertion of the expected operation success of the update, deletion, creation, non-list type query, etc., if no data verification error is triggered, the result after the operation is returned, so that the entry layer organizes a complex test scenario or organizes a tool. When the verification error is triggered, the error log and the returned error information are recorded.

[0152] In an embodiment, the request data can be transmitted by the entry layer and the assertion layer can be called, the request data transmitted by the entry layer is forwarded by the assertion layer, and the request result returned by the interface layer is asserted. For the normal scenario, the request result needs to be returned to the entry layer, so that the entry layer organizes a scenario test case; the interface layer only includes a url path and does not include environment information; and the test code of the three-layer structure only includes business-related information.

[0153] In an embodiment, by using the pre-configured environment information and login user information, when the automatic case execution reaches the request tool, the environment information and platform login user information are obtained according to the runtime transmitted environment and login user mark, the necessary information such as cookie or session, request path domain name, and other request data missing in the request service interface is added, and then the service interface call is triggered to complete the entire request process.

[0154] In an embodiment, based on the generated three-layer structured code without environment-related information, the main work of the tester is to organize the entry layer, assertion layer, and interface layer code with the aid of a tool. Generally, the assertion layer and the interface layer code do not need to be changed, and the tester mainly adjusts the entry layer test case logic. In this way, the tester does not need to focus on the environment information, but only needs to focus on the business scenario and business call logic, and organizes the test scenario in the entry layer. Not only can the entry layer be simplified to make the entry layer logic simple and clear, but also the efficiency of the tester in writing the automatic code can be greatly improved (only the internal organization logic of the interface, focusing on the data and interface relationship), and the automatic code written usually can also support multi-environment execution; by adding a mark (pytest mark mark), the use cases of each layer and each module can be quickly executed, and the flexibility of the automatic execution is greatly improved.

[0155] In the embodiments provided in the present application, the business module and the sub-business module can be extracted from the interface features of the request path, and the class names in the entry layer, the assertion layer and the interface layer are respectively generated based on the preset tag, the business module and the sub-business module.

[0156] For example, the class name generation rule can be: tag + business module + sub-business module; for example, the entry layer class name is TestBusinessSubModule, the assertion layer class name is AssertBusinessSubModule, and the interface layer class name is ApiBusinessSubModule.

[0157] Therefore, the entry layer class name is Test + business module, the assertion layer class name is Assert + business module, and the interface layer class name is Api + business module, forming a unified format class name, which facilitates the calling between the three-layer structure.

[0158] In the embodiments provided in the present application, the method name of the entry layer can be generated through the preset prefix, the request method and the preset formatted request path, and the method names of the assertion layer and the interface layer can be generated through the request method and the preset formatted request path.

[0159] For example, the preset prefix can be test, the entry layer method name can be test_ + case number, the test personnel needs to adjust, the default generates test_ + request method + url path after Snack, the assertion layer method and the interface layer method are both request method + url path after Snack, and after formatting, the calling relationship is formed, as shown in Figure 1 The generated code entry layer calls the assertion layer, the assertion layer calls the interface layer, and the interface layer calls the request tool.

[0160] In the case of dividing each functional module according to each function, the test code generation device provided in the embodiments of the present application can be the above-mentioned proxy device 10, such as a server or a chip applied to a server. Figure 7 The functional module schematic diagram of the test code generation device provided in an exemplary embodiment of the present application is shown in Figure 7 The test code generation device comprises:

[0161] The listening module 71 is configured to listen to the communication information between the terminal and the server.

[0162] The test code generation module 72 is configured to generate test code with a three-layer structure based on the communication information; wherein the test code with the three-layer structure comprises an entry layer, an assertion layer and an interface layer; the entry layer is configured to organize test logic; the assertion layer is configured to forward request data transmitted by the entry layer and receive request result data returned by the interface layer, and perform data verification on the request result data returned by the interface layer by using expected results transmitted by the entry layer; and the interface layer is configured to record a request url path and return request result data to the interface layer by triggering a request through a request tool.

[0163] In another embodiment provided in the present application, the test code generation module is specifically configured to:

[0164] obtain query parameters in a request method, a request type, a request body and a request path in the communication information;

[0165] format the query parameters in the request method, the request type, the request body and the request path into a uniform json format to obtain test code with a three-layer structure; wherein the entry layer comprises a class name, a method name and test logic; the interface layer comprises a class name, a method name and a url path in a request path; and the assertion layer comprises a class name, a method name and assertion logic.

[0166] The scheme can clearly organize test case logic by the entry layer, perform return result verification based on the assertion layer, and record a request url and provide a request parameter reference example based on the interface layer by generating test code with a three-layer calling logic.

[0167] In another embodiment provided in the present application, the apparatus further comprises a multiplexing module, which is specifically configured to:

[0168] multiplex the assertion layer by transmitting request data and expected results through the entry layer;

[0169] The entry layer calls the assertion layer, the assertion layer calls the interface layer, and the interface layer calls a request tool; the assertion layer receives request data and expected results, and generates structured code according to a test code generation structure according to different request methods and request types.

[0170] In another embodiment provided in the present application, the apparatus further comprises a processing module, which is specifically configured to:

[0171] transmit request data through the entry layer and call the assertion layer;

[0172] forward request data transmitted by the entry layer through the assertion layer, and perform assertion on request results returned by the interface layer; wherein request results need to be returned to the entry layer for organizing scene test cases in a normal scenario; the interface layer only comprises a url path and does not comprise environment information; and the test code with the three-layer structure only comprises business related information.

[0173] In the scheme, the interface layer only contains a url path and does not contain environment information; the test code of the three-layer structure only contains business-related information, so that the code example can be quickly reused.

[0174] In another embodiment provided in the application, the assertion layer includes normal assertion and abnormal assertion, and the apparatus further includes an assertion module, which is specifically configured to:

[0175] For the normal assertion of the expected operation success, if no data verification error is triggered, the result after the operation is returned.

[0176] For the abnormal assertion of the expected operation failure, the returned result and the expected error code value, and the input expected result are verified through the assertion layer.

[0177] In the scheme, if no data verification error is triggered, the result after the operation is returned, so as to help the entry layer organize a complex test scene or organize a tool. When the verification error occurs, the error log and the returned error information can be recorded.

[0178] In another embodiment provided in the application, the apparatus further includes a class name generation module, which is specifically configured to:

[0179] The business module and the sub-business module are extracted from the interface characteristics of the request path;

[0180] Based on the preset mark, the business module and the sub-business module, the class names in the entry layer, the assertion layer and the interface layer are generated respectively.

[0181] The scheme forms the class names in a unified format, so as to facilitate the calling between the three-layer structures.

[0182] In another embodiment provided in the application, the apparatus further includes a method name generation module, which is specifically configured to:

[0183] The method name of the entry layer is generated through a preset prefix, a request method and a preset formatted request path;

[0184] The method names of the assertion layer and the interface layer are generated through the request method and the preset formatted request path.

[0185] The scheme forms the method class names in a unified format, so as to facilitate the calling between the three-layer structures.

[0186] The embodiment of the application further provides a server, comprising: at least one processor and at least one GPU; the processor is used for storing a memory of at least one processor executable instruction; wherein the at least one processor is configured to execute the instruction, and when the GPU multi-instance configuration method disclosed in the embodiment of the application is implemented, a GPU configuration interface is generated; and when the GPU multi-instance segmentation method disclosed in the embodiment of the application is implemented, the at least one GPU is segmented into multiple instances.

[0187] The processor can also be referred to as a central processing unit (CPU), which can be an integrated circuit chip having a signal processing capability. The steps in the method disclosed in the embodiment of the application can be completed by integrated logic circuits of hardware in the processor or instructions in the form of software. The processor can be a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in the embodiment of the application can be directly embodied as hardware decoding processor execution completion or execution completion by a combination of hardware and software modules in the decoding processor. The software module can be located in a memory, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register or other mature storage medium in the art. The processor reads information in the memory and completes the steps of the method in combination with the hardware thereof.

[0188] In addition, various operations / processes according to the embodiment of the application are implemented by software and / or firmware, which can be installed in a server with a special hardware structure, such as a server 800 shown in the figure, from a storage medium or a network. Figure 8 The server 800 shown in the figure is installed with programs constituting the software, and the server can perform various functions when various programs are installed, including functions such as the foregoing functions and the like. Figure 8 The structure block diagram of the server provided for an exemplary embodiment of the application.

[0189] Server 800 is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, mainframe computers, and other suitable computers. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments described and / or claimed herein.

[0190] like Figure 8 As shown, server 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 802 or a computer program loaded from storage unit 808 into random access memory (RAM) 803. RAM 803 may also store various programs and data required for the operation of server 800. Computing unit 801, ROM 802, and RAM 803 are interconnected via bus 804. Input / output (I / O) interface 805 is also connected to bus 804.

[0191] Multiple components in server 800 are connected to I / O interface 805, including: input unit 806, output unit 807, storage unit 808, and communication unit 809. Input unit 806 can be any type of device capable of inputting information to server 800. Input unit 806 can receive input numeric or character information and generate key signal inputs related to user settings and / or function control of the server. Output unit 807 can be any type of device capable of presenting information and may include, but is not limited to, a monitor, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 808 may include, but is not limited to, disks and optical discs. Communication unit 809 allows server 800 to exchange information / data with other devices via a network such as the Internet, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0192] The computing unit 801 can be various general and / or special purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 801 performs various methods and processes described above. For example, in some embodiments, the above-described methods disclosed by the embodiments of the present application can be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on the server via the ROM 802 and / or the communication unit 809. In some embodiments, the computing unit 801 can be configured to perform the above-described methods disclosed by the embodiments of the present application by any other appropriate means (for example, by means of firmware).

[0193] The embodiments of the present application also provide a computer-readable storage medium, wherein when instructions in the computer-readable storage medium are executed by a processor of a server, the server is enabled to perform the above-described methods disclosed by the embodiments of the present application.

[0194] The computer-readable storage medium in the embodiments of the present application can be a tangible medium, which can contain or store programs for use by or in connection with an instruction execution system, apparatus or device. The above-described computer-readable storage medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, or any appropriate combination thereof. More specifically, the above-described computer-readable storage medium can include an electrical connection based on one or more wires, a portable computer 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 compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any appropriate combination thereof.

[0195] The above-described computer-readable medium can be contained in the above-described server; or can exist separately without being assembled into the server.

[0196] The embodiments of the present application also provide a computer program product, which includes a computer program, wherein the computer program is executed by a processor to implement the above-described methods disclosed by the embodiments of the present application.

[0197] In embodiments of the present application, the computer program code for carrying out operations of the present application can be written in one or more programming languages, including but not limited to object oriented programming languages such as Java, Smalltalk, C++, as well as conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer.

[0198] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a segment, or a portion of code, which comprises one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may

[0199] The modules, components or units described in the embodiments of the present application can be implemented by software or by hardware. In some cases, the name of the module, component or unit does not imply the limitation of the module, component or unit itself.

[0200] The functions described above in the detailed description of the application can be performed by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.

[0201] The above description is merely some embodiments of the present application and a description of principles of technology employed by the present application. It should be understood by those skilled in the art that the disclosed scope of the present application is not limited to the technical solutions formed by the specific combinations of the above technical features, and should also cover other technical solutions formed by the combinations of the above technical features or equivalent features without departing from the above disclosed concept. For example, the technical solutions formed by the mutual replacement of the above features and the technical features disclosed in the present application (but not limited to) having similar functions.

[0202] Although some specific embodiments of the present application have been described in detail by way of examples, it should be understood that the above examples are merely for illustration, but not to limit the scope of the present application. Those skilled in the art should understand that the above embodiments can be modified without departing from the scope and spirit of the present application. The scope of the present application is defined by the appended claims.

Claims

1. A test code generation method characterized by, The method comprises: monitoring communication information between a terminal and a server; generating test code with a three-layer structure based on the communication information; wherein the test code with the three-layer structure comprises an entry layer, an assertion layer and an interface layer, the entry layer is used to organize test logic, the assertion layer is used to forward request data transmitted by the entry layer and receive request result data returned by the interface layer, and data verification is performed on the request result data returned by the interface layer by using expected results transmitted by the entry layer, and the interface layer is used to record a request url path and return request result data to the interface layer by triggering a request by using a request tool.

2. The method of claim 1, wherein, The method further comprises: extracting query parameters in a request method, a request type, a request body and a request path in the communication information; formatting the request method, the request type, the request body and the query parameters in the request path into a json format to obtain the test code with the three-layer structure; wherein the entry layer comprises a class name, a method name and test logic; the interface layer comprises a class name, a method name and a url path in a request path; and the assertion layer comprises a class name, a method name and assertion logic.

3. The method of claim 1, wherein, The method further comprises: multiplexing the assertion layer by transmitting request data and expected results through the entry layer; wherein the entry layer calls the assertion layer, the assertion layer calls the interface layer, and the interface layer calls a request tool; the assertion layer receives the request data and the expected results, and generates structured code according to the test code according to different request methods and request types.

4. The method of claim 1, wherein, The method further comprises: transmitting request data and calling the assertion layer through the entry layer; forwarding the request data transmitted by the entry layer through the assertion layer, and performing assertion on request results returned by the interface layer; wherein request results need to be returned to the entry layer for normal scenarios, and the entry layer organizes scenario test cases; the interface layer only contains a url path and does not contain environment information; and the test code with the three-layer structure only contains business-related information.

5. The method of claim 1, wherein, The assertion layer comprises normal assertion and abnormal assertion, and the method further comprises: for normal assertion of expected operation success, if no trigger data verification error occurs, returning a result after operation; for abnormal assertion of expected operation failure, returning a result and an expected error code value, and inputting an expected result, and multiplexing data verification logic through the assertion layer.

6. The method of claim 2, wherein, The method further comprises: extracting a business module and a sub-business module from an interface feature of the request path; generating class names in the entry layer, the assertion layer and the interface layer based on a preset marker, the business module and the sub-business module.

7. The method of claim 2, wherein, The method further comprises: generating a method name of the entry layer by using a preset prefix, a request method and a request path formatted in a preset format; generating method names of the assertion layer and the interface layer by using a request method and a request path formatted in a preset format.

8. A test code generation apparatus characterized by comprising: The device comprises: a monitoring module configured to monitor communication information between a terminal and a server; The test code generation module is configured to generate test code with a three-layer structure based on the communication information; wherein the test code with the three-layer structure comprises an entry layer, an assertion layer and an interface layer; the entry layer is configured to organize test logic; the assertion layer is configured to forward request data transmitted by the entry layer and receive request result data returned by the interface layer, and perform data verification on the request result data returned by the interface layer by using expected results transmitted by the entry layer; and the interface layer is configured to record a request url path, and return the request result data to the interface layer by triggering a request through a request tool.

9. A server, characterized by Comprises: at least one processor; a memory for storing instructions executable by the at least one processor; wherein the at least one processor is configured to execute the instructions to implement the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, When the instructions in the computer readable storage medium are executed by the processor of the electronic device, the electronic device is enabled to perform the method of any one of claims 1-7.

Images