如果只是根据自身的问题来讨论事情是否有必要,就等同于给自己找一个不去做这件事的理由。
同样的,我们也可以给单元测试,接口测试,甚至测试这个事情找到同样多的理由。但是 “测试是否有必要?” 这个问题相信你也有显而易见的答案吧?
所以还不如多花点时间去想怎么解决你的问题吧,或者如果你自己想不通为什么一个后端开发要来做自动化测试,要不和你领导聊一下,让他另请高明,你专心做开发?
我以前是白嫖阿里云测,每天免费两次大概三十多台设备,不过现在不知道还能不能免费了。
你的个人发展方向是什么呢? 如果是测试,我觉得还是得把自动化测试框架,接口测试,和测试的基础先巩固好。现在这个行情下面,对很多团队来说最重要的还是找到能干测试活的人,测试平台什么的坦白说优先级没那么高了
嗯嗯,加油!
testin 不是云测平台吗,那么我理解它的优势应该是背后的云真机?
我们现在使用的国外云真机平台(device farm)是支持主流测试框架直接集成调用的(比如 selenium,appium,cypress,playwright 等),因为它所提供的服务就只是设备而已,不会也不应该强制客户要根据它的模式去写,或者重新编写一套用例。不然我以后不想继续用你了,要换个云真机平台或者自己搭建内部的平台,这套用例怎么办?又重写一次?
其实很多看似的没必要,背后都是为了兼容和处理不同场景。毕竟 appium 是一个同时兼容 Android 和 iOS 两个平台,底层还要集成不同的驱动类型。如果你这一套能实现到 appium 类似的体量,效果和程度,最后的效率提升会有多少呢?
从大部分的用户使用来看,这种方式起码保证了我只要专注于怎么使用和 selenium 一脉相承的语法去维护我的用例,甚至于同一套用例,只需要区分不同平台的 locator 就可以做到公用,牺牲一点执行时间是可以接受的。而且执行时间长,其实可以通过并发执行等方式去提升,一定程度上是可以接受的。
好像图片没有放上来?
不妨先大方(但私下)问问你主管是否有计划做,说不定他正好有想法但是没合适的人,那么刚好你可以领到这个任务去研究和主导;
但如果他实际上没有想法,或者他不懂自动化也不想,不敢去做,又或者他心里面有优先级更高的任务在计划中,可能他是不希望你在所谓的休息时间去做这个任务的。
没看出来是怎么实现关键字驱动的呢?效果怎么样?
我理解如果按常见的 BDD(业务行为驱动开发),是定义、封装好一系列的 keyword 关键字,测试同事可以根据业务场景,灵活使用关键字,结合 given,when,then 这种格式组合成不同的测试用例。
参考 cucumber 和 behave 的常见用法。
https://testerhome.com/articles/18060
之前类似的操作,可以参考一下
测试管理和测试执行一样吗?
遇到了
图像识别?录制回放?云设备并发测试?AI ?
我有个疑问,现在的并发只有 3500,平均处理时间是 200 ms.;但是不等同于可以推算出来 如果平均每秒可以处理的是 3500*5 吧? 实际上随着你并发数增加,系统的响应时间往往会下降,比如到了某个拐点,突然处理性能大幅度下降,甚至奔溃呢?
所以是不是要继续增加并发,来达到系统的满负荷状态?
你这是机翻的吧? 感觉翻译得挺全的,但是个别句子看起来又有点怪怪的
另一方面是不是也说明 web 自动化这块其实已经比较成熟了,没什么特别的亮点。难点还是在移动端上面。
https://testerhome.com/topics/13372 之前用 docker 搭建 selenium 的记录。
其实本质上可以分成两部分:
说说我自己的体会吧:
加油!
还啥护城河呢,真以为公司没你不行?就算公司没你不行,说不定公司哪天倒了呢?
好好学习好好积累,随时做好即使被裁了也能快点找到下家才是硬道理。
问清楚后台校验是用什么字段吧,可能不是 cookie,或者 header 里的其他字段,比如 token 之类的。参考接口文档,或者直接抄浏览器上看到的 header。
需要有自动驾驶方面的业务经验吗
应该还要保持播放的状态吧?
一个猜测:你的文件名不以 test 开头的话,好像默认是不会扫描出来的。可以在 pytest ini 里面配置。