软件给人用，或者会影响到人，那肯定是需要一个角色，提前帮人规避未知的、让软件责任人承担不了的风险，再怎么着，也需要使用人去做验收测试吧。

所以我个人觉得测试工作不会消失，不过会一部分转移给 AI、转给产品、转给开发、转给负责人，具体看各个组织的组织结构。

软件测试某种程度上代表了人定义正确的能力，如果以后人不能定义正确，AI 定义了正确，那确实可能就不需要人来做软件测试了。

让供应商提供两个雷达对比测试报告啊，作为甲方，这种还需要自己动手么

跟这个年代投入建筑行业有什么区别。。。

跟团队氛围、考核引导、个人原因等多因素相关

高产的飞哥~

你懂的很多道理，但是仍旧抵不过领导一声

楼主说的其实很多测试心里都明白，奈何有些 SB 领导就看数字，覆盖率只能涨不能跌，工作的意义就是为了他 PPT 上的数字好看

学习了 感谢分享

开发测试都是质量的共建者， 整个团队为线上质量负责。唯一测试主责的，就是用例写了，评审了，没有执行或者执行不到位

可以从后续发展考虑

无所谓的吧，除非程序处理对输入敏感。

单接口是一个维度，关注单个接口的处理。串起来是一个维度，关注整体的流程。一般的策略是先单，单没问题再串

Cursor 很强，Claude Code 很好，但是办公环境网都不给上，怎么破~

性能测试准入标准一般就是功能没问题，如果因为性能问题的修复导致功能有问题了，是不符合性能测试准入标准的。一般性能测试需求不多的，业务向团队内只搞性能的后面就慢慢没事做了

性能测试一般默认功能没问题，如果代码做了修改，功能和性能是测试的两个维度，如果归属两个团队做，正常来说是都要进行回归测试的，评估下回归的范围就行。

没有谄媚型管理者哇，唯领导论，不管下面死活的

如果 AI 替代不了，就先用制造恐慌，把人力成本打下来，这叫降本。如果 AI 能替代，就增效了。怎么着都是赢。AI 赢学永远都赢

用户怎么用的 你就怎么用 SDK 测试啊

就是各种指标，搞点实际的比如线上缺陷数之类的就行，别自己坑自己

以下这堆内容，你看有没有可参考的：

1. 准入准出规范文档
2. 非功能测试流程文档、规范文档
3. 功能测试流程文档、规范文档
4. 测试度量指标及规范
5. 项目共识

先强行用到一下

王权没有永恒，参考土木老哥们

提测质量肯定不行。一个东西，你都不知道他干啥的，照着样子做出来了，你敢直接给别人用么。。。

有收获，