“老兵爱学习”之《颠覆你的Python接口自动化测试》 - 51Testing软件测试论坛

第一节课总体设计思想 / 第二节课接口基础 / 第三节课接口手工测试

接口其实就是由一段具备逻辑处理的程序代码所组成的，可被其他方法、服务或应用所使用。

调用接口的人，可以把接口看作一个黑匣子，只需要按接口文档的约定传入正确的参数，再接收并处理返回的数据，不需要知道黑匣子里的处理机制；

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部组件与系统之间以及内部各个子系统之间的交互。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑及依赖关系等。

1、产品的系统复杂度越来越高，只靠手工的前端测试，很难确保很高的覆盖度，但是通过接口测试，我们能模拟出各种类型的入参值，包括一些从前端模拟不了的入参值，我们能根据接口文档的定义，设计出相对完善的入参值，力争在接口层先保证业务逻辑的正确，剩余的大多数问题就只是 APP 自身的交互和数据展示问题了。

2、接口测试相对 UI/功能测试来说，自动化的成本更低，性价比更高，特别是在产品进入稳定维护期之前，UI 和功能都不稳定，变化较大，导致脚本返工甚至于废弃重写的几率都很大，而接口大多都是可以重用的。

3、现在很多系统前后端是分离的，从安全层面来说，只依赖于前端进行 Input Validation 已经完全不能满足系统的安全要求，因为绕过前端相对容易，所以就需要后端同样进行 Output Validation，这就需要用接口测试工具去验证；

Options在Connection面板里将Allow remote computers to connect勾选起来，确定后，关闭Fiddler并重新打开Fiddler

b. 在cmd里执行netstat-anop tcp查看Fiddler进程是否正常监听8888端口，如果服务没有正常开启，可以尝试使用其他端口，端口修改的位置，如上图位置

c. 从上图我们看到，进程ID为7724的Fiddler正在监听8888端口，说明代理已经在工作了.

g. 测试完成后，记得关闭代理，以免 Fiddler 关掉之后，手机上不了网

听完了老师关于设计方法的讲解，结合我自己的认知，我对接口测试的用例设计做了下面一些思考和总结。

通常是用来做入参参数必填项检查的，因为前端往往会做必填项保护和响应提示信息，为了确保服务端也做了必填项保护，我们需要将必填项对应的入参参数值置为空，看服务端是否会返回相应的提示信息和响应状态码。

入参参数值的合法性检查一般也会在前端做保护，但后端往往容易忽视或遗漏，为了确保服务端也做了入参参数值的合法性检查，我们除了设计合法的入参值之外，还需要设计一些非法的参数值，看服务端是否会抛出相应的异常和响应状态码。

这里的逻辑性检查，就是检查服务端返回的 JSON 串里的参数值，是否与根据入参的值和业务逻辑推演出来的期望值一致，以此来测试该接口的业务逻辑处理是否正确。

关于这两类校验的自动化实现，我其实也一直在纠结它们的性价比。

前者是自动化测试工具很容易实现的，应用面也较广，比如回归测试、环境检查、现网巡检等场景，而且也易于复制，因为它本身和业务逻辑耦合性不大，更多的只是检查该接口的健康状态。

后者因为需要校验逻辑正确与否，所以在做返回值比对时，就不仅仅只是比较 JSON 串里的返回参数值和期望结果是否一致了，在某些场景下还需要对数据库里的数据进行实时比对或操作。这在设计工具时，不可避免地会增加实现的难度，同时还缩小了可应用范围，至少这类校验就不能在真实的客户环境去执行，会存在风险。

所以，比较期待在后续课程的学习过程中，能让我关于接口逻辑校验自动化工具的构思变得清晰。