有句話是這麼說的：能動手就別嗶嗶，尤其是在工作節奏堪比跑馬的今天，大家都推崇實幹精神，能解決問題就好，去他的理論。但是無可否認的是，良好的理論素養無論是解決工作中遇到的問題，還是未來的職業發展，都幫助甚大。本文整理彙總了軟件測試行業中常見的一些測試理論，供大家參考。
1、軟件測試按照測試分類有：黑盒測試和白盒測試。
黑盒測試
黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試着眼於程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。
黑盒測試是以用戶的角度，從輸入數據與輸出數據的對應關係出發進行測試的。很明顯，如果外部特性本身設計有問題或規格說明的規定有誤，用黑盒測試方法是發現不了的。
新人入行基本上都是採用黑盒測試的方法來入門的。
白盒測試
白盒測試又稱結構測試、透明盒測試、邏輯驅動測試或基於代碼的測試。白盒測試是一種測試用例設計方法，盒子指的是被測試的軟件，白盒指的是盒子是可視的，你清楚盒子內部的東西以及裏面是如何運作的。"白盒"法全面瞭解程序內部邏輯結構、對所有邏輯路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯着手，得出測試數據。貫穿程序的獨立路徑數是天文數字。
咱們以空調爲例來看什麼是黑盒測試，什麼是白盒測試：
當一臺新的空調組裝完成，質監部門需要對這臺空調的各個功能進行測試，比如開關機是否正常，製冷制熱功能是否正常，定時功能是否正常，等等，並將測試的結果一一記錄下來，如果有問題，及時反饋給設計部來解決，這就是黑盒測試的範疇。
對於空調的設計師們，他們的測試可能就會更復雜一些，除了對空調的各項功能進行測試之外，還要從空調的內在原理來分析，他們甚至會跟蹤空調的內部實現代碼，分析空調的各項數據狀態來看是否正常運行，而不只是從表面功能來看，這就是白盒測試的範疇。
2、按照測試的階段可以分爲：單元測試、集成測試、確認測試和系統測試及驗收測試
單元測試
單元測試（unit testing），是指對軟件中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，一般來說，要根據實際情況去判定其具體含義，如C語言中單元指一個函數，Java裏單元指一個類，圖形化的軟件中可以指一個窗口或一個菜單等。總的來說，單元就是人爲規定的最小的被測功能模塊。單元測試是在軟件開發過程中要進行的最低級別的測試活動，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試。
在一種傳統的結構化編程語言中，比如C，要進行測試的單元一般是函數或子過程。在像C++這樣的面向對象的語言中， 要進行測試的基本單元是類。對Ada語言來說，開發人員可以選擇是在獨立的過程和函數，還是在Ada包的級別上進行單元測試。單元測試的原則同樣被擴展到第四代語言（4GL)的開發中，在這裏基本單元被典型地劃分爲一個菜單或顯示界面。
經常與單元測試聯繫起來的另外一些開發活動包括代碼走讀（Code review)，靜態分析（Static analysis)和動態分析（Dynamic analysis)。靜態分析就是對軟件的源代碼進行研讀，查找錯誤或收集一些度量數據，並不需要對代碼進行編譯和執行。動態分析就是通過觀察軟件運行時的動作，來提供執行跟蹤，時間分析，以及測試覆蓋度方面的信息。
集成測試
集成測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照設計要求（如根據結構圖）組裝成爲子系統或系統，進行集成測試。
實踐表明，一些模塊雖然能夠單獨地工作，但並不能保證連接起來也能正常的工作。一些局部反映不出來的問題，在全局上很可能暴露出來。
確認測試
確認測試的目的是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試後，已經按照設計把所有的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接着就應該進一步驗證軟件的有效性，這就是確認測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。
系統測試
系統測試，英文是System Testing。是將已經確認的軟件、計算機硬件、外設、網絡等其他元素結合在一起，進行信息系統的各種組裝測試和確認測試，系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不符或與之矛盾的地方，從而提出更加完善的方案。系統測試發現問題之後要經過調試找出錯誤原因和位置，然後進行改正。是基於系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的部件。對象不僅僅包括需測試的軟件，還要包含軟件所依賴的硬件、外設甚至包括某些數據、某些支持軟件及其接口等。
驗收測試
驗收測試是部署軟件之前的最後一個測試操作。在軟件產品完成了單元測試、集成測試和系統測試之後，產品發佈之前所進行的軟件測試活動。它是技術測試的最後一個階段，也稱爲交付測試。驗收測試的目的是確保軟件準備就緒，並且可以讓最終用戶將其用於執行軟件的既定功能和任務。
驗收測試是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試後，已經按照設計把所有的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接着就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。
驗收測試，系統開發生命週期方法論的一個階段，這時相關的用戶和獨立測試人員根據測試計劃和結果對系統進行測試和接收。它讓系統用戶決定是否接收系統。它是一項確定產品是否能夠滿足合同或用戶所規定需求的測試。這是管理性和防禦性控制。
在工程及其他相關領域中，驗收測試是指確認一系統是否符合設計規格或契約之需求內容的測試，可能會包括化學測試、物理測試或是性能測試。在系統工程中驗收測試可能包括在系統（例如一套軟件系統、許多機械零件或是一批化學制品）交付前的黑箱測試。軟件開發者常會將系統開發者進行的驗收測試和客戶在接受產品前進行的驗收測試分開。後者一般會稱爲使用者驗收測試、終端客戶測試、實機（驗收）測試、現場（驗收）測試。在進行主要測試程序之前，常用冒煙測試作爲一個此階段的驗收測試。
3、其他的測試理論還有：自動化測試、迴歸測試、冒煙測試、性能測試
自動化測試
一般是指軟件測試的自動化，軟件測試就是在預設條件下運行系統或應用程序，評估運行結果，預先條件應包括正常條件和異常條件。通常，在設計了測試用例並通過評審之後，由測試人員根據測試用例中描述的規程一步步執行測試，得到實際結果與期望結果的比較。在此過程中，爲了節省人力、時間或硬件資源，提高測試效率，便引入了自動化測試的概念。
自動化測試分爲web自動化測試、接口自動化測試、APP自動化測試。
迴歸測試
迴歸測試是指修改了舊代碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。自動迴歸測試將大幅降低系統測試、維護升級等階段的成本。迴歸測試作爲軟件生命週期的一個組成部分，在整個軟件測試過程中佔有很大的工作量比重，軟件開發的各個階段都會進行多次迴歸測試。在漸進和快速迭代開發中，新版本的連續發佈使迴歸測試進行的更加頻繁，而在極端編程方法中，更是要求每天都進行若干次迴歸測試。因此，通過選擇正確的迴歸測試策略來改進迴歸測試的效率和有效性是很有意義的。
冒煙測試
這一術語源自硬件行業。對一個硬件或硬件組件進行更改或修復後，直接給設備加電。如果沒有冒煙，則該組件就通過了測試。在軟件中，“冒煙測試”這一術語描述的是在將代碼更改嵌入到產品的源樹中之前對這些更改進行驗證的過程。在檢查了代碼後，冒煙測試是確定和修復軟件缺陷的最經濟有效的方法。冒煙測試設計用於確認代碼中的更改會按預期運行，且不會破壞整個版本的穩定性。
性能測試
性能測試是通過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級別的測試。