1：20 的比例之下可以做到这么完善的质量体系和自动化程度，必须要点赞！

不过感觉这其中也有一部分原因是得益于你们有强有力的各种内部工具 Macaca， 云测试平台等等。普通公司往往在自己寻求这种基础工具或者开发维护上面疲于奔命。

另外说一下 Macaca，15-17 年左右的时候就有看到 Macaca 的开源，当时觉得非常好，也兴致勃勃地把它的自动化部分集成到了我们的测试平台里面；后来发现对应的社区活跃度对比 selenium 和 appium 实在是太低了，而且好多地方需要自己根据 selenium 的实现自己去做对应的开发，后来还是分别替换成了 selenium 和 appium。通过楼主的介绍，可以看到 Macaca 其实一直在维护和扩展，比如 playwright 的支持等。希望对应的开源社区也能尽快丰富，活跃起来吧，给大家多一个选择和思路。

大概三年多之前试过用 docker 拉 selenium 的 image 来跑自动化测试，支持 Chrome 和 Firefox。另外有看到一个好像叫 zelenium 的框架，在 selenium 基础上做了扩展，支持查看执行结果和录像。

不过到了新公司，我们换成了直连到购买的云真机平台 device farm 来跑自动化了，可以支持每个浏览器的最近 N 个版本和 beta 版

老兄是要质问你们的测试部？

不建议现在裸辞，趁着现在已经做自动化，起码再深入一些多积累经验，年后再观望。 现在的行情真的不好，找工作好难。

点赞！其实很多时候不需要怎么花哨的技术，把基础的自动化落地下来做好就非常加分

封面译者的第一个 “张立华” 就是恒温大佬吧？

正好论坛里大佬们都在做年终总结，你不妨去看看别人都在做什么。测试这个行业发展方向已经很多很多了，不要指望别人给你指一条一定正确的明路，得你自己去根据自己的情况去思考和选择。比如技术路线，自动化测试专家或者测试开发；业务路线，比如业务专家（前提是你所在的业务具备一定的门槛和通用性，比如金融业务）；又或者是测试管理方向，熟悉各种测试流程；又或者是全才。

我没做过专门的游戏测试，不过之前已经看到有不少工具和平台是专门为游戏设计的，你可以搜一下。我印象中有网易出的游戏自动化工具 airtest，还有一个做性能测试的 perfdog。

首先，是 robotframework；其次，真有不少领导喜欢这种容易上手推广的框架，而且依托于 selenium，做自动化效果也没那么差的

游戏测试一个很重要的点是性能测试和兼容性测试，比如不同机型上面的帧率，cup 占用，等等

你不妨猜一猜领导是通过什么去判断更好的框架？ 比如有些领导需要的是全员都能写代码，最好是都懂开发的框架和语言，那 cypress ，Junit，pytest 这种是他倾向于选择的； 但如果团队里面代码能力参差不齐，他可能会倾向于易用性，上手简单的框架，比如 robot framework，或者一些图形化，平台化可以操作的框架或者工具。

如果你已经根据自己的理解和判断，建议你可以把搜集到的不同框架列一个对比给领导看看。重要的还是沟通，说服他，被他说服，或者找到一个平衡。

你要先确定测试点是什么： 语言是通过什么规则来展示的？ 一般来说是分两种方式：

1. 系统中用户设置的语言。
2. 浏览器或者操作系统设置的语言。

无论是哪种情况，都要覆盖设置了不同语言下的展示是否正确。简单来说，就是不存在自动判断，而是有业务逻辑控制的，你要针对对应的逻辑去测试。

在 IT 团队内部，如果要甩锅的话，什么样的情况都可以归结成 “设计如此”，甚至真的就是这么设计的；
但是从用户的角度， 不好用，就是 bug

storage 和 cookie 是两个不同的概念。
第一个图是 localstorage，不是 cookie，所以你用 add cookie 是错的。

所以你要做的是去添加 local storage 的值，而不是 add cookie。可以试下用 selenium 执行 JS 的方法去 set local storage，参考：https://blog.csdn.net/Jack_13201/article/details/119320968

不就是 bug 嘛，工作里天天见那么多还有什么不能理解的

我理解其实还是一个等价类的问题，如果说等价类划得足够准确，是不是还需要覆盖那么多数据？

比如上面讲到的溢出情况，如果用例设计的时候严格考虑到了什么情况下会溢出，那么也能用更少的数据量去覆盖。

当然有个 engine 去自动覆盖也是一种补充。

就我个人来说吧，一方面是社区现在的审核机制多多少少会影响到发帖和互动的热情，这个之前也发帖吐槽过，但也明白这是必须遵守的规则；
另一方面，感觉是前两年大家都有很多东西可以交流，比如自动化的落地，比如各种新技术的调研和互动；但是最近这一年，新的东西分享比较少，而且受众面没那么广，另一方面大家也基本上把自动化的各方面都聊得差不多了，没什么新的话题好发的

天花板不是早日赚够钱，退休去环游世界吗？

和楼主的情况差不多，我也在广州，上一家公司也是某游戏公司，做了三年多的测试主管。三年里从零开始把部门的测试流程，测试体系陆续搭建起来了。项目上一个人对接了 Android，iOS，h5 三个版本的 sdk 测试, 还有 web 的后端管理系统，以及基于 hbase 和 es 的大数据系统；技术上，先后把基于 selenium 和 u2 的 UI 自动化框架和基于 pytest 的接口测试自动化框架搭建起来，后面还捣鼓出来一个内部的测试平台，把 docker 什么的也引入了进来。

后来因为部门的发展受限，然后自己也觉得成长空间很有限了，所以跳槽到了一家外企做自动化。机缘巧合，当时的团队在自动化这块几乎是从零开始，所以我也抓住了机会，把自己熟悉的自动化框架快速搭建和推广了起来，三年之后的现在带着三四十人的测试团队。

至于薪资，随着平台的变化和职位的变化，比起上一家公司来说已经有了不低的增长。虽然比起外面的互联网公司来说差距还是很大，但是胜在稳定，对于我这种中年人来说，薪资也算过得去了，起码够养家糊口。

所以我其实建议楼主不要太在意薪资，重要的是看接下来的发展平台。做了那么多东西，如果不想纯粹在技术上和别人卷，不妨把自己掌握的东西体系化起来，往全面的测试管理方向考虑，或许也是一个长远的发展方向。

不太清楚楼主在团队里是什么角色。正文里提到有测试的 leader，而且他已经有搭起来直接能用的 sonic 框架，那这个结论很正常啊？
从团队来说，学习和搭建一个可能是全新的框架是有成本和风险的。如果你有很充足的理由觉得纯 UI 的框架不适合你们团队，或者说不适用于长期维护，不妨找个时间和测试的 leader 讨论一下。但是要做好准备，也就是说你已经有足够的把握能把这一整套都掌握了，才可能说服对方。

坦白说，很多公司招聘会看你当前薪资是多少，然后给你一个增幅。

你说的 gui 是指 ride 的吗？ 我们是直接用代码的方式管理用例，没有用 ride.

我们现在的 UI 自动化就是用的 robot framework，当时在调研做 api 自动化的时候也考虑过 robot framework，也做过一些 demo。
当时的考虑是我们的 api 测试涉及到大部分都是数据的处理，和 robot framework 擅长的 bdd 关系不大，反而各种数据处理是 robot framework 不擅长的。所以后来我们改用了 pytest 。

谢谢。排版这部分和之前编辑的有点出入，有空的时候我再改一改

其实 rf 已经把大部分的 selenium 常用的操作封装成了 keyword 可以直接操作，而且自己用 Python 去基于 selenium 去扩展新的关键字也非常方便；report 方面，可以用 rf 自带的 report 格式，也能通过 allure report，也是方便的。

我们团队已经基于 rf 维护了几千条用例，基于 selenium 的用例非常稳定（只要 selenium 自己没问题）；每天不同级别的 pipeline 也都很顺利地在跑。

总而言之，rf 是一个框架，它的优势是用自然语言定义关键字，用 BDD 的格式组织用例（和 cucumber 这种框架是一样的），并且基于 Python 可以快速地扩展。每个框架都有自己的优势和缺点，关键看怎么去建立适合团队的规则和工作模式。