如何进行“花式”HTTP接口测试?

发表于:2019-11-14 10:36  作者:five3   来源:简书

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试技术 接口测试

  现如今每当我们谈起自动化测试的时候,首先想到的不在是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套系统同时回放请求,在对比二者的返回内容是否一致。这种影子测试的方式就解决自动生成数据的难题。
  总结
  相信上面的这么多种方式,大部分人都曾经遇到或者使用过。当然各有利弊,没有最好只有最适合。
 
      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理

【福利】填问卷 送2019精选测试大礼包+接口测试实战课程!

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2020, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道