接口测试 Http 接口测试框架 (思路 + 实现中 + 开源 + 可能难产)
写在前面
有时间我会把我初步的想法整理好分享出来，大家一起来探讨它的可行性，它不一定适用你们的业务，但是非常适合我项目的业务。虽然它也可能难产，但是我想尽力去做、去完成，也算巩固一下自己的知识，应用到项目中去。
这个框架需要大家不断的鞭策、一起努力、共同搭建，可以随时发表看法，欢迎拍砖，求不打脸！
它为何而来？
- 团队项目流程的规范，团队下一步的目标就是接口测试
- 一款应用上线前要测试 3 次服务器（接口一样，环境不同），纯手工验证是受够了
它能做什么？
- 简单的接口测试（主要回归测试）
- 持续化集成
- 接口日常监控
- 可能还有？
缺陷？
还没想，相信你们阅读后就会帮我回答了
框架整体思路
跪求积极发表看法、框架还在萌芽阶段、确保方向细节处理。
天啊撸，又是 Java
没错就是 Java，可以是其他吗？可以，你熟悉的语言都可以，首选 Python，用过的都知道
Java 的考量：
- Python 很久没碰了，忘的差不多（真相是原来水平就入门级还不到吧）
- 项目是 Java 开发的，http 框架是基于 okhttp 的二次封装（不以项目为导向的都是扯淡）
- 前面发现一个 http 框架的 bug，想看下还有没有什么没发现的 bug，特别是多线程的时候它的单例会不会有问题（功能测试一般遇不到 http 框架的 bug）
框架雏形
没错，这个框架已经在默默地搭建了。
目的：通过简单的接口验证发现服务器接口异常
经验：一般认为Response body code为 200，则表明该接口无改动（试用目前的项目，总结的经验）
实现：判断每个接口的Response header code，如不是 200 则接口失败（常见 code：404/502，302 情况说明，因为是 API 所以应该没有重定向的，基于目前的经验判断，欢迎指正），再判断Response body的JSON里面的StatusCode是否为 200，不是则初步判断接口失败，最后查看失败的文件即可
评价：速度慢、手工录制、简单回归、简单验证
关于代码：明天补上
目前的情况汇报下：
-
接口录制（已完成）
- 通过手工录制/monkey 录制
- 数据源录制时机：功能测试过一遍后，一般此时服务器接口比较稳定
- 自动保存每次请求的 URL，用于与索引器遍历，得出Diff文件
- 自动保存每次请求的 Request header、Request body、Response header、Response body
- 考虑加入统计每次请求的耗时
-
索引器思路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？
- 欢迎提供更好的方式
综上所述，欢迎一起探讨！
疑难杂症传送门
判断 200 后还得再判断下返回的数据吧，有时候返回错误的数据也不行啊
你得 show 出你工具的输入, 输出示例.
#5 楼 @seveniruby 还在做，现在是概念阶段，先发个思路出来，然后讨论下有没什么问题。
接口录制、索引遍历已经完成了
对 expect result 怎么维护和更新比较感兴趣
#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
- 注意测试框架的强壮性,任何框架错误可能导致大量发送邮件