思维导图挺好的, 我们也用这个评审
方便看测试点和测试逻辑

可以收集一下反馈, 为啥产品研发没怎么投入
是听不懂看不明白, 还是用例太乱逻辑理不清, 还是又臭又长没重点

机械是真的苦...., 996 都是毛毛雨

最高点上车, 30% 左右

靓仔到时候拉我

听说不咋地, 还在上海苟

请问页面 ui 的设计也是 Kiro 或 trae 吗, 需要先搭建脚手架不, 我建空目录 ai 生成的页面就几个输入框和按钮, 没有任何设计

「我已经配置了弹性伸缩，也就是内存达到 80% 就应该要新启动一个实例」这个策略 k8s 应该只会申请资源, 不会启动新 pod
故障转移一般是 k8s 通过探针检测到 pod 不可用才会启动, 如果探针接口不受数据库影响那么 k8s 看来 pod 是可用的.
针对长连接的问题, 一般在服务层上接一个网关, 简单点就是加个 nginx(或者 ingress-inginx) 并配置负载均衡算法, 避免 http 长连接都发到一个后端 pod.

非常感谢~

有个问题比较好奇
既然是 db 连接数不够, 为啥要改负载均衡, 不应该是调整 mysql 连接池配置、优化 sql/索引/锁, 及时释放连接, 避免长期占用
pod 再多也 db 还是连接数不足, 拥堵不更严重了吗

大佬用的什么 ai 开发的呀

感觉小公司写来就是用来炫技 + 练手的
前领导写了个测试平台 (用例管理 + 接口自动化), 离职后就废弃了....
用例管理, 换成 xmind 写然后导入 teambition(公司项目周期管理都在这)
接口自动化, 换成 apifox

和 ai 的对话记录, 好奇是怎么和 ai 去描述这一套系统的

好奇题主的沟通过程

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

好奇「工资拉满」是多少

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

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

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

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

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

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

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

外包?

感觉就是被针对了

这个条款无效的, 可以多咨询咨询 12345