如何进行接口测试

1.接口测试的重要性

1. 接口测试直接测试后端服务，更加接近服务器上运行的代码的程序，也更能发现影响范围更广的bug。
2. 更容易与其它自动化系统结合
3. 可以更早开始，测试界面测试无法测试的范围

2.接口测试概念（是什么）

1. 接口是有特定输入和特定输出的一套逻辑处理单元，不用知道自身内部的实现逻辑。本质：开发前期约定接口接收什么数据，处理完成后，它又返回什么数据。模拟调用方，通过接口通信来检测被测接口的正确性和容错性。
2. 分类

1. 内部接口
2. 外部接口

3.如何开始接口测试（没有完善的接口文档和产品文档）

1. 借助fiddler等工具抓取接口信息
2. 分析问题，并整理自己的接口文档

A.查看request和response，关注以下属性：

HOST，它表示指定访问的服务器域名；

Connection 的值为 keep-alive，这表示需要持久连接；

Accept，它表示客户端可以接受的内容类型为 application/json, text/plain, / ；

User-Agent，它说明请求是从什么浏览器发出去的；

Sec-Fetch-Site 和 Sec-Fetch-Mode，它们是 JS 中对跨域的一些设置；

Accept-Encoding 设置为 gzip、deflate、br，这表示可以支持的 Web 服务器返回内

容压缩编码类型；

Accept-Language，它表示接受的语言。

1. 记录cookie中字段
2. 记录response中的参数
3. 询问解惑
4. 参数来源

中文语义、参数的赋值从哪里来，是从其它页面返回值中得到的？还是js生成的？还是其它页面或接口返回的？是哪一个接口返回的哪一个字段？

     5.参数作用域

这个参数在这个接口中是做什么用的，它在哪个访问周期一直存在，是否导致业务逻辑分支？比如，这个参数是用来验证用户权限吗，验证的算法是什么？

     6.返回值的含义

每一个返回值的含义。

     7.单接口测试

保障单个接口的正确和健壮，完成全部异常状态的覆盖。

     8.业务流程接口测试

通过单个接口测试完成多个接口的业务逻辑串联，站在业务逻辑的角度完成业务逻辑的正确性检测。关心业务流和数据流的关系。

      9.持续集成测试

 将postman中的脚本导出，push到本地的Git仓库中，持续集成平台通过pull对应的接口测试脚本，然后通过newman执行。

4.搭建测试框架

测试框架就是在测试脚本中不断抽象和封装得来的。把流程化的测试脚本，一步步抽象成自己的测试框架。借助postman生成脚本，然后改写成自己的框架。

5.测试未知新协议接口

1. 了解协议是如何传输数据，又如何返回数据库。向开发拿到客户端代码查看并利用。
2. 利用自己属性的工具，方法寻求解决办法。
3. 融入自己的测试框架。比如websockt协议、resful协议

6. Mock服务

Mock服务框架，比如moco（易上手）

7.接口测试经常遇到的 bug 和问题

如下：

（1）传入参数处理不当，导致程序 crash

（2）类型溢出，导致数据读出和写入不一致

（3）因对象权限未进行校验，可以访问其他用户敏感信息

（4）状态处理不当，导致逻辑出现错乱

（5）逻辑校验不完善，可利用漏洞获取非正当利益等

8.接口测试用例设计

接口测试的用例设计，主要从输入和接口处理两方面考虑：

8.1针对输入，可按照参数类型进行设计

1.数值型

数值型的参数主要考虑以下几个方面设计：

如果参数规定了值的范围，则需要考虑等价类取值范围内、取值范围外，取值的边界，如有需要，可能会遍历取值范围内的各个值。

例如检查权限的接口：TaskChecker.checkTask(int taskID) taskID 的取值范围是 1-35，那么设计时考虑：

1-35 范围内和范围外的值

1-35 的边界：0，1,35,36；

类型的特殊值：-1,0

数据类型的边界值：int 的最小值最大值

因为 1-35 代码的权限 ID 不同，可能需要遍历 1-35 的每个值

常见问题和风险：

特殊值处理不当导致程序异常退出；

类型边界溢出

取值范围外值未返回正确的错误信息等

 2.字符型

字符串型的参数，主要考虑字符串的长度和内容：

例如接口转换设置闹钟的接口 DateUtil.getDayOfDDHH(String ddhh)，用例可以考虑：

长度为 4 位，比 4 位少，比 4 位多；

边界值：String 的最大长度；

特殊值：空字符

字符串内容可考虑类型：数字，非数字；

特殊字符

如果是输入用户输入且其他用户可见的内容，则还需要考虑敏感字是否被正常过滤。可能出现的问题和风险

传入非特定类型程序异常退出

超长字符未进行处理，导致存储、显示等异常

其他用户可见设置的敏感字

3.数组或链表

参数类型为数组或链表时，用例可以考虑：

例如批量提交任务的接口 submitTask(int[] taskID)，参数用例设计考虑：

正常取值：1-5 个权限，范围外：6 个权限；

边界值：1-35 的边界值，请求允许最大最小值；

特殊值：0 个；

合法 ID和不合法的；

重复的 ID 等。

可能存在的问题和风险：

0 个 item 时程序异常退出；

重复的 item 处理时未去重导致结果异常等。

8.2针对接口处理，可按照逻辑进行用例设计

1.约束条件

1. 数值限制：分数限制、金币限制、等级限制等等。
2. 例如：兑换 Q 币活动要求积分>50 才可参与。
3. 状态限制：登录状态等。
4. 例如：同步用户信息需要先登录账号。
5. 关系限制：绑定的关系，好友关系等。
6. 例如：帮家人防骗功能只能查询绑定家人的来电信息。
7. 权限限制：管理员等。
8. 约束条件的测试在功能测试中经常遇到，在接口测试中更为重要。它的意义在于：用户进行操作时，在该操作的前端可以已经进行了约束条件的限制，故用户无法直接触发请求该接口。但是实际上，如果有其他手段：例如 UI 有 bug 或者通过技术手段直接调用接口，那么接口是否针对这些条件进行了限制就尤为重要。
9. 例如常见的例子：要兑换 5Q 币需要 200 积分，但是我积分不足，所以兑换按钮是灰色无法点击的状态：
10. 正常用户是无法操作的，但是兑换其实是调后台的一个接口，如果绕过页面按钮的限制，直接调用后台接口兑换呢？是否可以兑换？预期当然是不能兑换的。因此积分这个数值限制就需要针对接口进行测试，并且非常重要。

2.操作对象

操作通常是针对对象的，例如用户绑定电话号码，电话号码就是操作对象，而这个电话号码的话费、流量也是对象。

对象分析主要是针对合法和不合法对象进行操作。例如下述用例子:

用户 A 查询电话 P1 话费

用户 A 查询电话 P1 流量

用户 A 查询电话 P2 话费

用户 A 查询电话 P2 流量

后台的逻辑处理，如果一个电话已经被绑定过，从后台的角度是可以查询到该电话的话费和流量的。但是在用户侧，应该是 A 绑定了的电话，才能让 A 查询到该电话的话费。故类似对象的测试也必不可少。

常见的问题和风险：

用户可访问非权限内的其他用户信息、敏感信息，从而利用这些信息谋取利益。

3.状态转换分析

被测逻辑可以抽象成状态机，各个状态之间根据功能逻辑从一个状态切换到另一个状态。如果我们打乱了这个次序，从一个状态切换到另一个不在它下一状态集中的状态，那么逻辑将会打乱，就会出现逻辑问题。

如上图所示，从某状态改变到新的状态，依赖于转换接口。而对于某转换接口，其输入状态是确定的，比如 Fun23, 这个函数只能把状态 2 转换为状态 3，而不能把状态 1 转换为状态 3。

那么测试点就可以是：

（1）状态为状态 2，调用接口 Fun23（），状态切换到状态 23；

（2）状态为 1,3 等，调用接口 Fun23（），状态不能切换。

例如在做任务的时候，任务有三种状态：未领取，已领取未提交，已完成三种状态。

8.3针对输出，可根据结果进行分析设计

9.cookie与session的区别

1、cookie数据存放在客户的浏览器上，session数据放在服务器上

2、cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗考虑到安全应当使用session

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用cookie

4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie

5、所以个人建议：

将登陆信息等重要信息存放为session

其他信息如果需要保留，可以放在cookie中

10.如何模拟弱网测试

fiddler和charles都可以模拟弱网测试，平常说的模拟丢包，也是模拟弱网测试