サービス仮想化とは何なのでしょうか。サービス仮想化は、開発やテスト妨げるコンポーネントに簡単にアクセスできるようにするものです。この記事を読んで、サービス仮想化がどのように利用できるか知ってください。
サービス仮想化は、Parasoftのお客様のテスト戦略において重要なコンポーネントになりつつあり、それに伴って多くの質問が寄せられています。以下では、それらの質問にいくつかお答えしています。
サービス仮想化の定義
一言で言えば、 サービス仮想化は開発とテストを妨げるような制約のあるコンポーネントに簡単にアクセスできるようにします。多くの場合、問題なのは環境の制約です。完全なエンドツーエンドの機能性を実現するために、テスト対象アプリケーション（AUT）が依存するコンポーネントも必要となります。
サービス仮想化は、テスト対象アプリケーション（AUT）が依存するコンポーネント（サービス）をシミュレートし、実際の機能をエミュレートした挙動に切り替えることで、これらの制約を取り除くことができます。仮想化を適切に行うことで、実際のコンポーネントを利用しているかのようにシステムは動きます。
このように、正確にエミュレートしたテスト環境にいつでもアクセスできる状態にすることで、スケジュール上の制約を取り除くことができます。また、依存先システムが拡張中、利用不可、アクセス困難といった状態であっても、サービス仮想化によって速やかにアクセスを提供することで、プロセス上のボトルネックを取り除くこともできます。ウィキペディアの サービス仮想化 の記事で挙げられているとおり、依存先システムは以下の状態である場合があります。
- 未完成
- 拡張中
- サードパーティまたはパートナーによって管理されている
- 限られた負荷または不便な時間でしかテストに利用できない
- テスト環境でのプロビジョニングまたは構成が難しい
- さまざまなテストデータのセットアップなどを必要とする複数のチームによる同時アクセスが必要
- 負荷テストおよびパフォーマンステストの使用に制限がある、またはコストが高い
さらにウィキペディアの記事は、サービス仮想化について、次のように詳しく説明しています。
（サービス仮想化は）システム全体を仮想化するのではなく、依存先の挙動のうち開発およびテストタスクの実行に不可欠な特定の箇所だけを仮想化します。実際のサービスが完成して利用可能になるのを待たなくても、開発者またはテスターが必要とするものを入手できるよう、必要最小限のアプリケーションロジックを提供します。
たとえば、データベース全体を仮想化する（そして関連するすべてのテストデータ管理作業を行い、テストセッションごとにデータベースをセットアップする）代わりに、アプリケーションがどのようにデータベースと関わるのかをモニターし、関連するデータベースの挙動（SQLデータベースに渡されるクエリー、返される一連の結果など）をエミュレートします。
なぜサービス仮想化が重要なのか？
品質とスピードを両立させるには、信頼できる現実的なテスト環境に無制限にアクセスできることが不可欠です。完全なテスト環境には、テスト対象アプリケーション（AUT）とそのすべての依存先コンポーネント（API、サードパーティサービス、データベース、アプリケーション、その他のエンドポイントなど）が含まれることを認識するのが重要です。
サービス仮想化を利用すると、DevTestチームは必要な依存先システムコンポーネントをすべて含む完全なテスト環境にアクセスできるほか、ステージングテスト環境では不可能な方法でこれらの依存先コンポーネントの挙動を変更し、早期の段階から、より速く、完全にテストできます。また、デバッグやパフォーマンステストのためにアプリケーションのさまざまなレイヤーを分離することも可能ですが、これについては、今回は詳しく説明しません。
完全なテスト環境にアクセスする
今日のハイペースな反復開発サイクルでは、DevTestチームは以下の項目を実行するために、早期の段階から完全なテスト環境にアクセスする必要があります。
- ユーザーストーリーが完成したらすぐにその機能性を検証する
- ユーザーストーリーが完成したらすぐにその影響を検証する
- プロセスの初期段階からより包括的なテストを実行する
- 別のチームが依存先コンポーネントの実装または拡張を行っている場合でも、現在のイテレーションと並行して自チームがDevTestタスクを完了する
サービス仮想化によって、テスト環境にない、または制約がある依存コンポーネントへのアクセスが可能になります。これには、サードパーティのサービス、API、データベース、メインフレーム、ESB、その他の一般的なメッセージングプロトコルを使用して通信するコンポーネントが含まれます。以下のような依存コンポーネントは、サービス仮想化の有力な候補です。
- スケジュールの競合、アクセス料金、ライセンス、地政学的境界などの要因により、ある程度（またはそれ以上に）テストでアクセスするのが困難なコンポーネント
- ある程度（またはそれ以上に）テスト用に構成するのが困難なコンポーネント
たとえば、内部サービスはステージングテスト環境から簡単にアクセスでき、構成がシンプルです。一方、複雑なメッセージキューをステージングテスト環境で立ち上げ、テスト用に構成するのはそれより難しいでしょう。極端な例では、メインフレームやERPシステムの場合、DevTestチームからのアクセスに関してさまざまな制約があるほか、テスト用に構成できる範囲にも明確な制限があるでしょう。サービス仮想化を活用すると、テスト環境にオンデマンドでアクセスできます。そのため、アクセスの制約がなくなり、構成の繰り返しに伴うオーバーヘッドが軽減されます。
SOAtest/Virtualize 製品ページへ >
依存先コンポーネントの挙動を変更する
また、サービス仮想化により、依存先コンポーネントの挙動を制御できます。AUTの依存先コンポーネントに関連するネットワークまたはハードウェアの構成を変更するのは非常に困難です。また、本番環境よりもパフォーマンスが遅いステージングテスト環境に対処することもよくあります。
サービス仮想化を使用すると、依存先コンポーネントの応答をより詳細に制御できます。これにより、（フライトシミュレーターのように）はるかに広い範囲で依存先コンポーネントの挙動にオンデマンドでアクセスできます。その結果、リリース候補のアプリケーションに潜むリスクをより迅速かつ正確に評価できます。
たとえば、依存先コンポーネントの挙動をシミュレートすることで以下を実現できます。
- 依存先コンポーネントのパフォーマンスのバリエーションに対して、AUTがどのように応答するかを確認する。1つの依存先コンポーネントで著しい遅延が発生した場合でも、ユーザーはコアトランザクションを完了できるか。レスポンスが速いシナリオで同時実行性の問題が明らかになるか。
- テスト対象コンポーネントを切り離すことで、予期しない挙動を示した場合に、問題が依存先コンポーネントとAUTのどちらに起因するものなのかを把握する
- テスト環境全体をさまざまな状態に設定し、それらの条件下でのAUTのセキュリティと復旧力を検証する
依存先コンポーネントのデータを変更する
仮想サービスは、必ずしも実システムのデータで応答させる必要はありません。実際、仮想サービスから予期しないデータを返すことには多くの利点があります。仮想サービスはデータソースから分離されているため、さまざまなチームのニーズに合ったレスポンスデータを非常に柔軟に生成できます。たとえば、以下のような例が挙げられます。
- アプリケーションの不正なレスポンスやネガティブな挙動への防護を強化したい開発チームは、ネガティブな挙動を引き起こすサービスレスポンスを生成できる
- サービスが規定外のレスポンスをどのように処理するかを検証したいテストチームは、不正な文字を含むレスポンスを返すことができる
- ペイロードが大きなレスポンスに対する影響を把握したいパフォーマンスチームは、依存コンポーネントから通常よりも大きなレスポンスを返すことができる
このような状況でさまざまなサービスデータをシミュレートできるので、テストの柔軟性が大幅に高まります。
サービス仮想化の実用的な利点
もちろん、この記事ではサービス仮想化のほんの一部にしか触れていません。サービス仮想化の採用には多くの利点があります。サービス仮想化という最先端のテスト手法を採用している企業からは、欠陥の減少、テストカバレッジの改善、テスト実行率の向上、テストに費やす時間の劇的な短縮が報告されています。
（この記事は、開発元Parasoft社 Blog 「What is Service Virtualization?」2018年9月7日の翻訳記事です。）
Parasoft SOAtest/Virtualizeについて
>