如何分别构造 未上架、已上架、已下架 状态的商品数据?
是按照方案二的 1、3、5 流程构造吗, 那么你需要执行 3 次 , 那还不如直接使用方案一效率更高
还是通过改数据? 或者从数据库里捞取已有的数据?, 各有优缺点

认同使用这些指标作为质量管理的引入点, 但不认同长期使用. 上有政策下有对策, 好的指标使团队聚焦提高战斗力, 但有的指标使团队陷入内耗

不是说重复缺陷, 或者无效缺陷, 比如样式问题, 如果没有考核,那么写个文档所有样式问题放一起, 要考核那就一个样式一个缺陷
千行代码缺陷量也是, 本来少量的代码能解决的, 为了数据把代码量堆上去, 而且不同模块的代码本身要求差异就大, 比如业务代码和核心算法

总之个人觉得这些指标都比较形式化, 属于面对复杂质量问题无奈的表现, 不去深究问题根因试图靠简单的指标解决问题

好奇一点, 为了数据好看, 会不会导致一些很小的问题也提一个 bug, 或者一个 bug 拆分成多个

不明觉厉

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

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

感觉需要分析一下漏的原因
是没分析到、还是漏执行了
是否可以把核心流程的校验点做成 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, 那么去要源码权限, 可以从手上的任务开始, 也可以从业务主流程开始, 去梳理系统逻辑、各模块的交互, 数据库表的关系, 输出文档. 这个事情无论后面是跳槽做开发还是测试, 你对手里的业务流程是必须掌握清楚的.
个人也不建议过于沉入业务测试, 对测开来说, 必要的业务测试是必须的, 对系统的理解也是一定要有, 但是很多测试工作对自己的能力提升并没有意义. 所以建议尽量深入理解业务以及代码逻辑, 少接复杂度低的功能点 (想摸鱼另算)
另外对于新手来说, 熟悉工作流程、看看公司积累的技术文档, 最好在第一份工作形成自己的方法论.
最后, 有些问题, 换工作是解决不了的, 下一份工作如果遇上相同的事情要怎么办.