CN113407458B

CN113407458B - Interface testing method and device, electronic equipment and computer readable medium

Info

Publication number: CN113407458B
Application number: CN202110777550.4A
Authority: CN
Inventors: 许晓平; 屈可敏
Original assignee: Guangzhou Boguan Information Technology Co Ltd
Current assignee: Guangzhou Boguan Information Technology Co Ltd
Priority date: 2021-07-09
Filing date: 2021-07-09
Publication date: 2023-07-14
Anticipated expiration: 2041-07-09
Also published as: CN113407458A

Abstract

The disclosure relates to a method and a device for testing an interface, electronic equipment and a computer readable medium, and belongs to the technical field of testing. The method comprises the following steps: obtaining a test case of an interface to be tested, wherein the interface to be tested comprises a plurality of services; transmitting a tracking protocol packet containing a tracking mark bit to the interface to be tested, and executing the test case; if the protocol packet received by the service in the interface to be tested is the tracking protocol packet, adding the tracking mark bit into 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 sent tracking protocol packets, and acquiring 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. The interface test is carried out in a link tracking mode, so that the efficiency and the accuracy of the interface test can be improved.

Description

Interface testing method and device, electronic equipment and computer readable medium

Technical Field

The disclosure relates to the field of testing technology, and in particular, to a testing method of an interface, a testing device of the interface, electronic equipment and a computer readable medium.

Background

Interface test is a common functional test mode, and is one of important means for ensuring stable and continuous integration of the system by testers.

Some existing interface testing tools and testing methods can only be used as auxiliary tools for testing, so that the real automation is difficult to meet, the verification of the obtained interface testing result is too simple, and the testing result is often inaccurate for interfaces of complex systems possibly involving multiple upstream and downstream service calls.

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

It should be noted that the information disclosed in the above background section is only for enhancing 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 disclosure aims to provide a testing method of an interface, a testing device of the interface, electronic equipment and a computer readable medium, so as to improve the accuracy of the testing result of the interface 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:

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

transmitting 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 into 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 sent tracking protocol packets, and acquiring 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 present disclosure, the tracking protocol packet issued by the service includes: the service returns to the protocol packet of the downstream service, the protocol packet of the upstream service sent by the service and the protocol packet broadcast by the service.

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

If the preset interface parameters exist, a universal gateway interface is called, and service data required in the test case are initialized according to the preset interface parameters;

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

In an exemplary embodiment of the present disclosure, the initializing service data required in the test case according to preset database parameters and/or cache parameters 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 service data required in the test case by executing database initial operation pre-configured by 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 service data required in the test case by executing a pre-configured cache initial operation in the cache.

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

judging whether a service server for executing the test case starts a virtual service for configuring a virtual protocol or not;

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

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

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

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

and after the test case is executed, recovering 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, the method includes:

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

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

In an exemplary embodiment of the disclosure, the 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 the protocols expected to be generated are complete or not and whether the protocol data accords with the expected protocol data of the interface to be tested or not;

and if the protocol expected to be generated 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.

if the test case is executed, acquiring database key data and cache key data, and judging whether the database key data and the cache key data accord with expected data or not;

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 for an interface, comprising:

the test case acquisition module is used for acquiring test cases of interfaces to be tested, wherein the interfaces to be tested comprise a plurality of services;

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

the trace marking bit adding module is used for adding the trace marking bit into the protocol packet sent by the service and marking the protocol packet sent by the service as a trace protocol packet if the protocol packet received by the service in the interface to be tested is the trace protocol packet when the test case is executed;

and the test result determining module is used for acquiring protocol data in all the tracking protocol packets received by the service and the sent tracking protocol packets if the test case is executed, 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.

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 the 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 the method of testing an interface of any of the above.

Exemplary embodiments of the present disclosure may have the following advantageous effects:

in the method for testing the 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 the trace protocol packet, the trace flag bit is added to a protocol packet sent by the service to other services, and then a test result of the interface to be tested is obtained according to protocol data in all the trace protocol packets. According to the method for testing the interface in the disclosed example embodiment, a trace mark 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 the interface is initiated, and whether protocol data in the trace protocol packet are correct or not is analyzed to determine call conditions of related services and changes of related data in the interface, so that a test result of the interface is obtained. The efficiency and accuracy of interface testing can be improved for interfaces of complex systems involving multiple upstream and downstream service calls.

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 disclosure and together with the description, serve to explain the principles of the disclosure. It will be apparent to those of ordinary skill in the art that the drawings in the following description are merely examples of the disclosure and that other drawings may be derived from them without undue effort.

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 of initializing business data according to an example embodiment of the present disclosure;

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

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

fig. 5 schematically illustrates a schematic diagram of the operating principle of a protocol Mock according to one embodiment of the present disclosure;

FIG. 6 illustrates a flow diagram of ending a test in one embodiment according to 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 diagram of a test result analysis interface according to one embodiment of the present disclosure;

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

fig. 10 shows a schematic diagram of a computer system suitable for use in implementing embodiments of the present disclosure.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. However, the exemplary embodiments may be embodied in many 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 the 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 present disclosure. One skilled in the relevant art will recognize, however, that the aspects of the disclosure may be practiced without one or more of the specific details, or with other methods, components, devices, steps, etc. 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 a repetitive description thereof 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 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, which is a common functional testing mode, is one of the important means for ensuring the stability and continuous integration of the system by QA (Quality Assurance, test staff). In the frequently iterated business, the test of the existing interface is continuously returned, so that the test efficiency and project progress of QA are seriously affected. Therefore, the interface automation test is realized, so that QA can spend more time on the test of the use case design and the new function, thereby accelerating project iteration.

In some related embodiments, automated test functions may be provided by some test tools, such as Postman, JMeter, soapUI tools. However, in many practical projects, these tools do not fully satisfy "automation," but can only be used as a QA aid, or even cannot be applied to the project. To achieve real automation, the following problems need to be solved:

1. The test result of the interface is too simple to check

Most test tools can basically only check the message packet of the interface to determine whether the test result is correct. For an interface of a complex system, multiple calls of upstream and downstream services may be involved, and simple packet-back verification may easily cause missing problems or incorrect positioning of problems. For example, in one iteration, invoking a service on the link updates little of the database field, or does not continue to invoke an upstream service, but still returns correctly, resulting in the problem continuing to travel downstream traffic latency until it is likely to be discovered when it does affect downstream traffic. Therefore, the QA is still required to observe the calling condition of the related service and the data transformation of the database manually to ensure the accuracy of the interface facing the interface of the complex service.

2. Failure to automatically resolve interface dependent traffic data

The conventional 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 an interface for purchasing goods needs to be tested, QA needs to find an account with a sufficient balance before each test, or set a sufficient balance for a certain test account, and then perform the test.

Based on the above-mentioned problems 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:

s110, obtaining a test case of an interface to be tested, wherein the interface to be tested comprises a plurality of services.

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

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

And S140, if the test case is executed, acquiring protocol data in the tracking protocol packet received by all the services and the sent tracking protocol packet, 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.

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, wherein the interface to be tested includes a plurality of services.

The test case refers to the description of a specific software product for testing tasks, and the test scheme, method, technology and strategy are embodied. The content of the method comprises a test target, a test environment, input data, a test step, an expected result, a test script and the like, and finally a document is formed. Briefly, a test case is a set of test inputs, execution conditions, and expected results tailored for a particular goal to verify that a particular software requirement is met.

In this example embodiment, a test case of an 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 method for testing the interface in this example embodiment further needs to set environmental data required for testing, and the specific method may be: if the preset interface parameters exist, a universal gateway interface is called, and service data required in the test case is initialized according to the preset interface parameters; if the preset interface parameters do not exist, initializing service data required in the test case according to the preset database parameters and/or the cache parameters.

In this example embodiment, the corresponding CGI may be directly called according to the preconfigured CGI (Common Gateway Interface, universal gateway interface) and interface parameters, to initialize the service data required in the test case, and simplify the initialization operation of the database and cache of the complex service. 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 of money needs to be set for a user, and a tester can initialize business data in two ways. If a service interface for setting balance is configured, the initialization of service data is completed directly through interface call, and enough balance of users is set without setting through a database or a cache; if no corresponding service interface is provided, the service data is initialized by preset database parameters and cache parameters, for example, a database table of the balance of the user is set to be a sufficient amount, or if the balance of the user is cached, the cache is set, and the setting is specifically performed by the database or the cache, which can be determined according to the actual service requirement.

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

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

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

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

In this example embodiment, the pre-configured database initial operation may be, for example, insert, set, inc, remove, and the like. The service data may be initialized by performing a database initialization operation provided by the configuration.

For example, assuming a certain service is used to count the number of balls owned by a user, the pre-configured database initial operation may be: setting ip, port, user and password of the connection database, and then executing the four initial database 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 number of balls is 1; second, updating the number of balls with id of 2 to 2 by performing a set operation; thirdly, adding 1 to the number of balls with id of 2 by executing inc operation, and updating the number to 3; finally, the ball with id 1 is deleted by performing the remove operation.

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

In this example embodiment, the cache parameters may include the address and port configuration information of the cache. After the initial setting of the database is executed, the cache can be initialized according to the address and the port configuration information of the cache.

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

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

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

Before initializing service data required in the test case, the test method of the interface in the present exemplary embodiment may further backup the database and the cache to obtain backup environment data, so as to restore the database and the data in the cache according to the backup environment data after the test case is executed.

In this example embodiment, after initializing service data required in the test case, the method for testing an interface in this example embodiment may further include: judging whether a service server for executing the test case starts a virtual service for configuring a virtual protocol; if the service server starts the virtual service, the virtual data which is pre-configured is obtained through a virtual protocol to serve as service data required by the test; if the service server does not start the virtual service, the real data is obtained through a third party service protocol and is used as the service data required by the test.

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 related protocol. The protocol Mock refers to that real data is not returned when the protocol is requested, but 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 preparing the relevant environment, the protocol configured by the test case can be requested to start executing the test case. Before initiating a protocol, a trace protocol packet containing 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 executing the test case, if the protocol packet received by the service in the interface to be tested is a 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 on which the downstream service depends, so that the call of each service in the interface is completed, and the complete function of the interface is finally realized. After passing through the current service, the protocol packets sent by the downstream service in the interface generate a plurality of protocol packets according to the received protocol packets, and send the protocol packets. Each service in the interface receives the protocol packet, if the header contains a field of the trace flag bit, the trace flag bit is automatically parsed, the trace flag bit is added to the protocol packet sent by the service, and then the protocol packet sent by the service is marked as a trace protocol packet.

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

In step S140, if the test case is executed, protocol data in the trace protocol packet received by all the services and the trace protocol packet sent out are obtained, and a 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 example embodiment, two use case end detection criteria may be supported, one that detects a corresponding end-of-test protocol and the other that ends over time. Specifically, if the service server for executing the test case detects a pre-configured test ending protocol, the test case is executed; if the service server does not detect the test ending protocol, when the test time length is greater than or equal to the test time length threshold value, the test case is executed.

When the test case is executed, the trace protocol package received by all the services stored before and the protocol data in the issued trace protocol package are acquired from the log database, then the expected protocol data in the test case is acquired, and the test result of the interface to be tested is obtained by comparing the protocol data in the log database with the expected protocol data. The protocol data is generally stored in a data format such as JSON (JavaScript Object Notation, JS object numbered musical notation), and includes some key data in the running process of the interface, for example, for a payment interface, the protocol data may include data such as a balance of the user, a payment amount of the user, and the like.

In this example 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 is: judging whether all the protocols expected to be generated are complete or not, and judging whether the protocol data accords with the expected protocol data of the interface to be tested or not; 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, the collected protocol data can be analyzed in the report, whether all the key protocols expected to be generated exist or not is judged, and then the collected protocol data is compared with the expected protocol data in the test case to judge whether the collected protocol data accords with the expected protocol. 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 expected. For another example, if a certain protocol data needs to be greater than an expected value given in the test case, if the protocol data is less than or equal to the corresponding expected value after the test is finished, it is indicated that the protocol data is not expected. If the test result does not meet the expectation, generating test result warning information and sending the test result warning information to related staff.

In addition to analyzing the accuracy of protocol data, the method also needs to analyze the database and the cache before and after the test, and specifically comprises the following steps: if the test case is executed, acquiring database key data and cache key data, and judging whether the database key data and the cache key data accord with expected data or not; 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 the method for testing the interfaces in the example embodiment of the disclosure, uplink and downlink messages of all services on the call link after one interface is initiated are tracked and recorded by means of link tracking, whether key protocols before and after execution of the test case are correct, databases and cache data transformation are analyzed, and the accuracy of the interfaces in the true sense is guaranteed by means of multidimensional verification. Before the test case is executed, the method ensures the business environment on which the interface executes depending by means of interface setting, database setting, cache setting and mock data returning of the interface, and finally generates a test report and alarms the execution result which does not accord with expectations.

As shown in fig. 3, which is a block diagram of an interface automation test apparatus under a complex system provided according to a test method of an interface in an embodiment of the present disclosure, and is an illustration of a specific application scenario of the above steps in the embodiment, 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 respective modules are as follows:

1. Environment preparation Module 310

Before the test case is executed, 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 service related environment data of the test environment according to the configuration. The specific content of the initialization is as follows:

(1) Database setting: before executing the use case, setting data related to the dependent service.

(2) And (3) cache setting: before the use case is executed, a cache related to the dependent service is set.

(3) And (3) interface setting: before executing the use case, calling the dependent service interface to set.

(4) Protocol mock: before executing the use case, the mock is a certain protocol, so that the protocol does not return real data during the protocol, and the mock data is returned for the condition of using a third party interface in service.

By setting the database and the cache, service data required by most of own services can be basically ensured (except for a small amount of data, the mode of reading configuration files and the like is required). However, the setting of the database and the cache is complicated, especially for some complicated service logics, so the device also provides a way of calling a service interface (CGI) to simplify the preparation process of the service data environment of the service itself, and if the device provides the service called by the interface, the service data can be initialized directly by the way of calling the service interface (CGI) without initializing by the way of setting the database and the cache. Meanwhile, considering that the service possibly depends on a third party service, the device also provides a protocol Mock mode, so that virtual data which is configured is fixedly returned by depending on the third party protocol, and smooth execution of the test case is ensured.

As shown in fig. 4, the overall flow of the environment preparation module 310 in initializing the environment data may specifically include the following steps:

step S410, reading environment preparation configuration.

The device can back up the database and the cache, and reads the database address, the cache address, the related service interface, the protocol requiring Mock and the parameters which are respectively and correspondingly set.

Step S420, initial database setting.

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

Step S430, initial buffer setting.

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

Step S440, calling the initial setting of the interface.

If the device provides the service called by the interface, the corresponding CGI is called directly according to the configured CGI and CGI parameters, and the initialization of service data is performed by acquiring preset parameters, so that the database and the cache initialization operation of complex services 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 ignore the logic in the step S420 and the step S430. If the corresponding interface service is not provided, the service data may be initialized by the method in step S420 or step S430.

S450, performing Mock on the third party protocol.

After initializing the own service data, the device also sets Mock information of related protocols, and returns preset data information when the service requests the protocol of a third party.

The working principle of the protocol Mock is shown in fig. 5, when the service server 501 of the interface automation test device needs to request the third party protocol data, the request passes through a proxy server 502, and at this time, the device determines whether the proxy server 502 starts the Mock service. If the Mock service is started, directly returning the data of the fixed configuration without carrying out a real request; if the Mock is not started, the third party service protocol is truly requested, and the data is acquired.

2. Use case execution module 320

After preparing the relevant environment, the device requests the protocol of the case configuration, and starts to execute the test case. In the execution process of the test case, the key points comprise the following two parts:

(1) When initiating the protocol, the message is marked.

Before initiating the protocol, the device adds a unique flag bit pt (protocol track) to the header of the sending protocol packet, and collects the data of the protocol packet, with the type of client_msg, and stores the data in the log database.

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

When the header of the request packet received by each service contains a pt field, the tag bit pt is analyzed, and the tag bit pt is packed into a message packet of the service, a message packet sent to an upstream service, and the header of a broadcast message packet, which are respectively of the types send_client_msg, send_ svr _msg and broadcast_msg, and then the protocol packet (of the type receive_msg) received by the service and the protocol packet sent by the service are collected and recorded and stored in a log database.

3. End detection module 330

As shown in fig. 6, after executing the use case, the device supports two use case end detection criteria, one is that the corresponding test end protocol is detected, and the other is that the timeout is ended.

And S610, detecting a test ending protocol.

If a test ending protocol, such as a service packet-back protocol, is configured in the test case, the device ends execution of the case when the test ending protocol is detected, then sets an execution state of the case, and starts to end the processing module.

Step S620, ending the timeout.

If the device does not detect the configured end-of-test protocol after executing for a period of time, or if the use case cannot configure the end-of-test protocol (for example, after ending the use case, the device needs to execute some tasks in the background and cannot use any protocol to make an identification), the use case can automatically end. The timeout end is also the last guarantee of the use case end, for example, a timeout end time of 5s can be defaulted, i.e. after the use case is executed for 5s, the timeout end time also supports modification, if no configured test end protocol is detected.

4. Use case ending module 340

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

(1) Environmental recovery: restoring context-ready related context settings

After the use case is finished, the device will 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 device generates a report for each test case, mainly analyzes each protocol collected in the case execution module 320, and compares the database with the transformation of the backup data, and the specific contents in the generated test report are as follows:

1) Protocol analysis: whether critical protocols exist and whether protocol data is expected

The device firstly judges whether a pre-configured protocol is generated or not in a collected protocol log database according to the pt of the use case mark; and then the device can take the protocol data of the log, compare the protocol data with the configured expected protocol data, and judge whether the protocol data accords with the expected protocol data.

2) Database analysis: whether the key data of the database is correct

And then, the device also judges whether the data accords with the expectations or not according to the configured database and comparing the data after the use case is executed with the transformation of the backup data. FIG. 8 is a schematic diagram of a test result analysis interface, wherein the configuration items in the interface are as follows:

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

Look-up table: data sheet for report analysis

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

The operation is as follows: (1) insert: after the query case is executed, whether records meeting query (query) are inserted or not, if an expected result is set, whether the query meets the expected result or not is also compared, and a plurality of sentences are generally found by the query of the insert, so that the device generally adds the judgment of the data insertion time of the data table;

(2) update: after the query case is executed, whether records meeting the query exist or not, and if an expected result is set, whether the expected result is met or not is also compared, for example, a certain state of a query user is queried;

(3) inc: after the query case is executed, whether a record meeting the query exists or not, and the set expected transformation result is accordant, wherein the expected result must be set to a numerical value, and a negative value is allowed to represent reduction, such as whether the fixed limit is deducted from the gold ingot after the query user gives a gift.

The desired result is: querying records meeting the query, and whether the configured fields meet the expectations of the operation. As shown in fig. 8, after the expected result in the interface represents the execution case, it is detected whether the field number is updated to 3 in the column with the ball_count table id of 2.

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

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

(3) Error warning

After the device finishes report analysis, if the result which does not meet the expected result occurs, alarm information can be sent to corresponding staff, and the problem is ensured to be solved in time.

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

Further, the disclosure also provides a testing device for the interface. Referring to fig. 9, the test apparatus of the interface may include a test case acquisition module 910, a trace protocol packet tagging module 920, a trace tag bit adding module 930, and a test result determining module 930. Wherein:

the test case acquisition module 910 may be configured to acquire a test case of an interface to be tested, where the interface to be tested includes a plurality of 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 add a trace flag bit to a protocol packet sent by a service and mark the protocol packet sent by the service as a trace protocol packet if the protocol packet received by the service in the interface to be tested is the trace protocol packet when the test case is executed;

the test result determining module 940 may be configured to obtain the protocol data in the trace protocol packet received by all the services and the trace protocol packet sent by all the services if the test case is executed, 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 present disclosure, the trace protocol package issued by the service in the trace flag bit addition module 930 includes: the service returns to the protocol packet of the downstream service, the protocol packet of the service sent to the upstream service and the protocol packet of the service broadcast.

In some exemplary embodiments of the present disclosure, a test apparatus of an interface provided by the present disclosure may further include an environment data setting module, which 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 preset interface parameters exist, and initializing service data required by the test case according to the preset interface parameters;

the database cache setting unit may be configured to initialize service data required in the test case according to the preset database parameters and/or cache parameters if the preset interface parameters do 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 initializing unit may be configured to connect to 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 used for initializing service data required in the test case by executing a database initialization operation configured in advance by the database;

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

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

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

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

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

The real data acquisition unit may be configured to acquire, if the service server does not open the virtual service, real data as service data required for the test through a third party service protocol.

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

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

In some example embodiments of the present disclosure, the test result determination module 940 may include a protocol ending unit and a timeout ending unit. Wherein:

the protocol ending unit may be configured to finish execution of 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 finish execution of the test case when the test time period is greater than or equal to the test time period threshold if the service server does not detect the test ending protocol.

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

the expected protocol data judging unit may be used to judge whether all the protocols expected to be generated are complete or not and whether the protocol data conform to the expected protocol data of the interface to be tested or not;

the test result alarm unit may be configured to generate test result alarm information if the protocol expected to be generated 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 determination module 940 may further include a key data judgment unit and a test result warning unit. Wherein:

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

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 conform to expected data.

The specific details of each module/unit in the testing device of the interface are described in detail in the corresponding method embodiment section, and are not repeated here.

Fig. 10 shows a schematic diagram of a computer system suitable for use in implementing 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 impose any limitation on the functions and the application scope of the embodiments of the present invention.

As shown in fig. 10, the computer system 1000 includes a Central Processing Unit (CPU) 1001, which can execute 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 required for system operation are also stored. The CPU1001, ROM 1002, and RAM 1003 are connected to each other by 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 portion 1007 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), etc., and a speaker, etc.; a storage portion 1008 including a hard disk or 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 drive 1010 is also connected to the I/O interface 1005 as needed. A removable medium 1011, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like, is installed as needed in the drive 1010, so that a computer program read out therefrom is installed as needed in the storage section 1008.

In particular, according to embodiments of the present invention, the processes described below with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present 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 shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network via the communication portion 1009, and/or installed from the removable medium 1011. When executed by a Central Processing Unit (CPU) 1001, the computer program performs various functions defined in the system of the present application.

It should be noted that the computer readable medium shown in the present disclosure may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any 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 context of this 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 the present disclosure, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. 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 flowcharts 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 that may be contained in the electronic device described in the above embodiment; or may exist alone without being incorporated into the electronic device. The computer-readable medium carries one or more programs which, when executed by one of the electronic devices, cause the electronic device to implement the methods described in the embodiments below.

It should be noted that although in the above detailed description several modules of a device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functions of two or more 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 a plurality of modules to be embodied.

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 adaptations, 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 is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A method for testing an interface, comprising:

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

if the test case is executed, acquiring all the protocol data in the tracking protocol packets received by the service and the sent tracking protocol packets;

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

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

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

5. A method of testing an interface according to claim 3, wherein after said initializing the required service data in the test case, the method further comprises:

6. A method of testing an interface according to 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 of testing an interface of claim 6, further comprising:

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

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

10. An interface testing apparatus, comprising:

the trace marking bit adding module is used for adding the trace marking bit into a protocol packet sent by an upstream service on which the service depends and marking the protocol packet sent by the service as a trace protocol packet if the protocol packet sent by the downstream service and received by the service in the interface to be tested is the trace protocol packet when the test case is executed;

the protocol data acquisition module is used for acquiring all the protocol data in the tracking protocol packets received by the service and the sent tracking protocol packets if the test case is executed;

the expected data judging module is used for judging whether all protocols expected to be generated are complete or not and whether the protocol data accords with the expected protocol data of the interface to be tested or not;

and the test result warning module is used for generating test result warning information if the protocol which is expected to be generated is incomplete or the protocol data does not accord with the expected protocol data of the interface to be tested.

11. An electronic device, comprising:

a processor; and

a memory for storing one or more programs that, when executed by the processor, cause the processor to implement the method of testing an interface of any of claims 1-9.

12. A computer readable medium on which a computer program is stored, characterized in that the program, when executed by a processor, implements a method of testing an interface according to any one of claims 1 to 9.