從模型開發測試
在 Microsoft Visual Studio Ultimate 中，可以使用需求和架構模型，以協助您組織整理系統及其元件的測試。 這種作法可協助您確保測試對於使用者和其他專案關係人來說非常重要的需求，並可協助您在需求變更時快速更新測試。 如果您使用 Microsoft 測試管理員，則您也可以維護模型與測試之間的連結。
系統和子系統測試
「系統測試」(System Testing) 也稱為「接受度測試」(Acceptance Testing)，表示測試是否符合使用者的需求。 此類測試主要是關於系統的外部可見行為，而不是內部設計。
在擴充或重新設計系統時，系統測試是非常有幫助的。 它們可協助您避免在變更程式碼時引入 Bug。
當計劃對系統進行任何變更或擴充時，先在現有系統上執行一組系統測試非常有用。 然後，您可以擴充或調整測試來測試新的需求、變更程式碼，然後重新執行完整的一組測試。
開發新系統時，您可以在開始開發時就立即建立測試。 透過在開發每個功能之前先定義測試，您可以使用相當特定的方式來擷取需求討論。
子系統測試套用與系統主要元件相同的準則。 每個元件都是與其他元件分開進行測試。 子系統測試的重點在於元件使用者介面或 API 上的可見行為。
如需如何執行測試的詳細資訊，請參閱 測試應用程式。
從需求模型衍生系統測試
您可以建立並維護系統測試與需求模型之間的關聯性。 若要建立此關聯性，您可以撰寫與需求模型的主要項目對應的測試。 Visual Studio Ultimate 可讓您在模型的測試與組件之間建立連結，以保有該關聯性。 如需需求模型的詳細資訊，請參閱模型化使用者要求。
對每個使用案例撰寫測試
如果使用 Microsoft 測試管理員，則您可以對在需求模型中定義的每個使用案例，建立一組測試。 例如，如果擁有「訂購餐點」使用案例，其中包含「建立訂單」和「將項目加入訂單」，則您可以同時建立這些使用案例的整體和細節測試。 如需使用案例的詳細資訊，請參閱 UML 使用案例圖表：方針。
下面是一些有用的方針：
每個使用案例都應具有數個測試，用於主要路徑和例外結果。
描述需求模型中的使用案例時，需要定義其後置條件 (亦即要達到目標)，這要比詳細描述程序，讓使用者遵循以達成目標更為重要。 例如，「訂購餐點」的後置條件可能是「餐廳」為「客戶」準備餐點，以及「客戶」付款。 後置條件是測試應該驗證的準則。
不同的測試要以後置條件的不同子句為基礎。 例如，針對通知餐廳訂單以及取得客戶付款建立不同的測試。 這樣區分具有下列好處：
需求的不同方面經常會個別發生變更。 使用這種方式將測試分為不同的方面，更易於在需求變更時更新測試。
如果開發計劃先實作使用案例的一個方面，然後再實作另一個方面，則您可以在開發進行的過程中，分別啟用相關測試。
設計測試時，將測試資料的選擇與判斷是否滿足後置條件的程式碼或指令碼分開。 例如，簡式算術函式的測試可能是：輸入 4，驗證輸出是 2。 然而，指令碼的設計卻是：選擇輸入，將輸出與自己相乘，然後驗證結果是原始輸入。 這種設計方法可讓您在測試時改變測試輸入，而無需變更測試的主體。
將測試連結至使用案例
如果使用 測試管理員 來設計和執行測試，則您可以在需求、使用案例或使用者本文工作項目下組織整理測試。 您可以將這些工作項目連結至模型中的使用案例。 這可讓您快速追蹤測試的需求變更，並協助您追蹤每個使用案例的進度。
若要將測試連結至使用案例
在 測試管理員 中，建立需求，並以該需求為基礎建立測試套件。 若要了解如何進行，請參閱使用需求或使用者本文建立測試計劃。
您建立的需求是 Team Foundation Server 中的工作項目。 該工作項目可能是「使用者本文」、「需求」或「使用案例」，視專案與 Team Foundation 使用的流程範本而定。 如需詳細資訊，請參閱計劃和追蹤專案。
將需求工作項目連結至模型中的一個或多個使用案例。
在使用案例圖表中，以滑鼠右鍵按一下使用案例，然後按一下 [連結至工作項目]。 如需詳細資訊，請參閱 HOW TO：從模型項目連結至工作項目。
加入至驗證使用案例的測試套件、測試案例。
通常，每個使用者本文或需求工作項目都會連結至模型中的數個使用案例，而每個使用案例都將連結至數個使用者本文或需求。 這是因為每個使用者本文或需求都涵蓋可以開發數個使用案例的工作集。 例如，在專案的早期反覆項目中，您可能會開發基本使用者本文，客戶可以在其中選擇目錄中的項目，並交付這些項目。 在後期的反覆項目中，本文可能是使用者在完成訂單時進行付款，以及供應商在送貨之後收款。 每個本文都會將子句加入「訂購貨物」使用案例的後置條件。
您可以建立從需求至後置條件子句的個別連結，方法是在使用案例圖表上以個別註解的方式撰寫這些子句。 您可以將每個註解連結至需求工作項目，並將註解連結至圖表上的使用案例。
需求型別上的基礎測試
需求模型的型別 (即類別、介面和列舉) 會就使用者考量和討論其業務的方式來描述概念和關聯性。 它排除只與系統的內部設計相關的型別。
依據這些需求型別來設計測試。 這種作法可協助您確保在討論需求變更時，可以輕鬆地將變更與向測試中的必要變更加以關聯。 通過這種作法，還可以直接與使用者和其他專案關係人討論測試和想要的結果。 這表示可在開發流程之外維護使用者的需求，並避免可能的設計缺陷而造成不當的測試設計。
對於手動測試，這種作法涉及遵守測試指令碼中需求模型的詞彙。 對於自動測試，這種作法涉及使用需求類別圖表做為測試程式碼的基礎，並建立存取子和更新程式函式，以將需求模型連結至程式碼。
例如，需求模型可能包括「菜單」、「菜單項目」、「訂單」型別以及它們之間的關聯。 此模型代表餐點訂購系統所儲存和處理的資訊，而不代表實作的複雜度。 在工作系統中，資料庫、使用者介面和 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 屬性。
若要讓這個方法順利運作，類別的屬性必須定義為唯讀函式或存取子，其可存取系統以擷取目前狀態的資訊。 模擬諸如「將項目加入訂單」的使用案例的方法，必須透過其 API 或使用者介面之下的一層來驅動系統。 諸如「訂單」和「菜單項目」等測試物件的建構函式，也必須驅動系統以在系統內建立對應的項目。
透過應用程式的正常 API，可使用許多存取子和更新程式， 但還必須撰寫部分其他函式，才能啟用測試。 這些其他存取子和更新程式有時稱為「測試檢測」。 因為它們依賴系統的內部設計，所以必須由系統開發人員負責提供，而測試人員則是以需求模型的角度來撰寫測試的程式碼。
撰寫自動測試時，可以使用「一般測試」來包裝存取子和更新程式。 如需詳細資訊，請參閱建立會使用一般測試執行可執行檔的自動化測試。
商務規則的測試
部分需求不會直接與任何一個使用案例相關。 例如，「立即進餐」商務可讓客戶從許多「菜單」中進行選擇，但需要在每個「訂單」中，所有選擇「項目」都應來自單一「菜單」。 在需求類別模型中，這個商務規則可表示為「訂單」、「菜單」和「項目」之間關聯的非變異。
此類非變異規則不僅管理目前定義的所有使用案例，也包括稍後要定義的任何其他使用案例。 因此，使用與其他任何使用案例分開的方式撰寫它，並使用與使用案例分開的方式測試它非常有用。
您可以將非變異商務規則撰寫為類別圖表中的註解。 如需詳細資訊，請參閱 UML 類別圖表：方針。
您可以將註解連結至需求或使用者本文工作項目，以連結至 測試管理員 中的測試套件，將測試連結至商務規則。 如需詳細資訊，請參閱將測試案例附加至模型項目。
效能和其他服務需求品質可以在使用案例圖表、活動圖表或順序圖表的註解中進行說明。 您也可將這些項目連結至需求工作項目及其測試套件。
測試的順序圖表和活動圖表
如果需求或架構模型包括順序圖表或活動圖表，則您可以直接撰寫遵循圖表的測試。
設計可透過圖表中的分支和迴圈來動態選擇不同路徑的測試，有時非常有用。
嘗試在每則訊息或每個動作之後，驗證系統的狀態。 這可能需要其他檢測。
從模型衍生子系統測試
在大型系統的高階設計中，可以識別元件或子系統。 這些項目代表可以分別設計的部分、位於不同電腦上的部分，或可以使用許多方式來重新合併的可重複使用模組。 如需詳細資訊，請參閱 UML 元件圖表：方針。
您可以針對每個主要元件，套用與完整系統所用相同的準則。 在大型專案中，每個元件可以具有自己的需求模型。 在較小型專案中，可以建立架構模型或高階設計，以顯示主要元件及其互動。 如需詳細資訊，請參閱模型化軟體系統的架構。
在任一情況下，您都可以使用與建立需求模型與系統測試之間關聯性的相同方式，來建立模型項目與子系統測試之間的關聯性。
使用提供的所需介面來隔離元件
識別系統其他部分或外部服務上元件的所有相依性，並將這些相依性表示為「所需的介面」非常有用。 使用這種作法，通常需要進行部分重新設計，以進一步解除元件的結合，以便可從設計的其餘部分相分離。
這個解除結合的優點是藉由利用模擬物件取代服務經常使用的元件，以執行該元件並用於測試。 這些都是爲了測試目的而設定的元件。 模擬元件提供元件所需的介面，使用模擬的資料來回應查詢。 模擬元件組成完整測試控管的一部分，您可以將該測試控管連接至元件的所有介面中。
模擬測試的好處是，即使您正在開發之元件所要使用的服務來自其他尚未開發完成的元件，您仍可以先開發該元件。
維護測試與模型之間的關聯性
在每隔數週就會執行反覆項目的典型專案中，會在每次反覆項目要開始時進行需求檢閱。 會議會討論在下一個反覆項目中要發佈的功能。 需求模型可以用來協助討論要開發動作的概念、案例和順序。 商務專案關係人設定優先順序，開發人員進行評估，而測試人員確保正確擷取每個功能的預期行為。
撰寫測試是定義需求最有效的方式，也是確保人員清楚了解所需內容的有效方式。 然而，在對規格進行研討期間，撰寫測試需要太長的時間，而建立模型則會快很多。
從測試的視點來看，需求模型可以看做是測試的簡略表示法。 因此，在整個專案中，維護測試與模型之間的關聯性非常重要。
將測試案例附加至模型項目
如果專案使用 測試管理員，則您可以將測試連結至模型中的項目。 這樣可讓您快速找到需求中的變更所影響的測試，並可協助您將範圍追蹤至已實現需求的測試。
您可以將測試連結至所有類型的項目。 以下是一些範例：
將使用案例連結至使用它的測試。
在連結至使用案例的註解上，撰寫使用案例後置條件 (或目標) 的子句，然後將測試連結至每個註解。
在類別圖表或活動圖表上的註解中撰寫非變異規則，並將它們連結至測試。
將測試連結至活動圖表，或連結至個別活動。
將測試套件連結至其測試的元件或子系統。
若要將測試連結至模型項目或關聯性
在 測試管理員 中，建立需求，並以該需求為基礎建立測試套件。 若要了解如何進行，請參閱使用需求或使用者本文建立測試計劃。
您建立的需求是 Team Foundation Server 中的工作項目。 該工作項目可能是「使用者本文」、「需求」或「使用案例」，視專案與 Team Foundation 使用的流程範本而定。 如需詳細資訊，請參閱計劃和追蹤專案。
將需求工作項目連結至模型中的一個或多個項目。
在模型圖表中，以滑鼠右鍵按一下項目、註解或關聯性，然後按一下 [連結至工作項目]。 如需詳細資訊，請參閱 HOW TO：從模型項目連結至工作項目。
加入至用來驗證模型項目中敘述的需求的測試套件、測試案例中。