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

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 可以快速地扩展。每个框架都有自己的优势和缺点，关键看怎么去建立适合团队的规则和工作模式。

为你们点赞

我没有继续研究这个工具了。cypress 现在应用得挺广的，肯定有很多人已经踩过了坑，你可以在论坛里搜一下。

为什么麻烦呢？每个框架都有它的优势和缺点啊，而且 rf 也有很多使用场景的，用的人也不是少数，在合适的团队里面也有它适合的土壤。

https://mp.weixin.qq.com/s?__biz=MzI0MjIyMTYwNA==&mid=2651220780&idx=1&sn=2822f55c742ac7f7bd7b6873f87f388c&scene=19&ascene=7&devicetype=android-31&version=28001c57&nettype=WIFI&abtest_cookie=AAACAA%3D%3D&lang=zh_CN&session_us=gh_02e3ae2052f9&exportkey=n_ChQIAhIQRiy45axFfmdPcE6fxBcIjhLlAQIE97dBBAEAAAAAAFRhIGtGBMkAAAAOpnltbLcz9gKNyK89dVj0fF9AYI8KKP6%2BbNKVqW%2FrnxodxiY49CVmxYEWAojoizoYY8FS%2BUKho1wcVFVTMXayOE6yfZo83HVVHXZIYAeZXuXCNWpx%2FnDL9CdJPWNw%2BMy2JbymJrSOvTp%2BgONJy6UPbtOlAdI56mWc4R0p5sqcrVsVVGQJwu4e7NwJlG2T127yb01TdMkCuVLvmby9lCNInwQGBNwXQXEB3bs%2F2wJejDMmXw2mZCfGS%2B0OcMfEwM3aM%2FpB04F03DkbJpEGP%2BE%3D&pass_ticket=AN2Bm%2BRgcwSvbgPi1BNpCpt1DxR45HmJbXO14U1IczaX7L7R0fEttZCipskI5B0q&wx_header=3

以前使用过 tsung 这个工具，好像单机发起的请求能力比较强。仅供参考，因为已经是几年前的事情了，我也没有那么高并发量的需求，所以没深入去看过。

不差钱的话买最新的吧，或者都买

Weditor 确实挺好用的👍🏻

找你们公司的财务商量好，测完之后，要么给你报销，要么直接给你退。

我们的做法是在 setup 里做处理，确保每条用例是从指定的页面开始。
在 selenium 里面就是把这个页面的 URL 保存起来，在这一步就是强制跳转到这个页面；
在 appium 里面因为没有指定页面跳转，所以一般是点返回，直到返回到了想要的根页面为止。

如果返回某个页面出错了，还会重新登录。

整个过程处理起来比较复杂，但是对提高整体的通过率是很有帮助的。

主要是要保证配置不出错，所以直接对部署后的配置文件进行快速检测可以发现大部分问题；
图像检测也是一个思路，我们也有 diff image，图片对比的方式可以快速识别出那些元素的翻译发生了变化，配合手工检查进行验证。

Rf 本质上也是调用的 selenium 库进行测试，所以你先查一查服务器上面的 Chrome 是不是可以正常被调起的，比如写个简单的 Python 脚本直接调 selenium 去启动

你是要工作日报还是项目的测试日报？

如果是工作日报，就写你做了什么，有什么后续跟进，遇到什么困难；
如果是项目日报，要分几个部分

1. 项目总况。当前测试准备，测试执行，回归测试的进度分别是多少，总体状态是良好还是高风险；进度最好有计划的进度和实际进度进行参考。
2. 如果状态是非良好状态，要写明是什么原因导致的（比如有什么环境问题或者缺陷阻碍测试，或者开发交付延迟），以及需要怎么样才能回归到正常状态（问题什么时候之前就要解决，或者是否需要延期或者加班赶进度）。另外写清楚对应的责任人是谁，哪天是 due date。
3. 当天的更新内容，比如今天完成多少用例的测试，完成多少故事，提了多少 bug； 因为什么问题导致测试被阻碍了多长时间，谁在跟进或者需要谁的支援解决。
4. 具体的测试内容状态。比如用例执行的状态表，缺陷的状态表，等等。