自动化工具 httprunner 3.x 为啥要取消 api 定义这一测试分层?

sq876 · 2020年09月28日 · 最后由 L 回复于 2020年11月26日 · 355 次阅读

2.x 的设计思想感觉很优秀,3.x 感觉增加一个 py 文件的生成就可以了,为啥设计思想也要发生改变,最小粒度不是 api 定义,变成 testcase 了,那么每一个 api 调用的校验都要放在 testcase 里面,这样很不方便啊,一个 api 可以有不同参数的调用和返回,感觉这个设计改成这样很鸡肋
一般的后端框架,都要把 api 定义拆出来的,方便复用

共收到 8 条回复 时间 点赞

降低上手难度吧,如果像后端那么封装,可能有些测试就不一定看得懂了😂

什么时候才能把这个问题修复一下:https://github.com/httprunner/httprunner/issues/1008
--dot-env-path #1008 这个参数不支持了,很不方便在 jenkins 上跑配置化

我想吐槽下 httprunner 每个大版本更新,都不兼容之前的用例,3.x 已经看不懂了😂

4楼 已删除

3 版本的用例用 py 格式自己抽象出 api 层也是可以的,我就是这么干的。感觉更灵活了

测试团队的差异性决定了对测试分层有不同的需求,这个不用纠结吧。
3 不好用就用 2 呗

娃哈哈 回复

我们目前也是抽象出来 api 的,但是只能做场景级的测试,单接口不能用的,因为要写死返回值

有一个场景我没搞懂,如果只是创建、删除、更新 3 个独立的 case 运行是没有问题的,但我们做自动化的时候一般都要清理数据,那么我在创建的 case 用例步骤里面 call 一个删除用例,这样来删除数据?如果是删除的用例呢?如果我一个用例里面包括创建、删除、更新呢?

娃哈哈 回复

你这个是把 3 手动变成 2 了吧?

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