聊聊接口测试

司格特

这段时间自己捣鼓捣鼓了接口测试，也扫了一些其他人分享的经验，现在来说说自己的想法。

接口测试是什么?

API testing is a type of software testing that involves testing application programming interfaces (APIs) directly
and as part of integration testing to determine if they meet expectations for functionality, reliability, performa
nce, and security.[1] Since APIs lack a GUI, API testing is performed at the message layer.[2] API testing is no
w considered critical for automating testing because APIs now serve as the primary interface to application lo
gic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commo
nly used with Agile software development and DevOps) ————引自维基百科
接口测试的开始阶段

我觉得接口测试应该在程序的开发阶段就开始，具体的时间点应该是后台接口开发完毕之后，前端开始写功
能之前，当然由于现实中的各种情况，基本上不会出现这么刚好的时间点，只能说在后台接口开发基本完毕
之后，需要开始接口测试，在前端写功能之前对接口进行测试，能够在早期就把接口层的问题暴露出来，后
续前端在写功能时能够减少很多由于接口问题导致返工的工作量。

今天和小伙伴简单的聊了一下,了解了另外一个方向，他们公司使用MockServer来解决异
步开发的问题，这其实是一个很好的方向，引入MockServer之后，前端和接口测试可以同步编码，等后端接
口开发完毕后，约定时间来联调。虽然也难以做到无缝衔接，但是这样整个效率肯定会提升很多，但是这种
流程需要整个研发团队发展到一定规模后才能达到的水准，大部分公司达不到，因此接口测试应该尽早的开始。

接口测试的目的

我觉得目的就是两个。

第一、在开发接口尽早暴露出接口的问题，减少前端开发的返工工作量。

第二、由于接口测试中会覆盖一些冒烟的业务测试，因此可以在测试环境中定期的执行，减少功能测试经常
性的检验环境的重复工作。

测试的分层

测试大致分了三层，单元测试、接口测试、UI测试。单元测试离大多数人都是很遥远很遥远的，等遇到了再
想吧。接口测试和UI测试这两块其实是有一部分是重叠的，UI测试是通过前端写的界面，来调用接口，而接
口测试是直接调接口。所以排除前端的处理的逻辑和调用的正确性，在理论上接口测试是可以覆盖所有的UI
测试。我也尝试过这样处理，在接口层覆盖所有的业务流，在UI上只测试前端的逻辑，最终的结果就是忽视
了很多原有的功能点，导致了UI测试的不充分。所以存在多人分工且时间充分的时候可以尝试接口去做业务
流的全覆盖，否则不要轻易尝试。

我的做法

在接口的开始测试阶段，我用POSTMAN来手工测试接口，单一接口测试通过后，把测试用例Copy到Jmeter中，
作为后续的定期执行的基础，在接口手工全部测完后，用Jmeter+Ant+Jenkins来定期检查每天测试环境的接
口，并生成测试报告，再写一个爬虫每天监控测试报告，如果出现了异常，发邮件报警。

Jmeter的测试报告


每天的历史报告肯定也是需要留存的


有案例失败时的邮件通知


一些问题

接口测试不等于功能测试
虽然在某些地方，接口测试会和功能测试有重复的地方，但是两种测试的方向和角度不同，就导致了该重复的
还是要重复。在做了接口测试之后，功能测试依然是非常重要的，不能因为接口测试做了功能覆盖，就减轻了
功能测试的工作量。毕竟中间还间隔了前端的调用是否正确，当然也有某些处理的逻辑在前端。

接口测试的业务覆盖度
我觉得接口测试应该尽可能的覆盖功能测试的冒烟用例。但是不需要过多的去覆盖其他的业务流，接口测试的
重点应该放在客户端难以覆盖或者无法覆盖的地方，这样做会发现很多功能测试发现不到的问题。当然，发现
问题是一回事，解决问题也是要评估的，有些问题解决起来并不划算。

工具选择

工具有很多了，基于HTTP协议的接口测试可选的余地非常大，比如POSTMAN、Jmeter、soupUI，甚至用浏览
器直接发url也不是问题。

手工测试接口的阶段，我个人比较喜欢用POSTMAN，没啥原因，就是界面漂亮。到了自动化的阶段，用的是
Jmeter。

这里其实是有一个问题的。Jmeter的学习成本其实挺大的，基础的发请求断言这类功能当然是很简单，再往后，
很多细节上的处理问题，解决起来就非常非常困难，网络上很难找到类似的问题和解决方法，即使是自己去翻
官方文档，也不一定就能很快的找到。Jmeter作为Apache的顶级项目，理论上来说遇到的问题是能解决的，只
是这个解决成本很大可能会很大。用多了，有种四不像的感觉，虽然基本上的功能它都行。

用Python自己写一个接口测试的工具，其实难度不大，最初我的想法是写一个数据驱动或者关键字驱动的一整
个框架，论坛有一个朋友说不要把时间浪费在关键字驱动上，一开始并不理解，自己去写写后发现，还真是这
样，在技术水平没有达到的情况下，去写一个通用的东西无异于自己折腾自己。

后续有时间，需要把之前的接口测试用代码走一遍，从实际的工作量上看，好像用代码来写和用其他GUI端的工
具不会有很大很大的差别。

最后

最后应该就是测试报告了，集成于自动化的接口测试，每天的接口测试报告也是挺重要的，Jmeter的测试报告
虽然也很清楚，但是并不是我想要的东西，我理想的测试报告应该有一下那么两点

测试通过率
每条测试的过程展示
测试通过率是方便查看报告的人直观的了解本次测试的结果。

测试过程的展示需要展示如下内容：测试结果、请求地址、输入参数、输出结果、断言结果。并且成功和失败
的标识需要非常明显。

1047490880

很详细  很到为  谢谢分析

andypeker

请教一个问题，Postman，Jmeter这些可以根据服务，保存请求报文和响应报文的结构；
自己写一个接口测试框架的话，怎么根据服务类型构造请求报文，以及解析响应报文呢？
数据驱动和关键字驱动，可以解决这个问题吗？