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

SOAテストとは何ですか?

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

SOAとは

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

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

SOA で働くソフトウェア開発者は、プログラムの一部を独自に開発するか、購入します。 サービス.

サービスとは？

下の図は、複数のeコマースサイトが呼び出すことができるサービスとして公開された決済ゲートウェイを示しています。

• サービスとは、アプリケーションまたはビジネスプロセスの機能単位であり、他のアプリケーションやプロセスによって再利用または反復することができます。（例えば、上の図では、決済ゲートウェイはあらゆるeコマースサイトで再利用できるサービスです。支払いを行う必要がある場合、eコマースサイトは決済ゲートウェイサービスを呼び出し、要求します。ゲートウェイで支払いが完了すると、eコマースサイトに応答が返されます。）
• サービスは組み立てが簡単で、コンポーネントの再構成も簡単です。
• サービスは、構成要素に例えることができます。必要なアプリケーションを構築することができ、アプリケーションや業務プロセスへの追加や削除も容易です。
• サービスは、コードの塊としてではなく、それが果たすビジネス機能によって定義される。

ウェブサービス

ほとんどのSOAサービスはWebサービスとして公開されているため、テスト層の前にWebサービス呼び出しの仕組みを明確にしておく価値がある。

ウェブサービス これらは、ウェブ経由で利用可能な独立したアプリケーションコンポーネントです。

これらはウェブ上で公開、検索、利用することができ、インターネットを介して通信します。以下の図は、プロバイダー、レジストリ、およびコンシューマーがどのように相互作用するかを示しています。

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

例:

以下のスクリーンショットは、外部サービスから提供され、検索エンジンのホームページに埋め込まれた天気予報を示しています。

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

SOAテストレイヤー

SOAは様々な技術で構成されており、SOAを用いて構築されたアプリケーションは、疎結合された様々なサービスを備えています。下の図は、テスト計画でカバーする必要のある3つのレイヤーを示しています。

SOAテストは、3つのシステム層に焦点を当てるべきである。

サービス層

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

例えば、以下のような要素で構成されるウェルネスウェブサイトを考えてみましょう。

• 重量 TracKER
• 血糖 TracKER
• 血圧 TracKER

Trackersはそれぞれのデータとその入力日を表示します。サービス層は、データベースからそれぞれのデータを取得するサービスで構成されます。

• 重量 Trackerサービス
• 血糖 Trackerサービス
• 血圧 Trackerサービス
• ログインサービス

プロセス層

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

これらのプロセスは、ユーザーインターフェース（例えば検索エンジン）の一部である場合もあれば、データベースからデータを抽出するETLツールの一部である場合もある。

この層の主な焦点は、ユーザーインターフェースとプロセスです。重みのユーザーインターフェース trackerとそのデータベースとの統合が主な焦点です。

以下の機能が検討対象となります。

• 新しいデータの追加
• 既存のデータを編集する
• 新しいを作成する tracKER
• データの削除

消費者層

この層は主にユーザーインターフェースで構成されており、下の画面にその様子が示されています。

これらの層に基づいて、SOAアプリケーションのテストは3つのレベルに分けられます。

• サービスレベル
• インタフェースレベル
• エンドツーエンドレベル

両者のアプローチは異なり、テスト設計にはトップダウン方式が用いられるのに対し、テスト実行にはボトムアップ方式が用いられる。

SOA テストの戦略

テスト計画のアプローチ

• SOAテスターは、アプリケーションの完全なアーキテクチャを理解している必要がある。
• アプリケーションは、独立したサービス（独自の要求と応答の構造を持ち、応答を生成するために他のサービスに依存しないサービス）に分割する必要があります。
• アプリケーションの構造を、データ、サービス、フロントエンドアプリケーションの3つのコンポーネントに再編成する必要がある。
• すべての構成要素を慎重に分析し、ビジネスシナリオを具体的に策定する必要がある。
• ビジネスシナリオは、共通シナリオとアプリケーション固有のシナリオに分類されるべきである。
• A Trac能力マトリックス 準備しておくべきであり、すべてのテストケースは tracビジネスシナリオに合わせて編集されています。

テスト実行アプローチ

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

SOA テスト方法

1) ビジネスシナリオに基づいたデータベースのテスト

• システムに関連する様々なビジネス面を分析する必要がある。
• シナリオは、アプリケーションの様々なWebサービスと、Webサービスとアプリケーションの統合に基づいて開発されるべきである。
• データ設定は、上記のシナリオに基づいて行う必要があります。
• データ設定は、エンドツーエンドのシナリオも網羅する必要がある。

2) スタブ

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

3) 回帰テスト

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

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

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

5) 機能テスト

機能テスト 各サービスにおいて以下のことを行う必要があります。

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

6) セキュリティテスト

ウェブサービスのセキュリティテストは、SOAアプリケーションのサービスレベルテストにおいて重要な側面であり、アプリケーションの安全性を保証するものである。

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

• ウェブサービスは、WS-Securityによって定義された業界標準を遵守しなければならない。
• セキュリティ対策は完璧に機能する必要があります。
• データの暗号化と文書へのデジタル署名。
• 認証と認可。
• SQLインジェクション、マルウェア、XSS、CSRF、その他の脆弱性は、 XML.
• サービス拒否攻撃。

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

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

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

• サービスのパフォーマンスと機能は、高負荷の下でテストする必要があります。
• サービスのパフォーマンスは、単独で動作する場合と、アプリケーションに組み込まれた場合とで比較する必要がある。
• 負荷テスト サービスのテストは、応答時間の検証、ボトルネックのチェック、CPUとメモリの使用率の検証、およびスケーラビリティの予測を行うために実施する必要があります。

8) 統合レベルのテスト

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

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

このフェーズでは、アプリケーションが機能面および非機能面の両方において、ビジネス要件に適合していることを確認します。

以下の項目は、検査中に必ずテストされます。 エンドツーエンドのテスト:

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

SOAテストにおける課題

これらの手法を適用することは決して容易ではなく、以下のような困難はほぼすべてのSOAプログラムで繰り返し発生する。

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

SOA テストツール

市場には、テスターがSOAアプリケーションのテストを行う際に役立つSOAテストツールが数多く存在します。以下に、代表的なSOAテストツールをいくつかご紹介します。

1) SoapUI

SoapUI サービスとサービス向けのオープンソースの機能テストツールです。 APIテスト.

• デスクトップアプリケーション
• SOAP、REST、HTTP、JMS、AMF、JDBCなど、複数のプロトコルをサポート
• ウェブサービスは、開発、検査、および呼び出しが可能である。
• 負荷テストにも使用できます。 自動化テスト、およびセキュリティテスト
• スタブはMockServicesで作成できます
• ウェブサービスリクエストとテストは、そのウェブサービスクライアントを通じて自動的に生成できます。
• レポート作成ツールが内蔵されています
• SmartBear社が開発し、 オープンソースの SoapUI 流通と商業 ReadyAPI エディション

2) Broadcom Service Virtualization（旧称 iTKO LISA）

LISAは、SOAなどの分散システム向けの機能テストソリューションを提供する製品スイートです。この製品はiTKOからCA Technologiesに譲渡され、現在はBroadcom Service Virtualizationとして販売されています。

• 回帰テスト、統合テスト、負荷テスト、およびパフォーマンス テストにも使用できます。
• テストの設計と実行に使用できます。

3) UFT One（旧HPサービステスト）

Service Test は、UI と共有サービスのテストの両方をサポートする機能テストツールです。その API テスト機能は Unified Functional Testing に統合され、現在は販売されています。 OpenText as UFT 一つ。

• サービスの機能テストとパフォーマンステストの両方を、単一のスクリプトで実行できます。
• Quality Centerと統合され、現在は販売されています。 OpenText ALM / 品質センター
• 膨大な量のサービスとデータを管理できる。
• JEE、AXIS、DotNet クライアント環境をシミュレートすることで相互運用性テストをサポートします。

4) Parasoft SOAtest

Parasoft SOAtestは、APIおよびAPI駆動型アプリケーションのテスト用に開発されたテストおよび分析ツールスイートです。

• Webサービス、REST、JSON、MQ、JMS、TIBCO、HTTP、およびXML技術をサポートします。
• 機能テスト、単体テスト、統合テスト、回帰テスト、セキュリティテスト、相互運用性テスト、コンプライアンステスト、およびパフォーマンステストが可能です。
• スタブは以下を使用して作成できます パラソフト仮想化より能力が高い SoapUI モックサービス。

SOA テストの使用例

以下の実例では、上記の戦略、手法、ツールを単一のeコマースサイトに段階的に適用していきます。

以下の機能とサブ機能を備えたeコマースウェブサイトを考えてみましょう。

注文処理

以下の図は、注文処理をサービスとなるサブ機能に分解したものです。

フェーズ1

SOAテストの最初の段階であるテスト戦略段階では、アプリケーションはサービスとビジネス機能に分割されます。

アプリケーションに含まれる以下のサービスについて考えてみましょう。

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

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

注：テスト戦略文書には、テスト対象となるサービスと機能のリストが含まれます。

フェーズ2

これはテスト計画段階です。 テストケース 各レベルごとに作成されています。

エンドツーエンドレベル。 テストケースは、各業務ユースケースと業務フローごとに作成されます。以下にテストケースの例を示します。

• アクティブユーザーで注文を作成する。
• 非アクティブなユーザーでオーダーを作成します。
• 在庫のある商品で、注文数量が在庫数量未満となるように注文を作成します。
• 在庫のある商品で、注文数量が在庫数量よりも多い注文を作成してください。
• 複数の商品を含む注文を作成します。
• 注文を完全にキャンセルします。
• 注文を一部キャンセルする。

統合レベル。 データベースとユーザーインターフェースの統合に関するテストケースを作成します。以下にテストケースの例を示します。

• 単一のアイテムで新しい注文を作成します。 注文がデータベース上に作成されたことを確認します。
• 単一のアイテムで新しい注文を作成します。 注文に対して計算された価格が正しいことを確認してください。
• 単一商品で新規注文を作成します。注文数量分だけ在庫数量が減少していることを確認してください。
• UIに表示されている注文ステータスが、データベース上のステータスと同じであることを確認してください。
• 注文をキャンセルし、データベース上で注文のステータスが変更されていることを確認します。
• 初回支払いの場合、UIに入力した支払い情報がデータベースに保存されていることを確認してください。
• 支払いを返金する場合は、データベースの支払い詳細が UI に表示されることを確認します。

サービスレベル。 各サービスは、あらゆるデータ条件についてテストされています。以下にいくつかの例を示します。

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

フェーズ3 — テスト実行

テスト実行はボトムアップ方式を採用しており、まずサービスレベルのテストを行い、次に統合レベルのテスト、最後にエンドツーエンドのテストを実施します。

1) サービスレベル

では、 SoapUI このツールはアプリケーションのテストに使用されます。WSDLと URL テストウィンドウにブラウズされます SoapUIそして、各サービスに対するリクエストがリクエストウィンドウに表示されます。サービスレベルのテストケースに従ってデータを変更することで、各テストケースに対するリクエストが作成されます。

テストケース	リクエスト	期待される応答
注文を作成します。アイテム数 = 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 サイトを開きます。
• ユーザーは注文を行うためにサイトにアクセスする。
• ユーザーは有効な商品と数量を選択し、注文を保存します。
• 注文が正常に完了したことを示すメッセージが表示されるはずです。
• ユーザーはデータベースを開き、注文の詳細がウェブサイトに入力された内容と同じかどうかを確認する。

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

ビジネスフローとユースケースはユーザーインターフェース上で実行されます。複数のアイテムを含む注文を作成する例：

• ユーザーが Web サイトを開きます。
• ユーザーは注文を行うためにサイトにアクセスする。
• ユーザーは有効な商品と数量について問い合わせ、それらをカートに追加します。
• その他の有効な商品が有効な数量で追加され、注文が保存されます。新しい支払い方法で支払いが行われ、注文が確定します。
• 「注文が正常に完了しました」というメッセージが表示されます。
• テスターは、データに歪みが生じることなく、フロー全体が完了することを検証する必要があります。

よくあるご質問