雖然這聽起來很誘人，但是這不現實，因為：TDD中開發的白盒的單元測試的粒度和目標與黑盒測試有所區別。
單元測試的總體目標是用于證明代碼是如預期般工作的，而回歸測試的目的是確保修改的代碼不會引起非預期的結果。兩者存在的意義是不一樣的，例如，"檢查某個屬性的日期格式是正確的"，就與"對于給定的輸入，檢查其值具有預期的日期"不一樣。
神話3："我們不再需要測試人員、或者自動化工具"
專業的測試人員履行了不一樣的職責，與開發同僚們一樣是不可或缺的項目組角色之一。
不得不承認：傳統的自動化測試工具并沒有像廠商們所鼓吹的那樣神奇。但是這不意味著我們要放棄自動化工具，我們仍然期待更多更好的自動化工具的出現。
#FormatImgID_1#
神話4："有了單元測試，手工測試就沒有存在的必要性了"
手工測試時重復性的勞動，代價高、繁瑣、容易出錯。然而，雖然TDD能減少一定量的手工功能測試，它并不能廢除進一步的黑盒測試的需要（無論是手工的還是自動化的）。
通過自動化的捕獲測試人員的操作過程，并且將他們的鍵盤和鼠標點擊事件文檔化，測試人員可以把更多的時間放在有趣的、增值的活動上，例如測試那些自動化很難實現，或者是根本不可能實現的復雜測試場景。雖然通過手工測試尋找bug是一個耗時的、代價高昂的過程，但是如果不采用這種手段而遺漏了BUG，代價會更高。
神話5："不再需要用戶驗收測試"
在敏捷開發中，用戶驗收測試通常用于與顧客一起解決"不正確的需求"的問題，而不是用于糾正功能問題。
當用戶最初定義需求時，他們是基于自己的初始想法和愿景來定義的。當他們看到"活生生的"真正的系統后，他們總是會有不同的、額外的需求。雖然敏捷方法可以減少這種情況發生的頻率，但是也不可能杜絕，因此也就不可避免地需要用戶驗收測試。
神話6："自動化是不可能的"
在敏捷項目的早期階段開展自動化測試通常是很困難的，但是隨著系統的演進，某些方面穩定下來之后就可以開始實施自動化測試了。
洞悉自動化測試開展的正確時機并不容易，因此，使用某些技術，讓早期的手工測試可以順利過渡到自動化測試是很關鍵的。如果早期的測試設計和手工測試可以被很好地記錄下來，以備重用的話，后面的自動化測試將大大受益。
神話7："開發人員擁有足夠的測試技巧"
如果測試是很容易的，那么每個人都可以做，則每次我們都可以發布和交付優質的代碼。一個獨立的測試組的目標是作為第三方、能夠從全局出發、驗證和確認軟件功能的質量。而開發人員趨向于證明系統是正常工作的。一個好的測試者會傾向于"假設"某些場景的出現，再加上業務用戶的測試，則確保系統滿足預期目的將變得容易。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
