軟件測試應該注意的幾大誤解 軟件測試
最近看了網絡上所謂專家寫的文章，發現了一些對TDD與QA部門的誤解。本文將解釋部分誤區，并集中討論QA團隊要在敏捷的世界里獲得成功所必須解決的一些問題。
對測試的誤解
1. "你只需要做單元測試——TDD測試已經足夠"
對于大部分商業開發來說，根本就沒有這回事。即使是敏捷開發的強力擁護者也承認他們需要一系列的測試技術。
TDD程序設計人員需要這些測試來驗證代碼的正確性。如果需求(測試用例)解釋錯誤，那么你構建的代碼也將無法達到目標要求。
大多敏捷項目都會使用探索性測試方法(黑盒)來支持白盒測試，而不會認為這兩種技術只能選一。優秀的探索性測試可以在開發地過于深入之前發現開發人員所忽略的問題。
2. "你可以重用單元測試來創建回歸測試集"
有些TDD擁護者認為常規的下游測試(downstream testing)是多余的，因為每一行應用代碼都有對應的測試用例;他們認為重用單元測試就可以做到用戶驗收測試和回歸測試所能做到的一切。
這聽起來挺有道理，但由于某些原因，這是不現實的：TDD中的白盒單元測試的粒度與目標與下游黑盒測試的目的是不同的。
雖然單元測試的整體目標是保證代碼能夠實現所需的功能，但是回歸測試的目標是保證被改動的應用代碼不會產生意料外的效果。這兩個目標是不同的--比如，檢查一項屬性是否具有合法的日期格式，與檢查輸入域中是否存在所需的日期是不同的。
3. "開發人員可以用開源工具寫測試，因此我們不需要測試人員或者自動測試工具了"
職業測試人員實現的是與其開發同僚不同但同樣有效的作用。
人們普遍認識到傳統的自動測試工具并不像供應商們炒作的那么有效。原始軟件的源碼和供應商的產品一樣可以改善數據庫測試環境下的效率。這是因為沒有合適的工具可以提供用戶界面測試，所以我們才把方案擴展到了這一領域;我們的傳統是有效地實施測試而不是屏幕抓取自動測試。我們開發了測試驅動，是因為在過去的二十年里傳統的供應商錯過了這個機會。
通常，TDD項目的測試代碼至少與應用代碼一樣多，因此其本身就是應用軟件。這種測試代碼是需要在目標應用的生命周期中進行維護的。
4. "有了單元測試就不需要手動測試了"
手動測試是一項重復性很強的工作;成本昂貴、枯燥并且容易出錯。雖然TDD可以減少功能測試所需的手動勞動，但是它不能消除對黑盒測試(手動和自動)的需求。
通過自動抓取測試人員的過程并記錄其鍵盤和鼠標動作，測試人員能夠騰出更多的時間來進行更有意義、更有價值的活動，比如測試難以(甚至無法)自動化的復雜場景。雖然手動測試很費時間(因此也很昂貴)，但是如果因為不進行手動測試而漏掉一些錯誤，則通常意味著將來可能要付出更大的代價。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
