看不出它的优势在哪里?
结合了框架和平台各自的优势: 用框架
写用例,我认为是优势; 用平台
展示用例,执行用例是优势。(相反,尝试用平台
写用例,解决复杂的用例更复杂,我不认为是优势。)
省了哪方面的时间?
这套方案,相比其他自动化方案 可能没有什么节省时间上的优势;
谁是你的目标用户?
需要做自动化的测试团队。
懂代码的还是不懂代码的?
必须懂代码啊~!不懂代码咋写用例?
我来简单介绍一下背景:
接口测试平台我们做了三版,文章有介绍过:https://testerhome.com/topics/20084
对于我们公司的业务测试来说都不算好用,虽然第三版比较强大,但编写复杂的场景测试,需要借助辅助功能写很多 py 函数(类似 httprunner 的 debugtalk.py 文件里实现函数)
那既然用平台还不是要写代码,为什么不全部写代码? 于是,全部业务测试开始使用 seldom 框架编写用例。使用 gitlab 管理 接口自动化项目。 我们公司的业务测试是乐于接受这个方案的,面试的时候就考察了编程能力。 --- 你本地使用 pytest/unittest 写自动化,难道不会 debug 吗?
业务测试人员用 seldom 框架写自己负责模块的用例, 不受制于平台的功能限制(代码可以随意安装扩展库)--- 这对我们来说就是优势。 这也是框架
本来的优势。
你们可能又想,我们写好了代码 集成 jenkins 上面不一样可以 自动/定时触发执行,生成结果。
那 seldom-platform 平台的优势可以自动解析和展示每一条用例。统计历史执行结果; 我们公司基于 seldom-platform 的思路做了 产线拨测 系统; 那用例需要审核, 创建任务的时候可以选择 test_a.py 文件的一条用例 和 test_b.py 文件的一条用例... 这种管理用例的粒度,jenkins 估计做不到吧? --- 这不是刚好发挥出了 平台
应该的优势吗?
适合自己团队的就是最好的。
另外再说一下:
seldom-platform/seldom 解决的不不单纯是接口自动化问题;可能文章大量提到了接口案例,误以为就是为了解决接口问题的;seldom 支持 web/app UI、接口,写什么用例都可以;多复杂的场景都可以;这个框架的优势; 并不影响 seldom-platform 对用例的解析和展示。 --- 这是一整套 自动化的解决方案。
你只看我抛出的问题,没看看 seldom-platform/seldom 方案? 你说提到的问题是 seldom 框架中实现的,怎么实现取决于你的业务和方案; seldom-platform 只是用于展示、解析、和执行用例,并不限制你用例如何写。
首先,感谢 @taylortaurus 发帖:
我来补充几点说明:
虽然图中的截图是 接口自动化项目。但理论上通过 seldom 编写的各种类型的测试都是支持的, Web/App UI 自动化测试也可以; 不过 App 测试环境相对复杂,比如 后端需要 启动 appium server 。
图中解析用例 不是单纯的 把目录下的文件/类/方法
解析出来,一个项目中 有各种.py
文件,比如 common/utils
放的公共模块, 甚至在测试类中也有 普通的 不以 test
开头的方法, seldom 可以做到只解析测试用例
。
用例解析不依赖 seldom-platform
,这是 seldom 框架的能力; 比如,我们公司 后端用 go 调用 seldom
命令来解析和执行用例。
seldom-platform
是开源项目,有些人参与了走了,有些人贡献了想法,有些人贡献了代码,非常希望更多人参与贡献想法和代码; 你看不上 UI 可以自己 fork 分支,重写 前端/ 后端都是可以的。
好的轮子是需要时间打磨的。引用前两天在知乎看到的观点;
你想造一个满足 特定 项目 的特定场景轮子很简单;
你想造一个满足所有项目的特定场景的轮子有点难。
你想造一个满足所有项目的所有场景的轮子就很难了。
拿我自己维护的 seldom 框架为例:框架封装了 MySQL 数据库的调用,本来我们公司只用 MySQL,甚至我待过的公司都用的 MySQL, 但是,有人 就要 用 Mongdb,还有人要用 SQL Server...
随便造个轮子自己用用无所谓;如果想开源,想给所有人用,那么就要做好长期投入的准备。
社区里大部分项目都是开源三分钟热度的那种!seldom 敢说不是,虽然 不完美,有一些天生缺陷;但一直在迭代;已经满足了自动化测试的大部分需求;
与其自己造轮子,不如参与到一个轮子的开发中。
SeldomQA 包括框架和平台,是自动化测试的一整套解决方案(今年已经在我们公司落地)。
https://github.com/SeldomQA
希望更多人参与进来~!我会毫无保留的和你们交流 经验 和 设计思想。
第 1 个问题可以参考这篇文章:https://www.cnblogs.com/fnng/p/15554203.html
你在用 pytest 框架 写 自己的 业务测试用例,并且 对 selenium 的 API 做了简单的封装,并使用了 PO 设计模式。
框架设计
被用烂了,作为公开框架,应该具备:
框架提供独立的安装,pip
安装 或 exe
安装程序,或别的独立的安装程序。至少应该和业务代码剥离吧!
框架的版本号,有版本号才能更好的迭代和维护。
框架的 API 和 文档,如果是给别人用的话。
-- 无意冒犯,只是更正一下业务代码的设计
和 框架设计
的区别。
@ 不声不响 这里不讨论 quick 平台的功能,他仅用于学习,很多功能没有,也不稳定,可以社区的其他接口测试平台。
备注:关于测试平台,我们有一些新的想法,可以留意这个项目:https://github.com/SeldomQA/seldom-platform
我们测试平台做了三版,我之前有文章做过介绍,第三版类似于 httprunner 的 web 版,http://testerhome.com/topics/20084
今年重新用回框架,我们公司的接口自动化流程比较长也挺复杂的,例如 获取一些 token 信息(不仅仅登录),用到一些数据加密,需要通过秘钥链接查询数据库。UI(web 界面的功能)不能完全满足需求,为此用 python 写了大量的函数(类似 httprunner 中的 debugtalk.py 文件作用),在用例执行的过程中调用。当然,这些东西都可以 web 设计到系统了。但总之,开发平台的人力不足,业务测试团队又觉得难用,所以,使用率一直不高。
另一个很重要的诉求,测试人员自己需要成长空间。他们更愿意通过框架更加灵活的编写测试用例,也更能从编程中得到技术提升,从而带来一些成就感。改用框架之后,积极性都高了很多。
seldom 有强大的参数化(@data()
/@data_file()
)功能,其实可以很大限度降低编写重复的代码。所以,对于熟悉编程的同学,编写接口自动化的效率是高于通过平台去创建用例的。
当然,我们也并未完全抛弃平台,平台的主要作用是拉取项目代码 在远端执行,并解析报告在平台上展示。也可以通过平台执行测试。
总之,这是一个目前双方都接受的方案
这肯定不适用于所有公司、所有团队。