ビルド プロセスの自動化
自動ビルド プロセスは、プロジェクトの最新のソース コードに対して、定期的な事前に定義された間隔でビルド検証テスト (BVT) をコンパイル、デプロイ、実行します。 その後、ビルド プロセスの成功または失敗を詳しく説明する "ビルド レポート" がプロジェクトの利害関係者に配布されます。 ビルド レポートを分析して、プロジェクトの注意が必要な領域と、プロジェクトを以前のバージョンまたはビルドにロールバックする必要があるかどうかを判断します。
自動ビルド プロセスの機能は、"オフ時間" に実行されるようにスケジュールできることです。 これにより、開発時間から直接サイクルを取ることなく、プロジェクトの安定性を確保できます。 このトピックでは、ビルド プロセスの概要、ビルド検証テストがビルド プロセスにどのように適合するか、ビルド検証テスト中に使用される機能テストの側面について説明し、ビルド プロセスの自動化の重要性に関する情報を提供します。
ビルド プロセスの概要
テストの詳細を調める前に、テストが全体的なビルド プロセスにどのように適合するかを考慮することが重要です。 Microsoft のすべての製品グループは、ビルド プロセスがソフトウェア プロジェクトのハートビートであるという理念に基づき動作します。 このアプローチは、Microsoft ソフトウェア スタックの上にミッション クリティカルなソリューションを構築する世界のトップ コンサルティング企業の多くでも使用されています。 安定したハートビートと定期的なチェックがないと、プロジェクトの正常性を知ることは不可能です。 製品グループがプロジェクトの全体的な正常性に関する継続的な分析情報を確実に得られるように、ビルド プロセスは毎日 (通常は午前 0 時) に実行されます。 次の手順は、一般的な自動ビルド プロセスをまとめたものです。
ソース コード リポジトリからソース コードの最新のビルドを取得します。
ソース コードをコンパイルします。
展開用にバイナリをパックする - 通常はスクリプトまたは Microsoft Windows インストーラー ファイルを使用します。
プロジェクトをテスト サーバーに配置します。
ビルド検証テスト (BVT) の完全なセットを自動的に実行します。
プロジェクト チームのメンバーに詳細なビルド レポートを発行します。
Note
BVT は、ソリューションのメイン機能を実行して品質をテストする機能テストです。 BVT がビルドの品質を測定するのに十分な包括的であり、割り当てられた毎日のビルド時間内に実行するのに十分な小さいことを確認する必要があります。
Note
また、展開、展開解除、構成とインストールのスクリプトまたはプロセスは、テスト目的でソフトウェア プロジェクトの一部として扱う必要があります。 プロジェクトの操作と、その配置と構成の両方をテストする必要があります。
このプロセスは通常、午前 6 時頃に早朝に完了します。これにより、チームの最初のメンバーは新しい日のビルドで作業を開始できます。 前の夜の 1 つ以上の BVT が失敗した場合は、できるだけ早く修正する必要があります。
毎日のビルド プロセスを実行すると、プロジェクトに多くの利点があります。 まず、定期的なハートビートを提供します (毎日のビルドと自動化された BVT で構成されます)。 第 2 に、BVT を使用すると、難しいタスクであるシステムとの統合が強制され、それ自体の早い段階でこれを行うことで、プロジェクトのリスクが軽減されます。 それらを完了するために必要な時間のため、ストレスとパフォーマンスのテストは通常、毎日のビルド プロセスの外部で実行されます。 ストレス テストとパフォーマンス テストは、通常、プロジェクトのマイルストーン ビルドで実行されるようにスケジュールされます。
毎日のビルド プロセスは、BizTalk ソリューションで非常に効果的に使用できます。 ただし、通常はプロジェクトの最後まで残っているタスクが、最初から繰り返し実行されるようにする必要があります。 たとえば、BizTalk Serverでのデプロイは、確かに簡単ではありません。 自動デプロイ スクリプトを前もって開発することが重要です。 これを行わないと、プロジェクト全体でソリューションを何度も手動でデプロイおよび展開解除することになるため、最終的には時間がかかります。 毎日のビルド プロセスを推進するためのツールがあります。Visual Studio Team System と Team Foundation Server は、多くのユーザーにとって主要な選択肢です。 MSBuild スクリプトを使用して、ビルド プロセスの手順を実行できます。
Note
このツールの使用は Microsoft ではサポートされておらず、Microsoft はこのプログラムの適合性について保証しません。 このプログラムは、ユーザー自身の責任で使用してください。
Microsoft Test Manager を使用したテストの自動化の詳細については、「自動テストの 実行」を参照してください。
ビルド確認テスト
ビルド検証テストは、通常、次の要素で構成されます。
単体テスト - 通常、単体テストは最初に開発されるため、テスト駆動型の開発アプローチを実際に使用している場合は、コードが実際に記述される前に作成するのが理想的です。 プロジェクトの初期段階で BVT に追加することで、少なくとも一部のコード カバレッジをすぐに提供できます。 機能テストの数が増え、したがってテスト カバレッジが増えるにつれて、BVT から単体テストを削除することを選択できます。
スモーク テスト - ソリューションの基本的な機能をテストするエンドツーエンドの機能テスト。 これらが失敗した場合、何かが深刻に間違っています。 通常、これらは比較的迅速に実行できます。
機能テスト - これらはエンド ツー エンドのシナリオも対象としますが、この場合はプロジェクト内のすべてのシナリオをテストします。 大規模なプロジェクトの場合は、機能テストをさらに分類することが理にかなっている場合があります (たとえば、特定のコンポーネントを迅速かつ確実に、分離してテストできるようにします)。 これらの機能テストは、ソリューションで機能的に正しいものとしてサインオフした後にロックダウンする必要があります。
回帰検証テスト - ソリューションのバグが見つかり、修正されるたびに、バグが修正され、プロジェクトライフ サイクルの後半で再導入されないことを確認するために、回帰検証テスト ケースを追加する必要があります。 通常、これらのテストは、機能テスト ケースでカバーされなかったケースになります。 新しいバグが検出されて修正された場合、ソリューションが稼働した後でも回帰検証テストの数が増えると予想されます。
非常に大規模なプロジェクトでは、BVT を完全な機能テスト スイートのサブセットにする必要がある場合があります (実行に時間がかかるため)。 小規模なプロジェクトの場合、BVT はセット全体を構成します。 明らかに、BVT を毎日のビルドの一部として統合する場合は、プロセス全体を自動化する必要があります。 このトピックの残りの部分では、BizUnit やその他のツールを使用してこれを実現する方法について説明します。
機能テスト
BizTalk アプリケーションの機能テストのコンテキストで、特定のエンド ツー エンドのシナリオをテストします。 この種のテストを実行する場合は、BizTalk Serverを外部の観点から機能的にテストする黒いボックスと考えると便利です。 たとえば、テストでは、入力メッセージ (既知の値を含む) を受信場所のエンドポイント (URL、FTP の場所など) にフィードする必要があります。トランスポートの選択が何であれ。 その後、テストでは、送信側で生成される正しい出力を使用して、正しい数のメッセージを監視します。 これは比較的簡単に聞こえるかもしれません。 ただし、一部のシナリオでは特定の順序で特定の順序で入力が必要であり、これを他のソリューション要件 (BAM で追跡データを記録する場合など) と組み合わせて使用すると、これを調整するためにツールとフレームワークを使用できることは明らかになります。
機能テストは、ソリューションを通じて可能なすべてのパスをカバーするように設計されていることが重要です。 これには、運用環境で想定されるシナリオだけでなく、実装した障害パスと例外処理パスも含まれますが、使用しないことを願っています。これを説明するために一般的に使用される 1 つのフレーズは、"悪い日のシナリオ" のテストです。 すべてのオーケストレーション、すべての許容されるメッセージの種類、およびすべてのコード ブランチが機能テスト スイートによって実行されていることを確認する必要があります。 次のセクションでは、すべてのコード パスをカバーする正と負の機能テスト ケースの開発について説明します。
機能テストと、BizTalk Server ソリューションを運用環境に配置する前に実装する必要があるその他のテスト カテゴリの詳細については、「チェックリスト: 運用準備のテスト」を参照してください。
肯定的なテスト
メッセージ、パイプライン、オーケストレーション、エンドポイントのすべての組み合わせがソリューションを通過し、すべてのメッセージ フローが実行されるように、肯定的なテストを実行する場合に重要です。 すべてのコード パスをテストするには、異なるコンテンツで異なるメッセージを処理する必要がある可能性があります。
テストする場合は、運用環境で使用されるトランスポートの種類を使用します。 残念ながら、多くの場合、機能テストは、運用環境で他のトランスポートが使用される場合に、ファイル アダプターを使用してのみ実行されます。 このアプローチを採用することは、後でプロジェクト全体を失敗に備えて設定することです。
システムから送信されるすべてのメッセージのペイロードを検証します。 メッセージが XML の場合は、XPath 式を使用して、メッセージ内のスキーマとキー フィールドを検証する必要があります。
BAM に格納されている追跡データ (使用されている場合) を検証します。外部データ リポジトリに残されているその他のデータは、考慮する必要があります。
ソリューションで BRE が使用されている場合は、すべてのビジネス ルール エンジン (BRE) ポリシーとルールの実行をテストします。
負のテスト
システムを介して無効なメッセージの処理をテストしてください。 選択した戦略 (BizTalk Serverに入る前に拒否するため、または中断するため) が正しく機能したことを確認する必要があります。
無効なメッセージの処理をテストする場合は、中断されたメッセージを処理するために受信側エラー処理オーケストレーションが実装されていることをテストしてください。
障害シナリオがオーケストレーション内のすべての例外ブロックをカバーしていることを確認します。 これを適切にテストできないのは一般的な問題です。
補正動作で実行時間の長いトランザクションを使用している場合は、これらのシナリオを慎重にテストしてください。 これは、運用環境でテストが不十分な場合に重大な結果が発生するもう 1 つの領域です。
エラーが適切なエラー ログに正しく記録されていることを確認します。
自動化が重要
このすべてを効率的かつ効果的に行うには、テストを自動化するために前もって時間を費やします。 手動テストは時間がかかり、エラーが発生しやすく、コストも高くなります (時間とコストの観点から)。 手動テスト パスを実行するたびに、プロジェクト リソース (チーム内のユーザー) で処理する必要があるタスクの別のバッチを追加します。 これを前もって自動化することで、テストを実行するたびに開発するために必要な初期投資の収益率を得ることができます。 優れた機能テストは、迅速かつ効率的に実行され、反復可能である必要があります。各テストも自律的である必要があります (他のテストとは独立している必要があります。このアプローチを採用すると、テスト スイートとして複数のテストを順番に実行できます)。機能テストでは、常に同じ結果が生成されます。 機能テストの記述が不十分な場合や、コードの記述が不十分な場合は、テストの実行間でテスト結果が異なり、エラーの根本原因を調査する混乱と無駄な時間が発生します。
各機能テストを記述するために必要な開発作業を最小限に抑える必要があります。 通常、(開発時間の観点から) 何かを生成するコストが高いほど、最終的にはテスト ケースが少なくなります。 つまり、コードに対するテスト カバレッジのレベルが低くなります。 テスト フレームワークを使用すると、テスト ケースをより迅速かつ簡単に開発できるため、完全なコード カバレッジを簡単に取得できます。 ほとんどの優れたテスト フレームワークでは、宣言型のアプローチを使用してテストを定義します。 (つまり、テストの構成は構成ファイル (通常は XML ファイル) に格納されます)。優れたテスト フレームワークを使用すると、アジャイルで信頼性の高い方法で完全に機能するテスト スイートを開発でき、話すために何度も何度も "ホイールを再発明" する必要がなくなります。
BizTalk Server プロジェクトの MSBUILD サポート
BizTalk Serverは、Visual Studio がインストールされていないビルド ラボ環境でのマネージド プロジェクトのビルドに対応する、Microsoft Build Engine (MSBUILD) プラットフォームのサポートを提供します。 MSBUILD は、コマンド ラインからのプロジェクトのビルドと、MSBUILD のログ記録やバッチ処理などの高度な機能に対応しています。 MSBUILD の詳細については、「 MSBuild の概要」を参照してください。