最近小弟做出了一款基于 mitmproxy+yaml 文件的接口测试自动录制工具，也可以说正在研究之中，希望和大家分享讨论

先说一下基于我自己对接口自动化测试框架的理解（下面提到的的自动化都为接口自动化,存储数据暂时都用 yaml 文件）

第一种是 api-testcase-yaml 框架，就是将所有的接口都封装成函数（api 层），之后所有测试用例的组合，都是 api 函数的编排组合 + 数据驱动
这样的好处是，用例可以自由定义，后续如果接口有修改，也只需要修改相关接口

第二种是 半 api-testcase-yaml 框架，将所有超过一次使用的接口封装成独立 api，可以被其他用例引用，如果只用一次则直接写
对比第一种可能会更简便一些

第三种是 我最近在做的录制-yaml 框架，用户开启录制后，只需在界面上点点点操作过，就可以把录制的用例存进 yaml 文件里，并且实现参数自动化转变
这样的优点在于快速启动，不需要写一点代码，也不需要封装接口，速度很快

其实我一边在做的时候也一边问一些朋友和大佬们的意见，然后做了一些改进和想法，但是觉得有的想法很别扭所以还是想请大家一起讨论指点一下
先大致讲一下原理：其实原理也有一些简陋，可能只能覆盖大部分的场景。首先是通过 mitmproxy 通过代理抓取请求信息，这样我们就得到
一个全都是 api 信息的列表，每个 api 信息都是字典的表现方

然后先通过 dfs（这一步借鉴了米洛大佬的 pity 平台的做法），找出所有相同值的路径关系列表

然后再通过对这个列表的观察和分析，反写回原来的请求信息列表，并且第一个值用 key 表达，后续的值都用第一个 jsonpath 表达式来代替

然后存入 yaml 文件，这里录制的功能就差不多了

后续就是使用播放的部分，先取出 api 列表，然后根据 title 名字是否相同来判断是否是一条用例，然后分用例执行也可以选择用例执行

每次执行一个接口，都会覆盖模板列表，并且用另一个模板列表去找值

对比 api-testcase 框架的提问：
问题 1： 如果后续接口修改怎么办
回答 1： 今天已经成功实现修改某个参数名称并同步修改所有引用到这个参数的地方

问题 2： 如果增加和删除参数，然后下游接口又用到这个参数
回答 2： 退一步来讲，其实删除参数对接口请求并没有影响 qaq，一般接口都是允许存在不需要的参数的把
然后如果删除一个接口，又新增一个接口，那是不是和修改有点类似，或者单独新增一个参数，但是没有被引用到其实也已经实现了
但是后续更复杂的修改我已经蒙圈了，有点不知道从哪里想起

问题 3： 怎么实现用例断言
回答 3： 目前的思路是，因为其实录制下来的接口信息里就包括了请求响应，这部分是否能拿来当作断言的样本呢

问题 4：如果有一个单接口有一百个参数需要校验
回答 4：应该只用录一次把，因为一般必填都有前端校验，不管录多少次也只能录一种情况，
所以我觉得可以通过对录制的信息进行手动或者自动地写修改参数地测试用例
目前思路是手动就是在 yaml 里复制修改，自动就是写一个规则，根据提供的字段进行对应用例的生成

问题 5： 是否支持 sql 查询，sql 断言
回答 5：暂时不支持 sql 查询语句的添加和 sql 断言，我们确实有遇到某个接口并不直接返回项目 id，但是其实可以通过其他接口查到
因为前端能拿到这个数据，我们就一样能拿到，除非是有这种场景：他只能在数据库里查到，但是前端用不到 -- 那么是不是某种意义上来说客户也用不到呢哈哈

问题 6： 这个是我自己想问的，就是大家觉得这个是否有一定的意义（因为其实一路做过来很多人都说，不现实，有空研究这个，还不如研究流量会放）
我自己的想法是希望他不仅能在启动项目上比 api 框架快，并且也能有 api 框架优点的能力，那应该从哪些地方去丰满他，或者大家有哪些意见和构思欢迎指点，虽然我知道很可能他是一个伪命题，但是反正就是在自己能有能力和时间的情况下尽量去完善和尝试去做
ps.由于目前还在公司试用阶段，部分功能也还在持续修改更新种，并且项目数据还没有剥离，所以暂时还不能开源抱歉。后续有机会一定会分享给大家（如果有人想要的话）