目次


結合テストでの環境の制約を打破する

環境の可用性を向上させるためのストラテジー

Comments

結合テストでは、提供されたシステムの検証が行われます。このテストで企業はアプリケーションを実際に確認し、要求されていたものが開発によって作成されたかどうかを判断することができます。ソフトウェア・システムのコンポーネント化が進んで、システムを構成するサービスの数が増えるなか、コード変更が行われてから結合テストを実施するまでの時間差が、タイム・ツー・マーケットと開発者の生産性を予測する主要な判断材料となっています。

理想的なプロセスは、開発者がコードに変更を加えるたびに、すべてのテストを迅速に実行して、そのフィードバックを開発者に提供するという単純なものです。つまり、変更が加えられたコンポーネントをビルドし、ユニット・テストを実行し、統合環境にデプロイした後、すべての結合テストをほんの数分で実行します。

しかし残念ながら、多くのチームにとって、この理想的なプロセスは現実ではありません。例えば、自動化されているテストの数があまりにも少なかったり、自動テストの実行にあまりにも時間がかかったりすることがあります。また、継続的インテグレーションをセットアップできない場合もあります。複雑なアプリケーションを自動的にデプロイするために、特殊なツールが必要になる可能性もあります。

これらの問題に対するソリューションは、今では十分に理解されています。それは、API テストに重点を置いてテストを自動化することです。継続的な自動ビルド・プロセスをセットアップするのは簡単なので、その手を使わない理由はありません。デプロイメント自動化ツールは、今では定着しています。

その一方で、多くの組織にとって共通の問題となりつつあるのは、結合テスト環境の欠如です。結合テスト環境が不完全であったり、一貫していなかったり、あるいは単に必要を満たしていなかったりする場合があります。この記事では、なぜこのような問題が存在し、それにどう対処すべきかを見ていきます。

環境の制約

より高い品質のテスト環境を別途用意してフィードバックを迅速化する方法を理解するには、環境の制約について把握しておかなければなりません。その知識が、問題の解決に役立ちます。

  • 限られたハードウェア: テスト環境を稼働させるにはリソースが必要です。それらのリソースは無料ではありません。
  • 高い構築コスト: 新しいテスト環境を構築するには、サーバーをプロビジョニングし、ミドルウェアを構成し、アプリケーションを実行させる必要があります。これには、かなりの作業が必要です。
  • 高い保守コスト: テスト環境の数が増えることから、構成やパッチ・レベルなどを保守するための労力が必要になります。
  • 一定でない需要: チームに多数の環境が必要になるときもあれば、少数の環境しか必要でないときもあります。
  • 貴重なコンポーネント: 一部のアプリケーション・コンポーネントは、テストで使用するには高価なため、そのようなコンポーネントに対するテストの頻度が制限されることがあります。また、トランザクション、メインフレーム・コンポーネント、アプライアンス・アプリケーションに対して料金を請求するサード・パーティーの Web サービスも制約要因となります。
  • 欠落したコンポーネント: テスト対象のサービスを他のチームが所有していて、そのチームがそのサービスをまだ提供していないこともあります。その場合、ソリューションは不完全なままになってしまいます。
  • 壊れたコンポーネント: 多数のコンポーネントに頻繁に変更が加えられる場合、いずれかの時点でコンポーネントが壊れている可能性が高くなります。

概して、上記に挙げた結合テスト環境の特性は、互いに促進されます。例えば、環境構築のコストが高くても、その環境が長期間存続するものであれば、そのコストは許容されますが、需要が一定しないため、その環境が必要となるのは短期間になる可能性があります。また、常に稼働している環境は保守するのが容易になりますが、あいにくハードウェアにはコストがかかるため、利用されていない環境はシャットダウンすることが望まれます。

ボトルネックを解消する手法

結合テスト環境に伴う問題を取り除き、環境の可用性を向上させる手法には、「環境の予約」、「サービスとしての環境 (Environment as a Service)」、「サービス仮想化」の 3 つがあります。問題で解決される部分は、手法ごとに異なります。

環境の予約

最も単純なストラテジーは、積極的に環境をスケジューリングして管理することです。環境のスケジューリングと管理は、一般にリリース・マネージャーの役割です。このストラテジーでは、統合環境を貴重なリソースとして扱い、リリースの優先度とリリース日までの期間を基に、統合環境をリリース・テストに割り振ります。最近のリリース管理ツール (例えば、IBM UrbanCode Release) には、環境を組織的に追跡する手段や、スケジューリング手段、競合検出手段などが用意されていますが、今でも一般的に使用されているのはスプレッドシートです。

利点

どのリリースがいつ環境を使用できるかを明確に記述することで、開発チームとテスト・チームに必要とされる予測可能性がもたらされ、限られたリソースの価値を最大限活かせるようになります。

制約事項

環境の予約は、限られたリソースを確実に有効利用するのに役立ちますが、これによって追加の環境が提供されるわけでも、環境の不一致が軽減されるわけでもありません。

サービスとしての環境 (Environment as a Service)

アプリケーションに応じてカスタマイズされたテスト環境を要求すると、その環境のプロビジョニングと構成が数分で行われるのは極めて強力です。このストラテジーでは、環境を必要に応じて開始、構成、破棄するパターンを備えた UrbanCode Deploy のような環境パターン・エンジンと、クラウド・テクノロジー (パブリックまたはプライベート) とが組み合わされて使用されます。

利点

サービスとしての環境 (Environment as a Service) というソリューションを使用すると、テスト環境の構築作業が大幅に削減されます。既に用意されている構成の更新も行うこのソリューションは、本番環境に対する忠実度を向上させると同時に保守の管理を行います。概して、チームは必要な統合環境を必要なときに手に入れることができます。サービスとしての環境 (Environment as a Service) テクノロジーは、結合テスト・ストラテジーの基礎となるはずです。

制約事項

低いコストで環境を作成できるとなると、環境の数が増加しがちです。この場合、ハードウェア・コストが問題になる可能性があります。これは、非常に大規模な統合環境ではなおのことです。構築コストを削減するのに役立つ方法は、比較的低いコストのクラウド・リソースをベースに環境を構築することです。そのような環境は作成するのも破棄するのも簡単なため、めったに使用しない環境を保持する傾向は少なくなります。代わりに、必要に応じて未使用のリソースを回収して再び環境を起動できるようになります。

サービスとしての環境 (Environment as a Service) というストラテジーはクラウドと仮想化がベースであるため、「貴重な」コンポーネントの多くは、このストラテジーに上手く適合しません。これらのコンポーネントは、プロビジョニングされた複数の環境で共有するか、仮想化する必要があります。

他のチームが所有する壊れたコンポーネントが懸念事項になる可能性がありますが、大規模なチームのそれぞれがチームに専用の統合環境を所有し、他のチームのコンポーネントについては問題のないことがわかっているバージョンに対してのみ自動デプロイメントを使用すれば、サービスとしての環境 (Environment as a Service) によってチーム間を分離することができます。

サービス仮想化

サービス仮想化では、システムの一部のコンポーネントを「スタブ」または「モック」に置き換えます。モックは、長年使用されてきた手法であり、開発者が完全なサービスのように機能するサービスを作成して、そのサービスに対してテストするというものです。例えば、サード・パーティーによって提供されている株価情報サービスが、トランザクション単位で課金を行うとします。その場合、開発者はそのサービスと同じ API を持ちつつも常に同じ値を返すテスト用の代替サービスを作成します。IBM Rational Test Workbench に組み込まれているようなサービス仮想化ツールは、このようなスタブを作成してその実行場所と実行方法を管理するプロセスを簡素化します。

利点

サービス仮想化では、「貴重な」コンポーネントを扱うための専用の手段を提供しており、使用量に応じて課金するコンポーネントや特有のコンポーネント (メインフレーム、高価なミドルウェア、アプライアンス) の代替をスタブが務めます。

スタブは、他のチームによるコンポーネントの代替に使用することもできます。この場合の利点としては、次の 3 つが挙げられます。

  • ある程度の分離: 別のチームが自ら担当するコンポーネントを壊したとしても、結合テスト環境の有用性には影響しません。
  • リソースの使用: これらの他のチームのコンポーネントを実行するために必要なサーバー・キャパシティーを確保する必要がなくなります。
  • まだ完成していないコンポーネントについては、その代替としてスタブを使用できるため、ライフサイクルの初期段階で結合テストのシナリオを利用することができます。

制約事項

スタブではなく実際のコンポーネントをテストする段階になると、テストの関連性は増してきます。自分たちが行っている作業を別のチームが壊さないようにするための分離機能が、完全に結合されたシステムのテストを遅らせることにもなります。テストが遅れると、その分フィードバックも遅れることから、テストの遅れは代償を伴います。また、サービス仮想化は、実際に存在するコンポーネントからなる環境を管理する上では役に立ちません。

3 つの手法を組み合わせた現実的なシナリオ

Marketplace という架空の主要なシステムの例で、上記で説明したツールを組み合わせて使用する方法を示します。Marketplace は、以下のように多数のコンポーネントからなります。

  • やや緊密に結合された 60 の Web サービス。4 つのチームが、それぞれ 15 のサービスを所有しています。
  • トランザクションの 20% に貢献するメインフレーム・コンポーネント。変更されることがめったにないこれらのコンポーネントは、別のチームが所有しています。
  • フロントエンド Web サイト。サービスの前面にあり、ドットコム・チームが所有しています。
  • 2 つのサード・パーティーからの (Web サービスを介した) データ・フィード。一方はトランザクションに基づく従量制のサービスであり、もう一方は従量制ではないサービスです。

Marketplace リリース・チームには 1 つの大規模な結合テスト環境 (INT: Integration Test Environment) と、パフォーマンス・テスト環境 (PERF: PERFormance testing environment) があります。現在は 6 つのチームのそれぞれが小規模なテスト・ラボを使用して、コンポーネントの一部をテストできるようになっていますが、これらのラボで結合テストのシナリオを実行することはできません。結合テストはリリース・スケジュールに従って行われ、リリース管理によって INT 環境と PERF 環境へのアクセスが管理されています。

チーム・レベルの統合環境

開発者の生産性を促進するために、Marketplace 組織では、各開発チームが専用の結合テスト環境を使用できるようにするとともに、追加のコード行をテストする場合や開発作業が急増した場合には、追加の環境を起動できるようにすることにしました。

  • サービスとしての環境 (EaaS): EaaS ツールが企業の内部クラウドを使用してアプリケーションのコピーを開始します。該当する開発チームのサービスにとって十分とされるだけの数の仮想マシンと、UI の最新作業用コピーが使用されます。
  • サービス仮想化: 他の Web サービス・チームのサービスと、メインフレームを仮想化します。サード・パーティーの従量制サービスも仮想化しますが、もう一方のフィードはライブで使用します。
  • 環境の予約: 可視性のために、リリース管理ツールの予約システムで、どの環境がどのリリースの作業をホストしているのかを把握します。ただし、環境の数は不足していないため、チーム・レベルの環境は予約しません。

最終的に、各開発チームは、サービス仮想化を多用した小規模でコストの低い環境を多数保持することになりました。大規模なシステムでコンポーネントをテストすることも可能ですが、各開発チームは他のチームから分離されています。自分たちのコンポーネントを他のチームが壊したり、自分たちが他のチームのコンポーネントを壊したりしないか心配することはありますが、仮想化が多用されているということは、サービスの統合の問題はすぐに見つからないことを意味します。

リリース・レベルの統合環境

リリースごとにシステム結合テスト環境をプロビジョニングします。これらの環境はほぼ完成していて、使用するサービス仮想化は最小限です。変更をこの環境に取り込む場合、その変更はチーム・レベルの環境での厳格な一連の自動テストに合格していなければなりません。

  • サービスとしての環境: EaaS では、長期間存続する傾向にある多数の環境をプロビジョニングすることができます。これらの環境は以下のとおりです。
    • 現行リリースに対するパッチのテスト環境
    • 次期リリースのために頻繁に用いられる環境
    • 次に控えた大規模な開発作業のために時折用いられる環境
    EaaS の主な役割は、複数の環境を正しいインフラストラクチャーに従った状態に保つことです。
  • サービス仮想化: メインフレームと従量制 Web サービスのみを仮想化します。
  • 環境の予約: リリース・レベルの統合環境は大規模であるため、ハードウェアに関してコストがかかります。環境の予約を使用して、追加の環境が必要である事態かどうかを監視すると同時に、可能であれば環境の追加を最小限に抑えます。チーム環境と同じように、このシステムは主に、誰もが適切な環境を適切なリリースに対して使用できることが確実となるようにするために使用されます。

チーム・レベルの環境で徹底的な結合テストが行われるため、この環境でのテストを妨げるような変更はほとんどありません。手動テストの担当者にとって、リリース・レベルの統合環境は作業に時間を費やす場所となり、高可用であること、そして常に最新の適切なコードが存在する状態にあることによる恩恵を享受できる場所となります。

パフォーマンス・テスト環境

パフォーマンス・テスト環境は、ほとんど変更されることのない最大規模の環境です。サービス仮想化は Web サービスにもメインフレームにも有効です。メインフレームと従量制サービスの場合、トランザクション数が多いテスト期間に仮想化が使用されることがよくあります。他のパフォーマンス・テストのシナリオでは、時間をかけてリクエストに応答するようにサード・パーティーの両方の Web サービスに代わるスタブを設定し、サード・パーティー・プロバイダーで問題が発生した場合のアプリケーションの動作を検証します。

最終的な結合テスト

結合テスト環境は、結合したソフトウェアの最終的な検証に使用されます。結合テスト環境にはライブ・バージョンの従量制サービスやメインフレーム・コンポーネントなどの十分ではないリソースへのアクセスが含まれることから、環境は管理され、スケジューリングされます。期待されるリリースに結合テスト環境を割り振るには、引き続き環境の予約システムを使用します。

パターン

上記の例で検討したパターンは、かなり一般的なものです。開発者によく使用されるのは、仮想化を多用した小規模な環境です。開発者は環境を利用しては離れる傾向があるため、開発者も環境のプロビジョニングを積極的に活用します。中間の環境では、環境のプロビジョニングを使用して、より完成した統合環境を構築するため、サービス仮想化が提供する部分は少なくなります。後半のテスト環境では、貴重なリソースがスケジューリングされてリリースに割り振られます。それぞれに特有の長所がある各手法を利用して、ある手法の制約事項を他の手法の長所で補完してください。そうすることで、チームはスケジューリング、サービス仮想化、そしてサービスとしての環境 (Environment as a Service) の組み合わせから最大限の有用性を引き出すことになります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps
ArticleID=1003806
ArticleTitle=結合テストでの環境の制約を打破する
publish-date=04302015