好奇题主的沟通过程

既然没有给你分太多的业务上的活, 可以和导师聊一下试用期的期待 (正常应该有聊过了), 先做好手上的事情.
关于「大量重复的工作」这个在测试岗位上是少不了的, 如果准备继续干下去, 可以想想如何简化操作、提高效率, 毕竟你会代码的对不, 可写写工具啥的.
关于「业务底层逻辑不清楚」: 你会 java, 那么去要源码权限, 可以从手上的任务开始, 也可以从业务主流程开始, 去梳理系统逻辑、各模块的交互, 数据库表的关系, 输出文档. 这个事情无论后面是跳槽做开发还是测试, 你对手里的业务流程是必须掌握清楚的.
个人也不建议过于沉入业务测试, 对测开来说, 必要的业务测试是必须的, 对系统的理解也是一定要有, 但是很多测试工作对自己的能力提升并没有意义. 所以建议尽量深入理解业务以及代码逻辑, 少接复杂度低的功能点 (想摸鱼另算)
另外对于新手来说, 熟悉工作流程、看看公司积累的技术文档, 最好在第一份工作形成自己的方法论.
最后, 有些问题, 换工作是解决不了的, 下一份工作如果遇上相同的事情要怎么办.

好奇「工资拉满」是多少

社区是否可以开一个新的节点, 专放副业相关, 或者职业扩展之类的内容

喜欢发现特殊 bug, 反复争论后把代码和文档拍开发脸上, 写的工具被更多人使用
讨厌执行别人写的用例, 有的人用例不区分验证点、不分重要程度. 比如一个 P1 用例下几十个验证点, 一堆菜单和页面的回归写里面, 迭代改动的反而照抄需求, 总之就是该细的不细, 该粗的不粗, 看得就烦躁

刚刚测试了一下, 挂🪜或者手动设置 dns=8.8.8.8 时, 搜索是正常的, 估计是 dns 污染了

如果年轻, 学历好, 没经济压力, 目前的工作珍稀程度不高
那就想走就走, 年纪大了就走不了了....

主要是投入和收益 (比如使用后线上 bug 率是否明显降低, 显著减少回归时间), 很多时候迭代一个一个接着来, 每个迭代改一堆东西, 历史的自动化就会有很多需要重新维护的. 如果又不给这块工作留出足够的时间, 那最后维护成本越来越高, 导致变成吃灰用例.
所以最终还是这个工具能带来多大的收益, 能不能提高大家的工作效率. 如果一个工具带来了额外的工作量, 解决的问题又少, 又不能带来个人能力上的成长, 然后又不安排额外的工时, 那么肯定是难以维持下去的.

最后自驱力也是要有收益 (无论是否滞后) 才行. 不然用这份精力学点别的不好嘛

没有自动化对你们现在的质量有影响吗, 有了后会有提高吗, 或者可以提高效率?
不要为自动化而自动化.

外包?