當程序無法實現最終用戶要求的合理功能時，就會發生一個軟件錯誤。
根據這個定義，即使完成了一次非常完美的模塊測試，仍然不能保證已經找出了程序的所有錯誤。因此，要結束整個測試任務，必須進行其他形式的更深入的測試，將這些新型形式的測試稱爲“更高級別的測試”
軟件開發週期的文檔說明：
●要求規格說明定義了爲什麼要開發程序
●目標定義了程序要做什麼，以及做得怎樣
●外部規格說明了程序對用戶的準確表現
●與後續階段相關的文檔越來越詳細地規定了程序是如何建立起來的
確定軟件開發週期7個階段包括了信息的溝通，理解和轉換，以及大多數的軟件錯誤都源於信息處理中的故障，現在有三個方法來預防和識別這些錯誤。
可以是軟件開發過程更加精密，以防其中有很多錯誤。
引入獨立的驗證過程，在進入下一階段前儘可能多地發現錯誤。
對不同的階段的採用不同的測試方法，應該在開發和測試過程之間建立一對一的聯繫。
●模塊測試的目的是是發現程序與規格說明之間的不一致
●功能測試的目的是爲了說明程序未能符合其外部規格說明
●系統測試的目的是爲了證明軟件產品與其初始目標不一致
注：我們討論功能測試，系統測試，驗收測試和安裝測試的過程。這裏忽略了集成測試。因爲集成測試往往不是作爲獨立測試步驟，而且在增量模塊測試中，它是模塊測試的隱含部分。
1.功能測試
功能測試是一個試圖發現程序與其外部規格說明之間存在的不一致的過程。外部規格說明是一份最終的用戶角度對程序行爲的精確描述。
功能測試通常是一項黑盒操作，也就是說，依賴早期的模塊測試過程來實現理想的白盒邏輯規則。
在功能測試時，需要對規格說明進行說明以獲取測試用例集，如等價類劃分，邊界值分析，因果圖分析和錯誤猜測法。最後應該牢記測試的目的是爲了暴露程序的錯誤以及規格說明不一致之處，而不是爲了證明程序符合外部說明。
2.系統測試
系統測試並不是測試整個系統或程序功能的過程。因爲有了功能測試這樣會顯得多餘。系統測試有着特定的目的：將系統或程序與其初始目標進行比較，給定這個目標後，隱含兩方面的含義：
系統測試並不侷限於系統，如果產品是一個程序，那麼系統測試就是一個試圖說明程序作爲一個整體是如何不滿足其目標的過程。
根據定義，如果產品沒有一組書面的，可度量的目標，系統測試將無法進行。
再尋找程序與其目標不一致的過程中，應重點注意那些設計外部規格說明所犯的錯誤。這也暗示了與功能測試不同，外部規格說明不能作爲系統測試用例的基礎，否則就破壞了系統測試的目標。另一方面，也不能用文檔本身表示測試用例，因爲這些文檔並不包含對接口的準確描述。
克服方法：利用程序的用戶文檔，通過分析目標文檔來設計系統測試，分析用戶文檔來闡明測試用例。
目標雖已闡明，但沒有確認生成測試用例的方法，僅含一些含糊卻有用的指南來指導如何編寫測試用例，以證明程序與中的目標文檔每一句都存在不一致性。事實上，設計好的系統測試用例比設計系統或程序需要更多的創造性。
2.1能力測試
最明顯的系統測試類型是判斷目標文檔提及的每一項能力是否確實以實現，能力測試的語句是逐條檢查目標文檔，語句定義了一個“要做什麼”，就判斷該程序是否滿足，這種類型的測試常常在不同的計算機情況下運行，又是人工對目標文檔和用戶文檔進行比較久足夠了。
2.2容量測試
是使程序經受大容量數據的檢驗，例如：編譯器可能要處理編譯規模非常大的源程序，編譯器可能需要處理一個包含上千模塊的程序等等。而操作系統的作業隊列可能已經達到飽和容量。如果程序需要處理跨越不同的卷，則應產生足夠的數據使程序從一個卷轉到另一箇中。故：容量測試的目的是爲了證明程序不能處理目標文檔中規定的數據容量
2.3強度測試
強度測試使程序承受高負載或強度的檢驗。所謂高強度就是指在短時間間隔內達到數據或操作的數量峯值。類似一名打字員，容量測試是判斷打字員能否處理大篇幅的稿子，而強度測試是判斷打字員能否達到每分鐘50個單詞的速度。
基於web的應用程序是最長接受強度測試的軟件之一，在這裏，我們需要確信是應用程序以及硬件能夠處理一定容量 的併發用戶，但有人會狡辯說，也許數百萬人在同一時刻訪問該站點，但這是不現實的，我們需要弄清用戶羣，然後設計一個強度測試，體現出可能訪問站點的最大人羣的情況。
2.4易用性測試
今天的軟件系統，尤其那些廣大的商業市場而設計的軟件。通常有廣泛的人爲因素的研究。列舉測試中的一些問題：
每個用戶界面是否能夠根據最終用戶的智力，教育背景和環境進行了調整
程序輸出是否有意義，不模糊且沒有計算機雜亂信息
診斷錯誤（如錯誤信息）是否直接。
整體的用戶界面是否在語法，慣例，語義，格式，風格和縮寫方面展現出相當程度的概念完整性。
在準確性極爲重要的環境中，如網上銀行系統，輸入中是否有足夠的冗餘信息例如：該系統可能會要求輸入賬號，用戶名和PIN來驗證訪問賬號信息是合法用戶。
系統是否包含過多或不大可能遇到的選項？
對於所有的輸入，系統是否返回了某些類型的及時的確認消息。
程序是否易用。如輸入是否區分大小寫這一點對用戶來說是否清楚。此外，如果需要瀏覽一系列的菜單操作，返回主菜單的方法是否清楚。
2.5安全型測試
安全性測試是設計測試用例來破壞程序安全性檢查的過程。舉例來說，我們可以設計測試用例來規避操作系統的內存保護機制，破壞數據庫管理系統的數據安全機制。設計這種測試用例的方法之一是研究類似系統中已知的安全問題，然後生成測試用例，儘量暴露被測系統存在的相似問題。
基於web的應用程序常常比絕大多數程序所需的安全測試級別更高，對於電子商務網站尤其如此，儘管已經有了足夠多的技術（密碼學）允許客戶在因特網上安全地完成交易，但不能單純地依賴技術的應用來確保安全。
2.6性能測試
很多軟件都有特定的性能或效率目標，這些特性描述在特定負載和配置環境下程序響應時間和吞吐量，再一次強調，由於系統測試的目的是爲了證明程序不能實現其目標，因此，應設計測試用例來說明程序不能滿足其性能目標。
2.7存儲測試
類似的，軟件可能偶爾有存儲目標，舉例來說，可能描述了程序使用內存和輔存的容量，以及臨時文件或溢出文件的大小，應用測試用例來證明這些存儲目標沒有得到滿足。
2.8配置測試
諸如操作系統，等都支持多種硬件配置，包括I/O設備，通信線路，或不同的存儲容量。通常可能配置的數量非常大，無法面面俱到，但至少有一種類型的設備，以最大最小的配置來測試程序。如軟件本身的配置可忽略掉某些程序組件，或可運行在不同的計算機上，軟件所有可能的配置都應測試到。
如今的軟件都設計在可運行的多種操作系統環境下，因此如果設計此類程序，應該在該程序面向的所有操作環境中進行測試。
2.9兼容性/配置/轉換測試
大多數開發軟件並不是全新的，常常爲了替換掉某些不完善的軟件，往往有着特定的目標，設計現有系統的兼容以及現有系統的轉換過程。針對這些目標測試程序，測試用例的目的是爲了兼容性目標未被滿足，轉換過程爲生效。將數據從一個系統轉換到另一個系統時，應盡力發現這些錯誤。升級數據庫管理就是一個例子。很多不同的方法測試這個過程，但這些方法都高度依賴於所用的數據庫系統。
2.10安裝測試
有些類型的軟件系統安裝過程非常複雜，測試安裝過程是系統測試中一個重要的部分，對於包在軟件安裝包的自動安裝系統而言，尤其重要，安裝如果出現錯誤，可能會影響用戶對軟件的成功體驗。
2.11可靠性測試
當然，所有類型的測試是爲了提高軟件的可靠性，但軟件的目標中包含了對可靠性的特別描述，就必須專門設計可靠性測試。此種類型的軟件證明或測試聽起來很複雜，但是對於那些必須維持非常高的正常時間運行時間的系統。重要性日益增加。
2.12可恢復性測試
諸如操作系統，數據庫管理系統，和遠程處理系統等軟件，通常有可恢復性目標，說明系統是如何從錯誤、硬件失效和數據錯誤中恢復過來，系統測試的一個目標是爲了證明這些恢復機制不能夠正常發揮作用。我們可以故意將程序錯誤步入某個系統中，判斷系統是否可以從中恢復。諸如內存錯誤，I/O錯誤等硬件錯誤可以模擬。而如通信中的線路噪音或數據庫中的無效指針等數據錯誤也可以模擬出來。以分析系統的反應。
2.13適用性測試
軟件還可以有適用性或可維護性的目標，所有此類的目標必須測試到，這些功能可能定義了系統提供的輔助功能，包括存儲轉發程序或診斷程序，調試明顯問題的平均時間、維護過程以及內部業務文檔的質量等。
2.14文檔測試
系統測試也需要檢查用戶文檔的正確性，完成此任務主要方法是根據文檔來確定系統測試用例的形式，也就是說，一旦設計完成某個具體的測試情況，應該使用文檔來作爲編寫實際測試用例的指南。同時，用戶文檔作爲審覈的對象，檢查其正確性清晰性。在文檔中描述的任何範例應當編寫成測試用例，並提交給程序。
2.15過程測試
很多軟件都是較大系統的組成部分，這些系統並不是完全自動化的，包含了很多人員操作過程。在系統測試中，必須對所有已經規定的人工過程，如系統操作員、數據庫管理員或最終用戶的操作過程進行測試。
數據庫管理員必須記錄備份和恢復數據庫系統的操作過程。在可能的情況下，應由與數據庫管理不相關的人來測試這些情況。然而，公司必須爲充分測試這些過程提供所需資源，這些資源通常包括硬件和額外的軟件許可證。
2.16系統測試的執行
系統測試執行的最關鍵的一個考慮是決定由誰來進行測試。（1）不能由程序員來進行系統測試；（2）在所有的測試階段之中，這是唯一一個明確地不能由負責該程序開發的機構來進行測試
第一點基於的事實是，執行系統測試的人思考問題的方式必須與最終用戶相同，顯然，理想的測試小組應由幾位專業的系統測試專家（以執行系統測試爲職業）、一位或者兩位最終的用戶代表，一位人類工程學工程師以及該程序主要分析人或者設計者所組成。
第二點基於現實的是，大多數開發機構最關心的是讓系統測試進行的儘可能順利並且按時完成，而不會盡力去證明程序不能滿足其目標。系統測試至少應由很少受開發機構左右的獨立人羣來執行，也是最經濟的執行系統測試的形式。
3.驗收測試
驗收測試是將程序與最初的需求及最終用戶當前的需要進行比較的過程。這是一種不尋常的測試用例，因爲這通常是由程序的客戶或最終用戶來進行一般不認爲軟件開發機構的職責，由訂購方（用戶）來驗收測試。將程序的實際操作與原始合同進行對照。與其他類型的測試一樣，驗收測試最好的方法是設計測試用例，盡力證明程序沒有滿足合同的要求。
4安裝測試
它與其他測試過程不同，與設計過程中的任何階段都沒有聯繫，它的目的不是爲了發現軟件的錯誤，而是爲了發現安裝過程中出現的錯誤。
在安裝軟件系統期間會發生很多事件，簡單概括下列事件
用戶必須選擇大量的選項。
必須分配並加載文件和庫
必須進行有效的硬件配置
軟件可能要求網絡連通，以便與其他軟件連接。
測試用例需要檢查以確認已選的選項集合互不衝突，系統的所有部件全部存在，所有文件已經常見幷包含必須內容。
5測試計劃與控制
與大多數項目的情況一樣，計劃是管理測試過程中至關重要的一部分，一個良好的測試計劃包括：
1）目標。必須定義每個測試階段的目標
2）結束準則。必須制定準則以規定每個測試階段何時該結束
3）進度。應何時設計、編寫執行測試用例。
4）責任。對於每一個階段，應當有誰來設計、編寫驗收測試用例，誰來修改發現軟件錯誤。
5）測試用例庫及標準
6）工具。包括由誰來開發或採購，如何使用工具以及何時需要使用工具。
7）計算機時間。計劃每個測試所需要的時間
8）硬件設備。如特別需要的硬件設備或裝備，則需一份計劃來描述該需求，應該如何滿足需求以及何時需要滿足。
9）集成。測試計劃的一部分是定義程序如何組裝在一起的方法（如自頂向下的增量測試）。一個系統如果包含大的子系統或程序，可按增量方式組裝在一起，例如自頂向下或者自底向上的方法，但這些構造塊是程序或者子系統，而不是模塊。如果是這種情況，就需要個系統集成計劃。系統集成計劃規定了系統集成的順序。
10）跟蹤步驟。必須跟蹤進行中的方方面面，包括對錯誤易發模塊的定位以及有關進度、資源和結束準則的進展估計。
11）調試步驟。必須制定上報已發生錯誤、跟蹤錯誤修改進程以及將修改部分加入系統中去的機制。調試計劃中還應包括進度、責任分工，工具以及計算機時間/資源等。
12）迴歸測試。是對程序功能改進或者修改之後進行，其目的是判斷程序的改動是否引起了程序其他方面的退步。迴歸測試通常是執行測試用例中的某個子集。迴歸測試很重要，因爲因爲程序的改動和對錯誤的糾正要遠比原來程序代碼更容易出錯。迴歸測試計劃規定測試人員，測試方法和測試時間，它也是必須的。
6測試結束準則
1)用完了安排的測試時間後，測試便結束。
2)當執行完所有測試用例都爲發現錯誤，測試便結束。
以上兩條沒有任何作用。不能保證測試用例的質量。
有三類較爲有用的結束準則。
第一類：
測試用例來源於：
（1）滿足多重條件覆蓋準則
（2）規模塊接口規格說明進行了邊界值分析，產生的所有測試用例最終都是不成功的
在滿足下列情況時規定測試功能結束
測試用例來源於
（1）因果圖分析
（2）邊界值分析
（3）錯誤猜測產生的所有測試用例均不成功
第二類：
（1）預測出程序中錯誤的總數量
（2）預測這些錯誤中有多大比例可能通過測試而發現
（3）預測這些錯誤中有多少是由各個設計階段產生的，以及什麼樣的測試用例能夠發現這些問題。
第三類結束準則表面上看上去很容易，其中涉及很多判斷和直覺，需要在測試過程中記錄單位時間發現錯誤的總量。假設某個程序正在進行功能測試，對於每週發現的錯誤數量都進行了記錄，如果第七週的曲線仍然相對於前幾周處於上升狀態，那麼這時候結束顯然有些草率。此時應該繼續進行功能測試。另一方面，如果程序中的錯誤一直處於下降階段，並且第七週比前幾周都低，此時也許就是最佳的行動結束功能測試並開始新的測試類型。當然也要考慮其他因素。
最佳結束準則可能是上述三種類型的結合
7.獨立的測試機構
就公司的架構而言，而是部門用該儘可能遠離開發部門。事實上，最理想的測試機構不應該是同一公司的一部分。而是僱傭獨立的公司進行軟件測試。