測試為何如此重要
本主題提供導致測試不足的思維概觀、描述無法測試 BizTalk 解決方案的相關風險，以及對比手動測試的陷阱與自動化測試的優點。
測試為「額外負荷」
可惜的是，隨著投資報酬率增加的需求 (ROI) ，專案的測試階段通常被視為可相應減少的專案計劃的第一個層面之一。
針對測試 BizTalk 解決方案的一個引數是：「我們不需要測試我們的解決方案，因為 Microsoft 已經徹底測試BizTalk Server」。 雖然 Microsoft 確實會徹底測試BizTalk Server，但不同的使用案例需要輸送量、高可用性、配接器使用方式、延遲、追蹤需求、協調流程使用方式和自訂程式碼的其中一個幾乎不計數目的排列。 因為BizTalk Server非常有彈性，而且可以容納許多不同的使用案例，所以無法預期並測試所有案例。 此外，應該優化BizTalk Server環境中套用的預設設定，以容納每個使用案例。 判斷特定使用案例的最佳設定的唯一方法是測試解決方案、測量各種參數、調整環境，以及重新測試。 請考慮下圖，其描述BizTalk Server解決方案的範例實體架構。
範例實體 BizTalk 架構
您可以在上圖中看到，BizTalk Server解決方案包含許多移動元件，包括執行BizTalk Server的多部電腦、執行SQL Server的電腦、伺服器叢集節點和 Active Directory 網域。 系統啟動並執行之後，將會套用許多設定調整，以根據業務需求優化應用程式，以最大化解決方案的整體 ROI。 這個單一案例顯示有許多變數可供使用。 除了環境的實體架構之外，請考慮下圖，其描述透過BizTalk Server的訊息流程。
範例邏輯 BizTalk 訊息流程的訊息流程
當我們查看流經BizTalk Server之訊息的邏輯圖表時，我們會看到需要個別專案測試的其他變數，包括自訂傳送和接收管線元件，以及可從 BizTalk 協調流程呼叫的自訂類別。 由於自訂群組件和 BizTalk 元件的類型複雜度和使用方式會因專案而異，因此對於每個特定使用案例執行測試會變得更明顯。
測試方法和時程表
為了確保測試有效率且有效率地執行，測試配接應該完全自動化，以便輕鬆地重現，並將人為錯誤的機會降到最低。 此外，在規劃專案時，應該配置足夠的時間進行測試。 測試的最小方法會包含類似下列的手動步驟：
手動將一或多個訊息載入接收端點，例如檔案卸載，或使用 SOAP 用戶端呼叫 Web 服務。
手動驗證訊息的正確內容和結構。 因為專案中通常會有多個架構，所以訊息可能是一般檔案和 XML 的混合，也可能包含跨欄位相依性。
注意
其中一個範例是任何涉及 SWIFT 訊息的專案。 這些是具有跨欄位相依性的一般檔案訊息。 也就是說，一個欄位的值相依于另一個 –簡單的 XSD 驗證不會在這裡執行;因此，SWIFT 加速器會使用 BizTalk 規則引擎來驗證訊息。 如需 SWIFT 加速器的詳細資訊。
手動檢查BizTalk Server電腦上的事件記錄檔是否有錯誤。
如果) 用來驗證活動資訊是否已正確記錄，請手動檢查 BAM 資料庫 (。
如上所述，使用手動程式進行測試是主旨且容易出錯。 請考慮針對 10 個不同的測試案例，檢查具有跨欄位相依性的百行 SWIFT 訊息。 大部分的專案開發人員都無法或即使它們能夠運作，也不會偏向參與這類工作可靠且正確。 實作主旨、手動、容易出錯的測試程式會增加專案的風險，並增加失敗的機會。
失敗的風險通常是由未納入足夠時間進行測試的專案規劃時程表所放大。 太常，專案測試策略會依排定一周或一周之前排程的單一手動測試階段來決定。 這類有限的測試會讓專案有風險。 假設有這類有限的時間軸可供測試，如果偵測到任何問題，則專案可能會延遲，因為未配置任何時間來修正問題。 此外，如果發現並修正問題，在系統上線之前，可能沒有足夠的時間執行後續的測試通過。
「單一最終建置、單一測試通過、即時進行專案」測試是它通常會導致專案延遲、專案超過預算，甚至更糟，專案完全失敗！ 對於任務關鍵性系統，這種測試方法是等候發生的災害。
有效且有效率地測試
因為適當的測試通常會被視為昂貴的昂貴需求，而不是不可或缺的需求，所以通常會在專案的尾端加總。 由於異質企業環境中所使用的軟體和硬體堆疊複雜度，這種方法就不切實際。 您可以視需要重新執行自動化測試方法，是有效且有效率地測試的最佳方法，而且是成功專案不可或缺的一部分，最終可為企業提供絕佳的 ROI。 透過透過您正在產生測試資產的每個程式碼路徑，投資專案開頭的完整端對端功能測試。 這些資產需要投資 (，也就是開發時間) ，以便日後獲得提升測試效率與效率的優點。 若要將專案所需的投資降到最低，以衍生這類架構，我們建議您使用 Visual Studio 2010 負載測試架構。 Visual Studio 2010 包含成功測試所需的大部分常見測試步驟，而且是本指南稍後所說明的測試案例中使用的架構。