I. Overview of interface Testing

• Defined

Wiki definition: The interface test as part of the integration test, through the direct control API to determine the functional, reliability, performance and security of the system. The API test is not interface-executed at the communication layer. API testing plays an important role in automated testing because APIs are typically the primary interface for application logic, and GUI testing is difficult to maintain in agile development and in fast iterations and frequent changes in DevOps.

• Classification

Interface testing is a test of the interface between components of a test system. Interface testing is primarily used to detect the interaction points between external systems and systems, as well as within each subsystem. The focus of testing is to examine the exchange of data, the transfer and control of management processes, and the mutual logical dependencies between systems. Interface testing is broadly divided into two categories: module interface testing and web interface testing.

• Module Interface Test

Module interface testing is the basis of unit testing. It mainly tests the call and return of the module. It is often necessary to write some pile modules and drive modules.
The main test points are as follows:
Check that the data returned by the interface is consistent with the expected results.
Check the fault tolerance of the interface, if it can be handled if the type of the data passed is wrong.
The boundary value of the interface parameter. For example, if the passed parameter is large enough or negative, the interface can be handled normally.
The performance of the interface, the time the interface processes the data is also a method of testing. The internal algorithm and code optimization are involved.
Security of the interface

• Web Interface Testing

Web interface testing can be divided into two categories: Server interface testing and external interface testing.
Server interface Test: Is the interface between the test browser and the server. User input data is input to the front-end page, how to transfer the data in the background? The Get and post requests for the HTTP protocol are implemented to achieve data transfer at the front and back ends. This can also be considered an interface test.
External interface Testing: This is a typical example of third-party payments, such as in our application, when the charge is charged, the third-party payment interface will be called.
The main test points are as follows:
The request is correct, the default request succeeds 200, and if the request error can return 404, 500, and so on.
Check the correctness and format of the returned data; JSON is a very common format.
The security of the interface, the general web will not be exposed to any online call, need to make some restrictions, such as authentication or authentication.
The performance of the interface, which directly affects the user experience.
Interface Test Tools
SOAPUI
Jmeter
Grinder
Suds Python
The main application of SOAPUI and JMeter in the work. SOAPUI has better support for interface security testing. This article is mainly about the use of JMeter, the focus is on functional testing, for its strengths performance testing, described in a future article.
Test Case design and principles
Because the interfaces tested in the actual work are based on the HTTP protocol, the following test cases and principles are also for such interfaces.
Test Cases
Positive test Cases:

Overwrite all required parameters

Combining optional parameters

Parameter boundary value

If the value range of the parameter is an enumeration variable, all enumerated values need to be overwritten

You should also consider the actual business application scenario to design the combination of input parameters. (These use cases can be used to test functionality as smoke use cases.) It can also be used in the future to simulate actual business scenarios for stress testing, but be careful to ensure the independence of use cases, because stress testing is multithreaded. For example, we test account creation interface, name is not heavy, when writing a test case, the name can be assigned to a time stamp, so that the use case in multi-threaded concurrency test is not a problem)
Negative test Cases:

Empty data

Contains special characters

Data out of bounds

The wrong data
Verification point:

Status code (under normal circumstances, all requests should return 200)

Response Information data structure (most of the time, the return information is JSON, we should verify the corresponding structure when the data information changes)

Verify the type of node

Verify the value of the node (mainly for fixed values or values following certain rules, we can know the expected result)

For lists, you should also verify that the length of the list is consistent with the expected value based on the request parameters.

Negative test cases, you should verify that error info matches the actual

• Testing principles

Tests should be self-contained, readable, variable, and maintainable, which is the principle that all automated tests should follow.
Each test case is independent
Test cases are repeatable (this means that some test data cannot be written to death, and different environmental data may be different.) In the actual work, the solution has two: self-created the required data, such as you want to test the interface requires input parameter AccountId, you can call the Create account API, and then from the response value to get AccountId, when you test the interface you want to measure, Then delete the new account, which means a test case is divided by three steps. Another way is to read the database, from the database to obtain data, this method in the test development and test environment is OK, but if the line of the environment is more difficult, because we can not arbitrarily update the above data, and can not put too much test data on it. So I personally prefer the first method, although increase the workload of development cases, but once and for all)

Testing can be run in different environments (the normal test environment will be at least divided dev/test/staging/online, we in the test process, we should put the domain name, Token/apikey, etc. should be placed in a variable, when switching environment, we only need to change the value of the variable can be

Test data is decoupled from the business (test data includes parameter interface data/system data required for test execution)

Try to unify common test environment variables

After the test is complete, delete the unnecessary test data.

I. Overview of interface Testing