軟件測試分類的方法其實有很多種，從不同的維度進行分類，其所分的類型也完全不同，通常可以從三個維度對測試方法進行分類。
(1)從被測試對象的角度分類。從被測試對象的角度分類，測試可以分為黑盒測試、白盒測試和灰盒測試。
(2)從被測試對象是否運行的角度進行分類。從被測試對象是否運行的進行分類，測試可以被分為動態測試和靜態測試。
(3)從測試執行時使用的工具角度分類。從測試執行時使用的工具角度分類測試可以分為手工測試和自動化測試。
一、黑盒、白盒、灰盒測試的區別
從被測試對象的角度分類，測試方法可以分為黑盒測試、白盒測試、灰盒測試三種，這也是我們最常看到的分類方法。
任何一個程序在測試時都由這幾部分組成：輸入、程序的處理過程和輸出三部分，如圖1-1 所示。黑盒測試是指在整個測試過程中只關注輸入和輸出，如果輸入一個測試數據，輸出的結果是正確的，我們就認為這個功能是正確的。如輸入測試數據(2,2)，結果如果輸出為4，就認為是正確的，其中程序是如何處理的，測試工程師并不關注，這里有可能是2×2、2+2，也可能是22。當然如果不知道程序是怎么處理的，那么再另一組數據后，可能得到的結果就不一定正確了，如輸入(3,3)，那結果就不一定會正確了。
圖1-1 程序處理過程
白盒測試與黑盒測試不同的地方是，白盒測試不僅僅關注輸入與輸出的結果是否正確，同時還關注程序是如何處理的，同樣是上面的例子，輸入測試數據(2,2)，白盒測試不僅僅關注測試結果是否為4，同時還關注這個程序的內部邏輯處理過程。
關于黑盒測試和白盒測試其實還像社會的兩種人，黑盒測試就相當于黑道，白盒測試就相當于白道。黑道的老大如果要解決什么事情，他們會派下屬去處理，并且老大只關注結果，至于中間是如何處理的，與他沒有關系。而白道的人即我們說的公務員，他們對辦事的整個流程或法律體系都很了解。舉個例子，你親戚和別人打架了，把別人打了，你第一件事不會去報案，而是聯系朋友看法院、派出所或其他的相關部門是否有熟人，因為這些人對法律流程很熟悉，他們很清楚如何將你親戚的責任最小化。
但是這個社會還有一類人，是黑白通吃的，這就是我們測試分類里面的灰盒測試，灰盒測試是界于黑盒測試和白盒測試之間的一種測試。之所以存在灰盒測試，是因為按測試階段來劃分，整個測試的流程包括單元測試、集成測試、系統測試，而白盒測試對應單元測試，黑盒測試對應系統測試，那么在正確的測試過程中，應該是先測試單元模塊，單元模塊測試完成之后，并沒有立即進入系統測試，而是集成測試，這個時候其使用的方法就是灰盒測試，即我們測試完成單個模塊后，雖然單個模塊沒有問題，但并不代表這些模塊組合在一塊時就一定沒有問題。那么要驗證這些功能模塊組合在一起有沒有問題，這就是我們說的集成測試，其使用方法就是灰盒測試。
從某種角度來說，白盒測試顯然比黑盒測試更全面，因為他們不僅關注測試結果，還注重程序內部的邏輯結構，所以有人提出為什么不能只有白盒測試就可以呢?答案顯然是肯定的。討論這個極端的問題，其反過來的問題就是黑盒測試的內容有哪些是白盒測試不可能做到的。我們說黑盒測試是更接近用戶使用的測試，所以關于用戶使用流程、易用性等方面并不是白盒測試可以測試到的，也就是如果白盒測試沒問題后，并不能保證程序的易用性、界面顯示、業務流程等內容就一定沒有錯誤。同樣的道理，顯然只有黑盒測試也是不夠的，因為黑盒測試雖然可以更好地站在用戶的角度進行測試，但黑盒測試并不能像白盒測試那么有效地測試程序內部結構。所以不能極端地認為只有白盒測試或只有黑盒測試可以測試好系統。
所以現在一個完善的測試體系中有這三類方法：黑盒測試、白盒測試、灰盒測試。只有將這三種完美的結合起來，才能更好的保證系統的質量。從軟件測試發展的歷程來看，包括國內軟件測試，其實都是先有黑盒測試才有白盒測試，不可能先做白盒測試再做黑盒測試，并且在現階段國內很少公司做白盒測試，之所以出現這種情況是因為白盒測試對測試工程師的技能要求會高出許多，同時還有一個原因是因為當前國內軟件測試發展還是處于初級階段，所以白盒測試開展的并不理想。
二、動態與靜態測試的區別
如果從被測試對象是否被運行的角度來劃分，測試可以分為靜態測試和動態測試兩種。靜態測試是指不運行被測試的軟件系統，而是采用其他手段和技術對被測試軟件進行檢測的一種測試技術。
例如：代碼走讀、文檔評審、程序分析等都是靜態測試的范疇。常用的靜態分析技術包括：控制流、信息流和數據流，但現在這些方法其實用的比較少，因為很多問題在編輯器的時候就解決了。在我們進行測試過程中，關于靜態測試用得最多的是對文檔進行評審，當然不同文檔在評審時所關注的問題是完全不同的。
動態測試是指按照預先設計的數據和步驟去運行被測軟件系統，從而對被測軟件系統進行檢測的一種測試技術。如果按階段來分，單元測試中常見的動態測試方法就是邏輯覆蓋的方法，而在系統測試階段，我們做的測試都屬于動態測試，因為我們要運行系統才能驗證系統功能是否正確。
動態測試是通過觀察代碼運行時的動作，來提供執行跟蹤、時間分析及測試覆蓋度方面的信息。動態測試通過真正運行程序發現錯誤。通過有效的測試用例，對應的輸入/輸出關系來分析被測程序的運行情況。
三、手工與自動化測試的區別
從測試執行時使用的工具角度分類，測試可以分為手工測試和自動化測試。手工測試是指軟件測試的整個活動過程(如評審、測試設計、測試執行等)都是由軟件測試工程師手工執行人來完成，不使用任何測試工具，狹義上是指測試執行由人工完成，這是最基本的測試形式。
自動化測試是使用軟件來控制測試執行過程，比較實際結果和預期結果是否一致，設置測試的前置條件和其他測試控制條件并輸出測試報告。通常，自動化測試需要在適當的時間使已經形式化的手工測試過程自動化。
前些年幾乎都是手工測試，近幾年自動化測試開始慢慢地開展起來了軟件測試過程分為，一些成熟的企業已經開始有專業的團隊來做自動化測試。那么自動化測試為什么會存在呢?其實也是有著其自身的道理，并不是無緣無故地出現。
隨著現在系統越來越復雜，如果版本升級，新增一些需求，那么我們必須對整個系統進行全面的回歸測試，但這樣將花費巨大的時間成本。例如中國平安的主頁，其綁定了很多子系統，包括平安銀行、平安金融、平安保險等。如果現在只是升級幾個需求的話軟件測試過程分為，那么必須對所有功能都進行全面的測試，而這么大的系統少說也有3000個功能點，這樣回歸測試一輪，可能每天需要幾百人，這個成本是巨大的，所以這個時候我們必須通過自動化測試來解決回歸測試的問題，進而節約測試成本。
并且即使我們不考慮時間成本的問題，手工測試也無法全面回歸，在1.3節中我們有介紹過測試心態的情況，如果我們持續測試一個功能，測試了好幾輪都沒問題，那么下一輪我們可能不會認真且全面地測試，這樣就導致一些問題被遺漏了。但如果我們使用自動化測試工具則不存在這個問題，因為工具不知道它測試了多少輪。
所以自動化測試和手工測試應該是相互結合地使用，也不能只有自動化測試沒有手工測試，因為在自動化測試的概念中說的很清楚：“自動化測試需要在適當的時間使已經形式化的手工測試過程自動化。”也就是說，第一輪測試是不允許做自動化測試的，第一輪必須是手工測試。所以只有自動化測試也不行。