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