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