一起加油！

明天上班再截一些图上来，主要是基于百度 kityminder 做的，在它基础上加了一些一键记录测试结果、关联 jira 、过滤用例、多人协作自动合并等功能。

谢谢~你也要保重身体哦

谢谢支持~

暂时满足当前工作的需要了，进入维护阶段。后续重心会先转移到研测一体化，做到测试环境可快速搭建快速使用。

加精理由：从资损角度对系统线上问题进行防控，思路和方法非常具有参考价值。

https://github.com/testerhome/homeland/issues/83

我本地环境无法复现，而且从代码上看也不大应该会出现。你看下会不会是服务器上部署配置引起的？

说的挺细，但感觉和官方文档基本一致，没看到你想分享的点。

能否多一些思考选型方面的说明，或者说下踩了什么坑，怎么填的？

如果是设计时就不想有太大偏差，建议是开发之前，就需要进入项目或者和项目人员深度交流，了解大家最需要什么，项目特点是什么。比如项目如果是流程较长，链路较长型的，单个接口如果没有准备好数据很难测试，那就需要能比较简单就可以把多个用例组装起来，达到可以符合流程自动化执行的目标，方便快速把数据造起来。

然后框架有个雏形后，就轮岗进入项目中，自己加上少数项目中对这个有兴趣的同学一起作为先锋把最需要自动化的几个用例用自己的框架实现并在项目中跑起来，然后再推广。这个时候你可以针对项目说出很多接地气的例子，大家也就更容易接受，不会自嗨。

你的想法也不错，写完一个模块就和手工联调，及时修正。如果可以，建议问下有没有一些手工对这个有兴趣，抽出 30%-50% 的时间陪你一起做，这样沟通更多，修正也更快。

如果大家对 RF 并不是特别熟悉，我觉得 RF 的对比不大需要太突出。一个新框架本来就有学习成本，还多加一个对比，成本更高了。

建议突出自动化的好处（手工一起参与编写，写完后不用乏味地重复劳动），以及你的框架如何简单易用（如 xx 步写好一个自动化测试用例，套路一定要简单，容易听懂），让大家产生试用的冲动就达到目的了。

起步阶段，很多 pytest 的特性其实不大需要介绍，否则会让大家觉得复杂兴趣消退。只需要介绍起步阶段最常用的几个就好了。

另外：强烈建议先找个合适的团队（感兴趣、有技术底子）试点，丰富你的实际使用案例，再全面铺开，会顺利不少。

可以通过 rancher 的 api 来完成测试环境的部署，甚至是 ui 自动化、接口自动化工具运行环境的自动创建和执行。

这个就不大清楚了，目前没尝试过他们的结合。

其实主机这个一般使用不用太关注，除非是运维人员。

之前有收到过，目前暂时没有特别好的解决方法，所以还没修复。

docker 的思想是一次构建，随处可用。所以别人执行你的用例，应该是不再需要用 dockerfile 来构建环境才对。

一个接口很多用例这个没有变化，变化的是这些用例的编写成本（适当使用数据驱动，减少代码量），以及通过调整设计，这些用例和后续功能测试的重合度降低，减少重复劳动。

当然，当功能测试效率比较低的时候，适度的重合也是可接受的。

连现场问答都记录了，很详细，点赞！

不知道是不是我错觉，感觉和极客时间测试 52 讲课程里的一些思路很相似。

截图没看懂你这个接口的请求格式到底是啥样的，我只看到了一个 json 的 body 和 string 的 query parameter，没见到你说的 form 的部分。

建议截个抓包软件抓包后的图？

不知道实际场景和上下文怎样，不好说有没有问题。

但这种风格，可读性和复用性都比较弱，大量用 sleep 而非智能等待也比较低效，程序属于 “能用” ，但离 “好用” 还有些距离。建议看看 Page Object 优化下，至少也把变量命名为 a、b 这种完全不能代表变量内容的命名方式改掉。

为啥不给加 hook ？

加精理由：从原理到具体方法，讲得挺完整，而且也有相关的参考资料。

PS：印象中 wwdc 中有相关的 topic 专门讲启动时间的，建议也补充到参考资料里，更为完整。

让我想起以前 android 单个 class 文件里的方法数的限制。

1. 看你的配置，没有给 apk 文件，而是直接给了 app 的配置。有确认过设备里是不是真的装了对应的 app ？
2. 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 到你截图的这一行所有日志都附上来，这样才能全面地分析。