破解敏捷測試的十大"神話"

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

項目中使用敏捷技術的相關測試實踐，開發作為測試的顧客，強調測試先行的設計理念。在敏捷開發中，測試被整合到整個開發的生命周期中。

敏捷測試

敏捷將被越來越多的人所接受，這很容易理解，如果從開發者和用戶的角度去看的話。

對于用戶，他們不愿意花費大量的時間被人盤問關于整個系統的需求和過程，而且需要評審大量的規格說明，而且開發團隊可能會在后期拿著這些規格說明來與他們"對質"。

對于開發人員，他們希望發揮自己的想象空間和創意，不愿意遵循規格說明的約束，尤其是在他們看到有更好的解決方案的時候。

#FormatImgID_0#

然而，對于QA人員來說，敏捷意味著什么呢？敏捷會給他們帶來諸多不便。在理想的世界里，他們會獲取一個"已完成"的產品來針對規格說明進行驗證�，F實中，他們被要求對"正在移動"的目標進行驗證，這是違背直覺的。這意味著一些技術和自動化的使用變得困難，需要新的測試方式。

所有敏捷方法都有一個共同點，就是它們對QA角色造成影響。

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

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

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

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

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

因此，大部分敏捷項目包括調查性質的測試（黑盒），用于補充白盒的測試。好的調查性質的測試能盡早揭露開發人員遺漏的問題。

神話2："你可以重用單元測試來構建回歸測試套件"

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

文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/

TAG: 破解 神話