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