Python Python+unittest 的接口自动化

sunzhang · 2023年07月10日 · 最后由 Mr.Li 回复于 2023年07月27日 · 5902 次阅读

我的框架介绍,主要分一下几个部分


-公共的方法封装,都放在 common 中
-配置文件放置 conf 中
-业务中涉及到重要方法放在 CommonFunc 中
-测试数据放在 data 中,用表格形式呈现

-日志放在 log 中
-报告在 report 中
-最后用例放在 testcase 中

### 我的疑问点
-用例与用例之间代码重复度比较高,因为大致的步骤都是:获取用例数据,替换参数,调接口,断言,只是存在微小的差异
-有些接口依赖的数据比较广,那么涉及到调用各种接口来满足参数,就会存在堆高楼的现象,本人感觉似乎不太妥
-对于 testcase 中,如何去减少代码维护,是不是写用例之前得先分清各个接口的共性,同一类的放在同一个 testcase 中

希望有大佬帮忙提点提点🙏🙏🙏

共收到 17 条回复 时间 点赞

我先抛砖引玉说说自己的看法,有大佬分享麻烦踢我一脚
1.你是通过不同的用例文件执行读取不同的 sheet 表名来各自取数据吗?那每个文件除了定值(sheet 名或其他)都不该有差异,要做到复制粘贴即用
2.我觉得可以先执行一些接口获取大量必备数据存储到主配置文件中,然后后续接口需要就读取,想用自己的就自己执行然后保存到小配置文件读取
3.不同用例文件只要变的地方只有定值,可以将所有用例文件继承父文件,父文件来写执行逻辑

@ 木小白 ,非常感谢大佬!!!
上面的 1,我的文件,表头都是一样的,表里的值可能都不太一样,比如接口名,参数,预期等,这些都不一样,不能直接复制黏贴,怎么做到复制黏贴呢

上面的 2,我是写了公共的业务方法,需要的时候调用一下,然后用 setattr 存放在临时变量里面,用的时候直接拿,这一点跟你的原理很类似

上面的 3,不太懂你说的文件继承父类,可有例子供参考呢

seldom 项目看看学学

sunzhang 回复

接口名,参数,预期,这些应该控制在 excel 上,文件中只能修改定值。父类的话就是子类继承父类,会拥有父类的方法,知道这个原理,在父类写好 before 和 after,子类只需要继承,就不用自己写了

浅谈下我的观点:
第一点:测试用例里应该全是用例的数据,可能某个参数一样,导致接口返回的结果不一样,这样只需维护好你的 Excel 表就好,这跟代码没有关系。除非你的框架并没有解决用例和代码分离的问题。
第二点:关于一个接口需要依赖多个接口的问题。其实我想到有两个方法,第一个方法是控制用例的执行顺序的方法,先让依赖的接口执行,保存你需要的数据,然后再执行。第二个就是写个方法,用来判断当前用例是否有依赖的接口,如果有就先执行依赖的接口,等依赖的接口执行完成,数据都拿到后,再执行当前用例。当然这种方式最好给每个用例编写好编号,以便于调用。
第三点:对于 testcase 中,如何去减少代码维护,是不是写用例之前得先分清各个接口的共性,同一类的放在同一个 testcase 中。这个应该在你的公共方法类中对不同的接口类型进行封装,比方说 JSON ,PARAMS ,DATA ,FILE ,EXPORT,NONE 等,然后在你的用例标识出来,不用的方法走不通的逻辑。

木小白 回复

感谢大佬的不吝赐教!!!,似乎明白了父类继承的原理,目前我的代码确实有很多重复性的

ZW 回复

感谢大佬指点!!!
第一点:我的代码是跟数据分离的,但是代码中涉及各类断言,有些接口不一样断言方式也就不一样,是不是要把断言方式也封装成公共方法?

第二点:使用执行顺序,在调试的时候是不是不太方便,我采用的是如果需要依赖,我吧依赖的接口封装成公共方法,在执行接口的用例的之前先执行 这个公共方法,拿到需要的数据,对于加个依赖标识,觉得这个主意很棒,我现在貌似是写死了,有个标识的话可能灵活一点

第三点:你这么一说,我的的用例分类貌似有问题,我的分类好像都是业务模块分类,导致 testcase 里面出现很多重复性的,大部分重复在于获取用例数据,然后发起请求,而区别在于提取数据做断言的部分,最近才对获取数据用例这块封装了公共方法,现在直接调用,是不是也要考虑吧提取数据以及断言分别封装成公共方法

干饭狂人 回复

seldom 项目确实没有了解过,感谢大佬的建议

命名能不能统一风格啊,看得强迫症犯了

sunzhang 回复

第一点:断言的确需要封装,因为接口测试中涉及到的断言种类很多,包含,长度,大小,相等,正则匹配,以及还有数数据库断言等等。
第二点:依赖封装成公共方法,这样的话你的用例最好有个编号。然后每次执行依赖就可以直接调用该用例,并且这个用例也可以用与其他接口的调用,避免重发劳动
第三点:我觉得你的框架这块需要优化下。获取用例数据生成可执行文件这块应该是公共方法,通过你的 excel 直接生成 py 文件,你的重心应该在于用例的设计。我现在感觉你在生成这块浪费的时间比较多,有点本末倒置的感觉。建议可以去看看开源的接口测试项目,了解作者的思路可能对你有些帮助

过来人给你个建议要搞就搞 pytest,不要在 excel 上浪费时间,不要自己造轮子,去看 httprunner 源码

ZW 回复

感谢大佬的宝贵意见,你的第二点意见很赞,我的用例有编号,但是就没有想过利用这个编号来完成依赖
第三点说到我的痛点了,开源项目可有推荐的啊

注意,本菜鸡要开始胡说八道了

是不是给用例加上一个 “用例类型” 会比较好一点,比如隶属于什么模块属于什么业务链之类的。同时用例中添加一个 “使能” 字段方便暂时排除某些用例,这样维护的时候组织用例的时候要用的时候就打开,不用的时候就关上。

我可能说不到点上,但是我感觉代码框架不一定是问题来源哈。就目前看来,似乎你的问题都能通过用例设计去解决哎。不知道我有没有表达清楚

sunzhang 回复

gitee 上面有很多,你可以看看

Vanessa 回复

很同意这个观点,找一个好的开源项目,然后取其精华应用到自己的项目中,比自己从头到尾造轮子收货要好很多

你这个框架分层好粗糙啊 😂
建议你分三层,公共 API 一层,业务 API 一层,测试用例一层。
每一层都是一个独立的 python 包,这样你再加入新的产品、新的业务 API,就可以做到很好的封装和隔离。
测试数据和测试配置 conf、测试报告都归测试用例那一层。
测试用例的上一层就是测试执行器,也就是你的 run_test.py

你的测试数据如果不是成百上千,你就不要放到 excel 里面管理,直接放在普通文本里面,或者直接作为 python 的变量来储存就行了。一个 Pycharm IDE 就可以管理,非要去打开几个 Excel 占内存干什么。
另外一种变通的做法就是,你把你的接口定义的默认值放在 excel 里面 (注意这个 excel 以后都不动,除非开发增删改了接口),然后在测试用例里面对这组默认值取相对变化的值 (自己实现一个函数),来形成同一个接口的各种各样的测试参数。

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