自动化工具 纯 python,requests 根据接口写业务逻辑是否可行?

json · 2018年04月11日 · 最后由 1281480917 回复于 2018年07月08日 · 2059 次阅读

纯python,requests根据接口写业务逻辑是否可行?
多层次if else.if elif😅😅😅😅

共收到 22 条回复 时间 点赞
json #1 · 2018年04月11日 作者

😢

这不累?

到最后自己先疯了

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

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

0x88 回复

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

json #7 · 2018年04月12日 作者
cscomic 回复

不可行对嘛?

json #8 · 2018年04月12日 作者
0x88 回复

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

json #9 · 2018年04月12日 作者
layasa 回复

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

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

json 回复

……300行,好难维护了

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

json #13 · 2018年04月12日 作者
cscomic 回复

嗯嗯,好的

json #14 · 2018年04月12日 作者
jphtmt 回复

接口多了会累😂

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

json #16 · 2018年04月12日 作者
junyjiang 回复

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

json 回复

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

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

仅楼主可见

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

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

junyjiang 回复

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

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册