インターフェイステストとは? 種類と例

⚡ スマートサマリー

インターフェーステストは、接続された2つのソフトウェアシステムが正しくデータを交換していることを検証します。アプリケーションが行うすべてのリクエストを伝送するWebサーバー、アプリケーションサーバー、データベースサーバー間のリンク、およびそれらの周辺のエラー処理を対象とします。

  • 🔗 定義: インターフェースとは、API、Webサービス、メッセージキューなど、2つのコンポーネントを接続するあらゆる接続のことです。
  • 🧭 2つのセグメント: テスト対象は、Webサーバーとアプリケーションサーバー間の接続、およびアプリケーションサーバーとデータベースサーバー間の接続です。
  • 📄 実例: XML入力とJSON出力は、それぞれ公開されているフォーマット仕様に基づいて検証されます。
  • 🧪 テストタイプ: ワークフロー、エッジケース、パフォーマンスと負荷、さらに各システムを個別に検証する。
  • 🛠️ ツーリング: APIクライアントとサービス仮想化は、クリック操作を行うためのユーザーインターフェースが存在しない場合でも、リクエストを駆動します。
  • 🔍 範囲の境界: インターフェーステストは、接続接続に焦点を当てた統合テストのサブタイプです。tracそれ自体。

Webサーバーとアプリケーションサーバー間のインターフェーステスト

インターフェーステストとは何ですか?

インターフェイステスト これは、2つの異なるソフトウェアシステム間の通信が正しく行われているかどうかを検証するソフトウェアテストの一種として定義されます。

2つのコンポーネントを統合する接続をインターフェースと呼びます。コンピュータの世界では、このインターフェースはAPIやWebサービスなど、あらゆるものを指します。これらの接続サービスまたはインターフェースのテストは、インターフェーステストと呼ばれます。

インターフェイスは実際には、デバイスとユーザー間の通信を可能にする一連のコマンド、メッセージ、およびその他の属性で構成されるソフトウェアです。

重要な点は、インターフェースにはtract: 合意されたリクエスト形式、合意されたレスポンス形式、合意されたエラーコードのセット、および合意されたタイムアウト。インターフェース テスト演習では、trac両側からtが送られるため、一方のチームが行った変更がもう一方のチームにひっそりと影響を与えることはありません。このトラフィックのほとんどは画面に到達しないため、検出された欠陥は目に見えません。 ブラックボックステスト ユーザーインターフェースのみを通じて実行されます。

インターフェーステストのやり方

インターフェイス テストには、次の XNUMX つの主要セグメントのテストが含まれます。

  1. Webサーバーとアプリケーションサーバーのインターフェース
  2. アプリケーションサーバーとデータベースサーバーのインターフェース。

上記のシナリオでは、インターフェイスのテストが行​​われます。

  • サーバーが正しく実行されているかどうかを確認します
  • エラーは適切に処理されるか、アプリケーションによって行われたクエリに対してエラー メッセージが返されます。
  • 途中で Web サーバーへの接続がリセットされた場合の結果を確認する

下の図は、ブラウザがWebサーバーと通信し、Webサーバーがアプリケーションサーバーと通信し、アプリケーションサーバーがデータベースサーバーと通信するという、これら2つのセグメントを1つのチェーンとして示しています。

ウェブサーバー、アプリケーションサーバー、データベースサーバーチェーン全体にわたるインターフェーステスト

実際には、テスターはそのチェーンを一度に1ホップずつ実行します。各ホップは、まず有効なリクエストで駆動され、次に不正なリクエストで駆動され、最後に意図的に終端が利用できない状態にして駆動されます。これにより、成功パスと失敗パスの両方が同じに対して記録されます。 テストケース.

インターフェーステストの例

任意の xyz アプリケーションに対して、インターフェースが XML ファイルを入力として受け取り、 JSONの 出力としてファイルを使用します。このアプリケーションのインターフェースをテストするには、XMLファイル形式とJSONファイル形式の仕様のみが必要です。

これらの仕様を参考に、サンプル入力XMLファイルを作成し、インターフェースに入力することができます。そして、入力(XML)ファイルと出力(JSON)ファイルを要件と照合して検証するのが、インターフェーステストです。

この例で必要ないものに注目してください。画面も、フロントエンドの構築も、インターフェース内部のコードに関する知識も必要ありません。テストを書くには2つのフォーマット仕様だけで十分です。そのため、ユーザーインターフェースが存在するずっと前からインターフェーステストを開始できるのです。

インターフェーステストを行う理由

インターフェーステストが完了しました

  • エンドユーザーまたは顧客が特定のソフトウェア製品を使用する際に問題が発生しないようにするため
  • エンドユーザーが通常アクセスするアプリケーション領域を特定し、その使いやすさもチェックします。
  • システム間で通信を伝播する際のセキュリティ要件を検証するため
  • ソリューションがアプリケーション サーバーと Web サイト間のネットワーク障害に対応できるかどうかを確認するには

コスト面も考慮すべき点です。リクエスト形式の不具合は、2つのシステムがまだ接続段階にあるうちに修正すれば安価ですが、下流システムが既に不正なデータを保存してしまうと、修正コストが高くなります。

インターフェーステストの種類

インターフェイス テスト中に、インターフェイス上でさまざまな種類のテストが実行されます。

  • ワークフロー: これにより、インターフェイス エンジンが標準ワークフローを期待どおりに処理できるようになります。
  • エッジケース - 予期しない値: これは、テストに日付、月、日の順不同が含まれる場合に考慮されます。
  • パフォーマンス、負荷、ネットワークのテスト: 大容量インターフェースには、 負荷テスト インターフェイス エンジンと接続インフラストラクチャによっては、少量のインターフェイスよりも
  • 個々のシステム: これには、各システムを個別にテストすることが含まれます。たとえば、小売店の請求システムと在庫管理システムは、個別に動作できる必要があります。

最初の項目は、 ワークフローテスト シナリオを再利用するため、最後の項目は モジュールテストなぜなら、単独で故障するシステムは、接続されると再び故障するからである。

インターフェースのテスト戦略

インターフェーステスト戦略は、実装に関係なく共通のテストを使用してインターフェースをテストするために使用される方法です。tract テストケースを作成し、インターフェーステスト戦略の各実装に対してテストケースの具体的なインスタンスを作成します。ベース/アブソリュートtractテストケースは実装に依存しないテストを実行する一方、具体テストはテスト対象オブジェクトのインスタンス化と実装固有のテストの実行を担当します。

その構造の利点は再利用性です。同じインターフェースの 3 番目の実装が現れると、tract スイートは変更されずに実行され、インスタンス化コードのみを記述する必要があります。同じアイデアは、より大規模に以下に適用されます。 コンポーネントのテスト共通のコンtractスイートは、その要件を満たすと主張するすべてのコンポーネントに対して実行されます。

インターフェーステストツール

インターフェースには画面がないため、ツールはリクエストを直接構築し、生のレスポンスに対して検証を行う必要があります。チームは通常、3つのカテゴリのツールを組み合わせて使用​​します。

  • APIクライアントとリクエストビルダー: ツール Postman, SoapUIInsomniaとHoppscotchは、REST、SOAP、またはGraphQL呼び出しを送信し、それらを再利用可能なコレクションとして保存し、ステータスコード、ヘッダー、およびレスポンスボディに対してアサートを行います。
  • Code-レベルテストライブラリ: 既存のテストスイート内で動作するライブラリを使用すると、インターフェースチェックを単体テストと並行して実行し、ビルドごとに実行できるため、テストが古くなってしまうのを防ぐことができます。
  • ロードおよびプロトコルツール: 例えば JMeter 同じインターフェースをボリュームで駆動し、それが機能チェックを 性能試験 接続の。
  • サービス仮想化とモック: 終端の代わりにスタブを使用することで、片側が利用できない場合、未完成の場合、または繰り返し呼び出しを行うには費用がかかりすぎる場合に、もう片側をテストすることができます。

選択よりも網羅性が重要です。どのクライアントを選択するにしても、リクエストのコレクションはコードとともにバージョン管理システムに保存する必要があります。そうすることで、インターフェースの変更とテストの変更が同じコミットで反映されます。より広範なカテゴリの詳細については、以下を参照してください。 APIテスト.

インターフェーステストのチェックリストとベストプラクティス

簡単なチェックリストを使用することで、リリース間でインターフェースの網羅性を正確に維持できます。アプリケーション全体ではなく、接続ごとにチェックリストを確認してください。

  • とともにtract 最初: リクエストとレスポンスのスキーマが、データ型やオプションフィールドを含め、フィールドごとに公開されている仕様と一致していることを確認してください。
  • 境界値: 空のペイロード、最大長を超えるフィールド、予期しない文字セット、および逆順の日付形式を送信してください。
  • エラー発生経路: すべての失敗がスタックトレースではなく、意味のあるコードとメッセージを返すことを確認してください。 tracあるいは、静かな成功と言えるかもしれません。
  • タイムアウトと再試行: リクエストの途中で接続を中断し、呼び出し元がトランザクションを重複させることなく安全に再試行することを確認します。
  • セキュリティ: リンクの認証、認可、暗号化を確認し、エラーメッセージから内部情報が漏洩しないことを確認してください。
  • データの一貫性: 反対側から記録を読み返し、転送中にデータが切り詰められたり、再エンコードされたり、順序が変更されたりしていないことを確認してください。
  • ボリューム: 同時負荷がかかった状態で、最もトラフィック量の多い呼び出しを繰り返し実行し、接続プールの枯渇を監視します。

このチェックリストを繰り返し実行可能にするには、次の3つの方法が有効です。まず、インターフェースは画面よりも変化が緩やかなため、テストスイートを自動化し、ビルドごとに実行します。次に、インターフェースの不具合はスクリーンショットから再現することがほぼ不可能なため、すべての不具合についてリクエストとレスポンスの完全なログを記録します。最後に、他のテストスイートで作成されたテストデータとは独立させ、不具合の原因がレコードの欠落ではなくインターフェースにあることを特定できるようにします。

これらのチェックは、以下に説明するより広範な計画の中に自然に収まります。 ソフトウェアテストの種類、そしてそれらは、同じ接続がエンドツーエンドで実行される前に実行されます。 システムテスト.

インターフェーステストと統合テスト

この2つの用語は対立するものではなく、むしろ関連しています。インターフェーステストは、統合作業の中でも接続そのものに焦点を当てた部分です。以下の表は、それぞれの重点事項を示しています。

インターフェイステスト 統合テスト
コンポーネントまたはシステム間のインターフェイスのテストに関係する統合テスト タイプ インターフェイス内の欠陥や、統合されたコンポーネントまたはシステム間の相互作用の欠陥を明らかにするために実行されるテスト。
フォーカスはtract — リクエスト形式、レスポンス形式、エラーコード、タイムアウト 焦点は、コンポーネントが結合された後のそれらの複合的な動作です。
仕様が存在するとすぐに実行可能で、遠端はスタブ化される。 参加するコンポーネントは一緒に構築および展開する必要があります。
障害は1つの接続箇所を示している 故障の原因は、組み立てられたグループ内のどのコンポーネントにも存在する可能性がある。

より広い分野に初めて触れる人は、周囲のレベルが説明されているのを見つけるでしょう 統合テスト そして一般的に ソフトウェアテスト 序論では、上記の用語は標準的なものから来ている。 ソフトウェア工学 練習中、ブラウザ向けシステムの場合、同じ接続が最終的に再び実行されます。 Webアプリケーションのテスト.

よくあるご質問

通常、統合カバレッジを担当するQAエンジニアが、両システムの開発者と協力してテストを行います。サービス重視の製品では、画面操作スキルよりもリクエスト構築スキルが求められるため、専任のAPIテスターが担当します。

目に見える出力がないため検査ができず、サードパーティのエンドポイントは自由に呼び出すことができず、テストデータは両側に存在しなければならず、仕様は予告なく変更される。スタブとバージョン管理されたリクエストコレクションを使用することで、これらの問題のほとんどを軽減できる。

これらは大きく重複しています。API はインターフェースの一種なので、 APIテスト インターフェーステストは、その特定のテクノロジーに適用されます。インターフェーステストには、APIを持たないファイルドロップ、メッセージキュー、データベースリンクなども含まれます。

いいえ。名前は同じですが、対象が異なります。インターフェーステストはシステム間の接続をチェックし、ユーザーインターフェーステストは画面、コントロール、レイアウトをチェックします。この2つを混同すると、サーバー側の接続がテストされないままになってしまいます。

要求と応答の仕様が合意され次第(通常はどちらのシステムも完成する前)、テストスイートを早期に実行できるように準備します。遠端側のテストスイートを事前に準備しておくことで、テストスイートを早期に実行でき、両方のシステムが稼働した後は同じスイートを再利用できます。

少なくとも 1 つの陽性テストと 1 つの陰性テストが記録されたエンドポイントの割合、実際にトリガーされた宣言済みエラー コードの割合、およびエスカレーションされたインターフェース欠陥の数ping 後の段階へ。生の検査数だけではほとんど何も証明できない。

機械学習はスキーマを読み込み、人間が見落としがちな境界ペイロードやネガティブペイロードを生成します。そして、失敗したレスポンスをクラスタリングすることで、根本原因が8回も報告されるのを防ぎます。また、既存のリクエストと一致しなくなったスキーマの変更も検出します。

はい。スキーマまたはサンプルペイロードが与えられると、リクエストビルダー、アサーション、スタブレスポンスを迅速に生成します。ただし、生成されたアサーションの正確さはスキーマまたはサンプルペイロードの正確さに依存するため、仕様は人間が提供する必要があります。tracその背後にある。