インターフェイステストとは? 種類と例
⚡ スマートサマリー
インターフェーステストは、接続された2つのソフトウェアシステムが正しくデータを交換していることを検証します。アプリケーションが行うすべてのリクエストを伝送するWebサーバー、アプリケーションサーバー、データベースサーバー間のリンク、およびそれらの周辺のエラー処理を対象とします。
インターフェーステストとは何ですか?
インターフェイステスト これは、2つの異なるソフトウェアシステム間の通信が正しく行われているかどうかを検証するソフトウェアテストの一種として定義されます。
2つのコンポーネントを統合する接続をインターフェースと呼びます。コンピュータの世界では、このインターフェースはAPIやWebサービスなど、あらゆるものを指します。これらの接続サービスまたはインターフェースのテストは、インターフェーステストと呼ばれます。
インターフェイスは実際には、デバイスとユーザー間の通信を可能にする一連のコマンド、メッセージ、およびその他の属性で構成されるソフトウェアです。
重要な点は、インターフェースにはtract: 合意されたリクエスト形式、合意されたレスポンス形式、合意されたエラーコードのセット、および合意されたタイムアウト。インターフェース テスト演習では、trac両側からtが送られるため、一方のチームが行った変更がもう一方のチームにひっそりと影響を与えることはありません。このトラフィックのほとんどは画面に到達しないため、検出された欠陥は目に見えません。 ブラックボックステスト ユーザーインターフェースのみを通じて実行されます。
インターフェーステストのやり方
インターフェイス テストには、次の XNUMX つの主要セグメントのテストが含まれます。
- Webサーバーとアプリケーションサーバーのインターフェース
- アプリケーションサーバーとデータベースサーバーのインターフェース。
上記のシナリオでは、インターフェイスのテストが行われます。
- サーバーが正しく実行されているかどうかを確認します
- エラーは適切に処理されるか、アプリケーションによって行われたクエリに対してエラー メッセージが返されます。
- 途中で 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アプリケーションのテスト.

