测试人员应该有自己的判断，但这个判断是否可以变成团队决策进行执行，取决于整个团队的沟通结果。至于哪些做哪些不做，核心就是看出性能问题的风险和测试成本对比，同样是测试先判断，项目团队沟通决策后执行。

你这个例子里，你做出了你的判断，这个是好事。但只是一个开发人员说不用，你就放弃了，没有把你的判断推动到整个项目团队决策（产品 + 开发 + 测试），所以你这个放弃有点太轻易了。

首先看团队有没有组织级测试策略，说明压力测试、安全测试等测试的归属方（例如专门的团队），
如果没有，可以根据自身风险承担情况，要求项目负责人或者决策者给出意见。

正常情况下，一个接口要不要做压力测试，应该是在测试策略评审的时候就确定了，可以避免你说的问题。

一个接口做不做压测，是应该测试人员自己判断 ，还是听开发说呢？

结论：产品、开发、测试共同判断。
如果这个接口有历史数据，可以基于历史数据来分析接口重要性，再判断是否要压测。
如果这个接口没有历史数据，是新增接口，最正确的方式都是产品、开发、测试三方一同判断。或者某方判断出结论后，正式地（会议、邮件均可，至少有书面记录性质的东西）跟其他方同步并征求意见最终确定下来（这样做的原因，是出问题一起背锅……）。

应该怎么判断一个接口做不做压测？

1. 有历史数据就基于历史数据判断重要性或者优先级
2. 如果没有历史数据，要预估新接口的 QPS 和对应的服务器资源。如果 QPS 达到某个阈值就考虑压测，阈值要根据业务和历史压测其他接口的情况去判断
3. 产品核心功能相关的接口一定要压测（除非真的没人力，而且预期没有负载压力）
4. 测试直觉……（这个接口 tmd 肯定在压测时有严重 bug，那就压它证明自己）

共同判断。。。。开发：不需要压，测试：我觉得需要压，产品：你们说的压是什么啊。。。。产品不懂啊，，这咋办

您说的预估 我是不是可以理解为 在测试站，预发布去进行线上的压力预估？

我们产品又不懂压力是啥。。问对应开发 人家说不用做，问他们开发老大 人家原话就是：所有的接口 都要压。。。甚是无语

策略评审是啥 = =米有听过

如果产品不明白，那还是得耐心解释给他们听，其实这也是你在研发和产品之间制造自己影响力的机会，让大家觉得你知道得很多决策经常正确，那是一件好事。

对的，其实压测本来就是有两种目的，视不同场景：

• 目的一：要上一个活动，这个活动从产品侧估计会有 N 人参与，所以某些接口必须要能支持这种程度的压力，这种就是在上线前就有明确的压力预期（一般是 8/2 原则来评估），压测的主要目标是 check 接口能否达到这个预期
• 目的二：要上一个新功能，这个功能大家都不知道会有多少人用，是个船新的东西。这时需要旁敲侧击，比如有无类似的接口可以拿数据来参考，或者有个保底的用户人数，这时候压测的主要目标是看这个接口能承受的极限压力，先让大家知道这个接口能扛得住多少多少，然后在来评估是否合适上线

压测我以前做过一个总结，可以看我的博客做个参考。

如果专职做压测，那你的目标是都测吧，测不完的情况下，再去讨论风险定优先级。但每个接口压测标准可能不一样。标准可以根据实际情况找团队来定。

就是对定义测试的范围和需求，选择的测试方法，制定测试启动、停止、完成的标准和条件进行评审。

测试资源充足的时候，做不做还不是你自己主观的事。

你们这个问题，在于在团队在性能方面专业度不足、无法达成团队共识的情况下，对于性能测试相关决策，没有明确可以拍板的人。产品明显不具备能力，开发和测试意见又相左，甚至开发内部都有两种不同的意见。

解决也不难，看按照你们公司现在的情况，线上性能出严重问题要背锅，是谁来背，然后这个背锅的人/角色来拍板就可以了。拍板的人觉得现在大家都不专业，性能测试做了也没啥意义（对于你目前这个团队情况，我觉得性能测试做完，线上仍然有性能问题这个可能性确实是有的），干脆一刀切全部不做，通过线上监控 + 云服务的灵活伸缩来处理，也是可以的。

当然，从完善的质量保障角度，性能测试肯定不能全部不做，所以可以后面多给开发产品普及下性能出问题影响业务的案例，以及在后面真出事故后，复盘里增加对故障涉及接口的性能测试，这样来逐步推进。