我现在使用消息队列,每个人的框架,都往该 MQ 订阅消息。当 web server 收到任务请求,向 MQ 生产消息。本地的框架收到消息后,判断标识,true 的话,就开始本地环境执行测试。
driver.tap 试试先啦,driver.scroll 这个可以从 A 元素滚动到 B 元素
识别后,就可以获取到坐标啦
appium 新增了图片识别。可以试试
你能实现到 grpc 的客户端,就可以自动化啦。这个跟 http 几乎没什么区别。
但要实现共享。只能内网没啥用。
难点还有一个,解决局域网连接设备。
成本好高啊。
好的。谢谢
这样整体的测试运行效率会好低
还没开始写呢
目前设计上,是否每次都需要重启 chrome,由写用例的人决定。
这样也可以,但得保证设备和测试工具在局域网。
是第一种方式,大概理解了 opendx 的调试方式,可以借鉴借鉴。哈哈哈
也是可以哦。谢谢
日志实时展示与在报告查看应该差别不大,主要是看不到浏览器 (客户端) 的界面
请问在 web 平台上编写关键字用例后,如何调试。
其实也不闲的吧,当游戏强更或者其他更新,推渠道包时,你得回归所有渠道包。
发行商更关注的是账号系统,支付系统而不太关注游戏质量,纯软件测试。除了两个基础系统外,还会有客服系统,数据统计系统等等;运营活动和周更只是其中的日常工作之一,但也是回归上述的软件内容,而不是游戏。
1 万并发限制,会报错的
请求接口,请求量越大越好,可以用压测工具。然后统计数据。分析是否与配置的概率一致
有可能,涉及到参数排序,计算 sign,重写 url
666
嗯嗯,学习了
为什么我打包 jar 引用,jmeter 的性能下降超级严重