接口测试 Http 接口测试框架 (思路 + 实现中 + 开源 + 可能难产)

Heyniu · July 24, 2016 · Last by Heyniu replied at August 15, 2016 · 2395 hits

写在前面

衔接前面的传送门

有时间我会把我初步的想法整理好分享出来,大家一起来探讨它的可行性,它不一定适用你们的业务,但是非常适合我项目的业务。虽然它也可能难产,但是我想尽力去做、去完成,也算巩固一下自己的知识,应用到项目中去。

这个框架需要大家不断的鞭策、一起努力、共同搭建,可以随时发表看法,欢迎拍砖,求不打脸!

它为何而来?

  • 团队项目流程的规范,团队下一步的目标就是接口测试
  • 一款应用上线前要测试3次服务器(接口一样,环境不同),纯手工验证是受够了

它能做什么?

  • 简单的接口测试(主要回归测试)
  • 持续化集成
  • 接口日常监控
  • 可能还有?

缺陷?

还没想,相信你们阅读后就会帮我回答了

框架整体思路

跪求积极发表看法、框架还在萌芽阶段、确保方向细节处理。

Http接口测试框架流程

天啊撸,又是Java

没错就是Java,可以是其他吗?可以,你熟悉的语言都可以,首选Python,用过的都知道

Java的考量:

  • Python很久没碰了,忘的差不多(真相是原来水平就入门级还不到吧)
  • 项目是Java开发的,http框架是基于okhttp的二次封装(不以项目为导向的都是扯淡)
  • 前面发现一个http框架的bug,想看下还有没有什么没发现的bug,特别是多线程的时候它的单例会不会有问题(功能测试一般遇不到http框架的bug)

Http框架bug传送门

框架雏形

没错,这个框架已经在默默地搭建了。

目的:通过简单的接口验证发现服务器接口异常

经验:一般认为Response body code为200,则表明该接口无改动(试用目前的项目,总结的经验)

实现:判断每个接口的Response header code,如不是200则接口失败(常见code:404/502,302情况说明,因为是API所以应该没有重定向的,基于目前的经验判断,欢迎指正),再判断Response bodyJSON里面的StatusCode是否为200,不是则初步判断接口失败,最后查看失败的文件即可

评价:速度慢、手工录制、简单回归、简单验证

关于代码:明天补上

目前的情况汇报下:

  • 接口录制(已完成)

    • 通过手工录制/monkey录制
    • 数据源录制时机:功能测试过一遍后,一般此时服务器接口比较稳定
    • 自动保存每次请求的URL,用于与索引器遍历,得出Diff文件
    • 自动保存每次请求的Request header、Request body、Response header、Response body
    • 考虑加入统计每次请求的耗时

Fiddler 保存会话 (请求)

  • 索引器思路JAVA版(已完成)20160724

    • 由来:加快遍历速度
    • 掌握知识:因没接触过索引器的知识,欢迎懂的/有更好思路的童鞋帮忙指正,改进
    • 思路
    • 取出接口页面某个应用的所有接口存进一个List
    • 每个接口取出首字母,存进HashMap(key > firstLetter, value > start|end),存字母在List中出现的位置和结束的位置(即字母区间),中间用分隔符分割
    • 当数据对比时遍历HashMap,匹配key,当匹配时拿出value,以分隔符分割value存进一个长度为2的数组
    • for循环数组的区间去匹配接口
    • 代码

    传送门

  • 拉取接口(已完成)20160726

    传送门

  • 移除录制的接口(已完成)20160726

    传送门

  • 意外惊喜

    • 发现了还未登录就请求接口的若干bug,因为未登录请求的Header会缺少参数,服务器JSON返回500错误(有些错误直接被客户端屏蔽了,所以功能测试是没发现的)
    • 之前公司的部分应用部分模块没有内外网之分,导致不敢跑monkey,怕乱发帖子。现在有新思路:通过Fiddler拦截发帖Request header修改参数或缺少字段后请求服务器,服务器必定返回500错误,此时帖子是发送失败的,再拦截Response body修改参数,欺骗客户端发帖成功,进而可以跑monkey

框架的下一步

除以下几点,其余的都是下一步需要做的:

  • Response body的各种参数验证(此阶段简单验证就好,参考框架雏形的经验table)
  • 注入特殊传参接口数据
  • 持续集成
  • Html/邮件通知

关于数据源存储方式的思考

目前的情况:以最简单的方式txt存储

思考:

  • xml存储?那一个接口的所有传参类型怎么存?一个接口多个xml?
  • 数据库存储?
  • excel?
  • 欢迎提供更好的方式

综上所述,欢迎一起探讨!

疑难杂症传送门

Http 接口测试框架疑问解答

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 7 条回复 时间 点赞
Heyniu [Topic was deleted] 中提及了此贴 24 Jul 15:05

判断200后还得再判断下返回的数据吧,有时候返回错误的数据也不行啊

Heyniu #3 · July 24, 2016 作者

#2楼 @jphtmt 这个前面有提到,现在雏形是不判断的,主要用于回归测试,接口在功能测试时期就验过了

Heyniu [Topic was deleted] 中提及了此贴 24 Jul 23:26

你得show出你工具的输入, 输出示例.

Heyniu #6 · July 25, 2016 作者

#5楼 @seveniruby 还在做,现在是概念阶段,先发个思路出来,然后讨论下有没什么问题。
接口录制、索引遍历已经完成了

对expect result怎么维护和更新比较感兴趣

Heyniu #8 · July 25, 2016 作者

#7楼 @simple 目前打算是这样的,录制的接口最终会转换成json的格式,就是一份文件里面多条json,一个json包含多个信息(request response那些),回归时拉取request去请求,请求会被fiddler自动保存起来,然后此时服务器返回的response在与录制接口的预期response(此时的response应该都要是正确性的,对于录制错误的,前面疑问解答有说fiddler右键移除)进行对比,具体怎么对比就看项目需求了(一般都是正则啊,判断大于小于那些,还没想到更好的)。然后每个接口有一个实体(包含各参数),实体可从开发那里获取,既然是回归用的,那么自然这些实体什么的都是维护过的,这是目前想到最便捷的方式。

看了楼主的想法,还是挺不错的,消除重复劳动,可以提升生成率

前几天实现过类似的框架,由于是公司内部的,暂时还没法开源
不过可以交流下想法
个人看法

  • CI,执行效率很重要,需要考虑并行测试.
  • 执行生命周期不建议使用任务的方式,有时候因为程序bug,没有接收到任务,可能无法判断,是否是CI成功.整个设计应该更简单一些,简单更强壮一点.
  • 语言建议选择脚本语言,更新部署比较容易,开发效率也相对较高
  • 将测试分层,基本的HTTP error,可以使用全局控制,集成测试,还是需要写脚本
  • 录制可以作为辅助工具,不可以作为判定标准
  • 提供可追溯的日志,建议结合现有测试框架(xxunit),并且记录http的request和resonse
  • 在测试报告中带上这些日志,可以让程序员马上定位到
  • 数据库建议使用内存数据库,比如mongo之类的,有可能你还需要用到redis.并行测试很可能需要加一些锁.文件有个比较大的问题是需要加写锁
  • 尽可能不要用java,类型转换会使代码量大大增加
  • 建议脱离jenkins依赖,使之可以单独运行
  • 不同环境,可以使用统一配置,然后使用环境变量作为参数传入
  • CI的情况很复杂,最好在整个软件的生命周期里按照一定的频率执行.运营产生的数据可能会使接口返回不可预期.
  • 邮件通知名单可以和项目绑定,并且控制发送策略,有时候邮件刷屏会让程序员忽略.
  • 生产环境做接口测试可能会产生大量对业务干扰的数据,这个需要提前做策略
  • 测试脚本,最好是即放即用的,这就是脚本语言的好处
  • 尽可能不要使用DSL
  • 注意测试框架的强壮性,任何框架错误可能导致大量发送邮件
Heyniu [Topic was deleted] 中提及了此贴 26 Jul 15:26
Heyniu [Topic was deleted] 中提及了此贴 27 Jul 09:54
Heyniu [Topic was deleted] 中提及了此贴 08 Aug 14:29
Heyniu [Topic was deleted] 中提及了此贴 15 Aug 09:48
Heyniu Http 接口测试框架疑问解答 中提及了此贴 06 Dec 16:37
Heyniu Http 接口测试框架之拉取接口 中提及了此贴 20 Mar 11:24
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up