真不是大佬，还有好多东西要学习。技术不断在变，学无止境

repeater 有自己的钉钉沟通群，github 项目 readme 底部有。repeater 的几个主要作者也都在里面。

前两个问题，直接去业务里面轮岗测 1-2 个需求，就能找到了。好工具的共同点就是能解决实际问题。

第三个，不知道你的 GUI 和 web 差异是啥？GUI 指的是图形化界面吧，web 也有呀。

额，还没到大佬级别哈。针对你说的这几个问题，如果是我，我可能这么回答：

12、你觉得小程序测试与 web 测试有什么区别？

这里的小程序是微信小程序吗？如果是，个人理解大概有这些区别
1、功能方面，一个是微信授权的对接是否正常，另一个是控件及界面在不同屏幕下的适配效果。测试环境的话需要想办法构造入口，便于测试时按需切换环境/造数据。（记得某年小红书分享小程序测试的时候有提过这个坑，不知道现在还有没有。实际工作目前也没太专项测过小程序）
2、非功能方面，需要关注下发包大小、不同微信版本下的功能适配。小程序官方有个性能体验测评的东西，可以借助这个来大致评估下

13、有想过 web 和移动端的前端性能测试有什么区别吗？

web 的由于是随用随加载特性，所以性能关注的除了界面展示是否流畅（特别低端机型），还有加载时间是否尽可能短、需要加载的文件是否尽可能少和小
移动端由于是提前下载安装包，大部分资源都已经加载好，所以性能关注的除了界面展示是否流畅，还有流量消耗是否尽可能少（现在 4G 和 5G 普及，流量多很多，这个优先级基本降低了）、cpu 及内存使用是否会过高（会引起卡顿甚至直接被 kill）、是否有内存泄漏、耗电量是否尽可能少（特别是后台时）、弱网下体验尽可能好

16、如何解决版本迭代数据兼容性的问题？比如当前有一个排名，然后代码修改之后，怎样确定修改之后会不会出异常？

1、设计时，尽可能采用新增字段的策略，尽量不要改动已有字段的定义或内容
2、提测前，看代码具体改了啥，评估这个改动对于历史数据是否会有问题
3、测试时，从线上脱敏导一些相关的历史数据到测试环境，验证下有没有问题，测试环境本来就有最佳。不行的话可以在测试后期，线上拉一个节点部署新版本服务，只对公司内网开放，然后在上面测试一些历史数据的读取，确认正常
4、上线时，采用灰度上线策略，持续监控日志是否有异常。这样就算历史数据有问题也不至于影响太多用户

22、你觉得怎样的模块是不合适做自动化，哪一些是适合做自动化的？

经常变化且不持续使用的模块不适合做自动化，比如一些只会持续 1-2 个月的活动页。不经常变化且出问题影响比较大的适合做自动化，比如支付子系统。

好奇问下，面试结果是？

端口是附属在 ip 下面的，基本对应关系是 ip=主机（不是物理上的，是逻辑上的，比如 docker 内部网络下，每个容器都有自己的 ip，但在 docker 网络外部，整个 docker 主机只有一个 ip），端口=应用

之所以不同应用要换端口，原因是一个 ip 下面一个端口只能绑定给一个应用监听，你多个应用绑定时，第二个开始就会绑定失败。

你在 docker 网络外部访问里面的容器，所有容器用的都是 docker 主机的 ip，自然必须要每个容器都用不同的端口。
当你在 docker 网络内部访问里面的容器（比如起一个采集服务的容器，访问其他容器），每个容器用的是 docker 内部网络分配的 ip，一个容器一个 ip，自然就不用错开端口了。
你例子写的也是一样，A 和 B 服务器只要是用不同的 ip ，就可以用同样的端口而不冲突，A 上面多个容器，每个就得错开端口。

post 和 put 是不是反了？我了解的是 post 对应 create ，put 对应 update 。

不过也没啥好纠结的，实际用只要前后端约定好就行。

之前看到一篇讲得挺详细的，搬运一下：https://testerhome.com/topics/25530

在实际工作中，主要区别还是 get 是读场景，post 大多是写场景，当然也不绝对，也有见过不管三七二十一全部都是 post 的系统。

规范写得挺全的，不错。个人经验，其实与其给非常多的规范约束，不如直接搞个脚手架仓库，让大家基于脚手架来扩展添加自己的业务功能，用起来更方便？用的人只要都是模仿已有的写法去延续，那风格就会保持一致，基本上这个脚手架就能保障大家是按照这些相对规范的写法来写自己的项目。

PS：项目结构里面，sample 存放项目的核心代码应该不是规范吧。我接触的项目，sample 一般是放示例项目用的。

并不是所有功能测试都外包，而且很多时候大公司的非外包测试 title 都变成测试开发了，但并不一定全都是做我们通常理解的开发工具的测试开发工作，也有一部分实际主要是做功能测试的，只是都会有代码能力要求，不是纯功能。

facebook 官方已经停止维护 WDA 了，项目会被整合到 https://github.com/facebook/idb/ 。建议综合考虑下是否真的要基于原生的 WDA 做二次开发。

不用啊，你采集覆盖率部分的服务也部署到 docker 同一个网络里面，就可以按主机名或者 ip 来区分各个服务了。

实际只有获取 ec 文件这个步骤需要访问这个端口，后续的生成报告啥的都是基于 ec 文件了。

有个疑惑点，好像你 config 配置里的类名，和截图里的被测应用，有点不大一样？

这个情况以前还没怎么遇到过，不大清楚是什么原因。 @kujiale-qa @kujiale 看有没有遇到过？

每天业务测试量贼多，做工具又得加班做，想做工具不给排期

想问下楼主，你的业务测试量和团队里其他没有测开 title 的相比，是一样的吗？如果是，那感觉你领导没把你当测开来用，如果不是，说明领导其实已经在尽自己所能给你时间了。

不过业务测开这个混合名称，个人理解其实和高级测试差不多，重心还是在业务测试，所以才加上业务两个字。这类岗位一般定位是用好工具提高效率，自己要开发或者二次开发的工作量应该并不多，而且也不会对开发工具有太高要求。

hmm，消耗的内存差异应该不太大，而且对于测试代码来说不会 7x24 长时间执行，不大需要考虑内存的问题

至于代码简洁程度和案例编写流畅度，这个有点见仁见智，特别编写流畅度这个比较主观。建议你可以按这个思路分别写个 demo 对比一下？也可以听下团队其他要一起参与写自动化用例同学的意见。

对于楼主 3 楼提到的场景，想到一种思路，让 iframe2 对象的任意方法执行的时候，都统一先判断当前 frame 对不对，不对的话走一遍 switch_to.frame(iframe2) ，同理其他 iframe 也可以这么操作。

实际代码编写上，可以在 frame 的类里面重写 find_element 之类的基本大部分操作都会用到的方法，让它在 find 之前先切换，这样可以节省代码量。

匿名贴回复默认匿名，个人觉得没啥问题吧？

底部有显示名字选项，选中就会非匿名了。

建议先学会思路，再用框架吧。学 AI 比学一个框架要复杂多，基本相当于一个新领域了。不要抱着学一个框架的想法去学习，你会发现入门都很困难。

可以看看西瓜书，或者 google 的 ai 课程（本身就是针对编程人员的，有可以直接运行代码的教程，个人用起来比较顺手）。对于一个陌生领域的从零开始学习，最好还是像以前学编程语言那样去学一些相对系统化的课程，这方面领域知识比学一个框架要复杂得多，不是看一天框架文档就能基本上手使用这么简单的。

如果只是应用别人已经做好的基于 ai 的框架，可以看看 appium 那个图像识别的扩展插件。

不是说二维码，是说正文的结尾

实际做自动化测试，Web 网页是很复杂的，App 自动化测试的周期要比 Web 自动化时间要短很多。

写框架先写页面，首先研究下页面构造，看下页面功能的关联性。

感觉好像还没说完。

你要考虑维护成本。比如后面要求从小于 300kb 变成小于 500kb，开发只需要改个参数，1 分钟不到的事情，然后你的自动化用例得重新找等于 500kb、大于 500kb 的素材并替换进去，还得跑一遍确认下对不对，一般至少需要 5 分钟。这么算，你的成本至少是开发的 5 倍。

并且 UI 自动化由于各种偶然因素，失败率一般会比较高，所以为了保障稳定性能达到 90% 以上，还需要做一些调优；用例多了执行起来太慢，要并行之类的加速。这些调整都是成本。

自动化应该主要关注出问题会 P0 故障的场景，这些是尽可能保障每次代码变更都不会出问题的，所以要自动化高频率跑。至于那些出问题其实影响不大的，不一定值得做自动化。

@ 醋精测试媛 说个题外话，怎么感觉你现在自动化已经逐渐到了只要人工做测试的都要做自动化的程度了？

结尾有点怪怪的，有点像还没写完。确定所有内容都有转过来了吗？

赞，这种实际实战出来的 tdd，比理念宣传 +demo 强多了。特别是写用例还要考虑后面其他同学的维护成本，从这个角度考虑，用例是越少越好，只要能把握住最核心的功能就可以。

抓包时不用安卓 7 系统的可以不？

基本上应用不大会根据系统版本发不同的请求吧。

个人经验：
能用 id 尽量 id，一般 id 能保证唯一性，且基本不会变（一般是做业务逻辑用的，就算改界面布局也不会动到）
不能 id 再考虑 xpath 或 css