您可以使用需求及架構模型來協助您組織系統及其元件的測試。 此做法有助於確保您測試對使用者和其他利害關係人很重要的需求，並協助您在需求變更時快速更新測試。 如果您使用 Microsoft 測試管理員，您也可以維護模型與測試之間的連結。
若要查看哪些版本的 Visual Studio 支援這些功能，請參閱 架構和模型化工具的版本支援。
系統和子系統測試
系統測試， 也稱為 驗收測試，是指測試使用者的需求是否得到滿足。 此類測試關注的是系統的外部可見行為，而不是內部設計。
在擴展或重新設計系統時，系統測試非常有價值。 它們可協助您避免在變更程式碼時引入錯誤。
當您規劃系統的任何變更或延伸時，從在現有系統上執行的一組系統測試開始會很有幫助。 然後，您可以擴充或調整測試以測試新需求、變更程式碼，以及重新執行完整的測試集。
當您開發新系統時，您可以在開發開始時立即開始建立測試。 透過在開發每一個特性之前定義測試，您可以以非常特定的方式擷取需求討論。
子系統測試將相同的原則應用於系統的主要組件。 每個組件都與其他組件分開測試。 子系統測試著重於元件使用者介面或 API 上可見的行為。
從需求模型衍生系統測試
您可以建立及維護系統測試與需求模型之間的關係。 若要建立此關係，您可以撰寫對應至需求模型主要元素的測試。 Visual Studio 可讓您在測試與模型各部分之間建立連結，以協助您維護該關聯性。 如需需求模型的詳細資訊，請參閱 模型使用者需求。
針對每個使用案例撰寫測試
如果您使用 Microsoft Test Manager，您可以針對您在需求模型中定義的每個使用案例建立一組測試。 例如，如果您有「訂購餐點」使用案例，其中包括「建立訂單」和「將項目新增至訂單」，您可以為這些使用案例的整體和更詳細的使用案例建立測試。
這些指導方針可能會有所幫助：
每個使用案例都應該有數個測試，以取得主要路徑和特殊結果。
當您在需求模型中描述使用案例時，定義其後置條件 （即已達成的目標） 比詳細描述使用者為達成目標而遵循的程序更重要。 例如，「訂購餐點」的後置條件可能是餐廳正在為顧客準備餐點，且顧客已付款。 後置條件是您的測試應驗證的準則。
根據後置條件的單獨子句進行單獨的測試。 例如，建立個別的測試，以通知餐廳訂單，以及向顧客收取付款。 這種分離具有以下優點：
需求不同方面的變化經常獨立發生。 透過以這種方式將測試分成不同的層面，您可以在需求變更時更輕鬆地更新測試。
如果開發計劃在其他部分之前先實施使用案例的一個方面，您可以隨著開發的進展逐步地啟用測試。
當您設計測試時，請將測試資料的選擇與決定是否已達成後置條件的程式碼或指令碼分開。 例如，簡單算術函數的測試可能是：輸入 4;驗證輸出是否為2。 相反地，將腳本設計為：選擇輸入;將輸出乘以本身，並驗證結果是否為原始輸入。 此樣式可讓您改變測試輸入，而不變更測試的主體。
將測試連結至使用案例
如果您使用測試管理員來設計和執行測試，您可以在需求、使用案例或使用者劇本工作專案下組織測試。 您可以將這些工作項目連結至模型中的使用案例。 這可讓您快速追蹤測試的需求變更，並協助您追蹤每個使用案例的進度。
將測試連結至使用案例
在 Test Manager 中，建立需求，並以此為基礎建立測試套件。
您建立的需求是 Team Foundation Server 中的一項工作專案。 它可能是使用者劇本、需求或使用案例工作專案，視您的專案搭配 Team Foundation 使用的程序範本而定。 如需詳細資訊，請參閱 關於敏捷式工具 和 敏捷式專案管理。
將需求工作專案連結至模型中的一或多個使用案例。
在使用案例圖表中，用滑鼠右鍵按一下使用案例，然後按一下 連結至工作項目。
將驗證使用案例的測試案例新增至測試套件。
通常，每個使用者劇本或需求工作專案都會連結至模型中的數個使用案例，而每個使用案例都會連結至數個使用者劇本或需求。 這是因為每個使用者劇本或需求都涵蓋一組開發數個使用案例的任務。 例如，在專案的早期迭代中，您可以開發基本使用案例，讓客戶能夠從產品目錄中選擇物品並安排配送。 在後面的迭代中，故事可能是使用者在完成訂單時付款，供應商在發送貨物後收到款項。 每個故事都會將子句新增至「訂購商品」使用案例的後置條件。
您可以建立從需求到後置條件子句的個別連結，方法是在使用案例圖上的個別註解中撰寫這些子句。 您可以將每一個註解鏈結至需求工作項目，並將註解鏈結至圖表上的使用案例。
需求類型的基礎測試
需求模型的類型，即類別、介面和列舉，會根據使用者如何思考及溝通其業務來描述概念和關係。 它不包括僅與系統內部設計有關的類型。
根據這些需求類型來設計您的測試。 此作法可協助您確保在討論需求的變更時，很容易將變更與測試中的必要變更相關聯。 它使得直接與最終用戶和其他利益相關者討論測試及其預期結果成為可能。 這意味著使用者的需求可以在開發過程之外得到維護，並避免基於設計中可能存在的缺陷無意中設計測試。
對於手動測試，此做法涉及遵守測試腳本中需求模型的詞彙。 對於自動化測試，此作法涉及使用需求類別圖作為測試程式碼的基礎，以及建立存取程式和更新程式函式，以將需求模型連結至程式碼。
例如，需求模型可能包括類型 Menu、Menu Item、Order 以及它們之間的關聯。 該模型代表訂餐系統存儲和處理的信息，但並不代表其實現的複雜性。 在工作系統中，在資料庫、使用者介面和 API 中，每種類型可能有數個不同的實現。 在分散式系統中，每個實例的數個變體可能同時儲存在系統的不同部分。
若要測試使用案例，例如「將項目新增至訂單」，測試方法可以包含類似下列的程式碼：
Order order = ... ; // set up an order
// Store prior state:
int countBefore = order.MenuItems.Count;
// Perform use case:
MenuItem chosenItem = ...; // choose an item
AddItemToOrder (chosenItem, order);
// Verify part of postcondition:
int countAfter = order.MenuItems.Count;
Assert (countAfter == countBefore = 1);
請注意，此測試方法使用需求模型的類別。 關聯和屬性會以 .NET 屬性的形式實現。
為了使這項工作正常運作，類別的屬性必須定義為唯讀函式或存取子，從系統中擷取其目前狀態的相關資訊。 模擬使用案例的方法 （例如 AddItemToOrder） 必須透過其 API 或透過其使用者介面下方的層來驅動系統。 測試物件的建構函式，例如 Order 和 MenuItem，必須驅動系統在系統內建立對應的項目。
許多存取器和更新程式已經可以透過應用程式的一般 API 使用。 但可能必須撰寫一些額外的函式才能啟用測試。 這些額外的存取器和更新器有時稱為「測試工具」。 因為它們依賴於系統的內部設計，所以系統開發人員有責任提供它們，而測試人員則根據需求模型編寫測試的程式碼。
當您撰寫自動化測試時，您可以使用泛型測試來包裝存取程式和更新程式。
商業規則測試
某些需求與任何一個用例沒有直接關係。 例如，DinnerNow 業務允許客戶從多個菜單中進行選擇，但要求在每個訂單中，所有選擇的項目都應來自一個菜單。 此商務規則可以表示為需求類別模型中訂單、功能表和項目之間關聯的不變量。
這類不變規則不僅會控管目前定義的所有使用案例，也會控管稍後將定義的任何其他使用案例。 因此，將其與任何用例分開編寫，並與用例分開進行測試非常有用。
從模型衍生子系統測試
在大型系統的高階設計中，您可以識別元件或子系統。 這些代表可以單獨設計的部分，或位於不同電腦上的部分，或是可以透過多種方式重新組合的可重複使用的模組。
您可以將與整個系統相同的原則應用於每個主要組件。 在大型專案中，每個元件都可以有自己的需求模型。 在較小的專案中，可以建立架構模型或高階設計來顯示主要元件及其互動。 如需詳細資訊，請參閱 建立應用程式架構模型。
在任一情況下，您可以在模型元素與子系統測試之間建立關係，其方式與需求模型與系統測試之間的關係相同。
隔離具有提供和需求介面的元件
識別元件對系統其他部分或外部服務的所有相依性，並將這些表示為「必要介面」會很有用。 此練習通常會導致一些重新設計的過程，這使得元件更加解耦，並且更容易與設計的其他部分分離。
這種解耦的一個優點是，可以透過將它通常使用的服務替換為模擬物件來執行元件進行測試。 這些是為測試目的而設置的組件。 模擬元件提供所需的介面，並以模擬的資料回應查詢。 模擬元件是完整測試工具的一部分，您可以將其連接至元件的所有介面。
模擬測試的一個好處是，您可以在其將使用其服務的其他元件仍在開發中時開發您的元件。
維護測試與模型之間的關聯性
在每隔幾週執行一次疊代的一般專案中，會在每次疊代開始時進行需求檢閱。 會議討論了將在下一次迭代中交付的功能。 需求模型可用來協助討論將要開發的動作概念、案例和順序。 業務利益相關者設定優先級，開發人員進行估計，測試人員確保正確捕獲每個功能的預期行為。
編寫測試是定義需求的最有效方法，也是確保一個人清楚地了解需要什麼的有效方法。 然而，雖然在規格研討會期間編寫測試需要很長時間，但創建模型可以更快地完成。
從測試的角度來看，需求模型可以看作是測試的簡寫。 因此，在整個專案中維護測試和模型之間的關係非常重要。
將測試案例附加至模型元素
如果您的專案使用測試管理員，您可以將測試連結至模型中的元素。 這可讓您快速找到受需求變更影響的測試，並協助您追蹤需求已實現的程度。
您可以將測試連結至各種元素。 以下是一些範例：
將使用案例與針對它進行的測試連結起來。
將使用案例的後置條件或目標的條款寫入相關的註解中，然後將每個註解與測試連結起來。
在類別圖或活動圖的註解中編寫不變規則，並將它們連結到測試。
將測試連結至活動圖表或個別活動。
將測試套件連結至其測試的元件或子系統。
將測試連結至模型元素或關聯性
在 Test Manager 中，建立需求，並以此為基礎建立測試套件。
您建立的需求是 Team Foundation Server 中的一項工作專案。 它可能是使用者劇本、需求或使用案例工作專案，視您的專案搭配 Team Foundation 使用的程序範本而定。 如需詳細資訊，請參閱 關於敏捷式工具 和 敏捷式專案管理。
將需求工作專案連結至模型中的一或多個元素。
在模型圖表中，以滑鼠右鍵按一下元素、註解或關聯性，然後按一下 [連結至工作專案]。
將驗證模型元素中表達的需求的測試用例添加到測試套件中。