CN107203465B - System interface testing method and device - Google Patents

Abstract

The embodiments of the present application provide a system interface testing method and device. The method includes the following steps: acquiring a business request initiated by a mock mock object; The processing logic modifies the return object to obtain the expected return object; returns the expected return object to the mock object. In this embodiment of the present application, after obtaining the return object returned by the target calling object for the service request, the return object can be modified according to the preset processing logic to obtain the expected return object, thereby realizing that the actual result or actual request can be flexibly obtained. The parameters are used to change the returned object, which meets the requirements of constructing various complex business scenarios in system interface test automation.

Description

System interface testing method and device

technical field

The present application relates to the technical field of software testing, and in particular, to a system interface testing method and device.

Background technique

System interface testing is mainly used to detect the interaction points between the system and the outside of the system and between various subsystems within the system. The key point of system interface test is to check data exchange, transfer and control management process, as well as mutual logical dependencies between systems.

At present, the existing system interface testing can be implemented through interceptors. Interceptors, on the other hand, typically perform predefined actions before or after the called target method executes, such as choosing to continue executing join points, or short-circuit execution by returning their own return value or throwing an exception. Generally, the return value returned by the interceptor is the return value returned by the called target method, and the return value of the called target method is generally a preset fixed value. Therefore, the achievable test scenarios of the existing system interface testing methods are relatively simple, which cannot meet the increasingly complex system interface testing needs.

SUMMARY OF THE INVENTION

The purpose of the embodiments of the present application is to provide a system interface testing method and device, so as to obtain the returned object more flexibly, so as to realize the system interface testing in complex business scenarios.

In order to achieve the above purpose, an embodiment of the present application provides a system interface testing method, comprising the following steps:

Get the business request initiated by the mock mock object;

After obtaining the return object returned by the target calling object for the business request, modify the return object according to the preset processing logic to obtain the expected return object;

Return the expected return object to the mock object.

On the other hand, the embodiment of the present application also provides a system interface testing device, including:

The request acquisition module is used to acquire the business request initiated by the mock mock object;

The return processing module is configured to modify the return object according to the preset processing logic after obtaining the return object returned by the target calling object for the service request to obtain the expected return object;

The return sending module is used to return the expected return object to the mock object.

In this embodiment of the present application, after obtaining the return object returned by the target calling object for the service request, the return object can be modified according to the preset processing logic to obtain the expected return object, thereby realizing that the actual result or actual request can be flexibly obtained. The parameters are used to change the returned object, which meets the requirements of constructing various complex business scenarios in system interface test automation.

Description of drawings

The drawings described herein are used to provide further understanding of the embodiments of the present application, and constitute a part of the embodiments of the present application, and do not constitute limitations to the embodiments of the present application. In the attached image:

1 is a flowchart of a system interface testing method according to an embodiment of the application;

2 is a structural block diagram of a system interface testing device according to an embodiment of the application;

FIG. 3 is a schematic diagram of a processing flow in a mode including multiple return processing modules in a system interface testing method according to another embodiment of the present application.

Detailed ways

In order to make the purposes, technical solutions and advantages of the embodiments of the present application more clearly understood, the embodiments of the present application will be described in further detail below with reference to the embodiments and the accompanying drawings. Here, the exemplary embodiments and descriptions of the embodiments of the present application are used to explain the embodiments of the present application, but are not intended to limit the embodiments of the present application.

The specific implementations of the embodiments of the present application will be further described in detail below with reference to the accompanying drawings.

Referring to Fig. 1, the system interface testing method of the embodiment of the present application includes the following steps:

S101, obtain a business request initiated by a mock object.

Among them, the mock object is pre-configured, and its configuration can be as follows:

Add Mock With Cond(String mockId,Object expect,String cond,StringiocConfig)

mockId – identifies the intercepted class, that is, the target calling object

expect – the expected return object to construct

cond – process the returned object according to the condition

S102, after obtaining the return object returned by the target calling object for the service request, modify the return object according to preset processing logic to obtain the expected return object.

In an embodiment of the present application, when there are multiple types of processing logics, these processing logics may be unifiedly completed by one return processing module.

In another embodiment of the present application, as shown in FIG. 3 , when there are multiple types of processing logics, each processing logic can be completed by a one-to-one corresponding return processing module (when the system starts, these return processing modules will is initialized and loaded into the memory), and the business request initiated by the mock object is pre-bound with a return processing module. For example, the following configuration can be added to the mock configuration:

iocConfig – returns the distinguished name of the processing module

The identification name indicates the binding return processing module required by the target calling object of this call. Usually, the business request sent by the mock object will carry the identification name of the return processing module. When there is a business request of the target calling object When intercepted, the corresponding return processing module will be called according to the identifier name of the return processing module (that is, after the return object returned by the target calling object for the business request is intercepted, the return processing module will be selected according to the identifier carried in the business request). Generally, the binding is only valid for this call. In the next call, you can pre-bind any other return processing modules as needed to implement tests in other mock scenarios.

Since one processing logic generally corresponds to one test scenario, in this way, not only the function division of each test scenario is relatively clear, the parameter hierarchy is simple and easy to understand, and has good decoupling; but also it is convenient to expand other test scenarios later, and There is no need to change the original return processing module, just add a new return processing module.

In an embodiment of the present application, the modifying the returned object according to the preset processing logic may include:

The specific output parameters in the returned object are modified according to the specific input parameters in the service request.

For example, the ID (identification) generated by a target invocation object is random after each execution, and the target invocation object is generally a part of the test case that needs to be tested, but in the entire test case, due to the usual context. Therefore, after calling the target call object, it is necessary to modify the ID in the return object returned by the target call object according to the predefined condition attributes.

For example, cond="return_param1=request_param1, return_param2=request_param1" means to set the parameter value of the parameter named "request_param1" in the input request to the parameter in the returned object: return_param1,…

Of course, according to the specific situation and needs, return_param1 can also take parameter mode for complex objects, so that any parameter can be obtained from any complex large object. for example:

Take parameters from child objects: param.id, param.name…

Take parameters from an array: param[1].id

Take parameters from list:

Base object: param_list[1]

Complex object: param_list[1].id

Take parameters from map:

Base object: param_map(key)

Complex object: param_map(key).id

In this way, the purpose of adjusting the returned object based on the input parameters is finally realized, so as to obtain the desired returned object.

In another embodiment of the present application, the modifying the returned object according to the preset processing logic may further include:

Modifies specific output parameters in the returned object based on predefined condition properties. After obtaining the business request, the target calling object performs business processing according to the normal process. After obtaining the return object returned by the target calling object, the specific output parameters in the returned object are modified according to the predefined condition attributes, so that the final returned is the expected return object. For example, cond="return_param1=xxx, return_param2=yyy", it means to change the output parameter value named "return_param1" in the result object returned by normal business to xxx; and change the result object returned by normal business named "return_param2" The output parameter value of is modified to yyy.

For example, a certain output parameter returned after the execution of a target calling object is true. If the return of the output parameter is expected to be false, then true needs to be replaced by false to ensure that the subsequent execution of the entire test case is performed as expected. of.

In another embodiment of the present application, the modifying the returned object according to the preset processing logic may further include:

When the mock object needs to call the same target calling object multiple times and is pre-configured with multiple expected return objects, it is determined which one of the multiple expected return objects is selected as the main object according to the specific indication parameters carried in the service request. The expected return object after the call.

For example, cond="PARAM=trans_type, withdraw=1, dback=2" means to judge the specific indication parameter trans_type in the request. When its value is 'withdraw', it returns the first object, and when its value is 'dback', it returns the first object. two objects.

For example, if three return objects A, B, and C are set to a target call object at one time, a test case may call the target call object three times. According to expectations, the return returned after the first call to the target call object is expected. The object is C, the return object returned after the second invocation of the target invocation object is A, and the returned object after the third invocation of the target invocation object is B. Therefore, it can be determined according to a specific indication parameter in the pre-defined conditions. Which return object should be returned each time.

S103, returning the expected return object to the mock object.

Although the process flows described in the various method embodiments above include multiple operations occurring in a particular order, it should be clearly understood that these processes may include more or fewer operations, which may be performed sequentially or in parallel as desired ( e.g. using parallel processors or multi-threaded environments).

In this embodiment of the present application, after obtaining the return object returned by the target calling object for the service request, the return object can be modified according to the preset processing logic to obtain the expected return object, thereby realizing that the actual result or actual request can be flexibly obtained. The parameters are used to change the returned object, which meets the requirements of constructing various complex business scenarios in system interface test automation. In addition, the embodiment of the present application can also process different logic processing scenarios through different return processing modules. Therefore, when the test scenario needs to be expanded in the future, a new return processing module can be added, and it is not necessary to process the original return processing. It is very convenient to change the module.

Referring to Fig. 2, corresponding to the above method embodiment, the system interface testing device of the present application includes:

The request obtaining module 21 is used to obtain the business request initiated by the mock mock object. Among them, the mock object is preset, for example:

Add Mock With Cond(String mockId,Object expect,String cond,StringiocConfig)

mockId – identifies the intercepted class, that is, the target calling object

expect – the expected return object to construct

cond – process the returned object according to the condition

The return processing module 22 is configured to modify the return object according to the preset processing logic after obtaining the return object returned by the target calling object for the service request to obtain the expected return object.

In an embodiment of the present application, when there are multiple types of processing logics, these processing logics may be unifiedly completed by one return processing module.

In another embodiment of the present application, when there are multiple processing logics, each processing logic can be completed by a one-to-one corresponding return processing module (when the system starts, these return processing modules will be initialized and loaded into the memory ), and the business request initiated by the mock object is pre-bound with a return processing module. For example, the following configuration can be added to the mock configuration:

iocConfig – returns the distinguished name of the processing module

The identification name indicates the binding return processing module required by the target calling object of this call. Usually, the business request sent by the mock object will carry the identification name of the return processing module. When there is a business request of the target calling object When intercepted, the corresponding return processing module will be called according to the identifier name of the return processing module (that is, after the return object returned by the target calling object for the business request is intercepted, the return processing module will be selected according to the identifier carried in the business request). Generally, the binding is only valid for this call. In the next call, you can pre-bind any other return processing modules as needed to implement tests in other mock scenarios.

Since one processing logic generally corresponds to one test scenario, in this way, not only the function division of each test scenario is relatively clear, the parameter hierarchy is simple and easy to understand, and has good decoupling; but also it is convenient to expand other test scenarios later, and There is no need to change the original return processing module, just add a new return processing module.

In an embodiment of the present application, the modifying the returned object according to the preset processing logic may include:

The specific output parameters in the returned object are modified according to the specific input parameters in the service request. For example, the ID (identification) generated by a target invocation object is random after each execution, and the target invocation object is generally a part of the test case that needs to be tested, but in the entire test case, due to the usual context. Therefore, after calling the target call object, it is necessary to modify the ID in the return object returned by the target call object according to the predefined condition attributes.

For example, cond="return_param1=request_param1, return_param2=request_param1" means to set the parameter value of the parameter named "request_param1" in the input request to the parameter in the returned object: return_param1,…

Of course, according to the specific situation and needs, return_param1 can also take parameter mode for complex objects, so that any parameter can be obtained from any complex large object. for example:

Take parameters from child objects: param.id, param.name…

Take parameters from an array: param[1].id

Take parameters from list:

Base object: param_list[1]

Complex object: param_list[1].id

Take parameters from map:

Base object: param_map(key)

Complex object: param_map(key).id

In this way, the purpose of adjusting the returned object based on the input parameters is finally realized, so as to obtain the desired returned object.

In another embodiment of the present application, the modifying the returned object according to the preset processing logic may further include:

Modifies specific output parameters in the returned object based on predefined condition properties. After obtaining the business request, the target calling object performs business processing according to the normal process. After obtaining the return object returned by the target calling object, the specific output parameters in the returned object are modified according to the predefined condition attributes, so that the final returned is the expected return object. For example, cond="return_param1=xxx, return_param2=yyy", it means to change the output parameter value named "return_param1" in the result object returned by normal business to xxx; and change the result object returned by normal business named "return_param2" The output parameter value of is modified to yyy.

For example, a certain output parameter returned after the execution of a target calling object is true. If the return of the output parameter is expected to be false, then true needs to be replaced by false to ensure that the subsequent execution of the entire test case is performed as expected. of.

In another embodiment of the present application, the modifying the returned object according to the preset processing logic may further include:

When the mock object needs to call the same target calling object multiple times and is pre-configured with multiple expected return objects, it is determined which one of the multiple expected return objects is selected as the main object according to the specific indication parameters carried in the service request. The expected return object after the call.

For example, cond="PARAM=trans_type, withdraw=1, dback=2" means to judge the specific indication parameter trans_type in the request. When its value is 'withdraw', it returns the first object, and when its value is 'dback', it returns the first object. two objects.

For example, if three return objects A, B, and C are set to a target call object at one time, a test case may call the target call object three times. According to expectations, the return returned after the first call to the target call object is expected. The object is C, the return object returned after the second invocation of the target invocation object is A, and the returned object after the third invocation of the target invocation object is B. Therefore, it can be determined according to a specific indication parameter in the pre-defined conditions. Which return object should be returned each time.

The return sending module 23 is configured to return the expected return object to the mock object.

In this embodiment of the present application, after obtaining the return object returned by the target calling object for the service request, the return object can be modified according to the preset processing logic to obtain the expected return object, thereby realizing that the actual result or actual request can be flexibly obtained. The parameters are used to change the returned object, which meets the requirements of constructing various complex business scenarios in system interface test automation. In addition, the embodiment of the present application can also process different logic processing scenarios through different return processing modules. Therefore, when the test scenario needs to be expanded in the future, it is only necessary to add a new return processing module, and it is not necessary to modify the original return processing module. It is very convenient to return to the processing module to make changes.

The systems, devices, modules or units described in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions.

For the convenience of description, when describing the above device, the functions are divided into various units and described respectively. Of course, when implementing the present application, the functions of each unit may be implemented in one or more software and/or hardware.

Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the various embodiments may be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and for related parts, please refer to the partial descriptions of the method embodiments.

In the 1990s, improvements in a technology could be clearly differentiated between improvements in hardware (eg, improvements to circuit structures such as diodes, transistors, switches, etc.) or improvements in software (improvements in method flow). However, with the development of technology, the improvement of many methods and processes today can be regarded as a direct improvement of the hardware circuit structure. Designers almost get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware entity modules. For example, a Programmable Logic Device (PLD) (eg, Field Programmable Gate Array (FPGA)) is an integrated circuit whose logic function is determined by user programming of the device. It is programmed by the designer to "integrate" a digital system on a PLD without having to ask a chip manufacturer to design and manufacture a dedicated integrated circuit chip 2 . Moreover, today, instead of making integrated circuit chips by hand, this kind of programming is also mostly implemented using "logiccompiler" software, which is similar to the software compiler used in program development and writing, but to compile the previous The original code must also be written in a specific programming language, which is called Hardware Description Language (HDL), and there is not only one HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL(Altera Hardware DescriptionLanguage), Confluence, CUPL(Cornell University Programming Language), HDCal, JHDL(Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL(RubyHardware Description Language), etc. VHDL is currently the most commonly used (Very-High-SpeedIntegrated Circuit Hardware Description Language) and Verilog2. It should also be clear to those skilled in the art that a hardware circuit for implementing the logic method process can be easily obtained by simply programming the method process in the above-mentioned several hardware description languages and programming it into the integrated circuit.

The controller may be implemented in any suitable manner, for example, the controller may take the form of eg a microprocessor or processor and a computer readable medium storing computer readable program code (eg software or firmware) executable by the (micro)processor , logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers and embedded microcontrollers, examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicon Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory.

Those skilled in the art also know that, in addition to implementing the controller in the form of pure computer-readable program code, the controller can be implemented as logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded devices by logically programming the method steps. The same function can be realized in the form of a microcontroller, etc. Therefore, such a controller can be regarded as a hardware component, and the devices included therein for realizing various functions can also be regarded as a structure within the hardware component. Or even, the means for implementing various functions can be regarded as both a software module implementing a method and a structure within a hardware component.

From the description of the above embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform. Based on this understanding, the technical solutions of the present application can be embodied in the form of software products in essence or the parts that make contributions to the prior art, and the computer software products can be stored in storage media, such as ROM/RAM, magnetic disks , CD-ROM, etc., including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of the present application.

The present application may be used in numerous general purpose or special purpose computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, including A distributed computing environment for any of the above systems or devices, and the like.

The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

Although the application has been described by way of examples, those of ordinary skill in the art will recognize that the application is subject to many modifications and variations without departing from the spirit of the application, and the appended claims are intended to include such modifications and changes without departing from the spirit of the application.

Claims (8)

1. a system interface testing method, is characterized in that, comprises the following steps: Obtain the business request initiated by the simulated mock object; the business request includes specific indication parameters; After obtaining the return object returned by the target calling object for the service request, modify the return object according to the preset processing logic to obtain the expected return object; wherein, when there are multiple types of processing logic, each processing logic The logic is completed by a one-to-one corresponding return processing module, and the business request initiated by the mock object is pre-bound with a return processing module; wherein, when the mock object needs to call the same target call object multiple times and pre-configured multiple When there are expected return objects, decide which of the plurality of expected return objects is selected as the expected return object after this call according to the specific indication parameter; Return the expected return object to the mock object. 2. The system interface testing method according to claim 1, wherein the modifying the returned object according to a preset processing logic comprises: The specific output parameters in the returned object are modified according to the specific input parameters in the service request. 3. The system interface testing method according to claim 1, wherein the modifying the returned object according to a preset processing logic comprises: Specific output parameters in the returned object are modified according to predefined condition properties. 4. The system interface testing method according to claim 1, wherein the binding comprises: The service request carries the identifier of the returned processing module. 5. A system interface testing device, characterized in that, comprising: A request acquisition module is used to acquire a business request initiated by a simulated mock object; the business request includes specific indication parameters; The return processing module is configured to modify the return object according to the preset processing logic after obtaining the return object returned by the target calling object for the service request, and obtain the expected return object; wherein, when the processing logic has multiple In this case, each processing logic is completed by a one-to-one corresponding return processing module, and the business request initiated by the mock object is bound in advance with a return processing module; wherein, when the mock object needs to call the same target call multiple times object and pre-configured with multiple expected return objects, decide which of the multiple expected return objects to select as the expected return object after this call according to the specific indication parameter; The return sending module is used to return the expected return object to the mock object. 6. The system interface testing device according to claim 5, wherein the modifying the returned object according to a preset processing logic comprises: The specific output parameters in the returned object are modified according to the specific input parameters in the service request. 7. The system interface testing device according to claim 5, wherein the modifying the returned object according to a preset processing logic comprises: Specific output parameters in the returned object are modified according to predefined condition properties. 8. The system interface testing device according to claim 5, wherein the binding comprises: The service request carries the identifier of the returned processing module.

Images