An integrated testing method based on recording and playback

Abstract

The present invention discloses an integrated testing method based on recording and playback, which can record test cases in various forms during the local debugging or joint debugging test of developers and the operation process of the system, and form integrated test cases, achieving the effects of cost reduction and simplicity and ease of use. Its technical solution is: by intercepting the function call process during the operation of the application to record and automatically form test cases, thereby achieving a significant reduction in test costs. Specifically, when a certain function is executed, the execution of the function is intercepted. If it is a function within the target interception range, recording, playback, incremental recording, etc. are performed according to the current working mode.

Description

Technical Field

[0001] The present invention relates to integration testing in a microservice software architecture, and particularly to an integration testing method based on recording and playback. Background Art

[0002] Integration testing is a logical extension of unit testing. It is a process of assembling software units into modules, subsystems, or systems according to software requirements specifications to check whether the work of each part meets or achieves the corresponding technical index requirements. In practice, integration refers to the aggregation of multiple units. Many units are combined into modules, and these modules are further aggregated into larger parts of the program. Integration testing is one of the effective ways for software developers to conduct testing. Compared with unit testing and system testing, it has the highest comprehensive benefits in terms of the coverage of business requirements, the execution time of a single test case, and the test case maintenance cost.

[0003] In a microservice software architecture, the mesh-like calls between microservices and the calls of microservices to external services such as middleware and databases form a complex call network. It is very cumbersome and complex to set up test doubles through unit testing in a Mock manner or to provide test data and application context for testing activities by controlling the entire microservice operation and maintenance system, and it is not economical.

[0004] Specifically, in a microservice architecture system, especially in an application based on Spring MVC, the application system mainly consists of the following layers: a resource layer, a service layer, a domain layer, and a data layer.

[0005] In addition, there are also two auxiliary modules: a module for microservice external communication and a database access module. Among them, the module for microservice external communication includes an HTTP terminal and a Gateway part, as well as external message services such as payment and notification. The database access module mainly refers to the interaction module with an external database.

[0006] When developers conduct testing, when using the unit testing method, in order to isolate the above modules and cross-layer calls, a large amount of time and effort are required to write test stubs (mocks). Integration testing can partially reduce this part of the cost by accessing an in-memory database or a Mock Server, etc., and can implement functions of the Spring framework such as permissions and aspects, which are very difficult to cover by unit testing.

[0007] Existing recording and playback tools basically record and playback through the network protocol layer, mainly using the HTTP protocol, and can only achieve the recording and playback of HTTP calls between services. A small number of tools support the simulation of internal classes and methods of applications, but lack support for automatic recording and playback, or are mainly applied to system testing rather than the code-based testing activities of developers. Summary of the Invention

[0008] A brief overview of one or more aspects is given below to provide a basic understanding of these aspects. This overview is not an exhaustive survey of all contemplated aspects, and is neither intended to identify key or decisive elements of all aspects nor to define the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that follows.

[0009] The object of the present invention is to solve the above problems, and provides an integrated test method based on recording and playback, which can perform various forms of use case recording during the local debugging or joint debugging test of developers and the operation process of the system, and form integrated test cases, achieving the effects of reducing costs and being simple and easy to use.

[0010] The technical solution of the present invention is as follows: The present invention discloses an integrated test method based on recording and playback, and the method includes:

[0011] Step 1: Perform interception, check whether the integrated test tool is enabled, and if it is enabled, continue to execute Step 2;

[0012] Step 2: Check whether the currently executing function is a function within the intercepted range. If so, continue to execute Step 3; otherwise, normally execute the current function and return;

[0013] Step 3: Check the working mode of the integrated test tool, and perform different processing according to whether the working mode is the playback mode or the recording mode. If it is the recording mode, execute Step 4; if it is the playback mode, execute Step 5;

[0014] Step 4: In the recording mode, according to the type of the target function, call the corresponding recording method to record the process of the current execution of the target function, form an instance of MockRecord record, and save it into List <mockrecord>in the record set, serialized to a file at the end of the use case execution, and then step 10 is executed;

[0015] Step 5: In playback mode, determine whether it is stateful playback. If it is stateful playback, execute step 7; if it is stateless playback, execute step 6;

[0016] Step 6: Currently, the integration test tool is in stateless playback mode. According to the MockRecord of this function, search and return the matching record in the Mock dataset as the Mock result of this function execution, and convert it into the execution result of the target function according to the function type, so as to achieve the playback of this function execution, and then execute step 8;

[0017] Step 7: Currently, the integration test tool is in stateful playback mode. The integration test tool will create a queue for each function, push the records of this function in the Mock dataset onto the stack, perform data matching from the Mock queue of the target function, and use the first matching result as the Mock result of this function. Delete the record from the queue, and convert the Mock result into the execution result of the target function according to the function type, so as to achieve the playback of this function execution, and then continue to execute step 8;

[0018] Step 8: In the case where the current record is not found in both step 6 and step 7, determine again whether the current is incremental recording. If incremental recording is enabled, execute step 9; if incremental recording is not enabled, return Null and execute step 10;

[0019] Step 9: Enter the recording logic. After the recording is completed, append the generated MockRecord to the current List <mockrecord>In the process, after the execution of the test case is completed, it is serialized and persisted into a record file, and then step 10 is executed;

[0020] Step 10: Return the result, and the integrated test method ends.

[0021] According to an embodiment of the integrated test method based on recording and playback of the present invention, a dual switch is set in step 1. One switch realizes whether to load the start of the integrated test tool, and the other switch realizes whether to enable the recording / playback function, and realizes a switch at the single test case level.

[0022] According to an embodiment of the integrated test method based on recording and playback of the present invention, in step 2, the interception range setting of the integrated test tool is matched through the AspectContext object. The AspectContext object includes package name, fully qualified class name, class name, method name, and return type. When the function is executed, the corresponding data in the AspectContext object is captured and matched with the target aspect expression configured by the user to determine whether it is an operation that needs to be intercepted and executed for recording or playback within the target range.

[0023] According to an embodiment of the integrated test method based on recording and playback of the present invention, in step 4, the MockRecord record is a recording record formed during the interception of a function execution. One MockRecord record includes the following attributes: class name, function name, function input parameters, function return value, function return type, input parameters after function execution, exceptions during function execution, and session data.

[0024] According to an embodiment of the integrated test method based on recording and playback of the present invention, step 4 further includes:

[0025] Step 4-1: Recording by the exception recorder;

[0026] Step 4-2: Recording by the Null recorder;

[0027] Step 4-3: Recording by the iterator recorder;

[0028] Step 4-4: Recording by the generic recorder;

[0029] Step 4-5: List <t>Recording of the recorder

[0030] Steps 4 - 6: Recording of the PageList recorder

[0031] Steps 4 - 7: Recording of the stream recorder

[0032] Steps 4 - 8: Recording of the default recorder

[0033] According to an embodiment of the integrated test method based on recording and playback of the present invention, in step 5, matching is performed in a depth - first manner and immediately returns after the first match is achieved. The result of the first MockRecord match is used as the Mock result. Among them, by screening the execution records of the same function into the same queue, and after each successful match request, the first record in the queue is returned as the playback result and deleted from the queue at the same time, so as to achieve stateful playback that returns different responses to the same request in sequence.

[0034] According to an embodiment of the integrated test method based on recording and playback of the present invention, in step 6, through fuzzy matching, it supports fuzzifying the input parameters of a specified type during recording and writing them into the recording file, and uses the same function to perform fuzzy matching on the input parameters of the function during playback, so as to ensure the normal playback of the function.

[0035] The present invention has the following beneficial effects compared with the prior art: The method of the present invention intercepts the function call process during the application running process to record and automatically form test cases, thereby greatly reducing the test cost. Specifically, when a function is executed, the execution of the function is intercepted. If it is a function within the target interception range (simply referred to as the target function), then recording, playback, incremental recording, etc. are performed according to the current working mode. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] After reading the detailed description of the embodiments of the present disclosure in conjunction with the following drawings, the above - mentioned features and advantages of the present invention can be better understood. In the drawings, the components are not necessarily drawn to scale, and components with similar relevant characteristics or features may have the same or similar reference numerals.

[0037] Figure 1 Shows a flowchart of an embodiment of the integrated test method based on recording and playback of the present invention.

[0038] Figure 2 Shows Figure 1 The detailed process of step 4 in the method embodiment shown. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0039] The present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. Note that the aspects described below in conjunction with the accompanying drawings and specific embodiments are merely exemplary and should not be construed as imposing any limitation on the scope of protection of the present invention.

[0040] Figure 1 The flowchart of an embodiment of the integrated test method based on recording and playback of the present invention is shown. Please refer to Figure 1 , and the implementation steps of the integrated test method based on recording and playback in this embodiment are described in detail as follows. The purpose of the method in this embodiment is to intercept the execution of a function when the function is executed. If the function is within the target interception range, recording, playback, incremental recording, etc. are performed according to the current working mode.

[0041] Step 1: Perform interception and check whether the integrated test tool is enabled. If the integrated test tool is not enabled, the function is executed normally and returns. If it is enabled, proceed to step 2.

[0042] In this embodiment, the design of the dual switch improves the safety factor. To ensure safe production, in the production environment, through one switch, the startup of the integrated test tool is not loaded, completely eliminating the hidden danger of data leakage caused by accidental startup. At the same time, through another switch, the opening and closing of the recording / playback function itself are realized, and the switch at the level of a single test case can be realized, so as to realize the mixed execution of the test cases generated by the integrated test tool and the test cases generated by the rest of the unit test framework.

[0043] Step 2: Check whether the currently executing function is within the interception range.

[0044] In this embodiment, the AspectContext is used to match the interception range setting of the integrated test tool. If the currently executing function does not match the interception range setting, the currently executing function is executed normally and returns. If the currently executing function matches the interception range setting, proceed to step 3.

[0045] AspectContext refers to: when recording and playing back the execution of a certain function, it is first necessary to define whether the execution process of the function needs to be intercepted. Therefore, it is necessary to define the AspectContext type for the above matching.

[0046] The AspectContext object includes the package name, fully qualified class name, class name, method name, and return type. When the function is executed, the above data is captured and matched with the target aspect expression configured by the user to determine whether it is an operation within the target range that needs to be intercepted for recording or playback.

[0047] Specifically, the execution process of each function of a certain Java service is intercepted through aspect, and it is determined whether the function executed this time is the target function to be mocked through matching processing. The matching processing supports fuzzy matching of packages, classes, and methods and the AND / OR algorithms to implement the mocking of certain types of functions.

[0048] Step 3: Check the working mode of the integration testing tool. Different processing is performed according to whether the working mode is the playback mode or the recording mode. If it is the recording mode, step 4 is executed; if it is the playback mode, step 5 is executed. Before the test case is executed, the working mode can be specified as playback or recording, and the default is recording.

[0049] Step 4: In the recording mode, according to the type of the target function, different recording methods are called to record the execution process of the target function this time, and a MockRecord instance is formed and saved into the List. <mockrecord>In the record set, it is serialized to a file at the end of the use case execution. Then step 10 is executed.

[0050] The MockRecord record is defined as follows:

[0051] When an execution process of an interception function is intercepted and a recorded record is formed, it is recorded as a MockRecord record. A MockRecord record includes the following attributes: class name, function name, function input parameters, function return value, function return type, input parameters after function execution, exceptions during function execution, and session data.

[0052] In some scenarios, the input parameters of the target function may change during the process before and after the execution of the target function. Therefore, it is necessary to additionally record the input parameters after the execution of the target function. Similarly, if an exception is thrown during the execution of the target function, the exception needs to be recorded for subsequent playback. In addition, during the running process of the target function, it may also be necessary to obtain some information from the session, such as the logged-in user, etc. Therefore, it also needs to be additionally recorded.

[0053] Multiple interceptions may occur during the execution of a test case, and multiple records are formed, forming a List <mockrecord>A record set, and finally serialize it to form a test case in the JSON file format.

[0054] For the HTTP requests of the application under test, the main contents include data such as url, request type, parameters, return values, sessions, headers, etc. The MockRecord data type can also be reused.

[0055] For the detailed processing of this step 4, please refer to Figure 2 as shown. In the recording mode, it is necessary to record a certain execution of the target function and be able to serialize and save it to form a test case in the JSON file format. This embodiment proposes recording methods for some function return value types, exceptions, and return types such as streams and iterators that cannot be serialized.

[0056] Before and after the execution of the target function, the input parameters of the target function may change. For example, the input parameter of a certain target function is an entity, and a certain attribute of the entity, such as ID, is assigned after the function execution, or a certain input parameter of the target function is a Map, and additional records are inserted into the Map after the target function execution. Due to the shallow copy of Java objects, simple input parameter recording will affect the playback execution process of the function itself. This algorithm traverses the input parameter object array and performs deep copying one by one according to the type, ensuring that the target function is not affected during the recording process, and can execute and match the target function according to the input parameters at runtime during playback, and then playback the changed input parameter data after the target function execution is completed, realizing the correct recording and playback of this type of target function.

[0057] The entire recording process is as follows.

[0058] Step 4-1: Recording by the exception recorder. If an exception occurs during the function execution, it is necessary to record the exception so that the same exception can be used as the result when the function is executed again during playback. The present invention defines a ThrowRecord object to record the exception name, exception message, and error code, thus realizing the serialization of the exception and forming a MockRecord instance. In addition, the present invention also records the cause of the exception (i.e., cause).

[0059] In this step 4-1, multi-layer exception recording and playback are adopted. Throwing an exception during the function execution is a scenario in unit testing. In addition to truly restoring the exception type to strictly match the real scenario, the present invention also supports recording the cause of the exception, thus realizing the recording and playback of multi-layer exceptions.

[0060] Step 4-2: Recording by the Null recorder. If the return value of the function after execution is Null, the Null recorder is used to form a MockRecord instance.

[0061] Step 4-3: Recording of the iterator recorder. An iterator is a return type in database query methods. Different from the return value of a normal function, an iterator only provides an accessor for data query and does not contain all the return values. In addition, the access of an iterator is unidirectional and one-time. After the iterator recorder finishes recording all the data from the remote data source, the code logic where the original function is located cannot obtain data from this data source anymore. The present invention designs a method to solve such problems. By pre-accessing to obtain all the data for recording instead of using the execution result of the function as the result of this recording, and replicating a copy of the data set for the subsequent execution of the code of the recorded method, the above problems are solved. During playback, it is also necessary to pre-generate the data set and generate a supporting iterator to be returned as the execution result of the mocked method, thus realizing playback.

[0062] Step 4-4: Recording of the generic recorder. The recording of generics is also a key design in the recording of the present invention. In the default recorder, as long as the execution result of the current function is recorded as an object and serialized. During playback, it can be deserialized according to the return type declared by the target function. However, due to type erasure, generics cannot be played back. The present invention designs a recording method for generics. By detecting the type of the method return value to obtain the actual return type of the function according to the function as the function return type additionally recorded in the MockRecord. During playback, it is deserialized according to the recorded function return type as the execution result of the generic method.

[0063] Step 4-5: List <t>The recording of the recorder is similar to Step 4-4. List <t>As a special generic type, since the type of objects within a list is lost during serialization, it is additionally necessary to convert the List into a data structure that can preserve the object type on the basis of generic processing before serialization for storage. During playback, it is restored in the reverse manner.

[0064] Steps 4-6: Recording by the PageList recorder. PageList represents another return value type that cannot be directly serialized. Since the prototype of this type is ArrayList, it will be serialized and deserialized as this type during serialization, resulting in the loss of paging and other information. Although the playback steps can be successfully executed during playback, it will cause problems with the subsequent application code not being able to execute. The present invention designs a recording function for such objects. The PageList itself, as well as the paging object Paginator it contains, are both saved and deposited into MockRecord as the return value of this function. During playback, a complete PageList is reconstructed according to the return type, thus realizing the playback of the execution of this function.

[0065] Steps 4-7: Recording by the stream recorder. The playback of a stream is similar to that of an iterator, and reference can be made to Step 4-3. For Steps 4-3 to 4-7, some Java classes cannot be serialized, such as streams, iterators, generics, types, sessions, front-end paging, etc. The innovation of this algorithm lies in realizing the recording and playback of the above types through a preprocessing method without manual intervention.

[0066] Steps 4-8: Recording by the default recorder. Use the default recorder to record ordinary objects.

[0067] Step 5: In the playback mode, determine whether it is a stateful playback. If it is a stateful playback, execute Step 7; if it is a stateless playback, execute Step 6.

[0068] During the playback process, the usual playback algorithm is to perform matching in a depth-first manner and return immediately after the first match is achieved, taking the first MockRecord match result as the result of the Mock. In this step, by recording and screening the execution of the same function (the package, class, and input parameters of the function) into the same queue, and after each successful match request, taking the first record in the queue as the playback result and returning it, and at the same time deleting it from the queue, a stateful playback that returns different responses to the same request in sequence is realized.

[0069] Step 6: Currently, the integration testing tool is in a stateless playback mode. According to the MockRecord of this function, it searches for and returns a matching record in the Mock dataset as the Mock result of this function execution, and converts it into the execution result of the target function according to the function type, thereby realizing the playback of this function execution. Then continue to execute Step 8.

[0070] In Step 6, with the design of fuzzy matching and Mock callback interface, the input parameters of the function often include input parameters such as id, serial number, and timestamp that change every time the function is executed. Through fuzzy matching, the present invention supports the fuzzy processing of specified types of input parameters during recording and writing them into the recording file, and uses the same function to perform fuzzy matching on the input parameters of the function during playback, thus ensuring the normal playback of such functions.

[0071] Step 7: Currently, the integration testing tool is in a stateful playback mode. The integration testing tool will create a queue for each function and push the records of this function in the Mock dataset onto the stack. When entering this Step 7, it will perform data matching from the Mock queue of the target function, and use the first matching result as the Mock result of this function, and delete this record from the queue. According to the function type, convert the Mock result into the execution result of the target function, thereby realizing the playback of this function execution. Then continue to execute Step 8.

[0072] Step 8: In the case that the current record is not found in both Step 6 and Step 7, determine again whether the current is incremental recording. If incremental recording is enabled, execute Step 9. If incremental recording is not enabled, return Null and execute Step 10.

[0073] During the playback process, if a function being mocked is not matched in the recorded response result and the incremental recording switch is enabled, then this function will be actually processed, and the execution result of this time will be recorded and incrementally saved to the recording file, thereby realizing incremental recording.

[0074] Step 9: Enter the recording logic. After the recording is completed, append the generated MockRecord to the current List <mockrecord>and serialized and persisted to a record file after the execution of the test case is completed.

[0075] In step 9, the present invention further provides a Mock callback interface, which can retrieve the recorded record of the function to be returned after matching, and directly modify it according to the user's needs and return it as the result of this playback, providing greater convenience.

[0076] Step 10: Return the result and end the method.

[0077] In addition, the present invention supports only recording and playing back backend dependencies and full front-end and backend recording and playing back. In the MVC architecture, when developers conduct tests on the controller or service layer through coding, the present invention provides a backend recording and playing back mode for recording and playing back database, middleware, and service dependencies for this type of integration test. In addition, the present invention also provides a front-end and backend recording mode for testers to use. In this mode, HTTP can be initiated through the front-end page or upstream service, and the present invention fully records the HTTP request, response, and external dependencies during the execution of this interface to form a request and dependency record file as a test case. The present invention realizes the automated execution of the test case set file in the specified directory through playback and makes (fuzzy) assertions on the execution results.

[0078] The present invention relates to the operations of adding, deleting, updating, and querying data objects. Among them, the query operation is the source of cached data, and the other three operations will cause the cached data to become invalid. For these operations, the present invention relates to four relative pointcuts (annotations) and one auxiliary pointcut (annotation).

[0079] For these four operations, the present invention proposes the following processing flow, corresponding to the following three working modes respectively:

[0080] REC: Recording mode. In this mode, a MockRecord record set is formed by intercepting the function execution process. If the recording includes an HTTP request, the HTTP request is additionally recorded.

[0081] SIM: Playback mode. In this mode, the function execution process is intercepted and matched. If it is determined that the function is within the intercepted target range, according to the Mock data query algorithm, the matching MockRecord record is queried and obtained from the MockRecord record set and returned as the execution result of this function.

[0082] SPY: Incremental recording mode. This mode is similar to the playback mode, except that when querying from the MockRecord record set, if no matching MockRecord record is obtained, the actual function is executed, and the execution result of this time is recorded and appended to the existing MockRecord record set and persisted after the test case execution.

[0083] Although the above methods are illustrated and described as a series of acts for simplicity of explanation, it should be understood and appreciated that these methods are not limited by the order of the acts, because according to one or more embodiments, some acts may occur in a different order and / or concurrently with other acts not illustrated and described herein but understood by those skilled in the art.

[0084] Those skilled in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, the various illustrative components, blocks, modules, circuits, and steps are described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

[0085] The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein can be implemented using 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, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors cooperating with a DSP core, or any other such configuration.

[0086] The steps of a method or algorithm described in connection with the embodiments disclosed in this specification can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read from, and write to, the storage medium. In an alternative, the storage medium may be integrated into the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In an alternative, the processor and the storage medium can reside as discrete components in a user terminal.

[0087] In one or more exemplary embodiments, the described functionality can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software as a computer program product, the functions can be stored on or transmitted via a computer-readable medium as one or more instructions or code. The computer-readable medium includes both a computer storage medium and a communication medium including any medium that facilitates transfer of a computer program from one place to another. A storage medium may be any available medium that can be accessed by a computer. By way of example and not limitation, such computer-readable medium can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a web site, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. As used herein, disk and disc include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable medium.

[0088] The previous description of the present disclosure is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to the present disclosure will be apparent to those skilled in the art, and the general principles defined herein can be applied to other variations without departing from the spirit or scope of the present disclosure. Thus, the present disclosure is not intended to be limited to the examples and designs described herein, but should be accorded the widest scope consistent with the principles and novel features disclosed herein.< / mockrecord> < / t> < / t> < / mockrecord> < / mockrecord> < / t> < / mockrecord> < / mockrecord>

Claims

1. An integrated testing method based on recording and playback, characterized in that The method includes: Step 1: Perform interception. Check whether the integration test tool is enabled. If it is enabled, continue to execute Step 2; Step 2: Check whether the currently executing function is a function within the intercepted range. If it is, continue to execute Step 3; otherwise, execute the current function normally and return; Step 3: Check the working mode of the integration test tool and perform different processing according to whether the working mode is the playback mode or the recording mode. If it is the recording mode, execute Step 4; if it is the playback mode, execute Step 5; Step 4: In the recording mode, call the corresponding recording method according to the type of the target function to record the process of the current execution of the target function, form an instance of MockRecord record, and save it into the List <mockrecord>Record centrally and serialize it to a file at the end of use case execution, and then execute Step 10; < / mockrecord> Step 5: In the playback mode, determine whether it is a stateful playback. If it is a stateful playback, execute Step 7; if it is a stateless playback, execute Step 6; Step 6: Currently, the integration test tool is in the stateless playback mode. According to the MockRecord of this function, search and return the matching record in the Mock dataset as the Mock result of this function execution, and convert it into the execution result of the target function according to the function type, so as to realize the playback of this function execution, and then execute Step 8; Step 7: Currently, the integration test tool is in the stateful playback mode. The integration test tool will create a queue for each function, push the record of this function in the Mock dataset onto the stack, match the data from the Mock queue of the target function, and use the first matching result as the Mock result of this function, and delete this record from the queue. Convert the Mock result into the execution result of the target function according to the function type, so as to realize the playback of this function execution, and then continue to execute Step 8; Step 8: In the case that the current record is not found in both Step 6 and Step 7, determine again whether incremental recording is enabled. If incremental recording is enabled, execute Step 9; if incremental recording is not enabled, return Null and execute Step 10; Step 9: Enter the recording logic. After the recording is completed, append the generated MockRecord to the current List <mockrecord>Record it centrally and serialize and persist it to the record file after the execution of the test case is completed, and then execute Step 10; < / mockrecord> Step 10: Return the result and the integration test method ends; Among them, in Step 5, match in a depth-first manner and return immediately after the first match is achieved, and use the first MockRecord matching result as the Mock result. Among them, filter the same function execution records into the same queue, and after each successful match request, use the first record in the queue as the playback result to return, and delete it from the queue at the same time, so as to realize the stateful playback of different responses for the same request in sequence.

2. The integrated test method based on recording and playback according to claim 1, wherein Set a dual switch in Step 1. One switch realizes whether to load the start of the integration test tool, and the other switch realizes whether to enable the recording / playback function, and realizes the switch at the single test case level.

3. The integrated test method based on recording and playback according to claim 1, wherein In step 2, the AspectContext object is used to match the interception scope settings of the integration test tool. The AspectContext object includes the package name, class name, method name, and return type. The class name also includes the fully qualified class name. When the function is executed, the corresponding data in the AspectContext object is captured and matched with the target aspect expression configured by the user to determine whether it is an operation that needs to be intercepted and executed for recording or playback within the target scope.

4. The integrated test method based on recording and playback according to claim 1, wherein In step 4, the MockRecord record is the recording record formed during an interception of a function execution. One MockRecord record includes the following attributes: class name, function name, function input parameters, function return value, function return type, input parameters after function execution, exceptions during function execution, and session data.

5. The integrated test method based on recording and playback according to claim 4, wherein Step 4 further includes: Step 4-1: Recording by the exception recorder; Step 4-2: Recording by the Null recorder; Step 4-3: Recording by the iterator recorder; Step 4-4: Recording by the generic recorder; Step 4-5: List <t>Recording by the recorder; < / t> Step 4-6: Recording by the PageList recorder; Step 4-7: Recording by the stream recorder; Step 4-8: Recording by the default recorder.

6. The integrated test method based on recording and playback according to claim 1, wherein In step 6, through fuzzy matching, it supports fuzzy processing of specified types of input parameters during recording and writing them into the recording file, and uses the same function to perform fuzzy matching on the input parameters of the function during playback, thus ensuring the normal playback of the function.

Images