When we usually do interface testing, we should be very familiar with the use of some common interface testing tools:

  • Interface documents: Swagger, Yapi

  • Interface tests: Postman, Postwoman

  • Mock: EasyMock, Mockito, mock.js

  • Performance tests: Jmeter, Locust

…

Does it hurt to have to install so much software on your computer to do interface testing?

I just don’t want to install so much software. Is there an interface testing software that integrates all of the above functions into one piece?

There is.

Today I recommend a crazy API testing tool: Apifox.

If you don’t understand it, you don’t know how ambitious it is. If you don’t use it, you won’t know how good it tastes!

Let’s cut the crap and get straight to the point.

Directory:

Apifox profile

The basic use

conclusion

Brief introduction of Apifox

The official introduction:

Postman + Swagger + Mock + JMeter Apifox is a full-process integration tool for interface management, development, and testing.

It solves the data synchronization problem among multiple systems by using one set of systems and one piece of data. Once the interface documentation is defined, interface debugging, data Mock, and interface testing can be used directly without needing to be defined again. The interface documentation and interface development and debugging use the same tool, after the interface debugging can ensure that the definition of the interface documentation is completely consistent. Efficient, timely and accurate!

[Operating environment]

  • Windows

  • Mac

  • Linux

【 Official website 】

www.apifox.cn/

[Official document]

www.apifox.cn/help/

Top 10 core features of Apifox

As you can see, Apifox already meets most of your daily interface testing needs.

In my opinion, some useful features are:

Interface documentation, team collaboration, data import/export, continuous integration of CI/CD.

Two, basic use

Apifox page looks like Postman, Postman should have functions, Apifox also, so you can completely use it as Postman.

Interface environment isolation Settings

Request to construct

All of these features are fairly simple, and if you’ve ever used Postman, you should be able to get started.

Here are some useful tips for Apifox.

2.1 Quick construct request

When we manually enter the request, we need to fill in many parameters, including:

  • Request method

  • URL

  • Header

  • Params

  • Body

.

And so on.

Is there a fast way to generate interface requests quickly?

There is.

We can use Apifox’s import capture request to quickly generate interface requests.

Step 1: Open Charles, right-click the target interface, and “Copy cURL Request”

Step 2: Import captured packet data in Apifox

Two simple steps will quickly help us generate interface requests.

2.2 Generating Interface Documents

In the project Overview, you can generate online interface documentation.

The resulting online interface documentation is still pretty good, which is a great boon for teams that don’t like to maintain interface documentation.

2.3 Perform automated tests

We can take recorded use cases, extract and perform simple automated tests, and even control the number of threads, loops, and so on.

(Isn’t that Jmeter?)

After the test is completed, it can also generate a more intuitive test report

2.4 Automatic code generation

Apifox even supports automatic generation of business code!

Support for many programming languages. (common Java/PHP/Go/Python/C# support)

I tried to generate a Java business code (Spring) and open it with IDEA.

In general, exported business code has all kinds of weird problems, and we don’t use this automatic code generation function directly when we write business code.

Still, it looks pretty cool, doesn’t it?

Third, summary

This article is only a brief introduction to the basic use of Apifox client, but Apifox has a lot of practical functions, here will not show one by one, there is a need for friends, you can go to the official website to understand.

Beyond Apifox’s introduction, let’s talk about how some free or open source test projects can be better used in daily work, and don’t reinvent the wheel.

In my work, I have met many people who, when faced with a problem, would not go to the market to research the good testing tools, just want to write code to solve their own.

However, the products are often too easy to use to be promoted in the team. Or they waste a lot of time on design, but they’re really crude and they don’t meet the needs of everyday work.

You end up writing crappy tools that don’t work, and you end up having to find third-party or open source tools to use.

Don’t reinvent the wheel if you already have a tool that works. It’s a real waste of time.