軟件測試作為軟件質量保證的重要手段已引起軟件用戶和開發人員越來越多的關注。然而在對測試認識逐漸深化的過程中，首先應該弄清幾個問題。
非進行測試不可嗎？
世界軟件市場將有一個突飛猛進的發展，應用程序的類型越來越復雜，從傳統客戶/服務器應用，到基于瀏覽的Internet/Intranet應用，再到混合型應用等等。在這些大量的、日漸復雜的應用程序中，由于GUI的對象豐富，使得狀態組合數量巨增；軟、硬件來自不同廠商，程序運行環境復雜；版本不斷升級以及同時使用某個廠家的不同版本，致使程序運行環境經常改變；并發用戶的數量逐漸增多，對性能要求不斷提高等等?？梢?，隨著軟件業的發展，測試成為必然。
據統計，在軟件開發總成本中，用在測試上的開銷要占30%到50%。如果把維護階段考慮在內，討論整個軟件生存期時，測試的成本比例也許會有所降低，但實際上維護工作相當于二次開發，乃至多次開發，其中必定還包含有許多測試工作。因此，有人估計軟件工作有50%的時間和50%以上的成本花在測試工作上。因此，測試是必需的，問題是我們應該思考“采用什么方法、如何安排測試？”
測試和調試可以相互替代嗎？
為了判斷應用系統是否合格，而用預先確定的一系列數據在系統中運行，并與預期的結果進行比較，這一過程稱為測試。它是軟件質量保證的重要手段。然而，有些人往往把測試和調試混為一談，這是不正確的。
簡單地說，測試是一種檢驗，經過測試人們會看到一些現象。這些現象也許是可疑的征兆，但往往不能直接從測試的結果中找到錯誤的根源。這就需要充分利用測試結果和測試提供的信息進行全面分析，以便找到錯誤的根源和出現錯誤的原因。緊接著便是糾正已發現的錯誤。測試以后進行的這些工作稱為調試或排錯。
我們不能把兩者混為一談。但它們畢竟有著密切的關系，常常是在測試以后緊接著要著手排錯。實際上，這兩種工作經常交叉進行，是不可相互替代的。
科學的測試應從何時開始？
有一種傳統的觀念認為：“應用系統開發完畢，再對它進行測試。”用這種思想來指導測試工作是相當危險的。
對于軟件質量的判斷決不只限于程序本身，它和編碼以前所完成的需求分析及軟件設計工作密切相關。很顯然，表現在程序中的錯誤，并不一定是編碼所引起的，很可能是詳細設計、概要設計階段，甚至是需求分析階段的問題引起的。錯誤在初期也許只是范圍很小的隱藏問題，但由于各開發階段的連續性，使其逐步擴展。如果早期開發中出現的錯誤不能及時發現和解決，將帶到設計、編碼、測試等各階段，影響會逐步擴大。這就要付出不必要的人力、物力來修正錯誤?？梢姡鉀Q問題、糾正錯誤應追溯到前期的工作，越早著手越好?？茖W的測試是貫穿整個產品生命周期中的測試。
考慮到以上這些情況，我們將測試分成如下階段：模塊測試、集成測試、確認測試和系統測試。對程序的最小單位——模塊進行測試，是為了檢驗每個模塊能否單獨工作，從而發現模塊的編碼問題和算法問題；集成測試是將多個模塊連接起來，以檢驗概要設計中對模塊之間接口設計的問題；確認測試則應以需求規格說明書中的規定作為檢驗尺度，發現需求分析的問題；最后的系統測試是將開發的軟件與硬件和其他相關因素（如人員的操作、數據的獲取等）綜合起來進行全面檢驗，這樣的做法涉及到軟件需求以及軟件與系統中其他方面的關系。
我們應著眼于整個軟件生存期，特別是著眼于編碼以前各開發階段的測試工作，以保證軟件的質量，這就要突破原來對測試的理解。據有關機構研究表明：在開發周期中，每推后一步實施錯誤檢查，成本就會增加10%。因此，查找、修改錯誤的最佳開始時間是在項目設計階段，之后還要伴隨著開發過程的每一個環節，保證測試與開發的同步進行。
對軟件能夠做到徹底測試嗎？
既然測試的目的就是查找軟件中的錯誤，那么為了得到高質量的軟件，能不能借助測試工具將所有隱藏的錯誤全部找出來呢？
我們知道，只有對應用的每一個運行環境、語句、條件分支、路徑等進行窮舉測試，才能確保測試的徹底性。但往往這種做法工作量過大，所用時間過長，實際是不現實的，因而也就失去了實用價值。軟件工程的總目標是充分利用有限的人力和物力資源，高效率、高質量地完成測試開發項目。在測試階段既然窮舉測試是不現實的，為了節省時間和資源，提高測試效率，就必須精心設計測試用例，這樣采用這些測試數據能夠取得最佳的測試效果。掌握測試量的度是至關重要的。一位有經驗的軟件開發管理人員在談到軟件測試時曾這樣說過：“不充分的測試是愚蠢的，而過度的測試是一種罪孽。”測試不足意味著讓用戶承擔隱藏錯誤帶來的危險；過度測試則會浪費許多寶貴的資源。到測試后期，即使找到了錯誤，然而已經付出了過高的代價?？傊M行測試是為了使軟件中蘊涵的缺陷低于某一特定閾值，使產出/投入比達到最大。