接口测试

接口测试基础知识

接口类型
webservice接口，走soap协议通过http传输，请求报文和返回报文都是xml格式的，测试时通过工具soapUI进行测试。
http api接口，走http传输协议，通过路径来区分调用的方法，最常用的是get和post请求。
Dubbo接口，使用的是 TCP/IP是传输层协议，比 HTTP协议快。
区别：
http1.1协议默认使用短连接，每次请求均需要进行三次握手，而http2.0协议开始将默认socket连接改为了长连接
http 短连接，协议标准化且易读，容易对接外部系统，适用于上层业务模块
Dubbo rpc长连接、传输效率较高，可定制化路由，适用于内部系统互联；

【Dubbo】Dubbo 接口是什么？与http 接口有什么区别？

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

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

做好接口测试的前提
1、系统化的接口文档
2、标准化的接口规范

理想中的自动化测试结构应该是大量的UT+适量的集成测试(或者API测试)+少量的UI测试。
　　构建API测试的价值
　　测试覆盖率。UT关注点是各个单元是否能够完成期望工作，只覆盖一个单元内部工作情况；集成/API测试关注点是各个模块/单元之间协同工作，它所覆盖的场景也会比单元测试更多。而UI测试会更加关注e2e，模拟用户行为，在所有的程序依赖环境准备完成后再进行操作。相比之下API测试不依赖环境，测试成本会比UI测试更低，而且覆盖率比UT更高。
　　快速反馈。API测试速度比UI测试更快(因为无需界面加载/响应)，短时间内能跑很多用例。API测试也能精确的揭露是软件中哪个组件除了问题，如果把你的API测试放到CI里面，一旦代码修改破坏了现有的功能，就能够快速反馈到团队中。还可以把测试中发现的BUG也写到API测试里面，让测试成为一堵墙，从而能更好的能保证产品质量。
　　可复用。API测试由于不需要浏览器、GUI等环境，所以可以更加灵活的在各个环境中复用。例如你可以在产品环境中、测试环境、研发环境中使用，你需要做的只是修改下测试数据而已。另外如果是在TDD模式下工作的话，API测试可能会在产品完成前就写完了，后续的工作也会减少很多。
　　怎么做API功能测试
　　API功能测试的主要手段是使用工具/软件调用待测API，然后验证是否返回期望的output。这个output通常可能是:

返回成功或者失败的status
是一段数据或者information
或者是跳转到其他API
工具
　　市面上常见的API测试工具我知道的可以分成几大类：
　　1、开源纯代码类，比如基于nodeJS的supertest，基于Java的rest-assured等，这类工具易于学习，易于和CI集成，但是需要使用者有一定的编码能力。
　　2、商用工具，比如SoapUI，功能强大操作简单，还提供免费社区办可以试用。
　　3、各类插件工具，比如Chrome插件Postman，也有收费版可以玩儿。
　　工具的选择见仁见智，根据不同的环境选择不同的工具。
　　测试
　　在正式开始测试之前，你得先搞清楚几个问题：
　　· 待测API的目的是什么，谁是使用者
　　· 待测API会在什么环境下使用
　　· 待测API在异常环境下会不会有非期望响应
　　· 这个测试需要测什么功能点
　　· 各个功能点的测试优先级
　　· 如何定义期望返回的结果是成功还是失败
　　· 待测API会不会和其他系统有交互(修改代码后影响其他系统)
　　这些问题会影响到你的测试结果是否符合客户需求，或者说这些潜在的风险会影响到这个项目是否成功。
　　如果你选的是必须得自己写点儿代码的工具，那么接下来得根据选择的工具和项目代码，去setup测试环境，让工具能够成功跑起来。
　　接着是设计你的测试框架，最好是要满足可复用性强，高内聚低内聚什么的原则，记得要有输出测试报告的模块。
　　然后是用例，上面你已经想好了需要测哪些功能点，针对这些点我们用脑图之类的工具把需要测试的场景记录下来。
　　最后就是脚本设计和测试数据设计，脚本和数据最好可以分开，这样的话可以复用测试脚本，用不同的测试数据输入去获取不同的期望结果。
　　验证的过程大致包含下面这些：
　　1、检查API是不是根据你输入的数据返回期望的结果
　　2、验证API是不是不返回结果或者返回异常结果
　　3、验证API是不是正确触发其他event或者正确调了其他API
　　4、验证API是不是正确更新了数据等等
　　完了就是输出测试报告了，好的测试报告可以帮助你轻松定位到出错的地方，使修复流程更加顺畅。
　　最后的最后，强烈推荐把测试集成到CI中去，加速异常反馈，创建墙有力的质量体系。