现如今每当我们谈起自动化测试的时候，首先想到的不在是 UI 自动化，而是接口自动化。因为大家在被 UI 自动化 “坑” 多了之后，都变了聪明了。那么今天我们就来聊聊 HTTP 接口测试的那些 “花式” 测试方式。

最 Old-School 的方式

曾经接手过一个 HTTP 的接口项目，主要业务逻辑是一个分仓发货的物流子系统。可以通过 HTTP 的 POST 方式发送请求，并返回一个 XML 格式的内容。

对于这样的一个 HTTP 接口项目，前任 OWNER 在做自动化测试的时候，是这么做的：

• 直接通过 QTP 打开浏览器
• 访问一个定制表单页
• 然后选择不同的子项组合
• 最后提交表单
• 通过 QTP 从浏览器中获取返回内容
• 进行内容检查

简单来讲，这就是一个通过 UI 的方式来测试 API 接口的方法。不能说这种方式不好，只能说在效率和扩展性上不够优秀。主要体现在以下几个方面：

• 150 多个用例执行需要半天
• 换一个其他项目脚本都得重写
• 需要为每个项目编写至少一个表单页辅助测试

当然，后来这个项目被我优化了，后面会介绍具体的方式。

最普通的方式

如果说让一个新手来做 HTTP 接口的自动化测试，那么他首先会考虑的方式，肯定是基于单元测试框架。然后针对每一个接口编写多个不同检查点的 Case。

说它普通，那是因为大多数人都会选择或者曾经使用过这种方式，算是 HTTP 接口测试的入门方式。对于聪明点的同学可能会进行写稍微的改进，比如：

• 对同一个接口只开发一个用例，通过参数化请求数据和期望结果来实现多检查点覆盖
• 对同一个项目只开发一套逻辑，通过参数化 URL、请求参数、请求方式、期望结果等实现项目逻辑的覆盖

如果一个 HTTP 接口测试已经被完全的参数化了，那么可以认为你已经正式的 “毕业” 了！可以开始开拓其它更好的好的测试方式了。

最文艺的方式

如果你对 100 个测试人员说，你正在使用 RF（RobotFramework）进行自动化接口测试，那么肯定有一半人觉得疑惑，一半人表示 “钦佩”。因为毕竟 RF 在江湖中已经失传已久了。

觉得疑惑的同学，是因为他们可能只是听过说 RF，但是从来没有使用甚至了解过。不知道它具体能干嘛，或者只以为是一个 UI 的自动化框架。

表示 “钦佩” 的同学，是因为他们曾经尝试过 RF，但最终肯定是放弃过 RF。RF 如果没有被设计成 2 类用户使用，那么它可能会是一个 “噩梦”。毕竟直接使用 Python 原语言开发用例，总比多套一层 RF 再开发用例要清爽的多。

简单来讲，RF 本质上与单元测试框架一样，也是一个执行框架，它可以支持任意的测试类型，包括 UI、接口自动化。但是让它独树一帜的，是它能提供的 Keyword 机制，一切抛弃 “keyword” 理念的 RF 实践基本上等同于耍 “流氓”。

最认真的方式

诚然 RF 并不是毒药，就要比毒药可以杀人，也可以救人一样。使用得当的情况下，RF 也是有它的魅力的。曾经参加过某一个线下沙龙，一位嘉宾分享过他们公司基于 RF 框架的 HTTP 接口自动化测试实践。

之所以把它归为最认真的方式，是因为他们基于 RF 进行了深度的定制，具体体现在如下方面：

• 自主开发了在线的 WEB 用例编辑器（支持 keyword 选取）
• 优化用例存储方式（改进为直接存放在 DB 中）
• 扁平化 RF 用例层次结构（WEB 用例编辑器下面只有一层 keyword 封装函数，且都是使用 python 开发的 keyword）

经过定制之后，可以说是取其精华，去其糟粕。完美的重用了 RF 的 keyword 机制，同时摒弃了 RF 繁杂难用的语法。另外以服务的方式对外提供调用，集中管理了测试用例和测试报告。

最 “期望” 的方式

上一小节，我们已经初步体会到了以 WEB 服务提供 HTTP 接口测试的好处。但是以 RF 为基础的方式，毕竟还是避免不了开发 keyword 函数。而我们所期望的方式可能是仅仅在 UI 上面点点、选选就可以完成接口用例的开发，而无需再开发 keyword 了。

如你所想，我曾经就有过这样的想法，并且开发过这样的一个用于接口测试的 WEB 工具。主要用来替代了最 old-school 的那种方式。

起初开发这个 WEB 测试工具的时候，期望的内容是这样的。

• 不需要写代码直接通过 UI 操作,就可以在线编写接口测试用例，并且统一保存在服务端
• 直接通过 UI 触发就可以在服务端执行指定的测试用例
• 报告统一存放在服务端可供查看，并且保存用例的历史测试记录
• 支持通过 API 接口执行单个用例或用例集
• 通用的逻辑可以支持到所有项目

待到开发完成后，发现前面的所有条目都可以实现，唯独最后一条是一个 “坑”。毕竟针对简单 HTTP 的 API 接口还好对付，对于 API 间有复杂逻辑关系的业务就非常麻烦。即使该工具也提供了插件技术，支持开发扩展功能。

最后，这个工具主要用来维护一些单接口 API 测试需求的项目。对于复杂的还是推荐直接通过开放性的框架或者工具来完成。

最 “偷懒” 的方式

之所以说是偷懒的方式，是因为大多数人在接触 API 接口一段时间之后，都会有无聊和懈怠；毕竟新鲜劲过了，API 测试也就这个样子，跟手动 UI 测试一样无聊。

最关键的是也发现不了几个 bug，但是却要一个一个的反复开发 API 用例，感觉又要回到 “解放前”。所以就会想 API 测试虽然挺好，但还需要手工编写，能不能有一种方式可以自动生成呢？

答案是有的！！！俗话说的好：每当有人懒起来的时候，就是社会进步的时候了！！

具体而言，就是通过录制的方式来完成 API 接口用例的生成。这样接口测试的工作就变得即好用就便捷了，只要录制用例，执行用例就行了。具体而言可以有如下几种方式可以实现：

• 通过代理软件录制 HAR 文件，导入到 POSTMAN 中
• 录制 HAR 文件，导入到 YAPI 中
• 录制 HAR 文件，导入到 HTTP Runner 中
• 通过代理工具二次开发，直接录用用例数据到 DB 中

除了最后一种方式，需要自己编写一些代码来实现；其它的都是 “先懒” 们早就已经想到的了。最后一种也是我最近在项目中使用到的方式。

最 “理想” 的方式

通过录制的方式虽然方便，但是它有一个前提要求，就是录制的内容可以重复去执行。如果一个接口每次获得的内容是变化的，或者每次提交的内容也是变化的，那么录制的方式就不是很适合了，或者通过一些限定的手段来保证这一点。

再回过头来想想，API 测试最终极的理想方式，应该是自动生成用例，并且自动生成正确的测试数据。虽然现在 AI 很火，但是还远没有达到这种自动化生成测试用例数据的能力。

而在 AI 还不能完成之前，我们可以通过真正的 “人工智能” 的方式，来解决一些特定需求的项目。

比如：对于重构项目的测试，就可以通过拉去线上请求历史日志，在线下同时对新旧 2 套系统同时回放请求，在对比二者的返回内容是否一致。这种影子测试的方式就解决自动生成数据的难题。

总结

相信上面的这么多种方式，大部分人都曾经遇到或者使用过。当然各有利弊，没有最好只有最适合。如果你还有其它的方式，希望你能关注公众号并回复给我哈！

获取更多关于 Python 和自动化测试的文章，请扫描如下二维码！