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

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

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

　　敏捷測試

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

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

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

　　然而，對于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的追捧者提出傳統的測試不再需要，因為每一行代碼都有相應的單元測試用例了;他們認為，通過重新組合單元測試，可以替代從用戶驗收測試到回歸測試的所有測試類型。

　　雖然這聽起來很誘人，但是這不現實，因為：TDD中開發的白盒的單元測試的粒度和目標與黑盒測試有所區別。

　　單元測試的總體目標是用于證明代碼是如預期般工作的，而回歸測試的目的是確保修改的代碼不會引起非預期的結果。兩者存在的意義是不一樣的，例如，"檢查某個屬性的日期格式是正確的"，就與"對于給定的輸入，檢查其值具有預期的日期"不一樣。

　　神話3："我們不再需要測試人員、或者自動化工具"

　　專業的測試人員履行了不一樣的職責，與開發同僚們一樣是不可或缺的項目組角色之一。

　　不得不承認：傳統的自動化測試工具并沒有像廠商們所鼓吹的那樣神奇。但是這不意味著我們要放棄自動化工具，我們仍然期待更多更好的自動化工具的出現。

　　神話4："有了單元測試，手工測試就沒有存在的必要性了"

　　手工測試時重復性的勞動，代價高、繁瑣、容易出錯。然而，雖然TDD能減少一定量的手工功能測試，它并不能廢除進一步的黑盒測試的需要(無論是手工的還是自動化的)。

　　通過自動化的捕獲測試人員的操作過程，并且將他們的鍵盤和鼠標點擊事件文檔化，測試人員可以把更多的時間放在有趣的、增值的活動上，例如測試那些自動化很難實現，或者是根本不可能實現的復雜測試場景。雖然通過手工測試尋找bug是一個耗時的、代價高昂的過程，但是如果不采用這種手段而遺漏了BUG，代價會更高。

原文轉自：http://www.uml.org.cn/Test/200907026.asp