從一段對話談起
甲、乙、丙三人對“所有奇數都是質數”這個假設進行測試。
甲說：“3是質數，5是質數，7是質數�？雌饋磉@個假設沒錯�！�
乙說：“3是質數，5是質數，7是質數，9是質數，11是質數……”
丙說：“錯！9就是一個非質數奇數�！�
軟件測試就是從一個錯誤陳述（“系統能正常運行”）開始，從無限種可能中選出與該陳述矛盾的輸入。必須避免甲犯過的錯誤（沒有驗證合適的值），也要避免犯乙犯過的錯誤（驗證了合適的值，但是沒有發現矛盾之處），需要像丙那樣，用最小工作量找出合適的反例。
IEEE把軟件測試定義為:從通常是無限大的執行域中恰當地選取一組有限測試用例，對照程序已經定義的預期行為，動態地檢驗程序的行為。
從這個定義可以看出軟件測試的四個特點：首先是“動態”，軟件測試總要通過一組輸入執行程序。但是，單靠輸入值并不總能充分地確定一個測試，因為對于復雜、非確定的系統，由于系統會處于不同的狀態，因此對于同樣的輸入可能產生不同的響應。所以，特定的輸入通常還要指定系統的特定狀態。其次是“有限”，在測試中實際能夠觀察的執行數量是有限的。測試永遠都意味著有限資源和計劃進度與本質上是無限測試需求之間的折衷：正是這種矛盾帶來了大家經常提到的技術（測試充分性評判準則）和管理（測試工作量估計）兩個方面的測試問題。接著是“選取”，很多測試手段的本質區別就是如何選擇有限的測試集。針對特定條件確定最合適的選取準則是一個非常復雜的問題，在實踐中需要運用風險分析技術和測試工程專門知識。最后是“預期”，必須能夠確定所觀察到的程序執行輸出是不是可接受的，否則測試工作就是無用的。
軟件測試通常要在不同層次上執行，大體上劃分為三大階段：單元測試、集成測試和系統測試。單元測試檢驗獨立軟件模塊的機能，軟件模塊可以是獨立子程序，也可以是由緊密相關的數個單元組成的較大構件，單元測試一般需要對被測代碼進行訪問并借助調試工具的支持，并且可能需要被測代碼編程人員的介入; 集成測試檢驗系統各部件間的交互性。經典的集成測試策略有自頂向下或自底向上兩種，用于傳統的、分級的結構化軟件系統�，F代的集成測試策略更多是結構驅動的，這意味著對軟件部件或子系統的集成是基于確定的功能線程，因此集成測試是一個連續活動，在每一階段測試人員必須抽象出低一級的情況并集中于正在處理的這一級的狀況; 系統測試關注的則是整個系統的行為，它需要將系統與非功能性系統需求進行比較，非功能性系統需求指系統的安全性、速率、精確性、可靠性等。系統與其它軟件、應用程序、硬件設備或操作環境的外部接口評估也在系統測試中進行。
測試技術分類
從軟件生產發達國家來看，20世紀60年代，軟件測試主要以代碼調試為主；70年代主要以演示軟件系統的正確性為主；80年代到90年代中期，主要以檢查程序錯誤為主；90年代中期以后，軟件測試開始更注重軟件質量特性的整體評估。目前軟件測試最主要的目標是評估軟件功能，但一般也要測試軟件的非功能屬性。
目前應用于軟件測試領域的技術有很多，而且差別很大，大致有兩種分類方法。
第一種是按測試的生成來源劃分，即基于測試人員的直覺和經驗（即興測試）、需求規格說明（包括等價類劃分、邊界值分析、判定表、基于有限狀態機、形式化語言轉換和隨機測試等）、代碼結構（基于流程圖、調用關系圖等參考模型、基于控制流標準、基于數據流的標準）、發現的錯誤（以過去經驗為基礎的錯誤推測法、增加一個被測程序變種的變異測試）、被測程序的使用領域（操作剖面、軟件可靠性工程測試）和被測程序類型（面向對象、基于構件、網站、GUI、并發程序、協議一致性、分布式系統、實時系統、科學計算軟件測試）的測試技術。
第二種是經典的分類方法，即黑盒測試和白盒測試。依賴于被測軟件設計及編碼信息進行的測試稱為白盒測試（基于代碼測試的參考模型、基于控制流標準、基于數據流標準和變異測試等），只依靠被測軟件輸入/輸出行為而沒有關于輸入/輸出之間信息狀況的測試稱為黑盒測試（等價類劃分、邊界值分析、判定表、基于有限狀態機、源于形式化需求規格說明、錯誤推測法、隨機測試、操作剖面和軟件可靠性工程測試等）。
在實際測試中，往往綜合采用這些技術。
測試過程有章可循
過程是一組把輸入轉換為輸出的相關活動。不同層次上的測試活動必須與人員、工具、政策、度量一起組織于一個良定義的過程中，這一過程是軟件生命周期的完整組成部分。測試過程需要加以控制并進行持續改進。
軟件測試過程的決定性因素是人。對于成功的測試來說，一個必要條件是人員對測試活動所采取的積極和相互協作的態度。另外，應該使軟件產品涉及的所有人員都認識到：及早發現軟件錯誤是大家共同的目標，而不僅僅是測試人員的責任。
文檔是測試過程規范化的一個完整組成部分。IEEE 829完整描述了各種測試文檔、文檔間關聯及文檔與測試過程間的關聯。測試文檔包括測試計劃、測試設計說明、測試過程說明、測試案例說明、測試日志和測試事件或問題報告等。用于測試過程控制與改進的度量包括:設計的測試用例數、執行的測試用例數、通過的測試用例數、失敗的測試用例數等。
測試管理的一個關鍵性任務是決定什么樣的測試是充分的，某個測試階段何時可以終止。對此，充分性度量和錯誤密度估價、操作可靠性評估都可提供有益支持，但只有這些還不充分。決策還應考慮潛在的遺留失效可能造成的損失和風險，并將之與進一步測試所需成本進行對比。為使測試和維護工作有組織、成本效益高，應將各測試手段系統化地加以重用。為此，應在測試的各個層次，對測試腳本、測試用例和預期結果進行精心定義并記錄。
用于特定環境、特定類型程序的測試方案，以及決策動機，構成了測試模式。測試模式本身也可文檔化，并可重用于以后的類似項目。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
