接口测试的一些知识

一、接口的种类

• 系统内部的接口：系统内部的方法和方法，模块和模块之间的交互。系统内部调用，不暴露在外
• 系统对外的接口：系统如果想要提供资源给外界（或者外界想获取系统的资源），肯定不是直接给数据库给对方，而是写好一个方法，然后暴露出一个对外地址。这样外界就能通过这个地址去调用这个方法，从而获得所想要的资源（这里的获取，也可以说是操作，对应数据库的CRUD）

二、常用的接口（也称为API）

• http/https接口：使用的是http协议，通过路径/地址来区分所要调用的方法，请求报文是键值对形式，返回报文一般是json，常用的请求方法有get、post等方法
• webService接口：使用的是soap协议，请求报文和返回报文都是xml格式，一般用于多应用系统的复杂机构中，或者是不同技术平台之间的数据交互
• 两个协议的接口测试，都可以通过jmeter、loadrunner来进行，当然，自己写代码实现也行

三、接口的组成

• 见之前写的文章中的“示例”：https://www.jianshu.com/p/74177c44303c

四、接口测试的优点

• 降低修复成本：bug发现越晚，修复成本越高。而接口测试能比功能测试更早发现bug
• 缩短产品周期：提前发现bug，提前修复bug，在功能阶段的bug就会减少，从而缩短整个产品的周期
• 发现更底层的问题：对于一些参数的校验，可能前端进行了检验处理，但是后端并没有
• 测试的持续集成：接口测试可以为项目稳定后的自动化测试提供前提条件，能够降低自动化测试阶段的测试用例准备时间

五、接口测试的关注点

黑盒测试是把整个系统当成一个黑盒，只关注输入和输出，不关注内部实现。同理，接口测试就是把接口当成一个黑盒，只关注输入（请求参数）和输出（响应数据），不需要了解接口内部的具体逻辑实现

六、接口测试必备知识点

• http协议和https协议的不同
• http协议的常用的方法：GET、POST的作用以及区别
• http协议的状态码及其意义

七、接口测试用例参考模板

模板1
模板2

八、接口测试用例的设计思路

1、通用设计思路

• 正常情况验证
  按照接口文档上所写的参数的正常情况，正常传入数值，看响应信息是否正确

• 参数逻辑组合
  比如说有个操作商品的接口， 有一个字段type，type=add代表添加商品，type=delete代表删除商品。其中type=delete时，商品id是必传字段；这样的话，就需要测试type和商品id的组合情况

• 绕过验证的情况
  1.绕过逻辑验证：比如说提交订单接口，把订单总价格改成负数或者错误数值，看后端是否做了负数验以及价格对比判断
  2.绕过身份验证：比如说推广员才能进行拉人，那么使用非推广员身份去调用拉人接口，看是否做了身份验证
  3.更多情况...

• 异常情况
  不遵循接口文档的正常要求进行参数的输入，大体可归类为四种：必填、非必填、参数长度、参数类型。
  比如：不符合规定类型的值、超出长度限制的值、空、空字符串、不符合所要求的字段的值、必填参数不填写、非必填字段不填写or填写等多种情况。

2、根据业务逻辑来设计

根据所测试的系统的业务逻辑来进行用例设计，在设计之前，需要对业务逻辑了解。其设计思维和功能测试差不多，所使用的设计测试用例的方法也是常用的那几种：等价类、边界值、场景法、错误推测、因果图、判定表等。

• 例子
  1.推广员推广一个成功办卡并首刷的用户，可获得100块奖励
  2.助力活动，一个用户一天最多助力3次
  3.组团活动，一个用户最多能组1个团
  ...
  然后根据这些业务逻辑，找测试点，设计测试用例，调用接口，查看响应数据

九、用什么工具测试

理论上说，只要能够发送请求，查看响应的工具都可以进行。但是方便好用的工具，能够提高测试效率以及降低维护成本，个人建议使用：jmeter、postman。如果满足不了需求，则可以写脚本。
工具只是用来提高工作效率的，不要被工具所束缚住，了解本质和解决问题的思维更重要。学习一个工具的使用，只是百度的功夫。

十、一些注意点

1.使用jmeter进行post请求传递json参数时，请求头需设置Content-Type:application/json
2.jmeter中，请求头设置charset:utf-8是不起作用的，具体体现于如果传递中文参数，保存到数据库的数据会出现乱码情况。解决方法：在“HTTP请求”页面右边的Content encoding中输入所需的编码，一般是utf-8
3.接口测试只对接口负责，也就是只对接口的响应信息负责。除非真的必要，无需去看mysql/es