接口测试到底该怎么做？你真的会接口测试吗？

前言

1、接口测试

对于接口测试来说，项目测试用例的重复运行首先是表现在单个测试用例的独立性方面的，也就是说，每一个测试用例的运行除了依赖被测对象和对应的数据库环境外，是不依赖于其他任何测试用例的。

并且这个测试用例执行完毕后，对系统来说，也是没有任何痕迹的，这样就保证了每个测试用例运行时，都在一个干净的环境中运行。

要实现测试用例的独立性，就必须对被测系统的设计有详细的了解，这样，不会出现测试用例执行后遗漏数据，环境未改变，另外，还需要对测试用例进行详细的设计。

另外，要保证测试用例的重复使用，还需要做到测试用例的及时更新，在这个方面，我们是做接口测试的人会维护对应的系统的接口测试用例，要保证，代码每次更新，测试用例都必须全部执行通过。

具体的测试用例设计，考虑如下：

输入参数测试：
针对输入的参数进行测试，也可以说是假定接口参数的不正确性进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法，输入参数不合法，输入参数为空，输入参数为null，输入参数超长。

功能测试：
接口是否满足了所提供的功能，相当于是正常情况测试，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例具有更好的可读性和维护性。

逻辑测试：
逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试界限并不是那么清楚，所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常；

异常情况测试：
接口实现是否对异常情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何的异常都进行处理。

2、接口测试怎么做

接口测试作为集成测试的一部分，通过直接调用被测试的接口来确定系统在功能性、可靠性、安全性和性能方面是否能达到预期，有些情况是功能测试无法覆盖的，所以接口测试是非常必要的。

接口测试分为两种，一种是webservice接口，走soap协议通过http传输，请求报文和返回报文都是xml格式的，测试时通过工具soapUI进行测试。使用情况比较少；

另一种http api接口，走http传输协议，通过路径来区分调用的方法，最常用的是get和post请求。

上面说过，get和post请求是通过路径来区分的，get请求的请求参数都是写在URL里的，格式为：http://url?param1¶m2。而post的请求一般都是写在body里的，可能是key-value格式，或者json串格式，也可能是上传一个文件。。。

那么问题来了，get请求和post请求的区别在哪里呢？百度时，大多数的答案是这样的：

1）get请求可以在浏览器中请求到，post请求的测试需要借助工具
2）get请求使用url和cookie传参，post的数据放在body中
3）post比get更安全，因为传递的参数在url上是看不到的
4）get请求的url会有限制，而post请求的数据可以非常大
5）一般get请求是来获取数据，post请求是传递数据的

其实，对于现在飞速发展的互联网来说，上面的说法已经不严谨了。

首先，post请求的参数也可以写在url里，但是这种情况不多见；

其次表面上看起来，post利用body传参，比get的url传参安全，但其实只要用抓包工具（fiddler，Charles等），post的参数也是一览无余；

再次，现在的浏览器非常强大，可以输入支持很长的URL，所以也不再有限制一说了。这么说来，种种区别只有最后一条是最根本的了。

3、怎么来测试接口呢？根据什么来测呢？

这就需要开发提供的接口文档了，接口文档和功能测试的需求说明书的功能是一样的。包括：接口说明、调用的url，请求方式（get or post），请求参数、参数类型、请求参数说明，返回结果说明。

有了接口文档后，我们就可以设计用例了，一般接口测试的用例分为以下几种：
　　
1）通过性验证，说白了就是传递正确的参数，是否返回正常的结果

2）参数组合，因为参数有必传和非必传，参数的类型和长度，以及传递时可能业务上的一些限制，所以在设计用例时，就要排列组合这些情况，保证所有情况都能覆盖到

3）接口的安全性，这个又分为几种情况：
绕过验证，比如提交订单时，在传递商品价格参数时，修改商品价格，就要看后端有没有验证了。或者我支付时，抓个包将订单金额一改，如果能以我改后的金额支付，那这个借口就有问题了。

绕过身份验证，就是某个功能只有有特殊权限的用户才能操作，那我传递一个普通的用户，是不是也能操作呢

参数是否加密，这个关系到一些账户的安全，比如我们在登录一些网站时，它要将我们的登录信息进行加密，如果不加密我们的信息就会暴露，危害性极大。

密码安全规则，设置密码时复杂程度的校验。

根据业务逻辑来设计用例
用例设计完了，用什么来测试接口呢？
我们可以借助一些工具，比如postman和jmeter。postman使用比较简单，可以在列表中选择请求方式，在输入框中输入URL，如果是get请求，直接点击send就可以看返回结果了。

4、接口测试范围

业务功能（包括正常、异常场景是否实现）
业务规则（覆盖度是否全面）
参数验证（边界、业务规则是否达到要求）
异常场景（重复提交、并发提交、事务中断、多机环境、大数据量测试）
性能测试（响应时间、吞吐量、并发数、资源要求）
安全测试（权限验证、SQL注入等）

5、接口测试的重点

检查接口返回的数据是否与预期结果一致。
检查接口的容错性，假如传递数据的类型错误时是否可以处理。
接口参数的边界值。例如，传递的参数足够大或为负数时，接口是否可以正常处理。
接口的性能，http请求接口大多与后端执行的SQL语句性能、算法等比较相关。
接口的安全性，外部调用的接口尤为重要。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！