功能问题:
大部分情况下测试主责
特殊情况下如, 缺陷被发现但是修复后遗留深层的缺陷导致线上问题, 研发改了不该改的不在测试范围内的功能, 研发主责
非功能问题, 如性能、兼容性
测试前要明确范围, 范围内的测试主责
其他非测试流程问题, 如线上配置错了、代码合并漏了等等测试最多次责

婚假还能只休 3 天? 不是只能一次性用完嘛

确实, 现在有问题基本不去这些网站上搜索, 直接问 ai 方便很多
来社区一方面是摸鱼, 顺便了解下行业动态和技术趋势提高一下技术视野,
比如最近 ai 的火热,从社区看到了很多实践, 也看到了很多专业文档 (比如恒温提到的 Hello-Agents, 狂师提到的 skills) 方便学习

效果咋样

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

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

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

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

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

不明觉厉

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