信息技術的飛速發展，使軟件產品應用到社會的各個領域，軟件產品的質量自然成為人們共同關注的焦點。不論軟件的生產者還是軟件的使用者，均生存在競爭的環境中，軟件開發商為了占有市場，必須把產品質量作為企業的重要目標之一，以免在激烈的競爭中被淘汰出局。用戶為了保證自己業務的順利完成，當然希望選用優質的軟件。質量不佳的軟件產品不僅會使開發商的維護費用和用戶的使用成本大幅增加，還可能產生其他的責任風險，造成公司信譽下降，繼而沖擊股票市場。在一些關鍵應用 (如民航訂票系統、銀行結算系統、證券交易系統、自動飛行控制軟件、軍事防御和核電站安全控制系統等) 中使用質量有問題的軟件，還可能造成災難性的后果。
軟件危機曾經是軟件界甚至整個計算機界最熱門的話題。為了解決這場危機，軟件從業人員、專家和學者做出了大量的努力�，F在人們已經逐步認識到所謂的軟件危機實際上僅是一種狀況，那就是軟件中有錯誤，正是這些錯誤導致了軟件開發在成本、進度和質量上的失控。有錯是軟件的屬性，而且是無法改變的，因為軟件是由人來完成的，所有由人做的工作都不會是完美無缺的。問題在于我們如何去避免錯誤的產生和消除已經產生的錯誤，使程序中的錯誤密度達到盡可能低的程度。
給軟件帶來錯誤的原因很多，具體地說，主要有如下幾點：
�、�、交流不夠、交流上有誤解或者根本不進行交流
在應用應該做什么或不應該做什么的細節(應用的需求)不清晰的情況下進行開發。
�、�、軟件復雜性
圖形用戶界面(gui)，客戶/服務器結構，分布式應用，數據通信，超大型關系型數據庫以及龐大的系統規模，使得軟件及系統的復雜性呈指數增長，沒有現代軟件開發經驗的人很難理解它。
�、�、程序設計錯誤
向所有的人一樣，程序員也會出錯。
�、�、需求變化
需求變化的影響是多方面的，客戶可能不了解需求變化帶來的影響，也可能知道但又不得不那么做。需求變化的后果可能是造成系統的重新設計，設計人員的日程的重新安排，已經完成的工作可能要重做或者完全拋棄，對其他項目產生影響，硬件需求可能要因此改變，等等。如果有許多小的改變或者一次大的變化，項目各部分之間已知或未知的依賴性可能會相互影響而導致更多問題的出現，需求改變帶來的復雜性可能導致錯誤，還可能影響工程參與者的積極性。
�、�、時間壓力
軟件項目的日程表很難做到準確，很多時候需要預計和猜測。當最終期限迫近和關鍵時刻到來之際，錯誤也就跟著來了。
�、�、自負人更喜歡說:'沒問題','這事情很容易','幾個小時我就能拿出來'
太多不切實際的‘沒問題’，結果只能是引入錯誤。
�、�、代碼文檔貧乏
貧乏或者差勁的文檔使得代碼維護和修改變的異常艱辛，其結果是帶來許多錯誤。事實上，在許多機構并不鼓勵其程序員為代碼編寫文檔，也不鼓勵程序員將代碼寫得清晰和容易理解，相反他們認為少寫文檔可以更快的進行編碼，無法理解的代碼更易于工作的保密(“寫得艱難必定讀的痛苦”)。
�、�、軟件開發工具
可視化工具，類庫，編譯器，腳本工具，等等，它們常常會將自身的錯誤帶到應用軟件中。就象我們所知道的，沒有良好的工程化作為基礎，使用面向對象的技術只會使項目變得更復雜。
為了更好地解決這些問題，軟件界做出了各種各樣的努力。
人們曾經認為更好的程序語言可以使我們擺脫這些困擾，這推動了程序設計語言的發展，更多的語言開始流行，為了使程序更易于理解開發了結構化程序設計語言，如pl/1,pascal等；為了解決實時多任務需求開發了結構化多任務程序設計語言，如modula，ada等；為了提高重用性開發了面向對象的程序設計語言，如simlasa等；為了避免產生不正確的需求理解，開發形式化描述語言，如hal/s等，這使得建立基于自然語言的描述成為可能，人們以形式化語言來描述需求；為了支持大型數據庫應用，開發了可視化工具，如visual studio、power builder等。程序語言對提高軟件生產效率起到了一定的積極作用，但它對整個軟件質量尤其是可靠性的影響，與其他因素相比作用較小。
可能是因為程序語言基于嚴格的語法和語義規則，人們企圖用形式化證明方法來證明程序的正確性。將程序當作數學對象來看待，從數學意義上證明程序是正確的是可能的。數學家對形式化證明方法最有興趣，在論文上談起來非常吸引人，但實際價值卻非常有限，因為形式化證明方法只有在代碼寫出來之后才能使用，這顯然太遲了，而且對于大的程序證明起來非常困難。
受到其他行業項目工程化的啟發，軟件工程學出現了，軟件開發被視為一項工程，以工程化的方法來進行規劃和管理軟件的開發。
針對需求不確定的應用，可以使用漸進和迭代類的開發模型。還可以采用快速應用程序開發(rad)和協同應用程序開發（jad）技術，由軟件開發者和用戶代表共同參與開發軟件規范。rad和jad的基本思路是開發者和用戶共同設計系統中的屏幕，開發者迅速地把實現這些屏幕的最基本功能編寫好，然后把它們交給用戶看，然后用戶和開發者回顧這些屏幕以確認它們達到了用戶的要求，這個周期一直持續到系統的基本部分定義完畢。一旦設計被用戶接受，開發者將完成完全實現屏幕需要的代碼。rad和傳統軟件開發項目之間的一個基本區別是：應用程序rad系統是按階段發布的。傳統項目一般一次發布，也叫“big bang”。rad方法使用高效開發工具，開發者能夠非常迅速地設計出系統的基本屏幕，允許用戶在開發周期中很早就能見識到系統將來看起來怎么樣，避免了在傳統開發項目中長篇大論并且枯燥難懂的說明。
ibm的dr.harlan mills提出了凈室過程。凈室過程組合了形式化程序驗證和統計過程控制(spc)。在這種方法中，首先用正確性數學證明預防缺陷發生，然后用mtbf度量軟件質量。凈室過程是一種相當新的軟件開發方法，它要求軟件開發在管理方式和技術方法上作重大改變，特別是要求spc應用到軟件的知識，這影響了其被廣泛的接受。
硬件成本持續降低，可支持case工具運行的新的強大的工作站和網絡已經成為軟件工程使用的工作平臺，case工具可完成一些特定的軟件開發過程。這些工具提供給軟件設計者以圖形方式描述軟件設計的能力，這樣就易于維護、易于交叉檢查、易于理解。許多人（尤其是case工具供貨商）相信case工具扮演了解決軟件危機和拯救軟件工業的角色，但事實上我們看到的情形卻是許多公司花了大量的金錢買回的case工具但很少使用，原因在于這些工具執行的過程與機構的軟件設計過程不相適用。
在可以借助許多新的技術和工具進行軟件開發的今天，軟件開發過程的成熟性問題開始引起人們的重視。這種產品一致性問題的主要癥結在于管理，因此人們將目標轉向了管理的改善，一些以改進軟件開發過程為目標的活動已經展示出積極的結果。
以下是一些比較典型的文本。
sei sw-cmm
iso spice(software process improvement and capability determination)
bootstrap
iso-9000-3
tickit
trillium
事實上，對于軟件來講，還沒有象銀彈那樣的東西。不論采用什么技術和什么方法，軟件中仍然會有錯。采用新的語言、先進的開發方式、完善的開發過程，可以減少錯誤的引入，但是不可能完全杜絕軟件中的錯誤，這些引入的錯誤需要測試來找出，軟件中的錯誤密度也需要測試來進行估計。
測試是所有工程學科的基本組成單元，是軟件開發的重要部分。自有程序設計的那天起測試就一直伴隨著。統計表明，在典型的軟件開發項目中，軟件測試工作量往往占軟件開發總工作量的40％以上。而在軟件開發的總成本中，用在測試上的開銷要占30％到50％。如果把維護階段也考慮在內，討論整個軟件生存期時，測試的成本比例也許會有所降低，但實際上維護工作相當于二次開發，乃至多次開發，其中必定還包含有許多測試工作。因此，測試對于軟件生產來說是必需的，問題是我們應該思考“采用什么方法、如何安排測試?”
二、軟件測試的目的
軟件測試的目的決定了如何去組織測試。如果測試的目的是為了盡可能多地找出錯誤，那么測試就應該直接針對軟件比較復雜的部分或是以前出錯比較多的位置。如果測試目的是為了給最終用戶提供具有一定可信度的質量評價，那么測試就應該直接針對在實際應用中會經常用到的商業假設。
不同的機構會有不同的測試目的；相同的機構也可能有不同測試目的，可能是測試不同區域或是對同一區域的不同層次的測試。
在談到軟件測試時，許多人都引用grenford j. myers在《the art of software testing》一書中的觀點：
�、�、軟件測試是為了發現錯誤而執行程序的過程；
�、�、測試是為了證明程序有錯，而不是證明程序無錯誤。
�、�、一個好的測試用例是在于它能發現至今未發現的錯誤；
�、�、一個成功的測試是發現了至今未發現的錯誤的測試。
這種觀點可以提醒人們測試要以查找錯誤為中心，而不是為了演示軟件的正確功能。但是僅憑字面意思理解這一觀點可能會產生誤導，認為發現錯誤是軟件測試的唯一目，查找不出錯誤的測試就是沒有價值的，事實并非如此。
首先，測試并不僅僅是為了要找出錯誤。通過分析錯誤產生的原因和錯誤的分布特征，可以幫助項目管理者發現當前所采用的軟件過程的缺陷，以便改進。同時，這種分析也能幫助我們設計出有針對性地檢測方法，改善測試的有效性。
其次，沒有發現錯誤的測試也是有價值的，完整的測試是評定測試質量的一種方法。詳細而嚴謹的可靠性增長模型可以證明這一點。例如 bev littlewood發現一個經過測試而正常運行了n小時的系統有繼續正常運行n小時的概率。
三、軟件測試的基本方法
軟件測試的方法和技術是多種多樣的。
對于軟件測試技術，可以從不同的角度加以分類：
從是否需要執行被測軟件的角度，可分為靜態測試和動態測試。
從測試是否針對系統的內部結構和具體實現算法的角度來看，可分為白盒測試和黑盒測試；
1、黑盒測試
黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出信息，并且保持外部信息（如數據庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因?果圖、錯誤推測等，主要用于軟件確認測試。
“黑盒”法著眼于程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測試�！昂诤小狈ㄊ歉F舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。
2、白盒測試
白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用于軟件驗證。
“白盒”法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試�！鞍缀小狈ㄊ歉F舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測試數據。貫穿程序的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設計規范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發現不了一些與數據相關的錯誤。
3．alac(act-like-a-customer)測試
alac測試是一種基于客戶使用產品的知識開發出來的測試方法。alac測試是基于復雜的軟件產品有許多錯誤的原則。最大的受益者是用戶，缺陷查找和改正將針對哪些客戶最容易遇到的錯誤。
四、軟件測試的復雜性與經濟性
人們常常以為，開發一個程序是困難的，測試一個程序則比較容易。這其實是誤解。設計測試用例是一項細致并需要高度技巧的工作，稍有不慎就會顧此失彼，發生不應有的疏漏。
不論是黑盒測試方法還是白盒測試方法，由于測試情況數量巨大，都不可能進行徹底的測試。所謂徹底測試，就是讓被測程序在一切可能的輸入情況下全部執行一遍。通常也稱這種測試為“窮舉測試”。 “黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。 “白盒”法是窮舉路徑測試，貫穿程序的獨立路徑數是天文數字，但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設計規范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發現不了一些與數據相關的錯誤。e．w．dijkstra的一句名言對測試的不徹底性作了很好的注解：“程序測試只能證明錯誤的存在，但不能證明錯誤不存在”。
在實際測試中，窮舉測試工作量太大，實踐上行不通，這就注定了一切實際測試都是不徹底的。當然就不能夠保證被測試程序中不存在遺留的錯誤。軟件工程的總目標是充分利用有限的人力和物力資源，高效率、高質量地完成測試。為了降低測試成本，選擇測試用例時應注意遵守“經濟性”的原則。第一，要根據程序的重要性和一旦發生故障將造成的損失來確定它的測試等級；第二，要認真研究測試策略，以便能使用盡可能少的測試用例，發現盡可能多的程序錯誤。掌握好測試量是至關重要的，一位有經驗的軟件開發管理人員在談到軟件測試時曾這樣說過：“不充分的測試是愚蠢的，而過度的測試是一種罪孽”。測試不足意味著讓用戶承擔隱藏錯誤帶來的危險，過度測試則會浪費許多寶貴的資源。
測試是軟件生存期中費用消耗最大的環節。測試費用除了測試的直接消耗外，還包括其它的相關費用。能夠決定需要做多少次測試的主要影響因素如下：
�、�、系統的目的
系統的目的的差別在很大程度上影響所需要進行的測試的數量。那些可能產生嚴重后果的系統必須要進行更多的測試。一臺在boeing 757上的系統應該比一個用于公共圖書館中檢索資料的系統需要更多的測試。一個用來控制密封燃氣管道的系統應該比一個與有毒爆炸物品無關的系統有更高的可信度。一個安全關鍵軟件的開發組比一個游戲軟件開發組要有苛刻得多的查找錯誤方面的要求。
�、�、潛在的用戶數量
一個系統的潛在用戶數量也在很大程度上影響了測試必要性的程度。這主要是由于用戶團體在經濟方面的影響。一個在全世界范圍內有幾千個用戶的系統肯定比一個只在辦公室中運行的有兩三個用戶的系統需要更多的測試。如果不能使用的話，前一個系統的經濟影響肯定比后一個系統大。除此而外，在分配處理錯誤的時候，所花的代價的差別也很大。如果在內部系統中發現了一個嚴重的錯誤，在處理錯誤的時候的費用就相對少一些，如果要處理一個遍布全世界的錯誤就需要花費相當大的財力和精力。
�、�、信息的價值
在考慮測試的必要性時，還需要將系統中所包含的信息的價值考慮在內，一個支持許多家大銀行或眾多證券交易所的客戶機/服務器系統中含有經濟價值非常高的內容。很顯然這一系統需要比一個支持鞋店的系統要進行更多的測試。這兩個系統的用戶都希望得到高質量、無錯誤的系統，但是前一種系統的影響比后一種要大得多。因此我們應該從經濟方面考慮，投入與經濟價值相對應的時間和金錢去進行測試。
�、�、開發機構
一個沒有標準和缺少經驗的開發機構很可能開發出充滿錯誤的系統。在一個建立了標準和有很多經驗的開發機構中開發出來的系統中的錯誤不會很多，因此，對于不同的開發機構來說，所需要的測試的必要性也就截然的不同。
然而，那些需要進行大幅度改善的機構反而不大可能認識到自身的弱點。那些需要更加嚴格的測試過程的機構往往是最不可能進行這一活動的，在許多情況下，機構的管理部門并不能真正地理解開發一個高質量的系統的好處。
�、�、測試的時機
測試量會隨時間的推移發生改變。在一個竟爭很激烈的市場里，爭取時間可能是制勝的關鍵，開始可能不會在測試上花多少時間，但幾年后如果市場分配格局已經建立起來了，那么產品的質量就變得更重要了，測試量就要加大。測試量應該針對合適的目標進行調整。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
