接口测试个人总结

什么是接口

首先我们来看一下接口的定义，我们可以看到如下这样一个网址：
https://www.baidu.com/s?ie=UTF-8&wd=%E6%8E%A5%E5%8F%A3%E6%B5%8B%E8%AF%95
https：请求协议，也有http，https是经过加密的http协议，更加安全。
www.baidu.com：域名，这里是.com结尾的，常见的还有.cn，.org，.net等等
这里在域名之后常见还会接一个端口号，默认是80
/s：请求路径
?后面的就是传参，而ie，wd是参数名，UTF-8和后面%E6一长串是具体参数值

测试重点

简介

其实目前我所做的接口测试，大多还是数据驱动类型的，就是修改参数从而结果会有变化。在我看来用最直白简单的说法来说，接口测试就是考虑到各个场景，然后进行参数的变化，最后和预期结果进行比对。

背景介绍

上面是一个测试金字塔模型，底层是单元测试，中间层是服务端测试，上层是UI测试，纵轴上面表示的是，越下层的测试速度是越快的，越上层的测试速度是越慢的，而花费上面，最下层成本是最低的，最上层是最高的，但这三者都是十分重要必不可少的，在底层只不过是能更早的发现问题以及更快的质量反馈，而目前单元测试基本上是开发的范畴，作为一个测试人员而言，服务端测试和UI测试技能都是必不可少的。本文主要讲的接口测试就是服务端测试中的其中之一，还有很多专项测试，例如性能测试、安全测试。

具体内容

接口文档

首先我们需要完成与接口和沟通和交互，这时候我们就要了解接口所使用的协议，然后进行用例的设计。
我们第一件需要的，就是一份完善的接口文档，接口文档现在又分为人工维护的接口文档和自动生成的接口文档，人工维护的接口文档大多需要依赖开发人员进行维护，有很大的不确定性，需要在使用前和开发进行确认。
当然可能有部分公司并没有完善的接口文档，这时候就需要测试人员直接去和开发人员沟通，或者是使用对客户端进行抓包的手段进行接口数据的了解。

数据协议

数据协议，这个一般会在接口文档里有所体现，现在常见一些的数据协议是json和xml，不过protobuf的使用也日益增多。我个人目前主要接触的是protobuf，这个数据协议还是很大程度上能够帮助我们进行测试，因为他对数据类型，数据顺序的严格限定，能够帮助测试人员节省部分校验时间。
除此之外，大多的还是以json为主，这时就要去校验一下数据类型，其实我看通用一点的json可以使用json-schema去进行统一的限定，进行快速的简单校验，至于比较特殊的就要特别照顾了。

根据接口文档设计测试用例 —— 接口关联性测试

在我们拿到了详细的接口文档之后，要根据接口文档考虑到各个业务场景，这就需要一定的测试思维和一定的业务经验。接口与接口之间是存在上下层关系依赖的，很可能一个接口的调用就会影响到很多个其他接口的响应的值的变化。这里我们可以以微信小程序的服务端API（附近的小程序）进行一个举例，如下：

这四个接口还算是比较简单就可以理解的，首先我最上层是nearbyPoi.setShowStatus，展示或取消展示附近小程序，只有打开展示才能在客户端查看到附近小程序。
而下一层是nearbyPoi.getList，查看地点列表，肯定要查询地点列表才能展示出附近小程序。
然后最下层就是nearbyPoi.add和nearbyPoi.delete，添加地点和删除地点，调用这两个接口时， 会改变上一层，'nearbyPoi,getList’接口的响应数据。那我在进行这两个接口测试时，肯定也要看一下上层接口nearbyPoi.getlist的响应。
以上，在接口测试中被我理解为接口关联性测试，是和业务场景息息相关的，接口大多都是互有影响的，我们在测试时不光要保证接口本身的传参入参的正确性，而是要站在更上层，站在全局的角度去进行一个用例设计，这样才能将接口测试做得较为完善。

具体参数

其次需要对数据足够敏感，利用自己所掌握的测试方法，如等价类法，边界值法，因果图法等等，进行数据上的排列组合，将自己所想到的业务场景通过数据的变动进行模拟。

特殊情形

有的时候测试环境是不一定支持你去做一次非常完善的接口测试的，那么在这种情况下，就要想办法，利用其异常等其他返回，进行接口正确性的一个简单判断。当然我不是说这样可以完全保证接口的正确性，但是在特殊的测试环境限定下，这样不失为一种测试用例的设计思路。

手工？

目前，有不少测试人员使用一些测试工具，手动的进行接口测试，最常用的应该是chrome的F12开发者工具，postman，还有各种抓包改包工具，例如fiddler。目前的工具组合起来使用，已经能够完成接口测试的工作，不过有的时候可能因为工具的限制，不是特别灵便，而且还是需要花费一定的人力去做。而如果因为测试人员长时间进行接口测试，总归会产生枯燥感，而枯燥感带来的注意力不集中等问题，可能会影响到测试质量。这个是不太可控的。

自动化？

其实我个人认为接口测试最终还是要走向接口自动化测试，上面我们说了手工去进行接口测试，是属于测试任务进行中，投入一定的人力进行测试。而自动化测试，基本上要在测试任务早期，甚至是没有开始测试任务，还在开发阶段中就进行介入，是属于提前投入比较多的人力，而带来的收益也是较为长期的。
接口层本身就已经是比较底层的测试了，跟UI相比，一般是不会有太大变动的，变动比较少就不需要经常改动，而这也是我们便于做接口自动化测试的原因之一，而一旦我们做好了接口自动化测试，可以快速进行一个接口上的回归测试，这个也可以作为一个定时的监控测试。
语言上让我来推荐，我还是比较建议使用python+公司开发主要语言为主，我个人这方面也还需要学习，python作为一门极其灵便的语言，在自动化测试方面还是十分有帮助的，它有很多关于自动化测试的库，万能的requests，selenium，appnium，pytest等等，至于为什么还需要学习公司开发主要语言，也是为了加深和开发的交流，便于快速理解他们的具体实现过程，顺便也拓展自己的广度。