1. STest软件测试社区首页
  2. 接口测试

接口测试实践和一些想法

本帖已被设为精华帖!,

因为最近想接触一下移动测试方面,所以了加入了TesterHome这个社区,看见了很多优秀的文章,也看见了很多讨论《自动化测试的困惑》《很多接口测试框架》《接口测试感悟》,下面我谈一下个人的见解,勿喜勿喷。


接口测试的好处


  • 简单(对于开发基础比较好的同学来说)
  • 稳定(成功率极高,很少出现UI自动化测试的各种状况)
  • 效率(1个接口下的100条用例1秒执行完成)
  • 可信(UI自动化测试报告天天发送,一堆Fail,费了好大劲排查原因,结果各种环境、浏览器问题等,慢慢大家对这个就想白盒扫描工具的报告一样,当成垃圾邮件)
  • 时间(用例编写时间段短,也不需要写测试脚本,调试页面脚本)

接口分析、工具选择


  • 目前主流的协议HTTP、WEBSERVICE、REST等,还有一些dubbo、hessian等个别公司内部开发或者二次改装的协议。
  • 其实我们做接口测试对于是什么协议前期不用太怎么关注,我们主要关注怎么模拟发送请求。(当然学一样东西,不仅仅要知道,而且要知道原理,否则就违背了我们身为技术人员这个职业了)
  • 当我们确定接口是哪些协议的时候,那么我们就开始选择模拟调用端了。
  • 基于HTTP接口测试的工具:restclient、postman、jmeter、soapUI等等,基于JAVA代码的httpclinet、JAVA自带的URLConnection等。
  • Dubbo之类的可能要自己客户端请求代码了。
  • 所以接口测试第一件事情,确定客户端或者调用工具。

用例编写、开始执行


  • 开始编写前置条件、入参、返回结果、预期结果等测试用例相关信息。
  • 运用工具去执行测试用例。
  • 校验返回结果是否正确。 -简单的一个 接口测试完成。

【思考】手工接口用例执行完了,那我们开始自动化测试吧


  • 开始找各种开源框架,二次开发等。
  • 编写各种脚本。
  • 准备各种接口自动化测试用例。
  • 准备接口数据。

我们在回顾一下自动化测试的好处,可以帮助人做某些事情,提高效率,减少资源。
那么我们专门为了做接口自动化测试而做了以上4点工作。
如果我作为功能测试人员的话,我是不会想做完手工测试在去维护各种接口自动化用例和数据(事实证明其他同事确实如此)。
框架可能好做,接口请求客户端也可能好写,用例数据的维护呢?


一个想法

  • 手工接口测试和自动化测试能够有效的结合起来是不是更有好处,测试人员在做手工接口测试的同时数据可以保存下来,然后可以批量运行,发送报告,这样是不是接口自动化测试呢?

实践

  • 我们没有做框架。
  • 根据公司的技术,做了一套接口测试的平台,它不是最好的,但是可能是最适合的。
  • 当然你也可以基于开发工具二次开发。
  • 菜单列表工程介绍。

    接口测试实践和一些想法

  • 工具箱是一个工具集合,和市面工具没有区别,打码的是公司内部的协议就不外传了。

    接口测试实践和一些想法


接口测试菜单


-接口测试主要是创建接口与项目进行绑定。

  • 直接在这里进行接口的手工测试,当手工接口测试结束之后,执行的用例数据可以作为自动化测试用例使用。
  • 创建接口

接口测试实践和一些想法

  • 接口列表,可以在这里选择接口执行所有测试用例,也可以设置前置,后置条件,数据恢复,维护接口写的测试用例。

接口测试实践和一些想法

  • 测试用例维护

接口测试实践和一些想法

  • 新增测试用例,里面可以设置一些数据库条件、数据查询校验条件、断言匹配规则以及接口测试,针对JSON的List自动排序对比,在这里测试之后直接就保存了自动化回归用例。

接口测试实践和一些想法


报告


  • 当然还有执行报告、邮件报告、定时任务、Diff对比等

接口测试实践和一些想法

  • Diff

接口测试实践和一些想法


以上内容仅供参考,平台的功能没有全部介绍,希望能给大家带来帮助。

原创文章,作者:STC,如若转载,请注明出处:http://www.stest.com

发表评论

电子邮件地址不会被公开。 必填项已用*标注

QR code