首页 > 代码库 > 我理解的接口测试(二)

我理解的接口测试(二)

上文中,谈了一些接口测试的概念和原理。接口测试的原理很简单:模拟调用方往接口放数据后再校验拿出来的数据。原理说起来的确很简单,但如何模拟、如何调用、如何校验?这些问题你必须在接口测试开始之前都得找到答案。

 

如何模拟?


目前,有很多的接口测试工具,例如:postman、jmeter、SoapUI、robotframework+协议lib、firefox插件RESTClient等,是的,可以用来做接口测试工具很多,不同的工具能够模拟协议也不尽相同。所以,需要先知道被测应用的接口是什么协议?HTTP、HTTPS、SOAP、XMPP、DUBOBO、FTP、SMTP等,确认接口协议后,再来挑选需要使用的接口测试工具。但作为一个靠谱的测试人员,应该提前储备这些测试工具的使用方法,在测试需求到来之时能直接上手开展接口测试。

 

如何调用?


虽然所有的接口测试工具都能手动调用,但从长远来看,更应该去使用支持No Gui(命令行)运行测试集的工具。因为,在前期我们用来做接口手工测试的测试集能很快转换为接口自动化测试的测试集,再接入到我们的CI平台(eg.jenkins、Travis CI等),通过Svn操作或定时任务触发,构建=>发布=>接口测试=>测试报告=>邮件,从而达到持续集成(持续集成不仅仅是接口测试),快速发现问题。

 

如何校验?


接口测试工具都会展示返回数据,并提供展示模板(json、html、xml等),我们除了校验数据是否正确以外

  • 校验返回的数据格式是否符合协议文档(例如:协议定义返回的数据格式是int,那么返回的数据不应该是“1”,而应该是类似1这样的数据)

  • 校验返回的数据结构是否符合协议文档(例如:协议定义返回的数据结构中name为必返回,那么返回的数据中必须包含name)

  • 校验指定场景下,非必返回的数据是否返回(例如:协议文档中的字段sex非必返回,只有当请求值sex为空时才返回,那么在构造测试用例中,要构造请求值sex为空的请求数据,再校验返回的数据中是否包含字段sex,没有则用例执行失败)

  • 校验数据持久化正确性(例如:需求定义查询时保留查询记录,那么校验返回数据之外,还得校验数据是否正确持久化,有没有存到相关数据库表或缓存服务器中)

从长远来看,更应该去使用校验手段更多的接口测试工具(能断言返回数据、能查询并断言数据库和缓存服务器、能横向扩展校验功能),从而确保全覆盖的接口自动化测试。

 

下图就是主流测试工具的横向对比,仅供参考

技术分享

 

总结下:

  • 无编程能力、要快速上接口测试,推荐:postman

  • 要陆续推进、深耕接口测试,推荐:Jmeter

  • 想同时推进UI和接口,推荐robotframework

  • 基于SOAP协议的接口测试,推荐:SoapUI

 

事实上,被测应用并不只是单个模块,很可能是多个产品构成的复杂架构,这种情况,如何最优的进行接口测试?下篇讲解

 

部分说明:

持续集成的目的,就是让产品可以快速迭代,同时还能保持高质量。它的核心措施是,代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。

Martin Fowler说过,"持续集成并不能消除Bug,而是让它们非常容易发现和改正。"

技术分享

 

在编程语言中,“1”和1是不同的数据类型,前者是字符串,后者是整数

 

数据持久化:持久化是将程序数据在持久状态和瞬时状态间转换的机制。通俗的讲,就是瞬时数据(比如内存中的数据,是不能永久保存的)持久化为持久数据(比如持久化至数据库中,能够长久保存)

我理解的接口测试(二)