從整體的角度可以分為單元測試、整合測試、系統測試、確認測試。

下面內容來自網路相關資料的整理：

1.單元測試

（1）定義：單元測試（又稱為模組測試）是針對程式模組(軟體設計的最小單位)來進行正確性檢驗的測試工作。程式單元是應用的最小可測試部件。在過程化程式設計中，一個單元就是單個程式、函式、過程等；對於面向物件程式設計，最小單元就是方法，包括基類（超類）、抽象類、或者派生類（子類）中的方法。

（2）單元測試任務包括：1模組介面測試；2模組區域性資料結構測試；3模組邊界條件測試；4模組中所有獨立執行通路測試；5模組的各條錯誤處理通路測試。

模組介面測試是單元測試的基礎。只有在資料能正確流入、流出模組的前提下，其他測試才有意義。

測試介面正確與否應該考慮下列因素：

1輸入的實際引數與形式引數的個數是否相同；2輸入的實際引數與形式引數的屬性是否匹配；3輸入的實際引數與形式引數的量綱是否一致；4呼叫其他模組時所給實際引數的個數是否與被調模組的形參個數相同；5呼叫其他模組時所給實際引數的屬性是否與被調模組的形參屬性匹配；6呼叫其他模組時所給實際引數的量綱是否與被調模組的形參量綱一致；7呼叫預定義函式時所用引數的個數、屬性和次序是否正確；8是否存在與當前入口點無關的引數引用； 9是否修改了只讀型引數；10對全程變數的定義各模組是否一致；11 是否把某些約束作為引數傳遞。

如果模組內包括外部輸入輸出，還應該考慮下列因素：1檔案屬性是否正確；

檢查區域性資料結構是為了保證臨時儲存在模組內的資料在程式執行過程中完整、正確。區域性資料結構往往是錯誤的根源，應仔細設計測試用例，力求發現下面幾類錯誤：1不合適或不相容的型別說明；2變數無初值；3變數初始化或省缺值有錯；4不正確的變數名（拼錯或不正確地截斷）；5出現上溢、下溢和地址異常。　　除了區域性資料結構外，如果可能，單元測試時還應該查清全域性資料（例如FORTRAN的公用區）對模組的影響。

在模組中應對每一條獨立執行路徑進行測試，單元測試的基本任務是保證模組中每條語句至少執行一次。此時設計測試用例是為了發現因錯誤計算、不正確的比較和不適當的控制流造成的錯誤。此時基本路徑測試和迴圈測試是最常用且最有效的測試技術。計算中常見的錯誤包括：1誤解或用錯了算符優先順序；2混合型別運算；3變數初值錯；4精度不夠；5表示式符號錯。　　比較判斷與控制流常常緊密相關，測試用例還應致力於發現下列錯誤：1不同資料型別的物件之間進行比較；2錯誤地使用邏輯運算子或優先順序；3因計算機表示的侷限性，期望理論上相等而實際上不相等的兩個量相等；4比較運算或變量出錯；5迴圈終止條件或不可能出現；6迭代發散時不能退出；7錯誤地修改了迴圈變數。　　一個好的設計應能預見各種出錯條件，並預設各種出錯處理通路，出錯處理通路同樣需要認真測試，測試應著重檢查下列問題：1輸出的出錯資訊難以理解；2記錄的錯誤與實際遇到的錯誤不相符；3在程式自定義的出錯處理段執行之前，系統已介入；4異常處理不當；5錯誤陳述中未能提供足夠的定位出錯資訊。

邊界條件測試是單元測試中最後，也是最重要的一項任務。眾的周知，軟體經常在邊界上失效，採用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有可能發現新的錯誤。

（3）單元測試過程　　一般認為單元測試應緊接在編碼之後，當源程式編制完成並通過複審和編譯檢查，便可開始單元測試。測試用例的設計應與複審工作相結合，根據設計資訊選取測試資料，將增大發現上述各類錯誤的可能性。在確定測試用例的同時，應給出期望結果。　　應為測試模組開發一個驅動模組（driver）和（或）若干個樁模組（stub）,下圖顯示了一般單元測試的環境。驅動模組在大多數場合稱為“主程式”，它接收測試資料並將這些資料傳遞到被測試模組，被測試模組被呼叫後，“主程式”列印“進入-退出”訊息。　　驅動模組和樁模組是測試使用的軟體，而不是軟體產品的組成部分，但它需要一定的開發費用。若驅動和樁模組比較簡單，實際開銷相對低些。遺憾的是，僅用簡單的驅動模組和樁模組不能完成某些模組的測試任務，這些模組的單元測試只能採用下面討論的綜合測試方法。　　提高模組的內聚度可簡化單元測試，如果每個模組只能完成一個，所需測試用例數目將顯著減少，模組中的錯誤也更容易發現。整合測試：在單元測試的基礎上，將模組按照設計要求組裝進行測試。一般包括邏輯關係檢查、資料關係檢查、業務關係檢查、模組間介面檢查、外部介面檢查。

2.整合測試

（1）定義： 整合測試也叫組裝測試、聯合測試、子系統測試或部件測試。整合測試是在單元測試的基礎上，將所有模組按照概要設計要求組裝成為子系統或系統。

（2）整合測試的關注點：

　　1.在把各個模組連線起來時，穿越模組介面的資料是否會丟失。

　　2.各個子功能組合起來，能否達到預期的要求的父功能。

　　3.一個模組的功能是否會對另一個模組的功能產生不利的影響。

　　4.全域性資料結構是否有問題，會不會被異常修改。

　　5.單個模組的誤差積累起來，是否會放大，從而達到不可接受的程度。

（3）整合測試的模式：

     ① 非增殖式整合方式。先分別測試每個模組，再把所有模組按設計要求一次全部組裝起來所要的系統，然後進行整體測試。使用這種方式可能發現一大堆錯誤，但為每個錯誤定位和糾正非常困難，並且在改正一個錯誤的同時又可能引入新的錯誤，新舊錯誤混雜，更難斷定出錯的原因和位置。
　　② 增殖式整合方式。又稱漸增式整合方式。首先對一個個模組進行模組測試，然後將這些模組逐步組裝成較大的系統，在組裝的過程中邊連線邊測試，以發現連線過程中產生的問題。最後通過增殖逐步組裝成為要求的軟體系統。 常用的增殖方法有：自頂向下整合測試、自底向上整合測試、核心整合測試等。

　　自頂向下的增殖方式：將模組按系統程式結構，沿控制層次自頂向下進行整合。由於這種增殖方式在測試過程中較早地驗證了主要的控制和判斷點。在一個功能劃分合理的程式結構中，判斷常出現在較高的層次，較早就能遇到。如果主要控制有問題，儘早發現它能夠減少以後的返工。

　　自底向上的增殖方式：從程式結構的最底層模組開始組裝和測試。因為模組是自底向上進行組裝，對於一個給定層次的模組，它的子模組(包括子模組的所有下屬模組)已經組裝並測試完成，所以不再需要樁模組。在模組的測試過程中需要從子模組得到的資訊可以直接執行子模組得到。

    自頂向下增殖的方式和自底向上增殖的方式各有優缺點。自頂向下增殖方式的缺點是需要建立樁模組。要使樁模組能夠模擬實際子模組的功能將是十分困難的。同時涉及複雜演算法和真正輸入/輸出的模組一般在底層，它們是最容易出問題的模組，到組裝和測試的後期才遇到這些模組，一旦發現問題，導致過多的迴歸測試。而自頂向下增殖方式的優點是能夠較早地發現在主要控制方面的問題。自底向上增殖方式的缺點是“程式一直未能做為一個實體存在，直到最後一個模組加上去後才形成一個實體”。就是說，在自底向上組裝和測試的過程中，對主要的控制直到最後才接觸到。但這種方式的優點是不需要樁模組，而建立驅動模組一般比建立樁模組容易，同時由於涉及到複雜演算法和真正輸入/輸出的模組最先得到組裝和測試，可以把最容易出問題的部分在早期解決。此外自底向上增殖的方式可以實施多個模組的並行測試。

　　核心整合測試：核心系統先行整合測試法的思想是先對核心軟體部件進行整合測試，在測試通過的基礎上再按各外圍軟體部件的重要程度逐個整合到核心系統中。每次加入一個外圍軟體部件都產生一個產品基線，直至最後形成穩定的軟體產品。核心系統先行整合測試法對應的整合過程是一個逐漸趨於閉合的螺旋形曲線，代表產品逐步定型的過程。　　③ 混合增殖式測試

3. 系統測試

（1）定義：系統測試是在所有單元、整合測試後，對系統的功能及效能的總體測試。

（2）系統測試內容：系統不僅僅包括軟體本身，而且還包括計算機硬體及其相關的外圍裝置、實際執行時大批量資料、非正常操作(如黑客攻擊)等。通常意義上的系統測試包括壓力測試、容量測試、效能測試、安全測試、容錯測試等。

　　· 壓力測試(s"esstest)：也稱為強度測試、負載測試。壓力測試是模擬實際應用的軟硬體環境及使用者使用過程的系統負荷，長時間或超大負荷地執行測試軟體，來測試被測系統的效能、可靠性、穩定性等。壓力測試的目的就是在軟體投入使用以前或軟體負載達到極限以前，通過執行可重複的負載測試，瞭解系統硼J靠性、效能瓶頸等，以提高軟體系統的可靠性、穩定性，減少系統的宕機時間和因此帶來的損失。
　　· 容量測試(c印ac時test)：預先分析出反映軟體系統應用特徵的某項指標的極限值，如某個web站點可以支援多少個併發使用者的訪問量、網路線上會議系統的與會者人數。知道了系統的實際容量，如果不能滿足要求，就應該尋求新的解決方案， 以提高系統的容量。若一時沒有新的解決方案，就有必要在產品釋出說明書上明確這些容量的限制，避免引起軟體產品使用上的糾紛。如果實際容量已滿足要求，就能幫助使用者建立對產品的信心。

　　· 效能測試(pe晌nllance test)：通過測試確定系統執行時的效能表現，如得到執行速度、響應時間、佔有系統資源等方面的系統資料。對丁那些實時或嵌入式系統，系統有時滿足了功能要求，但未必能夠滿足效能要求，如某個}{_9站可以被訪問， 而且司以提供預先設定的功能，但每開啟一個頁面都需要1～2分鐘，使用者不可忍 受，其結果沒有使用者願意使用這個網站所提供的服務。

　　· 安全測試(securhyten)：檢查系統對非法侵入的防範能力。安全測試期間。測試人員假扮非法入侵者，採用各種辦法試圖突破防線。系統安全設計的準則是，使非法侵入的代價超過被保護資訊的價值。

　　· 容錯測試(recovervtest)：主要檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤並重新啟動系統。容錯測試首先要通過各種手段，讓軟體強制性地發生故障，然後驗證系統是否能儘快恢復。對於自動恢復需驗證薰新初始化、檢查點、資料恢復和重新啟動等機制的正確性

4.確認測試

 （1）定義：確認測試又稱有效性測試。有效性測試是在模擬的環境下，運用黑盒測試的方法，驗證被測軟體是否滿足需求規格說明書列出的需求。任務是驗證軟體的功能和效能及其他特性是否與使用者的要求一致。對軟體的功能和效能要求在軟體需求規格說明書中已經明確規定，它包含的資訊就是軟體確認測試的基礎。

      確認測試的目的是向未來的使用者表明系統能夠像預定要求那樣工作。經整合測試後，已經按照設計把所有的模組組裝成一個完整的軟體系統，介面錯誤也已經基本排除了，接著就應該進一步驗證軟體的有效性，這就是確認測試的任務，即軟體的功能和效能如同使用者所合理期待的那樣。

 （2）基本方法：

 　通過整合測試之後，軟體已完全組裝起來，介面方面的錯誤也已排除，確認測試即可開始。確認測試應檢查軟體能否按合同要求進行工作，即是否滿足軟體需求說明書中的確認標準。

　　1. 確認測試標準

　　實現軟體確認要通過一系列黑盒測試。確認測試同樣需要制訂測試計劃和過程，測試計劃應規定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟體與需求是否一致。無論是計劃還是過程，都應該著重考慮軟體是否滿足合同規定的所有功能和效能，文件資料是否完整、準確人機介面和其他方面（例如，可移植性、相容性、錯誤恢復能力和可維護性等）是否令使用者滿意。

　　確認測試的結果有兩種可能，一種是功能和效能指標滿足軟體需求說明的要求，使用者可以接受；另一種是軟體不滿足軟體需求說明的要求，使用者無法接受。專案進行到這個階段才發現嚴重錯誤和偏差一般很難在預定的工期內改正，因此必須與使用者協商，尋求一個妥善解決問題的方法。

　　2. 配置複審

　　確認測試的另一個重要環節是配置複審。複審的目的在於保證軟體配置齊全、分類有序，並且包括軟體維護所必須的細節。

　　3. α、β測試

　　事實上，軟體開發人員不可能完全預見使用者實際使用程式的情況。例如，使用者可能錯誤的理解命令，或提供一些奇怪的資料組合，亦可能對設計者自認明瞭的輸出資訊迷惑不解，等等。因此，軟體是否真正滿足終端使用者的要求，應由使用者進行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有系統的測試。有時，驗收測試長達數週甚至數月，不斷暴露錯誤，導致開發延期。一個軟體產品，可能擁有眾多使用者，不可能由每個使用者驗收，此時多采用稱為α、β測試的過程，以期發現那些似乎只有終端使用者才能發現的問題。

　　α測試是指軟體開發公司組織內部人員模擬各類使用者行對即將面市軟體產品（稱為α版本）進行測試，試圖發現錯誤並修正。α測試的關鍵在於儘可能逼真地模擬實際執行環境和使用者對軟體產品的操作並盡最大努力涵蓋所有可能的 使用者操作方式。經過α測試調整的軟體產品稱為β版本。緊隨其後的β測試是指軟體開發公司組織各方面的典型使用者在日常工作中實際使用β版本，並要求使用者報告異常情況、提出批評意見。然後軟體開發公司再對β版本進行改錯和完善。