写在前面
衔接前面的传送门
有时间我会把我初步的想法整理好分享出来，大家一起来探讨它的可行性，它不一定适用你们的业务，但是非常适合我项目的业务。虽然它也可能难产，但是我想尽力去做、去完成，也算巩固一下自己的知识，应用到项目中去。
这个框架需要大家不断的鞭策、一起努力、共同搭建，可以随时发表看法，欢迎拍砖，求不打脸！
它为何而来？
- 团队项目流程的规范，团队下一步的目标就是接口测试
- 一款应用上线前要测试 3 次服务器（接口一样，环境不同），纯手工验证是受够了
它能做什么？
- 简单的接口测试（主要回归测试）
- 持续化集成
- 接口日常监控
- 可能还有？
缺陷？
还没想，相信你们阅读后就会帮我回答了
框架整体思路
跪求积极发表看法、框架还在萌芽阶段、确保方向细节处理。
天啊撸，又是 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 body的JSON里面的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 接口测试框架疑问解答
↙↙↙阅读原文可查看相关链接，并与作者交流