本文的第一部分（上、下）著重介紹了測試人員在敏捷開發過程中，需要完成的一些測試準備工作。對於讀者來說，這些工作項可能會比較陌生，但在敏捷開發中卻對保證開發的質量和速度起到了很重要的作用。在這一部分中，我們將進入大家較為熟悉的實際測試階段，為大家介紹測試任務的執行以及bug的管理。
在整個敏捷軟體開發流程中，存在著各種測試任務。比如，夥伴測試（buddy test）、常規的測試執行（test run）、bug的驗證、bug大掃除（bug bash）、dogfooding等等。但是，無論具體任務如何變化，測試總是以3種形式存在的：執行測試用例、ad-hoc測試和實際使用產品。這裡我重點介紹兩種重要卻不太常見的測試任務，以囊括解釋這3種形式的測試是如何進行的。
在開發人員第一次簽入某個功能（或者簽入重大的修復）之前，為保證構造的穩定性，往往會先將**通過team foundation server（tfs）的擱置集（shelveset）發給相關的測試人員做夥伴測試。夥伴測試常常是測試人員同某一新功能的第一次親密接觸，是實際測試的開端。同時，它也是一種非正式的手動測試，因為這些**尚未簽入，測試人員發現的問題並不構成bug，他們也不會將其記錄到bug資料庫中。
在夥伴測試中，測試人員需要關注以下幾點：
那麼，如何入手來做夥伴測試呢？這裡就需要我們前面提到過的2種不同形式的測試：
1. 執行測試計畫在夥伴測試時，執行一次制定好的測試計畫是乙個好主意。在真正接觸到產品功能前制定好的測試計畫，可以提示測試人員各處細節，使得夥伴測試更全面；同時測試計畫也有助於保持測試人員的客觀性。這將很好的覆蓋到功能測試，也能照顧到大部分的邊界測試。
通過在test manager中切換至的test標籤（如圖1所示），我們就可以在test runner工具中執行測試計畫中的測試用例。
圖1 測試標籤
圖2所顯示的是test runner在執行測試時的樣子。左邊是test runner介面，這裡會依次列出選擇執行的測試用例的測試步驟（如果測試用例帶有多組資料，則該測試用例會被列出多次，每次顯示不同的資料）。右邊的部分相當於普通的桌面，你可以在這裡執行test runner中列出的測試步驟，並在test runner中標註每個測試步驟是否執行成功、記錄執行結果、或是擷取執行時的螢幕截圖，也可以直接建立bug。測試步驟、執行的結果、執行時的環境等各種資訊，不但會被新增進執行結果報告中，還可以被直接新增到bug中。同時test runner還支援將手動執行的測試步驟「錄製」下來，這樣下次執行同乙個測試用例時，就不用手工操作了，可以讓test runner自動執行。
圖2 test runner
2. ad-hoc測試既定的測試計畫並不足以覆蓋測試人員在夥伴測試中所有關注的重點。於是我們需要引進乙個新的機制——ad-hoc測試。ad-hoc測試一種比較隨機的、自由的手動測試，有時我們也稱其為「玩自己的產品」。它不需要事前詳細的計畫，也不需要全面的覆蓋。它可以只是隨意的試用某個功能，也可以是用各種資料「折磨」某個功能。它可以是專注於乙個功能，也可以是隨意的在幾個功能間切換。大多數時候ad-hoc測試就是靈光一現的「如果我在這一步這樣做會怎樣呢？」而這恰恰是最容易發現bug的一種測試。因為寫成文件的測試計畫往往都是比較主要的使用者場景，開發人員也會偏重於保證這些場景能夠正確工作。而ad-hoc這種隨機的測試卻往往能深入到一些意想不到的地方，找出隱藏的問題。
不過從夥伴測試的關注點出發，在這裡我們做ad-hoc測試時可以有一些重點：開發人員關於其改動的意見、測試人員基於以往的經驗容易出錯的地方以及與改動相關的主要的使用者場景。這樣ad-hoc測試就能幫助測試人員覆蓋一部分邊界情況，以及回歸測試。
ad-hoc測試可以發生在開發周期的任何時間。幾個常見的場合包括新功能簽入後團隊成員的試用、每週一次團隊成員的bug大掃除等。
做ad-hoc測試也可以利用之前我們介紹的test runner工具。首先，在你的測試計畫中新增乙個ad-hoc測試專用的測試用例，執行它之後就可以利用同樣利用test runner來來記錄包括操作步驟在內各種資訊了。使用這種方式的最大好處就是避免了在隨機測試中測試步驟難以記錄下來的問題。
test manager中另乙個為ad-hoc測試提供方便的功能是虛擬機器。切換至lab center（如圖3所示），就可以在此建立虛擬環境用於執行測試，不同的作業系統、語言等等。而且lab center能儲存虛擬環境，從以前儲存的環境中直接建立一模一樣的虛擬機器。通過虛擬環境的重建，開發人員可以很容易的自己建立出完全一樣的環境來重現bug，進而避免了由於環境原因導致的bug無法重現的問題。
圖3 lab center
測試人員在完成夥伴測試後，會發布乙個夥伴測試報告。報告的內容應該包括：哪些功能是經測試能正常工作的、在測試過程中發現的問題以及這些問題的重現步驟和結果。開發人員就可以在簽入**前修復這些問題，或是經過團隊討論後先簽入**並將沒有修復的問題提交到bug資料庫。而作為測試人員，一件後續工作是重新審閱測試計畫，確認發現的問題是否能被已有的測試覆蓋，並視其嚴重程度決定是否新增進測試計畫。
在夥伴測試的流程中，再一次體現了一些我們已經重複過多次的、在敏捷開發中的一些重要概念：保證構造的穩定、盡早修復問題、團隊成員之間緊密合作。
dogfooding字面上的意思是吃**，這裡實際指的是完全作為乙個使用者來使用自己的產品。這是乙個在微軟內部非常強調的概念。就比如我們visual studio開發團隊使用的開發工具就是正在開發的新版本的visual studio，我們習慣於每隔幾天或幾周就更換至最新的構造，以便能第一時間體驗最新的產品功能，搶在使用者之前發現使用中可能出現的問題。
使用「半成品」的代價是顯而易見的——不穩定的環境、不好用的功能，但是帶來的好處也是十分豐厚：一方面提供了大量「免費」的手動測試，另一方面團隊成員充分理解使用者場景、感受使用者體驗後，能更有目的性的去提高產品質量——特別是對於一些設計上不方便使用的功能，可能在triage討論時會覺得沒有必要修復，但是一旦讓團隊成員自己使用後，他們可能就迫不及待的想要改進了。
而且dogfooding並不僅限於產品開發團隊本身，在產品比較穩定之後，我們還會邀請公司內部的其他兄弟團隊來試用產品。比如，在windows發布之前，公司裡幾乎所有的同事都會換上最新的試用版。不少很棒的bug都是在這種大規模的dogfooding活動中發現的。
林俊彥
本文精簡版收錄於《程式設計師》7月刊。
用Visual Studio實踐敏捷測試（二）下
無論採用何種測試形式 執行何種測試任務，都會產生一系列的bug。而開發團隊需要乙個健全的bug管理的機制。一般來說，乙個bug的生命週期大致要經過如下幾個過程 圖4 bug的生命週期 這裡大多數的階段都比較易懂，需要解釋一下的可能就是triage過程。bug在建立出來以後，首先要經過triage小組...
用Visual Studio 2005進行程式開發
vc 2005快速入門之復合賦值操作符 前面講過如何使用算術操作符來建立新值。全文閱讀 visual c 2005影象程式設計之預備知識 影象處理過程中，有很多需要我們掌握或者注意的方方面面。這裡我先簡單介紹一些比較基礎的 重要的知識。全文閱讀 vs2005和asp.net2.0中使用強型別資料 作...
用Visual Studio 編譯64位程式
由於硬體的公升級，目前伺服器處在乙個從x86到x64的過渡時期。如果用vs2008在x64位機上編譯程式，有時候會遇到 試圖載入格式不正確的程式 的錯誤資訊。如下圖所示 幾乎可以肯定是遇到了 x86和 x64位 dll混編的錯誤。所謂 x86和 x64位 dll混編 是指 32位程式集與 64位程式...