API automated testing practices five typical scenarios

First, the basic procedure of the API test

Generally, the basic steps API test includes the following three steps:

1, ready to test data;

2, through a common API to test or develop their own tools to initiate request to test the API;

3, the result of verification returned response.

API testing tools commonly used command-line tool cURL, graphical interface tool Postman or SoapUI, API support performance testing JMeter and so on.

Two, API Examples complex scenes

By using a basic test tool that can do simple API test scenarios; and the project is in progress in order to solve some practical problems, we will design more complex test scenarios, here are a few practical items typical scenes.

Scene One: API calls in series

Agreement to pay, for example, we know that after the tripartite joint company access network, with agreement to replace withholding payment, and paid for in the agreement process requires the user to enter a verification code returned by bank card to complete the tie. From the interface level, the order is to call the agreement signing API, return status was successful and get to the SMS verification code, and then use this SMS verification code as an input parameter called withholding API. Signed two agreements and withholding API is called in sequence, and in the middle there are two calls to get SMS verification code on your phone, these processes are required to implement a program to improve efficiency through automation.

Scene Two: API interface encryption

To ensure the security API interface between the system and the system needs to access each other between modules encrypt, commonly used encryption methods are DES, AES, RSA, MD5, etc., various encryption systems are not the same (the interface caller and the interface provider a good agreement can be), meaning API test need to support multiple automated encryption process. Some systems also returns the encrypted response message, also need to identify and decryption.

Scene Three: Asynchronous API test

Asynchronous API refers to a synchronous response is received after the request is issued, but not the final result of the processing, the final result obtained by the callback query or active. For such the API, only the first step of the verification synchronization response, have to continue subsequent verification value DB, whether the value of the MQ, and the like asynchronous callback success. For asynchronous callback, we can simulate the callback address to verify success; and for the initiative to check, we have to see through the DB status value to verify, but the results of the query to the point in time of uncertainty, a few minutes to a few hours are possible, which was to have a regular DB query task to verify.

Scene Four: external dependency API Test

APIA call APIB and B is unavailable at this time to consider how to test APIA. Such as payment system-party payment channels, reliance on banks, not all three parties support a test environment, address the core problem of this idea is to build MockServer, and try to make it universal, we have developed a system Mock -aMock, by page entry interface information stored in the database, configured Mock interfaces accessible via Nginx, background unified processing request information, and then to match specific response information via the URL and message characteristics.

Three, API test platform

Our API platform is to test based on business scenarios, that is, to support the common needs of the business, but also to be developed for the personality characteristics of different services to enrich the API testing capabilities; and, to use cases but also have a good plan, results have clearly demonstrated, tested platform architecture as shown below:

BIT: Business Interface Testing (BusinessInterfaceTest)

SUT: System UnderTest

TestCaseManagement: test case management, including collection from test to test, build and maintain data relationships and then to test tasks. Is the smallest unit test, test set, the test execution from the task is a test of a dimension of imputation the use cases, the timing may be triggered immediately executed only perform test cases.

Util: tool class encapsulation, mainly provides data encryption and decryption, data type conversion, configuration file read/write, data dictionary caching services, etc.

Validator: encapsulation field in response to verifying the interface and database fields.

RiskManagement: risk control process, because it will involve pay real money, you need the built-in risk control rules to ensure the safety of funds, risk control.

Timer: regular tasks, including

  • Series API embodiment, the pre-use state of the embodiment of the judgment;

  • Database validation of asynchronous API;

  • API timeout failure condition judgment embodiment;

  • The timing of execution of the mission plan.

MockServer: cases with external systems Mock dependent service.

Portal: API test platform portals, including the entry test, maintenance, testing tasks, the results of view, export and so operates through the portal.

DB: storing test data and the corresponding test task, test report data, as well as project configuration.

At present the project on the API test platform maintenance with more than 1,200 cases of summary to return to the main use cases, and is constantly increasing, with the added use case, the platform also gone through a series of optimization, Here to talk about the process of some thought.

Fourth, the test data preparation

For the embodiment using a number of API execution, the data driver needs test, i.e. the test data can be decoupled and separated from the test code, the test data for easy maintenance while ensuring the accuracy of the data format is such case design



Several key node data provided by the DataProvider, in order to increase test coverage, test database similar to a number of data, such as lines of four elements (bank card number, phone number, ID number, name) data, when a large number of use cases need to read , the cache can be stored and read cList inside, by looping through, so that each test data can be read uniformly, the following piece of code is the replacement of critical data node, the data is sequentially assigned to the corresponding variable cList.

Fifth, the logic control test execution

In many cases the test of API test scenarios, sequence example relates to a call. Below, “signing – Success -kftn- Protocol” depends on “sign – -kftn success message” is performed; when configured in association with the embodiment is added.

When executed, the two types are divided according to the use-case properties, which are stored in two lists, the use cases without precondition can be executed immediately, the use cases with precondition, set TestStatus to 0, wait for the scheduled task polling to trigger execution. The classification execution code is shown below

Scheduled task once per minute, following a period of pre-determining the execution state of the API, only the “0000” represents the success of this API to perform, when executed, needs to use the pre-read data and incoming embodiment; API if the front fails, stop the task execution, a number of API cases the order execution is the same reason; use cases even with external dependencies, such as SMS verification code, we can also automatically upload SMS verification code via write a mobile phone APP program to the server, and then trigger delay Get codes, status, and results obtained with the embodiment of the recording performed by the DB, and passed to the next API used to complete the execution order of the multiple use cases. In addition, the testing tasks are packaged as restful interface, it can be more flexible and the team is currently being developed in conjunction with CICD system.

Sixth, the verification of test results

By analysis of business, the result of the API checking roughly classified into two types, and in response to the checksum verification database. Parity check response is directed response message fields may be an exact match may also be through a positive fuzzy matching expression; database validation is based on the timing of the tasks, which need embodiment calibration method according to the conventions set format, such as in the following sql test conditions, will return in the semi-production environment by specifying a single number, and other conditions to the query field, and determine whether the status of 7, in order to determine whether the use cases successfully.

bs_outpay.trans_batchtbleft joinbs_outpay.es_business_sendbsontb.business_batch_no=bs.entity_uuidandbs.entity_status<>2 WHEREtb.outer_batch_noin (?)  order bytb.CREATED_TIMEDESC|,|{"status":"7"}


Successful use cases into state failure, Processing, timeout four states, corresponding respectively arranged SQL query demapping, success and failure is the final state, the process is the need to research timed task, timeout, we set the internal of a state, the current is not returned over one hour to the final state expires, the API with alarm and failure cases, human intervention required view. All these rules are used to establish and edit embodiment when added below, one embodiment comprises using a response check (values ​​of the check, key check) checksum and databases, such a flexible design to meet the basic API complex test scenarios. It should be noted is that many applications do not allow direct access to the database external test platform, our solution is to write a data query service deployed in the system environment, only provides query capabilities, and encryption verification to ensure communication parties (test platform and data query between service) credible.

Generally speaking, the test platform or framework can be understood from a certain level as a series of tool chain, development of this platform, we use technology stack has springmvc + herbinate do logic control, amazingUI do use case management, echart do the results show also use Jenkins to do the task scheduling, customer is the business line testers, they do not need to know to achieve specific code, but requires a system structure and a good understanding of the use case rules have, in order to design a use case in line with the test scenario.

Any design or test platform to service-based, follow-up strategy to advance our API platform is to continue to increase the scene capabilities to support more business types of tests, such as clearing and settlement system, end of day, day of running batch job, check reconciliation file data, etc., to increase concurrency and large and performance testing tool combined.

Author: Sun Eagle

Source: CreditEase Institute of Technology

Leave a Reply