WO2022095518A1

WO2022095518A1 - Automatic interface test method and apparatus, and computer device and storage medium

Info

Publication number: WO2022095518A1
Application number: PCT/CN2021/109474
Authority: WO
Inventors: 陈林
Original assignee: 深圳壹账通智能科技有限公司
Priority date: 2020-11-06
Filing date: 2021-07-30
Publication date: 2022-05-12
Also published as: CN112328486A

Abstract

The embodiments of the present application belong to the technical field of tests, and relate to an automatic interface test method. The method comprises: when a test instruction sent by a user is received, determining a test purpose corresponding to the test instruction, calling a preset dto layer on the basis of a test case layer, and generating an interface access parameter by means of the dto layer and on the basis of the test purpose; acquiring the interface access parameter on the basis of the test case layer, and generating an interface request on the basis of the interface access parameter, wherein the interface request carries the test purpose; and on the basis of the test purpose, calling an execution policy, which corresponds to the test purpose, in a preset API layer to execute the interface request, so as to complete an interface test. Further provided are an automatic interface test apparatus, and a computer device and a storage medium. An execution policy in an API layer can be stored in a blockchain. By means of the present application, the reusability of a test case is effectively improved, and the test efficiency is improved.

Description

Interface automated testing method, device, computer equipment and storage medium

This application claims the priority of the Chinese patent application filed on November 6, 2020 with the application number 202011232732.5 and the invention title is "Interface Automated Testing Method, Device, Computer Equipment and Storage Medium", the entire contents of which are by reference Incorporated in this application.

technical field

The present application relates to the technical field of testing, and in particular, to a method, device, computer equipment and storage medium for automated testing of interfaces.

Background technique

With the acceleration of the informatization process and the improvement of the computer level, all walks of life have used computers for efficient work and approval. To provide users with better services, these interfaces need to be tested before they are provided to users.

The inventor realizes that, at present, most of the common interface invocation test solutions directly write the interface parameters into the test strategy of the test case layer. When the interface parameters are changed, the parameter content in the corresponding test strategy needs to be modified. As the types of projects increase, this approach leads to low reusability of test strategies, and the defects of low test efficiency are gradually revealed.

SUMMARY OF THE INVENTION

The purpose of the embodiments of the present application is to provide an interface automated testing method, device, computer equipment and storage medium, which effectively improves the reusability of test cases and improves the test efficiency.

In order to solve the above-mentioned technical problems, the embodiment of the present application provides an interface automatic testing method, which adopts the following technical solutions:

An interface automated testing method, comprising the following steps:

When receiving the test command sent by the user, determine the test purpose corresponding to the test command, call the preset dto layer based on the test case layer, and generate interface input parameters through the dto layer based on the test purpose;

Obtain the interface input parameters based on the test case layer, and generate an interface request based on the interface input parameters, where the interface request carries the test purpose;

Based on the test purpose, the execution strategy corresponding to the test purpose in the preset API layer is invoked to execute the interface request to complete the interface test.

In order to solve the above-mentioned technical problems, the embodiment of the present application also provides an interface automatic testing device, which adopts the following technical solutions:

An interface automated testing device, comprising:

The parameter generation module is used to determine the test purpose corresponding to the test command when receiving the test command sent by the user, call the preset dto layer based on the test case layer, and generate an interface through the dto layer based on the test purpose input;

a request sending module, configured to obtain the interface input parameters based on the test case layer, and generate an interface request based on the interface input parameters, where the interface request carries the test purpose;

The request execution module is configured to, based on the test purpose, invoke the execution strategy corresponding to the test purpose in the preset API layer to execute the interface request to complete the interface test.

In order to solve the above-mentioned technical problems, the embodiment of the present application also provides a computer device, which adopts the following technical solutions:

A computer device, comprising a memory and a processor, wherein computer-readable instructions are stored in the memory, and when the processor executes the computer-readable instructions, the steps of the interface automated testing method described below are implemented:

In order to solve the above technical problems, the embodiments of the present application also provide a computer-readable storage medium, which adopts the following technical solutions:

A computer-readable storage medium, on which computer-readable instructions are stored, and when the computer-readable instructions are executed by a processor, the steps of the interface automated testing method described below are implemented:

Compared with the prior art, the embodiments of the present application mainly have the following beneficial effects:

The independent generation of interface input parameters is achieved through a separately set dto layer, and then the generated interface input parameters are transmitted to the test case layer, which avoids the need to modify the test strategy every time the parameters of the interface change, resulting in low test strategy reusability Case. When the parameters of the interface need to be modified, the application only needs to modify the generation method of the interface input parameters in the dto layer, and does not need to modify the test case layer, which effectively improves the reusability of the test strategy in the test case layer and improves the test efficiency. . Different from the prior art where each step of the execution process needs to call the corresponding API, the present application calls different execution strategies in the API layer in the execution process according to different testing purposes. It improves the simplicity and understandability of the overall test process, and realizes the rapid execution of the test process.

Description of drawings

In order to illustrate the solutions in the present application more clearly, the following will briefly introduce the accompanying drawings used in the description of the embodiments of the present application. For those of ordinary skill, other drawings can also be obtained from these drawings without any creative effort.

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

Fig. 2 is a flow chart of an embodiment of an interface automated testing method according to the present application;

3 is a schematic structural diagram of an embodiment of an interface automated testing device according to the present application;

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

Reference numerals: 200, computer equipment; 201, memory; 202, processor; 203, network interface; 300, interface automatic testing device; 301, parameter generation module; 302, request sending module;

Detailed ways

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the technical field of this application; the terms used herein in the specification of the application are for the purpose of describing specific embodiments only It is not intended to limit the application; the terms "comprising" and "having" and any variations thereof in the description and claims of this application and the above description of the drawings are intended to cover non-exclusive inclusion. The terms "first", "second" and the like in the description and claims of the present application or the above drawings are used to distinguish different objects, rather than to describe a specific 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 present application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor a separate or alternative embodiment that is mutually exclusive of other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

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

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

terminal devices

101 , 102 , and 103 , a network 104 and a server 105 . The network 104 is a medium used to provide a communication link between the

terminal devices

101 , 102 , 103 and the server 105 . The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

The user can use the

terminal devices

101, 102, 103 to interact with the server 105 through the network 104 to receive or send messages and the like. Various communication client applications may be installed on the

terminal devices

101 , 102 and 103 , such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, and the like.

The

terminal devices

101, 102, and 103 can be various electronic devices that have a display screen and support web browsing, including but not limited to smart phones, tablet computers, e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III, dynamic Picture Experts Compression Standard Audio Layer 3), MP4 (Moving Picture Experts Group Audio Layer IV, Moving Picture Experts Compression Standard Audio Layer 4) Players, Laptops and Desktops, etc.

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

terminal devices

101 , 102 , and 103 .

It should be noted that the automated interface testing method provided by the embodiments of the present application is generally performed by a server/terminal device, and accordingly, an automated interface testing apparatus is generally set in the server/terminal device.

It should be understood that the numbers of terminal devices, networks and servers in FIG. 1 are merely illustrative. There can be any number of terminal devices, networks and servers according to implementation needs.

Continuing to refer to FIG. 2 , a flowchart of an embodiment of an interface automated testing method according to the present application is shown. The interface automated testing method includes the following steps:

S1: When receiving the test instruction sent by the user, determine the test purpose corresponding to the test instruction, call the preset dto layer based on the test case layer, and generate interface input parameters 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, data transfer object) is generally used for data storage and transfer. This application combines the dto layer with the test case layer, and generates the interface input parameters and other information contained in the test strategy (that is, the case method) in the original test case layer through the dto layer, so that different test strategies can be reused. The dto layer can be combined with different test strategies in the test case layer to meet the needs of different test strategies to generate different types of parameters. During the application process, due to changes in requirements, changes in parameters may occur, which in turn lead to changes in the test strategy in the test case layer. For example, when a requirement is optimized, a required parameter needs to be added to an interface. If the interface has 50 parameters, the interface has at least 51 test strategies (ie case methods), including 1 entry and 50 test strategies. Parameter validation test strategy (ie case method). In this case, the parameter section of the 51 test strategies needs to be modified. After the interface input parameters are generated through the unified management of the dto layer of the present application, only the generation parameter method of the corresponding interface in the dto class needs to be modified, and the corresponding test cases and test methods do not need to be modified, which effectively improves the reuse of test strategies and computer testing. speed.

In this embodiment, the electronic device (for example, the server/terminal device shown in FIG. 1 ) on which the interface automated testing method runs may receive the test purpose through a wired connection or a wireless connection. It should be pointed out that the above wireless connection methods may include but are not limited to 3G/4G connection, WiFi connection, Bluetooth connection, WiMAX connection, Zigbee connection, UWB (ultra wideband) connection, and other wireless connection methods currently known or developed in the future .

Specifically, the dto layer includes different dto classes, and the dto classes have different parameter generation strategies. When receiving a test command sent by a user, the test purpose corresponding to the test command is determined, based on the test case The layer calls the preset dto layer, and the steps of generating interface input parameters through the dto layer based on the test purpose include:

When receiving the test instruction sent by the user, determine the test target user and the test purpose corresponding to the test instruction;

Call the preset dto layer based on the test case layer;

The corresponding dto class is selected based on the test target user, wherein the test target user and the dto class are in a one-to-one correspondence;

Determine the corresponding parameter generation strategy in the dto class based on the test purpose, and generate interface input parameters through the parameter generation strategy.

In this embodiment, the parameter generation strategy and the test purpose are in a one-to-one correspondence. The Dto layer includes different dto classes, and different test target users correspond to different dto classes, for example, a bank can correspond to one dto class. Different parameter generation strategies (ie dto generation methods) are included under the dto class, and different test purposes correspond to different dto generation methods. This setting is convenient for unified maintenance and management. When the project requirements change and the interface parameters change, you only need to find the corresponding dto class and maintain the dto generation method of the corresponding interface under this class. Different dto classes meet the needs of different test strategies to generate different types of parameters. For example, if a default dto class is set to generate parameters for normal scenarios, and the key and value are passed in, the dto class will be generated according to the received key and value. corresponding parameters. Specifically, the incoming key is the request serial number (applyNo), and the value is null (null), and further generates a test case for parameter validation where the request serial number parameter is null. For example: when the interface parameters need to be changed due to changes in actual requirements, the A interface has 1, 2, and 3 parameters, which become 2, 3, and 4 parameters, then only the method for generating the parameters of the A interface needs to be modified at the dto layer. The parameters are 2, 3, 4. In addition, the 1-parameter verification method of the A interface is removed from the test case layer, and a 4-parameter verification method can be added.

In addition, the parameter generation strategy includes an assembly strategy, and the step of generating interface input parameters through the parameter generation strategy includes:

When the corresponding parameter generation strategy in the dto class determined based on the test purpose is an assembly strategy, obtain preset interface parameters based on the test purpose, assemble the interface parameters through the dto layer, and generate an interface input Ref.

In this embodiment, when a fixed parameter needs to be tested, the computer receives and sets the interface parameter, calls the dto layer through the test case layer to assemble the interface parameter, and generates the interface input parameter. If you do not need fixed parameters, but in the case of random testing, you can directly generate the interface input parameters through the dto layer according to the requirements.

Correspondingly, the parameter generation strategy includes a random generation strategy, and the step of generating interface input parameters through the parameter generation strategy includes:

When the corresponding parameter generation strategy in the dto class determined based on the test purpose is a random generation strategy, the preset interface parameters are acquired based on the test purpose, and the preset interface parameters in the tool layer are called through the dto layer. Random number generator;

Obtain a timestamp, generate a random number according to the timestamp based on the random number generating tool, assemble the random number and preset interface parameters through the dto layer, and generate interface input parameters.

In this embodiment, the Dto layer invokes a random number generating tool in the tool layer (util layer) to generate random numbers, wherein the random number generating tool may use a pre-packaged random number generating function. The design of the Dto layer is convenient for decoupling from the test case layer, and the Dto layer is set separately to generate interface input parameters to meet the requirement that the parameters can be reused. At the same time, the dto layer can generate parameters randomly. For example, in loan application, it is generally required that the same user cannot apply for the same loan product repeatedly. Then, during the interface testing process, the user's identity information, such as mobile phone number, ID number, bank card number, etc., cannot be reused. Therefore, random numbers can be randomly generated through timestamps, so that parameters are not repeatedly generated, and various test cases can be executed repeatedly.

S2: Obtain the interface input parameters based on the test case layer, and generate an interface request based on the interface input parameters, where the interface request carries the test purpose.

In this embodiment, the test case layer, that is, the Case layer, is used to define a test strategy (case method), including two kinds of process test strategy and parameter verification test strategy. Because the interface input parameters are generated through the dto layer alone, the code template of the test strategy defined by the test case layer of the present application is more unified, clear and simple, and it is easy to quickly copy to other projects. The learning of relevant personnel and the maintenance cost of the test strategy are all lower. The test case layer sends corresponding interface requests to the API layer according to different test purposes, and the API layer is used to define the API to be called.

S3: Based on the test purpose, call the execution strategy corresponding to the test purpose in the preset API layer to execute the interface request, and complete 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, so as to facilitate the rapid progress of automated testing.

Specifically, the API layer includes a first interface and a second interface, the first interface is encapsulated with different main execution strategies, the second interface is encapsulated with different secondary execution strategies, the For the test purpose, call the execution strategy corresponding to the test purpose in the preset API layer to execute the interface request, and the steps to complete the interface test include:

Based on the test purpose, the main execution strategy corresponding to the first interface is invoked, and at least one sub-execution strategy corresponding to the second interface is invoked through the main execution strategy to execute the interface request to obtain the 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;

The assertion tool in the preset tool layer is invoked through the test case layer, the final execution result is asserted, and the assertion result is obtained to complete the interface test.

In this embodiment, different main execution policies are encapsulated in the first interface (FlowBaseAPI). Different secondary execution strategies are encapsulated in the second interface (BaseAPI), wherein there is a one-to-one and one-to-many correspondence between the primary execution strategy and the secondary execution strategy. Among them, when the main execution strategy invokes multiple sub-execution strategies, the sub-execution strategies execute corresponding operations in sequence, that is, after the execution of one sub-execution strategy is completed, the result is returned to the first interface, and when the continuation returned by the first interface is received When the instruction is executed, it continues to execute the next sub-execution strategy. Based on different testing purposes, different primary execution strategies in the first interface and different secondary execution strategies in the second interface are invoked. By setting two interfaces with a progressive relationship in the API layer, that is, calling at least one corresponding sub-execution strategy in the second interface through the main execution strategy in the first interface, the automated testing can be carried out in an orderly manner. The test case layer will only accept the final execution result (that is, the final processing result) returned by the first interface. The assertion tool is used to assert the final execution result. The commonly used assertion tool is JsonAssertion, which compares the final execution result with the pre-conceived result. Compare, and output consistency or inconsistency as the assertion result.

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

When the secondary execution strategy invoked by the main execution strategy is one, the final execution result is obtained;

When there are multiple secondary execution strategies invoked by the main execution strategy, the secondary execution strategies are executed in sequence, wherein each secondary execution strategy is executed, an intermediate execution result is obtained, and the intermediate execution result is returned to the The first interface, when receiving the continuing execution instruction returned by the first interface, executes the next sub-execution strategy until all sub-execution strategies called by the current main execution strategy are executed, and the final execution result is obtained.

In this embodiment, the test case layer only accepts the final execution result (ie, the final processing result) returned by the first interface. The second interface may perform multiple operations, and each step returns an intermediate execution result to the first interface, and the entire process is processed in the API layer. By setting the first interface and the second interface, the orderly execution of different interface tests is realized, and the intermediate execution result is returned to the first interface, which ensures that the entire operation process is in the API layer, and the first interface receives the intermediate execution result. After the execution result, the next sub-execution strategy is called, and the final execution result is not returned to the test case layer until the final execution result is received, which ensures that the test case layer does not need to care about the intermediate execution process, and only receives the final execution result. Test confusion.

Specifically, the first interface includes a first primary execution strategy, a second primary execution strategy and a third primary execution strategy, and the second interface includes a first secondary execution strategy, a second secondary execution strategy and a third secondary execution strategy , based on the test purpose, call the corresponding main execution strategy in the first interface, and invoke at least one sub-execution strategy corresponding to the second interface through the main execution strategy to execute the interface request, and obtain the final execution The resulting steps include:

identify the purpose of the test;

When the test purpose is parameter encryption, the first main execution strategy in the first interface is called, and the first sub-execution strategy in the second interface is invoked through the first main execution strategy to perform parameter encryption, and obtain final execution result;

When the test purpose is log comparison, the second primary execution strategy in the first interface is invoked, and the first secondary execution strategy and the second secondary execution strategy in the second interface are invoked through the second primary execution strategy, Execute parameter encryption and log comparison in turn to obtain intermediate execution results and final execution results;

When the test purpose is to compare notification logs, the third main execution strategy in the first interface is invoked, and the first sub-execution strategy and the second sub-execution strategy in the second interface are invoked through the third main execution strategy. The sub-execution strategy and the third sub-execution strategy execute parameter encryption, log comparison, and notification log comparison in sequence to obtain intermediate execution results and final execution results.

In this embodiment, when the test purpose is parameter encryption, the result returned by parameter encryption belongs to the final execution result. When the test purpose is 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. In the test purpose of notification log comparison, the results returned by parameter encryption operations and log comparison operations belong to the intermediate execution results. The result returned by the notification class log comparison operation is the final execution result. One or more sub-execution strategies are invoked by the main execution strategy, which realizes the control of the sub-execution strategy by the main execution strategy in the API layer, and ensures that the test process can be carried out in an orderly manner according to the control of the main execution strategy. The first interface (FlowBaseAPI) includes three different main execution strategies (ie methods): 1) getAPIResult method: interface request sending. 2) getCompareLogResult method: interface request sending, interface log comparison. 3) getCompareNoticeLogResult method: interface request sending, interface log comparison, notification interface log comparison. The second interface (BaseAPI) includes three different sub-execution strategies: 1) getAPIResult method: encrypt the message and send a post request. 2) compareLog method: compare the input parameters of the interface and the interface input of the log call related party, specifically: according to the keyword, extract the interface parameters of the request related party in the log, and compare them with the interface input parameters. The comparison content is based on the interface For the same key, compare the value. 3) compareNoticeLog method: compares the interface input parameters with the parameters in the notification class log.

It should be explained and understandable in this application that: the step of parameter encryption is executed in the test purpose of parameter encryption, log comparison and notification type log comparison. The steps of log comparison are performed in both log comparison and notification log comparison for test purposes. The steps of notification class log comparison are performed only when the test purpose is notification class log comparison.

Wherein, when the test purpose is log comparison, the steps of invoking the second main execution strategy, the first sub-execution strategy, and the second sub-execution strategy to perform the parameter encryption operation and the log comparison operation include:

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

Call the log extraction tool class in the preset tool layer through the first secondary execution strategy in the second interface, perform log query based on the preset request serial number, obtain the interface log, and use the interface log as the intermediate execution result , return to the first interface;

When receiving the continuation execution instruction sent by the first interface, obtain the parameters for calling the associated party interface in the interface log through the second secondary execution policy, and compare the parameters for calling the associated party interface with the interface Enter the parameters to obtain the log comparison result as the final execution result.

In this embodiment, the general application system will print a log for the convenience of checking the running situation and analyzing the cause of the problem when encountering a failure. The log records the program execution process, execution information, etc. After the application sends an interface request to the application system under test at the beginning of the test, it cannot directly obtain the request information sent by the system under test when it calls the associated party. It can only be obtained through the log information printed by the server under test. It is necessary to extract the log first to obtain the call association The request parameters of the party under test are compared with the interface input parameters generated by the dto layer to confirm that the request parameters in the request information of the related party under test are correct, wherein the request parameters in the request information of the related party under test are called Indicates the interface input parameters obtained through transparent transmission. Since the request serial number (applyNo) of the request from the system under test to the related party is unique, the request serial number (applyNo) can be used as the interface log print mark, and at the same time as the extraction log keyword, to accurately extract the interface log of the log file.

Further, the step of obtaining the parameters for calling the related party interface in the interface log, comparing the parameters for calling the related party interface and the interface input parameters, and obtaining the log comparison result includes:

Match the interface log with a preset regular expression, and obtain the parameters for calling the associated party interface in the interface log;

Compare whether the parameters of the calling associated party interface are the same as the keys of the interface input parameters;

When the keys are the same, compare whether the corresponding values are consistent and obtain the log comparison result.

In this embodiment, the regular expression uses a single character string to describe and match a series of character strings conforming to a certain syntax rule. A preset regular expression is used to match the log file of the related party, and the request parameters of the interface related party are obtained, wherein the related party may include the bank party or the platform party. The present application can encapsulate the parameter extraction method as a log extraction API, which is directly invoked during parameter extraction, specifically including: reading the log file printed by the system under test, following up the log print information of the system under test, and extracting the request parameters of the associated party.

The specific detailed execution process of the above-mentioned embodiment of the present application is as follows:

The step of executing the parameter encryption includes: 1) invoking the first main execution policy in the first interface (FlowBaseAPI) to send a post request to the second interface (BaseAPI), where the post request carries the interface entry. parameter; 2) parameter encryption is performed on the interface input parameter by the Http tool tool in the tool layer called by the first sub-execution policy in the second interface, and an encrypted message is generated; 3) based on the encrypted message, by The first secondary execution strategy in the second interface calls the Http tool tool to initiate an interface admission request, and generates a response result; 4) transmit the response result to the first interface; 5) the first interface transfers all The response result is transmitted to the test case layer; 6) The test case layer invokes an assertion tool to assert the response result, generates an assertion result, and completes the interface test. Due to security requirements, the application system generally encrypts the request information. Therefore, during the test process, the application also needs to encrypt the request parameters first, then initiate the request, and determine whether the response result meets the expectation through assertion. Wherein, the present application also includes comparing the encrypted message with the expected result to determine whether they are consistent, and if they are consistent, the parameter encryption test is correct.

The step of executing the log comparison includes: 1) invoking the second primary execution strategy in the first interface to send a log comparison request to the second interface; 2) through the second secondary execution strategy in the second interface Call the log extraction tool class (GetLogUnits) in the tool layer to perform log query to obtain the interface log; 3) obtain the parameters of the calling related party interface in the interface log, and compare the parameters of the calling related party interface with the interface Enter the parameters to obtain the log comparison result; 4) Return the log comparison result to the first interface; 5) The first interface transmits the log comparison result to the test case layer; 6) The test The use case layer invokes an assertion tool to assert the log comparison result, generates an assertion result, and completes the interface test. After sending an interface request to the application system under test, the request information sent when the system under test calls the related party cannot be directly obtained. It can only be obtained through the log information printed by the server under test. It is necessary to extract the log first to obtain the request parameters of the calling related party. Then, it is compared with the interface input parameters generated by the dto layer to confirm that the request parameters in the request information of the related party under test call are correct, wherein the request parameters in the request information of the related party under test call are obtained through transparent transmission interface input parameters.

The step of executing the notification class log comparison includes: 1) invoking the third main execution policy of the first interface to initiate a notification interface log comparison request to the second interface; 2) through the third interface in the second interface The log extraction tool class (GetLogUnits) in the sub-execution strategy calling tool layer traverses the notification log collection to obtain the corresponding notification log; 3) extracts and compares the notification interface parameters corresponding to different related parties in the notification log, and obtains Notification class log comparison result; 4) Return the notification class log comparison result to the first interface; 5) The first interface transmits the notification class log comparison result to the test case layer; 6) All The test case layer invokes 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 a notification needs to be sent, it is necessary to additionally compare the parameters in the notification log to confirm that the parameters in the notification are correct.

It should be noted that the tool classes in this application are all deployed in the tool layer (util), and the tool layer (util) includes different tool classes, such as Http tool class (Http tool), log extraction tool class (GetLogUnits), Assertion tool class (JsonAssertion), parameter type conversion tool class, random data generation tool class, such as random generation of mobile phone numbers, bank card numbers, ID numbers, etc., log platform reading tool class, configuration file reading tool class, and request sending tools etc.

In addition, this application is also provided with a Config layer. The Config layer is used to define the configuration. The Config layer includes environment information (Config-properties) and constant parameters. If there is a need for subsequent changes, the maintenance configuration information can be uniformly modified in the Config layer.

Concrete: The environment information is used in 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 changes, it only needs to be uniformly modified in the Config configuration file, without the need to modify the test. Content in the use case layer. Constant parameters refer to: for example, some random numbers in the generation method of the dto layer, which are generated by the tool class of the tool layer. Some parameters are constants, and multiple interfaces and multiple dto methods may need to be used. They can be written in the Config configuration file. If the constant value needs to be changed later, there is no need to modify multiple dto methods, and only need to be in the Config configuration file. unified modification.

The embodiments of the present application can be applied in the field of artificial intelligence technology to test data interfaces related to artificial intelligence such as semantic analysis, image recognition, and biometric identification.

It should be emphasized that, in order to further ensure the privacy and security of the execution strategy in the above API layer, the execution strategy in the above API layer can also be stored in a node of a blockchain.

The blockchain referred to in this application is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. Blockchain, essentially a decentralized database, is a series of data blocks associated with cryptographic methods. Each data block contains a batch of network transaction information to verify its Validity of information (anti-counterfeiting) and generation of the next block. The blockchain can include the underlying platform of the blockchain, the platform product service layer, and the application service layer.

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.

Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing the relevant hardware through computer-readable instructions, and the computer-readable instructions can be stored in a computer-readable storage medium. , when the computer-readable instructions are executed, the processes of the above-mentioned method embodiments may be included. Wherein, the aforementioned storage medium may be a non-volatile storage medium such as a magnetic disk, an optical disk, a read-only memory (Read-Only Memory, ROM), or a random access memory (Random Access Memory, RAM) or the like.

It should be understood that although the various steps in the flowchart of the accompanying drawings are sequentially shown in the order indicated by the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless explicitly stated herein, the execution of these steps is not strictly limited to the order and may be performed in other orders. Moreover, at least a part of the steps in the flowchart of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but may be executed at different times, and the execution sequence is also It does not have to be performed sequentially, but may be performed alternately or alternately with other steps or at least a portion of sub-steps or stages of other steps.

Further referring to FIG. 3 , as an implementation of the method shown in FIG. 2 above, the present application provides an embodiment of an interface automated testing device, and the device embodiment corresponds to the method embodiment shown in FIG. 2 . Can be applied to various electronic devices.

As shown in FIG. 3 , the interface automated testing apparatus 300 described in this embodiment includes: a parameter generation module 301 , a request sending module 302 and a request execution module 303 . Wherein: the parameter generation module 301 is used to determine the test purpose corresponding to the test command when receiving the test command sent by the user, call the preset dto layer based on the test case layer, and pass the dto layer based on the test purpose layer generates interface input parameters; the request sending module 302 is configured to obtain the interface input parameters based on the test case layer, and generate an interface request based on the interface input parameters, and the interface request carries the test purpose; request execution module 303: Based on the test purpose, invoking an execution strategy corresponding to the test purpose in the preset API layer to execute the interface request to complete the interface test.

In this embodiment, the independent generation of interface input parameters is achieved through a separately set dto layer, and then the generated interface input parameters are transmitted to the test case layer, which avoids the need to modify the test strategy correspondingly each time the parameters of the interface are changed, resulting in Test the case where the reusability of the strategy is low. When the parameters of the interface need to be modified, the application only needs to modify the generation method of the interface input parameters in the dto layer, and does not need to modify the test case layer, which effectively improves the reusability of the test strategy in the test case layer and improves the test efficiency. . Different from the prior art where each step of the execution process needs to call the corresponding API, the present application calls different execution strategies in the API layer in the execution process according to different testing purposes. It improves the simplicity and understandability of the overall test process, and realizes the rapid execution of the test process.

Described dto layer includes different dto classes, has different parameter generation strategies in described dto class, described parameter generation module 301 comprises to determine submodule, call submodule, select submodule and generate submodule. The determination submodule is used to determine the test target user and the test purpose corresponding to the test instruction when receiving the test instruction sent by the user; the calling submodule is used for calling the preset dto layer based on the test case layer; the selection submodule is used for The corresponding dto class is selected based on the test target user, wherein the test target user and the dto class are in a one-to-one correspondence; the generation sub-module is used to determine the corresponding parameter generation in the dto class based on the test purpose Strategy, the interface input parameters are generated through the parameter generation strategy.

The parameter generation strategy includes an assembly strategy. In some optional implementations of this embodiment, the above generation sub-module is further used for: when the corresponding parameter generation strategy in the dto class determined based on the test purpose is assembly During the strategy, the preset interface parameters are obtained based on the test purpose, and the interface parameters are assembled through the dto layer to generate interface input parameters.

The parameter generation strategy includes a random generation strategy, and the generation submodule includes a calling unit and a generating unit. The calling unit is configured to obtain preset interface parameters based on the test purpose when the corresponding parameter generation strategy in the dto class determined based on the test purpose is a random generation strategy, and call the preset interface parameters through the dto layer. A random number generation tool in the tool layer; the generation unit is used to obtain a timestamp, generate a random number according to the timestamp based on the random number generation tool, assemble the random number and preset interface parameters through the dto layer, and generate Interface input parameters.

The request execution module 303 includes an execution sub-module, a return sub-module, and an assertion sub-module. The execution sub-module is used to invoke the corresponding main execution strategy in the first interface based on the test purpose, and to invoke the main execution strategy through the main execution strategy. At least one sub-execution strategy corresponding to the second interface executes the interface request and obtains the final execution result; the return submodule is used to return the final execution result to the first interface, and send the final execution result to the first interface through the first interface. The final execution result is returned to the test case layer; the assertion submodule is used to invoke the pre-set assertion tool in the tool layer through the test case layer, assert the final execution result, and obtain the assertion result to complete the interface test.

In some optional implementations of this embodiment, the execution sub-module is further configured to obtain a final execution result when the secondary execution strategy invoked by the primary execution strategy is one, and when the primary execution strategy invokes the secondary execution strategy When there are multiple secondary execution strategies, execute the secondary execution strategies in sequence, wherein, each time a secondary execution strategy is executed, an intermediate execution result is obtained, and the intermediate execution result is returned to the first interface. When the continuous execution instruction returned by the first interface is executed, the next sub-execution strategy is executed until all sub-execution strategies called by the current main execution strategy are executed, and the final execution result is obtained.

The first interface includes a first primary execution strategy, a second primary execution strategy and a third primary execution strategy, the second interface includes a first secondary execution strategy, a second secondary execution strategy and a third secondary execution strategy, and the executor The module also includes an identification unit, an encryption unit, a log comparison unit and a notification log comparison unit. The identification unit is used to identify the test purpose; the encryption unit is used to call the first main execution strategy in the first interface when the test purpose is parameter encryption, and call the first main execution strategy through the first main execution strategy. The execution parameters of the first secondary execution strategy in the second interface are encrypted to obtain the final execution result; the log comparison unit is used for calling the second main execution strategy in the first interface when the test purpose is log comparison, and through the The second main execution strategy invokes the first sub-execution strategy and the second sub-execution strategy in the second interface, respectively executes parameter encryption and log comparison in sequence, and obtains the intermediate execution result and the final execution result; the notification type log comparison unit is used when all the The purpose of the test is to call the third main execution strategy in the first interface, and call the first sub-execution strategy and the second sub-execution strategy in the second interface through the third main execution strategy The strategy and the third sub-execution strategy execute parameter encryption, log comparison, and notification log comparison in sequence to obtain intermediate execution results and final execution results.

The notification type log comparison unit includes a calling subunit, a query subunit and a comparison subunit. The calling subunit is used to call the 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 used to pass the first secondary execution strategy in the second interface Invoke the log extraction tool class in the preset tool layer, perform log query based on the preset request serial number, obtain the interface log, use the interface log as an intermediate execution result, and return to the first interface; compare the subunit When receiving the continuation execution instruction sent by the first interface, obtain the parameters of calling the related party interface in the interface log through the second sub-execution strategy, and compare the parameters of calling the related party interface with all the parameters. Input parameters of the above interface, and obtain the log comparison result as the final execution result.

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

To solve the above technical problems, the embodiments of the present application also provide computer equipment. Please refer to FIG. 4 for details. FIG. 4 is a block diagram of a basic structure of a computer device according to this embodiment.

The computer device 200 includes a memory 201 , a processor 202 , and a network interface 203 that communicate with each other through a system bus. It should be noted that only the computer device 200 with components 201-203 is shown in the figure, but it should be understood that implementation of all shown components is not required, and more or less components may be implemented instead. Among them, those skilled in the art can understand that the computer device here is a device that can automatically perform numerical calculation and/or information processing according to pre-set or stored instructions, and its hardware includes but is not limited to microprocessors, special-purpose Integrated circuit (Application Specific Integrated Circuit, ASIC), programmable gate array (Field-Programmable Gate Array, FPGA), digital processor (Digital Signal Processor, DSP), embedded equipment, etc.

The computer equipment may be a desktop computer, a notebook computer, a palmtop computer, a cloud server and other computing equipment. The computer device can perform human-computer interaction with the user through a keyboard, a mouse, a remote control, a touch pad or a voice control device.

The memory 201 includes at least one type of readable storage medium, and the readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (for example, SD or DX memory, etc.), random access memory (RAM), static Random Access Memory (SRAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), Programmable Read Only Memory (PROM), Magnetic Memory, Magnetic Disk, Optical Disk, etc. The computer-readable storage medium may be non-volatile or volatile. In some embodiments, the memory 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 memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, flash memory card (Flash Card), etc. Of course, the memory 201 may also include both the internal storage unit of the computer device 200 and its external storage device. In this embodiment, the memory 201 is generally used to store the operating system and various application software installed in the computer device 200 , such as computer-readable instructions of an interface automated testing method, and the like. In addition, the memory 201 can also be used to temporarily store various types of data that have been output or will be output.

In some embodiments, the processor 202 may be a central processing unit (Central Processing Unit, CPU), a controller, a microcontroller, a microprocessor, or other data processing chips. The processor 202 is typically used to control the 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, computer-readable instructions for executing the interface automated testing method.

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

In this embodiment, there is no need to modify the test case layer, which effectively improves the reusability of the test strategy in the test case layer and improves the test efficiency. At the same time, according to different test purposes, different execution strategies in the API layer are invoked, which improves the simplicity of the overall test process.

The present application also provides another embodiment, that is, to provide a computer-readable storage medium, where the computer-readable storage medium stores computer-readable instructions, and the computer-readable instructions can be executed by at least one processor to The at least one processor is caused to perform the steps of the interface automation testing method as described above.

From the description of the above embodiments, those skilled in the art can clearly understand that the method of the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is better implementation. Based on this understanding, the technical solution of the present application can be embodied in the form of a software product in essence or in a part that contributes to the prior art, and the computer software product is stored in a storage medium (such as ROM/RAM, magnetic disk, CD-ROM), including several instructions to make a terminal device (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) execute the methods described in the various embodiments of this application.

Obviously, the above-described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. The accompanying drawings show the preferred embodiments of the present application, but do not limit the scope of the patent of the present application. This application may be embodied in many different forms, rather these embodiments are provided so that a thorough and complete understanding of the disclosure of this application is provided. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or perform equivalent replacements for some of the technical features. . Any equivalent structure made by using the contents of the description and drawings of the present application, which is directly or indirectly used in other related technical fields, is also within the scope of protection of the patent of the present application.

Claims

An interface automated testing method, comprising the following steps:

When receiving the test command sent by the user, determine the test purpose corresponding to the test command, call the preset dto layer based on the test case layer, and generate interface input parameters through the dto layer based on the test purpose;

Obtain the interface input parameters based on the test case layer, and generate an interface request based on the interface input parameters, where the interface request carries the test purpose;

Based on the test purpose, the execution strategy corresponding to the test purpose in the preset API layer is invoked to execute the interface request to complete the interface test.
The interface automated testing method according to claim 1, wherein the API layer includes a first interface and a second interface, the first interface is encapsulated with different main execution strategies, and the second interface is encapsulated with a For different sub-execution strategies, based on the test purpose, calling the execution strategy corresponding to the test purpose in the preset API layer to execute the interface request, and the steps of completing the interface test include:

Based on the test purpose, the main execution strategy corresponding to the first interface is invoked, and at least one sub-execution strategy corresponding to the second interface is invoked through the main execution strategy to execute the interface request to obtain the 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;

The assertion tool in the preset tool layer is invoked through the test case layer, the final execution result is asserted, and the assertion result is obtained to complete the interface test.
The interface automated testing method according to claim 2, wherein the step of invoking at least one corresponding sub-execution policy in the second interface to execute the interface request through the main execution policy, and obtaining a final execution result comprises:

When the secondary execution strategy invoked by the main execution strategy is one, the final execution result is obtained;

When there are multiple secondary execution strategies invoked by the main execution strategy, the secondary execution strategies are executed in sequence, wherein each secondary execution strategy is executed, an intermediate execution result is obtained, and the intermediate execution result is returned to the The first interface, when receiving the continuing execution instruction returned by the first interface, executes the next sub-execution strategy until all sub-execution strategies invoked by the current main execution strategy are executed, and the final execution result is obtained.
The interface automated testing method according to claim 2, wherein the first interface includes a first main execution strategy, a second main execution strategy and a third main execution strategy, and the second interface includes a first secondary execution strategy, The second sub-execution strategy and the third sub-execution strategy, based on the test purpose, call the corresponding main execution strategy in the first interface, and invoke at least one sub-execution strategy corresponding to the second interface through the main execution strategy The execution strategy executes the interface request, and the step of obtaining the final execution result includes:

identify the purpose of the test;

When the test purpose is parameter encryption, the first main execution strategy in the first interface is called, and the first sub-execution strategy in the second interface is invoked through the first main execution strategy to perform parameter encryption, and obtain final execution result;

When the test purpose is log comparison, the second primary execution strategy in the first interface is invoked, and the first secondary execution strategy and the second secondary execution strategy in the second interface are invoked through the second primary execution strategy, Execute parameter encryption and log comparison in turn to obtain intermediate execution results and final execution results;

When the test purpose is to compare notification logs, the third main execution strategy in the first interface is invoked, and the first sub-execution strategy and the second sub-execution strategy in the second interface are invoked through the third main execution strategy. The sub-execution strategy and the third sub-execution strategy execute parameter encryption, log comparison, and notification log comparison in sequence to obtain intermediate execution results and final execution results.
The interface automatic testing method according to claim 1, wherein the dto layer includes different dto classes, and the dto classes have different parameter generation strategies, and when receiving a test instruction sent by a user, determine the The test purpose corresponding to the test instruction, the preset dto layer is called based on the test case layer, and the steps of generating interface input parameters through the dto layer based on the test purpose include:

When receiving the test instruction sent by the user, determine the test target user and the test purpose corresponding to the test instruction;

Call the preset dto layer based on the test case layer;

The corresponding dto class is selected based on the test target user, wherein the test target user and the dto class are in a one-to-one correspondence;

Determine the corresponding parameter generation strategy in the dto class based on the test purpose, and generate interface input parameters through the parameter generation strategy.
The interface automated testing method according to claim 5, wherein the parameter generation strategy includes an assembly strategy, and the step of generating the interface input parameters through the parameter generation strategy includes:

When the corresponding parameter generation strategy in the dto class determined based on the test purpose is an assembly strategy, obtain preset interface parameters based on the test purpose, assemble the interface parameters through the dto layer, and generate an interface input Ref.
The interface automated testing method according to claim 5, wherein the parameter generation strategy comprises a random generation strategy, and the step of generating the interface input parameters through the parameter generation strategy comprises:

When the corresponding parameter generation strategy in the dto class determined based on the test purpose is a random generation strategy, the preset interface parameters are acquired based on the test purpose, and the preset interface parameters in the tool layer are called through the dto layer. Random number generator;

Obtain a timestamp, generate a random number according to the timestamp based on the random number generating tool, assemble the random number and preset interface parameters through the dto layer, and generate interface input parameters.
An interface automated testing device, comprising:

The parameter generation module is used to determine the test purpose corresponding to the test command when receiving the test command sent by the user, call the preset dto layer based on the test case layer, and generate an interface through the dto layer based on the test purpose input;

a request sending module, configured to obtain the interface input parameters based on the test case layer, and generate an interface request based on the interface input parameters, where the interface request carries the test purpose;

The request execution module is configured to, based on the test purpose, invoke the execution strategy corresponding to the test purpose in the preset API layer to execute the interface request to complete the interface test.
A computer device, comprising a memory and a processor, wherein computer-readable instructions are stored in the memory, and when the processor executes the computer-readable instructions, the steps of the interface automated testing method described below are implemented:

When receiving the test command sent by the user, determine the test purpose corresponding to the test command, call the preset dto layer based on the test case layer, and generate interface input parameters through the dto layer based on the test purpose;

Obtain the interface input parameters based on the test case layer, and generate an interface request based on the interface input parameters, where the interface request carries the test purpose;

Based on the test purpose, the execution strategy corresponding to the test purpose in the preset API layer is invoked to execute the interface request to complete the interface test.
The computer device according to claim 9, wherein the API layer includes a first interface and a second interface, the first interface is encapsulated with different main execution policies, and the second interface is encapsulated with different main execution policies The secondary execution strategy, based on the test purpose, invokes the execution strategy corresponding to the test purpose in the preset API layer to execute the interface request, and the steps of completing the interface test include:

Based on the test purpose, the main execution strategy corresponding to the first interface is invoked, and at least one sub-execution strategy corresponding to the second interface is invoked through the main execution strategy to execute the interface request to obtain the 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;

The assertion tool in the preset tool layer is invoked through the test case layer, the final execution result is asserted, and the assertion result is obtained to complete the interface test.
The computer device according to claim 10, wherein the step of invoking at least one corresponding secondary execution policy in the second interface to execute the interface request through the primary execution policy, and obtaining a final execution result comprises:

When the secondary execution strategy invoked by the main execution strategy is one, the final execution result is obtained;

When there are multiple secondary execution strategies invoked by the main execution strategy, the secondary execution strategies are executed in sequence, wherein each secondary execution strategy is executed, an intermediate execution result is obtained, and the intermediate execution result is returned to the The first interface, when receiving the continuing execution instruction returned by the first interface, executes the next sub-execution strategy until all sub-execution strategies invoked by the current main execution strategy are executed, and the final execution result is obtained.
The computer device of claim 10, wherein the first interface includes a first primary execution strategy, a second primary execution strategy, and a third primary execution strategy, and the second interface includes a first secondary execution strategy, a second primary execution strategy, and a second primary execution strategy. The secondary execution strategy and the third secondary execution strategy, based on the test purpose, call the corresponding primary execution strategy in the first interface, and invoke at least one secondary execution strategy corresponding to the second interface through the primary execution strategy Execute the interface request, and the steps of obtaining the final execution result include:

identify the purpose of the test;

When the test purpose is parameter encryption, the first main execution strategy in the first interface is called, and the first sub-execution strategy in the second interface is invoked through the first main execution strategy to perform parameter encryption, and obtain final execution result;

When the test purpose is log comparison, the second primary execution strategy in the first interface is invoked, and the first secondary execution strategy and the second secondary execution strategy in the second interface are invoked through the second primary execution strategy, Execute parameter encryption and log comparison in turn to obtain intermediate execution results and final execution results;

When the test purpose is to compare notification logs, the third main execution strategy in the first interface is invoked, and the first sub-execution strategy and the second sub-execution strategy in the second interface are invoked through the third main execution strategy. The sub-execution strategy and the third sub-execution strategy execute parameter encryption, log comparison, and notification log comparison in sequence to obtain intermediate execution results and final execution results.
The computer device according to claim 9, wherein the dto layer includes different dto classes, and the dto classes have different parameter generation strategies, and the test is determined when a test instruction sent by a user is received. The test purpose corresponding to the instruction, the preset dto layer is called based on the test case layer, and the steps of generating interface input parameters through the dto layer based on the test purpose include:

When receiving the test instruction sent by the user, determine the test target user and the test purpose corresponding to the test instruction;

Call the preset dto layer based on the test case layer;

The corresponding dto class is selected based on the test target user, wherein the test target user and the dto class are in a one-to-one correspondence;

Determine the corresponding parameter generation strategy in the dto class based on the test purpose, and generate interface input parameters through the parameter generation strategy.
The computer device according to claim 13, wherein the parameter generation strategy comprises an assembly strategy, and the step of generating interface input parameters through the parameter generation strategy comprises:

When the corresponding parameter generation strategy in the dto class determined based on the test purpose is an assembly strategy, obtain preset interface parameters based on the test purpose, assemble the interface parameters through the dto layer, and generate an interface input Ref.
The computer device according to claim 13, wherein the parameter generation strategy comprises a random generation strategy, and the step of generating the interface input parameters through the parameter generation strategy comprises:

When the corresponding parameter generation strategy in the dto class determined based on the test purpose is a random generation strategy, the preset interface parameters are acquired based on the test purpose, and the preset interface parameters in the tool layer are called through the dto layer. Random number generator;

Obtain a timestamp, generate a random number according to the timestamp based on the random number generating tool, assemble the random number and preset interface parameters through the dto layer, and generate interface input parameters.
A computer-readable storage medium, on which computer-readable instructions are stored, and when the computer-readable instructions are executed by a processor, the steps of the interface automated testing method described below are implemented:

When receiving the test command sent by the user, determine the test purpose corresponding to the test command, call the preset dto layer based on the test case layer, and generate interface input parameters through the dto layer based on the test purpose;

Obtain the interface input parameter based on the test case layer, and generate an interface request based on the interface input parameter, and the interface request carries the test purpose;

Based on the test purpose, the execution strategy corresponding to the test purpose in the preset API layer is invoked to execute the interface request to complete the interface test.
The computer-readable storage medium according to claim 16, wherein the API layer includes a first interface and a second interface, the first interface is encapsulated with different main execution policies, and the second interface is encapsulated in There are different sub-execution strategies. Based on the test purpose, calling the execution strategy corresponding to the test purpose in the preset API layer to execute the interface request, and the steps of completing the interface test include:

Based on the test purpose, the main execution strategy corresponding to the first interface is invoked, and at least one sub-execution strategy corresponding to the second interface is invoked through the main execution strategy to execute the interface request to obtain the 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;

The assertion tool in the preset tool layer is invoked through the test case layer, the final execution result is asserted, and the assertion result is obtained to complete the interface test.
The computer-readable storage medium according to claim 17, wherein the step of invoking at least one corresponding secondary execution policy in the second interface to execute the interface request through the primary execution policy, and obtaining a final execution result comprises the following steps: :

When the secondary execution strategy invoked by the main execution strategy is one, the final execution result is obtained;

When there are multiple secondary execution strategies invoked by the main execution strategy, the secondary execution strategies are executed in sequence, wherein each secondary execution strategy is executed, an intermediate execution result is obtained, and the intermediate execution result is returned to the The first interface, when receiving the continuing execution instruction returned by the first interface, executes the next sub-execution strategy until all sub-execution strategies invoked by the current main execution strategy are executed, and the final execution result is obtained.
18. The computer-readable storage medium of claim 17, wherein the first interface includes a first primary execution policy, a second primary execution policy, and a third primary execution policy, and wherein the second interface includes a first secondary execution policy The execution strategy, the second sub-execution strategy and the third sub-execution strategy, based on the test purpose, call the corresponding main execution strategy in the first interface, and call the corresponding main execution strategy in the second interface through the main execution strategy At least one sub-execution strategy executes the interface request, and the step of obtaining the final execution result includes:

identify the purpose of the test;

When the test purpose is parameter encryption, the first main execution strategy in the first interface is called, and the first sub-execution strategy in the second interface is invoked through the first main execution strategy to perform parameter encryption, and obtain final execution result;

When the test purpose is log comparison, the second primary execution strategy in the first interface is invoked, and the first secondary execution strategy and the second secondary execution strategy in the second interface are invoked through the second primary execution strategy, Execute parameter encryption and log comparison in turn to obtain intermediate execution results and final execution results;

When the test purpose is to compare notification logs, the third main execution strategy in the first interface is invoked, and the first sub-execution strategy and the second sub-execution strategy in the second interface are invoked through the third main execution strategy. The sub-execution strategy and the third sub-execution strategy execute parameter encryption, log comparison, and notification log comparison in sequence to obtain intermediate execution results and final execution results.
The computer-readable storage medium according to claim 16, wherein the dto layer includes different dto classes, and the dto classes have different parameter generation strategies, and when receiving a test instruction sent by a user, determining The test purpose corresponding to the test instruction, the preset dto layer is called based on the test case layer, and the steps of generating interface input parameters through the dto layer based on the test purpose include:

When receiving the test instruction sent by the user, determine the test target user and the test purpose corresponding to the test instruction;

Call the preset dto layer based on the test case layer;

The corresponding dto class is selected based on the test target user, wherein the test target user and the dto class are in a one-to-one correspondence;

Determine the corresponding parameter generation strategy in the dto class based on the test purpose, and generate interface input parameters through the parameter generation strategy.