破解敏捷測試的十大"神話(huà)"

對于敏捷測試，可定義如下：

項目中使用敏捷技術(shù)的相關(guān)測試實(shí)踐，開(kāi)發(fā)作為測試的顧客，強調測試先行的設計理念。在敏捷開(kāi)發(fā)中，測試被整合到整個(gè)開(kāi)發(fā)的生命周期中。

敏捷測試

敏捷將被越來(lái)越多的人所接受，這很容易理解，如果從開(kāi)發(fā)者和用戶(hù)的角度去看的話(huà)。

對于用戶(hù)，他們不愿意花費大量的時(shí)間被人盤(pán)問(wèn)關(guān)于整個(gè)系統的需求和過(guò)程，而且需要評審大量的規格說(shuō)明，而且開(kāi)發(fā)團隊可能會(huì )在后期拿著(zhù)這些規格說(shuō)明來(lái)與他們"對質(zhì)"。

對于開(kāi)發(fā)人員，他們希望發(fā)揮自己的想象空間和創(chuàng )意，不愿意遵循規格說(shuō)明的約束，尤其是在他們看到有更好的解決方案的時(shí)候。

#FormatImgID_0#

然而，對于QA人員來(lái)說(shuō)，敏捷意味著(zhù)什么呢？敏捷會(huì )給他們帶來(lái)諸多不便。在理想的世界里，他們會(huì )獲取一個(gè)"已完成"的產(chǎn)品來(lái)針對規格說(shuō)明進(jìn)行驗證�，F實(shí)中，他們被要求對"正在移動(dòng)"的目標進(jìn)行驗證，這是違背直覺(jué)的。這意味著(zhù)一些技術(shù)和自動(dòng)化的使用變得困難，需要新的測試方式。

所有敏捷方法都有一個(gè)共同點(diǎn)，就是它們對QA角色造成影響。

隨著(zhù)TDD（Test Driven Development）的出現，有人開(kāi)始質(zhì)疑QA存在的必要性（既然TDD的關(guān)鍵就是測試）。但是，最重要的問(wèn)題是QA需要直接全程參與到敏捷過(guò)程中，作為團隊的整體對測試進(jìn)行設計，與此同時(shí)，需要應對需求和解決方案的不斷演變。

QA需要知道敏捷方法論的真正影響，對業(yè)界關(guān)于敏捷測試的各種"神話(huà)"作出正確的詮釋和回應，以下列舉了10大著(zhù)名的"神話(huà)"：

神話(huà)1："你只需要單元測試就行了—TDD的測試是足夠的"

這顯然是不對的。即使是狂熱的敏捷開(kāi)發(fā)者也意識到需要包括很多其他的測試技術(shù)。例如，Scott W . Ambler就在他的FLOOT（Full Life Cycle Object-Oriented Testing）方法論中列舉了21種不同的測試技術(shù)，包括白盒測試、黑盒測試、回歸測試、壓力測試和用戶(hù)驗收測試（User Acceptance Testing），參見(jiàn)http://www.ambysoft.com/essays/floot.html

TDD中的程序員依賴(lài)這些測試來(lái)驗證他們代碼的正確性。如果需求（或者說(shuō)測試用例）沒(méi)有被正確地描述，那么你可能構建了足夠健壯的代碼，但是不能滿(mǎn)足目標。

因此，大部分敏捷項目包括調查性質(zhì)的測試（黑盒），用于補充白盒的測試。好的調查性質(zhì)的測試能盡早揭露開(kāi)發(fā)人員遺漏的問(wèn)題。

神話(huà)2："你可以重用單元測試來(lái)構建回歸測試套件"

有些TDD的追捧者提出傳統的測試不再需要，因為每一行代碼都有相應的單元測試用例了；他們認為，通過(guò)重新組合單元測試，可以替代從用戶(hù)驗收測試到回歸測試的所有測試類(lèi)型。

文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/

TAG: 破解 神話(huà)