解析敏捷測(cè)試的十大“神話”
對(duì)于敏捷測(cè)試，可定義如下：
項(xiàng)目中使用敏捷技術(shù)的相關(guān)測(cè)試實(shí)踐，開發(fā)作為測(cè)試的顧客，強(qiáng)調(diào) 測(cè)試先行的設(shè)計(jì)理念。在敏捷開發(fā)中，
測(cè)試被整合到整個(gè)開發(fā)的生命周期中。
敏捷測(cè)試
敏捷將被越來越多的人所 接受，這很容易理解，如果從開發(fā)者和用戶的角度去看的話。
對(duì)于用戶，他們不愿意花費(fèi)大量的時(shí)間 被人盤問關(guān)于整個(gè)系統(tǒng)的需求和過程，而且需要評(píng)審大量的規(guī)格說明，而且開發(fā)團(tuán)隊(duì)可能會(huì)在后期拿著這些規(guī)格說明來與他們"對(duì)質(zhì)"。
對(duì)于開發(fā)人員，他們希望發(fā) 揮自己的想象空間和創(chuàng)意，不愿意遵循規(guī)格說明的約束，尤其是在他們看到有更好的解決方案的時(shí)候。然而，對(duì)于QA人員來說，敏捷意味著什么呢？敏捷會(huì)給他們帶來諸多不 便。在理想的世界里，他們會(huì)獲取一個(gè)"已完成"的產(chǎn)品來針對(duì)規(guī)格說明進(jìn)行驗(yàn)證?，F(xiàn)實(shí)中，他們被要求對(duì)"正在移動(dòng)"的目標(biāo)進(jìn)行驗(yàn)證， 這是違背直覺的。這意味著一些技術(shù)和自動(dòng)化的使用變得困難，需要新的測(cè)試方式。
所有敏捷方法都有一個(gè)共同點(diǎn)，就是它們對(duì)QA角色造成影響。
隨著TDD（Test Driven Development）的出現(xiàn)，有人開 始質(zhì)疑QA存在的必要性（既然TDD的關(guān)鍵就是測(cè)試）。但是，最重要的問題是QA需要直接全程參與到敏捷過程中，作為團(tuán)隊(duì)的整體對(duì)測(cè)試進(jìn)行設(shè)計(jì)，與 此同時(shí)，需要應(yīng)對(duì)需求和解決方案的不斷演變。
QA需要知道敏捷方法論的真正影響，對(duì)業(yè)界關(guān)于敏捷 測(cè)試的各種"神話"作出正確的詮釋和回應(yīng)，以下列舉了10大著名的"神話"：
神話1："你只需要單元測(cè)試就行了—TDD的測(cè)試是足夠 的"這顯然是不對(duì)的。
即使是狂熱的敏捷開發(fā)者也意識(shí)到需要包括很多其他的測(cè)試技術(shù)。例如，Scott W . Ambler就在他的FLOOT（Full Life Cycle Object-Oriented Testing）方法論中列舉了21種不同的測(cè) 試技術(shù)，包括白盒測(cè)試、黑盒測(cè)試、回歸測(cè)試、壓力測(cè)試和用戶驗(yàn)收測(cè)試（UserAcceptance Testing）
TDD中的程序員依賴這些測(cè)試來驗(yàn)證他們代碼的正確性。如果需求（或者說測(cè)試用例）沒有被正確 地描述 ，那么你可能構(gòu)建了足夠健壯的代碼，但是不能滿足目標(biāo)。
因此，大部分敏捷項(xiàng)目包括調(diào)查性質(zhì) 的測(cè)試（黑盒），用于補(bǔ)充白盒的測(cè)試。好的調(diào)查性質(zhì)的測(cè)試能盡早揭露開發(fā)人員遺漏的問題。
神話2："你可以重用單元測(cè)試來構(gòu)建回歸測(cè)試套件 "
有些TDD的追捧者提出傳統(tǒng)的測(cè)試不再需要，因?yàn)槊恳恍写a都有相應(yīng)的單元測(cè)試用例了；他們認(rèn)為 ，通過重新組合單元測(cè)試，可以替代從用戶驗(yàn)收測(cè)試到回歸測(cè)試的所有測(cè)試類型。
雖然這聽起來很誘 人，但是這不現(xiàn)實(shí)，因?yàn)椋篢DD中開發(fā)的白盒的單元測(cè)試的粒度和目標(biāo)與黑盒測(cè)試有所區(qū)別。
單元測(cè)試的總體目標(biāo)是用于證明代碼是如預(yù)期般工作的，而回歸測(cè)試的目的是確保修改的 代碼不會(huì)引起非預(yù)期的結(jié)果。兩者存在的意義是不一樣的，例如，"檢查某個(gè)屬性的日期格式是正確的"，就與"對(duì)于給定的輸入，檢查其值具有預(yù)期的日期"不一樣。
神話3："我們不再需要測(cè)試人員 、或者自動(dòng)化工具"
專業(yè)的測(cè)試人員履行了不一樣的職責(zé)，與開發(fā)同僚們一樣是不可或缺的項(xiàng)目組角色之一。
不得不承認(rèn)：傳統(tǒng)的自動(dòng)化測(cè)試工具并沒有像廠商們所鼓吹的那樣神奇。但是這不意味著我們要放棄自動(dòng)化工具，我們?nèi)匀黄诖喔玫淖詣?dòng)化工具的出現(xiàn)。
神話4："有了單元測(cè)試 ，手工測(cè)試就沒有存在的必要性了"
手工測(cè)試時(shí)重復(fù)性的勞動(dòng)，代價(jià)高、繁瑣、容易出錯(cuò)。然而，雖然TDD能減少一定量的手工功能測(cè)試，它并不能廢除進(jìn)一步的黑盒測(cè)試的需要（無論是手工的還是自動(dòng)化的）。
通過自動(dòng)化的捕獲測(cè)試人 員的操作過程，并且將他們的鍵盤和鼠標(biāo)點(diǎn)擊事件文檔化，測(cè)試人員可以把更多的時(shí)間放在有趣的、增值的活動(dòng)上，例如測(cè)試那些自動(dòng)化很難實(shí)現(xiàn)，或者是根本不可能實(shí)現(xiàn)的復(fù)雜測(cè) 試場(chǎng)景。雖然通過手工測(cè)試尋找bug是一個(gè)耗時(shí)的、代價(jià)高昂的過程，但是如果不采用這種手段而遺漏了 BUG，代價(jià)會(huì)更高。
神話5："不再需要用戶驗(yàn)收測(cè)試"
在敏捷開發(fā)中，用戶驗(yàn)收敏捷測(cè)試通常用于與顧客一起解決"不正確的需求"的問題，而不是用于糾正功能問題。當(dāng)用戶最初定義需求時(shí)，他們是基于自己的初始想法和愿景來定義的。當(dāng)他們看到"活生生的" 真正的系統(tǒng)后，他們總是會(huì)有不同的、額外的需求。雖然敏捷測(cè)試方法可以減少這種情況發(fā)生的頻率，但是也不可能杜絕，因此也就不可避免地需要用戶驗(yàn)收測(cè)試。
神話6："自動(dòng)化是不可能的"
在敏捷項(xiàng)目的早期階段開展自動(dòng)化敏捷測(cè)試通常是很困難的，但是隨著系統(tǒng)的演進(jìn)，某些方面穩(wěn)定下來之后就 可以開始實(shí)施自動(dòng)化測(cè)試了。洞悉自動(dòng)化測(cè)試開展的正確時(shí)機(jī)并不容易，因此，使用某些技術(shù)， 讓早期的手工測(cè)試可以順利過渡到自動(dòng)化測(cè)試是很關(guān)鍵的。如果早期的測(cè)試設(shè)計(jì)和手工測(cè)試可以被很好地記錄下來，以備重用的話，后面的自動(dòng)化測(cè)試將大大受益。
神話7："開發(fā)人員擁有足夠的測(cè)試技巧"
如果測(cè)試是 很容易的，那么每個(gè)人都可以做，則每次我們都可以發(fā)布和交付優(yōu)質(zhì)的代碼。一個(gè)獨(dú)立的測(cè)試組的目標(biāo)是作為第三方、能夠從全局出發(fā)、驗(yàn)證和確認(rèn)軟件功能的質(zhì)量。而開發(fā)人員趨向于證明系統(tǒng)是正常工作的。一個(gè)好的測(cè)試者會(huì)傾向于"假設(shè)"某些場(chǎng)景的出現(xiàn)，再加上業(yè)務(wù)用戶的測(cè)試，則確保系統(tǒng)滿足預(yù)期目的將變得容易。雖然可能引起很多開發(fā)人員的爭(zhēng)辯，但是事實(shí)上很多開發(fā)人員不愿意花很多時(shí)間去先寫測(cè)試，然后開發(fā)代碼來證明測(cè)試通過了。
神話8："單元測(cè)試就是設(shè)計(jì)規(guī)格說明書"
無論你采 用哪一種開發(fā)模式，在開發(fā)代碼之前你都必須對(duì)需求進(jìn)行思考。雖然TDD的單元測(cè)試產(chǎn)物可以讓我們理解相當(dāng)一部分的設(shè)計(jì)規(guī)格說明，但是仍然存在差距。定義敏捷測(cè)試用例用于檢查需求并不是新鮮事。不管你采用的是什么開發(fā)模式，最重要的是針對(duì)每一項(xiàng)需求提出這樣的問題"我將如何測(cè)試它？"，這樣你的敏捷測(cè)試用例是在落實(shí)到代碼之前就被充分考慮過的，而不 是等待將來的"重構(gòu)"。
神話9："TDD適用于任何項(xiàng)目"
隨著項(xiàng)目規(guī)模的擴(kuò)大，執(zhí)行敏捷測(cè)試所需要的時(shí)間也在增加。這可以通過劃分項(xiàng)目和測(cè)試范圍來解決。但是無論如何都會(huì)導(dǎo)致測(cè)試運(yùn)行的頻率不一致，這樣就需要測(cè)試的計(jì)劃和測(cè)試執(zhí)行的管理，因此，除了白盒測(cè)試，我們還需要考慮以下幾種測(cè)試：
集成測(cè)試 - "我需要運(yùn)行哪些測(cè)試來確保新的代碼與其關(guān)聯(lián)的 代碼有效地工作在一起？"
系統(tǒng)測(cè)試 - "新的代碼在系統(tǒng)層面的功能是夠正確，與其他系統(tǒng)工作在一 起的流程是否正確?"
回歸測(cè)試 - "我需要隔多久運(yùn)行一次回歸測(cè)試來確保新的代碼沒有造成非預(yù)期的 影響？"自動(dòng)化的回歸測(cè)試為敏捷開發(fā)提供了一張安全網(wǎng)。
用戶驗(yàn)收測(cè)試 - "TDD不僅需要確保某項(xiàng)功能正確地工作了，還 要確保它們對(duì)于業(yè)務(wù)用戶來說是可接受的。"
然而，隨著項(xiàng)目組的擴(kuò)大，測(cè)試的"自我文檔化"（self-documenting）不再可接受，因?yàn)閰⑴c的項(xiàng)目組成員越多，不同的人對(duì)需求的不同理解，項(xiàng)目的風(fēng)險(xiǎn)隨之增加。
隨著項(xiàng)目規(guī)模增加，需要開發(fā)的測(cè)試代碼也大大增加，測(cè)試代碼的維護(hù)工作量也大大增加，對(duì)測(cè)試自動(dòng)化的需求也在增加，需要更多的自動(dòng)化測(cè)試用于縮短每個(gè)測(cè)試周期的時(shí)間。
神話 10："開發(fā)人員和測(cè)試人員是水火不相容的"
長(zhǎng)久以來，開發(fā)和測(cè)試之間存在"你我之分"的緊張局面。這其實(shí)會(huì)是一種"共生共贏"的健康關(guān)系，如果能很好地一起正確地工作的話，這種關(guān)系可以為顧客產(chǎn)生更高的產(chǎn)品交付質(zhì)量。
討論的焦點(diǎn)應(yīng)該集中在：
· 交付的軟件需要滿足業(yè)務(wù)目標(biāo)（滿足需求、按時(shí)、控制成本），而不是討論誰擁有哪一部 分流程的權(quán)責(zé)問題。
· 測(cè)試人員在需求收集階段可以做出什么貢獻(xiàn)？如何讓他們更好地融入到TDD的過程中 。
· 測(cè)試人員如何最大化地重用開發(fā)過程中產(chǎn)生的各項(xiàng)"資產(chǎn)"？
· 在TDD中是否有一個(gè)"傳統(tǒng)測(cè) 試人員"的角色？或者他們是否需要像開發(fā)人員一樣掌握新的技術(shù)來適應(yīng)新的開發(fā)模式？
· 在新的開發(fā)和測(cè)試工具中，開發(fā)人員和測(cè)試人員如何互相找到自己需要的東西？
結(jié)論
敏捷項(xiàng)目其實(shí)是QA領(lǐng)導(dǎo)敏捷過程的一個(gè)絕佳機(jī)會(huì)；誰是用戶和開發(fā)者之間的最佳橋梁，能理解各方面的需要，如何達(dá)成以及如何在開發(fā)之前就得到保證？
QA除了繼續(xù)在確保整個(gè)系統(tǒng)的演進(jìn)滿足業(yè)務(wù)目標(biāo) 和需求外，應(yīng)該對(duì)"如何"和"結(jié)果"兩方面都投入自己的興趣。但是這同時(shí)對(duì)QA提出了新的要求，他們必須自己"敏捷"起來，拋棄舊的模式，專注于應(yīng)用新的技術(shù)來優(yōu)化敏捷測(cè)試的策略。
【編輯推薦】
