这是运维的锅吧
很简单,CentOS 上跑个 Docker 不就行了么
既利用了 pytest-xdist 也用了自写的多进程,这样测试报告就能汇总了,其实很简单。大致代码如下:
from multiprocessing import Pool
import pytest
def run_case_part(pytest_lst):
pytest.main(pytest_lst)
def main():
case_lsts = [
['-s', '--alluredir=report/xml_20231009_0829', './cases/', '-n', '2', '--dist=loadfile', '-m', 'p1'],
['-s', '--alluredir=report/xml_20231009_0829', './cases/', '-n', '2', '--dist=loadfile', '-m', 'p1']
]
p = Pool()
for run_lst in case_lsts :
p.apply_async(run_case_part, args=(run_lst,))
p.close()
p.join()
if __name__ == '__main__':
main()
需要按自己要求处理下变量 case_lsts 就差不多了,里面 的 '-n', '2' 表示 2 个进程执行,'--dist=loadfile' 表示每个 py 文件的所有测试都在同一个进程中运行 (这个自己可以取舍,如果单 py 文件中的 case 有关联,建议加上,也可按自己的情况改成 loadgroup 或 loadscope 或其它)
这必然要分账号来分别测试啊。比如账号 A 登录后打开某个页面,应该有哪些功能入口 (如菜单上的选项),应该没有哪些入口,要做断言校验啊。
愿望是美好的,除了 css 和 xpath,实际上还有对各种情况做判断和相应处理,平台是很难做到较好支持的。
始终觉得在这种平台上写 case 简直是折磨,效率太低太低。
根据个人经验,在这种群里无法正常顺利讨论技术问题的。
都用过,显然是 playwright 更方便好用,学习成本也低
像我这种 40+ 的,是不是该自绝于职场了?哈
通常情况下,JSON Schema 既强大又方便,一般足够了。
显然是猎头,不是直聘
喜提 N+1
很可能是输入法的 bug 而已
如 7 楼所说,用 mitmporxy 录制接口。
当然还有个办法,用 playwright 写个简单脚本,起来后手动在浏览器中操作,将这中间产生的 api 请求请求自动记录到 csv 或 excel 中,然后简单处理下就能跑了哈
多年前用过 AutoIt ,类 basic 的语法
暂时还没有。我当前是将 case 分组,多进程来实现提速。
比较常用的,还有比较好用的定位方式是根据方位来:
page.click("button:right-of(#search)") # 右边
page.click("button:left-of(#search)") # 左边
page.click("button:above(#search)") # 上边
page.click("button:below(#search)") # 下边
page.click("button:near(#search, 50)") # 50px 之内的元素
换用 playwright ,自带录屏功能
很高兴能对你有所帮助。我目前所在的产品,已经实现 UI case 400 多个,一人维护这 19K 行代码,如果顺序逐次完成,大约需要 3.5 小时。将用例按模块大致分成 3 份(pytest 的 pytest.mark.part1),改成 3 个进程执行,基本上 1 小时 15 分能执行完成,效率提升很多。
楼上已经提到了,我目前采用的方法是对于个别频繁的步骤首次用 UI 检查,后面的类似操作直接用 api 来完成,把用例分组,多进程开 3 到 4 个浏览器同时来跑。
大龄,卷不动了,祝快手股价早日回到 400 块(有生之年?😄)
主要是你同一个 ID 还在其它网站用过,老毛豆一枚,哈哈
看楼主 ID 有点眼熟,奇安信的吧?
确实算是哈