How to use Jmeter to do interface testing? The process is really super simple.
After understanding the principle, just fill in the bits and pieces of knowledge. This article will introduce how to use Jmeter to do interface testing process, mainly for functional testing. The content of automated testing and performance testing is not involved yet.
In a nutshell, the main steps are pretty much the same.
Step 1: Extract the interface list by analyzing API documents and requirements documents.
The beginning of the interface testing staff's work is from API documents and requirements documents. So the first thing to do when you enter the company is to get API documents and requirements documents to understand, look at, and analyze. Extracting the list of interfaces from it is mainly because there are a lot of redundant and unnecessary information in the API documentation. This information may be useful for developers, but it is useless for our testers, so we need to remove redundancy and extract key information.
So how to extract it? The method is also very simple. The content in the API document is extracted from the function module and method module. The key to the extraction is the three elements of the interface: url+method+parameter+return value. The suggestion is to extract all the urls first. Basically, a url corresponds to an interface. If one line picks up the whole, the chaotic situation will become clearer.
Of course, at work, sometimes we can directly get the list of interfaces, because it is enough for a team to make a copy of the checklist, not everyone needs to make a copy. But we have to know and have the ability. I saw an interview question before, asking, if there is no API document, how to do interface testing?
In fact, the question is how to extract the interface list if there is no API document. It's very simple, it is extracted according to the requirements document and prototype diagram. Some companies are not formal, and indeed there is no API document. Or some companies' API documents are not written in a standardized manner, so when extracting them, it will test the experience and ability of the testers. So if you can find an excellent API document written in a restful style, that would be great, and it is very convenient to extract.
Step 2: For the interface list, do single interface test and associated interface test.
In the actual testing process, the time for single interface testing and associated interface testing is different, which involves business logic testing and function point testing. But when testing, their logic and methods are similar.
Of course, the main introduction here is the single interface test, because various possible situations will be considered in the single interface test, and the associated interface test is generally established on the premise that there is no problem with the single interface. From another perspective, it is equivalent to two levels, single interface test is the foundation, and associated interface test is the extension.
So what should be done? For example, here we have selected a certain interface to test.
First, build a test framework based on the selected interface.
The interface is not a big deal, it is nothing more than url, method, parameter, and return data. This means that the framework of an interface is fixed, but the data transmitted and returned each time may be different. So the first step we have to do is to build a test framework.
So how to build it? Here we will use the interface list and Jmeter sorted out from the API documentation. From the interface list, you can get the url + method + parameters + expected return data of the current interface. This is the basis for our test framework. Next, build it with Jmeter.
First you need to open Jmeter, then create a thread group based on the test plan, and create an HTTP request based on the thread group. Considering single-interface testing, a framework needs to test more than N data, and subsequent interfaces may also use the same ip address and the same content-type, so a default HTTP request is generally created first, and some possible Fill in the information that will be used repeatedly, such as port number, protocol and so on. If necessary, you need to add an HTTP information header manager, and put some user-agent, content-type and other content.
Ok, with these two foundations, you can create HTTP requests. In the new request, there is no need to fill in the port number, ip address, etc. that have already been filled in, and only need to fill in the method and the like. So where to build the framework? Generally, it will be considered in para or body. For example, if you want to submit a piece of data in json format, you need to submit it with body (message body), as shown in the figure below.
Fill in the json data obtained from the interface list into the message body data, and then parameterize the data that needs to be continuously passed in, then the test framework is built. Next, you only need to pass in the data one by one for testing.
So how to pass in the data?
In fact, we have introduced in the following article that there are four ways to import data, but the main ones are csv data set config and functions. For functional interface testing, csv is enough. So how to use it?
Create a CSV data file configuration component based on the current thread group or request. If this data is only used by this request, then it can be created based on the request. If this data will be used by multiple requests in this thread group, then it is created based on the thread group.
Do I need to fill in the file after it is created? But where are the files? At this time, it is necessary to stop the operation of jmeter for a while, and first design test cases for the current interface and form relevant documents. Regarding the use case design of functional interface testing, we will use an article to introduce it later, and I will bring it here first. This is because designing test cases is the core step in the testing process.
After the test case is designed, it can be saved in a txt file, encoded in utf-8, and saved in the same parent directory of the Jmeter script. Then set it according to the setting method in the above article. Note that the path can use a relative path, which is convenient for copying and using data files.
After the csv component is set up, the data source is available, the variable name is available, and the variable name assignment is available, and then only the reference parameters are left. In the test framework where parameters need to be quoted, the format of the reference is ${parameter name}. At this point, the test work for a certain interface is ready to be completed.
Then add the view result tree component in Jmeter, execute the request, and view the results in turn. Take a look at whether the returned data is consistent with our expected results. If it is inconsistent, it may be a bug.
To make a small summary, using jmeter to do functional interface testing is actually very simple. The logic and principle are similar. If you encounter a new project, you may say that you will use some new components, and it will take a few minutes to search on Baidu. When learning software testing, the most important thing is not to be cowardly, don't seem to say why there are so many things to learn, as long as you can pick out the clues and backbone, and then assemble some fragmentary points, you will be able to You will feel, wow, all of a sudden, so organized.
2023 latest Jmeter interface test from entry to proficiency (full set of practical project tutorials)