说说接口测试
越来越多的测试人开始做接口测试了，这个从大家的简历上就能看到端倪，基本上体现接口测试经验的就一句话：
但是经过面试，发现了一个本末倒置的问题，面试者往往熟练的是使用接口测试工具的能力，但是对于接口测试本身却知之甚少。无论做什么事情都有其目的，先搞清楚为什么做就不会出现跑偏。本着这个原则，我们就先来看看什么是接口测试吧。
接口测试是测试系统组件间接口的一种测试，主要用于测试系统与外部其他系统之间的接口，以及系统内部各个子模块之间的接口。测试的重点是要检查接口参数传递的正确性，接口功能实现的正确性，输出结果的正确性，以及对各种异常情况的容错处理的完整性和合理性。(来自百度百科)
定义其实很清楚了，目的就是通过一种测试方法验证 接口参数传递的正确性，接口功能实现的正确性，输出结果的正确性，以及对各种异常情况的容错处理的完整性和合理性。 接口测试和普通的功能测试一样，关心的是结果！而Jmeter或Postman只是工具而已，不能越俎代庖的成为目的。当然，如果你想说你熟练使用某一个接口测试工具实现了在接口测试上的各种提效（如自动化），那就要重点描述自动化的过程和技术实现，这才是面试官最关心的。
大部分人的接口测试
我经常在面试中会问的问题：
- 进行接口测试的流程是什么？
- 做接口测试的都关注那些？可以单从请求和返回值来说明。
- 都用过京东或者淘宝吧？能够说出和购物车功能相关的都有哪些接口吗？
- 这些接口怎么组合能形成一个购物车的接口闭环测试用例呢？
我得到的答案90%是下面这样的：
- 根据开发提供的接口文档进行测试或者开发不提供就自己抓包进行测试。（可以理解）
- 关注返回状态码是200。。。还有呢？没有了。。。
- 呃。。。不知道
- 呃。。。不知道
所以，结合之前说的接口测试的目的，大部分的接口测试连验证返回值的数据是否正确都没有做到，仅仅做到了验证接口能够调通而已！而且做的接口测试只是单接口的验证，并没有结合业务进行闭环整合。
回想一下功能测试，我们有通过产品需求来设计手工测试用例的能力，这些用例是从需求中按照功能抽离出来的，而且大部分用例是连续的。接口测试也是一样的，他们也可以从需求中抽离出来，只是不像功能测试点那么明显，而且接口测试也应该是连续的。我经常会和测试人员说一句话：如果不考虑给人看的话，其实一个功能用接口们就可以实现了。这就是为什么接口测试可以先于功能测试完成。
我希望得到的答案：
- 根据开发提供的接口文档进行测试或者开发不提供就自己抓包进行测试。（考虑到公司开发的良莠不齐，这个没问题）
- 我会根据接口文档，验证请求时不同的参数所得到的正常和异常返回值；并重点关注返回值的数据准确性和合理性。
- 购物车的相关接口会包含添加商品到购物车接口、删除购物车中商品接口、修改购物车中商品数量接口、查看购物车列表接口等（增删改查）
- 可以按照上面的四个接口来进行组合，并在每个阶段都保证数据的准确性。下面是组合顺序：
- 调用查看购物车列表接口保证购物车中商品为空
- 调用添加商品到购物车接口添加一个商品
- 调用查看购物车列表接口保证购物车中商品已添加
- 调用修改购物车中商品数量接口增加（或减少）商品数量
- 调用查看购物车列表接口保证购物车中商品已修改
- 调用删除购物车中商品接口删除商品
- 调用查看购物车列表接口保证购物车中商品为空
想要能够回答这些问题，需要进行接口测试能力的锻炼。
接口测试能力
再次强调一下，接口测试和功能测试一样，是一种基础能力。接口测试并不是什么神话，它其实就是一个普通的黑盒测试方法，只是不像功能测试那么明显罢了。
以下我们罗列下接口测试能力的拆解：
- 通过接口文档进行接口测试的能力
- 熟悉需求并根据开发提供的接口文档设计接口测试用例，可以结合需求判断出接口文档业务逻辑、各参数定义、返回值是否合理。
- 熟悉接口请求参数（url、header、body等），能够根据边界值法、等价类法等基本测试方法设计传入参数。
- 根据上面不同的传参来断言对应的返回值是否满足接口文档需求，尤其需要关注数据准确性、状态码是否正确等。
- 设计产生必要请求参数的脚本（如生成登录鉴权token等），不用每次都找开发生成。
- 通过业务功能窥探出对应接口的能力
有些时候我们拿不到接口文档或者开发提供不全怎么办？怎么能单从需求上就知道会有什么接口呢？其实并不难，只要遵循一个原则 - 数据增加、删除、修改、读取的动作大都会需要接口调用。 我们常见的前端页面包含H5页面、Web页面、客户端页面（Android、IOS），基本上只做展示逻辑，并不会进行更加复杂的操作。所以大部分的情况下，只要出现了提交、页面跳转等行为，出现了页面的数据变更时，基本上都会进行接口请求。当然，凡事都有例外，有些前端会缓存一部分数据，所以可能有些页面跳转不会进行接口请求；有些页面不会跳转但也会进行接口请求，比如购物车的商品数量增加动作（否则为什么你增加了商品就退出下次进来就能看到是变了的）。这些“非常见”的情况就要依托于业务来思考，只要多加锻炼就能形成思维定式。 - 将接口组装成业务级闭环测试用例的能力
光有测试一个接口的能力是远远不够的，因为一个功能是由很多接口构成的，只是一个接口一个接口的进行独立测试无法将功能串联起来，就像做功能测试只测试每个页面，不能不管多个页面的互相配合一样。这里也有一个简单原则来将接口测试闭环：增 - 查 - 改 - 查 - 删 - 查。
看了上面购物车例子的同学应该不难理解吧！但我要说每个功能都不同，素以我这个原则不一定适用于所有，只能说适应大部分简单的功能。但有一点要记住，所有涉及到数据变动（增、删、改）的行为，都要有查来验证，这才是正确的接口测试打开方式，否则不能算作闭环。
测试人需关注
接口测试涉及的知识还是很多的，今天我们只讲了思维部分，如何精进之后我们在聊。但是只有思维对了，才能真正的把事情做好，才不会跑偏。希望这篇文章能够让大家了解：
- 做接口测试的目的
- 如何拥有接口测试能力
还很迷茫的小伙伴可以再看下上面的文章，或者给我评论，我们一起讨论。
