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

可以从后续发展考虑

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

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

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

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

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

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

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

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

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

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

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

先强行用到一下

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

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

有收获，

拥抱新技术，同时保持清醒。等 AI 代替一切的时候，就是社会变革的时候。

快 40 了

deepseek 和豆包又不是不能用 不是非要用它撒~

这些要求真能达到的人，这个薪资肯定在筛选条件之外了，他们估计都不会看到~

你随便找几个测开的招聘要求，看看缺啥就行。
一般招测开干测试的不少，所以有开发能力的测试比无测试能力的开发更有优势。

情商高、人脉广的话，果断转啊。但是如果老得罪人，就算了吧，这种更危险。

把非常明确的参数校验的用例交给 AI，然后自动一键导到现在的用例管理工具里（直接在里面生成更好），你也可以在 PPT 中写东西了。
再整个智能测试环境维护，弄几个 MCP，自动重启切换什么的，又可以开始吹了。

先建立回顾总结机制。小团队最重要的是统一思想和活下去，流程某种程度上就是成本，就那么几个人，一切以活下去为重，任何形式化的东西都可以省略。主动发起的流程变更阻力很大，不如被动发起，事教人，一次会。每次流程变更因事而变，从回顾会入手，每个流程有对应事件依据，阻力会小很多。