测试精通这些,性价比太低了,天花板确实不高,并且吃香的测试的岗位并不多。
不妨把时间拉回到 5 年前,那个时候,不也是开始卷自动化,selenium。
现在呢?selenium 反而成为了每个测试人员的 “标配”。
卷是迟早的,市场需求决定,不迎合市场需求,注定会被替代或者淘汰。
这个是 logging 日志器的问题,应该是重复实例化了两次,需要排查一下,哪些地方实例化了 logging
企业效益,你懂得,不可能每个人都懂代码,要不然,也不会有测试开发这种岗位
省流:题主在很严肃的在讨论护城河的问题
看情况,有时候,开发就是自己不动脑子,自己不去思考解决方案,反而,要让测试说怎么改,这种情况,当然直接回绝,测试只看结果,结果符合需求就可以,具体怎么实现,开发自己解决。
协助解决问题
这种太灵活的需求,UI 自动化不太适合,UI 自动化本质上是代替人工,自动回归功能,并不是为了测试功能有没有 bug。
所以,不能偏离自动化的初衷,如果要这样搞,UI 自动化的脚本那是要费好大力气维护,得不偿失。
除非这种不得不做,如果是我肯定选择简单的方式实现;
这个 not,我还是第一次知道,可以同时判断,None 和 空字符串,,,学到了,,谢谢大佬
其实不然,这种 Excel 自动化测试框架,应该用的公司还是蛮多,主要考虑到团队,技术水平不统一,使用 Excel 可以降低学习成本,适合代码能力不强的测试人员,只要稍加培训,怎么使用关键字函数就可以快速上手,编写自动化测试用例。
当然,最好的方式,就是用自动化测试平台。。
借鉴
是要想实现什么场景需求么。
这个原理,我猜是,跟系统相机冲突了;
你可以尝试,视频通话,然后再去打开相机,拍照,录视频,,这个时候,系统的相机就会占用微信的视频通话,应该也会中断微信的视频通话;
想简单省事,其实只测支付接口就可以了,不需要通过页面,毕竟你页面的支付流程,最终还是得靠接口。
在 pytest 中,您可以使用@pytest.mark.parametrize 装饰器来定义测试用例的参数化,并使用 request.node 对象来获取参数值并将其设置到 Allure 的上下文中。然后,在测试用例执行结束时,Allure 会将参数信息写入 JSON 文件中。
例如:
import pytest
import allure
@user2ize("param", [1, 2, 3])
def test_example(request, param):
allure.dynamic.title(f"Test Example - Param {param}")
allure.dynamic.description("This is an example test case with parameters")
allure.dynamic.parameter("param", param)
# 执行测试逻辑...
使用@pytest.mark.parametrize 装饰器定义了参数化,将参数值传递给 test_example 函数。然后,在测试函数中,使用 allure.dynamic.parameter 方法将参数值设置到 Allure 的上下文中
短期是没问题,长远呢?你看看哪个现在主流 app,是有一堆问题的?
“产品能不能成功,说实话跟测试的关系最小”,我并不这么认可吧,你像小公司,虽然研发质量也很重要,但是测试质量同样重要,如果没有测试来保障产品的质量,发布上线之后,一堆问题,那产品谈何成功?
是的,所以,要么大搞开源,惠及中小企业,先让自己的开源项目火起来,后面再引投资。
我只有一个问题,你是否能够对你的测试结果负责?
这其中还涉及到,A 接口的数据如何传给 B 接口,你可有好方案?跨线程传数据
首先,这个问题很简单,锊一下思路
误区:
操作步骤:
线程组 A,请求 A 接口,并获取响应数据供 B 接口使用
线程组 B,请求 B 接口,设置并发线程数:10 个,并且给接口设置同步定时器,用户组 10,超时:2000
用表格查看结果,看一下是否满足需求