及早並經常測試
要確保軟體品質，盡早發現缺失是最經濟的方式。 Kent Beck 和 Cynthia Andres 曾經寫道：「軟體開發的兩難如下：雖然缺失的成本高昂，但是排除缺失的成本也很高昂。 不過，大部分缺失最後產生的成本會超過防範缺失的成本」(說明的極限程式設計:已變更。) 最佳做法和工具可協助您的小組可以維護專案的品質最小化防止和修正缺失的成本在其生命週期。
如果您逐步發現缺失、修正缺失及驗證修正，您的小組將可更精確地隨時評估專案的品質。 經常執行測試可讓您的小組和專案關係人隨時掌握程式碼的目前狀態，以及專案中的各項決策。 最後，您應該能夠回答「能否發行？」這個問題，並了解軟體使用者的意向。
本主題建議您執行下列作業：
為每個類別以及每個主要元件的 API 建立一組自動化單元測試。 撰寫單元測試一般約需耗費小組成員 40% 的時間。 如需詳細資訊，請參閱使用 Microsoft Test Manager 建立自動化測試。
建立每個使用者劇本的測試。 這些測試最好以自動化的方式進行。 如需詳細資訊，請參閱為產品待處理項目、使用者劇本或需求建立測試。
建立簽入原則，以提醒小組成員在簽入程式碼前執行單元測試。 如需詳細資訊，請參閱Add Check-in Policies。
設定會執行完整測試集的連續或夜間組建。
監視測試涵蓋範圍，以確保您所有的程式碼均受到測試。 涵蓋範圍至少應達 70%。 如需詳細資訊，請參閱測試間距 Excel 報表 (Agile)。
在每次衝刺 (Sprint) 即將結束時執行手動測試。
您的小組可以使用 Microsoft Test Manager、Visual Studio Application Lifecycle Management (ALM) 與 Visual Studio Team Foundation Server 間的整合功能，及早在專案中管理並調整這些測試活動。 如需詳細資訊，請參閱測試應用程式。
本主題內容
測試策略
測試計劃
接受度測試
單元測試
測試驅動式開發和及早測試
手動與自動化測試的比較
回報測試結果
測試策略
小組的測試成功與否取決於許多因素，包括小組的大小、小組的方法，以及小組的管理工具。 您可以使用敏捷式方法持續改善測試結果。 只要套用這種方法，您不僅能使用非常有限的資源開始進行測試，還能在整個專案進行期間視需要調整作法。
.gif "Ee330950.collapse_all(zh-tw,VS.110).gif")
引入敏捷式測試時應考量的事項
將敏捷式測試引入現有的應用程式時，您的小組首先可同時考量衝刺 (Sprint) 層級和專案層級上的測試策略。 在衝刺 (Sprint) 層級上，您可以加入一組接受度測試，以便涵蓋目前衝刺 (Sprint) 的每個使用者劇本。 在專案層級中，您可以設定跨越整個專案的測試，例如端對端測試。 如果您想要驗證跨越兩個或多個衝刺 (Sprint) 的功能，這種作法就很有用。 當小組在衝刺 (Sprint) 期間建置程式碼時，您可以建立所有測試種類。 這些測試包括單元測試、接受度測試和非功能測試，例如效能測試、安全性測試和可用性測試。
若要套用敏捷測試方法，您應該先考慮應用程式的記錄以及小組所使用的系統。 您可以將敏捷測試方法同時套用至新的以及現有的應用程式。 您可以使用 Microsoft Test Manager來建立整個專案的測試計劃以及專案中每個衝刺 (Sprint) 的測試計劃。 這些測試計劃可讓您的小組將測試案例組織成測試套件，以便協助小組排定執行測試的優先權並了解測試結果。 如需詳細資訊，請參閱為產品待處理項目、使用者劇本或需求建立測試。 您的小組可以使用 Visual Studio ALM，並透過許多方法，將測試案例分組成測試套件：
建立和管理測試案例的靜態群組。
使用查詢來建立和管理測試案例的動態群組 (亦即，根據優先權尋找測試案例)。
將使用者劇本或需求加入至測試計劃，其中測試案例具有需求的連結。
從另一個測試計劃複製現有的測試套件。
如需詳細資訊，請參閱使用測試套件組織測試案例。
其次，您必須考量程式碼的測試能力。 若要了解這點，您必須先了解應用程式的架構和模式。 如果您使用模型檢視控制器 (MVC)、模型檢視 ViewModel (MVVM) 或模型檢視展示器 (MVP) 等模式，就可以隔離特定功能並執行功能測試，避免使用者介面測試的負面影響。 不過，實際的情況未必如此。 例如，您無法隔離應用程式重構部分的功能，而且您只能透過使用者介面或網路事件處理常式存取特定程式碼區域。 如果您想大幅改善測試品質，即必須提升可測試程式碼的百分比。 如需這些模式的詳細資訊，請參閱 ASP.NET Model View Controller (MVC)。
再者，您必須在實作敏捷式測試前考量小組的能力。 當您實作功能時，某些小組成員應該能夠建立單元測試。 如果某些小組成員熟悉應用程式的商務規則，他們應該能夠建立和定義手動使用案例和工作流程測試。 此外，如果其他小組成員擁有必要的技術能力，他們應該能夠建立根據這些手動測試建立自動化且更詳細的測試。
如何管理測試生命週期
測試是整個專案進行期間的反覆流程。 請參閱下列步驟：
釐清測試目標，並確定您整個小組都同意這些目標。 根據這些目標，決定您的測試策略。 例如，您的策略可以是「在每次簽入之前執行測試、單元測試的程式碼涵蓋範圍將是 70%，且每個使用者劇本至少將有一個自動化測試」。
根據目前衝刺 (Sprint) 的專案使用者劇本、設計假設和非功能需求，定義您的測試計劃。
- 您可以將使用者劇本加入至待處理項目，並針對未來的衝刺 (Sprint) 計劃它們。 您應該讓每個測試計劃至少符合一個衝刺 (Sprint)，因此應該針對衝刺 (Sprint) 中的所有使用者劇本設定測試案例。
定義並建置測試案例，例如接受度測試、單元測試、功能測試和效能測試。
將測試案例分組成測試套件。 您可以將這些測試套件納入已定義的測試計劃，以便協助引導測試工作。
在整個衝刺 (Sprint) 進行期間，重複執行測試套件和內含的測試案例。 開始在衝刺 (Sprint) 中及早執行測試，並且繼續將測試案例加入至測試套件。 如果您想要識別重要的測試條件和情況，就可以套用探勘測試並且經常在小組內部進行交談。
在您將使用者劇本接受度測試的狀態設為完成之前，先確定所有此類測試皆已通過。
.png "反覆的測試週期")
雖然工作流程可能會因軟體的解析而更複雜，不過上圖擷取了主要元件之間的基本工作流程。
程式碼會產生組建。
程式碼會受到已定義工作、測試計劃和組建的品質所影響。
測試計劃、測試套件和測試案例會受到計劃的目標和上圖沒有顯示的其他專案層面所影響。
程式碼的變更可能會影響測試案例。
修正 Bug
您必須盡早處理 Bug。 嚴重 Bug 是指導致使用者劇本未完成的 Bug。
針對透過測試或其他活動而發現的 Bug，建立 Bug 工作項目。 設定 Bug 的嚴重性，以指出 Bug 對使用者劇本的影響程度。 高嚴重性 (如 0 或 1) 表示重要使用者劇本未執行，或使用者必須執行繁複的解決方法才能完成劇本。 低嚴重性 (如 3) 表示使用者仍可達成其主要目標，而無須執行額外的工作。
與其他小組成員一起決定每個 Bug 的措施計劃。
修正 Bug 之後，請立即加以解決。 Bug 應指派給其他人進行驗證。 請盡快驗證並關閉 Bug。
追蹤 Bug 的狀態。 在每個反覆項目執行尾聲進行追溯性會議時，請查看 [Bug 趨勢] 報表，並討論任何異常增量的原因。 如需詳細資訊，請參閱Bug 趨勢報表。
測試計劃
測試計劃是協助小組了解專案全貌的流程以及讓小組準備進行所有測試種類的流程。 敏捷測試會從衝刺 (Sprint) 層級開始。 在每個衝刺 (Sprint) 中，您的小組都會測試以驗證該衝刺 (Sprint) 中所建置的使用者劇本。 目前與舊有的衝刺 (Sprint) 中所建立的測試，小組都會執行。 在整個專案進程中，可能會建置涵蓋所有功能的大量測試。 下圖顯示您專案中測試計劃的範本。
.png "主要測試計劃")
為每個衝刺 (Sprint) 與專案建立一個測試計劃
您的小組可以使用 Visual Studio ALM 的測試功能，以累加方式計劃、組織、執行和回報測試。 您的小組可以建立測試計劃的範本，而且小組成員可以填入測試套件。 在測試計劃中，您的小組可以識別應該使用自動化或手動測試案例的位置。
您可以開始針對專案中的每個衝刺 (Sprint) 建立測試計劃。 您的小組可以使用這個計劃，將焦點放在驗證目前衝刺 (Sprint) 中的功能上。 雖然此計劃一開始是空的，不過您可以將它當做測試套件的預留位置使用。 然後，您可以將測試案例組織成適當的測試套件。 如果您想要取得專案關係人的及時回應，就應該在整個衝刺 (Sprint) 進行期間及早建立這些測試案例。
您也可以建立涵蓋整個專案的測試計劃。 您可以使用專案測試計劃來合併先前衝刺 (Sprint) 的測試，並且組織適用於整個專案的測試套件。 您應該繼續執行回復測試套件，因為當您的小組建置大型專案時，維持穩定性和流程是很重要的。 尤其是，如果您與分散各地的大型小組一起工作，回復測試套件就可以攔截以具有串聯影響之變更為基礎的錯誤。 如果沒有採取正確的措施，這些錯誤會非常難以攔截而且可能會在週期後期或交付之後才攔截到。
某些小組可能會想要定義跨越整個專案的測試計劃。 這些測試計劃種類可能會驗證許多衝刺 (Sprint) 中的相關功能，而且包含在整個專案進行期間執行的測試套件。 例如，只有當整個功能都已完整時，您才能測試橫跨衝刺 (Sprint) 之使用者劇本的功能。
在衝刺 (Sprint) 之前定義接受度測試
您應該在衝刺 (Sprint) 之前建置接受度測試。 這些接受度測試可協助您判斷使用者劇本是否完整。 如果您在每個衝刺 (Sprint) 的測試計劃中建立名為「接受度測試」的測試套件，就可以追蹤接受度測試案例。 如需詳細資訊，請參閱本主題後面的接受度測試。
在衝刺 (Sprint) 期間建置單元測試
您的小組應該在衝刺 (Sprint) 期間建置單元測試。 單元測試可以驗證程式碼效能，例如用來執行程式碼的時間和資源成本。 此外，您也應該建置其他測試類型，例如非功能測試 (亦即，效能測試和安全性測試)，並將它們加入至適當的測試套件。 您應該組織可輕易地識別其成本的測試套件。
測試應著重於高度使用的領域
了解軟體中存在高度變化性的位置就會決定作用區可能存在的位置。 輸入者輸入、執行軟體的環境、網路和硬體都是組態變數的範例，可讓您的小組在軟體中尋找作用區。 如果某個狀況很少發生，或者測試期間可能會發生的狀況數目不明確，則測試的價值就會降低，除非缺失的潛在影響非常大。 一般而言，您應該盡可能隔離功能。 高度影響的測試情況也很重要。 如需如何使用 Microsoft Test Manager管理組態的詳細資訊，請參閱測試組態 - 指定測試平台。
若為現有的專案，請監視缺失數目最高的區域，並且判斷存在缺失的原因。 此外，請監視程式碼變換，因為這個區域可能會忽略基礎假設。 存在程式碼缺失的部分原因包括難以管理狀態 (例如網路和使用者介面) 以及程式碼。
接受度測試
接受度測試會驗證使用者劇本。 這些測試不僅能在整個專案生命週期內確保您順利建置客戶所需要的項目，還能建置與客戶之間的信任並顯示您所接受的責任。 如需詳細資訊，請參閱下列網頁：接受度測試工程指南 (英文)。
如何開始使用接受度測試
開啟 Microsoft Test Manager，然後在測試計劃中建立名為「接受度測試」的測試套件。 您的小組應該會群組每個衝刺 (Sprint) 的接受度測試至少有一個測試套件。如需詳細資訊，請參閱定義測試計劃。
從手動測試移轉至自動化測試
相較於自動化測試，手動測試較易於定義，但執行成本較高。 因此，一開始先採用手動測試，然後逐步將較重要的測試改為自動化測試，是不錯的策略。
首先，開始建置一組手動測試案例，以便驗證已經針對衝刺 (Sprint) 所定義的每個使用者劇本。 因為衝刺 (Sprint) 一開始沒有任何程式碼，所以測試案例應該概述對應至使用者劇本各部分的高階動作。 例如，測試案例中的某個步驟可能是「身為經過驗證的使用者，必須...」。從手動測試案例開始可讓您的小組在衝刺 (Sprint) 開始之前快速定義理想的接受度測試。
其次，當您的小組擁有在衝刺 (Sprint) 中實作使用者劇本的程式碼時，請修訂並更新接受度測試來反映特定使用者經驗。 不過，如果您的小組不想要修改現有的接受度測試集，您也可以將這些測試匯入新的測試套件，然後將它當做更詳細測試的起點。 例如，更詳細測試案例中的某個步驟可能是「在 [使用者名稱] 文字方塊中輸入名稱，然後按一下 [登入] 按鈕來登入銀行帳戶」。
第三，根據您的接受度測試，使用動作記錄來建立自動程式碼使用者介面 (UI) 測試。 如需詳細資訊，請參閱從現有的動作記錄產生自動程式碼 UI 測試。 如果您建立了隔離功能的步驟，自動程式碼 UI 測試就可以產生更簡潔的程式碼。 如果您將自動程式碼 UI 測試附加至手動測試案例，就可以根據測試計劃執行自動化測試 (如需詳細資訊，請參閱 HOW TO：使自動化測試與測試案例產生關聯)。
在衝刺 (Sprint) 一開始定義的手動測試可以協助您建立自動化測試。 手動和自動化測試都具有成本，因為手動測試需要由人員執行，而自動化測試需要進行更新 (如果程式碼或使用者經驗變更的話)。 如需詳細資訊，請參閱本主題後面的手動與自動化測試的比較。
執行接受度測試案例的人員是誰？
您的小組、產品擁有者和客戶都可以執行接受度測試案例。 您的小組應該盡可能經常執行這些測試案例，以便提供必須在衝刺 (Sprint) 中成功之測試集的基準。 產品擁有者和客戶也可以執行接受度測試，而且可能需要經過驗證，才能順利完成衝刺 (Sprint)。
您的小組可以使用 Microsoft Test Manager來執行每個接受度測試案例並且記錄測試結果的視訊畫面擷取。 如此一來，您就可以取得測試結果的視覺化記錄，也可以與客戶共用這些結果。 當您難以建立必要的組態 (例如多伺服器組態) 時，這種作法就很有用。
定義接受度測試案例與使用者劇本
您可以在定義使用者劇本之後立即定義驗收準則。 透過定義接受度測試，您可以協助小組了解產品擁有者和客戶針對目前衝刺 (Sprint) 所設定的驗收準則。 因為客戶必須同意接受度測試，所以建議您最好在衝刺 (Sprint) 開始之前建立接受度測試案例。
單元測試
單元測試是在元件、類別、方法或屬性層級驗證功能的自動化測試。 單元測試是自動化和回復測試的基礎，可提供專案的長期穩定性和未來的可維護性。
單元測試如何協助發展應用程式的設計？
在建置測試程式碼時建立單元測試的流程有助於定義程式碼的雛形。 您可以使用單元測試來建立可測試的程式碼。 針對程式碼建立單元測試的難度在於程式碼應該重構的跡象。
如何組織我的單元測試？
每位撰寫程式碼的小組成員都應該針對他們所建置的元件建立單元測試，並且在 Visual Studio 專案內部，將單元測試程式碼簽入版本控制中。 您可以將測試案例工作項目歸檔至組建驗證測試套件 (透過連續整合在每個組建進行期間執行) 中，也可以歸檔至驗證對應使用者劇本的測試套件內部。
如何管理單元測試的變化，而不需要變更測試程式碼？
測試輸入的變化會定義測試之間的相似處或差異，因為它會驗證專案程式碼的功能。 例如，在測試 Web 應用程式的登入元件時，您可以在建立使用者帳戶時提供許多密碼類型。 此時，系統可能會針對所使用之字元類型的順序和組合設有規則。
Visual Studio Test Professional 撰寫資料驅動的單元測試和自動程式碼 UI 測試的功能。 如需詳細資訊，請參閱如何：建立資料驅動型單元測試與HOW TO：建立資料驅動型自動程式碼 UI 測試。
測試驅動式開發和及早測試
測試驅動式開發 (TDD) 是一種設計和程式設計的專業領域，其中每一行程式碼的撰寫方式都是為了回應程式設計人員在編碼之前所撰寫的測試。 成為您想要實作之程式碼的消費者這種想法非常有用，可維持程式碼之使用和設計方式的實際預期。
在 TDD 中，開發人員會以多次少量遞增的方式作業。 每次開發少量遞增時，約需要幾分鐘到幾小時不等。 一般而言，許多此類遞增累積起來，即構成使用者劇本。 開發人員會在使用者劇本運作時，簽入測試與程式碼。 開發人員會依下列循環作業：
撰寫預期會在遞增寫入時通過的自動化測試。
驗證新測試失敗，以確認現行測試已成功。
撰寫會使測試通過的程式碼。
執行測試以驗證它可順利通過。
另請執行相同範圍中的所有其他測試，以確定未引入任何 Bug。
視需要重構程式碼以改善其結構，而不加入行為。 重新執行測試，以確定程式碼仍可運作。
重複前述所有步驟，直到完整的使用者劇本完成實作為止。 當先前的遞增整合到完整劇本時，請加入測試以驗證完整劇本。
簽入實作程式碼與單元測試。
如果您想體驗一下及早測試方法的優點，您可以從建立手動 (或手動接受度) 測試開始。 建立自動程式碼 UI 測試，即可將這些手動測試自動化 (如需詳細資訊，請參閱 HOW TO：透過記錄待測應用程式產生自動程式碼 UI 測試)。此外，您也可以建立在 Visual Studio ALM 中使用單元測試架構的整合測試來驗證正在實作的功能。 在反覆項目中早期建立的測試案例群組會在反覆項目中早期執行，以便嘗試驗證功能和尋找 Bug。 這些測試套件和測試案例可以在整個專案生命週期內當做回復測試持續執行。 只要繼續執行這些測試，您就可以確保在反覆項目中早期發現的 Bug 和驗證的功能不會受到專案後期的變更所影響。
在連續整合中使用單元測試
您應該在目前衝刺 (Sprint) 和使用者劇本的測試套件內部組織使用及早測試作法時所建立的單元測試。 這些單元測試可以提升為專案範圍的測試計劃，並且由小組定期執行並在連續整合循環內部執行。 此外，單元測試也可以當做整合、負載和效能測試的基礎。
一開始建立的單元測試可以當做連續整合的一部分使用。 如需如何在組建進行期間執行測試的詳細資訊，請參閱 TestToolsTask Task。
使用虛擬化功能管理測試組態
若要執行單元測試，您可以建立在 Microsoft Test Manager的是 Managed Hyper-V 映像的一組環境。如需如何從Microsoft Test Manager測試計劃執行自動化測試的詳細資訊，請參閱HOW TO：使用 Microsoft Test Manager 在實驗室環境中執行自動化測試。
手動與自動化測試的比較
自動化和手動測試案例可彼此互補。 Agile 小組會致力於擁有更多自動化測試案例，因為他們會提升經常或連續測試回合。 為了持續執行測試，測試必須快速而頻繁地執行，這是手動測試難以達成的。
在決定手動和自動化測試案例的分配時，您應該考慮許多事項。
組織的人員技能對於測試類型的分配有何影響？
產品擁有者會協助定義專案的使用者劇本，而且也應該參與接受度測試的建立。 產品擁有者可能不會產生測試程式碼，但是卻擁有商務領域的重要知識。 因此，產品擁有者所定義的測試案例將位於商務詞彙和商務規則的層級。 例如，貨運公司的產品擁有者會指定企業所支援的不同運輸方式 (例如卡車、火車、空運、航運或組合運輸)。 然後，產品擁有者可以定義許多運用不同商機的測試案例。 針對這些手動測試，請務必指定運用不同選項 (在本例中，貨運的方式) 的測試數目下限。
產生程式碼的小組成員可以建置以手動測試為基礎或獨立於任何其他測試的自動程式碼 UI 測試 如需詳細資訊，請參閱How to: Generate a Coded UI Test by Recording the Application Under Test。 必須由能夠管理和開發專案的小組成員支援自動程式碼 UI 測試。
何時應該將手動測試轉換成自動化測試，或從頭開始建立自動化測試？
當您預期會重複執行測試以維護程式碼的穩定性時，您可以建置自動化測試。 請務必考量建立自動化測試所需的成本，因為投資於自動化將會影響到您小組的資源。 當程式碼具有少量變換時，建立自動化測試會產生較高的投資報酬率 (ROI)，因為測試變換較少。 不過，及早建立自動化仍有其價值，因為這樣做將有助於尋找邏輯和設計中的問題。 不論是哪一種情況，您都必須考慮支援自動化測試程式碼所需的資源。
在您決定必須自動化一組測試之後，請盡速完成自動化，因為自動化的優點包括管理程式碼的穩定性。 穩定性以及撰寫自動化時所發現的缺失數目將會影響完成自動化所需的投入時間。 最後，手動與自動化測試之間的平衡就是有關在專案生命週期內建置和執行之測試種類的優先權排定。
哪些測試類型會自動化？
單元測試
單元測試可驗證程式碼或 TDD 等流程中的功能。 單元測試很重要，因為它們有助於維持程式碼內部的穩定性和相依性。 此外，TDD 也比較容易產生具有相依性的較佳設計和良好的圖層定義，因為它可協助您從程式碼消費者的觀點了解設計。
負載測試
您可以建立以現有自動化測試案例為基礎的負載測試，或建立針對應用程式或服務產生特定負載類型的測試。 如需如何使用測試代理程式控制器和測試代理程式來產生模擬測試負載的詳細資訊，請參閱 HOW TO：使用測試控制器和測試代理程式執行測試。
如需使用 Visual Studio ALM 進行負載測試的詳細資訊，請參閱 Microsoft 網站上的下列網頁：了解負載測試。
連續整合測試
您可以搭配使用連續整合與 Visual Studio ALM，以確定程式碼在完成開發後簽入時，能夠與現有的程式碼正確搭配運作。 連續整合在小組和程式碼基底成長期間非常重要。 您可以定義包含測試參數的組建類型，並指定要在完成組建之後執行的測試。 如需如何定義執行測試之組建的詳細資訊，請參閱根據預設範本定義建置流程。
哪些測試類型可以自動化？
組態測試
在多個已安裝的環境上進行測試可能是非常耗時費力的工作。 Microsoft Test Manager提供了使用虛擬機器或實體機器在不同組態上執行測試套件的功能。 如需如何在多個環境中執行測試和蒐集資料的詳細資訊，請參閱設定測試電腦以便執行測試或收集資料。
使用者介面測試
Visual Studio ALM 具備直接針對使用者介面建立自動化測試的功能。 如需如何建立自動程式碼使用者介面測試的詳細資訊，請參閱 HOW TO：建立自動程式碼 UI 測試。
安裝測試
您可以使用 Microsoft Test Manager的實驗室功能來設定組態群組，用以驗證應用程式的安裝程式是否如預期方式運作。
自動化會面臨哪些障礙？
小組的能力
測試小組的子集必須了解如何撰寫程式碼，才能建立自動化。 您可以計劃產生建立自動化的學習過程以及測試程式碼的設計。 與實際執行程式碼很相似，您可以針對所需的目標建立自動化程式碼，例如可維護性、容易撰寫和壽命。
您可以使用 Visual Studio Test Professional，如需如何建立自動化測試的詳細資訊，請參閱 使用 Microsoft Test Manager 建立自動化測試。
程式碼變換
經常變更的程式碼是移動的目標，而且會對測試自動化程式碼造成串聯效應，因為它也需要變更。 您可以針對比較不容易變更的元件和介面建立測試自動化程式碼，藉以避免這些串聯效應。
程式碼設計
ASP.NET MVC 和 MVVM 等程式碼架構會引導小組成員撰寫具有隔離功能的程式碼，而這是驗證不同程式碼部分所需的功能。 緊密繫結至使用者介面的程式碼會難以測試，因為使用者可能必須與使用者介面控制項互動。
手動測試案例有哪些優點？
手動測試案例會提供下列優點：
手動測試可協助您的小組透過探索的流程尋找 Bug。
手動測試案例很容易定義，因為您可以用任何抽象方式定義步驟集合，而且可以用任何喜好的詞彙來定義成功和失敗。
在撰寫任何程式碼之前，及早在專案中開始撰寫手動測試案例非常簡單。 在定義接受度測試的流程中，這點很重要。
如果您使用 ，測試案例就可以由共用步驟組成，進而協助在定義類似的測試時節省時間，而且可讓您的小組重複使用單一版本的測試子集。 變更測試案例時，使用共用步驟也很有用，因為共用步驟的變更會自動變更使用這些共用步驟的測試案例。 如需如何建立和使用共用步驟的詳細資訊，請參閱 How to: Share Common Test Case Steps Using Shared Steps。
手動測試案例可以當做及早在專案或衝刺 (Sprint) 中進行通訊的工具。
手動測試案例可以當做記載自動化測試案例的工具，而不需要讓任何人檢閱程式碼。
如果您使用 Visual Studio ALM，執行手動測試就可以蒐集程式碼涵蓋範圍度量。
手動測試案例有哪些缺點？
手動測試案例具有下列缺點：
定義成功準則可能會很複雜，因為它會取決於觀點以及測試定義中所使用的語言。 某些語言的解譯方式可能不同，因此可能會保留錯誤的空間。
人員必須實際測試步驟並回報結果，才能執行包括手動測試案例的測試套件。 這個流程可能會耗費大量時間，因此可能會增加執行測試的小組成員數目，或增加執行測試套件的時間長度。 小組可以使用Visual Studio Test Professional來運用「向前快轉手動測試」，以便在測試期間記錄動作，然後將這些動作用於未來的測試回合中。
根據程式碼的穩定性，執行測試所需的時間和工作會有所不同。 因此，執行手動測試可能會影響小組的流程。
最大的缺點在於，手動測試很容易在偵測 Bug 時產生人為錯誤。 測試人員可能會看見 Bug 卻沒有辨識它。
自動化測試案例有哪些優點？
自動化測試案例會提供下列優點：
自動化測試有助於維持穩定性以及尋找由於程式碼變更而可能發生的回復。
自動化測試可以自動執行。
自動化測試是軟體，而且可加以設計並且由其他可重複使用的程式碼組成。 這樣會提高自動化測試的彈性和可維護性。
您可以使用 Microsoft Test Manager，針對多個組態執行自動化。
您可以在執行自動化測試時蒐集程式碼涵蓋範圍度量。
自動化測試案例有哪些缺點？
自動化測試案例具有下列缺點：
您必須考慮並且使用程式碼來實作特殊條件。 建立並執行自動化時，系統會在發現其他條件時實作這些條件。
當程式碼變更或重構時，可能會造成串聯效應，因此需要進行對應的工作來變更受影響的自動化測試。
當程式碼變更導致許多測試失敗時，您的小組可能會受到心理影響。 如果這些測試都當做旗標使用，小組可能會不想要舉起任何旗標。
如果測試案例沒有測試正確的條件，當所有測試都成功時，可能會產生安全性的假象。 請務必維護測試套件，並確定它們都驗證正確的條件和結果。
回報測試結果
從敏捷的觀點而言，根據 Bug 或彙總度量針對目前的品質狀態回報和查詢 Team Foundation Server 屬於回應循環的一部分，可讓小組逐一查看並變更程式碼、專案計劃與測試計劃。 如需詳細資訊，請參閱測試計劃進度報表。
使用 Microsoft 測試管理員，測試計劃結果功能也可以監視您的測試計劃進度。 測試計劃結果包含圖形和數字統計資料至傳遞的物件，在失敗和現用測試。 此外，測試計劃結果中會詳細的檢視失敗類型和解析資料。 測試計劃結果在測試計劃可以篩選包含或排除特定測試套件。 您也可以檢視個別測試人員的結果顯示在測試小組。 如需詳細資訊，請參閱HOW TO：使用 Microsoft Test Manager 檢視測試計劃結果。
.png "測試計劃結果")
應該將哪些測試層級回報給小組？
您可以使用 Visual Studio Test Professional 和 Team Foundation Server，您的小組可以了解計劃和執行測試的狀態。 Team Foundation Server 可儲存您的測試計劃、測試套件、測試案例、測試結果以及在整個測試流程期間產生的所有其他相關資料。 如果結合 Microsoft Test Manager 與中的報告和工作項目查詢，您可以在 Team Foundation Server視覺化測試和品質控制的流程。您可以使用 Microsoft Test Manager 為各種不同狀態的 Bug] 查詢。 已由其他小組成員標記為已修正的 Bug，應會處於已解決狀態。 您可以使用後續的組建來驗證已修正的 Bug。 如需如何驗證 Bug 是否已修正的詳細資訊，請參閱 HOW TO：使用 Microsoft 測試管理員驗證 Bug 已修正。