自動化建置程序
自動化建置程式會編譯、部署及執行建置驗證測試， (BWT) 定期預先決定的間隔，針對專案的最新原始程式碼。 然後，「建置報告」會詳細說明建置程式的成功或失敗，會受到專案專案關係人的影響。 系統會分析建置報表，以判斷專案需要注意哪些區域，以及專案是否應該回復至舊版/組建。
自動化建置程式的強大功能是可以排程在「停機」期間執行。 如此一來，它可協助確保專案的穩定性，而不需要直接離開開發時間。 本主題提供建置程式的概觀、描述組建驗證測試如何融入建置程式、描述建置驗證測試期間所使用的功能測試層面，並提供自動化建置程式重要性的相關資訊。
建置程式的概觀
在查看測試的詳細資料之前，請務必考慮測試如何融入整體建置程式的內容。 所有 Microsoft 產品群組都是從建置程式是任何軟體專案的活動訊號的原理運作。 許多世界級的諮詢公司也會使用此方法，以在 Microsoft 軟體堆疊之上建置任務關鍵性解決方案。 如果沒有穩定的活動訊號和定期檢查，就無法知道專案的健康情況。 為了確保產品群組能夠持續深入瞭解專案的整體健康情況，建置程式每天執行，通常是午夜。 下列步驟摘要說明典型的自動化建置程式：
從原始程式碼存放庫取得原始程式碼的最新組建。
編譯原始程式碼。
封裝二進位檔以進行部署 – 通常使用腳本或 Microsoft Windows Installer 檔案。
將專案部署至測試伺服器。
(BWT) 自動執行一組完整的組建驗證測試。
將詳細的建置報表發佈給專案小組的成員。
注意
BVT 是功能測試，可練習解決方案的主要功能來測試其品質。 您必須確保您的 BVT 夠完整，足以測量組建品質，但夠小，足以在配置的每日建置時間內執行！
注意
您也應該將任何部署、未部署、設定和安裝腳本或程式視為軟體專案的一部分，以供測試之用。 應該測試專案的作業及其部署和組態。
此程式通常會在上午 6 點左右完成，這可讓小組的第一個成員開始在新天的組建上工作。 如果前一個晚上的一或多個 BWT 失敗，則小組必須盡速修正它。
在每日建置程式之後，專案有許多優點。 首先，它會提供一般活動訊號 (，由每日組建加上自動化 BVT) 所組成。 其次，使用 BVT 會強制與系統整合，這是一項棘手的工作，並在其本身早期執行此動作可降低專案風險。 由於完成它們所需的時間，壓力和效能測試通常會在每日建置程式之外執行。 壓力和效能測試通常會排程在專案中的里程碑建置上執行。
每日建置程式可以在 BizTalk 解決方案上非常有效地使用。 不過，您必須確保一般留在專案中結尾的工作會從一開始就反復完成。 例如，BizTalk Server中的部署當然不是簡單的。 請務必預先開發自動化部署腳本。 如果您未這麼做，您最終會在整個專案中手動部署和取消部署解決方案多次，這將會花費您更多時間。 有工具可用來驅動每日建置程式;Visual Studio Team System 和 Team Foundation Server 是許多人的主要選擇。 MSBuild 腳本可用來驅動建置程式中的步驟。
注意
Microsoft 不支援使用此工具，Microsoft 不保證此程式的適用性。 請自行承擔使用這個程式的一切風險。
如需使用 Microsoft Test 管理員自動化測試的詳細資訊，請移至 執行自動化測試。
組建驗證測試
組建驗證測試通常包含下列元素：
單元測試 - 因為單元測試通常是要開發的第一個測試，因此最好先建立它們，才能實際撰寫程式碼，如果您真的使用測試驅動開發方法。 藉由在專案的早期階段將它們新增至 BVT，您至少會立即提供一些程式碼涵蓋範圍。 隨著功能測試的數目增加，因此測試涵蓋範圍增加，您可以選擇從 BWT 移除單元測試。
擷取測試 - 端對端功能測試，可測試解決方案的基本功能。 如果這些失敗，則發生嚴重錯誤。 這些通常可以相對快速地執行。
功能測試 - 這些也會以端對端案例為目標，但在此案例中，它們會測試專案中的所有案例。 對於大型專案，進一步 (分類您的功能測試可能很合理，例如，讓特定元件能夠快速、可靠且隔離地進行測試) 。 當您在解決方案上登出後，應該鎖定這些功能測試，因為其功能正確。
回歸驗證測試 - 每次找到並修正解決方案 Bug 時，都應該新增回歸驗證測試案例，以確認 Bug 已修正，且不會在專案生命週期稍後重新引進。 這些測試通常是功能測試案例中未涵蓋的案例。 如果發現並修正新的 Bug，您應該預期即使解決方案上線之後，您的回歸驗證測試也會增加。
在非常大型的專案上，您可能需要讓您的 BWT 成為完整功能測試套件的子集， (，因為其執行) 所需的時間。 對於較小的專案，BVT 將會構成整個集合。 很明顯地，如果您要將 BWT 整合為每日組建的一部分，則必須自動化整個程式。 在本主題的其餘部分，我們將著重于如何使用 BizUnit 和其他工具來達成此目的。
功能測試
在 BizTalk 應用程式功能測試的內容中，測試特定的端對端案例。 執行這種類型的測試時，假設BizTalk Server您從外部觀點以功能方式測試的黑色方塊很有用。 例如，測試可能牽涉到將輸入訊息饋送至已知值 (，) 接收位置端點 (例如 URL、FTP 位置，無論您選擇的傳輸方式為何，都會) 。 接著，測試會使用在傳送端產生的正確輸出來監視正確的訊息數目。 這聽起來相當簡單。 不過，當您考慮某些案例需要輸入以特定順序和特定時間出現時，並將此專案與其他解決方案需求複合 (，例如，在 BAM) 中記錄追蹤資料時，清楚知道工具和架構可用來協調這項作業。
功能測試是設計來涵蓋您解決方案的所有可能路徑非常重要。 這不僅應包含您在生產環境中預期的案例，也包括您已實作但希望永遠不會使用的失敗路徑和例外狀況處理路徑，其中一個常用來描述此情況的片語是針對「不良日案例」進行測試。 您應該確定所有協調流程、所有允許的訊息類型，以及您的功能測試套件會執行所有程式碼分支。 下列各節說明開發正面和負面的功能測試案例，以涵蓋所有程式碼路徑。
如需在將BizTalk Server解決方案放入生產環境之前應實作之功能測試和其他測試類別的詳細資訊，請移至檢查清單：測試作業整備程度。
正面測試
請務必執行正面測試，以確保所有訊息、管線、協調流程和端點的組合都會通過解決方案，以便執行所有訊息流程。 若要確保您測試所有程式碼路徑，可能需要處理具有不同內容的不同訊息。
測試時，請使用將用於生產環境的傳輸類型。 不幸的是，在生產環境中使用其他傳輸時，功能測試只會使用檔案配接器來執行。 採用此方法是設定您和稍後失敗的整體專案。
驗證從系統送出之所有訊息的承載。 如果訊息是 XML，您應該使用 XPath 運算式來驗證訊息中的架構和索引鍵欄位。
如果) 使用，請驗證儲存在 BAM (中的任何追蹤資料;應該考慮外部資料存放庫中剩餘的任何其他資料。
如果您的解決方案使用 BRE，請測試所有商務規則引擎的執行 (BRE) 原則和規則。
負面測試
請確定您透過系統測試無效訊息的處理。 您應該先確認您選擇的策略 (在進入BizTalk Server之前拒絕它們，或) 正常運作。
測試無效訊息的處理時，請確定您已測試已實作任何接收端錯誤處理協調流程來處理暫止的訊息。
請確定您的失敗案例涵蓋協調流程中的所有例外狀況區塊。 無法充分測試此狀況是常見的問題。
如果您使用長時間執行的交易搭配補償行為，請非常小心地測試這些案例。 這是另一個區域，其中測試不足會在生產環境中產生嚴重後果。
請確定在適當的錯誤記錄檔中正確記錄失敗。
自動化是關鍵
若要有效率且有效率地執行所有作業，請先投入時間將測試自動化。 以時間和成本) 而言，手動測試相當耗時、容易出錯且成本高昂 (。 每次執行手動測試階段時，您都會新增另一批必須由專案資源處理的工作， (小組中的人員) 。 藉由預先自動化，您就能夠取得每次執行測試時開發測試所需的初始投資報酬率。 良好的功能測試應該快速且有效率地執行，而且可以重複執行;每個測試也應該是自發性 (它應該與任何其他測試無關;採用此方法可讓您循序執行多個測試作為測試套件。) 功能測試應該一律會產生相同的結果。 撰寫不佳的功能測試或撰寫不佳的程式碼會導致測試回合之間的不同測試結果，導致混淆和浪費時間調查失敗的根本原因。
請務必將撰寫每個功能測試所需的開發工作降到最低。 通常，在開發時間方面產生 () 成本愈高，您最終可能會得到的測試案例較少。 這表示您程式碼的測試涵蓋範圍較低。 藉由使用測試架構，您可以更快速且更輕鬆地開發測試案例，因此，更容易取得完整的程式碼涵蓋範圍。 最理想的測試架構會使用宣告式方法來定義測試。 (也就是說，測試的組態會儲存在組態檔中，這通常是 XML 檔案。) 使用良好的測試架構可讓您以敏捷且可靠的方式開發完整的功能測試套件，並避免必須「重新初始化滾輪」，如此說來。
BizTalk Server專案的 MSBUILD 支援
BizTalk Server支援Microsoft Build Engine (MSBUILD) 平臺，其可配合未安裝 Visual Studio 之組建實驗室環境中的 Managed 專案建置。 MSBUILD 會容納從命令列建置專案，以及進階功能，包括 MSBUILD 記錄和批次處理。 如需 MSBUILD 的詳細資訊，請參閱 MSBuild 概觀。