The Rational Edge

Webサービスのテスト技法進化論

by Jason Bloomberg
Senior Analyst
ZapThink LLC

2002/11/19

---

　昨年から急速に関心を集め始め、メディアでもかなり大きく取り上げられてきたWebサービスだが、そのテスト情報となるとソースがほとんどない。Webサービスが従来のソフトウェアコンポーネントに、XMLインターフェイスを標準装備しただけというのであれば、（テスト情報がやたらと少ないという）説明の必要はほとんどなくなるだろう。既存の完成したテストツールやテクニックで十分だからだ。

　Webサービスの主な用途は、現段階では、企業内のシステム統合を簡略化し、コストを削減することにある。用途（コンポーネントをSOAPインターフェイスでラッピングし、XMLベースのRPCメッセージをほかのコンポーネントと交換する）がこれほど単純明快ならば、既存のテストツールやテクニックを活用しても問題はほとんど出てこないのである。　

　しかし、筆者がThe Rational Edge（*）で書いたWebサービス関連の記事を読んでもらえば、Webサービスが既存のコンポーネントプログラミングテクニックを簡略化するよりも数段高いポテンシャルを秘めていることが分かるだろう。ここ数年、Webサービスは分散コンピューティングの状況を根本的に変えようとしている。そして、この新しい状況から、Webサービスの開発者や顧客が理解していかなくてはならない新しいテストシナリオや問題が示されていくことになる。

Webサービステストの2つの局面

　現在、そして今後Webサービステストが直面する問題を理解するには、現在のテストテクニックの範囲と、Webサービスへの適用方法を理解することが重要である。つまり、これがWebサービステストの第1の局面である。Webサービステストの第2の局面はもっと先に実施されることになる。つまり、Webサービスを単純に適用する現状から、ダイナミックに記述され、認識される多数の「サービス」が含まれた、「サービス指向」の環境へと企業が移行する中で実施されるだろう。

　Webサービステストのこれら2つの局面と企業によるWebサービスの採用を詳細に説明する今後数年間のロードマップを組み合わせれば、Webサービステストがどの方向に向かって発展していくべきかが明確に見えてくる。

■第1の局面

　基本的に、Webサービスとは自らの機能をSOAP（Simple Object Access Protocol）インターフェイス経由で公開するソフトウェアコンポーネントを指す。そして、WSDL（Web Services Description Language）メタデータファイルが、ポートタイプやバインディングといったWebサービスのインターフェイス関連情報を提供してくれる。従って、この基本レベルにおけるWebサービステストは、適切なSOAPメッセージをWebサービスと交換するだけの簡単な作業にすぎない。このようなメッセージはテストツールに「ハードウェア的に」組み込んでおくことも可能だし、サービスのテストに必要なSOAPメッセージをダイナミックに作成するために、テストツールがWSDLファイルにアクセスすることもできる。テストのこのような基本的ニーズに対応するため、テスターは次のような既存の各種テストテクニックを利用することができる。

• 「ブラックボックス」機能テスト：コンポーネントの機能がそのコンポーネントの機能仕様と一致するかどうかを検証する。「ブラックボックス」という言葉は、この種のテストがコンポーネントの入出力だけに関心を寄せていることからきている
  
  
• 「ホワイトボックス」構造テスト：コンポーネントの品質を検証するために、そのコンポーネント内部のプログラミングコードの構造や機構を分析する。ホワイトボックステストは「コードプロファイリング」と呼ばれることも多い
  
  
• 回帰テスト：ブラックボックステストの一種で、コンポーネントの機能をその前のバージョンと比較し、そのコンポーネントに対して加えた変更がこれまで動作していた機能を破壊していないかどうかを検証する
  
  
• 負荷テスト：キャパシティテスト、ストレステスト、そしてチューニングなどを含む一連のテストテクニック。必要な負荷をかけてコンポーネントが適切に動作するかどうかを検証するため、コンポーネントに対して一定数のユーザー（もしくは一般にいう大量の入力トラフィック）のエミュレーションを実行する
  
  
• ユニットテスト：一般的にはデベロッパの日常業務の一環として、関連するほかのシステムと切り分けて個々のコンポーネントをテストする
  　
  
• システムテスト：コンポーネントのシステムをテストして、システム全体が用意された仕様に適合するかどうかを確認する。統合テストはシステムテストの一部であり、こちらは特にメッセージ交換やコンポーネント間のファンクションコールに焦点を合わせる
  

■第2の局面

　企業が疎結合の「サービス指向」アーキテクチャ（SOA）を構築すべくWebサービスのダイナミックディスカバリや呼び出し機能を活用すると、前述したWebサービステストのごく簡単なアプローチではカバーできないテスト関連の問題が多数発生してくる。これらの問題は、WebサービスやSOAの次のような機能が関連するWebサービステストの第2の局面へとつながっていく。

• SOAPメッセージのテスト：WebサービスとのインターフェイスとしてSOAPを使用するだけでなく、メッセージ自体のフォーマットをテストすることも含まれる
  
  
• WSDLファイルのテストとテスト計画作成のためのWSDLファイルの使用：Webサービスは、オープン標準に従ったインターフェイスに関するメタデータを含むファイルを持つ点で特殊なものだ。テストツールはこれらのWSDLファイルを使ってブラックボックステスト計画を自動的に作成する。WSDLファイルはホワイトボックステストでも役に立つ
  
  
• ユーザー／開発者エミュレーション：テストツールがコンポーネントに送信して結果を分析するテストメッセージを生成するときは、基本的にはそのコンポーネントのクライアントがエミュレートされている。また、そのコンポーネントがWebサービスの場合、テストツールはサービスをテストすべくサービスのユーザーをエミュレートする。しかし、WebサービスではユーザーがSOAPメッセージの送受信も行う。従って、テストツールはユーザーをテストするためにWebサービスプロバイダ（すなわちサービス自身）もエミュレートすることになる
  
  
• SOAの公開／検索／バインド機能のテスト：SOAの基本特性は「公開、検索、バインド」の3つだ。Webサービスプロバイダはまず、サービスのWSDLファイルをUDDIレジストリ内で公開し、ユーザーはそこで検索を行う。そして、ユーザーがそのレジストリ内のWSDLファイルをベースにしてサービスにバインドするのだ。Webサービステストツールはこの3要素をそれぞれテストしてくれる
  
  
• Webサービスの非同期通知／アラート機能およびその同期RPC機能のテスト：今日では、Webサービスが利用されるケースとして、簡易リモートプロシージャコール（RPC）が多い。RPCフォーマットの1つにSOAPを利用するのは強力な手法だが、これでは仕様の機能をフルに活用できない。この分かりやすい同期式の手法に加え、SOAPは通知（ユーザーからWebサービスプロバイダへ）やアラート（Webサービスプロバイダからユーザーへ）などの非同期メッセージもサポートしている。Webサービステストツールは全種類のSOAPメッセージをテストする必要があるのだ
  
  
• SOAPの仲介機能テスト：SOAP仕様ではメッセージの仲介手段（アクターとも呼ばれる）について規定している。一般的に、特殊なSOAPメッセージは決まった受け手に送られることになるが、SOAPメッセージヘッダで指定された指示に基づいて処理を行う1つもしくは複数のアクターを持つ場合もある。Webサービステストツールはこれらの仲介手段が適切に機能するかどうかを検証するだけでなく、その仲介手段がセキュリティホールとならないよう検証しなくてはならない
  
  
• Webサービス・オーケストレーションテスト：企業各社がWebサービス採用に向けて力を入れていくと、多数の細粒度Webサービスを、大きい粗粒度Webサービスへとまとめるようになる。このような編成作業としては、再帰的なもの（つまり、複数のWebサービスによって構成されるWebサービス）や、シーケンシャルなもの（ビジネスプロセスに整理される一連のWebサービス）、あるいはこれら2つを何らかの形で組み合わせたものが考えられる。Webサービスのこのような組み合わせは、BtoBトランザクションを実現するものなど、一般的には複数の企業が関与することになる
  　
  
• サービスレベル保証（SLA）とサービス品質（QoS）の監視：一部のWebサービステストツールは、デザインからランタイムへと移行する際にWebサービスが（個々および組み合わせで）本来の動作をするかどうか検証する
  　
  
• Webサービスのバージョンおよび「アジャイルアーキテクチャ」テスト：密接に結合されたコンポーネント指向の世界からWebサービスによって実現した「サービス指向」の疎結合環境へ企業のIT環境が移行する中、企業はソフトウェア開発のライフサイクルの一部としてではなく、臨機応変な形で個々のWebサービスをアップグレードできるようになっていく。アップグレードをこのように臨機応変に成功させるには、企業が個々のWebサービスの新バージョンを本番環境、もしくは本番環境に可能な限り近づけた環境でテストを実施できるテストツールを用意しておく必要がある
  

　このWebサービステストにおける第2の局面の一端は、Webサービスの既存の利用方法（すなわちRPC用のSOAPメッセージ）にしっかりと根ざしている。この局面のもう一端は数年先で、多数の疎結合サービスによって描写される変形IT環境にある。点と点を結ぶことはWebサービス採用ロードマップの重要な一部である。

Webサービスの採用ロードマップ

　Webサービステストの2つの局面は、企業がWebサービスをより広範に採用していくに当たってWebサービステストのベンダ各社がインプリメントすべき多数の機能を網羅している。以下で述べるWebサービス採用ロードマップは、ベンダ各社がどの機能をいつインプリメントすべきか理解するのを助けてくれるだろう。このロードマップには3つのフェイズがある。

■フェイズ1

　Webサービスの採用へと向かう最初のフェイズ（われわれがいまいるフェイズ）は社内を中心に考えられている。企業は主に社内の統合を簡略化し、そのコストを削減するためにWebサービスを使っている。Webサービスを使ってファイアウォールの外側とコミュニケーションを取ろうと模索する企業も中にはあるが、これらの事例はほとんどが名高いIT部門を抱える信頼性の高いビジネスパートナーとの試験プロジェクトとなっている。最初のフェイズでWebサービスの採用を遅らせる主な障害は、セキュリティ、Webサービスの管理、そしてトランザクションの3つだ。また、企業がこのフェイズで主に使うWebサービスの呼び出しスタイルはスタティックなWebサービスへのスタティックなバインディングとなっている。

　（実用的なすべての目的において）WebサービスがSOAPインターフェイスを持つソフトウェアコンポーネントとなっているのが、Webサービス採用の最初のフェイズだ。Webサービステストツールは、サポートする一連のインターフェイスにXMLサポートを付加するだけでブラックボックステストを実施することができる。WSDLファイルがWebサービス内部の仕組みに関する情報をある程度提供してくれるため、テストツールはこのWSDLファイルを使うことで、さまざまな内部コードストラクチャを動かす自動テストプランを作成することができる。

　フェイズ1におけるWebサービス負荷テストの実施も比較的分かりやすい。Webサービスの負荷テストと、Webページなどの負荷テストでは、Webサービスのテストに関してはエミュレートするユーザーインターフェイスが存在しない点が大きな違いになる。その結果、Webサービスをテストするには、ブラウザの動作を下位レベル（すなわちHTTP）で模倣するツールの方が、本物もしくはエミュレートされたブラウザとユーザーがやりとりをするところまで模倣する負荷テストツールよりも適していることになる。サービスとメッセージを交換することになるユーザーを正確にエミュレートすることがWebサービス負荷テストツールの目的なのだ。

　フェイズ1では、Webサービスに確実にユーザーが存在するため、これらのユーザーをテストすることが重要になる。一般的に、WebサービステストツールがWebサービスをエミュレートするのは、このサービスにアクセスするユーザーをテストするためだ。企業がWebサービスを含むシステムテストを実施するには、Webサービスプロバイダとユーザーの両方をテストするしか方法がない。

■フェイズ2

　新製品やサービスが市場に投入され、Webサービスのセキュリティ、管理、そしてトランザクションに関連する問題の多くを解決するようになると、企業は一段と自由で柔軟な形で他社（カスタマ、サプライヤ、そしてパートナー）とWebサービスメッセージを交換できるようになっていく。UDDI仕様はさらに完成され、UDDIインプリメンテーションのほか、Webサービスレジストリプロトコルも多数登場してくる可能性がある。これらのレジストリは過去に取引の実績がなかった企業同士の取引関係実現にとって特に有効なものとはならないが、企業や実績のあるビジネスパートナーのグループは、管理された環境におけるWebサービスのダイナミックディスカバリを成功させる要因としてサービス・レジストリを相当重要視するようになるだろう。それでもサービス自体は一般的にスタティックなものになるだろうが、ユーザーはこれらをダイナミックに検索およびバインドすることになる。フェイズ2におけるWebサービス採用拡大で大きな障害となるのは、オーケストレーション、ビジネスプロセスの自動化、そしてWebサービスの請求および計量処理だ。

　「サービス指向」のアーキテクチャを採用するというこのフェイズを特徴づけるのがWebサービスのダイナミックな「公開、検索、バインド」機能だ。これらの機能をテストすることは、（厳密には個々のWebサービスに対するブラックボックス機能テストの一部を指していっているわけではないが）コンポーネント指向の観点とは逆に、「サービス指向」の観点から見てWebサービスの機能テストでますます重要な位置を占めるようになる。適切なWebサービスを検索するだけでなく、バインドもしなければならないことから、ユーザーをテストすることも一段と複雑な作業になるだろう。

　フェイズ2におけるWebサービスの負荷テスト実施もフェイズ1より確実に複雑になっていくだろう。公開と検索の操作だけでなく、レジストリの機能が要求されるトラフィックの負荷をサポートしなくてはならない点がそれを最も明確に示す理由だ。だが、スケーラビリティに対する「サービス指向」のアプローチが本質的にはレジストリの動きによって決まるため、フェイズ2のWebサービス負荷テストではさらに微妙な違いも出てくることだろう。「サービス指向」の設計がUDDIレジストリを使ってネットワーク上の重複したリソースを整理し、確認するため、これらのアーキテクチャに対する負荷テストは、そのレジストリのコンフィグレーションが適切に行われているかどうかにすべて依存するようになる。

　設計の時点ではテストされるシステムが定義されないため、フェイズ2においてはシステムテストが最も複雑になると思われる。その代わり、やり方としては設計の時点で個々のWebサービスを定義して、レジストリに公開するようなことが考えられる。こうすれば、ユーザーがこれらのリソースを探し出し、ランタイム時にこれらにバインドするようになる。従って、システムテストは「サービス指向」のアーキテクチャが持つ、このダイナミックな性質を考慮する必要がある。

■フェイズ3

　「サービス指向」のアーキテクチャが成熟し、Webサービスのオーケストレーションやビジネスプロセス自動化ツールが普及すれば、Webサービスの基本である呼び出しのスタイルがJIT（Just-in-time）統合へと移行していくようになる。JITの統合では、Webサービス自体がランタイム時にダイナミックに記述されるようになる。フェイズ3では、ユーザーはフェイズ2のようにWebサービスをダイナミックに発見するが、今度はこれらのサービスが毎回異なってくる可能性がある。そして、対応するWSDLファイル中にあるこれらのサービス記述が、ランタイム時のサービスへのダイナミックなバインドに必要なすべての情報をユーザーに提供するようになる。

　さらに、これまで例外だった複雑なWebサービスのオーケストレーションが普通のことになるため、「ユーザー」と「Webサービスプロバイダ」の概念は一段とあいまいなものになる。企業は粗粒度Webサービス（「製品カタログ」サービスなど）を自社の顧客、サプライヤ、およびパートナーに公開するようになり、これらのWebサービスは実際には細粒度Webサービス（「製品リスト」「現在の在庫」「希望価格」など）を大きくダイナミックにまとめたものになるが、これら自身もさらに細粒度の高いWebサービスによって構成されている場合がある。さらに、これらのコンポーネントWebサービスには他社が提供するサービス（「クレジット承認」など）がそれぞれ含まれている場合もある。

　このように完全な状態で実現された「サービス指向」の環境においては、設計時と実行時の区別もあいまいになる。個々のサービスがダイナミックに記述されて公開されることから、ITマネージャはこれらを瞬時にアップグレードできるようになる。そして企業も、もはや多くの時間とコストをかけたライフサイクルに沿ってアップグレードを発表する必要がなくなる。デベロッパはその代わりに、個々のサービスを必要に応じて構築、テスト、そして発売するようになる。　

　明らかに、シーケンシャルウォーターフォールソフトウェア開発方法論の冗長なテストプロセス（最初にデザインしてから開発を進め、次にテストを実施して、それから発売する）は、フェイズ3で実現される「サービス指向」の環境にはまったくそぐわないものとなってしまう。その代わりに、ソフトウェア開発グループは、開発やテストでアジャイルと呼ばれるようになったアプローチを採用せざるを得なくなってしまう。顧客と協力し、必要なことだけに取り組み、テストを準備し、チームでコーディングを行い、テストを成功させたら、完成までこれを繰り返すのである。コーディングを始める前にテストを行うことは「エクストリーム」手法から、分散コンピューティングのダイナミックな特性に対処するための唯一の手法へと変化していくだろう。

　実際、テストに対するアジャイルアプローチはフェイズ3で理にかなう唯一のアプローチのように思える。システムが設置されてからでなくては実施できないようでは、システムを構成する個々のWebサービスを事前に決定できないのだから、そのシステムテストが包括的かつ完全になることは決してない。そうではなく、テストは新しい要求が定義されるたびに要求の収集を自動化することから開始されるものだ。テストと、その結果誕生するコードは、コードだけでなくテストも同時に完成するように（そしてコードがテストにパスするように）発展を繰り返していく。もし個々のWebサービスごとに対応する自動化テストがある場合、Webサービスのオーケストレーションにはテストのオーケストレーション作業も絡んでくる。やはり、通常のユーザー要求は粗粒度が高いのだ。開発チームがユーザーと協力して粗粒度要求を定義し、それに対応する粗粒度テストを用意する必要がある。粗粒度テストの用意に当たって、開発チームが使用するテストツールは、調和のとれた粗粒度Webサービスとの組み合わせによって構成できるような、既存のWebサービスすべてに適したテストを組み込めるようでなくてはならない。

今後の方向

　筆者がThe Rational Edgeで書いてきた記事を読んでもらえば、既存のIT環境をベースにして、理にかなう手順を追ったアプローチが採用される未来を推定したことが分かってもらえると思う。ニーズを満たすものでなければユーザーはソフトウェアを購入しない。ベンダも利益を生まないソフトウェアは書かない。このような、最も重要な経済の現状を基本として、その上にすべての予想が立てられている。

　では、われわれはフェイズ3の根底にあるダイナミックな「サービス指向」の環境に到達できるだろうか？ まあ、それには多少の時間がかかる（ひょっとしたら2005年以降にずれ込むかもしれない）し、多少の困難に遭遇するかもしれないが、これにはJIT統合へと向かうユーザーとベンダの両コミュニティにとって明確な経済的メリットがある。そして、金もうけのチャンスがあれば、だれかが確実に行動を起こすのだ。

　今日、経済の力がソフトウェアテストの世界を変えつつある。最も保守的な企業さえもが、ウォーターフォール方法論がもはや費用対効果の高いソフトウェア開発アプローチではないことを認識し、コストとリスクが低いというだけの理由から反復手法へと移行しつつある。同時に、反復手法はソフトウェアの開発に固有のコストやリスクの削減方法としてもますます軽快（アジャイル）になりつつある。これらの変化（ウォーターフォールから反復、そして反復からアジャイルへ）は、テストに対するアプローチの根本的な違いに起因している。　

　ソフトウェア開発プロセスの成熟の動きが、「疎結合」「オープン環境」「標準ベース」「分散コンピューティング」というキーワードを含むシステム構築のトレンドと一致するのは偶然ではない。一枚岩的なアプリケーション開発が、コンポーネント指向の開発に取って代わられて初めて反復手法が現実的なものとなったように、今日のアジャイル手法（正直なところいまだに主流ではないが）も、完全に実現された「サービス指向」の環境におけるソフトウェア制作業務にとっては費用対効果が高く、必然的に唯一の手法へとなっていくことだろう。

---

（*）　The Rational Edgeの2001年9月号、2002年3月号、2002年4月号、2002年5月号参照

2001年9月号
Web Services: A New Paradigm for Distributed Computing

2002年3月号
Web Services: Opening Soon for Business

2002年4月号
Web Services and a New Approach to Software Development

2002年5月号
Q&A with Industry Analysts
How Are e-Business Trends Impacting Developers and Development Teams?

本記事は「The Rational Edge」に掲載された「Testing Web Services Today and Tomorrow 」をアットマーク・アイティが翻訳したものです。

IT Architect 連載記事一覧