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