这里只是我聊聊，代码贴的并不多，开聊以前先说下，我叙事的路线：

1. 我准备怎么做 ，理由是什么？
2. 如何做，做后发现什么问题？
3. 总结

1. 我准备怎么做 ，理由是什么？

以往的工作种使用过 接口测试的方式和方法，Jmeter Java Request/ BeanShell/ Java Rest Assrued/Python Requst 以及去年说过的Hitchhiker API 测试平台践行等等....等等... Java 语言 JS 语言 Python 语言各种；至于为什么尝试这么多什么原因：1.有为了解决接口签名问题的 2.有单纯就是觉的比较简洁，3.有页面看起来很高大上。。
最终总是感觉有点厌烦，写完一个月后，再回头看自己写的东西，总感觉是坨屎，感觉都缺点啥；后来无意中看了这本书

对其中的一点 BDD 实践小有体会
结合自己的实际情况，本身我自身中小公司待的比较多，公司大多是业务驱动；业务快速试错，迭代速度快强度大，你说要复用以前的东西嘛；必须以前的人写的好，写的至少让后面的人看的懂吧～不然下次迭代想起来用的时候，就悲催了，自己砸自己脚的事情，我还是遇到不少次的；虽然框架规范了写的模式像单元测试框架 Junit Unittest 以前用这种框架特别多，但是现实是：10 个还好，100 个眼花撩乱；而且要这些人写注解那就是对牛弹琴，少了点中文，看着难受要死
所以打算转 BDD，就朝这个方向搜索学习，查了一下也不复杂 Python / Behave +Request ，心里美滋滋～

2. 如何做，做后发现什么问题？

这就开始新建工程，简单考虑了一下：（这里也包含后来工作中完善的功能）
1）每个请求 响应 要 打印
2）返回 数据 解析，要 异常处理捕获
3）测试/线上环境 配置
4）token/uId 类似这样固定的，一般需要提前准备的死数据
5）还有一些活数据，就是可以按一定规律代码生成的数据
6）上面这些数据存个 CSV 文件/Pickle 持久化一下还是需要的
7）必要的时候，咱需要直接查个数据库/redis 缓存
8）测试数据，跟请求字段，数据组装

陆陆续续为了满足自己的需求，在工程目录 utils 包下有了下图这些模块：

也不是很多，我闲的统计了一下，现在这几个文件写了也就 400 行代码
到这里工程目录结构说一下吧：

• conf 环境配置
  • 不同项目创建一个文件
    
    • env.ini （下面有截图/没啥就是 DeBug 开关 日志标示/域名/等等/都是硬东西，都不咋变的...）
• features（了解 behave 的应该都是到，这个看官网不说了）
  • 不同项目创建一个包
    • steps（这个也是 behave 框架的一部分）
    • utils （这个是不同项目下的私有 utils）
    • server（这个放 业务数据库 的查询，也可以说是 DAO）（用词没错吧～）
    • test-data（这个是文件夹不是包，存 csv 格式测试数据）
    • request-body（这个请求字段示例文件）一个.json 文件
    • features 文件（可以写中文哦）/ environment 文件

features 是描述文件，也是执行的入口，给大家看一下，大多数都这么短

不过也比较长的，例如玩个游戏，第一次 第二次，第三次 传不同分数 结果不一样 集成度高一点

姿势有很多种，代码什么都能实现；已经玩了有 7 个项目了
不管代码怎么写，feature 文件最终都会告诉我，在做什么，为的是什么～哪怕 2 个月后我再看也不蒙蔽
而且即写即用，维护反到觉得比其它工具舒服，而且还有一个我个人原因，代码不会生疏了；如果换在游戏里面，就是自由度高～
可以遇到很多场景，在工作中有锻炼：
例如：

1. 写一个程序按一定规则生成 数据存储于 CSV：日期不重复，长度大于 20，小于 20（批量 3000 条）
2. 按 给出的请求字段示例.json 文件，组装请求 Body：要注意数据类型，JsonArray 的组装（批量 3000 个）
3. 查询业务数据库，校验 响应参数 是否正确

还可以改一改，我后来又在有些项目下，用协程的写了一个小压测；结果在写入文件：简单轻量～应付一些日常轻量的工作，也没必要杀鸡用牛刀了～

3. 总结

总体这么做的原因主要还是，以前看过同事写的，实在是参差不齐，而且不知道目的是什么；有种见光死的感觉，代码写起来有激情无实用；没有从业务出发，贴近业务逻辑；业务校验少之又少；测试目的性不明确（这里纯属抱怨......😄，其实还是有写的不错的）
目前这个用了小半年，感觉良好（自己的东西，就是感觉自在）～好吧，就聊到这里了～有不对 的地方欢迎大家来踩！