このトピックでは、テストが不十分になる考え方の概要、BizTalk ソリューションのテストの失敗に関連するリスクについて説明し、手動テストの落とし穴と自動テストの利点を比較します。
"オーバーヘッド" としてのテスト
残念ながら、投資収益率 (ROI) の要求が増えるにつれて、プロジェクトのテスト フェーズは、多くの場合、スケールバックできるプロジェクト計画の最初の側面の 1 つと見なされます。
BizTalk ソリューションのテストに対する 1 つの引数は、「Microsoft は既にBizTalk Serverを徹底的にテストしているため、ソリューションをテストする必要はありません」という点です。 Microsoft がBizTalk Serverを徹底的にテストすることは事実ですが、さまざまな使用シナリオでは、スループット、高可用性、アダプターの使用、待機時間、追跡要件、オーケストレーションの使用、カスタム コードに関する、ほぼ数え切れない数のビジネス要件のいずれかが必要です。 BizTalk Serverは非常に柔軟で、さまざまな使用シナリオに対応できるため、それらのすべてを予測してテストすることはできません。 さらに、BizTalk Server環境で適用される既定の設定は、各使用シナリオに対応するように最適化する必要があります。 特定の使用シナリオに最適な設定を決定する唯一の方法は、ソリューションのテスト、さまざまなパラメーターの測定、環境の調整、再テストです。 BizTalk Server ソリューションのサンプル物理アーキテクチャを示す次の図を考えてみましょう。
サンプル物理 BizTalk アーキテクチャ
上の図では、BizTalk Server ソリューションには、BizTalk Serverを実行している複数のコンピューター、SQL Serverを実行しているコンピューター、サーバー クラスター ノード、Active Directory ドメインなど、多くの可動部分が含まれていることを確認できます。 システムが稼働すると、ソリューションの全体的な ROI を最大化するために、ビジネス要件に従ってアプリケーションを最適化するために多くの構成調整が適用されます。 この 1 つのシナリオは、多くの変数が存在することを示しています。 環境の物理アーキテクチャに加えて、BizTalk Serverを介したメッセージのフローを示す次の図を検討してください。
サンプル論理 BizTalk メッセージ フローを介したメッセージのフロー
BizTalk Serverを通過するメッセージの論理図を見ると、カスタム送受信パイプライン コンポーネントや BizTalk オーケストレーションから呼び出すことができるカスタム クラスなど、プロジェクトごとのテストを必要とするその他の変数が表示されます。 カスタム コンポーネントと BizTalk コンポーネントの型の複雑さと使用はプロジェクトによって異なるため、特定の使用シナリオごとにテストを実行することが重要な理由がより明確になります。
テスト手法とタイムライン
テストが効果的かつ効率的に実行されるようにするには、テスト ハーネスを完全に自動化して、簡単に再現でき、人的エラーの可能性を最小限に抑える必要があります。 さらに、プロジェクトの計画時にテストに十分な時間を割り当てる必要があります。 テストへの最小限のアプローチは、次のような手動の手順で構成されます。
ファイル ドロップなどの受信エンドポイントに、または SOAP クライアントを使用して Web サービスを呼び出すことによって、1 つ以上のメッセージを手動で読み込みます。
メッセージの正しい内容と構造を手動で検証します。 多くの場合、複数のスキーマがプロジェクトに存在するため、メッセージはフラット ファイルと XML が混在している可能性があり、フィールド間の依存関係も含まれる場合があります。
Note
この例としては、SWIFT メッセージを含むすべてのプロジェクトがあります。 これらは、フィールド間の依存関係を持つフラット ファイル メッセージです。 つまり、あるフィールドの値は別のフィールドに依存します。単純な XSD 検証ではここでは行われません。そのため、SWIFT アクセラレータは BizTalk ルール エンジンを使用してメッセージの検証を行います。 SWIFT アクセラレータの詳細については、以下を参照してください。
エラーが発生した場合は、BizTalk Server コンピューターでイベント ログを手動でチェックします。
BAM データベース (使用されている場合) を手動でチェックして、アクティビティ情報が正しく記録されていることを検証します。
上記のように手動プロセスをテストに使用すると、主観的でエラーが発生しやすくなります。 10 種類のテスト ケースについて、フィールド間の依存関係を持つ 100 行の SWIFT メッセージを調べる必要があるとします。 ほとんどのプロジェクト開発者は、それができても、そのようなタスクに確実かつ正確に取り組む傾向はないでしょう。 主観的で手動でエラーが発生しやすいテスト プロセスを実装すると、プロジェクトにリスクが追加され、失敗の可能性が高まります。
多くの場合、失敗のリスクは、テストに十分な時間が組み込まれていないプロジェクト計画のタイムラインによって増幅されます。 多くの場合、プロジェクト テスト戦略は、稼働日の 1 週間ほど前にスケジュールされた 1 回の手動テスト パスに依存します。 このような限定的なテストでは、プロジェクトが危険にさらされます。 このようなテストのタイムラインが限られている場合、問題が検出された場合、問題を解決するための時間が割り当てられていないため、プロジェクトが遅延する可能性があります。 さらに、問題が検出され、修正された場合、システムが稼働するまでの後続のテスト パスの実行に十分な時間が残っていない可能性があります。
"単一の最終ビルド、単一のテスト パス、プロジェクトをライブに取る" テストの現実は、プロジェクトが遅延したり、プロジェクトが予算を超えたり、さらに悪いことに、プロジェクトが完全に失敗したりすることが多いということです。 ミッション クリティカルなシステムの場合、このようなテスト手法は、発生を待っている災害です。
効果的かつ効率的にテストする
適切なテストは、多くの場合、不可欠な要件ではなく高価な贅沢と見なされるため、プロジェクトの末尾に取り付けすぎることがよくあります。 異種エンタープライズ環境内で使用されるソフトウェアとハードウェア スタックの複雑さを考えると、このアプローチは非現実的です。 オンデマンドで再実行できる自動テスト アプローチの実装は、効果的かつ効率的にテストするための最良の方法であり、最終的に優れた ROI をビジネスに提供する成功したプロジェクトの不可欠なコンポーネントです。 システムを通じてコード パスごとに完全なエンドツーエンドの機能テストにプロジェクトの開始時に投資することで、テスト資産を生成します。 これらの資産は、後でテストの有効性と効率を向上させる利点を得るために投資 (開発時間など) を必要とします。 このようなフレームワークを派生させるためにプロジェクトから必要な投資を最小限に抑えるには、Visual Studio 2010 ロード テスト フレームワークを利用することをお勧めします。 Visual Studio 2010 には、テストの成功に必要な一般的なテスト手順の大部分が含まれており、このガイドで後述するテスト シナリオで使用されるフレームワークです。