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

　　神話5："不再需要用戶驗收測試"

　　在敏捷開發中，用戶驗收測試通常用于與顧客一起解決"不正確的需求"的問題，而不是用于糾正功能問題。

　　當用戶最初定義需求時，他們是基于自己的初始想法和愿景來定義的。當他們看到"活生生的"真正的系統后，他們總是會有不同的、額外的需求。雖然敏捷方法可以減少這種情況發生的頻率，但是也不可能杜絕，因此也就不可避免地需要用戶驗收測試。

　　神話6："自動化是不可能的"

　　在敏捷項目的早期階段開展自動化測試通常是很困難的，但是隨著系統的演進，某些方面穩定下來之后就可以開始實施自動化測試了。

　　洞悉自動化測試開展的正確時機并不容易，因此，使用某些技術，讓早期的手工測試可以順利過渡到自動化測試是很關鍵的。如果早期的測試設計和手工測試可以被很好地記錄下來，以備重用的話，后面的自動化測試將大大受益。

　　神話7："開發人員擁有足夠的測試技巧"

　　如果測試是很容易的，那么每個人都可以做，則每次我們都可以發布和交付優質的代碼。一個獨立的測試組的目標是作為第三方、能夠從全局出發、驗證和確認軟件功能的質量。而開發人員趨向于證明系統是正常工作的。一個好的測試者會傾向于"假設"某些場景的出現，再加上業務用戶的測試，則確保系統滿足預期目的將變得容易。

　　雖然可能引起很多開發人員的爭辯，但是事實上很多開發人員不愿意花很多時間去先寫測試，然后開發代碼來證明測試通過了。

　　神話8："單元測試就是設計規格說明書"

　　無論你采用哪一種開發模式，在開發代碼之前你都必須對需求進行思考。雖然TDD的單元測試產物可以讓我們理解相當一部分的設計規格說明，但是仍然存在差距。

　　定義測試用例用于檢查需求并不是新鮮事。不管你采用的是什么開發模式，最重要的是針對每一項需求提出這樣的問題"我將如何測試它?"，這樣你的測試用例是在落實到代碼之前就被充分考慮過的，而不是等待將來的"重構"。

　　神話9："TDD適用于任何項目"

　　隨著項目規模的擴大，執行測試所需要的時間也在增加。這可以通過劃分項目和測試范圍來解決。但是無論如何都會導致測試運行的頻率不一致，這樣就需要測試的計劃和測試執行的管理，因此，除了白盒測試，我們還需要考慮以下幾種測試：

　　集成測試 - "我需要運行哪些測試來確保新的代碼與其關聯的代碼有效地工作在一起?"

　　系統測試 - "新的代碼在系統層面的功能是夠正確，與其他系統工作在一起的流程是否正確?"

　　回歸測試 - "我需要隔多久運行一次回歸測試來確保新的代碼沒有造成非預期的影響?"自動化的回歸測試為敏捷開發提供了一張安全網。

　　用戶驗收測試 - "TDD不僅需要確保某項功能正確地工作了，還要確保它們對于業務用戶來說是可接受的。"

　　然而，隨著項目組的擴大，測試的"自我文檔化"(self-documenting)不再可接受，因為參與的項目組成員越多，不同的人對需求的不同理解，項目的風險隨之增加。

　　隨著項目規模增加，需要開發的測試代碼也大大增加，測試代碼的維護工作量也大大增加，對測試自動化的需求也在增加，需要更多的自動化測試用于縮短每個測試周期的時間。

　　神話10："開發人員和測試人員是水火不相容的"

　　長久以來，開發和測試之間存在"你我之分"的緊張局面。這其實會是一種"共生共贏"的健康關系，如果能很好地一起正確地工作的話，這種關系可以為顧客產生更高的產品交付質量。

　　討論的焦點應該集中在：

　　交付的軟件需要滿足業務目標(滿足需求、按時、控制成本)，而不是討論誰擁有哪一部分流程的權責問題。

　　測試人員在需求收集階段可以做出什么貢獻?如何讓他們更好地融入到TDD的過程中。

　　測試人員如何最大化地重用開發過程中產生的各項"資產"?

　　在TDD中是否有一個"傳統測試人員"的角色?或者他們是否需要像開發人員一樣掌握新的技術來適應新的開發模式?

　　在新的開發和測試工具中，開發人員和測試人員如何互相找到自己需要的東西?

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