前两篇文章我们讲了接口测试能力的重要性和如何提高我们的接口测试能力。本篇我们讲一讲设计接口测试时会用到的技巧。
在 测试那些事儿（十一）- 接口测试（中） 文章后半部分，我们使用购物车的例子讲了下怎么进行闭环的接口测试。但是真实做测试的时候我们会发现一些细节并不像说的那么简单，这里就需要一些思维、技术、甚至沟通的技巧和工具来辅助我们。
一直以来我总结的一些接口测试用例设计时会遇到的问题及解决思路，罗列如下：
1. 有些接口需要签名信息，这些签名信息里面是有时间戳等动态验证信息，固定生成一个只能单独的测试一次，不能实现自动化怎么办？
回答这个问题，首先需要明确的就是这种信息的规则。因为无论是前端还是后端开发希望接入这个接口，那也一定是需要按照这个规则来进行生成的。接口文档中基本上都会包含这些规则，测试人员需要的其实就是读懂接口文档的能力、基础的编码能力和工具适配规则脚本的能力。
下面的例子是我们在jmeter的Beanshell中生成的一个签名信息，有了它，接下来的接口只要使用 signStr 作为参数就可以了：
import sign.*;
String userID = "3100000";
String userName = "小红";
String protocolStr = "#XXXX@XXX%";
Map map_parameters = new HashMap();
map_parameters.put("roomId", "xxxx-xxxx-xxxx-xxxx");
map_parameters.put("userId", userID);
map_parameters.put("userName", userName);
String signStr = Sign.generateHash(map_parameters, protocolStr);
vars.put("signStr", signStr);
2. 有些业务接口的数据无法做到绝对纯净，比如一些列表接口在测试前做不到删除干净，带着这些数据之后该怎么验证？
存在这种情况也不用着急，产生这种问题的大部分场景其实是在列表中，而列表接口的返回值基本上都是数组。所以，我们只要让 接口请求&返回值验证工具 具备校验数组中一部分数据的能力就可以了。比如，在接口测试前列表中已经有了1、2，而进行了一次增操作后，列表接口的返回值变为了1、2、3。由于我们并不关心1、2这些之前的数据，所以我们只要能够证明接口返回的数组中包含3即可。要实现这个功能，需要一定的编码能力对 接口请求&返回值验证工具进行改造。
对于这个问题，其实还有一种解决方案，就是在第一次列表请求的时候就记住列表里的返回数据，之后新变动的数据在这些原始数据上去做改动并进行验证。小编觉得这种方式有点复杂且性价比不高，所以没有采用。
3. 有些列表接口是有排序的，该怎么验证呢？
这个需要自行开发一个逻辑判断组件。这个组件可以在获取到返回值后对数组（只针对数组）中数据进行判断，按照指定排序的key来进行升序和降序的判断。
{
"result": "true",
"data": [{
"id": "XX23",
"name": "Tom",
"orderValue": "1"
}, {
"id": "XX43",
"name": "Jerry",
"orderValue": "2"
}, {
"id": "XX83",
"name": "Alam",
"orderValue": "3"
}, {
"id": "XX13",
"name": "Tim",
"orderValue": "4"
}]
}
比如这个返回值结构是根据"orderValue"来升序排列的，那我们的接口测试逻辑判断组件就可以按照指定数组中的这个orderValue作为key来判断它的value的排序规则是否满足需求定义。
4. 有些接口的请求参数依托的是上一个接口的返回值中数组的值，而数组中数据很多，我怎么拿到我需要的那个值呢？
这个问题其实是对于接口返回值提取器的功能加强。我们可以采用根据找到数组中特定key的值来查找它所在项的其他key的值的思路来做开发。
{
"result": "true",
"data": [{
"id": "XX23",
"name": "Tom",
"orderValue": "1"
}, {
"id": "XX43",
"name": "Jerry",
"orderValue": "2"
}, {
"id": "XX83",
"name": "Alam",
"orderValue": "3"
}, {
"id": "XX13",
"name": "Tim",
"orderValue": "4"
}]
}
还是这个返回值结构，如果我要获取id为XX83的数据的name值，光靠一些工具提供的按照数组的index（如Array[index]）来取是不可能的。所以要依靠能够根据id=XX83这个条件取到对应记录的name值才行。
5. 有些接口不简简单单是要验证有什么，还要验证没有什么！
对哦，很重要的功能。我们的断言大部分都只能验证一个数据存在，而不能验证不存在。所以，对 接口请求&返回值验证工具进行改造来充实它吧！
6. 接口返回的所有的值都需要验证吗？
不不不，能验证的都要验证，一些参数值比如创建时间、更新时间、随机id值什么的可以不做校验。但有些随机id值会在后续接口中用到，所以需要使用接口返回值提取器存储为参数，如果有必要，在后续接口中可以校验。
7. 在可测试性不足的情况下，比如有些查的接口开发没有提供，该怎么办？
可测试性的问题难就难在它不简简单单是技术能力可以解决的，还需要沟通和团队配合。如果本次服务端没有提供查询接口，那我们也需要问一下接下来能够提供查询接口的时间，当然最好的是能够提供并实现接口测试的闭环，这样对于开发和测试都有利，因为可以在持续集成下很好的保证接口级回归，有问题可以及时发现。如果不行，也有其他的方法 - 结合数据库操作、消息中间件模拟、redis操作等弥补可测试性，但是需要测试开发人员的努力来支持这些组件。
测试人需关注
除了要具备接口测试能力，还要有解决接口测试中痛点的能力。痛点就是需求，其实上面所说的几点都是在做接口测试时遇到的拦路虎，但大都已经通过 实践+思考+技术 的方式解决了，才慢慢形成了适合我们团队的接口测试框架。最后再重复一下那句话，千万不要为了做自动化而做自动化，不要忘了测试的目的
