Answers:
简短的答案：您需要一个用于第三方供应商API的测试套件-因此您将不得不开发一个。
不要指望别人会为您做这件事，也不要指望能自动生成正确测试的“灵丹妙药”。
您可以尝试一些其他方法：
这些事情是否奏效取决于您的供应商是谁以及您想到的是哪种API。与控制某些物理设备的API相比，生成一些可检查的输出（如文件）的API比控制某些物理设备的API要容易得多，在API中，您必须观察事物的行为来确定API调用是否成功。
根据海报的措辞，它不仅仅是测试，IMO。在为API编写单元测试并确保一切正常后，您需要监视第三方API，以便在用户之前发现问题。这是第三方API的真正风险-这不是您的代码，您无法控制对API进行了多少测试或更改的时间/时间。
（免责声明：此处使用的产品名称）如果使用soapUI编写API测试，则可以在AlertSite中将这些测试重新用作操作监视器，以确保API能够按预期运行。如果测试未通过，您可能会在用户致电给您之前收到警报，并抱怨您的应用程序无法正常工作。
针对您感兴趣的领域（计划使用的功能）实施学习测试。学习测试是开发人员根据API的公共合同编写的集成测试。即使API的源代码可用，也不应针对内部实现细节编写测试。这种学习测试有两个目的-
有两种解决此问题的方法...
您的应用程序已经投入生产并具有真实的用户流量：
如果您的生产中的应用具有实时流量并且依赖于外部api，则您别无选择，只能密切监视并具有良好的阈值，以便在外部api进行更改而不通知时尽快知道。
您应该始终考虑到以下几点：
您的应用是安装，并且具有计划的版本/发行版：
在这种情况下，您会有宽限期失败...外部api的更改不会立即影响实时用户。
我认为这是一个更简单的任务。编写一个测试（完整的端到端测试），以对调用外部api的应用程序进行真正的事务处理/ http /请求，并检查是否没有失败。没有测试工具包，没有模拟真实交易。
完成此任务后，您可以选择每24H，1分钟等运行一次。
良好做法：
工具：