API, namely: Application Programming Interface, is an agreement for the connection of different components of a software system. Due to the increasing scale of software in recent years, it is often necessary to divide complex systems into small components. The design of programming interfaces is very important.
In the practice of programming, the design of programming interface must first reasonably divide the responsibilities of the software system. Good interface design can reduce the interdependence of various parts of the system, improve the cohesion of the constituent units, and reduce the degree of coupling between the constituent units, thereby improving the maintainability and scalability of the system.
API testing is to verify all aspects of the API provided by the system. API performance and security testing will be an optional test item depending on the testing strategy. This can be discussed as two separate issues.
API function testing is similar to UI function testing. It uses this function/calls this API and verifies whether the expected result can be returned under the premise that the input content and expected result are known. The difference is that the API test is completed before the return result is presented to the customer, so the dependence on the test environment will be relatively small.
Remember the test pyramid that you learned in class?
Simply put, the higher the test, the higher the investment cost and the harder it will be to maintain. Under this structure, because UT has covered most of the code, the upper-level integration/API testing and UI testing can remove the part of repeated testing, so the amount will become less and less, and there will be a good coverage .
So the ideal automated test structure should be: a large number of UT + appropriate integration testing (or API testing) + a small amount of UI testing.
☞ Test coverage. The focus of UT is whether each unit can complete the desired work, and only covers the internal work of one unit; the focus of integration/API testing is the collaborative work between modules/units, and it will cover more scenarios than unit testing. The UI test will pay more attention to e2e, simulate user behavior, and perform operations after all program-dependent environment preparations are completed. In contrast, API testing does not depend on the environment, the testing cost will be lower than UI testing, and the coverage rate is higher than UT.
☞ Quick feedback. API testing is faster than UI testing (because no interface loading/response is required), and many use cases can be run in a short time. API testing can also accurately reveal which components in the software are in addition to the problem. If you put your API testing in CI, once the code modification breaks the existing function, it can be quickly fed back to the team. You can also write the BUG found in the test into the API test, making the test a wall, which can better guarantee the product quality.
☞ Can be reused. API testing does not require browsers, GUIs and other environments, so it can be reused in various environments more flexibly. For example, you can use it in a production environment, a test environment, and a research and development environment. All you need to do is to modify the test data. In addition, if you are working in TDD mode, the API test may be written before the product is completed, and subsequent work will be reduced a lot.
The main method of API function testing is to use tools/software to call the API to be tested, and then verify whether the expected output is returned. This output may usually be:
♡ Return success or failure status
♡ is a piece of data or information
♡ Or jump to other API
tool
The common API testing tools on the market I know can be divided into several categories:
Open source pure code classes, such as nodeJS-based supertest; Java-based rest-assured, etc. Such tools are easy to learn and easy to integrate with CI, but require users to have a certain coding ability. Commercial tools, such as SoapUI, are powerful and easy to operate. Free community offices are also available for trial. Various plug-in tools, such as Chrome plug-in Postman, are also available in paid versions. Different people have different opinions on the choice of tools, and different tools are selected according to different environments.
test
Before officially starting the test, you have to figure out a few questions:
What is the purpose of the API to be tested? Who are the users?
In what environment will the API to be tested be used?
Will the API under test have unexpected responses under abnormal circumstances?
What function points need to be tested for this test?
The test priority of each function point?
How to define whether the expected result is success or failure?
Will the API to be tested interact with other systems (other systems will be affected after the code is modified)?
These problems will affect whether your test results meet customer needs, or these potential risks will affect the success of this project. If you choose a tool that has to write some code yourself, then you have to set up the test environment according to the selected tool and project code, so that the tool can run successfully.
Design test framework
Next is to design your test framework. It is best to meet the principles of strong reusability, high cohesion and low cohesion, and remember to have a module that outputs test reports.
example
You have already figured out which function points need to be tested above. For these points, we use tools such as brain maps to record the scenes that need to be tested.
script
Followed by script design and test data design. Scripts and data should be separated, so that you can reuse test scripts and use different test data inputs to obtain different expected results.
verification
The verification process roughly includes the following:
Check whether the API returns the expected result based on the data you input; verify that the API does not return results or return abnormal results; verify that the API triggers other evens correctly; whether the API is correctly adjusted; or verify that the API is updated correctly Data and so on.
Finally, it is strongly recommended to integrate testing into CI to accelerate abnormal feedback and create a strong quality system.