SOA テストとは例を含むチュートリアル

SOAテストとは何ですか?

SOA (サービス指向) ArchiSOA (アーキテクチャ) テストは、アプリケーション コンポーネントが通常はネットワーク上の通信プロトコルを介して通信するように設計された SOA アーキテクチャ スタイルのテストです。

SOAとは

SOA は、ビジネス ニーズを満たすためにビジネス アプリケーションとプロセスを統合する方法です。

ソフトウェア エンジニアリングでは、SOA はビジネス プロセスに俊敏性と柔軟性をもたらします。 プロセスまたはアプリケーションへの変更は、システム全体に影響を与えることなく、特定のコンポーネントに向けることができます。

SOA のソフトウェア開発者は、と呼ばれるプログラムの塊を開発または購入します。 サービス。

サービスとは？

• サービスは、アプリケーションまたはビジネス プロセスの機能単位であり、他のアプリケーションまたはプロセスで再利用または繰り返しできます。(たとえば、上の図では、Payment Gateway は、任意の電子商取引サイトで再利用できるサービスです。)支払いが必要になるたびに、電子商取引サイトはペイメント ゲートウェイ サービスを呼び出し/要求します。ゲートウェイで支払いが完了すると、応答が電子商取引 Web サイトに送信されます)
• サービスは組み立てが簡単で、コンポーネントの再構成も簡単です。
• サービスはビルディングブロックに例えることができます。 必要なあらゆるアプリケーションを構築できます。 アプリケーションまたはビジネス プロセスへの追加や削除は簡単です。
• サービスはコードの塊としてではなく、サービスが実行するビジネス機能によって定義されます。

ウェブサービス

Web サービスは、Web 上で利用できる独立したアプリケーション コンポーネントです。

これらは Web 上で公開、検索、使用できます。 彼らはインターネットを介して通信できます。

1. サービス プロバイダーはサービスをインターネットに公開します。
2. クライアントは、Web サービス レジストリから特定の Web サービスを検索します。
3. 必要な Web サービスの URL と WSDL が返されます。 WSDL と URL を使用すると、サービス プロバイダーとリクエスタ間の通信は SOAP メッセージを通じて行われます。
4. コンシューマが Web サービスを呼び出すと、プロバイダへの HTTP 接続が確立されます。
   SOAP メッセージは、必要な Web サービス ロジックを呼び出すようにプロバイダーに指示するために作成されます。
5. プロバイダーから受信した応答は、HTTP 応答に埋め込まれる SOAP メッセージです。 この HTTP レスポンスは、コンシューマ アプリケーションが理解できるデータ形式です。

例

Web サイトや検索エンジンのホームページには、毎日の天気予報が表示されます。 天気予報セクションを全面的にコーディングする代わりに、天気予報のサービスをベンダーから購入してページに統合できます。

SOA テスト

SOAはさまざまなテクノロジーで構成されています。 SOA を使用して構築されたアプリケーションには、疎結合されたさまざまなサービスがあります。

SOA テストは 3 つのシステム層に焦点を当てる必要があります

サービス層

この層はサービス、つまりビジネス機能から派生したシステムによって公開されるサービスで構成されます。

例えば ​​-

以下で構成されるウェルネス Web サイトを考えてみましょう。

1. 体重トラッカー
2. 血糖トラッカー
3. 血圧トラッカー

トラッカーには、入力されたそれぞれのデータと日付が表示されます。 サービス層は、データベースからそれぞれのデータを取得するサービスで構成されます。

• 体重追跡サービス
• 血糖追跡サービス
• 血圧追跡サービス
• ログインサービス

プロセス層

プロセス層は、単一​​の機能の一部であるサービスの集合であるプロセスで構成されます。

プロセスは、ユーザー インターフェイスの一部 (例: 検索エンジン)、ETL ツールの一部 (データベースからデータを取得するため) である場合があります。

この層の主な焦点は、ユーザー インターフェイスとプロセスにあります。

体重トラッカーのユーザー インターフェイスとデータベースとの統合が主な焦点です。

以下の機能が考慮されます

1. 新しいデータの追加
2. 既存のデータを編集する
3. 新しいトラッカーの作成
4. データの削除

消費者層

この層は主にユーザー インターフェイスで構成されます。

レイヤーに基づいて、SOA アプリケーションのテストは XNUMX つのレベルに分散されます。

1. サービスレベル
2. インタフェースレベル
3. エンドツーエンドレベル

• テスト設計にはトップダウンアプローチが使用されます。
• テストの実行にはボトムアップアプローチが使用されます。

SOA テストの戦略

テスト計画アプローチ、

• SOA テスターはアプリケーションの完全なアーキテクチャを理解する必要があります。
• アプリケーションは、独立したサービス (独自の要求および応答構造を持ち、応答を形成するために他のサービスに依存しないサービス) に分割する必要があります。
• アプリケーション構造は、データ、サービス、フロントエンド アプリケーションの XNUMX つのコンポーネントに再編成する必要があります。
• すべてのコンポーネントを注意深く分析し、ビジネス シナリオを書き留める必要があります。
• ビジネス シナリオは、一般的なシナリオとアプリケーション固有のシナリオに分類する必要があります。
• A トレーサビリティマトリクス を準備し、すべてのテスト ケースをビジネス シナリオに基づいて追跡する必要があります。

テスト実行アプローチ

• 各サービス コンポーネントをテストする必要があります。
• 統合テスト サービスを通じたデータ フローとデータの整合性を検証するには、サービス コンポーネントの一部を実行する必要があります。
• システムテスト フロントエンド アプリケーションとデータベース間のデータ フローを検証するには、完全なモデルの検証を行う必要があります。
• 性能試験 微調整して最適なパフォーマンスを得るために行う必要があります。

SOA テスト方法

1) ビジネスシナリオ主導のデータベースのテスト、

• システムに関連するさまざまなビジネス側面を分析する必要があります。
• シナリオは、以下の統合に基づいて開発される必要があります。
• さまざまな ウェブサービス アプリケーションの
• Web サービスとアプリケーション。
• データのセットアップは、上記のシナリオに基づいて行う必要があります。
• データのセットアップは、エンドツーエンドのシナリオもカバーできるように行う必要があります。

2) スタブ

• サービスをテストするためにダミー インターフェイスが作成されます。
• これらのインターフェイスを通じてさまざまな入力を提供でき、出力を検証できます。
• アプリケーションがテスト対象ではない外部サービス (サードパーティ サービス) へのインターフェイスを使用する場合、統合テスト中にスタブが作成される可能性があります。

3) 回帰テスト

• 回帰テスト システムの安定性と可用性を確保するために、複数のリリースがある場合は、アプリケーションの変更を行う必要があります。
• アプリケーションの重要な部分を形成するサービスをカバーする包括的な回帰テスト スイートが作成されます。
• このテスト スイートは、プロジェクトの複数のリリースで再利用できます。

4) サービスレベルテスト

サービス レベル テストには、コンポーネントの機能、セキュリティ、パフォーマンス、相互運用性のテストが含まれます。

すべてのサービスは、最初に個別にテストする必要があります。

5) 機能テスト

機能テストはサービスごとに実行する必要があります。

• サービスが各リクエストに対して適切な応答を提供することを確認します。
• 無効なデータ、不正なデータなどを含むリクエストに対して正しいエラーが受信されます。
• 実行時にサービスが実行する必要があるすべての操作について、各要求と応答を確認します。
• サーバー、クライアント、またはネットワーク レベルでエラーが発生した場合の障害メッセージを検証します。
• 受信した応答が正しい形式であることを検証します。
• 応答で受信したデータが要求されたデータに対応していることを検証します。

6) セキュリティテスト

Web サービスのセキュリティ テストは、SOA アプリケーションのサービス レベル テスト中の重要な側面です。 これにより、アプリケーションの安全性が確保されます。

テスト中に次の要素をカバーする必要があります。

• Web サービスは、WS-Security テストによって定義された業界標準に従う必要があります。
• セキュリティ対策は完璧に機能する必要があります。
• データの暗号化と Digi書類への署名
• 認証と承認
• SQL インジェクション、マルウェア、XSS、CSRF、その他の脆弱性は XML 上でテストされます。
• サービス拒否攻撃

7) パフォーマンステスト

サービスは再利用可能であり、複数のアプリケーションが同じサービスを使用している可能性があるため、サービスのパフォーマンス テストを行う必要があります。

テスト中は次の要素が考慮されます。

• サービスのパフォーマンスと機能は、高負荷の下でテストする必要があります。
• サービスのパフォーマンスは、個別に動作する場合と、アプリケーション内で動作する場合とを組み合わせて比較する必要があります。
• サービスの負荷テストを実行する必要がある
• 応答時間を確認するため
• ボトルネックをチェックする
• CPUとメモリの使用率を確認する
• スケーラビリティを予測する

8) 統合レベルのテスト

• サービス レベル テストは、個別のサービスの適切な動作のみを保証し、結合されたコンポーネントの動作を保証するものではありません。
• 統合テストは主にインターフェースに焦点を当てて行われます。
• このフェーズでは、考えられるすべてのビジネス シナリオをカバーします。
• アプリケーションの非機能テストは、このフェーズでもう一度実行する必要があります。 セキュリティ、コンプライアンス、パフォーマンス テストにより、あらゆる面でシステムの可用性と安定性が保証されます。
• サービス間のデータ通信の一貫性を検証するには、通信およびネットワーク プロトコルをテストする必要があります。

9) エンドツーエンドのテスト

このフェーズでは、アプリケーションが機能的にも非機能的にもビジネス要件を満たしていることを確認します。

エンドツーエンドテストでは、以下の項目が必ずテストされます。

• 統合後、すべてのサービスが期待どおりに動作する
• 例外処理
• アプリケーションのユーザーインターフェイス
• すべてのコンポーネントを通る適切なデータ フロー
• ビジネスプロセス

SOA テストの課題

• サービス用のインターフェースが不足している
• テストプロセスは複数のシステムにまたがるため、複雑なデータニーズが生じます。
• アプリケーションは、変更される傾向のあるさまざまなコンポーネントの集合です。 回帰テストの必要性はより頻繁にあります。
• マルチレイヤーアーキテクチャのため、欠陥を特定することが困難です。
• サービスはさまざまなインターフェイスで使用されるため、負荷の予測が難しく、パフォーマンス テストの計画が面倒になります。
• SOA は異種テクノロジの集合です。SOA アプリケーションのテストにはさまざまなスキルセットを持つ人材が必要となり、計画と実行のコストが増加します。
• アプリケーションは複数のサービスを統合したものであるため、セキュリティ テストにはそれなりの問題があります。 認証と認可の検証は非常に困難です。

SOA テストの使用例

以下の機能とサブ機能を含む電子商取引 Web サイトを考えてみましょう。

注文処理

フェーズ1

SOA テストの最初のフェーズ、つまりテスト戦略フェーズでは、アプリケーションはサービスとビジネス機能に分割されます。

以下にアプリケーション内のサービスがあると考えてみましょう。

• 注文を作成
• 顧客ステータスの確認
• 注文状況の変更
• 注文状況の確認
• 在庫を確認する

ビジネス機能はウェブサイトの機能と同じです。

ご注意: テスト戦略文書には、テストする必要があるサービスと機能のリストが含まれます。

フェーズ2

テスト計画フェーズ。 テストケースはレベルごとに書かれています。

1. エンドツーエンドのレベル。テスト ケースは、ビジネス ユース ケースおよびフローごとに作成されます。以下はテストケースの例です
   • アクティブなユーザーでオーダーを作成します。
   • 非アクティブなユーザーでオーダーを作成します。
   • 注文数量 < 利用可能数量の、利用可能な製品で注文を作成します。
   • 注文数量 > 利用可能数量で、利用可能な製品の注文を作成します。
   • 複数の商品を含む注文を作成する
   • 注文を完全にキャンセルします。
   • 注文を部分的にキャンセルします。
2. 統合レベル。テスト ケースは、データベースとユーザー インターフェイスを統合するために作成されます。以下はテストケースの例です。
   • 単一のアイテムで新しい注文を作成します。 注文がデータベース上に作成されたことを確認します。
   • 単一のアイテムで新しい注文を作成します。 注文に対して計算された価格が正しいことを確認してください。
   • 単一のアイテムで新しい注文を作成します。 利用可能な製品の数量が注文金額分少ないことを確認してください。
   • UI に表示される注文のステータスがデータベース上のステータスと同じであることを確認します。
   • 注文をキャンセルし、データベース上で注文のステータスが変更されていることを確認します。
   • 初めて支払いを行う場合は、UI に入力した支払い詳細がデータベースに保存されていることを確認します。
   • 支払いを返金する場合は、データベースの支払い詳細が UI に表示されることを確認します。
3. サービスレベル。 各サービスはすべてのデータ条件についてテストされます。

以下にいくつかの例を示します。

いいえ。	注文の詳細	注文条件
1	注文を作成します。 アイテム数 = 1	注文数量 < データベース上の数量
2	注文を作成します。 アイテム数 > 1	注文数量 < データベース上の数量。
3	オーダーの作成アイテム数 = 1	注文数量 > データベース上の数量
4	注文ステータスを確認する	データベースのステータス = アクティブ
5	注文ステータスを確認する	データベース上のステータス = 出荷済み
6	注文ステータスを確認する	データベース上のステータス = キャンセル済み
7	注文ステータスを確認する	注文ID = 無効です
8	製品の在庫状況を確認する	製品の数量 >0
9	製品の在庫状況を確認する	製品の数量 =0
10	製品の在庫状況を確認する	製品ID = 無効です

フェーズ 3 – テストの実行

テストの実行ではボトムアップのアプローチが使用されます。つまり、最初にサービス レベルのテストが行​​われ、次に統合レベルのテストが行​​われ、最後にテストが行​​われます。 エンドツーエンドのテスト.

1) サービスレベル

それを考えてみましょう ソープイ このツールはアプリケーションをテストするために考慮されます。

この wsdl および URL が SOAP のテスト ウィンドウに表示されます。

各サービスのリクエストはリクエストウィンドウに表示されます。

サービス レベルのテスト ケースに従ってデータを変更することで、テスト ケースごとにリクエストが作成されます。

テストケース	リクエスト	期待される応答
注文を作成します。 アイテム数 = 1 注文数量 < データベース上の数量	×2 2	o3251 成功
オーダー番号を作成します。 アイテム数 > 1 注文数量 < データベース上の数量	y1 1 y2 3	o3251 成功
オーダー番号を作成します。 アイテム数 = 1 注文数量 > データベース上の数量	×23 200	ヌル失敗しました
注文ステータスの確認データベース上のステータス = アクティブ	o9876	アクティブ成功
注文ステータスを確認しますデータベース上のステータス = 発送済み	o9656	出荷済み成功
注文ステータスを確認してください注文 ID = 無効です	y5686	ヌル失敗しました
製品の在庫状況を確認する 製品の数量 >0	d34	34 はい成功
製品の在庫状況を確認する 製品の数量 =0	y34	0 いいえ成功
製品の在庫状況を確認する 製品 ID = 無効です	だ	失敗しました

2) 統合レベル

統合レベルのテスト ケースは、ユーザー インターフェイスとデータベースで実行されます。

• 単一アイテムの注文を作成する –
• ユーザーが Web サイトを開きます。
• 注文しに行きます。
• 有効な製品と数量を選択し、注文を保存します。
• 注文が正常に行われたことを示すメッセージが表示されます。
• ユーザーはデータベースを開き、注文の詳細が Web サイトで入力したものと同じかどうかを確認します。

3) エンドツーエンドレベル

ビジネス フローとユースケースはユーザー インターフェイス上で実行されます。

• 複数の商品を含む注文を作成する –
• ユーザーが Web サイトを開きます。
• 注文しに行きます。
• 有効な製品を問い合わせ、数量を指定してカートに追加します。
• 他の有効な製品が有効な数量で追加され、注文が保存されます。 新しい支払い方法で支払いが行われ、注文が行われます。
• 「注文が正常に完了しました」というメッセージが表示されます。
• テスターは、フロー全体がデータの偏りなく実行されていることを検証する必要があります。

まとめ

優れたサービスを提供するためのテスト、リソース、ツール、およびコンプライアンスの適切な戦略を描くことで、SOA テストは完全かつ完全にテストされたアプリケーションを提供できます。