基于Visual Studio的軟件生命周期管理和持續交付 (二) 采用成熟度
visual studio是微軟系開發人員最常用的開發工具,但是它不僅僅是開發工具;VS就像是浮在水面上的冰,下面還藏著很多好東西;
從采用成熟度來分,從低到高有以下幾種方式: (本文只描述了一部分的優勢和劣勢,而且只代表個人觀點)
(并不是用的越多越好,選擇適合你的)
1.只用Visual Studio
只使用visual studio作為開發工具(只是開發工具哦) 在一個人做開發的情況特別常見, 偶爾在非常不正規的軟件作坊中也會見到
不可否認,VS是一個非常有生產力的工具
備注:Visual Studio有很多很強的插件,例如說增加開發效率的resharper
2.引入TFS 作為源代碼管理器
大部分公司都引入了源代碼服務器,只是用的方案不一樣,有的用SVN有的用TFS或者是別的什么
相比于其他源碼管理工具,TFS和Visual Studio的集成是最為緊密的,而且和接下來要談到的很多微軟系的軟件也是集成非常緊密的。
作為微軟的軟件,升級和維護,還有搜索資料一般也都來的方便。
單純作為源碼管理軟件而言,我個人覺得TFS的性能還是挺不錯,功能方面比其他的源碼強很多 (當然 這是因為TFS它不僅僅是一個源碼管理軟件。。。)
常用功能使用也很方便,個人印象比較深的是TFS的自動合并還是挺好用的
3.引入TFS作為開發標準和軟件生命周期管理
3.1使用TFS Build Service作為編譯和每日構建
這是我個人很喜歡的一個功能,這東西是現在很流行的“持續交付”/“持續集成”的一個實現
通過配置TFS Build Service,我們可以設置每次簽入代碼前后的動作,包括但不僅限于:
- 不允許簽入無法編譯通過的代碼
- 每次簽入的時候自動執行編譯和測試,如果有問題就發郵件給相關人員
- 每天執行一次完整的編譯和完整測試,如果有問題就發郵件或者通過其他方式給別人給相關人員
- 每次有代碼改變的時候自動分析并執行需要測試。
這樣能較好的保證,源代碼庫中的代碼是可用的,也可以避免團隊其他程序獲取最新版本以后無法編譯通過的問題;我個人已經無數次遇到過,從源碼服務器上直接拉下來的代碼是不能跑的,要找原作者過來幫忙配置環境,修改引用什么的
(想象一下,你早上來獲取最新版本的代碼以后,編譯報錯,而這又是別人的代碼。。。他又正好請假了。。。這真是糾結的事情啊。。如果團隊里面有很多人。。。那這種事情發生的概率就很高了)
3.2使用VS作為測試工具 (單元測試,自動化測試等..)
你們做測試了嗎?在敏捷開發中,開發人員和測試人員的界限已經較為模糊了,很多測試都是由開發人員完成的。
即使是在傳統的軟件開發流程中,開發人員自己開發出來的東西自己總要試試吧~
單元測試的優勢和劣勢,已經有很多文檔描述了,這里就不廢話了
VS中內置的單元測試工具,第一點的優勢就是內置,這樣別人獲取你的代碼以后不需要額外的環境和引用就可以直接執行了
其次,作為mstest.exe兼容的測試,他與微軟的Test Manager 等配套軟件集成的很好,而且也可以很方便的放在3.1的過程中執行
功能方面。。。一般般吧。。。。
對了Coded UI還算是一個不錯的可以做end-to-end的測試,可以較好的模擬用戶的行為,并且支持的平臺也比較多
備注:Pex是VS的一個插件 可以很方便的自動測試和生成測試代碼
3.3使用VS和相關插件作為開發標準
Visual Studio本身就有一些代碼規范檢查標準, 同時我們還可以通過FxCop等擴展出一些自己的標準來,這樣,我們可以通過自動化的代碼檢查來規范代碼,提高代碼質量
其次,在TFS中簽入代碼的時候可以制定規則,只允許符合規范的代碼簽入,可以實現強制標準
3.4使用VS管理軟件生命周期
TFS內置了 Task, Test Case, Bug還有開發流程規范等東西,基本上可以覆蓋中小型軟件公司90%的需求了。。。
當然,用不用,怎么用,用到什么程度,需要結合公司情況考慮一下
對了 這東西有基于Sharepoint的web版本,沒有安裝VS也是可以使用的。
這東西用好了對軟件生命周期的進度和控制能力會有所改進
3.5報表
基于SQL Server Reporing service的報表功能,可以很緊密的和Visual Studio, Sharepoint 還有Excel Project等軟件結合起來
作為管理層,往往比較關心報表
4.使用Test Manager進行測試
在很多公司,測試都不怎么受重視。。。唉。。。也間接說明了在這些企業對于軟件質量要求并不高。。
不管怎么說,測試還是保證軟件質量的重要環節
Test Manager和TFS集成在一起,允許你建立測試計劃,Test Suite,并且關聯到Test Case。
并且,之前我們做的單元測試,或者是任何一種mstest.exe兼容的測試代碼,都可以關聯到Test Case,這樣就擁有了自動化執行一系列測試的可能
對了,在Visual Studio中本身也是有Test explorer的,不過沒有集成測試計劃管理和配置功能,只能本地測試下
5.lab environment
想象一個場景:開發了一個web應用,自然的我想在IE 789,chrome等瀏覽器下測試一遍,那么你會怎么做呢?
原始的做法是:在不同的機器上開不同的瀏覽器各測試一次。。。。
現在的做法是: 寫一段測試代碼,然后告訴Test Manager,我要運行在環境ABC上。 然后等一會兒來看各個環境的測試結果
在這一套方案中:
Hyper-V 實現了虛擬機的功能
System Center Virtual Machine Manager 實現了虛擬機的模板和管理功能
Lab Manager 將測試計劃和TFS和虛擬機關聯起來,
那么當你通過Test Manager 執行一次測試的時候, 就可以選擇一個測試環境,從而將測試計劃到遠程機器上執行
最終的測試數據和信息將保持到TFS中,作為以后查看和報表的工具
自動化測試有如下優勢:
- 測試成本低 (開發成本可能較高)
- 可以很頻繁的執行
- 執行時間可以很短
- 減少人工操作(人工操作比較容易犯錯)
- 可以很方便的在多個環境中執行測試
- 知識積累(對于有開發能力的人來說,有的時候代碼比文檔更容易看懂;并且不會像人工一樣忘記測試某個功能,自動化測試可以在軟件的每個版本中都完全的執行,)
最后回顧一下架構圖

浙公網安備 33010602011771號