1. A method for testing an interface, comprising:

acquiring a test case of an interface to be tested, wherein the interface to be tested comprises a plurality of services;

sending a tracking protocol packet containing a tracking mark bit to the interface to be tested, and executing a test case of the interface to be tested;

when the test case is executed, if a protocol packet received by a service in the interface to be tested is the tracking protocol packet, adding the tracking mark bit to the protocol packet sent by the service, and marking the protocol packet sent by the service as a tracking protocol packet;

and if the test case is executed, acquiring protocol data in all the tracking protocol packets received by the service and the tracking protocol packets sent out, and obtaining a test result of the interface to be tested according to the protocol data and the expected protocol data of the interface to be tested.

2. The method for testing an interface of claim 1, wherein the trace protocol packet sent by the service comprises: and the service returns a protocol packet to a downstream service, the protocol packet sent by the service to an upstream service and the protocol packet broadcasted by the service.

3. The method for testing an interface of claim 1, wherein before the sending the trace protocol packet including the trace flag bit to the interface under test and executing the test case of the interface under test, the method further comprises:

if the preset interface parameters exist, calling a universal gateway interface, and initializing the required service data in the test case according to the preset interface parameters;

and if the preset interface parameters do not exist, initializing the service data required in the test case according to preset database parameters and/or cache parameters.

4. The method for testing the interface according to claim 3, wherein initializing the service data required in the test case according to the preset database parameter and/or cache parameter comprises:

connecting a corresponding database according to preset database parameters, wherein the database parameters comprise a database address, port configuration information and authorization information of the database;

initializing the service data required in the test case by executing the initial database operation configured in advance in the database;

initializing a cache in the test case according to preset cache parameters, wherein the cache parameters comprise addresses and port configuration information of the cache;

and initializing the service data required in the test case by executing the initial cache operation pre-configured in the cache.

5. The method for testing an interface of claim 3, wherein after initializing the service data required in the test case, the method further comprises:

judging whether a service server for executing the test case opens a virtual service for configuring a virtual protocol;

if the service server starts the virtual service, acquiring pre-configured virtual data as service data required by the test through the virtual protocol;

and if the virtual service is not started by the service server, acquiring real data as service data required by the test through a third-party service protocol.

6. The method for testing an interface of claim 3, further comprising:

and before initializing the service data required in the test case, backing up the database and the cache to obtain backup environment data.

7. The method for testing an interface of claim 6, further comprising:

and after the test case is executed, restoring the data in the database and the cache according to the backup environment data.

8. The method for testing the interface according to claim 1, wherein the step of, if the test case is executed completely, comprising:

if a service server for executing the test case detects a pre-configured test ending protocol, the test case is executed;

and if the service server does not detect the test ending protocol, when the test duration is greater than or equal to the test duration threshold, the test case is executed.

9. The method for testing an interface according to claim 1, wherein the obtaining a test result of the interface to be tested according to the protocol data and the expected protocol data of the interface to be tested comprises:

judging whether all expected generated protocols are complete and whether the protocol data conform to the expected protocol data of the interface to be tested;

and if the expected generated protocol is incomplete or the protocol data does not accord with the expected protocol data of the interface to be tested, generating test result alarm information.

10. The method for testing an interface of claim 1, further comprising:

if the test case is executed, obtaining key data of a database and key data of a cache, and judging whether the key data of the database and the key data of the cache accord with expected data;

and if the database key data and the cache key data do not accord with the expected data, generating test result alarm information.

11. An apparatus for testing an interface, comprising:

the device comprises a test case acquisition module, a test case analysis module and a test case analysis module, wherein the test case acquisition module is used for acquiring a test case of an interface to be tested, and the interface to be tested comprises a plurality of services;

the trace protocol packet marking module is used for sending a trace protocol packet containing a trace marking bit to the interface to be tested and executing a test case of the interface to be tested;

a trace flag bit adding module, configured to, when the test case is executed, add the trace flag bit to a protocol packet sent by a service in the interface to be tested if the protocol packet received by the service is the trace protocol packet, and mark the protocol packet sent by the service as a trace protocol packet;

and the test result determining module is used for acquiring protocol data in all the tracking protocol packets received by the service and the tracking protocol packets sent out if the test case is executed, and obtaining the test result of the interface to be tested according to the protocol data and the expected protocol data of the interface to be tested.

12. An electronic device, comprising:

a processor; and

memory for storing one or more programs which, when executed by the processor, cause the processor to implement a method of testing an interface as claimed in any one of claims 1 to 10.

13. A computer-readable medium, on which a computer program is stored, which program, when being executed by a processor, carries out a method of testing an interface according to any one of claims 1 to 10.

Background

Interface testing is a common functional testing mode and is one of important means for ensuring system stability and continuous integration by testing personnel.

The existing interface test tools and test methods can only be used as auxiliary tools for testing, automation in the true sense is difficult to meet, the obtained interface test results are too simple to check, and the test results are often inaccurate for interfaces of complex systems which may involve a plurality of upstream and downstream service calls.

In view of this, there is a need in the art for a method for testing an interface, which can improve the accuracy of the test result of the interface.

It is to be noted that the information disclosed in the above background section is only for enhancement of understanding of the background of the present disclosure, and thus may include information that does not constitute prior art known to those of ordinary skill in the art.

Disclosure of Invention

The present disclosure is directed to a method for testing an interface, an apparatus for testing an interface, an electronic device, and a computer-readable medium, so as to improve the accuracy of an interface test result at least to a certain extent.

According to a first aspect of the present disclosure, there is provided a method for testing an interface, including:

acquiring a test case of an interface to be tested, wherein the interface to be tested comprises a plurality of services;

sending a tracking protocol packet containing a tracking mark bit to the interface to be tested, and executing a test case of the interface to be tested;

when the test case is executed, if a protocol packet received by a service in the interface to be tested is the tracking protocol packet, adding the tracking mark bit to the protocol packet sent by the service, and marking the protocol packet sent by the service as a tracking protocol packet;

and if the test case is executed, acquiring protocol data in all the tracking protocol packets received by the service and the tracking protocol packets sent out, and obtaining a test result of the interface to be tested according to the protocol data and the expected protocol data of the interface to be tested.

In an exemplary embodiment of the disclosure, the tracking protocol packet sent out by the service includes: and the service returns a protocol packet to a downstream service, the protocol packet sent by the service to an upstream service and the protocol packet broadcasted by the service.

In an exemplary embodiment of the present disclosure, before the sending a trace protocol packet including a trace flag bit to the interface to be tested and executing a test case of the interface to be tested, the method further includes:

if the preset interface parameters exist, calling a universal gateway interface, and initializing the required service data in the test case according to the preset interface parameters;

and if the preset interface parameters do not exist, initializing the service data required in the test case according to preset database parameters and/or cache parameters.

In an exemplary embodiment of the present disclosure, initializing the service data required in the test case according to a preset database parameter and/or a preset cache parameter includes:

connecting a corresponding database according to preset database parameters, wherein the database parameters comprise a database address, port configuration information and authorization information of the database;

initializing the service data required in the test case by executing the initial database operation configured in advance in the database;

initializing a cache in the test case according to preset cache parameters, wherein the cache parameters comprise addresses and port configuration information of the cache;

and initializing the service data required in the test case by executing the initial cache operation pre-configured in the cache.

In an exemplary embodiment of the present disclosure, after initializing the service data required in the test case, the method further includes:

judging whether a service server for executing the test case opens a virtual service for configuring a virtual protocol;

if the service server starts the virtual service, acquiring pre-configured virtual data as service data required by the test through the virtual protocol;

and if the virtual service is not started by the service server, acquiring real data as service data required by the test through a third-party service protocol.

In an exemplary embodiment of the present disclosure, the method further comprises:

before initializing the required service data in the test case, backing up a database and a cache to obtain backup environment data;

in an exemplary embodiment of the present disclosure, the method further comprises:

and after the test case is executed, restoring the data in the database and the cache according to the backup environment data.

In an exemplary embodiment of the present disclosure, if the test case is executed completely, the method includes:

if a service server for executing the test case detects a pre-configured test ending protocol, the test case is executed;

and if the service server does not detect the test ending protocol, when the test duration is greater than or equal to the test duration threshold, the test case is executed.

In an exemplary embodiment of the disclosure, the obtaining a test result of the interface to be tested according to the protocol data and the expected protocol data of the interface to be tested includes:

judging whether all expected generated protocols are complete and whether the protocol data conform to the expected protocol data of the interface to be tested;

and if the expected generated protocol is incomplete or the protocol data does not accord with the expected protocol data of the interface to be tested, generating test result alarm information.

In an exemplary embodiment of the present disclosure, the method further comprises:

if the test case is executed, obtaining key data of a database and key data of a cache, and judging whether the key data of the database and the key data of the cache accord with expected data;

and if the database key data and the cache key data do not accord with the expected data, generating test result alarm information.

According to a second aspect of the present disclosure, there is provided a test apparatus of an interface, comprising:

the device comprises a test case acquisition module, a test case analysis module and a test case analysis module, wherein the test case acquisition module is used for acquiring a test case of an interface to be tested, and the interface to be tested comprises a plurality of services;

the trace protocol packet marking module is used for sending a trace protocol packet containing a trace marking bit to the interface to be tested and executing a test case of the interface to be tested;

a trace flag bit adding module, configured to, when the test case is executed, add the trace flag bit to a protocol packet sent by a service in the interface to be tested if the protocol packet received by the service is the trace protocol packet, and mark the protocol packet sent by the service as a trace protocol packet;

and the test result determining module is used for acquiring protocol data in all the tracking protocol packets received by the service and the tracking protocol packets sent out if the test case is executed, and obtaining the test result of the interface to be tested according to the protocol data and the expected protocol data of the interface to be tested.

According to a third aspect of the present disclosure, there is provided an electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform a method of testing an interface of any of the above via execution of the executable instructions.

According to a fourth aspect of the present disclosure, there is provided a computer readable medium having stored thereon a computer program which, when executed by a processor, implements a method of testing an interface as described in any one of the above.

The exemplary embodiments of the present disclosure may have the following advantageous effects:

in the method for testing an interface according to the exemplary embodiment of the present disclosure, a trace protocol packet including a trace flag bit is sent to an interface to be tested, and whether a protocol packet received by each service in the interface to be tested is a trace protocol packet is detected, when the protocol packet received by the service is a trace protocol packet, the trace flag bit is added to a protocol packet sent by the service to another service, and then a test result of the interface to be tested is obtained according to protocol data in all the trace protocol packets. In the method for testing an interface in the exemplary embodiment of the present disclosure, a trace flag bit is added in a protocol packet in a link trace manner to trace and record uplink and downlink messages of all services on a call link after an interface is initiated, and a call condition of a related service in the interface and a change of related data are determined by analyzing whether protocol data in a trace protocol packet is correct, so as to obtain a test result of the interface. For the interface of a complex system involving a plurality of upstream and downstream service calls, the efficiency and accuracy of interface testing can be improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure. It is to be understood that the drawings in the following description are merely exemplary of the disclosure, and that other drawings may be derived from those drawings by one of ordinary skill in the art without the exercise of inventive faculty.

FIG. 1 shows a flow diagram of a method of testing an interface of an example embodiment of the present disclosure;

FIG. 2 illustrates a flow diagram for initializing business data according to an example embodiment of the present disclosure;

FIG. 3 illustrates a block diagram of an interface automation test setup under a complex system in accordance with one particular embodiment of the present disclosure;

FIG. 4 illustrates a flow diagram of environment preparation in accordance with one embodiment of the present disclosure;

fig. 5 schematically shows a schematic diagram of the working principle of the protocol Mock according to a specific embodiment of the present disclosure;

FIG. 6 shows a schematic flow chart of an end test according to one embodiment of the present disclosure;

FIG. 7 schematically illustrates a schematic diagram of a test report according to one embodiment of the present disclosure;

FIG. 8 schematically illustrates a schematic view of a test results analysis interface, according to one embodiment of the present disclosure;

FIG. 9 shows a block diagram of a test setup of an interface of an example embodiment of the present disclosure;

FIG. 10 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present disclosure.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the subject matter of the present disclosure can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and the like. In other instances, well-known technical solutions have not been shown or described in detail to avoid obscuring aspects of the present disclosure.

Furthermore, the drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus their repetitive description will be omitted. Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

Interface testing, as a common functional testing mode, is one of the important means for QA (Quality assessment, testing staff) to ensure the system stability and continuous integration. In the frequently iterative service, the test of the existing interface is continuously returned, and the test efficiency and the project schedule of the QA are seriously influenced. Therefore, the automatic test of the interface is realized, and QA can spend more time on the test of case design and new functions, thereby accelerating the iteration of the project.

In some related embodiments, automated testing functionality may be provided by a number of testing tools, such as Postman, JMeter, SoapUI, and the like. However, in many practical projects, these tools have not been fully satisfactory for "automation," and can only be used as an aid to QA, or even be impractical for use in the project. To achieve true automation, the following problems need to be solved:

1. the interface test result is too simple to check

Most test tools can only determine if the test results are correct by essentially checking the message back packet of the interface. For a complex system interface, multiple upstream and downstream service calls may be involved, and simple packet back checking easily causes problem omission or incorrect problem positioning. For example, in one iteration, a service on the call link rarely updates the database field, or does not continue to call an upstream service, but still returns correctly, causing the problem to continue to travel latently to downstream traffic until it is likely to be discovered if it really affects downstream traffic. Therefore, in the interface of complex service, QA still needs to manually observe the calling condition of the related service and the data transformation of the database to ensure the accuracy of the interface.

2. Service data which cannot automatically solve interface dependence

The common interface test tool has no way to automatically set the service data on which the interface depends. For example, in an e-commerce system, if the interface for purchasing goods needs to be tested, QA needs to find an account with a sufficient balance or set a sufficient balance for a certain test account before each test, and then perform the test.

Based on the above-mentioned problem to be solved, the present exemplary embodiment first provides a method for testing an interface. Referring to fig. 1, the method for testing the interface may include the following steps:

step 110, a test case of an interface to be tested is obtained, wherein the interface to be tested comprises a plurality of services.

And S120, sending a tracking protocol packet containing the tracking mark bit to the interface to be tested, and executing the test case of the interface to be tested.

Step S130, when the test case is executed, if the protocol packet received by the service in the interface to be tested is the tracking protocol packet, adding the tracking mark bit to the protocol packet sent by the service, and marking the protocol packet sent by the service as the tracking protocol packet.

Step S140, if the test case is executed, acquiring protocol data in the tracking protocol packets received by all the services and the protocol data in the sent tracking protocol packets, and obtaining a test result of the interface to be tested according to the protocol data and the expected protocol data of the interface to be tested.

In the method for testing an interface according to the exemplary embodiment of the present disclosure, a trace protocol packet including a trace flag bit is sent to an interface to be tested, and whether a protocol packet received by each service in the interface to be tested is a trace protocol packet is detected, when the protocol packet received by the service is a trace protocol packet, the trace flag bit is added to a protocol packet sent by the service to another service, and then a test result of the interface to be tested is obtained according to protocol data in all the trace protocol packets. In the method for testing an interface in the exemplary embodiment of the present disclosure, a trace flag bit is added in a protocol packet in a link trace manner to trace and record uplink and downlink messages of all services on a call link after an interface is initiated, and a call condition of a related service in the interface and a change of related data are determined by analyzing whether protocol data in a trace protocol packet is correct, so as to obtain a test result of the interface. For the interface of a complex system involving a plurality of upstream and downstream service calls, the efficiency and accuracy of interface testing can be improved.

Next, the above steps of the present exemplary embodiment will be described in more detail with reference to fig. 2 to 8.

In step S110, a test case of an interface to be tested is obtained, where the interface to be tested includes a plurality of services.

The test case is a description of a test task performed on a specific software product, and embodies a test scheme, a method, a technology and a strategy. The contents of the test object, the test environment, the input data, the test steps, the expected results, the test scripts and the like are included, and finally, a document is formed. Simply considered, a test case is a set of test inputs, execution conditions, and expected results tailored for a particular purpose to verify whether a particular software requirement is met.

In this exemplary embodiment, the test case of the interface to be tested refers to a test case corresponding to the interface to be tested. The interface to be tested can be an interface of a complex system and relates to the calling of a plurality of upstream and downstream services.

Before executing the test case, the test method for the interface in this exemplary embodiment further needs to set environment data required for the test, and the specific method may be: if the preset interface parameters exist, calling a universal gateway interface, and initializing the required service data in the test case according to the preset interface parameters; and if the preset interface parameters do not exist, initializing the service data required in the test case according to the preset database parameters and/or cache parameters.

In this exemplary embodiment, the corresponding CGI may be directly called according to a preconfigured CGI (Common Gateway Interface) and Interface parameters, so as to initialize service data required in a test case, and simplify initialization operations of a database and a cache of a complex service. And if the corresponding interface calling service is not provided, the initialization operation of the business data is completed through the setting of the database or the cache.

For example, in a business scenario of online shopping, a sufficient amount needs to be set for a user, and a tester may initialize business data in two ways. If a 'balance setting' service interface is configured, the initialization of service data is completed directly through interface calling, and enough user balance is set without setting through a database or a cache; if no corresponding service interface is provided, the service data is initialized through preset database parameters and cache parameters, for example, a database table of the user balance is set to be a sufficient amount, or if the user balance is cached, the cache is set, specifically, the setting is performed through the database or the cache, and the setting can be determined according to the actual service requirement.

In this exemplary embodiment, as shown in fig. 2, initializing the service data required in the test case according to the preset database parameter and/or cache parameter may specifically include the following steps:

and S210, connecting the corresponding database according to preset database parameters.

The database parameters can include database addresses, port configuration information and authorization information of the database, and the corresponding database can be connected according to the database parameters.

Step S220, initializing service data required in the test case by executing database initial operation configured in advance by the database.

In the present exemplary embodiment, the preconfigured database initial operation may be, for example, insert, set, inc, remove, and the like. The business data may be initialized by performing database initialization operations provided by the configuration.

For example, assuming that a certain service is used to count the number of balls owned by the user, the pre-configured database initial operation may be: setting an ip, a port, a user and a password for connecting the database, and then executing the four database initial operations: firstly, inserting a ball _ count data table by executing insert operation, wherein the id of a ball in the table is 2, and the quantity of the ball is 1; second, updating the number of balls whose id is 2 to be 2 by executing set operation; thirdly, adding 1 to the number of balls with id 2 by executing inc operation, and updating the number to 3; finally, the ball with id 1 is deleted by performing remove operation.

And step S230, initializing the cache in the test case according to the preset cache parameters.

In this example embodiment, the cache parameter may include an address of the cache and port configuration information. After performing the initial setting of the database, the cache may be initially set according to the address of the cache and the port configuration information.

Step 240, initializing the service data required in the test case by executing the cache initial operation pre-configured in the cache.

The cache initial operation may be, for example, set, del, etc.

For example, the number of balls with id 2 may be set to 3 by a set operation, and the balls with id 1 may be deleted by a del operation.

Before initializing the service data required in the test case, the interface test method in this exemplary embodiment may further back up the database and the cache to obtain backup environment data, so that after the test case is executed, the data in the database and the cache are restored according to the backup environment data.

In this exemplary embodiment, after initializing the service data required in the test case, the method for testing an interface in this exemplary embodiment may further include: judging whether a service server for executing the test case opens a virtual service for configuring a virtual protocol; if the service server starts the virtual service, acquiring pre-configured virtual data as service data required by the test through a virtual protocol; and if the virtual service is not started by the service server, acquiring real data as service data required by the test through a third-party service protocol.

After initializing the service data, the service can also return the pre-configured data information when requesting the protocol of the third party by setting the Mock (virtual) information of the relevant protocol. The protocol Mock refers to that real data is not returned when a protocol is requested, and virtual configuration data is returned.

In step S120, a trace protocol packet including a trace flag bit is sent to the interface to be tested, and a test case of the interface to be tested is executed.

After the relevant environment preparation is made, a request can be made for the protocol configured by the test case, and the test case is started to be executed. Before initiating a protocol, a trace protocol packet including a trace flag bit may be sent to an interface to be tested, specifically, the trace flag bit may be added to a header of the protocol packet to obtain a corresponding trace protocol packet, and data of the protocol packet is collected and stored in a log database for protocol analysis.

In step S130, when the test case is executed, if the protocol packet received by the service in the interface to be tested is the trace protocol packet, the trace flag bit is added to the protocol packet sent by the service, and the protocol packet sent by the service is marked as the trace protocol packet.

When the test case is executed, the downstream service in the interface sends a protocol packet to the upstream service which the downstream service depends on, so that the calling of each service in the interface is completed, and finally the complete function of the interface is realized. After a protocol packet sent by a downstream service in an interface passes through a current service, the current service generates a plurality of protocol packets according to the received protocol packet and sends the protocol packets out. If the header of the protocol packet received by each service in the interface contains the field of the tracking mark bit, the tracking mark bit is automatically analyzed, the tracking mark bit is added into the protocol packet sent by the service, and then the protocol packet sent by the service is marked as the tracking protocol packet.

In this exemplary embodiment, the tracking protocol packet sent by the service may include: the protocol packets returned by the service to the downstream service, the protocol packets sent by the service to the upstream service, and the protocol packets broadcast by the service. The protocol packet returned by the service to the downstream service refers to a message return packet returned by the service to the downstream service, the protocol packet sent by the service to the upstream service refers to a message packet sent to the upstream service on which the service depends, and the protocol packet broadcasted by the service refers to a message packet broadcasted by the service to each client. Meanwhile, the tracking protocol packets received and sent by all the services are collected and recorded, and are stored in a log database for protocol analysis.

In step S140, if the test case is executed, the protocol data in the trace protocol packets received by all the services and the protocol data in the sent trace protocol packets are obtained, and the test result of the interface to be tested is obtained according to the protocol data and the expected protocol data of the interface to be tested.

In this exemplary embodiment, two types of use case ending detection standards may be supported, one is to detect a corresponding test ending protocol, and the other is to end a timeout. Specifically, if a service server for executing the test case detects a pre-configured test end protocol, the test case is executed; and if the service server does not detect the test ending protocol, finishing the execution of the test case when the test duration is greater than or equal to the test duration threshold.

And when the test case is executed, acquiring the protocol data in the tracking protocol packets received by all the services and the protocol data in the sent tracking protocol packets which are stored before from the log database, then acquiring the expected protocol data in the test case, and comparing the protocol data in the log database with the expected protocol data to obtain the test result of the interface to be tested. The protocol data is generally stored in a data format such as JSON (JavaScript Object Notation), and includes some critical data during the operation of the interface, for example, for a payment interface, the protocol data may include data such as user balance, user payment amount, and the like.

In this exemplary embodiment, the specific method for obtaining the test result of the interface to be tested according to the protocol data and the expected protocol data of the interface to be tested includes: judging whether all expected generated protocols are complete and whether the protocol data conform to the expected protocol data of the interface to be tested; and if the expected generated protocol is incomplete or the protocol data does not accord with the expected protocol data of the interface to be tested, generating test result alarm information.

After the test is finished, a corresponding test report can be generated for each test case, collected protocol data can be analyzed in the report, whether all key protocols expected to be generated exist is judged firstly, then, the collected protocol data is compared with the expected protocol data in the test cases one by one, and whether the collected protocol data accords with the expectation is judged. For example, a certain protocol data needs to be equal to an expected value given in a test case, and if the protocol data is different from the expected value after the test is finished, the protocol data is not in accordance with the expectation. For another example, if a certain protocol data needs to be greater than an expected value given in a test case, if the protocol data is less than or equal to the corresponding expected value after the test is finished, it indicates that the protocol data is not in accordance with the expectation. And if the test result does not meet the expectation, generating test result alarm information and sending the test result alarm information to related workers.

Besides analyzing the accuracy of the protocol data, the method also needs to analyze the database and the cache before and after the test, and the specific method is as follows: if the test case is executed, obtaining key data of the database and key data of the cache, and judging whether the key data of the database and the key data of the cache accord with expected data; and if the key data of the database and the cache key data do not accord with the expected data, generating test result alarm information.

In the interface testing method in the disclosed example embodiment, uplink and downlink messages of all services on a call link after one interface is initiated are tracked and recorded in a link tracking mode, and the accuracy of the interface in the true sense is ensured by analyzing whether a key protocol before and after the test case is executed is correct, and by database and cache data transformation and multi-dimensional verification. And before executing the test case, the interface execution dependent service environment is guaranteed through interface setting, database setting, cache setting and a mode that the interface returns mock data, and finally a test report is generated and an alarm is given to an execution result which is not in accordance with expectation.

Fig. 3 is a block diagram of an interface automation testing apparatus under a complex system provided according to the interface testing method in the exemplary embodiment in a specific embodiment of the present disclosure, which is an illustration of a specific application scenario of the above steps in the exemplary embodiment, and the apparatus may include four parts, namely an environment preparation module 310, a use case execution module 320, an end detection module 330, and a use case end module 340, where specific functions of the modules are as follows:

1. environment preparation module 310

Before executing the test case, the device will backup the database and the cache through the environment preparation module 310, and initialize the database, the cache, the interface and the environment data related to the service of the test environment according to the configuration. The specific content of initialization is as follows:

(1) setting a database: before executing the use case, data related to the dependent service is set.

(2) Cache setting: and before executing the use case, setting a cache related to the dependent service.

(3) Interface setting: and calling a dependent service interface for setting before executing the use case.

(4) The protocol mock: before executing the use case, the mock protocol ensures that the protocol does not return real data during the protocol, and returns mock data for the condition that a third party interface is used in the service.

By setting the database and the cache, most of the service data required by the self-service can be basically ensured (except for a small part of the data, the configuration file needs to be read, and the like). However, the setting of the database and the cache is more complicated, especially for some more complicated business logics, so the device also provides a way of calling a service interface (CGI) to simplify the preparation process of the business data environment of the service itself, and if the device provides the service called by the interface, the device can directly initialize the business data by calling the service interface (CGI) without initializing by setting the database and the cache. Meanwhile, considering that the service may depend on the third-party service, the device also provides a protocol Mock mode, so that the virtual data which is configured is fixedly returned depending on the third-party protocol, and the smooth execution of the test case is ensured.

As shown in fig. 4, it is an overall flow of the environment preparation module 310 when initializing the environment data, and specifically includes the following steps:

step S410, reading environment preparation configuration.

The device backups the database and the cache, and reads the database address, the cache address, the related service interface, the protocol needing the Mock and the parameters which are correspondingly set respectively, which are configured in the background.

Step S420, setting an initial database.

The device can be connected with the corresponding database according to the configured database address, port and authorization information, execute the database operation provided by configuration, initialize the service data and cache. The device supports 4 database data initial operations, namely insert, set, inc and remove.

And S430, setting an initial cache.

The device can carry out initialization setting on the cache according to the address of the cache and the port configuration information. The device supports 2 kinds of initial buffer operations, respectively set and del.

And step S440, calling interface initial setting.

If the device provides interface calling service, the corresponding CGI is called directly according to the configured CGI and CGI parameters, and initialization of service data is performed by acquiring preset parameters, so that a database of complex services and cache initialization operation are simplified.

If the device provides the service called by the interface, the tester can directly initialize the service data according to the step S440, and the logic in the step S420 and the step S430 is omitted. If the corresponding interface service is not provided, the service data may also be initialized by the method in step S420 or step S430.

And S450, performing Mock on the third-party protocol.

After initializing self service data, the device also can set Mock information of related protocols, and when the service requests the protocol of a third party, the device returns the pre-configured data information.

The working principle of the protocol Mock is shown in fig. 5, when a service server 501 of an interface automation test device needs to request third-party protocol data, the request will pass through a proxy server 502, and at this time, the device will judge whether the proxy server 502 starts the Mock service. If the Mock service is started, directly returning the fixedly configured data without carrying out a real request; and if not, really requesting a third-party service protocol to acquire data.

2. Use case execution Module 320

After the relevant environment preparation is made, the device can make a request for the protocol of case configuration and start to execute the test case. In the execution process of the test case, the key points comprise the following two parts:

(1) when the protocol is initiated, the message is marked.

Before initiating a protocol, a device adds a unique mark bit pt (protocol track) to a header of a sending protocol packet, collects data of the protocol packet, and stores the data into a log database, wherein the type of the data is client _ msg.

(2) When the service interface receives the marker message, it logs and passes the marker to the upstream service.

If the header of the request packet received by each service contains a pt field, the mark bit pt is analyzed, the mark bit pt is packaged into a message return packet of the service, a message packet sent to an upstream service and the header of a broadcast message packet, wherein the types of the mark bit pt are send _ client _ msg, send _ svr _ msg and broadcast _ msg, and then a protocol packet (the type is receive _ msg) received by the service and the sent protocol packet are collected and recorded and stored in a log database.

3. End detection module 330

As shown in fig. 6, after executing a use case, the device supports two use case ending detection standards, one is to detect a corresponding test ending protocol, and the other is to end over time.

And S610, detecting a test ending protocol.

If a test end protocol, such as a service loopback protocol, is configured in the test case, the device ends the execution of the case when detecting the test end protocol, then sets the execution state of the case, and starts to end the processing module.

And S620, ending the timeout.

After the device executes for a period of time, if a configured test ending protocol is not detected yet, or the use case cannot configure the ending protocol (for example, after the use case ends, some tasks need to be executed in a background, and no protocol can be used as a mark), the use case is automatically ended. For example, a timeout end time of 5s may be set by default, that is, after the example executes for 5s, if the configured test end protocol is not detected, the timeout end time will automatically end, and the timeout end time also supports modification.

4. Use case ending module 340

After the device finishes the case test, a case analysis report is generated according to the data prepared by the backup recovery environment and the configuration, and when the report is abnormal, a mail alarm is sent to related personnel.

(1) And (3) environmental recovery: relevant Environment settings for recovery Environment preparation

After the use case is ended, the device may restore the backed-up database and the cached environment in the environment preparation module 310, and restore the set Mock.

(2) Analyzing and generating a data report:

as shown in fig. 7, the apparatus generates a report for each test case, mainly analyzes each protocol collected in the case execution module 320, and compares the conversion between the database and the backup data, and the specific content in the generated test report is as follows:

1) protocol analysis: whether a critical protocol exists and whether protocol data is as expected

The device judges whether a pre-configured protocol is generated in a collected protocol log database according to pt marked by the use case; then the device can take the protocol data of the log, compare with the expected protocol data configured one by one, judge whether the protocol data accords with expectation.

2) Analyzing a database: whether key data of database is correct

Next, the device compares the data after the case execution with the backup data according to the configured database, and judges whether the data meets the expectation. FIG. 8 is a schematic diagram of a test result analysis interface, in which the configuration items are illustrated as follows:

database connection configuration: ip/port/db/user/pwd, corresponding to the address, port, database name, authorized user and password of the database.

A look-up table: data sheet for report analysis

Query statement query: the query conditions of the corresponding data before and after the use case is executed have different meanings corresponding to different operations.

The operation is as follows: insert: after the query case is executed, whether records meeting the query are inserted or not is judged, if an expected result is set, whether the records meet the expected result or not is also compared, the query of insert generally finds out a plurality of statements, and therefore the device generally adds judgment on data insertion time of a data table;

update: after the query case is executed, whether records meeting the query exist or not is also compared, if the records meet the expected result, for example, a certain state of the query user is inquired;

③ inc: after the query case is executed, whether records meeting the query exist or not accords with the set expected conversion result, the expected result is required to be set as a numerical value at the moment, and a negative value is allowed to represent reduction, for example, whether a fixed limit is deducted from a gold ingot after the user gives a gift is queried.

The expected result is: the records that satisfy the query are queried, whether the configured field meets the expectations of the operation. As shown in FIG. 8, after the expected result in the interface represents the execution of the use case, it is detected whether the number of fields in the column with the ball _ count table id of 2 is updated to 3.

3) And (3) cache analysis: whether the cache key data is updated correctly

Finally, the device can compare whether the detected key exists or not and whether the corresponding value accords with the expected value or not after the case is executed according to the configured cache.

(3) Error warning

After the device finishes the report analysis, if the result is not in accordance with the expected result, the alarm information is sent to the corresponding staff, and the problem is guaranteed to be solved in time.

It should be noted that although the various steps of the methods of the present disclosure are depicted in the drawings in a particular order, this does not require or imply that these steps must be performed in this particular order, or that all of the depicted steps must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions, etc.

Furthermore, the present disclosure also provides a device for testing an interface. Referring to fig. 9, the test apparatus of the interface may include a test case obtaining module 910, a trace protocol packet marking module 920, a trace mark bit adding module 930, and a test result determining module 930. Wherein:

the test case obtaining module 910 may be configured to obtain a test case of an interface to be tested, where the interface to be tested includes multiple services;

the trace protocol packet marking module 920 may be configured to send a trace protocol packet including a trace marking bit to the interface to be tested, and execute a test case of the interface to be tested;

the trace flag bit adding module 930 may be configured to, when executing the test case, add the trace flag bit to a protocol packet sent by a service if a protocol packet received by the service in the interface to be tested is a trace protocol packet, and mark the protocol packet sent by the service as a trace protocol packet;

the test result determining module 940 may be configured to, if the test case is executed, obtain the protocol data in the trace protocol packets received by all the services and the protocol data in the sent trace protocol packets, and obtain the test result of the interface to be tested according to the protocol data and the expected protocol data of the interface to be tested.

In some exemplary embodiments of the disclosure, the trace protocol packet issued by the service in the trace flag bit adding module 930 includes: the protocol packets returned by the service to the downstream service, the protocol packets sent by the service to the upstream service, and the protocol packets broadcast by the service.

In some exemplary embodiments of the present disclosure, the interface testing apparatus provided by the present disclosure may further include an environment data setting module, and the environment data setting module may include an interface calling unit and a database cache setting unit. Wherein:

the interface calling unit can be used for calling the universal gateway interface if the preset interface parameters exist, and initializing the required service data in the test case according to the preset interface parameters;

the database cache setting unit may be configured to initialize the service data required in the test case according to the preset database parameter and/or cache parameter if the preset interface parameter does not exist.

In some exemplary embodiments of the present disclosure, the database cache setting unit may include a database connection unit, a first data initialization unit, a cache initialization unit, and a second data initialization unit. Wherein:

the first data initialization unit may be configured to connect a corresponding database according to preset database parameters, where the database parameters include a database address, port configuration information, and authorization information of the database;

the database initialization unit may be configured to initialize service data required in the test case by performing a database initial operation preconfigured in the database;

the buffer initialization unit may be configured to initialize a buffer in the test case according to preset buffer parameters, where the buffer parameters include a buffer address and port configuration information;

the second data initialization unit may be configured to initialize the service data required in the test case by executing a cache initial operation preconfigured in the cache.

In some exemplary embodiments of the present disclosure, the environment data setting module may further include a virtual service determination unit, a virtual data acquisition unit, and a real data acquisition unit. Wherein:

the virtual service judging unit may be configured to judge whether a service server for executing the test case opens a virtual service for configuring a virtual protocol;

the virtual data acquisition unit may be configured to acquire, if the service server starts a virtual service, pre-configured virtual data as service data required for a test through a virtual protocol;

the real data acquisition unit may be configured to acquire the real data as the service data required for the test through a third party service protocol if the virtual service is not started by the service server.

In some exemplary embodiments of the present disclosure, the testing apparatus of an interface provided by the present disclosure may further include an environment data backup unit, which may be configured to backup the database and the cache before initializing the service data and the cache required in the test case, so as to obtain backup environment data.

In some exemplary embodiments of the present disclosure, the interface testing apparatus provided by the present disclosure may further include an environment data recovery module, which may be configured to recover data in the database and the cache according to the backup environment data after the test case is executed.

In some exemplary embodiments of the present disclosure, the test result determining module 940 may include a protocol end unit and a timeout end unit. Wherein:

the protocol ending unit may be configured to finish the test case if the service server for executing the test case detects a pre-configured test ending protocol;

the timeout ending unit may be configured to, if the service server does not detect the test ending protocol, end the execution of the test case when the test duration is greater than or equal to the test duration threshold.

In some exemplary embodiments of the present disclosure, the test result determining module 940 may further include an expected protocol data determining unit and a test result alerting unit. Wherein:

the expected protocol data judging unit can be used for judging whether all expected generated protocols are complete and whether the protocol data accord with the expected protocol data of the interface to be detected;

the test result warning unit may be configured to generate the test result warning information if the expected generated protocol is incomplete or the protocol data does not conform to the expected protocol data of the interface to be tested.

In some exemplary embodiments of the present disclosure, the test result determining module 940 may further include a critical data judging unit and a test result alerting unit. Wherein:

the key data judging unit can be used for acquiring key data of the database and cache key data and judging whether the key data of the database and the cache key data conform to expected data or not if the test case is executed;

the test result warning unit may be configured to generate test result warning information if the database key data and the cache key data do not match the expected data.

The details of each module/unit in the testing apparatus for the interface are already described in detail in the corresponding method embodiment section, and are not described herein again.

FIG. 10 illustrates a schematic structural diagram of a computer system suitable for use with the electronic device to implement an embodiment of the invention.

It should be noted that the computer system 1000 of the electronic device shown in fig. 10 is only an example, and should not bring any limitation to the functions and the scope of the application of the embodiment of the present invention.

As shown in fig. 10, the computer system 1000 includes a Central Processing Unit (CPU)1001 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)1002 or a program loaded from a storage section 1008 into a Random Access Memory (RAM) 1003. In the RAM 1003, various programs and data necessary for system operation are also stored. The CPU1001, ROM 1002, and RAM 1003 are connected to each other via a bus 1004. An input/output (I/O) interface 1005 is also connected to bus 1004.

The following components are connected to the I/O interface 1005: an input section 1006 including a keyboard, a mouse, and the like; an output section 1007 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 1008 including a hard disk and the like; and a communication section 1009 including a network interface card such as a LAN card, a modem, or the like. The communication section 1009 performs communication processing via a network such as the internet. The driver 1010 is also connected to the I/O interface 1005 as necessary. A removable medium 1011 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 1010 as necessary, so that a computer program read out therefrom is mounted into the storage section 1008 as necessary.

In particular, according to an embodiment of the present invention, the processes described below with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the invention include a computer program product comprising a computer program embodied on a computer-readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication part 1009 and/or installed from the removable medium 1011. When the computer program is executed by a Central Processing Unit (CPU)1001, various functions defined in the system of the present application are executed.

It should be noted that the computer readable media shown in the present disclosure may be computer readable signal media or computer readable storage media or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In contrast, in the present disclosure, a computer-readable signal medium may include a propagated data signal with computer-readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

As another aspect, the present application also provides a computer-readable medium, which may be contained in the electronic device described in the above embodiments; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by an electronic device, cause the electronic device to implement the method as described in the embodiments below.

It should be noted that although in the above detailed description several modules of the device for action execution are mentioned, this division is not mandatory. Indeed, the features and functionality of two or more of the modules described above may be embodied in one module, in accordance with embodiments of the present disclosure. Conversely, the features and functions of one module described above may be further divided into embodiments by a plurality of modules.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains.

It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.