建站
咨詢
售后
建站咨詢
新聞中心
敏捷軟件開發(fā)是近些年來比較熱門的話題，《敏捷宣言》四條主要精神和十二條基本準(zhǔn)則概括了敏捷開發(fā)的基本思想。圍繞著這些基本概念和思想，產(chǎn)生了一系列的輕量級(jí)方法，如：極限編程、測(cè)試驅(qū)動(dòng)開發(fā)、Scrum、特性驅(qū)動(dòng)開發(fā)等。雖然具體名稱、過程和側(cè)重點(diǎn)不盡相同，但是相對(duì)于非敏捷的開發(fā)方法而言，它們都更強(qiáng)調(diào)面對(duì)面的溝通、團(tuán)隊(duì)不同角色之間的緊密協(xié)作、頻繁交付新的可用的軟件版本、緊湊而自我組織型的團(tuán)隊(duì)等。敏捷開發(fā)只是提供了一個(gè)思想和方法論，而要在實(shí)際的工程中正確運(yùn)用它，并真正顯現(xiàn)出它的優(yōu)點(diǎn)和產(chǎn)生實(shí)際的效果，這對(duì)于每個(gè)團(tuán)隊(duì)而言一開始都是一個(gè)挑戰(zhàn)，尤其是對(duì)那些那些習(xí)慣了傳統(tǒng)瀑布模式的團(tuán)隊(duì)。
敏捷是整個(gè)團(tuán)隊(duì)的敏捷，不只是團(tuán)隊(duì)中某個(gè)角色或者某個(gè)階段的敏捷，開發(fā)、測(cè)試和項(xiàng)目經(jīng)理等所有角色都要敏捷起來。敏捷方法的采用對(duì)團(tuán)隊(duì)每個(gè)成員都提出了新的挑戰(zhàn)，尤其是測(cè)試人員。之所以這樣說，是因?yàn)橄鄬?duì)于傳統(tǒng)的瀑布模型，敏捷開發(fā)所要求的頻繁交付，給測(cè)試所留出的時(shí)間更為緊迫，要求測(cè)試人員更早的介入和更及時(shí)地完成測(cè)試任務(wù)。如何在這么短的時(shí)間內(nèi)完成測(cè)試的計(jì)劃和實(shí)施呢？如何有效地避免回歸問題的出現(xiàn)？手工測(cè)試人員如何能更好的融入到敏捷團(tuán)隊(duì)？等等問題接踵而至，這都需要需要測(cè)試人員不斷的思考和嘗試。
無論是哪種開發(fā)模式，軟件的開發(fā)過程都可以歸結(jié)為：人、工具和過程這三個(gè)因素，三者的有機(jī)結(jié)合才能更高效的完成任務(wù)。有人會(huì)說：《敏捷宣言》四條主旨精神的第一條就是“個(gè)體和交互重于過程和工具”，工具還有那么重要嗎？回答是肯定的，工具很重要，這條主旨所提到的是“重于”而不是不要。為了支持敏捷開發(fā)，Visual Studio 2010（以下簡(jiǎn)稱為VS 2010）應(yīng)用程序生命周期管理中引入了 MSF for Agile Software Development v5.0 過程模板，用于輔助敏捷團(tuán)隊(duì)在實(shí)際工程中進(jìn)行敏捷實(shí)踐，它支持Scrum 敏捷開發(fā)過程框架。本文將從工具角度出發(fā)， 介紹Visual Studio 2010 如何幫助測(cè)試人員更勝任敏捷項(xiàng)目中的測(cè)試工作。對(duì)于工具與人的關(guān)系而言，好的工具應(yīng)該是將人從重復(fù)和機(jī)械的勞動(dòng)中解脫出來，讓人有更多的精力和時(shí)間花在有創(chuàng)造性地勞動(dòng)上，而由工具去完成將繁瑣和冗余的事務(wù)性操作；而對(duì)于工具和過程的關(guān)系，工具是過程能夠得到確實(shí)落實(shí)和準(zhǔn)確執(zhí)行的基石，很多時(shí)候我們總是依賴于人去執(zhí)行某個(gè)過程或者流程要求，但人的執(zhí)行往往帶有一定不穩(wěn)定性和主觀性，而工具則可以幫助我們準(zhǔn)確客觀的執(zhí)行。
一、團(tuán)隊(duì)有效協(xié)作的基石——Team Foundation Server
敏捷開發(fā)強(qiáng)調(diào)人與人之間的有效溝通和緊密的團(tuán)隊(duì)協(xié)作。對(duì)于測(cè)試團(tuán)隊(duì)和測(cè)試人員而言，首先應(yīng)該需要考慮的是：如何讓測(cè)試工作更有效的集成整個(gè)敏捷開發(fā)的活動(dòng)中去？而不是將測(cè)試工作僅作為一個(gè)“附件”或者可有可無的副產(chǎn)品。當(dāng)然，這會(huì)受到團(tuán)隊(duì)組織形式和開發(fā)過程的限制，例如：采用功能小組模型的團(tuán)隊(duì)，所有角色成員（PM、開發(fā)人員、測(cè)試人員）隸屬于同一個(gè)功能團(tuán)隊(duì)，客觀上其溝通就更為方便；而對(duì)于采用縱向按職能劃分團(tuán)隊(duì)的公司而言，測(cè)試和開發(fā)在隸屬關(guān)系上是分開的，相對(duì)在溝通上障礙就會(huì)更多些。無論是哪種組織形式，好的工具能幫助促進(jìn)和統(tǒng)一各個(gè)角色間的信息互通和共享，而不是要讓他們彼此之間更為孤立、工作在各自的一畝三分地（Silo）中。Team Foundation Server 2010（以下簡(jiǎn)稱為TFS 2010）就是這樣的工具，作為整個(gè)團(tuán)隊(duì)協(xié)作的核心，它統(tǒng)一了團(tuán)隊(duì)不同角色信息、實(shí)現(xiàn)了信息之間的有效互聯(lián)互通、彼此之間的共享和關(guān)聯(lián)，例如：TFS 2010 定義6 種默認(rèn)的工作項(xiàng)類型，如下圖所示。
其中，Test Case 和 Shared Steps 是2010 專門為測(cè)試新加入的。不要小看這些工作項(xiàng)，它們之間有著豐富的關(guān)聯(lián)關(guān)系，這種關(guān)系背后所代表是角色之間的關(guān)系。對(duì)于測(cè)試而言，它將測(cè)試和團(tuán)隊(duì)緊密的結(jié)合在一起。例如：Test Case 工作項(xiàng)用來詳細(xì)定義和管理測(cè)試用例，它還可以和User Story 相關(guān)聯(lián)，也就是將測(cè)試和用戶需求進(jìn)行了關(guān)聯(lián)，用戶可以從需求追溯到覆蓋的它的測(cè)試用例，這背后體現(xiàn)的是測(cè)試人員和需求人員/PM 的協(xié)作；Test Case 還可以與Bug關(guān)聯(lián)，通過這種關(guān)聯(lián)可以挖掘出哪些 Bug 被測(cè)試用例覆蓋，哪些還沒有，這種關(guān)聯(lián)體現(xiàn)了測(cè)試人員與開發(fā)人員的寫作，如果是自動(dòng)化測(cè)試用例，則體現(xiàn)了手工測(cè)試人員和自動(dòng)化工程師的協(xié)作 ；Bug 還可以可以和簽入集（Change-set）關(guān)聯(lián)，可以找到為了修復(fù)Bug，開發(fā)人員修改過哪些產(chǎn)品代碼，這體現(xiàn)了測(cè)試人員和開發(fā)的關(guān)聯(lián)。
敏捷開發(fā)頻繁的迭代和較短的迭代周期，對(duì)項(xiàng)目管理的精確性、透明性和可見性都提出了更高的要求， 尤其對(duì)于那些項(xiàng)目復(fù)雜和人員較多的團(tuán)隊(duì)。Task 是另一個(gè)重要的工作項(xiàng)類型，它用于管理開發(fā)過過程中的所有任務(wù)項(xiàng)，包括：開發(fā)、測(cè)試以及需求等任務(wù)，統(tǒng)一管理開發(fā)中的所有任務(wù)，統(tǒng)一計(jì)算項(xiàng)目的開銷和剩余工作量等。例如，項(xiàng)目的燃盡圖就是由它產(chǎn)生出來的。現(xiàn)在，人們雖然在理論和概念上已經(jīng)非常認(rèn)同軟件測(cè)試的在工程中的重要地位，但在具體實(shí)際操作中，測(cè)試卻仍然被看作是低于開發(fā)和需求分析等的“二等公民”。當(dāng)然這是由于多方面的綜合因素造成的，從管理技術(shù)角度講，這是由于測(cè)試工作本身缺乏可度量性和可見性，從導(dǎo)致了測(cè)試工作的透明性的缺失，團(tuán)隊(duì)往往看不到測(cè)試工作的進(jìn)度和所帶來的成果，從而意識(shí)不到測(cè)試的真正作用。對(duì)于測(cè)試人員自身而言，缺乏可度量性也讓自己無法對(duì)工作進(jìn)度準(zhǔn)確把握，進(jìn)而失去了對(duì)自己工作的目標(biāo)感和認(rèn)同感。將測(cè)試工作同其他工作一樣的用Task 工作項(xiàng)管理起來，增加了它的可度量性和可見性。將測(cè)試工作和其它任務(wù)一起統(tǒng)籌，時(shí)刻確保測(cè)試被作為整體中的一部分進(jìn)行考慮，所有的測(cè)試任務(wù)都被作為Task 工作項(xiàng)記錄下來，例如：編寫測(cè)試計(jì)劃、設(shè)計(jì)測(cè)試用例、自動(dòng)化測(cè)試用例等等，每項(xiàng)任務(wù)都有三個(gè)默認(rèn)時(shí)間估計(jì)數(shù)據(jù)需要填寫，它們是：Original Estimate、Remaining 和Completed，分別代表了任務(wù)的預(yù)估時(shí)間、剩余工作量和完成工作量。
為了增強(qiáng)敏捷過程的透明性和可見性，TFS 2010 定義了很多的報(bào)表和儀表板（Dashboard），它們會(huì)自動(dòng)生成各種報(bào)表，以可見的方式描述敏捷項(xiàng)目的健康狀況，這其中就有很多反映測(cè)試工作的報(bào)表，如下面所示。Stories Overview 展示了用戶故事的進(jìn)展情況，包括了每個(gè)用戶故事的測(cè)試用例覆蓋數(shù)量和執(zhí)行結(jié)果，以及相應(yīng)的Bug 數(shù)量；Test Dashboard 顯示了測(cè)試用例的狀態(tài)，包括正在設(shè)計(jì)的用例以及設(shè)計(jì)完畢可以執(zhí)行的用例數(shù)量，現(xiàn)實(shí)當(dāng)前Bug 的狀況，包括未被修復(fù)和以修復(fù)Bug 的數(shù)量。
二、集成測(cè)試環(huán)境 – Microsoft Test Manager
在過去的十幾年中，為了適應(yīng)了軟件項(xiàng)目的復(fù)雜度和規(guī)模的不斷膨脹，軟件開發(fā)工具和框架得到了長(zhǎng)足的發(fā)展，而測(cè)試工具則始終是塊短板 ，特別是對(duì)于那些需要手工完成的測(cè)試任務(wù)而言，進(jìn)展就更為緩慢，例如：現(xiàn)在很多團(tuán)隊(duì)仍然使用Word或者Excel這樣“原始”工具來管理測(cè)試用例。通過對(duì)業(yè)界的調(diào)查和分析，我們發(fā)現(xiàn)70%的軟件測(cè)試工作仍然是通過手工或者簡(jiǎn)單的腳本來完成的，在測(cè)試團(tuán)隊(duì)中不具備編程能力和僅有基本腳本編寫能力的測(cè)試人員仍然是測(cè)試的主力。
要讓你的項(xiàng)目敏捷起來，對(duì)于那些仍以手工測(cè)試為主的團(tuán)隊(duì)而言是一個(gè)非常大的挑戰(zhàn)，如何提高手工測(cè)試工作的效率將是實(shí)現(xiàn)敏捷的成敗關(guān)鍵。在VS 2010中，微軟首次為測(cè)試人員設(shè)計(jì)了一款專用的集成測(cè)試環(huán)境，稱為微軟測(cè)試管理器2010（Microsoft Test Manager 2010，以下簡(jiǎn)稱為MTM）。之所以稱之為集成測(cè)試環(huán)境，是因?yàn)镸TM的功能涵蓋了測(cè)試計(jì)劃、測(cè)試用例、手動(dòng)測(cè)試用例的執(zhí)行和錄制回放、自動(dòng)測(cè)試用例執(zhí)行、創(chuàng)建信息豐富的Bug、驗(yàn)證Bug、以及與測(cè)試實(shí)驗(yàn)室管理相關(guān)的對(duì)策是自動(dòng)化相關(guān)的功能等。下圖展示的是MTM測(cè)試計(jì)劃的操作界面，它以樹形的層次結(jié)構(gòu)來組織測(cè)試用例。
《敏捷序言》強(qiáng)調(diào)：“可工作的軟件重于完備的文檔”，那么是不是意味著敏捷測(cè)試也不需要測(cè)試計(jì)劃呢？當(dāng)然不是。敏捷的本質(zhì)是要去除軟件過程所有造成時(shí)間浪費(fèi)地方，不需要的是那些動(dòng)輒就幾十或上百頁的文檔。敏捷對(duì)文檔要求是要簡(jiǎn)明扼要，一兩頁列出測(cè)試要點(diǎn)計(jì)劃還是必須的，較短迭代周期（1-4周）也不可能要求文檔面面俱到。敏捷需要更快的對(duì)功能進(jìn)行驗(yàn)證，是不是不需要編寫測(cè)試用例直接根據(jù)用戶故事或者功能需求進(jìn)行探索性測(cè)試就可以了？當(dāng)然也不是。功能需求和用戶故事勾畫出的是一棵大樹軀干和主要枝杈，而那測(cè)試用例則不但要準(zhǔn)確描述出軀干和主枝，還要描述出細(xì)小的枝杈和綠葉的正確位置。從某種意義上講，測(cè)試用例在敏捷中的作用和地位應(yīng)該更為加強(qiáng)，它扮演著詳細(xì)功能文檔的角色。功能需求和設(shè)計(jì)文檔可以簡(jiǎn)單，但測(cè)試用例可不是這樣，相反我認(rèn)為敏捷對(duì)測(cè)試用例的設(shè)計(jì)和管理要求更高。
每個(gè)迭代周期，團(tuán)隊(duì)都會(huì)專注于實(shí)現(xiàn)不同的產(chǎn)品功能，用戶故事雖然描述了功能的內(nèi)容，但并不足以覆蓋所有相關(guān)的內(nèi)容。很多由用戶故事展開和關(guān)聯(lián)的功能一般在文檔中會(huì)體現(xiàn)出來，需要測(cè)試人員在早期圍繞著用戶故事測(cè)試展開需求文檔測(cè)試（需求評(píng)審），已明確那些未嚴(yán)格定義出來的內(nèi)容，以測(cè)試用例的形式明確和記錄下來。由1個(gè)簡(jiǎn)單用戶故事就有可能擴(kuò)展為1+N用戶可能執(zhí)行的執(zhí)行片段，也就我們測(cè)試用例。當(dāng)你有M個(gè)用故事，需要Ｍ個(gè)迭代周期來完成產(chǎn)品，那么就會(huì)有 ( M + N1 + N2 … + NM) 個(gè)測(cè)試用例，不把它們落實(shí)到筆頭上，很容易就會(huì)丟失一些重要的測(cè)試細(xì)節(jié)。此外，在敏捷方法中需求變化比較快，隨著多個(gè)迭代的深入，文檔的變化往往趕不上產(chǎn)品功能的變化，這時(shí)唯一能夠趕上這個(gè)變化的只有測(cè)試用例，應(yīng)為只有它準(zhǔn)確地反映了產(chǎn)品的變化，否則測(cè)試用例就是無法通過的。
在MTM 中，測(cè)試用例被分類至各個(gè)測(cè)試用例集，結(jié)構(gòu)十分清晰。測(cè)試用例只是邏輯上從屬于某個(gè)測(cè)試用例集，并沒有物理從屬關(guān)系，即一個(gè)測(cè)試用例可以同時(shí)被分在多個(gè)測(cè)試用例集內(nèi)，比如某個(gè)測(cè)試用例性質(zhì)上是一個(gè)性能測(cè)試，但是由于該用戶故事的訴求就是性能改進(jìn)，我們也就很自然得可以將其作為該用戶故事的驗(yàn)收測(cè)試，此時(shí)我們就可以將此測(cè)試用例添加到驗(yàn)收測(cè)試和性能測(cè)試兩個(gè)測(cè)試用例集中；另一個(gè)例子是給每個(gè)用戶故事都定義了不少測(cè)試，這些測(cè)試用例都應(yīng)該能在用戶故事測(cè)試用例集下找到，但是這些測(cè)試既可能是手動(dòng)測(cè)試也可能是自動(dòng)化測(cè)試用例，所以它們又會(huì)被本別歸類至這兩個(gè)測(cè)試用例集。在這種邏輯分類的支持下，我們可以很容易的根據(jù)需要指定運(yùn)行測(cè)試集中一部分測(cè)試用例。比如，我們可以定義一個(gè)簽入測(cè)試的測(cè)試用例集，挑選最基本的若干個(gè)測(cè)試置入其中，這樣在每次簽入前通過運(yùn)行這個(gè)測(cè)試用例集就能幫助我們確保簽入的代碼不至于破壞最基本的功能，即保證了版本隨時(shí)可運(yùn)行可測(cè)試，這無疑為測(cè)試帶來了更多的方便。具體如何創(chuàng)建測(cè)試用例集的結(jié)構(gòu)，團(tuán)隊(duì)可以根據(jù)自己項(xiàng)目的特點(diǎn)，靈活運(yùn)用此功能，制定分類規(guī)則以提高工作的效率。
很多測(cè)試團(tuán)隊(duì)仍然在使用Word或者是Excel管理測(cè)試用例，有些是使用專門的測(cè)試用例管理工具，使用獨(dú)立的數(shù)據(jù)庫(kù)來存儲(chǔ)測(cè)試用例信息。MTM相對(duì)于這些工具的優(yōu)點(diǎn)在于，它的所有數(shù)據(jù)都是存儲(chǔ)在TFS上，測(cè)試用例使用的是Test Case工作項(xiàng)。由于同存儲(chǔ)在TFS 上，所以可以輕松的實(shí)現(xiàn)與其它數(shù)據(jù)項(xiàng)的關(guān)聯(lián)，例如：在上一部分我們介紹的不同類型工作項(xiàng)之間關(guān)聯(lián)，此外還可以把Test Case與代碼關(guān)聯(lián)，即將測(cè)試用例與自動(dòng)化測(cè)試代碼關(guān)聯(lián)。這樣在MTM中，也可以直接管理和運(yùn)行自動(dòng)化測(cè)試用例，使MTM兼具了管理手工測(cè)試用例和自動(dòng)化測(cè)試用例的能力。
探索性測(cè)試（Exploratory Testing）是測(cè)試人員在對(duì)被測(cè)試系統(tǒng)的功能進(jìn)行不斷了解和學(xué)習(xí)的過程中進(jìn)行測(cè)試，包括：設(shè)計(jì)測(cè)試用例、執(zhí)行測(cè)試、以及匯報(bào)測(cè)試結(jié)果。與傳統(tǒng)的測(cè)試相比，它不需要事先定義好的齊備的測(cè)試文檔，更強(qiáng)調(diào)測(cè)試人員在對(duì)系統(tǒng)不斷地學(xué)習(xí)中，邊了解邊測(cè)試，它在很大程度上給測(cè)試人員更多地自由和想象空間，充分發(fā)揮他們的創(chuàng)造力，在不斷地學(xué)習(xí)中找到測(cè)試的靈感和快樂。這種測(cè)試的靈感和快樂對(duì)于組建和培養(yǎng)一支熱愛測(cè)試的團(tuán)隊(duì)是非常非常重要，它會(huì)讓測(cè)試人員覺得自己不是執(zhí)行重復(fù)測(cè)試勞動(dòng)機(jī)器，而是一個(gè)有著創(chuàng)造力和靈光的團(tuán)隊(duì)成員。MTM也支持探索測(cè)試功能，用戶可以使用MTM創(chuàng)建一個(gè)僅有一個(gè)測(cè)試步驟的測(cè)試用例，然后執(zhí)行它，Test Runner工具會(huì)輔助執(zhí)行手動(dòng)測(cè)試。它會(huì)記錄下所有用戶的操作，一旦發(fā)現(xiàn)有Bug時(shí)候，可以直接選擇‘Create exploratory bug’直接創(chuàng)建一個(gè)Bug。
Bug是測(cè)試工作最重要的產(chǎn)出之一，也是測(cè)試和開發(fā)人員之間重要接觸點(diǎn)。每個(gè)提交的Bug都應(yīng)該詳細(xì)記錄下如何重現(xiàn)（reproduce）的步驟，這是衡量Bug質(zhì)量的重要因素之一。因?yàn)椴豢芍噩F(xiàn)的Bug是沒有意義的，只會(huì)耽誤開發(fā)人員和項(xiàng)目經(jīng)理的時(shí)間。偶爾出現(xiàn)不可重現(xiàn)的Bug還是可以理解的，但如果經(jīng)常出現(xiàn)，那就會(huì)引來開發(fā)人員的抱怨和不滿，久而久之會(huì)造成開發(fā)和測(cè)試之間的不信任。好的Bug應(yīng)該是有清晰和詳細(xì)的重現(xiàn)步驟，期望的結(jié)果和實(shí)際得到結(jié)果，并提供盡可能多的信息，例如：出現(xiàn)問題的產(chǎn)品版本編號(hào)、語言、操作系統(tǒng)的版本以及日志信息等。大多數(shù)情況下，用文字進(jìn)行描述的內(nèi)容就可以了，但如果能配上一張問題現(xiàn)場(chǎng)截圖，或者對(duì)于更為復(fù)雜的Bug，配上一段小的錄像，這樣的Bug會(huì)給開發(fā)人員快速診斷和修復(fù)產(chǎn)品問題帶來很大幫助，大大提升測(cè)試和開發(fā)人員之間的協(xié)作效率，避免了不可重現(xiàn)Bug在開發(fā)和測(cè)試之間推來推去的“Bug乒乓”現(xiàn)象。然而要收工創(chuàng)建這樣一個(gè)信息豐富的Bug，是需要很多時(shí)間的。MTM提供了這樣的功能為幫助測(cè)試人員創(chuàng)建這樣高質(zhì)量Bug，它實(shí)現(xiàn)了多種診斷數(shù)據(jù)適配器（Diagnostic Data Adapters），在測(cè)試確認(rèn)Bug的過程中，這些適配器會(huì)在后臺(tái)運(yùn)行收集大量的數(shù)據(jù)，包括：執(zhí)行操作、系統(tǒng)配置、IntelliTrace已經(jīng)操作過程的錄像等，當(dāng)測(cè)試人員要?jiǎng)?chuàng)建一個(gè)Bug時(shí)，這些信息會(huì)被自動(dòng)添加的Bug中，如下圖所示，測(cè)試僅需填寫很少的內(nèi)容就可以創(chuàng)建好一個(gè)信息豐富的Bug。
三、實(shí)現(xiàn)自動(dòng)化測(cè)試用例 – 自動(dòng)化測(cè)試用例框架
隨著需求的不斷變化和迭代的深入，代碼庫(kù)不可避免的會(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è)試就是合算的；否則，就是不合算的。
這其中，開發(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è)試用例，如下圖所示。
這些測(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，以下簡(jiǎn)稱為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)圖 。
開發(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ǔ)充?；赨I自動(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）。
本文收錄于2010年InfoQ中國(guó)《架構(gòu)師》7月刊 “Visual Studio 2010之美”，作者：軟件測(cè)試開發(fā)工程師 周京生。
文章標(biāo)題：VisualStudio2010輔助敏捷測(cè)試詳解
本文路徑：http://www.dlmjj.cn/article/dpcoohd.html
