这不累？

到最后自己先疯了

建议在工作之余尝试一下，直接上手框架经常出现为了用框架而做自动化的情况。

上 git，大把开源优秀项目，看下别人怎么写，学着怎么写。

如何在 git 上找 python request 的优秀项目？

不可行对嘛？

目前🈶️两种方案，一个就是上面说的使用 pytest.unitest.二是数据驱动单接口的，这样可以吧

把业务拆分开，一个函数 300 多行，还好吧

如果是发布周期比较长的业务，这个方案能出成果，如果是多变的业务建议先考虑成熟的框架中适用于你当前业务的

……300 行，好难维护了

基于 unittest 框架，已有较为完善的框架，业务耦合性较高时实现起来很麻烦。
例如：我要购买任意产品 --- 前提：1. 获取登录 token or other login 标识。 2. 获取到产品 3. 若需要调整产品相关属性，需要获取请求产品相关信息从产品相关信息钟提取需要的内容。
反正我是为了实现这些东西写了大量额外的通用方法。。。。

嗯嗯，好的

接口多了会累

可行的 如果没有 kpi 压力的话，我是建议新人自己造轮子的，可以练手

是的，如果连接数据库的话是不是会好一些

连接数据库还是要做一样的操作，只是把从业务层获取信息的方式迁移到了数据库操作上。
另外业务层的数据可能是多表联查的数，在效率上可能会有偏差
还有就是直接数据库取值对于业务复杂的信息获取不确定因素可能会更多（1. 数据库钟的值可能和接口吐出的不一致（接口层做了二次处理）。 2. 大量 case 进行执行时高频次调用 pymysql 是否会出现未知问题？）

测试用例里面怎么会有多层次 if else.if ？
除非你不能控制测试环境的数据，要根据返回的结果自己判断然后向下执行，
这样无法保证全部的，哪怕最基本的用例都执行完全；
当然自己练手没关系，但这种 “多层次 if else.if ” 是造带角的轮子;“造圆轮子” 还是有收获的；

当然可行，而且这样的设计更加高效

这样做接口才有意义，我现在业务流覆盖功能测试 1000 多条用例，覆盖率 60%

接口一多你自己都凌乱了，框架简单，易扩展就是美德。昨天又把框架重构了一下，完全遵照模块分离的设计思想，简单易用多了，更加能适应变化了