Interface testing (detailed summary)

Prologue

Speaking of interface testing, there are many examples on the Internet. After reading it, I don’t know what they are talking about. I think interface testing is so high-end. She believes that if she learns interface testing, she will be able to counterattack, reach the pinnacle of her life, and marry Bai Fumei. So after learning some development knowledge, I found that interface testing is actually just a term people play around with. Interface testing is really simple. It is just a performance of data transfer.

request model

​ Looking at the "A" line in the picture below, you can understand that the interface is a light switch. It provides you with a parameter in the interface. The value of the parameter is "on" and the other is "off".

Speaking of which, how can I make the light turn on? A lamp head is connected to two wires, one wire is connected to the live wire, and one wire is connected to the neutral wire, then the light will turn on. On the contrary, if the neutral wire and live wire are not connected, the light will go out.

​ In fact, the interface simplifies these complex operations, so that all you see is a switch, and you just need to operate this switch. When we do interface testing, we only need to test this switch to complete the task. Interface testing is that simple.

  1. When you visit " http://127.0.0.1:8080/light?opt=open ", connect the neutral line and live line, and the light will turn on.
  2. When you visit " http://127.0.0.1:8080/light?opt=close ", disconnect the neutral line and live line, and the light will go out.

Request structure

​ Seeing this, we roughly understand what interface testing is all about. Next, you need to understand how the HTTP URL is composed into an interface. As shown in the picture:

  1. A URL is an interface: the interface can be roughly divided into the following parts:

    1. Request protocol:

      • http — ordinary http request
      • https — encrypted http request, more secure data transmission
      • ftp — File transfer protocol, mainly used to transfer files
    2. Request IP: refers to the server address deployed by the system that provides the interface

    3. Request port: If you do not fill in the port, the default is 80, otherwise you need to fill in the port number

    4. Interface path: refers to the location of the interface provided by the system

    5. Interface parameters: The parameters are after the interface path. Use "?" to indicate that the path address is complete, and the rest are parameters. Use "&" to distinguish the number of parameters.

      Example:

      http://127.0.0.1:8080/light?opt=open&use=yy&pwd=123456

      If you want to operate this light and require a user password, you can add new parameters "use" and "pwd", separated by "&". You can see that this example has 3 parameters:

      • “opt”:”open”
      • “use”:”yy”
      • “pwd”:”123456”
    6. Interface HTTP parameters [hidden parameters such as invisible url]

      • http request method

        GET --- 通过请求URI得到资源
        POST --- 用于添加新的内容
        PUT --- 用于修改某个内容
        DELETE --- 删除某个内容
        CONNECT --- 用于代理进行传输,如使用SSL
        OPTIONS --- 询问可以执行哪些方法
        PATCH --- 部分文档更改
        PROPFIND (wedav) --- 查看属性
        PROPPATCH (wedav) --- 设置属性
        MKCOL (wedav) --- 创建集合(文件夹)
        COPY (wedav) --- 拷贝
        MOVE (wedav) --- 移动
        LOCK (wedav) --- 加锁
        UNLOCK (wedav) --- 解锁
        TRACE --- 用于远程诊断服务器
        HEAD --- 类似于GET, 但是不返回body信息,用于检查对象是否存在,以及得到对象的元数据
        
      • http request header

        Request headers contain a lot of useful information about the client environment and the request body. For example, the request header can declare the language used by the browser and the length of the request body. Example:

        Accept:image/gif.image/jpeg./
        Accept-Language:zh-cn
        Connection:Keep-Alive
        Host:localhost
        User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)
        Accept-Encoding:gzip,deflate.
        
      • http request body

        The request body is the body of the request, and there can be many kinds of request bodies.

        • json format
        • xml format
        • html format
        • Binary format (mostly used for images)
        • String format

​ After seeing the request structure above, you can test the interface. You only need to modify the parameters of the interface, and you can test it like a functional test. You can use the method of designing use cases for functional testing to design use cases for interface testing. Various test tools can be used to assist testing. The picture below shows the "postman" test tool.

Where will the interface request be sent?

We can take a look at how to implement such an interface using Java Servlet

package com.yy.test;

import net.sf.json.JSONObject;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.io.PrintWriter;

// 接口的名称与路径,urlPatterns中的/light,就是说在输入地址与ip后,定义的接口名字http://127.0.0.1:8080/light 
@WebServlet(name = "light", urlPatterns = "/light")
public class light extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // 获取opt的值 
        String opt = request.getParameter("opt");

        // 新建返回json的对象 
        JSONObject json = new JSONObject();

        // 判断opt有没有值 
        if (null != opt) {

            // 定义返回的请求头,类型是json,编码是utf-8 
            response.setContentType("application/json; charset=UTF-8");

            // 定义返回的对象,用它来将json输出 
            PrintWriter out = response.getWriter();

            // 判断opt的值是不是open 
            if ("open".equals(opt)) {
                json.put("msg", "开灯啦!");
                out.println(json);
            }

            // 判断opt的值是不是close 
            else if ("close".equals(opt)) {
                json.put("msg", "关灯啦!");
                out.println(json);
            }
        }
    }
}

The above code roughly does the following operations:

  1. Get the value of opt
  2. Determine the value of the obtained opt

    • If it is "open", it returns "Turn on the lights!"
    • If it is "close", it returns "Turn off the lights!"

      When you see the code above, you can find that we pass the value of opt into the interface " http://127.0.0.1:8080/light ". When you get the value you want, you can do whatever you want. Yes, right. The code on my side simply returns. When you access my "turn on the light" interface, I will directly tell you "turn on the light" (actually I didn't do anything, this is already a BUG. So. To test the interface, you need to see whether it has taken effect, that is, is the light really on?). When we do interface testing, we need to develop and provide interface documents. The most important points are:

  3. The address of the interface under test

  4. Interface parameters, and descriptions of each parameter
  5. Necessary http header and http body (http header can be customized and can be used to verify whether it is accessed by yourself)
  6. What value does the interface return and the description of each return value?
  7. What is the interface for?

Only after these are determined can the interface test be carried out. A good interface document is as follows:

A more complex interface, RESTful

A user interface can do different things through requests in the following four different ways:

  1. Get user information
  2. Create user
  3. Modify user
  4. delete users

你完全可以像“灯”的那个例子,用GET请求来传递不同的参数来实现,但是这样如果接口多了,就会很混乱,很难管理。

At this time, we need a rule:

  1. When using the "GET" method, it is only used to obtain data. If successful, http status code 200 is returned.
  2. When using the "POST" method, it is only used to create data. If successful, http status code 201 is returned.
  3. When using the "PUT" method, it is only used to modify data. If successful, http status code 203 will be returned.
  4. When using the "DELETE" method, it is only used to delete data. If successful, http status code 204 will be returned.
  5. When the request fails to be sent, http status code 400 is returned.

Such rules are called "RESTful" standards.

The picture below is the status code returned by RESTful

5. Interface testing

Once the previous steps have been clarified, interface testing is simple. It is actually just a few steps.

  1. Get the url address of the interface
  2. Check how the interface is sent
  3. Add request headers and request body
  4. Send to view the returned results and verify whether the returned results are correct

This is a normal set of procedures. I don’t need to explain any abnormal situations. For example, the parameter does not pass a value, and the value passed is incorrect. It is clearly required to use a "GET" request to send it, but it must use a "POST" request to send it. There are many abnormal situations, etc. Generally speaking, if you understand functional testing, you can think of many abnormal situations, so I won’t give examples here.

Below I take the interface of Baidu Translation as an example:

Request address: http://fanyi.baidu.com/v2transapi

Request method: POST

Request parameters:

​ from — which language

    to --- 翻译成哪国语言

    query --- 翻译都内容

​ I use Python language for interface testing. It is simpler and easier to understand to use the "requests" library to write code. If the "requests" library is not installed, you can open cmd and enter "pip install requests" to install it.

import requests

# 接口的url 
url = "http://fanyi.baidu.com/v2transapi"

# 接口的参数 
params = { 
    "from":"en", 
    "to":"zh", 
    "query": "test"
}

# 发送接口 
r = requests.request("post", url, params=params)

# 打印返回结果 
print(r.text)

# 其实到上面就已经完了,因为百度不是我自己写的接口,为了让结果看的更加清楚一点,我取来翻译的字段 
import json
d = json.loads(r.text)
print(d['liju_result']['tag'])
返回结果

['试验', '测验', '考验', '化验', '考查', '受试验', '受测验', '受考验', '测得结果']


可以试着将"query"的参数改成"student",返回结果也随之改变

import requests

url = "http://fanyi.baidu.com/v2transapi"
params = { 
    "from":"en", 
    "to":"zh", 
    "query": "student" # 我改了这里 
}

r = requests.request("post", url, params=params)

import json
d = json.loads(r.text)
print(d['liju_result']['tag'])
返回结果

['中学生', '学生', '大学生', '研究者', '学者']

Of course, if you don’t understand the code, you can also use tools to test. As long as you remember to fill in a few points, you can do the interface test. The following picture shows the test using "postman":

  1. Enter the sending method "POST"
  2. Enter the test address " http://fanyi.baidu.com/v2transapi "
  3. Enter the parameters in the red box below
  4. Click "send" to view the returned results

 Interface testing is so simple

Interface test cases

There is nothing much to say about the design of interface test cases. Just design them the same as functional tests. I use Excel to write it, mainly for the convenience of management. As long as it is written cleanly and is comfortable for people to read, it will be fine. The use case I designed is this:

  1. One module corresponds to one Excel table
  2. One interface corresponds to one sheet
  3. One row in the table corresponds to a test case
  4. At the beginning, you need to indicate the SQL required for testing. As shown below, I will create a user at the beginning and delete it when it is finished.

Such use cases are easier to manage, as shown in the figure:

So much for the entire interface test. Interface testing is actually very simple. In the eyes of functional testing, interface testing is so high-end, but it is not much more than that.

Guess you like

Origin blog.csdn.net/weixin_45925028/article/details/132825660