隨著需求的不斷變化和迭代的深入，代碼庫不可避免的會(huì)有頻繁的簽入和簽出，此時(shí)測(cè)試人員一項(xiàng)很重要的任務(wù)就是要預(yù)防回歸問題發(fā)生。執(zhí)行手工測(cè)試用例可以幫助我們預(yù)防及和發(fā)現(xiàn)回歸問題，但是它的執(zhí)行效率太低，無法勝任頻繁執(zhí)行的要求。這時(shí)就我們需要考慮采用自動(dòng)化測(cè)試用例完成這項(xiàng)工作。決定是否采用自動(dòng)化測(cè)試是有很多因素決定，其中很重要的一條就是自動(dòng)測(cè)試的收益，下面的公式從概念上解釋了如何來計(jì)算這個(gè)收益，當(dāng)收益值大于1的時(shí)候，實(shí)施自動(dòng)化測(cè)試就是合算的；否則，就是不合算的。

圖1：計(jì)算收益公式

　　這其中，開發(fā)和維護(hù)自動(dòng)測(cè)試的成本是影響這個(gè)收益的重要因素，為此VS 2010提供了一整套的解決方案，幫助測(cè)試團(tuán)隊(duì)減少這部分成本，這包括前面我們所提到的測(cè)試計(jì)劃和用力管理工具，以及后面將會(huì)要介紹的生成和實(shí)驗(yàn)室管理。此外，Visual Studio 提供了多種測(cè)試工程模板，幫助測(cè)試人員開發(fā)自動(dòng)化的測(cè)試用例，如下圖所示。

圖2：Visual Studio提供的多種測(cè)試模板

　　這些測(cè)試工程模板可以幫助測(cè)試自動(dòng)化工程師，在Visual Studio 集成開發(fā)環(huán)境中創(chuàng)建和管理單元測(cè)試、功能測(cè)試、Web性能測(cè)試、負(fù)載測(cè)試等等一系列的自動(dòng)化測(cè)試用例。這其中，編碼的UI測(cè)試（Coded UI Test，以下簡稱為CUIT）是首次出現(xiàn)，是VS 2010測(cè)試部分一大亮點(diǎn)。測(cè)試人員可以通過它使用C#或者 VB.NET語言編寫自動(dòng)化測(cè)試用例，從用戶界面層驅(qū)動(dòng)Web、Winform或者是WPF的應(yīng)用。

　　CUIT為測(cè)試用例的自動(dòng)化提供了一個(gè)框架、API和可擴(kuò)展的接口，測(cè)試人員可以很輕松地開發(fā)出所要的自動(dòng)化測(cè)試用例。其實(shí)CUIT背后的測(cè)試自動(dòng)化實(shí)現(xiàn)技術(shù)對(duì)大家并不陌生，下面列出針對(duì)Web、WinForm和WPF應(yīng)用的測(cè)試技術(shù)基礎(chǔ)。對(duì)每種技術(shù)的支持采用的是插件的形式實(shí)現(xiàn)的，VS 2010包括了如下的三種插件：

• Document Object Model（DOM）插件 : IE 7/8 HTML/AJAX
• User Interface Automation（UIA）插件 : WPF
• Microsoft Active Accessibility（MSAA）插件 : Winform，Win32和MFC 。MSAA插件是默認(rèn)選項(xiàng)，用來支持出其它兩者之外的任何應(yīng)用。

　　CUIT 現(xiàn)在支持主要的微軟平臺(tái)，詳細(xì)的內(nèi)容可以參見MSDN : Supported Configuration and Platforms for Coded UI Tests and Action Recordings。對(duì)于那些尚不支持的平臺(tái)或者UI控件，CUIT提供了很好的擴(kuò)展機(jī)制，允許大家針對(duì)自己的特殊應(yīng)用進(jìn)行擴(kuò)充，下圖就是CUIT框架的體系結(jié)構(gòu)圖 。

圖3：CUIT框架的體系結(jié)構(gòu)

　　開發(fā)自動(dòng)化測(cè)試用例對(duì)于有效預(yù)防回歸問題的出現(xiàn)時(shí)非常必要，在實(shí)際應(yīng)用中應(yīng)該特別注意它的合理比例關(guān)系和靈活的策略，包括：自動(dòng)化用例和手工用例的比例、UI和非UI測(cè)試用例的比例關(guān)系。自動(dòng)化測(cè)試用例、執(zhí)行、分析和維護(hù)它們都是需要一定投入的，對(duì)于敏捷項(xiàng)目而言時(shí)間資源的緊缺尤為突出，所以在任何時(shí)候團(tuán)隊(duì)都要根據(jù)自身的資源，有選擇性進(jìn)行測(cè)試用例的自動(dòng)化，通常情況下應(yīng)該優(yōu)先自動(dòng)化那些高優(yōu)先級(jí)的測(cè)試用例。

　　對(duì)于UI和非UI的自動(dòng)化測(cè)試用例而言，應(yīng)該是以非UI 的單元測(cè)試和功能測(cè)試為主，UI測(cè)試未必要的補(bǔ)充。基于UI自動(dòng)化測(cè)試用例有它獨(dú)特優(yōu)點(diǎn)，例如：它從真實(shí)用戶角度出發(fā)進(jìn)行測(cè)試，即涵蓋了界面層、邏輯層和數(shù)據(jù)層，自動(dòng)化人員不需要了解被測(cè)試應(yīng)用的代碼實(shí)現(xiàn)細(xì)節(jié)等；但是相對(duì)于非UI測(cè)試它也有著先天的不足，包括：執(zhí)行速度相對(duì)比較慢、易受干擾不穩(wěn)定等。所以在自動(dòng)化過程中，能用非UI測(cè)試覆蓋的功能盡可能采用非UI的測(cè)試覆蓋，如：API單元測(cè)試等，UI測(cè)試用例只用來實(shí)現(xiàn)最基本用戶故事的驗(yàn)收測(cè)試（Acceptance Test）。

　　早測(cè)試和經(jīng)常測(cè)試——封閉簽入和滾動(dòng)生成

　　敏捷開發(fā)中最可怕的事情莫過于在迭代最后一兩天進(jìn)行測(cè)試，結(jié)果發(fā)現(xiàn)了嚴(yán)重功能缺陷或者回歸缺陷，導(dǎo)致不能按計(jì)劃發(fā)布給用戶試用。要想徹底解決這樣的問題，一方面要在迭代開發(fā)階段測(cè)試人員就要參與進(jìn)來，從客戶的角度出發(fā)對(duì)功能需求和設(shè)計(jì)文檔進(jìn)行文檔測(cè)試，即文檔評(píng)審。測(cè)試人員和開發(fā)還有項(xiàng)目經(jīng)理一起從源頭上保障將要實(shí)現(xiàn)的功能是用戶想要的。另一方面就是要在迭代的早期就開始就開始測(cè)試，特別前幾個(gè)迭代已經(jīng)實(shí)現(xiàn)好的自動(dòng)化測(cè)試用例，盡早的執(zhí)行它們可以有效地避免回歸問題的出現(xiàn)。在TFS 2010上專門提供封閉簽入（Gated Check-in）、滾動(dòng)生成（Rolling Builds）和持續(xù)集成（Continuous Integration）等功能，幫助敏捷團(tuán)隊(duì)實(shí)現(xiàn)早測(cè)試和經(jīng)常測(cè)試。這其中封閉簽入和滾動(dòng)生成是對(duì)敏捷團(tuán)隊(duì)比較實(shí)用的功能。

圖4：選擇簽入方式

　　封閉簽入是TFS 2010提供的一種新的代碼簽入方式，在配置這項(xiàng)功能后，當(dāng)用戶要簽入任何代碼時(shí)，系統(tǒng)會(huì)先將用戶本地要簽入的代碼打包成一個(gè)擱置集（shelve-set），然后提交到服務(wù)器端，TFS生成（Build）服務(wù)先從TFS源代碼控制器中同步項(xiàng)目的最新代碼，再將提交的代碼與之進(jìn)行自動(dòng)合并，然后進(jìn)行編譯，如果編譯成功，則執(zhí)行配置的自動(dòng)化測(cè)試用例，如果測(cè)試用例全部通過則代碼會(huì)被自動(dòng)簽入到代碼庫中，否則返回錯(cuò)誤信息給用戶，代碼是不會(huì)進(jìn)入到代碼庫。表面上看是與產(chǎn)品測(cè)試沒有直接關(guān)系，但實(shí)際上它和測(cè)試以及最終產(chǎn)品質(zhì)量的密不可分。

　　因?yàn)榇a簽入是整個(gè)開發(fā)過程中發(fā)生最為頻繁的操作，每次簽入代碼的質(zhì)量直接影響著日常的開發(fā)活動(dòng)。對(duì)于絕大多數(shù)的開發(fā)團(tuán)隊(duì)來說，check in代碼前不僅要保證編譯通過，同時(shí)還要最大限度的保證新代碼不會(huì)破壞已有的功能，也就是要執(zhí)行測(cè)試用例去驗(yàn)證。Gated Check-in中提到的“Build成功”，實(shí)際上包含兩部分內(nèi)容：編譯成功和測(cè)試用例執(zhí)行成功，有了它作為保護(hù)代碼庫的第一道屏障，就可以保證它在任何適合都是可編譯，并且達(dá)到一定質(zhì)量標(biāo)準(zhǔn)的。

　　滾動(dòng)生成是在VS 2008種就有的功能，當(dāng)TFS檢測(cè)到在它所監(jiān)控的范圍內(nèi)有任何新的代碼變化被簽入后，它就啟動(dòng)對(duì)最新的代碼庫進(jìn)行生成驗(yàn)證，該驗(yàn)證包括編譯和運(yùn)行指定的自動(dòng)化測(cè)試用例。之所以稱之為“滾動(dòng)”，因?yàn)樗窃谝粋€(gè)生成驗(yàn)證操作完成后再去探測(cè)有沒有新的簽入發(fā)生，對(duì)這期間發(fā)生的所有新簽入進(jìn)行新的生成驗(yàn)證。這里需要再強(qiáng)調(diào)一下滾動(dòng)生成的重要意義：它看似只是一個(gè)自動(dòng)生成代碼的功能，但實(shí)際上起著協(xié)調(diào)整個(gè)開發(fā)團(tuán)隊(duì)、時(shí)刻監(jiān)控代碼庫質(zhì)量、以及盡早暴露產(chǎn)品問題的作用。

　　因?yàn)闈L動(dòng)生成時(shí)刻都在不停的運(yùn)轉(zhuǎn)著，對(duì)于任何代碼簽入它都保持著警覺，會(huì)去自動(dòng)驗(yàn)證編譯是否成功，自動(dòng)化測(cè)試用例是否都能通過。它就像一個(gè)不知疲倦的“代碼守護(hù)者”一樣監(jiān)控著代碼庫，第一時(shí)間發(fā)現(xiàn)其中的任何問題，將問題通知給整個(gè)團(tuán)隊(duì)，從而避免了問題的積累和拖延。這非常符合敏捷開發(fā)中“今日問題今日解決，不要拖到以后”的原則，它幫你最早的發(fā)現(xiàn)問題、報(bào)告問題，開發(fā)團(tuán)隊(duì)則應(yīng)該建立制度要及時(shí)響應(yīng)滾動(dòng)生成所報(bào)告的問題，把它作為Priority 為0或1的高優(yōu)先級(jí)問題去對(duì)待和解決。

　　封閉簽入和滾動(dòng)生成都是來保護(hù)代碼庫的正確性和產(chǎn)品質(zhì)量，它們是否在功能上重復(fù)反而讓我們不敏捷了呢？其實(shí)兩者并不重復(fù)，只是各有側(cè)重，將它們搭配使用才會(huì)發(fā)揮其最大效能。封閉簽入是在代碼進(jìn)入代碼庫之前進(jìn)行驗(yàn)證，簽入提交者一般希望竟快知道結(jié)果，以便決定下一步的工作，所以封閉簽入的時(shí)間（編譯和運(yùn)行測(cè)試用例）不要太長（10-20分鐘）。這也就決定了我們加入的測(cè)試用例不能太多，只添加那些高優(yōu)先級(jí)的測(cè)試用例，保證主要的用戶故事不被破壞。

　　滾動(dòng)生成是在代碼簽入后在后臺(tái)執(zhí)行的，由于不存在著與用戶的交互等待，所以它執(zhí)行時(shí)間可以更長（幾個(gè)小時(shí)），可以為它加入更多的測(cè)試用例，從而全面驗(yàn)證代碼庫的質(zhì)量，一旦有任何問題它可以及時(shí)通知團(tuán)隊(duì)進(jìn)行修復(fù)，這種驗(yàn)證是在幾個(gè)小時(shí)或者每天都在發(fā)生的，保證了敏捷對(duì)頻繁測(cè)試的。

　　完整的自動(dòng)化測(cè)試解決方案——實(shí)驗(yàn)室管理

　　在談到軟件自動(dòng)化測(cè)試的時(shí)候，很多人會(huì)誤以為實(shí)現(xiàn)了自動(dòng)化測(cè)試用例就是自動(dòng)化測(cè)試，其實(shí)不然，自動(dòng)化測(cè)試僅是測(cè)試自動(dòng)化的一個(gè)重要步驟，絕對(duì)不等同于自動(dòng)化測(cè)試。一個(gè)完整的自動(dòng)化測(cè)試應(yīng)該包括：構(gòu)建、部署、執(zhí)行測(cè)試用例、分析測(cè)試結(jié)果并作出結(jié)論。在前面的自動(dòng)測(cè)試的收益公式中，我們可以看到減少自動(dòng)測(cè)試的維護(hù)成本，是提高自動(dòng)測(cè)試收益的重要因素之一。VS 2010的實(shí)驗(yàn)室管理（Lab Management）與測(cè)試用例管理、生成管理、源代碼控制、工作項(xiàng)管理等功能相結(jié)合，為自動(dòng)化測(cè)試提供了這樣一個(gè)完整的解決方案，目標(biāo)就是要降低了自動(dòng)測(cè)試的運(yùn)營和非維護(hù)成本，下面這張圖展示了實(shí)驗(yàn)室環(huán)境的系統(tǒng)構(gòu)架圖。

圖5：實(shí)驗(yàn)室環(huán)境的系統(tǒng)構(gòu)架圖

　　實(shí)驗(yàn)室管理功能充分利用了微軟的虛擬化技術(shù)，包括：Hyper-V和 System Center Virtual Machine Manager （SCVMM），快速創(chuàng)建干凈的虛擬測(cè)試環(huán)境并進(jìn)行產(chǎn)品生成和部署，然后執(zhí)行指定的測(cè)試用例集，將結(jié)果以報(bào)表的形式呈現(xiàn)出來，方便對(duì)此產(chǎn)品質(zhì)量進(jìn)行分析，如下圖所示：

圖6：虛擬測(cè)試環(huán)境

圖7：測(cè)試結(jié)果

　　同時(shí)，利用虛擬技術(shù)的環(huán)境快照功能，對(duì)于那些難于復(fù)現(xiàn)或者環(huán)境相關(guān)的Bug，利用虛擬環(huán)境的快照技術(shù)，可以為開發(fā)人員準(zhǔn)確的復(fù)現(xiàn)Bug出現(xiàn)的環(huán)境，從而能夠快速的進(jìn)行診斷和及時(shí)修復(fù)。

　　總結(jié)

　　Visual Studio 2010作為Visual Studio系列中一個(gè)非常重要的版本，為測(cè)試人員和團(tuán)隊(duì)提供了一整套解決方案，包括：測(cè)試計(jì)劃和用例管理、創(chuàng)建自動(dòng)化測(cè)試用例、測(cè)試用例的自動(dòng)執(zhí)行、以及實(shí)驗(yàn)室管理等。這些功能強(qiáng)調(diào)了測(cè)試作為整個(gè)軟件過程的重要角色的作用，促進(jìn)了測(cè)試人員與其它角色的有效溝通與協(xié)作，非常適合于敏捷團(tuán)隊(duì)使用來完成測(cè)試工作。

　　工具不是萬能的，但沒有合適的工具輔助也是萬萬不能的。對(duì)于工具在敏捷開發(fā)的作用，應(yīng)該用辯證的觀點(diǎn)來看待。不能片面唯工具論，畢竟軟件開發(fā)過程是人、工具和過程三者共同作用的結(jié)果，工具影響著人和過程，同時(shí)人和過程也影響著工具所能發(fā)揮的效力。所以這決定了工具的引入和部署應(yīng)該是一個(gè)漸進(jìn)的和逐步適應(yīng)的過程，特別是對(duì)Visual Studio 2010這樣比較大型和綜合性的工具。下面是三個(gè)向大家推薦的與Visual Studio測(cè)試相關(guān)的微軟論壇，希望能夠?qū)Υ蠹矣兴鶐椭?/p>

　　相關(guān)文章：應(yīng)用Visual Studio 2010輔助敏捷測(cè)試（上）

NET技術(shù)：應(yīng)用Visual Studio 2010輔助敏捷測(cè)試（下），轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。