Visual Studio 2010 Ultimate敏捷测试驱动开发
? 在微軟Visual Studio 2010 Ultimate Beta2版本中，MSF for Agile Software Development 5.0過程框架，是以Scrum模型為基礎導向擴展，并且結合了VSTS2010工具的眾多測試功能特性，為更多的從事微軟.NET技術相關的開發人員以 實現高質量的軟件產品。
在本文中，筆者將介紹Visual Studio 2010 Ultimate Beta2版本中的MSF for Agile的Scrum和XP敏捷思想與VSTS2010強大的測試功能，通過對這些內容的闡述，讓讀者了解在VSTS2010中的敏捷測試驅動開發方法，以便于.NET開發人員能把敏捷驅動開發為導向的技術，應用在自己的項目和團隊中，從而構筑出敏捷的開發團隊。
1.引言
在前幾篇的文章中提到過的Scrum，相信讀者們都應該已經不陌生了，它的核心在于迭代，并且以每個sprint時間段的周期進行產品功能迭 代。團隊首先瀏覽開發需求，考慮可用技術，并對自身技術及能力做出評估，所有實踐就是圍繞著一個迭代和增量的過程來展開，而在每個迭代內部，可以使用測試 驅動和持續集成的XP(eXtreme Programming，極限編程)工程實踐。
XP，是最輕量級的開發流程，其最主要的精神是“在客戶有系統需求時，給予及時滿意的可執行程序”，所以最適合需求快速變動的方案。Scrum 與XP所不同的是，Scrum只是一個敏捷過程框架，它并沒有提供核心的價值觀與指導原則，也缺乏具體的實踐方法，例如，測試驅動開發、結隊編程等。 Scrum僅僅規定了實施的基本流程與檢查表，它是一個開放的管理框架，重心在于項目管理，而不是指導團隊成員如何進行開發。這既是Scrum的優點，因 為它很靈活，能夠適應大多數場景，也可以兼容并包地引入其他方法學所提倡的實踐;同時也是Scrum存在的固有缺陷，使得它難以被實踐。如果沒有一位優秀 的Scrum Master，而團隊成員又缺乏自我組織和管理的能力，就會讓開發過程變得一團糟，團隊成員將會無所適從。
在團隊中開發人員隨時可以與客戶進行有效溝通，撰寫user stories以確認需求。簡易快速的系統設計，撰寫獨立的驗證程序以解決特殊困難的問題，并找出演算法即可丟棄驗證程式。規劃多次小型階段的方案計劃， 并且以最快得速度完成每一階段的程序交付客戶，客戶負責Acceptance tests;Coding前必須完成Unit Test與Acceptance tests程序，所有模組整合前都須經過Unit Tests;開發人員必須快速回應Bug和需求變更;要求二人一組使用一臺電腦設計程序，當一人coding時，另一人負責思考與設計(結對編程);程序 必須符合程序規范，并常做程序的重構(Refactoring)。
在Agile開發實踐方面，Scrum可以借鑒XP提倡的結隊編程以及測試驅動開發實現編碼，通過重構對編碼進行調整以適應需求的變化，Scrum為體，XP為用。XP開發流程的基本步驟，如圖1所示。
圖1 XP開發流程的基本步驟
測試驅動開發意味著你要先寫一個自動測試，然后編寫恰好夠用的代碼，讓它通過這個測試，接著對代碼進行重構，主要是提高它的可讀性和消除重復，這將會對Agile Team整體素質要求較高。
時至今日，Agile Process的精神已經成為共識，但是沒有一種固定的流程可以重復使用在不同的方案上，而且不管是RUP、XP、SCRUM、或其他的開發流程都允許相 當大的彈性，我們必須按方案性質的不同，調整或混合出適合的開發流程，并允許團隊在進行中做必要的彈性修改，才能夠達成目標。
?
2.敏捷之驅動開發
在XP開發實踐中的TDD(Test Driven Development)，它有一個別稱叫 Test-First Programming，要求開發的第一步是根據需求，必須先寫單元測試程序，然后再寫實現程序讓符合需求的測試通過。我們知道XP中的需求是以“用戶故 事”(User Story)的形式描述的，而用戶故事實質上就是一種軟件“特性”(Feature)。TDD 講的是如何通過編寫“測試”，尤其是單元測試，來驅動軟件的設計和編程。
系統測試從哪里來?來自系統需求。系統需求從哪里來?來自用戶目標，TDD則也不例外。在需求不穩定的情況下，這樣的TDD會有什么問題?會不 會帶來許多冗余的工作?答案是肯定的，這樣必然會帶來單元測試的不穩定，這就需要敏捷開發人員有相當強的抽象能力，抽象、界定出主要相對穩定需求就可以實 施TDD。
敏捷團隊可以采用在軟件工程學里有比較成熟的OOAD(Object Orient Analysis & Design，面向對象的分析和設計)軟件開發方法(參見筆者著作《我也能做CTO之程序員職業規劃》的高級程序員技術能力)，在用戶需求層面找到，并抽 象出相對不變的需求。OOAD科學分析法體現的是‘現實事實的抽象理解能力’，以業務為中心來分析解決問題，不涉及求解方案。分析階段所做的主要工作是理 解問題和需求構模，將現實世界中的問題映射到問題域，從而穩定主要需求。OOAD包括‘設計模式能力’，反映計算機世界來體現現實世界。
分析階段主要是明確用戶的功能需求，滿足用戶所需的系統部件及其結構。設計階段則主要是確定實現用戶需求的方法，即怎樣做才能滿足用戶需求，并構造出系統的實現藍圖。
OOAD方法要求在設計中要映射現實世界中(指問題域，如圖2所示)的對象和實體，如程序員、汽車、項目實施人員等。這就需要在設計中盡可能地 接近現實世界，以最自然的方式表述實體。所以，面向對象技術的優點就是能夠構建與現實世界相對應的問題模型(橋梁)，并保持它們的結構關系和行為模式。
例如，我們通常做的系統分析是在假定需求不變的情況下進行的，這樣可以把企業的資源配置到最優的程度，但是企業的需求是變化、不穩定的，那么以 變化的需求為基礎建立起來的軟件系統當然也就不穩定了。需求是項目的根本，既然需求都是不穩定的，那么何以建立起穩定的企業信息系統呢?
圖2 軟件需求抽象示意圖
采用OOAD開發的方法時的需求不穩定，可分析出這不穩定的東西就是對象。世界都是由對象組成的，而對象都是持久的，例如動物、植物已經有相當 長的時間。雖然對象也在變化，動物、植物也在不斷進化。但對象在一個相當長的時期內都存在，動植物的存在時間肯定比任何一家企業長久。面向對象開發方法的 精髓就是從企業的不穩定需求中分析出企業的穩定對象，以企業對象為基礎來組織需求、構架系統。這樣得出的系統就會比傳統的系統要穩定得多，因為企業的模式 一旦變化，只需將穩定的企業對象重新組織就行了。
在敏捷XP中，采用的是TDD驅動軟件的設計和編程實踐，即，測試驅動開
發。筆者負責過很多項目的敏捷實踐中，更喜歡UDD(Use Case-Driven Development)比較適合目前的國情。它可根據用戶目標，編寫軟件需求，根據軟件需求，編寫系統(驗收)測試，即，用戶目標驅動。利用 UML 對軟件的設計進行建模，這部分建模當然是敏捷的(agile)。簡單的只需幾秒鐘可以迅速在人的大腦中完成，復雜的則可以畫在紙上、白板上，記錄在建模工 具生成的電子文檔中，當需求穩定后可以迅速轉化成軟件應用代碼，在結合TDD會有很不錯的效果，這種理論體系有些像太極原理，需求的變化看似武術中的招 式，采用UDD見招破招，無招勝有招，這種客戶的需求應變使得UDD更為敏捷。
?
3.實戰VSTS2010驅動開發
在Visual Studio 2010中，敏捷測試驅動開發功能非常強大，微軟把Scrum和XP敏捷思想融入到Agile過程框架之中。TFS2010中增強了團隊源碼版本管理、迭 代開發和驅動測試開發模型等，從而給微軟.Net開發人員非常大的幫助。VSTS2010測試馬甲和單元測試過程，如圖3所示。
圖3 VSTS2010單元測試過程
IUT——在生產環境中最終交付而開發的軟件。
Test Environment——測試環境。
測試驅動開發(TDD)基本過程：
(1)明確當前要完成的功能。可以記錄成一個初始化測試清單(TODO)列表。
(2)快速完成針對一個功能的測試用例編寫。
(3)測試代碼編譯通過，但測試用例通不過。
(4)編寫對應的功能代碼。
(5)測試通過。
(6)對代碼進行重構，并保證測試通過。
(7)循環完成所有功能的開發。
·圖書收藏實例
確定好backlog，進行sprint backlog，把story拆分成更小的故事，并在把故事拆分成任務，索引卡片參考圖4所示。
圖4 圖書收藏Story索引卡
將案例分成任務，我們需要在很大程度上實現讀者個人借閱圖書的收藏集合。其中之一backlog索引卡，如圖4所示。當讀者到圖書館進行圖書借 閱中，會查詢圖書庫所有相關類圖書封面并選取其中自己最需要的幾本書。這個過程叫做“書簽”，圖書系統將通過圖書管理來支持這個活動。為圖書借閱集合初始 化測試清單，參考1所示。
表1 為圖書借閱夾初始化測試清單
?
列出表中完成有關的大部分任務測試清單，測試重點放在確保我們添加和移除圖書收藏夾的時候計數是正確的，以及集合的內容和是否可以恢復集合，驅動測試時間持續1到2小時的驅動編程實踐中完成這個測試清單，并確保這個測試清單不需要再次分解這個任務，以實現這個目標。
·實現第一個測試
打開Microsoft Visual Studio 2010，創建一個C#測試項目，項目名稱為LocalBookCollectionsTests，如圖5所示。
圖5 創建一個測試項目
清除原理項目方案自動生成的unit的C#測試文件，建立一個新的名稱為CollectionsTests單元測試類，如圖6所示。
圖6 創建一個單元測試unit類
先用一些函數代碼替換第一個測試中的語句，這樣做驅動了產品代碼Collections類的創建，并運行其Count屬性。在CollectionsTests.cs類添加代碼：
////// 創建一個測試清單
///
[TestMethod]
publicvoid EmptyCollectionsCountShouldBeZero()
{
Collctions collctions =new Collctions();
Assert.AreEqual(0, collctions.Count);
}
?
重新編譯生成這個解決方案，你將看到一個錯誤，因為沒有為Collections類定義Count。創建Collections類，填入一下代碼：
////// 定義Count
///
privateint count;
publicint Count
{
get
{
return count;
}
}
?
運行這個測試，輸出EmptyCollectionsCountShouldBeZero()單元測試成功界面，如圖7所示。
圖7 EmptyCollectionsCountShouldBeZero單元測試成功
?
·擱置你的測試清單代碼
為你的此次操作添加為一個版本控制擱置，這樣就可以在將來常常返回到這個點(版本控制)，在VS2010菜單打開View|Other Windows|Pending Changes，如圖8所示。
圖8 Vsts2010的View|Other Windows菜單
通常由于你并不想在所有相關單元測試通過之前，與團隊的其他成員共享文件，因此保持VSTS存儲庫中擱置自己的文件版本，而不是將你的變更點簽入到團隊代碼庫的分支中。完成所有單元測試后，可以直接點擊Check In 按鈕將此代碼加入到存儲庫中。Pending Changes擱置窗口，如圖9所示。
圖9 Pending Changes擱置窗口
Unshelve按鈕可以進行版本回卷。點擊Shelve按鈕進行版本擱置，建立一個Test the Should Be Zero的版本擱置，如圖10所示。
圖10 創建版本擱置
?
·修復一個失敗的測試和重構
現在我們處理清單上另外幾個簡單單元測試。它們在Collections對象中添加和刪除各種Collection項，并驗證Count熟悉返回正確的值。
首先在CollectionsTests.cs類中添加如下代碼：
////// 修復一個失敗的測試
///
[TestMethod]
publicvoid EmptyCollctionsCountShouldIsOne()
{
Collections collections =new Collections();
collections.Add(new Collection("Label", new Uri("db://book0001")));
Assert.AreEqual(1, collections.Count);
}
?
生成這個項目(生成|生成項目)，生成報錯是因為Collection類缺少參數，如圖11所示。
圖11 缺少參數報錯界面
添加一個unit新類Collection.cs，加入一下代碼：
privatestring label;private Uri uri;
public Collection(string label, Uri uri)
{
this.label = label;
this.uri = uri;
}
publicstring Label
{
get
{
return label;
}
}
public Uri Uri
{
get
{
return uri;
}
}
?
替換Collections.Add()方法，修改Count屬性返回count變量值。
////// 增加一個Count實例變量
///
publicvoid Add(Collection collction)
{
count++;
}
?
再次生成這個項目，輸出結果顯示成功，如圖12所示。
圖12 輸出單元測試成功結果
再次重復上面操作，創建一個版本擱置。
?
4.確認測試(BVT)
生成確認測試(BVT)是通過產生測試列表來檢查軟件，它通常作為一個生成任務在團隊生成結束的時候執行。當編寫好一個unit測試時，你可以加入到BVT中，確保任何時候在生存庫環境下運行集成生成，相同的測試程序都可以依次執行。
我們可以把上面的EmptyCollctionsCountShouldBeZero()和 EmptyCollctionsCountShouldIsOne()測試方法創建生成測試。打開Microsoft Visual Studio 2010菜單，點擊Test|Windows，如圖13所示。
圖13 Test|Windows菜單
點擊菜單項Test|Windows|Test List Editor，打開Test List Editor界面，如圖14所示。
圖14 Test List Editor界面
參考圖14，點擊界面“here”或者菜單Test|Create New Test List，創建一個新的測試列表，測試列表名稱為BookCollectionBVT，如圖15所示。
圖15 創建一個新的BVT
?
同理，打開菜單項Test|Windows|Test View，打開Test View瀏覽框從而顯示驅動單元測試程序，從Test View把EmptyCollctionsCountShouldBeZero和EmptyCollctionsCountShouldIsOne拖拽拖 到Test List Editor面板中，為了確保這個測試是作為集成測試的一部分運行，點擊BookCollectionBVT中所要測試程序的復選框。
點擊Run Checked Tests按鈕，運行這個測試程序，如圖16所示。
圖16 運行這個測試程序
運行測試結果界面，如圖17所示。
圖17 運行測試結果界面
這樣，安裝Microsoft Visual Studio 2010團隊成員，在每個人的本機上開發環境上運行自己的單元測試之后，就可以添加并測試完成余下的那些索引卡下分解出來的測試列表單元測試程序清單，加 入到BookCollectionBVT集成測試集合之中。
五、總結
Microsoft Visual Studio 2010的集成測試的功能特點結合MSF for Agile Software Development V5.0中的Scrum和XP敏捷過程框架，使從事在微軟.NET技術相關工作方向的人們擁有了一把利劍，并且可以充分的協助編程人員開發出高質量的軟件 產品。
Scrum專注于聚焦在找到一個最小的迭代式項目管理框架，注重敏捷的計劃、跟蹤和管理，而沒有把它強行綁定在某一種具體的工程技術和做法之上有關，這大概這也是它非常聰明的地方。既然沒有明確限定和約束，那么就代表著開放，可以適用于不同類型、不同環境下的項目。
從Scrum和XP—>OOAD—>UDD和TDD，不禁讓筆者想起太極陰陽理論，可以說太極是我們中國人千年的傳統智慧，看待宇 宙和世界的一種基本觀點和思維方式。世界和宇宙是由陰和陽組成，兩者既互為對立、矛盾，又相互依存、共生，和諧、統一地構成了整個宇宙。敏捷之道的精髓就 在于客戶、團隊和人與人之間的溝通與互動、協作，所以，作為中國人尤其是中國的軟件人，更應該開闊自己的思維，學會運用太極思想。
孫子兵法有云：兵無常勢，水無常形，能因敵變化而取勝者謂之神。很多人都向往用兵如神的境界，想必也知道讀萬卷書不如行萬里路，紙上談兵的故事更是耳熟能詳，除了以上所講述的內容外，也需要充分的運用敏捷和進行大量的實踐。
敏捷文化也決定管理，管理決定技術，因此實施敏捷應該只有具有先進文化的企業和團隊，才能實現真正的敏捷變革，并從中獲益……。
測試代碼下載
????? 我為it168籍稿，原文:http://tech.it168.com/a2009/1207/820/000000820565_1.shtml
轉載于:https://www.cnblogs.com/vmyspace/archive/2012/03/05/2379988.html
總結
以上是生活随笔為你收集整理的Visual Studio 2010 Ultimate敏捷测试驱动开发的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 第五节 19可空数据类型
- 下一篇： VS 2010 测试功能学习(八) -