不明觉厉

这证书随申办可查吗, 通过后有没有补贴
我们公司以前组织考证, 过了有钱发, 减去报名费还可以小赠一笔

那就有点难搞, 估计你能调动的就是自己和另一个全职测试, 另外两个半路出家估计都不好给压力.....

感觉需要分析一下漏的原因
是没分析到、还是漏执行了
是否可以把核心流程的校验点做成 checklist 强制校验、完善业务监控并在测试环境执行监控

非常有效的建议, 很中肯
这工作强度太高了, 好奇 3 个实习生是不是也这个强度, 有没有跑路的计划, 或者已经在跑路中了.......

骡没有后代, 只要长角就能脱离苦海
牛有角, 但不敢用

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

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

机械是真的苦...., 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 污染了