CN112328486A

CN112328486A - Interface automation test method and device, computer equipment and storage medium

Info

Publication number: CN112328486A
Application number: CN202011232732.5A
Authority: CN
Inventors: 陈林
Original assignee: OneConnect Financial Technology Co Ltd Shanghai
Current assignee: OneConnect Smart Technology Co Ltd; OneConnect Financial Technology Co Ltd Shanghai
Priority date: 2020-11-06
Filing date: 2020-11-06
Publication date: 2021-02-05
Also published as: WO2022095518A1

Abstract

The embodiment of the application belongs to the technical field of testing, and relates to an automatic interface testing method, which comprises the steps of determining a testing purpose corresponding to a testing instruction when the testing instruction sent by a user is received, calling a preset dto layer based on a testing case layer, and generating interface entry references through the dto layer based on the testing purpose; acquiring the interface access parameter based on the test case layer, and generating an interface request based on the interface access parameter, wherein the interface request carries the test purpose; and based on the test purpose, calling an execution strategy corresponding to the test purpose in a preset API layer to execute the interface request, and completing the interface test. The application also provides an interface automation testing device, computer equipment and a storage medium. Among other things, the execution policies in the API layer may be stored in a blockchain. The method and the device effectively improve the reusability of the test cases and improve the test efficiency.

Description

Interface automation test method and device, computer equipment and storage medium

Technical Field

The present application relates to the field of testing technologies, and in particular, to an interface automated testing method and apparatus, a computer device, and a storage medium.

Background

With the acceleration of the informatization process and the increasing level of computers, all industries have applied computers to carry out efficient work, examination and approval and other affairs, when information interaction is carried out among different servers, interfaces are required to be called frequently to provide better services for users, and the interfaces are required to be called and tested before being provided for the users.

At present, most of common interface call test schemes directly write interface parameters into a test strategy of a test case layer, and when the interface parameters are changed, parameter contents in the corresponding test strategy need to be modified. As the variety of items increases, this approach results in a less reusable test strategy and the drawback of inefficient testing gradually emerges.

Disclosure of Invention

The embodiment of the application aims to provide an interface automatic testing method, an interface automatic testing device, computer equipment and a storage medium, so that the reusability of test cases is effectively improved, and the testing efficiency is improved.

In order to solve the above technical problem, an embodiment of the present application provides an interface automation test method, which adopts the following technical solutions:

an interface automatic testing method comprises the following steps:

when a test instruction sent by a user is received, determining a test purpose corresponding to the test instruction, calling a preset dto layer based on a test case layer, and generating an interface entry parameter through the dto layer based on the test purpose;

acquiring the interface access parameter based on the test case layer, and generating an interface request based on the interface access parameter, wherein the interface request carries the test purpose;

and calling an execution strategy corresponding to the test purpose in a preset API layer to execute the interface request based on the test purpose, and completing the interface test.

Further, the API layer includes a first interface and a second interface, where the first interface is packaged with different main execution policies, and the second interface is packaged with different sub execution policies, and based on the test purpose, the API layer calls an execution policy corresponding to the test purpose in a preset API layer to execute the interface request, and the step of completing the interface test includes:

based on the test purpose, calling a corresponding main execution strategy in the first interface, and calling at least one corresponding auxiliary execution strategy in the second interface through the main execution strategy to execute the interface request to obtain a final execution result;

returning the final execution result to the first interface, and returning the final execution result to the test case layer through the first interface;

and calling an assertion tool in a preset tool layer through the test case layer, asserting the final execution result, and obtaining an assertion result to finish the interface test.

Further, the step of invoking, by the primary execution policy, at least one secondary execution policy corresponding to the second interface to execute the interface request to obtain a final execution result includes:

when the secondary execution strategy called by the main execution strategy is one, obtaining a final execution result;

and when receiving a continuous execution instruction returned by the first interface, executing the next auxiliary execution strategy until all the auxiliary execution strategies called by the current main execution strategy are executed, and obtaining a final execution result.

Further, the step of the first interface including a first main execution policy, a second main execution policy, and a third main execution policy, the second interface including a first sub execution policy, a second sub execution policy, and a third sub execution policy, based on the test purpose, invoking the corresponding main execution policy in the first interface, and invoking at least one corresponding sub execution policy in the second interface through the main execution policy to execute the interface request, and obtaining a final execution result includes:

identifying the test purpose;

when the test purpose is parameter encryption, calling a first main execution strategy in the first interface, calling a first auxiliary execution strategy in the second interface through the first main execution strategy to execute parameter encryption, and obtaining a final execution result;

when the test purpose is log comparison, calling a second main execution strategy in the first interface, calling a first sub execution strategy and a second sub execution strategy in the second interface through the second main execution strategy, and respectively executing parameter encryption and log comparison in sequence to obtain an intermediate execution result and a final execution result;

and when the test purpose is notification log comparison, calling a third main execution strategy in the first interface, calling a first sub execution strategy, a second sub execution strategy and a third sub execution strategy in the second interface through the third main execution strategy, and respectively and sequentially executing parameter encryption, log comparison and notification log comparison to obtain an intermediate execution result and a final execution result.

Further, the dto layers include different dto classes, the dto classes have different parameter generation strategies, and the step of determining a test purpose corresponding to a test instruction when the test instruction sent by a user is received, calling a preset dto layer based on a test case layer, and generating an interface entry through the dto layer based on the test purpose includes:

when a test instruction sent by a user is received, determining a test target user and a test purpose corresponding to the test instruction;

calling a preset dto layer based on the test case layer;

selecting corresponding dto classes based on the test target users, wherein the test target users are in one-to-one correspondence with the dto classes;

determining a corresponding parameter generation strategy in the dto classes based on the test purpose, and generating an interface entry through the parameter generation strategy.

Further, the parameter generation policy includes an assembly policy, and the step of generating an interface entry through the parameter generation policy includes:

when the corresponding parameter generation strategy in the dto classes determined based on the test purpose is an assembly strategy, acquiring preset interface parameters based on the test purpose, assembling the interface parameters through the dto layer, and generating interface entry parameters.

Further, the parameter generation policy includes a random generation policy, and the step of generating the interface entry parameter by the parameter generation policy includes:

when the corresponding parameter generation strategy in the dto classes determined based on the test purpose is a random generation strategy, acquiring a preset interface parameter based on the test purpose, and calling a random number generation tool in a preset tool layer through the dto layer;

acquiring a time stamp, generating a random number according to the time stamp based on the random number generation tool, and assembling the random number and preset interface parameters through the dto layer to generate interface access parameters.

In order to solve the above technical problem, an embodiment of the present application further provides an interface automation testing apparatus, which adopts the following technical scheme:

an interface automated testing apparatus, comprising:

the parameter generation module is used for determining a test purpose corresponding to a test instruction when the test instruction sent by a user is received, calling a preset dto layer based on a test case layer, and generating an interface entry parameter based on the test purpose through the dto layer;

the request sending module is used for acquiring the interface access parameter based on the test case layer and generating an interface request based on the interface access parameter, wherein the interface request carries the test purpose;

and the request execution module is used for calling an execution strategy corresponding to the test purpose in a preset API layer to execute the interface request based on the test purpose so as to finish the interface test.

In order to solve the above technical problem, an embodiment of the present application further provides a computer device, which adopts the following technical solutions:

a computer device comprising a memory having computer readable instructions stored therein and a processor that when executed implements the steps of the method for automated testing of an interface described above.

In order to solve the above technical problem, an embodiment of the present application further provides a computer-readable storage medium, which adopts the following technical solutions:

a computer readable storage medium having computer readable instructions stored thereon which, when executed by a processor, implement the steps of the interface automation test method described above.

Compared with the prior art, the embodiment of the application mainly has the following beneficial effects:

the independent generation of the interface input parameters is realized through the separately arranged dto layer, and then the generated interface input parameters are transmitted to the test case layer, so that the condition that the test strategy reusability is low due to the fact that the test strategy needs to be correspondingly modified when the parameters of the interface are changed every time is avoided. When the parameters of the interface need to be modified, only the generation method of the interface input parameters in the dto layer needs to be modified, and the test case layer does not need to be modified, so that the reusability of the test strategy in the test case layer is effectively improved, and the test efficiency is improved. Different from the prior art that each step of execution process needs to call the corresponding API, the method calls different execution strategies in the API layer according to different test purposes in the execution process. The simplicity and the understandability of the whole testing process are improved, and the quick execution of the testing process is realized.

Drawings

In order to more clearly illustrate the solution of the present application, the drawings needed for describing the embodiments of the present application will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application, and that other drawings can be obtained by those skilled in the art without inventive effort.

FIG. 1 is an exemplary system architecture diagram in which the present application may be applied;

FIG. 2 is a flow diagram of one embodiment of a method for automated testing of an interface according to the present application;

FIG. 3 is a schematic block diagram of one embodiment of an interface automated test equipment according to the present application;

FIG. 4 is a schematic block diagram of one embodiment of a computer device according to the present application.

Reference numerals: 200. a computer device; 201. a memory; 202. a processor; 203. a network interface; 300. an interface automation test device; 301. a parameter generation module; 302. a request sending module; 303. and requesting an execution module.

Detailed Description

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used in the description of the application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "including" and "having," and any variations thereof, in the description and claims of this application and the description of the above figures are intended to cover non-exclusive inclusions. The terms "first," "second," and the like in the description and claims of this application or in the above-described drawings are used for distinguishing between different objects and not for describing a particular order.

Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.

In order to make the technical solutions better understood by those skilled in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

As shown in fig. 1, the system architecture 100 may include

terminal devices

101, 102, 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the

terminal devices

101, 102, 103 and the server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

The user may use the

terminal devices

101, 102, 103 to interact with the server 105 via the network 104 to receive or send messages or the like. The

terminal devices

101, 102, 103 may have various communication client applications installed thereon, such as a web browser application, a shopping application, a search application, an instant messaging tool, a mailbox client, social platform software, and the like.

The

terminal devices

101, 102, 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III, mpeg compression standard Audio Layer 3), MP4 players (Moving Picture Experts Group Audio Layer IV, mpeg compression standard Audio Layer 4), laptop portable computers, desktop computers, and the like.

The server 105 may be a server providing various services, such as a background server providing support for pages displayed on the

terminal devices

101, 102, 103.

It should be noted that, the interface automation test method provided in the embodiment of the present application is generally executed by a server/terminal device, and accordingly, the interface automation test apparatus is generally disposed in the server/terminal device.

It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

With continued reference to FIG. 2, a flow diagram of one embodiment of a method for automated testing of an interface is shown, in accordance with the present application. The automatic interface testing method comprises the following steps:

s1: when a test instruction sent by a user is received, a test purpose corresponding to the test instruction is determined, a preset dto layer is called based on a test case layer, and an interface entry is generated through the dto layer based on the test purpose.

In this embodiment, the test purpose is included in the test strategy of the test case layer, and the corresponding test purpose in the test case layer is determined according to the test instruction. DTO (Data Transfer Object) is generally used for saving and transferring Data. According to the method, the dto layer and the test case layer are combined, information such as interface entry parameters contained in the test strategy (namely, case method) in the original test case layer is generated through the dto layer, and different test strategies can be repeatedly used. And the dto layer can be combined with different test strategies in the test case layer to meet the requirements of different test strategies for generating different types of parameters. In the application process, due to the change of the requirement, the change of the parameters may be caused, and further the change of the test strategy in the test case layer is caused. For example: when a certain requirement is optimized, a certain interface needs to be added with a necessary filling parameter, and the interface has 50 original parameters, and the interface has at least 51 test policies (i.e. case methods), wherein the test policies include 1 admission policy and 50 parameter verification test policies (i.e. case methods). In this case, the parameter part of the 51 test strategies needs to be modified. After the generation interface is uniformly managed by the dto layer, only the generation parameter method of the corresponding interface in the dto class needs to be modified, and the corresponding test case and the test method do not need to be modified, so that the multiplexing of the test strategy and the test speed of a computer are effectively improved.

In this embodiment, the electronic device (for example, the server/terminal device shown in fig. 1) on which the interface automation test method operates may receive the test purpose through a wired connection manner or a wireless connection manner. It should be noted that the wireless connection means may include, but is not limited to, a 3G/4G connection, a WiFi connection, a bluetooth connection, a WiMAX connection, a Zigbee connection, a uwb (ultra wideband) connection, and other wireless connection means now known or developed in the future.

Specifically, the dto layers include different dto classes, the dto classes have different parameter generation strategies, and the step of determining a test purpose corresponding to a test instruction when the test instruction sent by a user is received, calling a preset dto layer based on a test case layer, and generating an interface entry parameter through the dto layer based on the test purpose includes:

calling a preset dto layer based on the test case layer;

In this embodiment, the parameter generation policy and the test purpose are in a one-to-one correspondence relationship. The Dto layer includes different dto classes, and different test target users correspond to different dto classes, for example: a bank may correspond to a category of dto. Different parameter generation strategies (namely dto generation methods) are included under the dto category, and different dto generation methods correspond to different test purposes. By the arrangement, unified maintenance and management are facilitated, and when the interface parameters change due to change of project requirements, only the corresponding dto types need to be found, and the dto generation method of the corresponding interface under the type needs to be maintained. Different dto classes satisfy the need for different test strategies to generate different types of parameters, such as: and setting a default dto type to generate parameters of a normal scene, and transmitting a key and a value, so that the dto type generates corresponding parameters according to the received key and the value. Specifically, the imported key is a request serial number (applyNo), the value is null (null), and a test case for checking a parameter of which the request serial number parameter is null is further generated. For example: when the interface parameters need to be changed due to the change of the actual requirements, the a interface has 1, 2 and 3 parameters, and becomes 2, 3 and 4 parameters, and then only the method for generating the a interface parameters needs to be modified at the dto level, and the modified parameters are 2, 3 and 4. In addition, a 4-parameter verification method is added corresponding to the 1-parameter verification method of removing the interface A at the test case layer.

In addition, the parameter generation policy includes an assembly policy, and the step of entering the parameters through the parameter generation policy generation interface includes:

In this embodiment, when a fixed parameter needs to be tested, the computer receives a set interface parameter, assembles the interface parameter through a test case layer call dto layer, and generates an interface entry parameter. If the fixed parameters are not needed, and the random test is performed, the interface entry can be generated through the dto layer directly according to the requirement.

Correspondingly, the parameter generation strategy comprises a random generation strategy, and the step of generating the interface entry parameters through the parameter generation strategy comprises the following steps:

In the present embodiment, the Dto layer calls a random number generation tool in the tool layer (util layer) to generate a random number, wherein the random number generation tool may adopt a random number generation function packaged in advance. The design of the Dto layer is convenient for carry out decoupling with the test case layer, and set up dto layer alone and carry out the generation of interface income parameter, satisfies the demand that the parameter can used repeatedly. While dto layers may randomly generate parameters. For example: in loan applications, it is generally required that the same user cannot repeatedly apply for the same loan product. In the interface testing process, the identity information of the user, such as the mobile phone number, the identification card number, the bank card number and the like, cannot be reused. Therefore, random numbers can be generated randomly through the time stamps, so that parameters are not generated repeatedly, and various test cases can be executed repeatedly.

S2: and acquiring the interface access parameter based on the test case layer, and generating an interface request based on the interface access parameter, wherein the interface request carries the test purpose.

In this embodiment, the test Case layer, i.e. the Case layer, is used to define a test policy (Case method), which includes two types, a flow test policy and a parameter verification test policy. Because the interface is generated and participated in through the dto layer, the code template of the test strategy defined by the test case layer is more uniform, clear and simple, the test strategy is convenient to be quickly copied to other projects, and the learning cost and the maintenance cost of the test strategy of related personnel are lower. And the test case layer sends corresponding interface requests to the API layer according to different test purposes, and the API layer is used for defining called APIs.

S3: and calling an execution strategy corresponding to the test purpose in a preset API layer to execute the interface request based on the test purpose, and completing the interface test.

In this embodiment, different execution strategies are preset in the calling API layer, and different execution strategies are selected according to different test purposes, which is convenient for rapid automatic testing.

Specifically, the API layer includes a first interface and a second interface, the first interface is packaged with different main execution strategies, the second interface is packaged with different sub-execution strategies, the API layer calls an execution strategy corresponding to the test purpose in a preset API layer to execute the interface request based on the test purpose, and the step of completing the interface test includes:

In this embodiment, different master execution policies are encapsulated in the first interface (FlowBaseAPI). Different secondary execution strategies are packaged in a second interface (BaseAPI), wherein one-to-one and one-to-many corresponding relations exist between the primary execution strategies and the secondary execution strategies. When the main execution strategy calls a plurality of auxiliary execution strategies, the auxiliary execution strategies sequentially execute corresponding operations, namely after one auxiliary execution strategy is executed, the result is returned to the first interface, and when a continuous execution instruction returned by the first interface is received, the next auxiliary execution strategy is continuously executed. Based on different test purposes, different main execution strategies in the first interface and different auxiliary execution strategies in the second interface are called. Two interfaces with progressive relation are arranged in the API layer, namely, the main execution strategy in the first interface calls at least one corresponding auxiliary execution strategy in the second interface, so that the automatic test is carried out orderly. The test case layer only accepts a final execution result (i.e., a final processing result) returned by the first interface, wherein the assertion tool is used for asserting the final execution result, a commonly used assertion tool is jsonnaissertion, compares the final execution result with a pre-assumed result, and then outputs a consistent or inconsistent result as the assertion result.

In this embodiment, the test case layer only accepts the final execution result (i.e., the final processing result) returned by the first interface. Multiple steps of operation may be executed in the second interface, each step of operation returns an intermediate execution result to the first interface, and the whole process is processed in the API layer. Through the arrangement of the first interface and the second interface, organized execution of different interface tests is realized, an intermediate execution result is returned to the first interface, the whole operation process is ensured to be in an API layer, the first interface calls a next auxiliary execution strategy after receiving the intermediate execution result, the final execution result is returned to the test case layer until the final execution result is received, the test case layer is ensured not to be concerned about the intermediate execution process, only the final execution result is received, and test confusion is effectively avoided.

Specifically, the step of obtaining a final execution result includes:

identifying the test purpose;

In this embodiment, in the case that the test purpose is parameter encryption, the returned result of the parameter encryption belongs to the final execution result. In the test purpose of log comparison, the result returned by parameter encryption belongs to the intermediate execution result, and the result returned by log comparison belongs to the final execution result. And in the test purpose of notification log comparison, the results returned by the parameter encryption operation and the log comparison operation belong to intermediate execution results. And informing the result returned by the log comparison operation of the class to belong to the final execution result. One or more auxiliary execution strategies are called through the main execution strategy, so that the control of the main execution strategy on the auxiliary execution strategies in an API layer is realized, and the test process can be carried out orderly according to the control of the main execution strategy. The first interface (FlowBaseAPI) includes three different master execution policies (i.e., methods): 1) getAPIResult method: and sending an interface request. 2) getCompleeLogResult method: sending an interface request, and comparing interface logs. 3) getCompleNetwoLogResult method: sending an interface request, comparing interface logs, and informing the interface logs to compare. The second interface (BaseAPI) includes three different secondary execution strategies: 1) getAPIResult method: the message is encrypted and a post request is sent. 2) The compalog method: the interface parameter accessing and the log calling correlation side interface parameter accessing comparison specifically comprise: and extracting the interface parameters of the request correlation party in the log according to the keywords, comparing the parameters with the interface input parameters, and comparing the value values according to the keys with the same interface. 3) The companoneloticelog method comprises the following steps: and (4) comparing parameters in the interface entry and notification class logs.

This application needs to explain and understand that: the parameter encryption step is executed in the test purpose of parameter encryption, log comparison and notification log comparison. The log comparison step is performed in the test purpose of both log comparison and notification-type log comparison. The step of notification class log comparison is only performed when the test purpose is notification class log comparison.

When the test purpose is log comparison, the steps of calling the second main execution strategy, the first sub execution strategy and the second sub execution strategy to execute the parameter encryption operation and the log comparison operation comprise:

when the test purpose is log comparison, calling a second main execution strategy to send a log comparison request to the second interface;

calling a diary extraction tool class in a preset tool layer through a first secondary execution strategy in the second interface, carrying out log query based on a preset request serial number to obtain an interface log, and returning the interface log to the first interface as an intermediate execution result;

when a continuous execution instruction sent by the first interface is received, acquiring a parameter of a calling association party interface in the interface log through the second secondary execution strategy, comparing the parameter of the calling association party interface with the interface input parameter, and acquiring a log comparison result as the final execution result.

In this embodiment, a general application system prints a log in order to check the operation condition and analyze the cause of the problem. The log records the program execution process, execution information, and the like. After an interface request is sent to an application system to be tested when testing is started, request information sent when the system to be tested calls a correlation party cannot be directly obtained, the request information can only be obtained through log information printed by a server to be tested, a log needs to be extracted to obtain request parameters of the correlation party to be called, and then the request parameters are compared with interface input parameters generated by an dto layer to determine that the request parameters in the request information of the correlation party to be called by the system to be tested are correct, wherein the request parameters in the request information of the correlation party to be called by the system to be tested are the interface input parameters obtained through transparent transmission. Because the request serial number (applyNo) of the tested system requesting the correlation party is unique, the request serial number (applyNo) can be used as an interface log printing mark and an extraction log key word to accurately extract the interface log of the log file.

Further, the step of obtaining the parameter of the calling associated party interface in the interface log, comparing the parameter of the calling associated party interface with the interface input parameter, and obtaining the log comparison result includes:

matching the interface log through a preset regular expression to obtain a parameter for calling an interface of an associated party in the interface log;

comparing whether the parameters of the calling associated party interface are the same as the key of the interface input parameter or not;

and when the keys are the same, comparing whether the corresponding values are consistent or not to obtain a log comparison result.

In the present embodiment, a regular expression uses a single character string to describe and match a series of character strings that conform to a certain syntactic rule. The log files of the associated party are matched through a preset regular expression, and the request parameters of the interface associated party are obtained, wherein the associated party can comprise a bank party or a platform party. The method can package the parameter extraction mode into the log extraction API, and directly calls the log extraction API when the parameters are extracted, and specifically comprises the following steps: and reading the log file printed by the tested system, following the log printing information of the tested system, and extracting the request parameters of the associated party.

The following is a detailed implementation of the above embodiments of the present application:

the step of performing the parameter encryption comprises: 1) calling a first main execution strategy in the first interface (FlowBaseAPI) to send a post request to the second interface (BaseAPI), wherein the post request carries the interface join; 2) performing parameter encryption on the interface input parameters through an Http tool in a first secondary execution strategy calling tool layer in the second interface to generate an encrypted message; 3) based on the encrypted message, calling the Http tool to initiate an interface admission request through a first secondary execution strategy in the second interface, and generating a response result; 4) transmitting the response result to a first interface; 5) the first interface transmits the response result to a test case layer; 6) and the test case layer calls an assertion tool to assert the response result, generates an assertion result and completes the interface test. Because the application system generally encrypts the request information due to security requirements, in the testing process, the application also needs to encrypt the request parameters first, then issue the request, and determine whether the response result meets the expectation through assertion. The method also comprises the steps of comparing the encrypted message with an expected result, determining whether the encrypted message is consistent with the expected result, and if so, determining that the parameter encryption test is correct.

The step of performing the log comparison comprises: 1) calling a second main execution strategy in the first interface to send a log comparison request to the second interface; 2) performing log query by using a second sub-execution strategy in the second interface to call a diary extraction tool class (GetLogUnits) in a tool layer to obtain an interface log; 3) acquiring parameters of a calling associated party interface in the interface log, and comparing the parameters of the calling associated party interface with the interface input parameters to obtain a log comparison result; 4) returning the log comparison result to the first interface; 5) the first interface transmits the log comparison result to a test case layer; 6) and the test case layer calls an assertion tool to assert the log comparison result, generates an assertion result and completes the interface test. After an interface request is sent to the tested application system, the sent request information when the tested system calls the associated party cannot be directly obtained, and the request information can only be obtained through log information printed by the tested server, the log needs to be extracted to obtain the request parameter of the calling associated party, and then the request parameter is compared with the interface input parameter generated by the dto layer to determine that the request parameter in the request information of the calling associated party of the tested system is correct, wherein the request parameter in the request information of the calling associated party of the tested system is the interface input parameter obtained through transparent transmission.

The step of performing the notification class log comparison comprises: 1) calling a third main execution strategy of the first interface to send a notification interface log comparison request to the second interface; 2) a log set of a notification class is traversed by a log extraction tool class (GetLogUnits) in a tool layer is called through a third auxiliary execution strategy in the second interface, and a corresponding notification class log is obtained; 3) extracting and comparing notification interface parameters corresponding to different correlation parties in the notification log to obtain a comparison result of the notification log; 4) returning the notification log comparison result to the first interface; 5) the first interface transmits the notification log comparison result to a test case layer; 6) and the test case layer calls an assertion tool (JsonAssertion) to assert the log comparison result, generates an assertion result and completes the interface test. For notifications, many notifications are asynchronous and not sent in real-time. Therefore, when the notification needs to be sent, the parameters in the notification log need to be compared additionally to determine that the parameters in the notification are correct.

It should be noted that: the tool classes in the application are all deployed in a tool layer (util), and the tool layer (util) includes different tool classes, such as an Http tool class (Http tool), a diary extraction tool class (GetLogUnits), an assertion tool class (jsonnaisertion), a parameter type conversion tool class, a random generation data tool class, for example, a mobile phone number, a bank card number, an identity card number, and the like can be randomly generated, a log platform reading tool class, a configuration file reading tool class, a request sending tool class, and the like.

In addition, the application is further provided with a Config layer, the Config layer is used for defining configuration, the Config layer comprises environment information (Config-properties), constant parameters and the like, and if the configuration information needs to be changed subsequently, the configuration information can be modified and maintained uniformly on the Config layer.

Specifically, the method comprises the following steps: the environment information is used for the test case layer, such as interface IP, port, request URL, log file path, log file name and other information, if the subsequent environment information is changed, only the unified modification in the Config configuration file is needed, and the content in the test case layer is not needed to be modified. The constant parameters refer to: for example, a part of random numbers in the generation method of the dto layer are generated by tool classes of the tool layer. Some parameters are constants, and a plurality of interfaces and a plurality of dto methods may be used, and may be written in the Config configuration file, and if a constant value is required to be changed later, the plurality of dto methods need not be modified, and only the methods need to be modified uniformly in the Config configuration file.

It is emphasized that, in order to further ensure the privacy and security of the execution policy in the API layer, the execution policy in the API layer may also be stored in a node of a blockchain.

The block chain referred by the application is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. A block chain (Blockchain), which is essentially a decentralized database, is a series of data blocks associated by using a cryptographic method, and each data block contains information of a batch of network transactions, so as to verify the validity (anti-counterfeiting) of the information and generate a next block. The blockchain may include a blockchain underlying platform, a platform product service layer, an application service layer, and the like.

The application is operational with numerous general purpose or special purpose computing system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet-type devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include 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 memory storage devices.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware associated with computer readable instructions, which can be stored in a computer readable storage medium, and when executed, can include processes of the embodiments of the methods described above. The storage medium may be a non-volatile storage medium such as a magnetic disk, an optical disk, a Read-Only Memory (ROM), or a Random Access Memory (RAM).

It should be understood that, although the steps in the flowcharts of the figures are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and may be performed in other orders unless explicitly stated herein. Moreover, at least a portion of the steps in the flow chart of the figure may include multiple sub-steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, which are not necessarily performed in sequence, but may be performed alternately or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

With further reference to fig. 3, as an implementation of the method shown in fig. 2, the present application provides an embodiment of an interface automation testing apparatus, which corresponds to the embodiment of the method shown in fig. 2, and which can be applied to various electronic devices.

As shown in fig. 3, the interface automatic test apparatus 300 according to the present embodiment includes: a parameter generation module 301, a request sending module 302 and a request execution module 303. Wherein: the parameter generating module 301 is configured to, when a test instruction sent by a user is received, determine a test purpose corresponding to the test instruction, call a preset dto layer based on a test case layer, and generate an input parameter through the dto layer generation interface based on the test purpose; a request sending module 302, configured to obtain the interface entry parameter based on the test case layer, and generate an interface request based on the interface entry parameter, where the interface request carries the test purpose; and the request execution module 303 is configured to invoke an execution policy corresponding to the test purpose in a preset API layer to execute the interface request based on the test purpose, so as to complete interface testing.

In this embodiment, the independent generation of the interface input parameters is realized through the separately arranged dto layer, and then the generated interface input parameters are transmitted to the test case layer, so that the situation that the test strategy reusability is low because the test strategy needs to be modified correspondingly every time the parameters of the interface are changed is avoided. When the parameters of the interface need to be modified, only the generation method of the interface input parameters in the dto layer needs to be modified, and the test case layer does not need to be modified, so that the reusability of the test strategy in the test case layer is effectively improved, and the test efficiency is improved. Different from the prior art that each step of execution process needs to call the corresponding API, the method calls different execution strategies in the API layer according to different test purposes in the execution process. The simplicity and the understandability of the whole testing process are improved, and the quick execution of the testing process is realized.

The dto layer comprises different dto classes, the dto classes have different parameter generation strategies, and the parameter generation module 301 comprises a determination submodule, a calling submodule, a selection submodule and a generation submodule. The determining submodule is used for determining a test target user and a test purpose corresponding to a test instruction when the test instruction sent by a user is received; the calling submodule is used for calling a preset dto layer based on the test case layer; the selection submodule is used for selecting corresponding dto types based on the test target users, wherein the test target users and the dto types are in one-to-one correspondence; and the generation submodule is used for determining a corresponding parameter generation strategy in the dto classes based on the test purpose and generating an interface entry parameter through the parameter generation strategy.

In some optional implementations of this embodiment, the parameter generation policy includes an assembly policy, and the generation submodule is further configured to: when the corresponding parameter generation strategy in the dto classes determined based on the test purpose is an assembly strategy, acquiring preset interface parameters based on the test purpose, assembling the interface parameters through the dto layer, and generating interface entry parameters.

The parameter generation strategy comprises a random generation strategy, and the generation submodule comprises a calling unit and a generating unit. The calling unit is used for acquiring preset interface parameters based on the test purpose and calling a random number generation tool in a preset tool layer through the dto layer when the corresponding parameter generation strategy in the dto classes determined based on the test purpose is a random generation strategy; the generation unit is used for acquiring a time stamp, generating a random number according to the time stamp based on the random number generation tool, and assembling the random number and preset interface parameters through the dto layer to generate interface access parameters.

The request execution module 303 includes an execution sub-module, a return sub-module, and an assertion sub-module, where the execution sub-module is configured to invoke a corresponding main execution policy in the first interface based on the test purpose, and invoke at least one corresponding sub-execution policy in the second interface through the main execution policy to execute the interface request, so as to obtain a final execution result; the return submodule is used for returning the final execution result to the first interface and returning the final execution result to the test case layer through the first interface; the assertion submodule is used for calling an assertion tool in a preset tool layer through the test case layer, asserting the final execution result and obtaining an assertion result to finish the interface test.

In some optional implementations of this embodiment, the execution submodule is further configured to: when the number of the secondary execution strategies called by the main execution strategy is one, a final execution result is obtained, when the number of the secondary execution strategies called by the main execution strategy is multiple, the secondary execution strategies are sequentially executed, wherein an intermediate execution result is obtained when one secondary execution strategy is executed, the intermediate execution result is returned to the first interface, and when a continuous execution instruction returned by the first interface is received, the next secondary execution strategy is executed until all the secondary execution strategies called by the current main execution strategy are executed, and the final execution result is obtained.

The first interface comprises a first main execution strategy, a second main execution strategy and a third main execution strategy, the second interface comprises a first auxiliary execution strategy, a second auxiliary execution strategy and a third auxiliary execution strategy, and the execution sub-module further comprises an identification unit, an encryption unit, a log comparison unit and a notification log comparison unit. The identification unit is used for identifying the test purpose; the encryption unit is used for calling a first main execution strategy in the first interface when the test purpose is parameter encryption, calling a first auxiliary execution strategy in the second interface through the first main execution strategy to execute parameter encryption, and obtaining a final execution result; the log comparison unit is used for calling a second main execution strategy in the first interface when the test purpose is log comparison, calling a first sub execution strategy and a second sub execution strategy in the second interface through the second main execution strategy, and respectively executing parameter encryption and log comparison in sequence to obtain an intermediate execution result and a final execution result; the notification log comparison unit is used for calling a third main execution strategy in the first interface when the test purpose is notification log comparison, calling a first sub execution strategy, a second sub execution strategy and a third sub execution strategy in the second interface through the third main execution strategy, and respectively and sequentially executing parameter encryption, log comparison and notification log comparison to obtain an intermediate execution result and a final execution result.

The notification log comparison unit comprises a calling subunit, a query subunit and a comparison subunit. The calling subunit is used for calling a second main execution strategy to send a log comparison request to the second interface when the test purpose is log comparison; the query subunit is configured to call a diary extraction tool class in a preset tool layer through a first secondary execution policy in the second interface, perform log query based on a preset request serial number to obtain an interface log, and return the interface log to the first interface as an intermediate execution result; and the comparison sub-unit is used for acquiring the parameter of the calling association party interface in the interface log through the second sub-execution strategy when receiving the continuous execution instruction sent by the first interface, and comparing the parameter of the calling association party interface with the interface input parameter to acquire a log comparison result as the final execution result.

In some optional implementations of this embodiment, the above-mentioned sub-subunit module is further configured to: matching the interface log through a preset regular expression to obtain a parameter for calling an interface of an associated party in the interface log; comparing whether the parameters of the calling associated party interface are the same as the key of the interface input parameter or not; and when the keys are the same, comparing whether the corresponding values are consistent or not to obtain a log comparison result.

In order to solve the technical problem, an embodiment of the present application further provides a computer device. Referring to fig. 4, fig. 4 is a block diagram of a basic structure of a computer device according to the present embodiment.

The computer device 200 comprises a memory 201, a processor 202, a network interface 203 communicatively connected to each other via a system bus. It is noted that only computer device 200 having

components

201 and 203 is shown, but it is understood that not all of the illustrated components are required and that more or fewer components may alternatively be implemented. As will be understood by those skilled in the art, the computer device is a device capable of automatically performing numerical calculation and/or information processing according to a preset or stored instruction, and the hardware includes, but is not limited to, a microprocessor, an Application Specific Integrated Circuit (ASIC), a Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), an embedded device, and the like.

The computer device can be a desktop computer, a notebook, a palm computer, a cloud server and other computing devices. The computer equipment can carry out man-machine interaction with a user through a keyboard, a mouse, a remote controller, a touch panel or voice control equipment and the like.

The memory 201 includes at least one type of readable storage medium including a flash memory, a hard disk, a multimedia card, a card type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a Read Only Memory (ROM), an Electrically Erasable Programmable Read Only Memory (EEPROM), a Programmable Read Only Memory (PROM), a magnetic memory, a magnetic disk, an optical disk, etc. In some embodiments, the storage 201 may be an internal storage unit of the computer device 200, such as a hard disk or a memory of the computer device 200. In other embodiments, the memory 201 may also be an external storage device of the computer device 200, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), or the like, provided on the computer device 200. Of course, the memory 201 may also include both internal and external storage devices of the computer device 200. In this embodiment, the memory 201 is generally used for storing an operating system installed in the computer device 200 and various types of application software, such as computer readable instructions of an interface automation test method. Further, the memory 201 may also be used to temporarily store various types of data that have been output or are to be output.

The processor 202 may be a Central Processing Unit (CPU), controller, microcontroller, microprocessor, or other data Processing chip in some embodiments. The processor 202 is generally operative to control overall operation of the computer device 200. In this embodiment, the processor 202 is configured to execute computer readable instructions stored in the memory 201 or process data, for example, execute computer readable instructions of the interface automation test method.

The network interface 203 may comprise a wireless network interface or a wired network interface, and the network interface 203 is generally used for establishing communication connection between the computer device 200 and other electronic devices.

In the embodiment, the test case layer does not need to be modified, so that the reusability of the test strategy in the test case layer is effectively improved, and the test efficiency is improved. Meanwhile, different execution strategies in the API layer are called according to different test purposes, so that the simplicity of the whole test process is improved.

The present application further provides another embodiment, which is to provide a computer-readable storage medium storing computer-readable instructions executable by at least one processor to cause the at least one processor to perform the steps of the interface automation test method as described above.

Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solutions of the present application may be embodied in the form of a software product, which is stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (such as a mobile phone, a computer, a server, an air conditioner, or a network device) to execute the method according to the embodiments of the present application.

It is to be understood that the above-described embodiments are merely illustrative of some, but not restrictive, of the broad invention, and that the appended drawings illustrate preferred embodiments of the invention and do not limit the scope of the invention. This application is capable of embodiments in many different forms and is provided for the purpose of enabling a thorough understanding of the disclosure of the application. Although the present application has been described in detail with reference to the foregoing embodiments, it will be apparent to one skilled in the art that the present application may be practiced without modification or with equivalents of some of the features described in the foregoing embodiments. All equivalent structures made by using the contents of the specification and the drawings of the present application are directly or indirectly applied to other related technical fields and are within the protection scope of the present application.

Claims

1. An automatic interface testing method is characterized by comprising the following steps:

2. The method according to claim 1, wherein the API layer includes a first interface and a second interface, the first interface is packaged with different main execution policies, the second interface is packaged with different sub execution policies, the API layer is invoked with an execution policy corresponding to the test purpose to execute the interface request based on the test purpose, and the step of completing the interface test includes:

3. The method for automatically testing the interface according to claim 2, wherein the step of invoking the corresponding at least one secondary execution policy in the second interface through the primary execution policy to execute the interface request to obtain a final execution result comprises:

4. The method according to claim 2, wherein the first interface includes a first main execution policy, a second main execution policy, and a third main execution policy, the second interface includes a first sub execution policy, a second sub execution policy, and a third sub execution policy, based on the test purpose, the corresponding main execution policy in the first interface is called, and the interface request is executed by calling at least one corresponding sub execution policy in the second interface through the main execution policy, and the step of obtaining the final execution result includes:

identifying the test purpose;

5. The method for automatically testing the interface of claim 1, wherein the dto layers include different dto classes, the dto classes have different parameter generation strategies, and the step of determining the test purpose corresponding to the test instruction when receiving the test instruction sent by the user, calling a preset dto layer based on a test case layer, and generating the interface entry through the dto layer based on the test purpose includes:

calling a preset dto layer based on the test case layer;

6. The method for automated testing of interfaces of claim 5, wherein the parameter generation policy includes an assembly policy, and the step of generating the interface entry through the parameter generation policy includes:

7. The method of claim 5, wherein the parameter generation policy comprises a random generation policy, and the step of generating the interface entry parameters according to the parameter generation policy comprises:

8. An automated interface testing device, comprising:

9. A computer device comprising a memory having computer readable instructions stored therein and a processor that when executed implements the steps of the interface automation test method of any one of claims 1 to 7.

10. A computer-readable storage medium having computer-readable instructions stored thereon which, when executed by a processor, implement the steps of the interface automation test method of any one of claims 1 to 7.