由于人們對于軟件質量的重視程度越來越高，就導致了測試在軟件開發中的地位越來越重要。測試是目前用來驗證軟件是否能夠完成所期望的功能的唯一有效的方法。在這一趨勢的引導下，現在很多軟件相關的公司都非常重視對于他們所開發的軟件的測試，甚至不惜花費巨資購買商用的測試工具，但是效果卻不一定理想。究其原因主要是存在著對于軟件測試的諸多誤解。本文試圖對一些比較普遍的關于測試的誤解進行剖析，并且在測試對于軟件產品質量可能帶來的更深遠的影響方面，也進行了論述。
測試在軟件開發過程中一直都是備受關注的，即使在傳統的軟件工程中，也有一個明確、獨立的測試階段。隨著軟件危機的頻頻出現以及人們對于軟件本質的進一步認識，測試的地位得到了前所未有的提高。測試已經不僅僅局限于軟件開發中的一個階段，它已經開始貫穿于整個軟件開發過程，人們已經開始認識到：測試開始的時間越早，測試執行的越頻繁，所帶來的整個軟件開發成本的下降就會越多。Extreme Programming更是把測試推到了極限的位置，一切軟件開發活動都要從首先編寫測試代碼開始。
但是，相對于測試這個詞的流行程度而言，有關測試教育方面的工作做的還遠遠不夠，很多關于測試的文章都是針對某種測試工具使用方面的，而測試工具廠商也往往出于商業的目的對于測試工具的作用夸大其詞。這樣，很多的軟件從業者就很容易陷入一些誤區，導致了測試并沒有在他們所在的軟件開發項目中起到有效的作用。下面幾個小節將對于一些比較具有代表性的誤區進行剖析，并對于測試背后所蘊含的一些設計思考進行了闡述，希望能夠起到拋磚引玉的作用。
誤區之一：使用了測試工具，就是進行了有效的測試
這個誤區可以說是一種通病，幾乎每一個領域中的CASE工具剛剛出現時都會帶來這個問題，比如：如果一個軟件開發團隊在軟件的開發中使用了Rational Rose工具來進行UML圖的繪制，他們可能就會聲稱他們采用了面向對象的方法，也不管他們的設計和代碼實際上是多么的過程化。
在測試領域中也一樣如此，一個軟件開發團隊往往認為只要自己使用了某種軟件測試工具，那么就應該可以獲取測試帶來的種種好處，這種想法當然是錯誤的。因為，要想對一個軟件或者模塊進行有效的測試，首先該軟件或者模塊應該是可測試的�？蓽y試性是反映軟件質量的一個內在屬性，不會因為你使用了某種測試工具進行了測試行為，就使得被測試的軟件具有了可測試性。如果被測試的軟件本身并不具備可測試性，那么使用多么昂貴的測試工具進行測試所能夠帶來的收益都是微乎其微的。
巧的是，可測試性和好的軟件品質的其他方面有天然的關聯，一個具有可測試性的軟件必然是一個強內聚、弱耦合、接口明確、意圖明晰的軟件，而不可測試的軟件往往具有過強的耦合和混亂的邏輯。關于可測試性方面更多的內容不在本文的論述范圍，請自行參見相關的文獻（本文所附的參考文獻中有關于可測試性的更深入的信息）。
要想真正獲取測試帶來的巨大好處，并且使得測試工具能夠發揮最大的效率，關鍵就是要使軟件本身具有很好的可測試性。這種能力的獲取是一個逐步的過程，是不可能一蹴而就的。最關鍵的一點就是要不斷實踐，不斷學習一些優秀的經驗，不斷的反思。要想獲取好的結果，就必須要付出努力，這是亙古不變的真理。Extreme Programming中的測試先行的實踐倒是一個很好的起點，具體可以參見參考文獻[3]。
對于測試工具的選擇，只要滿足需要并能夠自動運行測試用例就可以了。不要一味的追求復雜的功能和不必要的靈活性。對于大多數項目來說，一些非常著名的源碼開放的測試工具就足夠了，比如：Java方面的單元測試工具JUnit和C++方面的單元測試工具CppUnit。關于驗收測試方面，目前沒有比較好的滿足各方面需要通用的測試工具，不過使用腳本語言，循序漸進的自行開發一個適合自己的驗收測試工具也不是一件困難的事情，一句話：只有提高了自身團隊內在的素質，外在的工具才能夠發揮作用。
誤區之二：存在太多的無法測試的東西
在軟件開發領域，確實存在一些東西看起來要比另外一些東西難測試一些，但是遠非無法測試。并且在大多數的情況下，還是由于被測試的軟件本身在設計時沒有考慮到可測試性的問題。只不過這種不可測試性不是由于被測試的軟件內部的過緊耦合造成的，而是和外部某些很難測試的部分耦合過緊，從而表現出被測試的軟件本身很難測試。這些
文章來源于領測軟件測試網 http://www.kjueaiud.com/