從整體的角度可以分爲單元測試、集成測試、系統測試、確認測試。
下面內容來自網絡相關資料的整理：
1.單元測試
（1）定義：單元測試（又稱爲模塊測試）是針對程序模塊(軟件設計的最小單位)來進行正確性檢驗的測試工作。程序單元是應用的最小可測試部件。在過程化編程中，一個單元就是單個程序、函數、過程等；對於面向對象編程，最小單元就是方法，包括基類（超類）、抽象類、或者派生類（子類）中的方法。
（2）單元測試任務包括：1 模塊接口測試；2 模塊局部數據結構測試；3 模塊邊界條件測試；4 模塊中所有獨立執行通路測試；5 模塊的各條錯誤處理通路測試。
模塊接口測試是單元測試的基礎。只有在數據能正確流入、流出模塊的前提下，其他測試纔有意義。
測試接口正確與否應該考慮下列因素：
1 輸入的實際參數與形式參數的個數是否相同；
2 輸入的實際參數與形式參數的屬性是否匹配；
3 輸入的實際參數與形式參數的量綱是否一致；
4 調用其他模塊時所給實際參數的個數是否與被調模塊的形參個數相同；
5 調用其他模塊時所給實際參數的屬性是否與被調模塊的形參屬性匹配；
6 調用其他模塊時所給實際參數的量綱是否與被調模塊的形參量綱一致；
7 調用預定義函數時所用參數的個數、屬性和次序是否正確；
8 是否存在與當前入口點無關的參數引用；
9 是否修改了只讀型參數；
10 對全程變量的定義各模塊是否一致；
11 是否把某些約束作爲參數傳遞。
如果模塊內包括外部輸入輸出，還應該考慮下列因素：
1 文件屬性是否正確；
2 OPEN/CLOSE語句是否正確；
3 格式說明與輸入輸出語句是否匹配；
4 緩衝區大小與記錄長度是否匹配；
5 文件使用前是否已經打開；
6 是否處理了文件尾；
7 是否處理了輸入/輸出錯誤；
8 輸出信息中是否有文字性錯誤；
檢查局部數據結構是爲了保證臨時存儲在模塊內的數據在程序執行過程中完整、正確。局部數據結構往往是錯誤的根源，應仔細設計測試用例，力求發現下面幾類錯誤：
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. α、β測試
事實上，軟件開發人員不可能完全預見用戶實際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供一些奇怪的數據組合，亦可能對設計者自認明瞭的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應由用戶進行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有系統的測試。有時，驗收測試長達數週甚至數月，不斷暴露錯誤，導致開發延期。一個軟件產品，可能擁有衆多用戶，不可能由每個用戶驗收，此時多采用稱爲α、β測試的過程，以期發現那些似乎只有最終用戶才能發現的問題。
α測試是指軟件開發公司組織內部人員模擬各類用戶行對即將面市軟件產品（稱爲α版本）進行測試，試圖發現錯誤並修正。α測試的關鍵在於儘可能逼真地模擬實際運行環境和用戶對軟件產品的操作並盡最大努力涵蓋所有可能的 用戶操作方式。經過α測試調整的軟件產品稱爲β版本。緊隨其後的β測試是指軟件開發公司組織各方面的典型用戶在日常工作中實際使用β版本，並要求用戶報告異常情況、提出批評意見。然後軟件開發公司再對β版本進行改錯和完善
————————————————
本文爲CSDN博主「咖啡Q伴侶」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/u012426327/java/article/details/78400045