default title

1. How the use case is organized

Jmeter is relatively flat, it has no concept of WorkSpace, it is directly TestPlan, and the Threads Group created under TestPlan is equivalent to TestCase, and there is no TestSuite level.

Postman is simpler in terms of functionality and lightweight, and it is mainly aimed at a single HTTP request. Collections are equivalent to projects, and you can create folders at indefinite levels in collections, and you can organize your own TestSuite. Each Request can be treated as a TestCase or Step:

2. Supported interface types and test types

In terms of functionality, Jmeter is the most powerful, it can test various types of interfaces, and those that are not supported can also be extended online or through self-written plugins.

Postman is lightweight and has different positioning, which can be used to test Rest interfaces.

3. Configure different interface types

Jmeter can add HTTP, TCP, or WebSocket samplers to the thread group.

Postman only supports REST interfaces.

4. Customize the variable and the scope of the variable

Each tool has system variables other than those listed in the table below, which are not listed.

5. Process control

Jmeter: Process control is implemented by a series of controllers such as Switch controller, If controller, random controller, etc., as well as Beanshell scripting.

Postman: Controlled via JavaScript script.

6. Assertions

Jmeter: TestPlan, Threads Group, and Sampler can all add assertions.

Postman: You can add assertions to the requested Tests.

7 Script expansion capabilities

　　Jmeter：Bean shell（Java）

　　Postman：JavaScript

8. Team collaboration

Jmeter: A TestPlan is also a jmx (xml) file and cannot be split, but Jmeter has a merge feature that allows multiple files to be merged together. Only each team member can create a TestPlan and test it in functional blocks. Finally, sort out and merge.

Postman: There is a team collaboration feature, which requires payment.