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

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

支持一下，孔老师好样的！

第 2 点有点没看懂，小号指的是手机号还是微博账号？好像没见过有什么系统登录后会显示不止一个用户的，不知道微博是否有这样的设计。
然后第 3 点，你用微信登录有有绑定回你的手机号吗？正常来说直接微信登录由于拿不到除了微信 id 之外的信息，所以其实没法和你自己手机号绑定的，得人工绑定，且一般要求此时手机号没有绑定过其他账号（按照实名制的要求，一般 1 个手机号只能 1 个账号，确保身份唯一）
第 4 点，爹是谁，娘是谁？

建议除了步骤外，也写上你的预期结果和实际结果吧，这样更清晰，现在通过步骤没看懂你觉得怎样才是对的，所以都不知道具体问题在哪。

看半天没看懂什么 bug，能分步骤 1234 说么？

额，不建议强调 “女” 这个特点，这个帽子太大。我以前团队里女生都很强的，有追求也耐压，干起活来不必男生差甚至更好，所以不要一上来就 “女测试” ，让人有歧视嫌疑。

其实这种问题和男女关系不大，也有遇到过男的类似这样的同学。基本上特点是比较关注工作和生活的平衡，工作之余应该自己也有不少的活动安排，一旦工作加班就会对这些活动产生比较大的影响。倒也没问题，每个人都有自己的追求，只是可能不一定适合自己团队。不妨面试的时候问下对加班的态度如何，可以了解到一些端倪。

不过我觉得，核心点是你招聘时不知道出于什么原因，太倾斜她了，别人都要求的到了她身上就没要求了。这些导致你招了一个其实不那么符合岗位要求的同学进来。感觉她应该会稳定一些 不知道依据是什么？

另外，请不要在面试时产生因为是男生/女生，所以要区别对待的想法。和工作无关的一些人性化的事情可以区别一下（比如加班时尽量男生先上，绅士风度帮忙做一些体力活之类的），但面试考察的是基础能力，这个地方上降低要求的话，后面双方都痛苦。

知道了，踩了暗坑，port forward 模式下转发时，一些和 host 有关的内容没有做替换，只是把内容做了转发。比如 header 里的 host 没改为 proxyRemoteHost 的值。所以背后真实服务看到 host 不大对，就不会正常返回了。

我实际启动命令里的相关配置：

java \
-Dmockserver.initializationJsonPath=${mock_file_path} \
-Dmockserver.watchInitializationJson=true \
-jar  mockserver-netty-5.11.1-jar-with-dependencies.jar -serverPort 1080 \
-proxyRemotePort 80 \
-proxyRemoteHost xxx.lizhi.fm

根据日志，转发时使用的 Url 和 header 中 host 字段还是 127.0.0.1:1080 ，不是我配置的 proxyRemote 相关信息。而且通过查服务端日志，会没有相关日志，估计是被框架层处理，都到不了业务逻辑层。

给请求加上 -H 'Host: xxx.lizhi.fm' 后，才能正常返回。详细的后面得再看看源码。

开发场景，客户端和服务端同步开发，客户端前期需要通过 mock 获取所需返回值。
测试场景也偶尔会用到，用于模拟返回特定错误码。

试用了下 port forwarding 的 proxy 方法，配置了 proxyRemotePort 和 proxyRemoteHost 。通过 mock-server 访问返回 404，但直接访问是可以的，看来还要再看看具体源码了。

这个片段看得有点一头雾水，如果是个人笔记可以放在记事本里面？

命中规则返回 mock response， 没有命中规则的话转发给真实服务。

这个是这个 java 应用直接具备的功能，还是通过文中的 go 脚本实现的？看了下 go 脚本，貌似没见到有相关的逻辑。文中的 java mockserver 有提供 proxy 的方式，但也必须要在被测服务里加配置才能实现。

目前实际项目里，需要用到这种指定规则的 mock，非指定的走真实流量。找到的各种 mock 基本都是 mock 整个服务，或者需要到被测系统里加配置，缺少类似网关的实现方式自由选择哪些 mock 哪些直接转发，不大合适。