× You cannot access banned topics.
前言
本篇文章,会详细分享,我搭建的关键字驱动自动化测试框架的整体技术架构组成,以及思路方案。
有建议的都可以畅所欲言,感谢!
技术架构
Python+ selenium + Excel 关键字驱动 + pytest + openpyxl + yaml + ddt + pillow + logging
功能点
通过编写 Excel 自动化测试用例,每条用例使用对应的关键字函数,实现自动化;
自动化执行过程,记录执行时间,输出执行结果,如遇执行失败,自动截图;
自动化用例执行过程,全程录制画面,用例执行完后自动保存为 GIF 图片,方便回顾执行过程;
自动化用例执行过程中,输出日志,并自动保存;
自动化用例执行前自动进行文件备份,原因是,有时候我会强制中断执行,这样可能会导致 Excel 文件损坏,那我写的用例就又得重新写一次;
自动化用例执行结束后,输出 allure 报告;
框架支持配置,如:
a. 指定当前运行环境(生产环境:prod,测试环境:dev),目前是两个作用,第一个是切换不同的环境,可以运行不同的项目地址;第二个是切换不同的环境,会使用不同的变量参数,如登录账号密码;
b. 指定执行浏览器,如:chrome、fixfox
c. 指定断言失败后,是否继续执行后续用例
项目结构
allure-report(allure 报告)
config(项目配置)
-- init.yaml(项目配置)
-- data.yaml(变量参数)
library(关键字函数库)
-- library.py(关键字函数)
logs(日志)
screenshot_gif(用例录制)
screenshot_imgs(用例错误截图)
testcase(pytest 测试用例)
-- testcase.py(pytest 测试用例)
testcase_data(Excel 自动化测试用例)
testcase_data_temp(Excel 自动化测试用例备份)
utils(工具库)
-- excel_util.py(读取 Excel 文件)
-- logging_util.py(日志器)
-- read_yaml_util.py(读取 yaml 文件)
-- tools.py(工具)
run.py(运行主函数)
关键字函数库文档.txt(关键字函数使用文档)
框架细节
关键字函数文档
pytest 测试用例,这里我只集成了一个 testcase,然后自动读取 testcase_data 所有的测试用例 excel 文件
关键字函数库,使用 python 的反射函数,可轻松调用任意的关键字函数
部分关键字函数
Excel 自动化测试用例
allure 报告
log 日志
其实,我觉得最实用的是,用例的执行过程录制,我用了一个比较巧妙的方法,就是把每一个执行步骤,做一次截图,然后存到临时文件,等所有用例执行完,自动合并为 gif 图片,这样就可以通过简简单单的方法,实现用例执行过程的画面录制,而且感觉很炫酷,这里暂不做展示;
总结
框架,还有很多细节未展示,文章篇幅有限,这里只做思路和方案的分享。
这套框架,我觉得会是我以后自动化测试平台的核心逻辑,现在这套缺点还是挺多,亟需自动化测试平台的集成,其中最重要的是,把数据存储到数据库,方便数据管理,实现更加强大的功能;
「All right reserved, any unauthorized reproduction or transfer is prohibitted」
你这个 Excel 里面放了元素定位,你觉得是好改了,其实更不方便,放代码里可以重复使用,你放 Excel 里面了。UI 自动化根本没必要搞 Excel,把变量放在配置文件,放在 yaml 不就行了,Excel 维护起来真的麻烦
放在 excel 也还行。你可以放在云文档上,随时修改,相当于当一个数据库来玩的,其实蛮有意思的,可以试试
如果我想在用例里面写个判断逻辑或者循环逻辑,应该怎么办呢
同意 2 楼的意见,不过自己实现的过程还是很值得的,做过了才知道优劣势
其实不然,这种 Excel 自动化测试框架,应该用的公司还是蛮多,主要考虑到团队,技术水平不统一,使用 Excel 可以降低学习成本,适合代码能力不强的测试人员,只要稍加培训,怎么使用关键字函数就可以快速上手,编写自动化测试用例。
当然,最好的方式,就是用自动化测试平台。。
这个 not,我还是第一次知道,可以同时判断,None 和 空字符串,,,学到了,,谢谢大佬
比如我拍卖行的上架商品的用例,前置数据需要依赖另外两个接口获取,获取之后的数据还不能直接用,还需要用一些逻辑处理下。
这种太灵活的需求,UI 自动化不太适合,UI 自动化本质上是代替人工,自动回归功能,并不是为了测试功能有没有 bug。
所以,不能偏离自动化的初衷,如果要这样搞,UI 自动化的脚本那是要费好大力气维护,得不偿失。
除非这种不得不做,如果是我肯定选择简单的方式实现;
在我做的测试平台里,这种能力还是很容易实现的,接口和 UI 用例可以混着执行,数据也可以相互传递。当然循环执行步骤也是支持的。
反对平台,测试不会代码就不要做自动化
企业效益,你懂得,不可能每个人都懂代码,要不然,也不会有测试开发这种岗位