The Rational Edge

分散コンピューティング時代のテスト手法

Jeffrey Bocarsly
Division Manager, Automated Functional Testing
RTTS
Jonathan Harris
Division Manager, Scalability Testing
RTTS
Bill Hayduk
Director, Professional Services
RTTS

2002/7/20

---

　テストの業界標準はクライアント／サーバアーキテクチャがそのつど直面する品質の問題に沿って進化し続けてきた。つい最近までは、フロントエンドシステムの機能テストはクライアントPCのみで、バックエンドシステムのスケーラビリティ調査やパフォーマンステストはサーバのみで行うという形態が主流だった。この「分業体制」は、旧来のクライアント／サーバアーキテクチャ（二層構造）が現行のマルチ階層／分散環境アーキテクチャに比べてシンプルなことから生まれたものだった。標準のクライアント／サーバ設定では、クライアント側かデータベース側のいずれかにしか問題がなかったからある。

　現在のコンピューティング環境は非常に複雑だ。旧式のシステム、自社開発のシステム、サードパーティの製品、標準化されたコンポーネントやコード群といった多種多様な環境が混在している（図1）。Webの登場以来、アーキテクチャは複雑になり、バックエンドにある1つもしくは複数のデータベースとプレゼンテーション層の中間にコンテンツ層が置かれることも多い。コンテンツ層がプレゼンテーション層でまとめられた複数のサービスからコンテンツを配信したり、クライアント／サーバシステムのフロントエンドに業務ロジックを持つ場合もある。

　 コンピューティング環境が複雑になったことで、新旧両方の技術成果を統合する問題のほか、ソフトウェアの調査、分析、ローカライゼーションやシステムに関する問題（機能およびスケーラビリティ／パフォーマンスの問題を含む）が、ソフトウェアシステムの開発と配布において大きな課題となる場合がある。さらに、標準データ転送フォーマットとしてXML／SOAPが受け入れられたことで、.NETおよびJ2EEの両開発プラットフォーム上ではXMLデータの互換性の問題が重要性を増してきた。簡単にいえば、既存のアーキテクチャやコンピューティング環境が複雑化したため、従来のクライアント／サーバ指向のテストスキーマが時代遅れになってしまったのである。

図1　現在の典型的なマルチ階層アーキテクチャ

品質管理の全体戦略

　ソフトウェアの開発と導入を成功させるには新しく積極的な品質改善戦略が必要である。最も有力な戦略は、コンポーネントのテストと環境全体のテストを組み合わせたものだ。この戦略は、データの整合性を検証するための機能テストと、さまざまなシステム負荷において満足できるレスポンスタイムを保証するためのスケーラビリティ／パフォーマンステストを、コンポーネントおよびシステムの両レベルで実施する必要がある。並行に進められるこれらの分析は、アーキテクチャの長所・短所の見極めや、パフォーマンスとスケーラビリティが影響を及ぼすアーキテクチャ関連の問題解決に必要なコンポーネントの特定に役立つ。

　 また、最近ではデータをさまざまな場所から持ってくるようになったため、「完全データ整合性検証」が重要になりつつある。処理中に発生するデータの機能変換を含むデータの整合性（コンポーネント内とコンポーネントを越えたものの両方）を評価することで、テスターは潜在的な不具合を突き止め、システムの統合作業と不具合の分離を、標準開発プロセスの一環として行うことができる。包括アーキテクチャテスト（End-to-End Architecture Testing）は、コンピューティング環境のアクセスポイントすべてをテストする概念を含んでおり、機能テストとパフォーマンステストをコンポーネントとシステムの両レベルで組み合わせているテスト形態である（図2）。

　包括アーキテクチャテストは、ホワイトボックスとブラックボックスの両テストの長所を組み合わせた「グレイボックス」的アプローチを採用している。ホワイトボックステストでは、テスターが基盤となるシステムコンポーネントにアクセスすることが可能である。それゆえかなり詳細で有用な結果が得られるものの、多くの統合／システムパフォーマンス問題を検知することはできない。一方、ブラックボックステストではシステム内部の仕組みをほとんどもしくはまったく知る必要がなく、ユーザーが適切な結果を遅延なく確実に取得できるようにするなど、エンドユーザーの使い勝手を重視している。一般的に、ブラックボックステストは問題の原因を特定することができない。どのコードが実行されたのか、それが効率的に動作しているのか、メモリリークなどの問題を起こさないか、といったことを確認することができない。包括アーキテクチャテストは、ホワイトボックステストとブラックボックステストの両テクニックを組み合わせることで、それぞれの長所を活用しながらそれぞれの短所を排除するのである。

図2　包括アーキテクチャテストはすべてのアクセスポイントで機能／パフォーマンステストを実施する

　パフォーマンスおよびスケーラビリティのテストでは、ハードウェア、オペレーティングシステム、データベース、およびネットワークなどのアクセスポイントを検証する。一方、機能テストでは、フロントエンドのクライアント、中間層、コンテンツのソース、そしてバックエンドのデータベースといったアクセスポイントを検証する。アーキテクチャという用語は環境の中のすべてのコンポーネントが同じ環境の中のほかのコンポーネントと対話する方法や、ユーザーがこれらすべてのコンポーネントと対話する方法を決定している。個々のコンポーネントの長所や短所は、これらをまとめる特定のアーキテクチャによって決まってくる。包括アーキテクチャテストのニーズが生まれるのは、実際、個々のコンポーネントとアーキテクチャがどのように対応するかが明確になっていないためだ。

　包括アーキテクチャテストを効果的にインプリメントするため、RTTS（筆者の所属する組織）は優れたリスクベースのテスト自動化方法論を作り出した。この「Test Automation Process」（TAP：テスト自動化プロセス）は長年にわたって好結果を収めてきたテストインプリメンテーションを基盤としており、自動化された最高のテストツールを活用する。これはテストを繰り返す形のアプローチを取り、明確に分類された以下の5つのフェイズを持つ。

• プロジェクトの評価
  
• テスト計画の作成もしくはインプリメンテーション
  
• テスト事例の開発
  
• テストの自動化、実行、およびトラッキング
  
• テスト結果の評価
  

　包括アーキテクチャテストで要求される個々の機能／パフォーマンステストは、「テストの自動化、実行、およびトラッキング」のフェイズで実施される。図3に示すように、このフェイズは繰り返されるようになっており、プロセスの反復に伴って関連テストが絞り込まれていく。

図3　包括アーキテクチャテストのためのRTTS Test Automation Process（TAP）

コンポーネントレベルテスト

　システムに組み込む前に、コンポーネントの開発を終わらせておくのは当然過ぎるほど当然のことだろう。コンポーネントはテストのために前もって利用できるため、TAPにおける包括アーキテクチャテストはコンポーネントテストから始まる。コンポーネントテストでは、環境の構築が進む中で個々のコンポーネントにとって適切なテストが実施される。コンポーネントレベルでの機能およびスケーラビリティのテストは、環境全体の組み立て前と途中で「ウイークリンク」（問題の発生源となりそうな部分）を特定するのに役立つ。

■コンポーネントレベルの機能テスト

　このレベルで適用する機能テストは、各コンポーネントが実行するトランザクションを検証する。これには、そのコンポーネントやシステムが実行しなくてはならないあらゆるデータ変換処理のほか、そのコンポーネントが処理するあらゆるトランザクションに適用される業務ロジックの検証も含まれる。インフラテストは、アプリケーションの機能が開発されていく中で、その環境のインフラを通じたデータの流れを検証、定量化し、同時に機能性とパフォーマンスのテストも行う。システムのコンポーネント間でデータの受け渡しが開始される際には、データの整合性を検証する必要がある。例えば、XML TestingはXMLデータのコンテンツをトランザクションごとに検証し、必要に応じて正式なXML構造（メタデータ構造）を検証する。

　コンポーネントテストでは、「RationalRobot」などの自動化された拡張テストツールを使う。これにより、GUIを持たないコンポーネントに対してGUIテストや機能テストを実施する際に必要となる時間と労力が大幅に削減される。Rational Robotのスクリプティング言語は外部COM（Component Object Model）DLLの呼び出しをサポートしており、GUIを持たないオブジェクトを直接もしくはCOMテストツールを使ってテストするのに理想的なツールとなっている。また、「Rational SuiteTestStudio」や「RationalTeamTest」に搭載される新しいWebおよびJava用テスト機能は、J2EEアーキテクチャのテストと、Javaを使ったテストスクリプトの作成や記録のために新たな機能を提供してくれる。

■コンポーネントレベルのスケーラビリティ／パフォーマンステスト

　これらの機能テストと並行して行うスケーラビリティテストは、環境内の各コンポーネントを試験運用し、トランザクション（もしくは処理量）の限界を判断する。ビジネス関連のトランザクションを作成するために十分なアプリケーション機能がそろったら、トランザクション調査テストを利用して、消費するネットワーク帯域幅やバックエンドのシステム上におけるCPU／メモリ利用率など、ビジネストランザクションが与える影響のレベルを判断する。マルチユーザーテストとともにこのコンセプトを拡大したリソーステストは、アプリケーションやサブシステム、モジュールの総使用量を判断するために実施する。そして最後に、コンフィグレーションテストを実施する。最大限のパフォーマンスを実現するために、ハードウェア、オペレーティングシステム、ソフトウェア、ネットワーク、データベースなどのコンフィグレーションに対して必要な変更を特定することができる。機能テストと同じように、Rational Suite TestStudioやRational TeamTestなどが持つ効果的な自動化ツールがスケーラビリティおよびパフォーマンスのテストを大幅に簡略化してくれる。一連のテストを効率的に行うためには、マルチユーザーテストを作成してスケジューリングし、実施する機能や、リソース、トランザクション調査、コンフィグレーションの各テストのリソース利用率を監視する機能が絶対不可欠となる。

システムレベルテスト

　システムが完成したら環境全体のテストを開始する。包括アーキテクチャテストでは、ここでも機能と環境全体のパフォーマンス／スケーラビリティの両方の確認が必須となる。

■システムレベルの機能テスト

　最初に検討しなくてはならないものの1つが統合の問題だ。統合テストは、データの観点からシステムを統合するか否かといった広範囲に及ぶ問題に取り組むものだ。つまり、「相互に対話をしなくてはならないハードウェアとソフトウェアの両コンポーネントが、適切にコミュニケーションを取っているのかどうか？ もしそうならば、これらの間で送受信されるデータは正しいものだろうか？」という疑問に対処する。可能であれば、データのアクセスや検証はシステムコンポーネント間で行われる送受信の中間の段階で行う。データが一時的なデータベーステーブルに書き込まれたときや、送信先のコンポーネントで処理される前にメッセージキューの中でデータにアクセスできるときなどに行う。各コンポーネントの境界部分でデータへのアクセスを可能にすることで、データの整合性検証やデータ関連問題の調査の際に重要な要因が加わることになる。データの破損が2カ所のデータ転送ポイント間に絞り込めるような場合は、不具合のあるコンポーネントがこれらのポイントの間で突き止められる。

■システムレベルのスケーラビリティ／パフォーマンステスト

　環境のスケーラビリティやパフォーマンスに関する以下のような疑問に対しては、テストを用意することで回答を示すことができる。

• システムが満足できるレスポンスタイムを維持できる最大同時アクセスユーザー数は何人か？
  
  
• アーキテクチャが設計どおりに機能するだろうか？
  
  
• 新しいアプリケーションを追加したり、現在使用中のものをアップデートしたらどうなるか？
  
  
• 立ち上げ時に予想される数のユーザーをサポートするには環境をどのように設定すればよいだろうか？ 6カ月スパンで考えるのか？ それとも1年か？
  
  
• 機能が完全にそろっていないが設計は信頼できるものか？
  

　これらの疑問に対する回答は、スケーラビリティ／負荷テスト、パフォーマンステスト、コンフィグレーションテスト、並行テスト、ストレス／ボリュームテスト、信頼性テスト、およびフェイルオーバーテストなど、幅広いテストテクニックによって得ることができる。

　システム容量に関しては、一般的にはスケーラビリティ／負荷テストから環境全体のテストを開始する。このようなテストでは、最大レスポンスタイムなどのパフォーマンス要求を満たせなくなるか、特定のリソースが飽和状態になるまで対象となる環境に負荷をかけていく。これらのテストはトランザクションの限界やユーザー数の上限を判断するよう設計されている。通常はパフォーマンスを最適化するためにほかのテストと組み合わされる。スケーラビリティ／負荷テストに関連し、特定の業務シナリオをテストすることで設定された負荷や各種トランザクションの要求を環境が満たせるかどうかの判断には、パフォーマンステストも利用される（図4）。

　システムレベルのコンフィグレーションテストは、コンポーネントレベルのコンフィグレーションテストを並行に実施することで、特定のハードウェアやソフトウェアの設定に関するトレードオフ情報のほか、リソースを効果的に割り当てるのに必要な測定基準などの情報を提供してくれる。

図4　パフォーマンステスト：特定のユーザー数に達したときにシステムは要求どおりのパフォーマンスを発揮できるだろうか？

　並行テスト（図5）は複数のユーザーが同じアプリケーションコード、モジュール、もしくはデータベースレコードに同時にアクセスしたときの影響を調査する。そして、ロック／デッドロックのレベルや、システム内でのシングルスレッドコードやロッキングセマフォの利用率を明らかにし、評価する。並行テストは技術的には機能テストの一種に分類することができるが、システムの稼働に複数のユーザーもしくは仮想ユーザーが必要なため、スケーラビリティ／負荷テストに分類される場合が多い。

図5　デッドロックなどの並行アクセスに関する問題を明らかにする並行テスト

　ストレステスト（図6）は、対象となるシステムや環境を飽和点（CPUやメモリなどのリソースが枯渇した状態）で試し、動作が変化するかどうか、そしてシステム、アプリケーション、もしくはデータにとって有害な状況にならないかどうかを判断する。ボリュームテストはストレステストやスケーラビリティ／負荷テストと関連があり、完成したシステムが処理できるトランザクションの量を判断するために実施する。ストレステスト、ボリュームテストは、一時的な（あるいは持続的な）データの大容量処理時に、メモリリークやキューのオーバーランといった障害を起こすことなく耐えられる環境の「障害許容力」をテストするために実施する。

図6　利用率が高いときの影響を判断するストレステスト

　長期にわたって環境を稼働させることで発生すると予測できる問題の発見に向けては、75〜90％の持続利用率で環境を試す長期信頼性テストを実施する。

　フェイルオーバーテスト（図7）は、冗長性や負荷バランシングを備えた環境において、机上で用意したフェイルオーバー手順を分析し、フェイルオーバープロセス全体とエンドユーザーに対する影響をテストし、測定する。フェイルオーバーテストは、基本的に「ユーザーは特定のコンポーネントが障害を起こしても最小限の中断で処理を継続できるのだろうか？」という疑問に答えてくれるものだ。

図7　フェイルオーバーテスト：コンポーネント「X」が障害を起こしたらどうなるのだろうか？

　そして最後に、環境の中にサードパーティ製のソフトウェアが導入されていたり、外部ソースやホスティングベンダからデータをフィードしている場合は、エンドユーザーのレスポンスタイムを保証し、送受信データストリームが確実に契約内容の範囲内であるようにするため、SLA（Service Level Agreement）テストを実施したい。典型的な契約では、あらかじめ決められた時間内での指定された処理量を指定された最大レスポンスタイムで保証している。

　外部ソースのデータもしくはソフトウェアを利用する場合、問題が発生したときに、早急に是正処置を取り、エンドユーザーへの影響を最小限に抑えられるよう、これらのソースを常時監視することが望ましい。

　Rational Suite TestStudioやRational TeamTestのようなツールは、コンポーネントレベルでのスケーラビリティテストと同様、高度なマルチユーザーテスト機能を提供しており、前述のスケーラビリティテスト、パフォーマンステストのすべてとはいかないまでも、多くを効果的に実施することができる。

実例

　実例を示すことが包括アーキテクチャテストを説明するのに最適な方法だと思う。そこで以下のようなシナリオを考えていただきたい。

　あるネット小売業者が、4つのWebサービスをコンテンツ層に実装したWeb書店を構築した。サービスの1つ目は、書名、宣伝文、著者を表示するカタログを提供する。2つ目のサービスは全商品の現在の在庫状況を示す。3つ目のサービスは、価格サーバである。購入者の居住国や地域に応じた価格、送料、消費税の情報を提供し、購入手続きを処理する。そして、最後のサービスはユーザーのプロファイルと購入履歴を保持する。

　プレゼンテーション層はユーザーインターフェイスから入力されたリクエストをXMLに変換し、コンテンツサーバに送信する。そして、応答XMLがプレゼンテーション層によってHTMLに変換され、ユーザーのセッションに送信される。また、各コンテンツ層のサービスは必要に応じてほかのサービスをアップデートする。例えば価格サービスは、ユーザーの購入履歴の変化に応じて、プロファイルサービスをアップデートしなくてはならない（図8）。

図8　典型的なネット小売業者アプリケーションのアクセスポイント

　先に概要を示したシステムの包括アーキテクチャテスト戦略は、機能、スケーラビリティ／負荷テストをコンテンツ層のシステムに対して別々に実施することから始まる。XMLのリクエストは各コンテンツサービスに送信され、応答XMLドキュメントがキャプチャされ、データコンテンツあるいはレスポンスタイムが評価される。これらの各サービスはシステムに統合される。機能、スケーラビリティ／負荷の両テストは、トランザクションをWebサーバに送信し、完成システム上で実施される。トランザクションは機能テスト（SQLクエリ使用）とスケーラビリティ／負荷テストの両方でサイトのインフラ全体を通じて検証することができる。

　システム開発を進める過程ですべてのアクセスポイントに適する個々のテストハーネスを使えば、各サービスが完成システム全体の中でデータコンテンツ（機能性）とパフォーマンス（スケーラビリティ）の両面でうまく機能するようチューニングできる。フロントエンド（ブラウザ経由の部分）で問題が見つかった場合には、個々のコンポーネントのテストに利用したテストスイートやテストハーネスが、不具合の発生場所を即座に特定できるよう支援してくれる。

ネットワークモデリングの利点

　異なるネットワークアーキテクチャのモデリングは、デザインプロセスの一環として組み込まれている場合（ハードウェアの購入前もしくは初期テストフェイズ中のいずれか）、ネットワークデザインを効率的にし、障害が発生しにくくなるのを支援する。その結果、包括アーキテクチャテストの利点拡大につながる。導入に先立ちネットワークインフラをモデリングすることは、パフォーマンスのボトルネックやルーティングテーブルおよびコンフィグレーション中の不具合の特定に役立つ。さらに、テスト中に入手したアプリケーションのトランザクション調査結果は、このモデルに反映することで、アプリケーションの「おしゃべり度」*1とインフラが抱える潜在的な問題の特定や切り分けに役立つ。

結論

　包括アーキテクチャテストは、広範囲な品質の面からコンピューティング環境を試験運用し、分析する。各コンポーネントのスケーラビリティや機能性が、開発途中やリリース前の品質評価中にも、個別にあるいは全体的にテストされるため、開発の効率を引き上げる診断情報が提供される。リリース時には高レベルの品質保証が実現するだろう。包括的なアーキテクチャテストは、今日のアーキテクチャや分散コンピューティング環境の複雑性を管理するために、包括的かつ信頼性の高いソリューションを提供してくれるだろう。

　必要なテストや分析が広範にわたることを考慮すれば、包括的なテスト作業を計画、管理、そしてインプリメントするためには、相当な専門知識と経験が要求されるのはもちろんだ。しかし、ビジネスの観点から見た場合、包括的なテストの考え方を取り入れる組織は、アプリケーションやシステムのパフォーマンス、信頼性で一段と高いレベルを保証できるようになるだろう。また、これらの組織は最終的にカスタマリレーションの向上、一般管理費の削減、そして売上高の増加など、本質的な改善のメリットを享受することになる。

　Rational PartnerであるRTTSでは、6年前に包括アーキテクチャテストアプローチを開発して以来改良を繰り返しており、アプリケーションの機能性、信頼性、スケーラビリティ、およびネットワークパフォーマンスを保証すべく、数百社のクライアントと協力を続けている。RTTSのWebサイトはhttp://www.rttsweb.com。

IT Architect 連載記事一覧

---

メモ

*1.コンポーネント間のトランザクションを完了するため多数のクエリとの応答を必要とするアプリケーションを「おしゃべり」という。

　

本記事は「The Rational Edge」に掲載された「End-to-End Testing of IT Architecture and Applications」をアットマーク・アイティが翻訳したものです。