Shulou(Shulou.com)06/01 Report--

1. Basic steps of API testing

Generally speaking, the basic steps of API testing mainly include the following three steps:

1. Prepare test data

2. Initiate the request of the tested API through general-purpose or self-developed API testing tools

3. Verify the response of the returned result.

The commonly used API testing tools are command line tool cURL, graphical interface tool Postman or SoapUI, JMeter which supports API performance testing and so on.

2. Examples of complex scenes in API

By using basic testing tools, we can do API testing for simple scenarios. In order to solve some practical problems during the project, we will design more complex test scenarios. Here are several typical scenarios in the actual project.

Scenario 1: API concatenation call

Take the agreement payment as an example, we know that after the three companies connect to the Internet, they replace the withholding with the agreement payment, and the process of the agreement payment requires the user to enter the verification code returned by the bank to complete the card binding. From the interface level, the order is to call the protocol signing API first, return the status successfully and obtain the SMS verification code, and then use the SMS verification code as the input parameter to call the withholding API. The two API of protocol signing and withholding are called sequentially, and the SMS verification code on the mobile phone is obtained between the two calls. These processes need to be realized through program automation to improve efficiency.

Scenario 2: API interface encryption

In order to ensure the security of the API interface, the mutual access between systems and modules within the system needs to be encrypted. The commonly used encryption methods are DES, AES, RSA, MD5 and so on. The encryption methods of each system are not the same (as long as the interface caller and the interface provider agree), which means that API testing needs to support a variety of automatic encryption procedures. Some systems also return encrypted response messages, which also need to be identified and decrypted.

Scenario 3: asynchronous API testing

Asynchronous API means that a synchronous response is received after the request is sent, but it is not the final processing result. The final result is obtained through callback or active query. For such an API, the verification of the synchronous response is only the first step, and then you have to continue to verify the values in the DB, the values in the MQ, and the success of the asynchronous callback. For asynchronous callback, we can simulate the callback address to verify whether it is successful or not; for active query, we have to check the status value in DB, but the time point at which the query reaches the result is uncertain, which can take from a few minutes to a few hours, so there must be a scheduled DB query task to verify.

Scenario 4: external dependencies in API testing

APIA calls APIB and B is not available, so how to test APIA needs to be considered. For example, the payment system depends on the tripartite payment channel and the bank. Not all three parties support the test environment. The core idea to solve this problem is to build MockServer and try its best to achieve versatility. We have developed a set of Mock system-aMock, which inputs interface information through the page and saves it in the database, accesses the configured Mock interface through Nginx, and processes the request information uniformly in the background. Then match the specific response information through URL and message characteristics.

3. API test platform

Our API test platform should be based on business scenarios, that is, we should support the common needs of various businesses and develop according to the individual characteristics of different businesses to enrich API testing capabilities. Moreover, we should also have a good plan for use cases, and the results should be clearly displayed. The architecture of the test platform is shown below:

BIT: business Interface Test (BusinessInterfaceTest)

SUT: system under test (SystemUnderTest)

TestCaseManagement: test case management, including the establishment and maintenance of data relationships from test cases to test case sets, to test tasks. The test case is the smallest unit, and the test case set is the set of test cases from a certain dimension. the test task is test execution, which can be triggered immediately or executed regularly, and can only execute the test case set.

Util: tool class encapsulation, mainly providing data encryption and decryption, data type conversion, configuration file reading and writing, data dictionary caching services and so on.

Validator: validation encapsulation of interface response fields and database fields.

RiskManagement: risk control processing, because it will involve the payment of real funds, the need for built-in risk control rules to ensure the safety of funds, risk control.

Timer: scheduled task service, including

State judgment of pre-use case in Series API use case

Database check of Asynchronous API

Failure state judgment of timeout API use case

A task plan that is executed regularly.

MockServer: the external system Mock service that the use case depends on.

Portal:API test platform portal, including test case input, maintenance, test task execution, result viewing, export and so on, are all operated through the portal.

DB: store test case data and corresponding test tasks, test report data, project configuration, etc.

At present, each project maintenance use case on the API test platform summarizes more than 1200, mainly regression use cases, and is still increasing. With the continuous addition of use cases, the platform has also gone through a series of optimization. Let's talk about some thoughts in this process.

Fourth, test data preparation

For the execution of a large number of API use cases, data-driven testing is required, that is, test data and test code can be separated and decoupled, which facilitates the maintenance of test data and ensures the accuracy of the data.

${accountName} ${accountNo} ${identNo}

Several key data nodes are provided by DataProvider. In order to increase test coverage, there are many similar test data in the database, such as multiple pieces of four elements (bank card number, mobile phone number, ID number, name). When a large number of use cases need to be read, they can be cached and read into cList. Through loop traversal, each test data can be read evenly. The following is a piece of code that replaces the key data node, assigning the cList data to the corresponding variables in turn.

Fifth, logical control of test execution

In many cases, testing is a situational API test, which involves the sequential invocation of use cases. As shown in the figure below, the "signing-success-kftn- protocol" depends on the execution of "sign-succeed-kftn SMS"; configure the association relationship when adding a use case.

When executing, the two items will be divided into two categories according to the attributes of the use case, which are stored in two list respectively. The use cases without preconditions can be executed immediately. For the use cases with preconditions, set TestStatus to 0, and wait for scheduled task polling to trigger execution. The classified execution code is shown in the following figure

The scheduled task is executed every minute. The following paragraph determines the execution status of the pre-API. Only "0000" indicates success, the current API can execute. When executing, the result data of the pre-use case needs to be read and passed in; if the pre-API fails, the task execution is stopped, and the sequential execution of multiple API use cases is the same. Even if there are externally dependent use cases, such as SMS CAPTCHA, we can automatically upload SMS CAPTCHA to the server by writing a mobile phone APP program, then trigger a delay to obtain the CAPTCHA, record the status and result of the use case execution through DB, and pass it to the next API, thus completing the sequential execution of multi-use cases. In addition, the execution of the test task is encapsulated into a restful interface, which can be more flexibly combined with the CICD system currently under development by the team.

VI. Verification of test results

Through the analysis of business, the result verification of API can be roughly divided into two types, response check and database check. Response verification is a check for response message fields, which can be matched accurately or by regular expression fuzzy matching. Database verification is based on scheduled tasks, and you need to set a verification method according to the agreed format in the use case, such as the sql verification condition below. In the quasi-production environment, you will query the return field by specifying the order number and other conditions, and determine whether the status is 7, so as to determine whether the use case is successful.

PreOnline.3 |, SELECTtb.outer_batch_no,tb.status,bs.send_statusFROM bs_outpay.trans_batchtbleft joinbs_outpay.es_business_sendbsontb.business_batch_no=bs.entity_uuidandbs.entity_status2 WHEREtb.outer_batch_noin (?) Order bytb.CREATED_TIMEDESC |, | {"status": "7"}

Use case state is divided into success, failure, processing, timeout four states, respectively by configuring the corresponding SQL query conditions to map, success and failure is the final state, processing is the need for timed tasks to continue to query, timeout, is a state we set internally, the current is more than an hour did not return to the final state set to timeout, this API use case invalidation and alarm, need human participation to check. All of these rules are added when the use case is created and edited, as shown in the figure below. A use case includes response verification (value check, key check) and database verification. Through this flexible design, it can basically meet the complex API test scenarios. It should be pointed out that many applications do not allow external test platforms to access the database directly. Our solution is to write a data query service that is deployed in the system environment and only provides query functions. and there is encryption verification to ensure the credibility of both sides of the communication (between the test platform and the data query service).

Generally speaking, the test platform or framework can be understood as a series of tool chains at some level. in the process of developing this platform, we use springmvc+herbinate for logic control, amazingUI for use case management, echart for result display, and Jenkins for task scheduling. Users are testers of all lines of business, who do not need to know the implementation of the specific code, but need to have a good understanding of the system structure and use case rules. Only in this way can we design a use case that matches the test scenario.

The design of any test platform should be based on business. In the follow-up, our strategy for promoting the API platform is to continue to add scene features to support testing of more business types, such as day-to-day and daytime batch tasks in the settlement system, data verification of reconciliation files, etc., to increase the concurrency capability and combine it with performance testing tools.

Author: sun Ying

Source: Yixin Institute of Technology

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.