回答:
簡単な答え：サードパーティベンダーAPIのテストスイートが必要です。そのため、テストスイートを開発する必要があります。
他の誰かがあなたのためにそれを行うことを期待しないでください。また、適切なテストを自動的に生成するための「魔法の弾丸」を期待しないでください。
あなたがさらに試すことができるいくつかのこと：
これらが機能するかどうかは、ベンダーが誰で、どのようなAPIを念頭に置いているかによって異なります。ファイルなどの検査可能な出力を生成するAPIは、API呼び出しが成功したかどうかを判断するためにモノの動作を観察する必要がある物理デバイスを制御するAPIよりもテストがはるかに簡単です。
ポスターのフレージングに基づいて、それは単なるテストではありません、IMO。APIの単体テストを作成し、すべてが期待どおりに機能することを確認したら、ユーザーが行う前に問題をキャッチするために、サードパーティのAPIを監視する必要があります。それはサードパーティAPIの本当のリスクです-それはあなたのコードではなく、APIで行われたテストの量や、いつ/いつ変更されるかを制御することはできません。
（免責事項：ここで使用されている製品名）soapUIを使用してAPIテストを記述する場合、それらのテストをAlertSiteで操作モニターとして再利用して、APIが期待どおりに機能し続けることを確認できます。テストに失敗した場合、ユーザーが電話をかける前に警告を受け取り、アプリが機能しないことを訴えることができます。
この問題には2つのアプローチがあります...
アプリは実際のユーザートラフィックで本番環境で稼働しています。
ライブトラフィックがあり、外部apiに依存する運用環境にアプリがある場合、外部apiが通知せずに変更を行ったときにできるだけ早く知るために、きめ細かく監視し、適切なしきい値を設定する以外に選択肢はありません。
次のことを常に考慮する必要があります。
アプリはインストール済みで、バージョン/リリースが計画されています：
この場合、失敗する猶予期間があります...ライブユーザーは、外部APIの破壊的な変更の影響をすぐには受けません。
私の意見では、これはより簡単な作業です。外部APIを呼び出すアプリケーションへの実際のトランザクション/ http /リクエストを行うテスト（完全なエンドツーエンドテスト）を記述し、障害がないことを確認します。テストキットやモックトランザクションはありません。
このタスクが完了したら、24時間ごと、1分ごとなどに実行することを選択できます。
良い習慣：
ツール：