接口测试聊聊接口测试

点点寒彬 · 2016年10月08日 · 最后由冷月醉夕阳回复于 2018年07月06日 · 4001 次阅读

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

接口测试是什么?

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, performance, and security.[1] Since APIs lack a GUI, API testing is performed at the message layer.[2] API testing is now considered critical for automating testing because APIs now serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps) ————引自维基百科

接口测试的开始阶段

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

接口测试的目的

我觉得目的就是两个。

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

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

我的做法

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

Jmeter 的测试报告

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

有案例失败时的邮件通知

一些问题

接口测试不等于功能测试

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

接口测试的业务覆盖度

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

工具选择

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

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

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

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

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

最后

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

测试通过率
每条测试的过程展示

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

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

最后的最后

以上内容是我自己工作中的想法，也不知道是否正确，希望社区的老司机们能给一些建议。

44 个赞

如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！

打赏支持

共收到 29 条回复时间点赞

孙高飞 #1 · 2016年10月08日 3 个赞

额，好像那个极力不推荐关键字驱动框架的人貌似是我。倒不全是技术原因，除非你团队的成员都不会写代码，否则还是算了。我说说我的感觉吧，你的思路挺好的。不过有几点，咱们探讨一下吧。

接口测试开始的时间：现在前后端都是并行开发没有先后顺序了吧？约定好 API 的定义，前端依靠 mock server 就可以自测了。然后约定时间联调，提测。虽然做不到无缝衔接，但基本没有时间说等测过了再联调的。我们公司就是用 RAP 做 API 定义管理和 mock server 的。
接口测试的目的：第一点尽早暴露问题是没错的。但那是把它加入到 CI 中才比较有效。第二点我觉得接口测试执行快，反馈快，建议尽量当成单元测试一样测，出现问题可以迅速找到根源，也不会因为一个 bug block 住之后的流程，加入到 CI 中定期执行，快速反馈，它主要的优势是尽早，尽快找到问题的根源。而不是取代前端的重复性功能测试。他也取代不了
Jenkins 有邮件报警和 report 展示的插件~ 楼主不用自己写。。。
越是底层的东西覆盖率更应该提高，UI 层的反而应该少。所以不太明白楼主说的不要过多的覆盖业务的想法
POSTMAN、Jmeter、soupUI 都只是过渡，它们的优势本就不是在企业级项目中做自动化的
最后关于测试的 report，有很多开源的 report 项目啊。python 的我不熟悉，但是 java 的 reportng，allure-report。都是定制 report 的最佳选择

点点寒彬 #2 · 2016年10月08日 Author

#1 楼 @ycwdaaaa 感谢回答，我们公司目前还是最原始的研发流程阶段，没有 mock server 这种东西，还是设计完之后，前端先写界面，后端开发接口，达不到并行的状态。整个公司就我一个测试，没人指导，只能靠自己摸爬滚打。

接口测试开始的时间：现在前后端都是并行开发没有先后顺序了吧？

我们做不到 mock server，没办法并行开发，所以我才觉得接口测试应该在这个阶段开始进行，之前压根就没有做接口测试，最近我自己捣鼓之后才感觉接口测试应该在这个时间切入，如果有 mock server，确实是可以做到三方并行开发，然后约定世家你联调，真是一个好方向有时间我一定要给领导安利安利这个东西

接口测试的目的：第一点尽早暴露问题是没错的。但那是把它加入到 CI 中才比较有效。

还是刚刚的问题，我们这里并没有 CI 这种东西，研发流程中编码之外的事情全部我一个人做。开发写完代码把更新包给我，让我来更新到测试环境，所以我的想法就是把接口测试案例做成自动化，定期在测试环境跑，确保测试环境不会由于开发更新代码发生其他问题。

越是底层的东西覆盖率更应该提高，UI 层的反而应该少。所以不太明白楼主说的不要过多的覆盖业务的想法

人员不足（就俺一个人），导致每次回归非常非常的痛苦，之前想用 Appium 来做 UI 的回归，发现推行起来问题很多，领导不 care 这块，开发就不配合，导致做到一半就流产了。接口测试其实是可以几乎完全模拟 UI，只是没有界面罢了，所以我之前的想法是把接口测试分为两块，一块是单个接口的验证，第二块是所有业务流的验证。这样导致了一个问题，我自己在执行功能测试的时候过于依赖接口测试的覆盖，导致了功能测试用例的缺失比以前大很多，我才觉得接口测试的业务流覆盖应该仅限于冒烟，而其他的业务流通过功能测试来覆盖。这样就能解决我现有的问题，不过分依赖接口测试的业务流覆盖，在前端不修改代码的情况下，通过接口来覆盖冒烟，定期执行接口测试就能在很大程度上保证主业务的正确性。