可以通过 rancher 的 api 来完成测试环境的部署,甚至是 ui 自动化、接口自动化工具运行环境的自动创建和执行。
这个就不大清楚了,目前没尝试过他们的结合。
其实主机这个一般使用不用太关注,除非是运维人员。
之前有收到过,目前暂时没有特别好的解决方法,所以还没修复。
docker 的思想是一次构建,随处可用。所以别人执行你的用例,应该是不再需要用 dockerfile 来构建环境才对。
一个接口很多用例这个没有变化,变化的是这些用例的编写成本(适当使用数据驱动,减少代码量),以及通过调整设计,这些用例和后续功能测试的重合度降低,减少重复劳动。
当然,当功能测试效率比较低的时候,适度的重合也是可接受的。
连现场问答都记录了,很详细,点赞!
不知道是不是我错觉,感觉和极客时间测试 52 讲课程里的一些思路很相似。
截图没看懂你这个接口的请求格式到底是啥样的,我只看到了一个 json 的 body 和 string 的 query parameter,没见到你说的 form 的部分。
建议截个抓包软件抓包后的图?
不知道实际场景和上下文怎样,不好说有没有问题。
但这种风格,可读性和复用性都比较弱,大量用 sleep 而非智能等待也比较低效,程序属于 “能用” ,但离 “好用” 还有些距离。建议看看 Page Object 优化下,至少也把变量命名为 a、b 这种完全不能代表变量内容的命名方式改掉。
为啥不给加 hook ?
加精理由:从原理到具体方法,讲得挺完整,而且也有相关的参考资料。
PS:印象中 wwdc 中有相关的 topic 专门讲启动时间的,建议也补充到参考资料里,更为完整。
让我想起以前 android 单个 class 文件里的方法数的限制。
info: [debug] Setting device id to 127.0.0.1:62001
info: [debug] Waiting for device to be ready and to respond to shell commands (timeout = 5)
info: [debug] executing cmd: F:\android-sdk-windows\platform-tools\adb.exe -s 127.0.0.1:62001 wait-for-device
info: [debug] Retrying restartAdb
error: Error running wait-for-device
info: [debug] executing cmd: F:\android-sdk-windows\platform-tools\adb.exe -s 127.0.0.1:62001 kill-server
info: [debug] Getting connected devices...
info: [debug] executing cmd: F:\android-sdk-windows\platform-tools\adb.exe -s 127.0.0.1:62001 devices
看起来 appium 想要确认设备会不会响应 adb 的命令,但貌似设备没响应。近期电脑 adb 版本或者模拟器有没有做过什么调整?你把配置后完整的 catalina.bat 文件内容发下?
emulator-5554 处于 offline 状态,确认下是不是掉线了?
192.168.107.101:5555 ,需要查看下更详细的日志看 adb 连接或者 stf service 的安装有没有问题,建议直接把从开始启动 provider 到你截图的这一行所有日志都附上来,这样才能全面地分析。
我们内部试了下,iOS 的开发同学反馈基本都没啥价值,而且还容易误报,所以后面没在 iOS 用了。
写得很齐全,加精鼓励下
另外,想问下 iOS 的规则开发同学反馈如何,发现的问题价值大吗?
没测试过,不大清楚。不过我理解一般不会对 private 方法做单测?
主要是意识,大家体会到甩代码给测试的爽快感后就不想搞测试了
可用率还可以,80% 左右吧。有效性个人感觉还不错,确实是要覆盖的场景
人工干预还是要的,用例还是要 review 下和人工补充一下
不熟悉这个框架,不知道截图里的 localhost 是个啥,建议你直接问框架作者吧。
既然都来到社区了,那就找篇入门文章,学习下呗。
目前会一些自动化已经变成是测试的基本能力之一了,而且有时候招聘遇到的应届生编程能力和想法都很厉害,学习能力也强。感觉自己再不学习,真的很容易被淘汰。
谢谢大家。
不要只给我点赞,也要给各位讲师和组织沙龙的小伙伴点赞,没有大家一起努力,这次沙龙达不到这么好的效果。
不好意思,这次没有录屏,下次会留意这个点。