本文讨论的接口均是服务级的接口，不是代码级

接口是什么

在讨论为什么要做接口测试之前，我们可以先稍微了解一下接口是什么？

接口可以很不准确的理解成是与资源打交道，这个资源可能是本系统的，也可能是其他系统的。

举个例子，假如我们在开发1个bug管理系统，该系统需要拿到公司的所有开发和测试人员的信息，这样开发和测试人员不用注册都可以登录进去了，这应该很好理解。

那么这些人员的信息储存在哪里呢？一般存储在hr系统里。现在的需求更加明确了，我们要到hr系统中去拿到人员信息，获取hr系统中的人员资源。

怎么拿呢？很多种方式，可以直接把hr系统的数据库拷贝一份放到bug管理系统里，不过这样不好，因为数据的同步会有点麻烦；还可以直接连hr系统的数据库去查，这样也不太好，这样我们就需要了解hr系统的数据存储结构和逻辑，一旦hr系统的数据字段发生改变，bug管理系统也要去该，以便同步。

比较好的做法是，hr系统暴露一些接口，通过这些接口去获取人员信息资源，这样bug系统就不需要关心hr系统的数据存储实现了。

这些接口可能是这样的：

  • 登录的接口，提供人员的用户名和密码，去hr系统中判断该人员是否存在，如果存在验证用户名和密码，如果验证通过就返回1个token，该token就是这个人员的通行证，通过token可以登录到bug管理系统中去；
  • 获取人员信息的接口，返回该人员的职位：测试还是开发，以及用户名，昵称等信息；

综上：接口可以理解成是不同系统或模块之间资源交流方式；

接口测试实际上是黑盒测试

作为黑盒测试，基本的测试思路是通过输入和输出判断被测系统或者对象的逻辑。

获取人员的信息，我需要把人员的用户名传给hr系统接口，这样hr系统的接口会返回给我用户的一些更加具体的信息。这里的输入是用户名，输出是用户的详细信息。

为什么要做接口测试

既然是接口获取和操作资源的方式，而大部分系统和产品中，资源一般都是产品的核心，比如微信核心资源就是通讯录关系链和聊天记录等，因此资源是必测的。

另外接口中大部分的内容是数据，通过数据的对比我们能推测到系统和产品的逻辑，测接口就是测逻辑。

最后接口中的返回相对单纯，不像web页面，html代码中有太多ui的东西，ui最不稳定，变化太快，接口相对稳定一点点，但是里面的干扰信息更少，断言相对容易很多。

接口测试用例怎么写

还是3A原则：

  • A: arrange 初始化测试数据，就是造数据，这里的数据有我们输入的数据，也有目标接口所涉及的资源，比如hr系统中的用户信息，我们必须先有几条人员的详细信息才能去测获取人员信息的接口（当然只是正常的流程，我们有时候还需要清掉数据以便测试资源为空的情况）；

  • A: act 调用接口，传入输入数据；

  • A: assert 断言， 对返回的资源信息进行断言，比如获取用户信息的接口返回了用户信息之后，我们要判断返回的用户是不是我们想要的那个用户，我们获取的是李雷的信息，接口如果返回韩梅梅，那么接口的逻辑就是不对的；

 

有哪些常见

服务间的接口测试用例

服务间的接口测试实际上是黑盒测试，3A原则也适用于这种测试用例的编写

  • A: arrange 初始化测试数据，就是造数据，这里的数据有我们输入的数据，也有目标接口所涉及的资源，比如hr系统中的用户信息，我们必须先有几条人员的详细信息才能去测获取人员信息的接口（当然只是正常的流程，我们有时候还需要清掉数据以便测试资源为空的情况）；
  • A: act 调用接口，传入输入数据；
  • A: assert 断言， 对返回的资源信息进行断言，比如获取用户信息的接口返回了用户信息之后，我们要判断返回的用户是不是我们想要的那个用户，我们获取的是李雷的信息，接口如果返回韩梅梅，那么接口的逻辑就是不对的；

举个例子(python)

def test_get_task_by_id(self):
# arrange create_task_res = self.create_task('test', 'desc') new_id = create_task_res['id'] # act url_for_get_by_id = self.ip + '/api/tasks/' + str(new_id) res = requests.request("GET", url_for_get_by_id).json() # assert self.assertEqual(res['id'], new_id)

的接口

  • 携程订飞机票，飞机票的信息一般都是通过各大航空公司的接口拿到的；

  • 淘宝的物流信息，一般淘宝的物流信息都是通过各个物流公司的接口拿到的；

  • 第三方微博客户端，个人用户的微博等信息都是通过微博的接口拿到的；

常见的接口测试工具

  • postman： 推荐。基本功能免费。最简单的基于http接口的调试和测试工具;
  • jmeter：后置处理器配合断言基本上可以满足接口测试需求，就是测试报告要做二次开发
  • 自己撸代码：推荐。配合类似xunit测试框架，基本可以满足一切需求；
  • soapui: 收费的；
  • insomnia：强力推荐。postman的弱化版，基本功能免费，重要的是工具代码开源，可以自己改；
  • paw: 强力推荐。mac上最强，淘宝买个授权好像就百把块钱；

接口测试面试题原题图片

参考答案

1

tps就是吞吐量，transaction per second。

吞吐量下降是可能因为频繁访问redis，而频繁访问redis的原因是参数过多，解决的思路很容易想到: 减少参数。

我们可以把多组参数变成json字符串之类的一个参数，从而达到信息量不减少而参数个数变少的效果。

2

对称加密: 信息交换的双方使用同一个密钥加密解密，就像是用同一把钥匙开一把锁

非对称加密

公开密钥加密（英语：Public-key cryptography），也称为非对称加密（英语：asymmetric cryptography），是密码学的一种算法，它需要两个密钥，一个是公开密钥，另一个是私有密钥；一个用作加密的时候，另一个则用作解密。使用其中一个密钥把明文加密后所得的密文，只能用相对应的另一个密钥才能解密得到原本的明文；甚至连最初用来加密的密钥也不能用作解密。由于加密和解密需要两个不同的密钥，故被称为非对称加密；不同于加密和解密都使用同一个密钥的对称加密。虽然两个密钥在数学上相关，但如果知道了其中一个，并不能凭此计算出另外一个；因此其中一个可以公开，称为公钥，任意向外发布；不公开的密钥为私钥，必须由用户自行严格秘密保管，绝不通过任何途径向任何人提供，也不会透露给要通信的另一方，即使他被信任。

基于公开密钥加密的特性，它还提供数字签名的功能，使电子文件可以得到如同在纸本文件上亲笔签署的效果。

如何测试：略

3

UI与接口测试的协同可以从下面的方向考虑

  • UI的操作实际上就是用另一种方式调用接口，那么接口有多少种参数组合就要求UI用例要构造多少种操作进行调用
  • UI操作所需要的数据可以用接口来生成
  • 接口测试可以保证数据和逻辑的准确性，UI测试需要考虑交互和界面展示的逻辑正确性
  • UI测试需要重视接口调用不成功或者接口异常情况下UI的呈现方式和用户体验
  • UI中可能会有一些状态的缓存信息（这样就不需要每次频繁调用接口去获取了），比如鉴权信息等，需要重点关注这些缓存的更新策略

4

上下游接口的数据依赖无非就是准备测试数据。

假如一个事务需要顺序调用3个接口，A B C， C依赖于AB， 而AB有数据依赖，这时候就需要准备好A和B的数据。

数据一般有两种方式生成

  • 动态方式：假如B依赖A创造的数据，那么每次执行B之前必须执行A去做数据创建

  • 静态方式：独立统一的测试数据库, ABC需要的数据都可以从库里拿到

5

依赖第三方就mock掉，可以自己写mock server

6

依赖登录态，那么每次测试该接口之前都需要调用登录的接口

如果是jwt之类的token based auth的话，每次在调用接口时提供token就可以了

7

不知道，感觉出题者的理解可能有点偏差。

8

修改的接口，也就是update的接口一般只需要传：被更新了的字段 以及 被更新实体的 主键 比如id。

这是开发常识，如果大家研究过jsonapi规格的话，可以直接套用jsonapi的设计进行阐述。

9

swagger文档可以解决这个问题。

10

看不清。

总结

题目涉及到一些开发的知识点，很正常，现在测试面试时一般也会考察一下开发基础。

总的来说题目出的一般，也不算太难，希望这些解答对大家有所帮助。