Table of contents
Parameter passing between interfaces
Foreword:
Interface automation is one of the important means to improve test efficiency and quality.
Why do interface automation
Compared with UI automation, interface automation has greater value.
In order to optimize the conversion path or improve the user experience, the button controls and layout of the APP/web interface will change almost every version, resulting in frequent changes in the automated code, which has no effect on reducing the workload.
Once the interface is developed, the frequency of later reconstruction/substantial modification is relatively low. Therefore, the cost-effectiveness of interface automation is still very high. For the regression of old functions in iterative versions, beta testing, and online regression can all achieve twice the result with half the effort effect.
This article does not talk about the test of a single interface in detail, let's mainly analyze how to do interface automation based on business scenarios.
where is the problem
A business scenario usually requires multiple interfaces to complete a complete business process, where each interface completes a specific functional step. For example, WeChat's process of adding friends:
There is at least one interface request in each operation step. Then we express this process in the form of an interface request, as follows:
Indicated only, not actual
If we want to complete this interface use case, what operations are required?
1) Enter the WeChat id and send a query request
2) Pass the obtained user information to the "add friend interface" and initiate a friend add request
3) Send the user information of the friend application to the send friend application interface
4) Send the consent information To become a friend message interface
5) Pass the rejection information to the rejection message interface.
In summary, there are several problems that need to be solved: test data input, interface dependency, and parameter transfer between interfaces. This is also a common problem encountered in interface test automation, and the solution can be migrated to various businesses. Next, the author will propose some specific solutions to the above problems
Tool Introduction The interface testing tool used in this article: Apifox Windows version
Postman is an interface testing tool, and its status in the industry is unquestionable. The workflow is easier to use.
Most of the functions can be completed by the visual interface + control operation. For testers who do not know code or write scripts, they can basically complete the interface automation tasks painlessly and smoothly.
Therefore, when explaining automation in this article, Apifox will be used directly. If you need to follow the article to explain and learn, you can go to the official website (www.apifox.cn) to download and register one. The software is free.
All about parameterization
The advantage of manual testing is that it is flexible and controllable, while automation relies on our pre-set steps to complete the function
Parameter passing between interfaces
Like the above-mentioned WeChat friend request example, it involves parameter transfer between multiple interfaces, and the next interface depends on a certain field in the response of the previous interface, which needs to be accurately extracted and passed over.
Solution: Extract the response data of the previous interface -- parameterize -- call the parameter for the next interface.
In this way, no matter how many times the interface runs or how the passed parameters change, the next interface can be dynamically extracted and called. The operation steps on
Apifox
are as follows : 1) In the post-step of the interface to extract parameters, use the json path expression to extract the target response field and name it, and set the variable type
2) This field will be saved in the project settings, and other interfaces in the same environment and the same project have the call permission. Run the interface in the above figure, and you can see that this field has been extracted into the variable setting.
3) In the interface request parameters that need to call this variable as a parameter, fill in the corresponding blank in the form of a parameter
Take a look at the result: send the post request, you can see in Interface>Run>Actual Request tab>Request URL, the parameter has been successfully called
Test Data Parameterization
-
Some test data (such as login account password, user information, etc.) using variables will be called repeatedly in different interfaces. At this time, the test data can be parameterized. Different from the interface response parameters, the response parameters are obtained from the previous Interface, and the test parameters are written directly into the variable settings.
-
The operation steps in Apifox are as follows:
-
1) Set the test data variable name and value in the global variable
-
-
2) Call the test data directly in the interface request parameters
-
-
Using test data sets When we need to upload different test data to verify whether there is an exception in the response data returned, one interface parameter requires multiple test data. Let's talk about this later in the part of test management.
test assertion
Since it is an automated test, we cannot manually verify whether the returned responses meet our requirements one by one, so we need to use scripts/function settings to complete these tasks for humans. We mainly check:
1) Whether the interface request is successful, that is, whether the returned code meets expectations
2) Whether the key fields and key values in the returned interface data meet expectations
On Apifox, basic assertion operations can be set directly through interface operations:
- Select assertion in interface management - post operation
-
- After the request is sent, if the return value meets expectations, it will prompt that the assertion succeeds at the return point, and an error prompt will be given if it fails.
-
If you need to flexibly set the assertion, you can use the custom script function in the post-operation in apifox, which also provides the code template function, and the tester only needs to modify the expected value.
For a single interface, the automated preparatory work is to parameterize the input data and the parameter transfer between the interfaces, not to be hard-coded, to modify and maintain the data in the later stage, and to use test assertions instead of manually checking the interface test results.
After completing this part of the work, we can then organize different interfaces into an interface automation use case to complete the test of a business scenario.
We will complete the next work in the test management tab of Apifox.
test management
Import test cases
Interface use cases need to be generated when testing a single interface, which is the preparation work that needs to be completed before importing test cases. When testing a single interface, choose to save as a test case to generate a test case.
In the test management tab, create a new test case > import interface use case > select the use case required for the test scenario > select binding by default > confirm the import
The use case after importing is as follows. An interface request is an operation step, and several steps work together to complete the test of a scenario.
Interface Execution Order
In the above use case, the steps of the interface request are from top to bottom. If you want to adjust the running order of the interface, just drag the interface to the target position. If you need to add other interface requests, select Add Step.
Use the test dataset
In the above test data parameterization section, it was mentioned that an interface needs multiple pieces of test data. It is more convenient to get it here because the function module is just right here. On the right side of Test Management>Use Case, you can see the test data function
Click Manage Data to enter the test data tab management to add external test data.
Then on the test step > settings page, modify the test data to the variable name of the test data set
When clicking the run button below, an interface will pop up for the tester to select the test data set to be used, and each test data set will be run as a test case.
Correspondingly, multiple test results will be generated:
In addition to being able to fill in directly, you can also import external CSV files, which is more suitable for testing scenarios with large amounts of data.
Test parameter configuration
On the right side of the use case, there are configurations such as the running environment and saving variable values, which can be selected according to the actual needs of the project. Among them, [interval pause] and [use global cookie] are frequently used in interface testing.
Running Results & Test Report
Click the [Run] button, and if the run is successful, it will jump to the run result page. Test reports can also be exported.
test suite
The interface use cases of the same module can be combined into a test suite to run. On the test suite page, add a single interface use case directly, and the other operation steps are the same as above. Click Run to run the added use cases in sequence.
As someone who has been here, I also hope that you will avoid some detours. Here I will share with you some necessities on the way forward for automated testing, hoping to help you. (WEB automated testing, app automated testing, interface automated testing, continuous integration, automated test development, big factory interview questions, resume templates, etc.), I believe it can make you better progress!
http://qm.qq.com/cgi-bin/qm/qr?_wv=1027&k=GlobQko2NS5bQu3wyjjJHcr4B9Vib3pp&authKey=2wt3S40B0Wtk%2BmHrtsk9Nj1MLWr7ipmS7cjW 3fAszz%2F11J8wOREcgAJDvHBM6TYa&noverify=0&group_code=574737577
