系統測試有着特定的目的：將系統或程序與其初始目標進行比較，給定目標後有兩含義：
- 系統測試不侷限於系統，若產品是一個程序：系統測試就是試圖說明程序作爲一個整體是如何不滿足其目標的過程
- 根據定義，若產品沒有一組書面的、可度量的目標，系統測試就無法進行
在尋找程序與其目標之間的不一致的過程中，應重點注意那些在設計外部規格說明的過程中所犯的轉換錯誤。系統測試因而成爲一種關鍵的測試類型，因爲就軟件產品本身、所犯錯誤的數量及其嚴重性而言，開發週期的這個階段是最易出錯的
這也暗示與功能測試的情況不同，外部規格說明不能作爲獲得系統測試用例的基礎，否則就破壞了系統測試的目標。然而另一方面，也不能利用目標文檔本身來表示測試用例，因爲根據定義，這些文檔並不包含對程序外部接口的準確描述
克服兩難局面的方法是利用程序的用戶文檔或書面材料：通過分析目標文檔來設計系統測試，分析用戶文檔來闡明測試用例。該方法能夠產生兩方面的作用：
- 將程序與其目標和用戶文檔相比較
- 將用戶文檔與程序目標相比較
![]()
將程序與程序目標進行比較【系統測試的核心目的】，卻不說明用什麼測試用例設計方法。因爲目標文檔闡述了程序該做什麼、做到什麼程度，卻不說明程序功能如何體現
如何編寫測試用例，以試圖證明程序與目標文檔中每條語句都存在着不一致性。因此，系統測試採取了一種不同的測試用例設計方法:不是描述一項技術，我們討論的是不同類型的系統測試用例。由於沒有一個方法，系統測試需要大量的創造性
15種測試用例（並非適合所有程序，爲避免遺漏而提出
- 能力測試
最明顯的系統測試類型是判斷目標文檔提及的每一項能力(避免與功能測試發生混滑而不使用“功能”一詞)是否都確實已經實現
能力測試的過程是逐條語句地檢查目標文檔，當某條語句定義了一個“要做什麼”(例如， “語法應該- …“用戶應當可以指定一個空間範圍…等)，就判斷程序是否滿足。此種類型的測試常常可以在不使用計算機的情況下進行，有時人工對目標和用戶文檔進行比較就足夠了。儘管如此，利用問題檢查單將有助於在下一次進行測試時，確保人工檢查的目標是相同的。 - 容量測試
使程序經受大容量數據的檢驗。舉例來說，編譯器可能要編譯規模非常龐大的源程序，連接編輯器可能需要處理一個包含上千模塊的程序，電子電路模擬器可能要輸入一個包含上T部件的電路，而操作系統的作業隊列可能已經達到飽和的容量。如果程序需要處理跨越不同卷的文件，則應產生足夠的數據使程序從一個卷轉換到另一箇中。換言之，容量測試的目的是爲了證明程序不能處理目標文檔中規定的數據容量
由於容量測試顯然需要大量的資源，鑑幹對機器和工時的考慮，不可進行過多的容量測試【每個程序應該至少進行幾次容量測試】 - 強度測試
強度測試使程序承受高負載或強度的檢驗。這不應和容量測試發生混淆:所謂高強度是指在很短的時間間隔內達到的數據或操作數的最峯值。
如測試一名打字員。容量測試是判斷打字員能否處理大篇幅的稿子，強度測試則是判斷打字員能否達到每分鐘50個單詞的速度
由於強度測試涉及時間因素，因此， 它不適用於很多程序，如編詳器或批處理工資程序。然而，強度測試適用於在可變負載下運行的程序，以及交互式程序、實時程序和過程控制程序。假如某個空中交通控制系統要求在其區域內最多可跟蹤200架飛機，則可以通過模擬200架飛機存在的情況來對其進行強度測試。由於在客觀上無法避免第201架飛機進入該區域，因此需要進一步的強度測試，考察系統的反應
常用於基於web的應用程序 - 易用性測試
發現人爲因素或易用性的問題：
1.每個用戶界面是否都根據最終用戶的智力、教育背景和環境要求而進行了調整?
2.程序的輸出是否有意義、不模糊且沒有計算機的雜亂信息?
3.錯誤診斷{如錯誤信息)是否直接，用戶是否需要有計算機學科的博七學位才能理解？
4.整體的用戶界面是否在語法、慣例、語義、格式、風格和縮寫方面展現出了相當程度的概念完整性、基本的一致性和統一性?
5.在準確性極爲重要的環境裏，如網上銀行系統,輸人中是否有足夠的冗餘信息?eg:該系統可能會要求輸人帳號、用戶名和PIN (個人識別號)來驗證訪問帳戶信息的是合法用戶
6.系統是否包含過多或不太可能用到的選項?現代軟件的一個趨勢是，僅向用戶提供那些基於軟件測試和設計考慮而確定出的最有可能使用的菜單選項。一個設計良好的軟件可以向用戶學習，並開始向不同的用戶展示其經常訪問的菜單項。即使已經有了這樣智能化的菜單系統，仍需要設計成功的軟件，使得對不同選項的訪問合乎邏輯、符合直覺。
7.對於所有的輸入，系統是否返回了某些類型的即時確認信息?舉例來說，在點擊鼠標進行輸入的環境裏，被選項可以變換顏色，或者某個按鈕對象可以顯示凹進或凸起的狀態。如果要讓用戶從列表中選擇，那麼當用戶作出選擇後被選序號應顯示在屏幕上。還有，如果被選的操作需要一些運行時間(如果軟件正在訪問一個遠程的系統)，那麼應顯示一條信息通知用戶當前正在做什麼
8.程序是否易於使用?eg：如果輸入是區分大小字符的，這一點對用戶來說是否清楚?如果程序要求瀏覽一系列的菜單或操作，那麼返回到主菜單的方法是否清楚?用戶是否可以很容易瀏覽到上一層或下一層? - 安全性測試
社會對個人隱私的日益關注，許多軟件都有特別的安全性目標。安全性測試是設計測試用例來突破程序安全檢查的過程。舉例來說，設計測試用例來規避操作系統的內存保護機制，破壞數據庫管理系統的數據安全機制
設計此種測試用例的方法之一是研究類似系統中已知的安全問題，然後生成測試用例，儘量暴露被測系統存在相似問題。例如，在雜誌.聊天室和新聞組中發佈的資料，經常包含有操作系統或其他軟件系統的已知錯誤。通過在與被測軟件提供相似服務的現有系統中搜尋安全漏洞，可以設計測試用例來判斷軟件是否受到類似問題的困擾
基於Web的應用程序常常比絕大多數程序所需的安全測試級別更高。對於電子商務網站尤其如此。儘管已經有了足夠多的技術(例如密碼學)允許客戶在因特網上安全地完成交易，但不能單純依賴技術的應用來確保安全。除此之外，我們必須向客戶羣證明軟件是安全的，否則就會有失去客戶的風險 - 性能測試
很多軟件都有特定的性能/效率目標，這些特性描述爲在特定負載和配置環境下程序的響應時間和吞吐率 - 存儲測試
軟件偶爾會有存儲目標，舉例來說，可能描述了程序使用的內存和輔存的容量,以及臨時文件或溢出文件的大小，應設計測試用例來證明這些存儲目標沒有得到滿足 - 配置測試
諸如操作系統.數據庫管理系統和信息交換系統等軟件都支持多種硬件配置，包括不同類型和數量的I/O設備和通信線路，或不同的存儲容量。通常可能的配置數量非常之大,以致於測試無法面面俱到，但是至少應該使用每一種類型的設備，以最大和最小的配置來測試程序。如果軟件本身的配置可忽略掉某些程序組件，或可運行在不同的計算機上,那麼該軟件所有可能的配置都應測試到
如今的很多軟件都設計成可運行在多種操作系統下，因此如果測試此類程序，應該在該程序面向的所有操作系統環境中對其進行測試。對設計在Web瀏覽器裏運行的程序，需要特別的注意，因爲Web瀏覽器的種類繁多，並不是所有瀏覽器都按同樣方式運行，即使是同一種Web瀏覽器，在不同的操作系統之下，運行方式也會不同 - 兼容性/配置/轉換測試
大多數開發的軟件都並不是全新的，常常是爲了替換某些不完善的系統。這樣的軟件往往有着特定的目標，涉及與現有系統的兼容以及從現有系統的轉換過程。再次強調，在針對這些目標測試程序時，測試用例的目的是證明兼容性目標標未被滿足，轉換過程並未生效。在將數據從一個系統轉移到另一個系統時，應盡力發現錯誤。升級數據庫管理系統就是一個例子。需要確定現有的數據安置到了新的系統中。有很多不同的方法測試這個過程;但這些方法都高度依賴於所使用的數據庫系統 - 安裝測試
有些類型的軟件系統安裝過程非常複雜。測試安裝過程是系統測試中的一個重要部分。 對包含在軟件包中的自動安裝系統而言，尤其重要
安裝程序如果出現故障，會影響用戶對軟件的成功體驗。用戶的第一次體驗來自幹安裝軟件的過程。如果這個過程進行得很糟糕，用戶或顧客就要麼尋找其他的產品，要麼對軟件的有效性不抱太大信心 - 可靠性測試
雖然所有類型的測試都是爲了提高軟件的可靠性，但是如果軟件的目標中包含了對可靠性的特別描述，就必須設計專門的可靠性測試。測試可靠性目標可能很困難------->引一個歸納斷言 - 可恢復性測試
如操作系統、數據庫管理系統和遠程處理系統等軟件通常都有可恢復性目標，說明系統如何從程序錯誤、硬件失效和數據錯誤中恢復過來。系統測試的一個目標是證明這些恢復機制不能夠正確發揮作用。我們可以故意將程序錯誤置入某個系統中，判斷系統是否可以從中恢復
如內存校驗錯誤或I/O設備錯誤等硬件錯誤也可以進行模擬、通信線路中的噪音或數據庫中的無效指針等數據錯誤可以故意生成或模擬出來，以分析系統的反應。這些系統的設計目標之一是使平均恢復時間(MTTR)最小。系統宕機往往會減少公司的收入。我們的一個測試目標是證明系統不能滿足MTTR的服務合同
MTTR往往有上界和下界，所以測試用例應反映出這些界限 - 適用性測試
軟件還可能有適用性或可維護性的目標。所有的此類目標都必須測試到。這些目標可能定義了系統提供的服務輔助功能，包括存儲轉存程序或診斷程序、調試明顯問題的平均時間、維護過程以及內部業務文檔的質量等 - 文檔測試
系統測試需要檢查用戶文檔的正確性。完成此任務的主要方法是根據文檔來確定系統測試用例的形式。也就是說，一旦設計完成某個具體的測試情況，應該使用文檔來作爲編寫實際測試用例的指南。同時，用戶文檔應成爲審查的對象，檢查其正確性和清晰性。在文檔中描述的任何範例應編成測試用例，井提交給程序 - 過程測試
很多軟件都是較大系統的組成部分，這些系統並不完全是自動化的，包含了很多人員操作過程。在系統測試中，必須對所有已規定的人工過程(如系統操作員、數據庫管理員或最終用戶)的操作過程進行測試
舉例來說，數據庫管理員必須記錄備份和恢復數據庫系統的操作過程。在可能的情況下,應由與數據庫管理不相關的人來測試這些過程。然而，公司必須爲充分測試這些過程而提供所需的資源，這些資源通常包括硬件和額外的軟件許可證 - 系統測試的執行
(1)不能由程序員來進行系統測試
(2) 在所有的測試階段之中，這是惟一一個明確地不能由負責該程序開發的機構來執行的測試
第一點基於的事實是：執行系統測試的人思考問題的方式必須與最終用戶相同，這意味着必須充分了解最終用戶的態度和應用環境，以及程序的使用方式。那麼顯然的是，如果可行的話，一位或多位最終用戶是很好的執行測試的候選人。但是，由於一般的最終用戶都不具備執行很多前面所描述的測試類型的能力或專業技術，因此，理想的系統測試小組應由幾位專業的系統測試專家(以執行系統測試作爲職業)、一位或兩位最終用戶的代表一位人類工程學工程師以及該程序主要的分析人或設計者所組成。將原先的設計者包括進來並不違反測試原則【不提倡測試由自己編寫的程序】因爲程序自構思以來已經歷經人手，所以原先的設計者不會再受到心理束縛的影響，對程序的測試不會再觸及該原則
第二點基於的事實是：系統測試是一項“隨心所欲，百無禁忌”的活動，而軟件開發機構會受到心理束縛，有悖於此項活動。而且大多數的開發機構最爲關心的是讓系統測試進行得儘可能順利並按時完成，而不會盡力證明程序不能滿足其目標。系統側試至少應由很少(如果有的話)受開發機構左右的獨立人羣來執行。也許最經濟的執行系統測試的方式(所謂經濟，是指花一定的成本發現最多的錯誤，或利用更少的費用發現相同數量的錯誤)是將測試分包給一個獨立的公司來完成