10年⽼测试与你分享HTTP接⼝测试的独特⽅式

在⾃动化测试领域，随着时间的推移，我们更倾向于谈论接⼝⾃动化⽽⾮ UI ⾃动化。对于经历了UI⾃动化的“坑”后，⼤家变得更为聪明。今天，我们将讨论HTTP接⼝测试中⼀些别致的测试⽅法。

最 Old-School 的⽅式

我曾接⼿过⼀个HTTP接⼝项⽬，涉及物流⼦系统的分仓发货主要业务逻辑。前任OWNER在进⾏⾃动化测试时采⽤了以下⽅法：

• 直接通过QTP打开浏览器
• 访问⼀个定制表单⻚
• 选择不同的⼦项组合
• 提交表单
• 通过QTP从浏览器中获取返回内容
• 进⾏内容检查

这种通过UI测试API接⼝的⽅式并⾮不可⾏，但效率和可扩展性⽅⾯存在不⾜。经过我的优

化，后⾯将介绍具体的⽅式。

最普通的⽅式

对于新⼿来说，最常⻅的HTTP接⼝⾃动化测试⽅式是基于单元测试框架。通过为每个接⼝编

写多个具有不同检查点的⽤例。

这种⽅式虽然普遍，但因其普及度⾼，很多⼈可能对其进⾏了改进：

• 对同⼀接⼝只开发⼀个⽤例，通过参数化请求数据和期望结果实现多检查点覆盖
• 对同⼀项⽬只开发⼀套逻辑，通过参数化URL、请求参数、请求⽅式、期望结果等实现项⽬逻辑的覆盖

当HTTP接⼝测试完全参数化后，可以认为你已经正式“毕业”，可以开始尝试其他更先进的测

试⽅式了。

最⽂艺的⽅式

如果你告诉100个测试⼈员，你正在使⽤RF（Robot Framework）进⾏⾃动化接⼝测

试，⼀半⼈可能感到疑惑，⼀半⼈可能表示钦佩。这是因为RF在⾏业中已经不再流⾏。

RF本质上与单元测试框架相似，是⼀个执⾏框架，⽀持各种测试类型，包括UI和接⼝⾃

动化。但RF独特之处在于其Keyword机制，摒弃这⼀机制的RF实践基本等同于放弃了其精

髓。

最认真的⽅式

虽然RF并⾮毒药，但在适当使⽤的情况下，它确实具有魅⼒。我曾参加过⼀个分享，介

绍了基于RF框架的HTTP接⼝⾃动化测试实践。

将其归为最认真的⽅式，是因为他们对RF进⾏了深度定制，具体体现在以下⽅⾯：

• ⾃主开发在线的WEB⽤例编辑器（⽀持Keyword选取）
• 优化⽤例存储⽅式（改进为直接存放在DB中）
• 扁平化RF⽤例层次结构（WEB⽤例编辑器下只有⼀层Keyword封装函数，且都是使⽤Python开发的Keyword）

通过这些定制，他们充分利⽤了RF的Keyword机制，同时摒弃了RF复杂且难以使⽤的语法。

最 “期望” 的⽅式

前⾯已初步体验了通过WEB服务进⾏HTTP接⼝测试的好处。然⽽，以RF为基础的⽅式

仍然避免不了开发Keyword函数。我们期望的⽅式可能是仅通过UI操作就能完成接⼝⽤例的开

发，⽆需再开发Keyword。

我曾有过这样的想法，并开发了⼀个⽤于接⼝测试的WEB⼯具，⽤于替代最传统的⽅式。该⼯

具最初的期望是：

• 通过UI操作⽆需编写代码，即可在线编写接⼝测试⽤例并统⼀保存在服务端
• 通过UI触发在服务端执⾏指定的测试⽤例
• 将报告统⼀存储在服务端以供查看，并保存⽤例的历史测试记录
• ⽀持通过API接⼝执⾏单个⽤例或⽤例集
• 通⽤逻辑可⽀持所有项⽬

然⽽，最后⼀点成为⼀个“坑”，尤其是对于具有复杂逻辑关系的业务。对于简单的HTTP API

接⼝需求，该⼯具仍然是⼀个不错的选择。

最 “偷懒” 的⽅式

在接触API接⼝⼀段时间后，⼤多数⼈可能感到⽆聊和懈怠。由于难以发现⼤量错误，但⼜需

要反复开发API⽤例，⼈们可能想要⼀种能够⾃动⽣成的⽅式。

答案是有的！当⼈们变得懒惰时，社会就会进步！

具体⽽⾔，可以通过录制的⽅式⽣成API接⼝⽤例。这使得接⼝测试变得更加简便，只需录制和执⾏⽤例即可。有⼏种⽅式可以实现：

• 通过代理软件录制HAR⽂件，导⼊到POSTMAN中
• 录制HAR⽂件，导⼊到YAPI中
• 录制HAR⽂件，导⼊到HTTP Runner中
• 通过代理⼯具⼆次开发，将⽤例数据直接录制到DB中

最后⼀种⽅式需要编写⼀些代码，但其他⽅式是早已被⼈们所想到的“偷懒”⽅式。

最 “理想” 的⽅式

虽然通过录制的⽅式很⽅便，但前提是录制的内容可以重复执⾏。对于每次获得不同内

容或提交不同内容的接⼝，录制的⽅式就不太适⽤，除⾮采取某些⼿段保证其可重复

性。

回过头来看，API测试的最终理想⽅式应该是⾃动⽣成⽤例并⽣成正确的测试数据。虽然现在AI很⽕，但在这⽅⾯的⾃动化能⼒仍有待提⾼。

在AI能够完全胜任之前，我们可以通过真正的“⼈⼯智能”⽅式解决⼀些特定项⽬的需求。例如，对于重构项⽬的测试，可以通过拉取线上请求历史⽇志，同时在线下回放新旧两套系统的请求，然后对⽐它们的返回内容是否⼀致。这种影⼦测试⽅式解决了⾃动⽣成数据的难题。

总结

上述⽅式中，⼤多数⼈都曾经遇到或使⽤过。各种⽅式都有利弊，没有最好，只有最适合的⽅式。选择适合团队和项⽬需求的⽅式才是最重要的。