每种语言都有覆盖率统计工具。 主要看被统计的是什么语言开发的项目:
覆盖率统计工具一般是需要在代码中插装的,不同语言插装方式,甚至统计方式也会有差异。 不存在一个工具可以做到所有语言的覆盖率统计。
如果有也一定要提供 相应语言的 插件。 类似 allure 的思路,之所以做到 不同语言、单元测试框架的支持,需要对不同的语言开发 相应的插件,使他们生成统一的测试结果的数据格式,然后,由 allure 解析展示。 --- 我这里 扯远了 。
针对主流的 API 测试工具做的深度对比。如果你们需要调研 API 工具看这份报告就够了。这些工具都是当前比较优秀的 API 自动化工具。表格中的对比维度非常多(几十个维度吧)。没有哪个工具有全面的绝对的优势,每个公司和团队的需求不同,请根据自身团队选择。
什么利益链条? 我帮你说了,在线培训,这个是见不得光的 违法行为
吗? 你可以认为是 没有技术含量
和 割韭菜
。那你怎么不 打击 各种幼儿培训。一个幼儿英语收费 几万,不更是 没有技术含量
和 割韭菜
?
之所以 认为是 年轻人
, 是我主观认为 年轻人 才有可能 会年轻气盛,看不上我们这些工作了 10 几年的 老人
。如果同为工作多年的老人,不是应该惺惺相惜吗?在这个大环境不好的情况下,很多人找不到工作的情况下。 为什么别人辞个职就会引来嘲讽?
最后,我跟 狂师 也没有任何 利益 关系,唯一的 交流时 帮 RF 写过推荐,他赠送了一本 RF 的书。此外,我早不开线上培训。你可以继续恶意
猜测,我们还有什么利益链条?
@ 小黑子
关注的有 狂师 的公众号,很少有 RF 的分享,更多的 python 相关的框架和技术。 至少 说明 他的技术不局限于 RF,为什么会觉得 这辈子 只能靠 “RF” 这个技术过活了?
其次,你提到了 AI 跟他的行业没关系。那么你一定是从事 AI 相关行业的 开发和 测试? 如果是的话,恭喜你,站在了这个赛道上,希望你走的更远。 如果不是的话,在面对 AI 相关技术的学习速度上,我更相信作者学的更快,长期保持学习和分享的人可能学的更快,除非是遇到特别高维度的知识和技术
。 你在傲娇什么?你更年轻所以学的更快吗?
最后,不太可能能回到原来的薪资水平
, 马云/ 王健林
的 资产缩水严重,赶紧去嘲讽他们,他们不太可能回到 首富
的位置了,影响他们座私人飞机了吗?
最后,我不觉得辞职是勇气
,就是人在不同的环境和阶段,做出了自己想要的选择。对的也好,错的也罢!自己承担这个结果。只不过,这个时代包容性太差了,潜台词是 你拿着那么高的工资,怎么敢辞职?
不允许人有除了 钱
之外的任何追求。
本来打字说原因,后来发现写过一篇文章。直接贴给你。https://mp.weixin.qq.com/s/x9r9ryNu4Ha30lJkWWSavA
seldom 官网也有 seldom vs pytest 对比:https://seldomqa.github.io/introduce.html
docker-selenium 提供了 selenium 的运行环境(包含浏览器和驱动): https://github.com/SeleniumHQ/docker-selenium
至于 selenium 脚本,因为这个脚本时长需要改动,想不到放 docker 的目的; 更应该考虑 集成 CI 吧~!
seldom 应该是非常适合你的!
同样基于 unittest 单元测试框架, 对于你来说几乎无成本。
接口测试非常需要数据驱动,seldom 提供的数据驱动:支持 class_data()
装饰类、data()
装饰用例, file_data()
支持 json\yaml\excel\csv 文件。 api_data()
支持接口数据,甚至数据驱动文件可以做环境区分。
https://seldomqa.github.io/getting-started/data_driver.html
集成 XTestRunner 定时化报告,美观不输 allure(unittest 也可以直接使用 XTestRunner)
https://github.com/SeldomQA/XTestRunner
楼上提到平台化,seldom-platfrom 可以将 seldom 自动化代码解析映射到 Web 平台上,
看不出它的优势在哪里?
结合了框架和平台各自的优势: 用框架
写用例,我认为是优势; 用平台
展示用例,执行用例是优势。(相反,尝试用平台
写用例,解决复杂的用例更复杂,我不认为是优势。)
省了哪方面的时间?
这套方案,相比其他自动化方案 可能没有什么节省时间上的优势;
谁是你的目标用户?
需要做自动化的测试团队。
懂代码的还是不懂代码的?
必须懂代码啊~!不懂代码咋写用例?
我来简单介绍一下背景:
接口测试平台我们做了三版,文章有介绍过: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 对用例的解析和展示。 --- 这是一整套 自动化的解决方案。