TFS的使命就是要解決開發過程中的信息“孤島”問題，通過統一的存儲機制是它們的能夠協作起來，實現1 + 1 + 1 ... + 第n個1 > n的效果。如下圖所示，微軟已經為不同的角色提供了豐富的工具來訪問TFS數據，同時還提供了TFS Object Model(API)，讓第三方廠商就能夠開發自己的基于TFS的軟件。
圖2 TFS彌補了信息的孤島
現在Visual Studio已不再是僅面向開發人員一種角色的軟件編碼工具，它已變成了一個覆蓋整個軟件開發生命周期的ALM工具。其實，作為軟件工具廠商這也是必然的發展方向，就像IBM也有Rational、ClearCase等工具。作為每一個軟件行業的從業人員，無論是開發人員、項目經理、還是測試人員，也要不斷適應這個趨勢，我認為它只會使我們的工作更簡單和更輕松。
Test Impact Analysis是Visual Studio 2010測試部分新增加的一個功能，我也不知道該如何翻譯其中文名，那就簡單點兒，按字面翻譯為“測試影響分析”，以下簡稱為TIA。啥時TIA呢?簡單地說，就是根據產品代碼變化自動分析出受影響的測試用例。
那么這個功能有什么實用價值呢?對于我所在的開發團隊而言，其價值可老大了。我們所開發的產品規模比較大、功能比較稀碎，并且是多人合作開發。為了保證產品的質量，我們為產品編寫了大量的自動化測試用例 (>5000)，同時還有少部分的手動測試用例(< 200)。為了保證每次產品代碼Check-in的質量，在我們開發過程規范中明確指出：每次check in代碼之前，必須執行所有相關的自動化測試用例，并全部通過之后才能checkin。這樣做的初衷是為了防止regression缺陷的發生，但問題是如何找到“相關的測試用例”呢?如果運行所有的自動化測試用例，大概需要8+小時。僅為了一小的修改就要去華8個小時執行測試用例，顯然是不值得。所以我們所采用的方法是將測試用例分類：集成測試用例、功能測試用例和單元測試。其中，集成測試用例數量最少(5~8%)，覆蓋了最最基本用戶功能;單元測試覆蓋數量較大(30%)，但運行速度很快;功能測試用例覆蓋絕大多數一般功能和一些邊界條件，其數量大運行時間最長(60~65%)。根據這三個分類，我們選擇為每個checkin執行所有的集成測試和單元測試用例。這樣做的好處是：覆蓋了最基本的產品，同時運行時間不是很長。
上述方案僅是一種折中的選擇，其不足之處也是顯而易見的：所選擇的測試用例固定不便、不準確，雖然保證了最基本產品功能不會被破壞，但往往不能發現checkin代碼對其它功能影響。但在過去，這也是無奈的選擇。TIA功能的出現就大大改善了這種情況，它可以幫助我們更精確的從所有測試用例中找出受到代碼變化影響的測試用例。
在Visual Studio 2010中，啟用TIA的方法非常簡單，首先打開你的測試工程，然后選擇 Test –> Edit Test Settings –> Local(local.testsettings)，再在Test Settings對話框中選擇 Data and Diagnostics –> Test Impact，如下圖所示：
然后，需要重新編譯編譯整個測試工程，并執行所有的測試用例，以生成TIA所需要的基線數據。通過Test –> Windows –> Test Impact View打開Test Impact View窗口，如下圖所示。在沒有任何代碼改變情況下，窗口中會顯示“No tests are impacted”。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
