preface
You are a test, and your team’s current development model is a front end separation.
One day, the version V1.0 interface was reviewed and released on Swagger, with the front and back ends being developed separately. At this point you migrate the new interface to JMeter according to the interface document, and then start writing test cases for the interface.
After a few days, the front end first tested the APP, how to test the front end effect, 💡 you think of using Charles to capture packets, create some fake data, and then change the response data. However, the interface situation is a bit heavy, and the data preparation is a bit tedious. At this point, the front end student introduced you to the Mock tool Rap, and they put the interface on it, wrote the Mock rules, and got the simulation data for the front end debugging. The data isn’t very realistic either, but the type and structure are right.
After a few days, the backend was finally tested and connected to the test server to run the interface use case. An interface error was reported and the front end opened the price page. You calmly captured packets to look at the data, check the interface document, the original is the field type returned by the back end is wrong, so you put a bug on JIRA to the back end students, and according to paste the document screenshot and captured packets screenshot.
After a while, the backend student came to tell you, “There is a change in this field, I passed the debugging in Postman, I forgot to change the document and notify you, please forward to the front end. “
The back end is very innocent, the front end is very helpless, your heart is very tired, but can only silently use examples.
After a while, you find that some of the automated use cases are not running. It turns out that the interface changes have been delayed for a long time, and there are more differences between the data and documents of the script. It seems that you need to find time to check the differences of the interface. But just a new employee, but also to give him training on the use of JMeter, it seems that this week to work overtime 😢.
Have you ever thought that all of this is because your team didn’t use an interface document management tool that handles data synchronization, debugging, mocking, and automated testing all at once? Yi, you ask me is what artifact, that I tell you 👇
What is a Apifox
Apifox is a collaborative platform for API documentation management, interface debugging, Mock functionality, and testing. Simply put, Apifox is a combination of Postman, Swagger, Mock, and JMeter. Provide r&d teams with a visual tool for Api process management out of the box.
Why Apifox
We often talk about agile development and using digital tools to manage the process of r&d projects. However, in the API management area, we are still in the front, back end, and test of their own island management situation:
- Back-end development manages the interface documentation via Swagger, and then debugs the interface via Postman
- The front-end development uses tools such as RAP to Mock the interface data
- Test through JMeter, HttpRunner and other tools to do interface automation test, stress test
In this mode, the most prominent problem is data synchronization. The data of several tools are isolated from each other, and different roles maintain one copy of interface data respectively. Because the interface changes are not synchronized in a timely manner, the connection between front and back ends fails or test cases fail frequently. Therefore, only by centralizing the interface data and collaborating on the same platform around the interface documents can the research and development efficiency be maximized. So the advantages of Apifox are obvious:
- 1. Data synchronization: the changes of interface data are automatically synchronized to use cases and mock services in real time, so that different roles no longer need to pay attention to the problem of data consistency, so as to effectively manage interface documents;
- 2. Cross-department collaboration: test cases, mock rules, public scripts and other data of the platform can be shared within the team to realize data precipitation and reduce duplication of work;
- 3. Cost reduction and efficiency improvement: Common functions (assertion, database operation, data extraction, etc.) have convenient visual operation, Xiaobai can also participate in document management and automated testing, avoid duplication of wheels, reduce r&d costs, so that R&D can focus on their own work.
At the beginning of Apifox experience
Apifox is an interface document management tool, an interface document generation tool, an interface Mock tool, an interface debug tool, and an interface test automation tool
Install the registration
Apifox is a cross-platform tool that supports macOS(Intel+M1), Linux, and Windows (32-bit and 64-bit). You can download and install the Apifox from the official website.
For the first time, you can register by email or directly log in through wechat.
Log in to Apifox, and you can see the list of teams and team projects that the current user has joined. Click the small plane Settings direct to the right of the project, and the next time you open Apifox, you can direct to the project.
Interface Document Management
We enter the pet shop project, as shown below: the left side is a tree aggregation interface list, the hierarchy is classified (multi-level classification) -> interface -> use case, all three levels support one-key replication, deletion, and the list is modified by dragging and dropping. On the right is the project overview page, where you can set up online documents to be shared with team members or partners.
Double-click the interface. The interface document page, including basic information, request parameter format, response data format, and example value, is displayed.
Click Modify Document/New Interface to edit the interface information. As shown in the figure, we can edit the interface information of login. Example values and descriptions can be edited for all fields. There are various optional drop-down forms of field types, and the interface is clear and easy to use.
Of course, Apifox’s data structures and data models are fully compliant with the JSON Schema specification, and you can edit the JSON Schema directly to define the data structures.
Online interface documentation
The interface is defined, and the online document effect is as follows
Interface debugging
Once we have the interface designed, we can debug it to see what it looks like. Take the login interface as an example. Enter the running page, edit parameter values, select the running environment, and click Run to initiate a simple request. You can view the interface response and request details at the bottom of the page.
The interface debugging content can be saved as a use case for the next debugging or test by team members.
Debugging and use cases are all about testing the correctness of the interface, and you definitely need to validate the information returned by the interface and sometimes extract information from the response for subsequent requests. At this time, we need to extract variables and assert operations, ready-made 0 coded visual steps, entry behind the operation, we extract a token from the response stored as an environment variable, and assert that the value of the city field in the response is “Guangzhou”.
Run, the system will automatically verify that the data structure of the response is consistent with the document definition, and when the assertion fails, it will prompt and print the expected and actual values.
Click on the console to see the variable token extracted successfully
The variable extracts the source and the object of the assertion not only the response JSON, but also cookies, headers, and so on, greatly improving the efficiency of writing assertions.
In addition to extraction and assertion, the front and rear interface operations also support database query, public script, and custom script, meeting the requirements of daily test scenarios, such as database query value, custom function, and so on. These operations are easy to use. Users can also test the interface in an elegant and leisurely manner
In addition to being able to write JS scripts, You can also call Java (.jar), Python (.py), PHP (.php), js (.js), BeanShell (.bsh), go (.go), shell (.sh), Ruby (.rb), lua directly (.lua) and other languages to meet the customization needs of advanced users.
The data model
Apifox documents support data models, can be managed by category, and support calls between data models
Environmental management
Each environment has its own pre-URL, environment variables, and remote values of variables can be shared within the team, while local values are stored locally and not uploaded to the cloud. When we run, selecting an environment initiates a request for that environment. Use {{variable name}} to read the environment variable value of the environment.
Global variables and global parameters are used by all environments.
A Mock function
Usually in a parallel development pattern, the front end needs to Mock the response data according to the API documentation to keep the front end call link open. The Apifox runtime Mock feature is launched locally, the interface document page can automatically generate Mock data based on the response structure, and its built-in rules enable most commonly used fields, such as profile picture, city, phone number, IP, and so on, to generate very user-friendly Mock data with zero configuration. This feature not only saves time in building mock services and writing mock rules, but also greatly improves the presentation of front end data:
In addition, it can also be based onInterface/data structure definition
,Mock Rule configuration
,Mock expected configuration
, automatically generate simulation data, and users can flexibly construct a variety of structure interface data according to the need.
The test case
When we want to test a complete process of a function, or test different cases of a single interface, we need to test multiple use cases in series. Test management – Test cases can be used to combine use cases to automate tests. To create a test case in Test Management, click the Add step to select import from the interface case or import from the interface.
Select Import from interface Use cases to import previously written interface use cases. The import mode can be replication or binding, and Binding is recommended. Test management and interface use case data synchronization are recommended. When changes occur in one place, data in the other place is automatically synchronized without manual modification.
Let’s do a simple login-check-in example and import two interface use cases – logon and check-in.
Let’s take a look at the Settings for these two use cases: The login use case sets up the post-operation to extract the token from the response and store it as a variable
Sign-in use case: Token Field Parameter Value Reads the token value extracted by the login interface for sign-in
After the import, you can adjust the use case sorting and set the number of loops and threads
Run and generate test report as follows:
Click the interface to view the request and response information of the interface. You can see that the token value returned by the login is used in the check-in request. This is an example of a simple integration test.
The test suite
A suite is a collection of test cases used to organize more complex functional tests. It is often used for interface automation tests, regression tests, and similar to test cases.
A parameterized
Stress test the interface by setting the number of loops and threads while the test case/suite is running. In the stress test, we may also need to use different parameter values for the interface. Apifox supports setting the interface parameter values as variables, and we can parameterize the use case by uploading a CSV/JSON data file. Again, in the login example, we will set the account password as variables
We create a CSV file that holds the account and password. The first line is the variable name, and the second line starts with the data
account | password |
---|---|
[email protected] | 123456 |
[email protected] | 123457 |
[email protected] | 123458 |
[email protected] | 123459 |
[email protected] | 123460 |
[email protected] | 123461 |
[email protected] | 123462 |
[email protected] | 123463 |
[email protected] | 123464 |
[email protected] | 123465 |
The CSV file is uploaded when the use case is run, and the number of cycles automatically fills the number of rows of data in the CSV
Click “Run”, the use case will be run in CSV order, as shown in the figure, to view the second interface request running, and the parameter value is the second set of data.
Continuous integration
To facilitate the integration of Jenkins and other continuous integration tools to automatically build and continuously run test cases, Apifox supports continuous integration through the command line running tool Apifox CLI. There are two methods: downloading test data and running it locally and downloading online data through commands.
On the Test Cases/Test suites page, click Continuous Integration to generate the command to run the online test cases/suites in real time through the Apifox CLI.
The running result is shown in the figure.
You can also export data in ApifoxCLI format, and use ApifoxCLI to read the exported JSON data to run test cases.
Team management
Team roles include owner, manager, and common users, who have the following permissions:
Permission to name | The owner of the | The administrator | Ordinary members |
---|---|---|---|
Modify team information | Square root | x | x |
Handed over to the team | Square root | x | x |
The dissolution of team | Square root | x | x |
View the member permission list | Square root | Square root | x |
Modifying member Permissions | Square root | Square root | x |
Invite/remove members | Square root | Square root | x |
Each member in each project can set different project permissions: administrator, common member, read-only member, and forbidden access.
The corresponding contents of different project permissions are as follows to meet the multi-level management requirements of the team.
Permission to name | The administrator | Ordinary members | A read-only member | Blocking access |
---|---|---|---|---|
Projects have been added, deleted and revised | Square root | x | x | x |
Modification of Project Information | Square root | x | x | x |
Access interface document | Square root | Square root | Square root | x |
Interfaces were added, deleted, or modified | Square root | Square root | x | x |
Interface Viewing and Debugging | Square root | Square root | Square root | x |
Add, delete and modify use cases | Square root | Square root | x | x |
Use case view and run | Square root | Square root | Square root | x |
Test suite additions and deletions | Square root | Square root | x | x |
Test suite run | Square root | Square root | Square root | x |
Data model modifications | Square root | Square root | x | x |
Data model viewing | Square root | Square root | Square root | x |
Environmental modifications | Square root | Square root | x | x |
Mock rules have been added or deleted | Square root | Square root | x | x |
Added, deleted and modified public Response | Square root | Square root | x | x |
Add, delete, and change public scripts | Square root | Square root | x | x |
Added, deleted, and modified database connections | Square root | Square root | x | x |
Custom functions added or deleted | Square root | Square root | x | x |
Changes in variables | Square root | Square root | x | x |
Variable local value setting | Square root | Square root | Square root | x |
Importing and Exporting Data | Square root | Square root | x | x |
The generated code
Apifox provides code generation based on the OpenAPI Generator — according to the interface model definition, Automatically generate business code for a variety of languages/frameworks such as TypeScript, Java, Go, Swift, ObjectiveC, Kotlin, Dart, C++, C#, Rust, etc Model, Controller, unit test code, and so on) and interface request code. Apifox currently supports automatic code generation in 130 languages and frameworks.
More importantly, you can customize code templates to generate code that conforms to your team’s architectural specifications and meets a variety of personalized needs.
conclusion
See this, this can manage the interface and can do automated testing, good looking also free interface documentation tools are not quickly used up, Fox in hand, efficiency, on time off work is not a dream ~ ps. For more detailed instructions, please visit the official documentation