模拟接口返回成功，不就不用花钱了吗

Why not！虽然这是第三方接口，但是也会影响到自身服务的性能啊！

不做的话，这个接口可能就是你的性能瓶颈。而且还得加上监控报警，万一第三方的接口挂了，导致自己的服务挂掉或者无法响应。就很亏

从技术完整性角度，是个接口最好都做一下性能测试摸个底。

但从实际场景角度，要从几个方面考虑：
1、这个接口日常调用量大吗？不大的话是不是可以改为通过监控预警来观察性能？
2、第三方接口对接的网络链路质量满足性能测试需要吗？如果有性能问题第三方愿意配合吗？第三方给出的测试环境接口性能是否和生产基本没差异？如果这几个问题都是否定回答，那这个测试也没太大做的必要，因为做了意义不大，知道了问题但也解决不了问题。通过监控预警来观察更好。
3、从公司角度，做性能测试中的每次调用如果都得花钱，除非能说服老板性能测试的收益比这个多次调用成本要高很多，值得投入。否则我相信大部分公司领导都不大会接受这样的性能测试，要不让你自己内部模拟代替，要不找商务沟通性能测试期间特殊处理，去掉调用收费。

以下是我的理解：

• 首先评估下第三方接口性能有问题对你们有没有影响，毛影响没有就别管了。
• 都收费的第三方接口了，找他们给个性能参数不就行啦，你花钱了你就是大爷。
• 线上监控看下这个接口实际性能表现，预估下是否符合他们给的性能指标，是否满足你们业务发展的需要
• 按第三方性能参数，设置 mock，先把自己系统性能瓶颈摸清
• 如果第三方的性能指标线上观察后不符合你们的预期，找他们谈撒

最好的办法还是线上观察后预估，然后和第三方接口做沟通，第三方接口的性能本来是他们要保证的，你是被服务方。

你做大保健的时候指明点个技术最好的，难道还特么要花钱把整个店的技师包了一个个试么。。。

以前就遇到过这个问题
1）领导首先不会让花钱的。
2）在不花钱的情况下怎么解决呢，那就是打桩了。开发从第三方那边要到了他们接口的一些性能数据，比如他们接口响应时间多少支持多少 QPS。那么我们就以他们的响应时间改造代码，比如模拟他们的接口延时多少 ms.然后以他们的 QPS 为极限 QPS 压测。得出性能数据。
最终你还是要明确，本次性能测试的目的是啥，是验证你自身应用的代码是否有瓶颈，还是验证他们的瓶颈呢。一般第三方的瓶颈无需我们来测试，需要他们提供一些他们接口的性能数据作为参考。

拿到数据后评估一下依赖的第三方接口是否能满足你当前的业务量。如果你预估你这边的 QPS 需要达到 1000qps,而你的第三方依赖方只能有 100qps,那么你根本就无需测试了。让他们优化，如果不能优化那就是你们这边业务或者架构是否合理了。