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