偷懒了小半年，最近把接口自动化脚本的最后几个需求也都写完了，回头看看，整理整理，写篇文章，做个简单的小复盘。
起因/经过
在刚开始想要写这个脚本的时候，其实目的很简单，就是想提高下自己代码水平，并且在工作中也想体现下自身价值。于是乎，在没有方案，没有明确目标的情况下，就开始着手准备大干一场。
结果下来就是被否认，因为在中小型公司中，jmeter确实比这种调整代码式的接口测试，更来的快些；
第一版，接口自动化纯脚本形式的“脚本”就被扼杀在摇篮里；
暂停了一段时间，从脚本式的入手行不通这条路子，就想着结合web框架， html页面，做成类似工具的东西，方便公司同事使用；当然，脚本的定位方向也起了一些变化：
- 结合swagger接口文档，自动生成逆向用例，做接口的合法性验证
说白了就是对接口的必填、长度、类型做验证；
这次优先做了方案，并且组织评审，内部评审过了以后，就开始了无数个日夜的写bug中；
类似第一版的页面，只做了些许优化
在真正使用了一段时间后，感觉并不是很好用，因为这个版本的脚本，局限性很高，并且每次从页面操作完以后，如果后端代码出现bug，就需要一步步排查，调整，然后在执行。
测一个项目的接口投入比较高，并且自动生成的参数，是没有后参考意义的，也就只能说是表明这个接口能不能通（当时记得定义成返回400或400其他的code值，即该接口是通的。500即失败）；最终这个版本也搁置了；
恰逢每年HW，对系统安全有一定要求，于是脚本就转型，对接口的横纵向越权、接口返回敏感信息校验的目标发起了进攻（此时已经与年初目标，渐行渐远。。。）
开始方案评审、考察可行性、调研各种技术实现，最终，做完第三版脚本
这一版本功能，支持了burp的xml文件导入，解析其中接口出入参，并将这些数据自动生成yaml文件。最后将结果输入在excel表中，当然做了很多小修改，比如可以选择某几个接口跟服务来执行用例等等使用过程汇总的优化（此处省略一万字的废话）；
实践效果：这一版，用起来虽然能用，但是不不好用；一方面是用例管理，不好管理，对于使用人来说就是个黑盒，另一方面就是在想要替换入参时，就需要跑到yaml文件中替换；
解决方案：通过数据库解决这些使用中问题，将用例、接口等这些关键参数入库
既然选择要入库，就索性做一个前后端分离，学习了一段时间vue后，把页面操行也做了优化，后端使用flask-restx扩展，将之前的逻辑实现成接口形式；
目前为止的版本：
功能：
- 用例管理
- 解析burp出入参，并将其请求参数，作为用例入参保存
- 根据配置文件的测试用户，自动生成一条该用户下相同的参数用例，从而实现流量重放，验证该接口是否越权
- 普通用例的增删改查以及关联所属接口
- 接口/环境管理
- 接口的增删改查
- 用例报告
- 实现报告文件展示、下载、删除
- 执行某服务下所有用例或者选择接口，执行部分用例
这一版本，满足了我们对接口横纵向越权的基本验证，通过单一入参，替换不同的用户，校验接口是否拦截
也满足了接口返回参的敏感词是否加密，通过正则的形式，匹配出参是否包含用户敏感信息
至此，这个脚本画上了一个阶段性的句号
回头看
在最后一版评审会上，演示完当前脚本的实际效果后，当时感觉还是很欣慰的，经过自己努力，独立完成了一个小项目
过程中，不乏有抓耳挠腮、解bug解到半夜、心生放弃，但最终还是做了出来。对于我个人而言，还是有很大提升的；不管是从测试的思维角度，还是代码编写上；并且在这个过程中，也会记录踩过的很多坑点，以及解决方案，是一笔很大的收获吧
在需求沟通以及工具定位上，还是有待提高，首先需要明确工具定义，以及初期目标，做着做着，初期目标就做没了，是有点。。。
其次时做好蓝图；在开发初期就要做好技术方案，内部讨论过后，再实施，避免拍头效应，之前的工作都白费；
最后就是感谢自己没有放弃这个机会，尽管过程中，有很多头大的事，但静下心来，都得到了解决，对于以后得工作，在软实力上也得到了提升
结语
最后的最后，就是希望几年后的自己，看到这篇文章，笑骂着SB并发自内心的感谢
多做项目，多做项目。多做项目！！！！
