Hello，大家好，工作之余就測試種類做了一下匯總和整理，以平白的語言敘述了出來，不妥之處還請大家指出來，共同進步。
我涉及到的有單元測試、端到端測試和冒煙測試。
首先是測試總的來說可以分為兩大類：功能測試和非功能測試。
功能測試類型包括：單元測試、集成測試、系統測試、健全性測試、冒煙測試、接口測試、回歸測試、Beta/驗收測試。
非功能性測試類型包括：性能測試、負載測試、壓力測試、容量測試、安全測試、恢復測試、可靠性測試、可用性測試、一致性測試、本地化測試。
0）A/B測試(A/B Testing)
就是准備兩個(A/B)或者兩個以上的版本，讓不同的用戶隨機去訪問這些版本，收集各版本的用戶體驗數據和業務數據。最后分析、評估出最好的版本
1）Alpha測試
這是軟件工程中很常見的測試類型。目標就是盡可能地在發布到市場或者交付給用戶之前找出所有的問題和缺陷。該測試一般是在開發的末端且在Beta測試之前進行，在這個測試過程中可能會驅動開發者進行一些小的設計變動，一般是在開發者網站進行，即只對開發者或者內部用戶開放，一般可以為此類測試創建內部的虛擬用戶環境。
Pre-alpha：有時候軟件會在Alpha或者Beta版本前會發布該測試，相比前兩者，這是個功能不完整的版本。
Alpha：版本功能還沒有完善，需要進一步測試，該版本通常會發送到開發軟件的分組織或者某群體中的軟件測試者進行內部測試。
Beta：該版本會包含所有的功能，但是可能又有一些bug，需要調試反饋，Beta版本是軟件最早的對外公開的軟件版本，由公眾(通常是公司外的第三方開發者和業余玩家)參與測試。
Release Candidate(rc): 發布候選版本，如果沒有出現問題則可以發布成為正式的版本。這個版本包含完整並且比較穩定的功能。
2)驗收測試
通常都是部署軟件之前的最后一個測試操作，也稱為交付測試，由最終客戶執行，他們會驗證端到端的系統流程是否符合業務需求，以及功能是否滿足最終用戶的需求。只有當所有的特性和功能按照期望的運行，客戶才會接受軟件。這是測試的最后階段，在驗收測試之后，軟件將投入生產環境，所以它也叫做用戶驗收測試。舉例來說，驗收測試就是相當於收快遞，包裹是軟件、你就是客戶，是驗收方，貨物不符合要求，是要退貨的。
3)臨時測試
這種測試在臨時基礎上進行的，有時候也稱為隨機測試，即沒有參考任何測試用例、沒有針對該測試的任何計划和文檔。它的目的就是通過執行隨意的流程或者或任意的功能來找出應用的缺陷和問題，它可以由項目的任何人來執行盡管沒有測試用例很難識別缺陷，但是有些時候會發現無法使用現有的測試用例來識別，也就是說它是隨機性的，沒有事先任何的測試計划。
4)可訪問性測試 它是為了確定軟件或者應用程序是否可供殘疾人使用。殘疾人指的是聾人、色盲、智障人士、失明者、老年人和其他殘疾人群體，這里會執行各種檢查，比如針對視覺殘疾的字體大小測試，針對色盲的顏色和對比度測試等等。5)Beta測試 它是一種正式的軟件測試類型，在將產品發布作為商業用途之前完成的最終測試，通常，發布的軟件或者產品的Beta版本僅僅限於特定區域的特定數量的用戶，所以最終用戶實際使用軟件后會將一些問題反饋給公司，公司可以在全面發布之前采取必要的措施。
6)后端測試
前端應用輸入的數據，一般都會存儲在數據庫，所以針對數據庫的這類測試稱為數據可測試或者后端測試，市面上有不同的數據庫，所以該測試會涉及表結構、模式、存儲過程以及數據結構等。后端測試一般不會涉及GUI，通過后端測試可以發現一些數據庫問題，比如數據丟失、死鎖、數據損壞。這些問題在生產環境之前進行修復至關重要。
7)瀏覽器兼容測試
這是兼容性測試的子類型，由測試團隊執行，主要針對的是Web應用，用於確保軟件可以在不同的瀏覽器或者操作系統中運行，或者驗證Web應用程序是否能在瀏覽器的所有版本上運行，以確定應用最終兼容的范圍。
8)后向兼容測試
適用於驗證新開發或更新的軟件是否能在就版本環境運行比如向后兼容的測試會檢查新的軟件是否能正確的處理舊版本軟件創建的問及那格式，比如新版的office是否可以打開舊版本創建的文件同理也可以檢查新版本是否可以兼容舊版本創建的數據表、數據文件、數據結構、配置文件。總則：任何軟件更新應該在先前版本基礎之上良好運行。
9)黑盒測試
它不考慮軟件的內部系統設計，它基於需求和功能進行測試，只關心系統的輸入和輸出以及功能流程。換句話說該測試只是從用戶的角度出發針對軟件界面、功能以及外部結構進行測試，而不考慮程序內部邏輯結構，黑盒測試下面還有很對哦種類，例如集成測試、系統測試、大部分非功能性測試。
10)邊界值測試
邊界值測試，是測試應用處於邊界條件的行為。很多邊界開發者是很難考慮周到的，所以才有一個專門的測試類型來驗證這種情況，邊界值測試檢查應用處於邊界值時是否存在缺陷，邊界值測試通常用於測試不同范圍的數字，每個范圍都有一個上下邊界，就是針對這些邊界值進行測試。比如數字范圍是1-500，那么邊界值就是在這些值上進行驗證：0、1、2、499、500、501.
11)分支測試
是白盒子測試的子類型，在單元測試中實施，顧名思義，表示測試要覆蓋程序代碼的各種條件分支，避免遺漏缺陷，是單元測試覆蓋率的一個指標之一。
12)比較測試
是將產品的優點和弱點與舊版本或者同類進行比較，比如IM會和微信作比較
13)兼容性測試
這是一個大類，用於驗證應用在不同環境、web服務器、硬件、網絡條件下的行為。兼容性測試確保軟件可以在不同的配置、不同的數據庫、不同的瀏覽器以及他們不同的版本下運行。
14)組件測試
一般也稱為模塊測試，一般是由開發者在完成單元測試后執行。將多個功能組合起來作為單一的整體進行測試，目的是發現多個功能在相互連接起來后的缺陷。組件測試可大可小。大的可以到幾個單獨的頁面、模塊、子系統的組合。比如將多個頁面組合起來，測試他們流程跳轉，就屬於組件測試。
15)端到端測試
也是一種黑盒測試類型，類似於系統測試，端到端測試在線模擬的、完整的、真實應用環境下模擬真實用戶對應用進行測試，比如應用會和數據庫交互、會使用網絡通信、或者在適當的情況下其他硬件、應用、系統進行交互，端到端指的是從一個端點到另一個端點的意思，所以端到端測試重點是用於測試模塊和模塊之間的協調性。當應用是分布式系統或者需要其他外部系統協同時，端到端測試扮演着非常重要的角色。它可以全面檢查以確保軟件在不同平台和環境中能准確地交互，該測試有以下目的： 確保應用可以和外部系統之間良好的協調，對於前端來說，是確保頁面和后端之間的良好協調。 檢查從原系統到目標系統的所有系統流 從最終用戶角度驗證需求 識別異構環境中的問題 我們工作中就是使用ECU-TEST測試軟件去檢查Ibox上的車載app是否存在異常，主要的范圍是測試車載軟件的性能，是否可以正常打開，數據是否加載得出來，觸發的事件后台有沒有記錄，與后台能不能正常通信等。
16)等價划分
一種黑盒測試的測試技術，通過等價划分，可以將所有的輸入數據合理地划分為多個分組，只需在每個分組中取一個數據作為測試的輸入條件，這樣可以實現用少量的代表性的測試數據取得較好的測試結果，所以這個測試的目的是：在不導致缺陷的前提下，移除指定分組中重復的用例，簡化測試的工作。比如一個程序接受-10到10之間的值，使用等價分區方法可以划分為三個組，0、負值、正值。接下來的測試只需要從這三個分組中取一個成員進行測試，不需要每個成員都測試一遍。
17)實例測試
實時測試，包含着實時場景還涉及基於測試人員經驗的場景。
18)探索測試
類似於Ad-Hoc測試，探索性測試是由測試團隊進行的非正式測試。目的是探索應用並查找應用中存在的缺陷，在測試期間有一定幾率發現重大甚至可能導致系統故障的缺陷。探索性測試期間，最好跟蹤記錄好測試的流程、以及開始該流程之前的活動記錄，方便復現bug。
19)功能性測試
是一個大類，又稱為行為測試，功能測試會忽略內部實現而關注組件的輸出，目的是驗證是否符合需求，這是一種面向功能需求的黑盒測試類型，它是相對於非功能測試而言的，功能測試需要關注功能或者業務，需要業務耦合程度高，非功能測試則是通用的，比如壓力測試、負載測試等，這些都有通用的工具來支持，不需要很少定制化操作。
20)GUI測試
目的是根據業務需求驗證GUI，在詳細設計文檔和GUI模型中一般會提到應用期望的GUI。 常見的包括測試屏幕上顯示的按鈕和輸入字段的大小、表格中所有文本、表格或內容的對齊規則等等。
21)大猩猩測試
指的是由測試人員執行的測試類型，有時也由開發人員執行，大猩猩測試中，對模塊中的一個模塊或者功能進行了徹底和嚴格的測試，改測試會對一個功能或者模塊進行重復"上百次"的測試，人類根本受不了，所以說是又稱為令人沮喪的測試 目的是檢查應用程序的穩健性。
22)樂觀路線測試
樂觀路線測試的目標是在正常流程上成功測試應用。它不會考慮各種負面或者異常情況。重點只是關注於驗證應用在有效和合法輸入條件下能生成期望的輸出。比如銀行付款，只考慮賬戶有錢的正常狀態。
23)增量集成測試
增量集成測試是一種自下而上的測試方法，即在添加新功能時立即集成應用程序進行連續測試。應用程序功能和模塊應該足夠獨立，以便單獨測試。通常由程序員或者測試人員完成。
24)安裝卸載測試
安裝和卸載測試時在不同硬件或者軟件環境下的不同操作系統上進行完整/部分的安裝、升級、卸載、回滾等測試，常用於桌面端應用。
25)集成測試
是指將所有的模塊集成之后，驗證合並后的功能。模塊通常是代碼模塊、單個應用、網絡上的客戶端和服務器應用等等 集成測試一般在單元測試之后，所以單元測試時集成測試的基礎，沒有進行單元測試的集成測試是不靠譜的。所以最簡單的形式是：把兩個已經測試過的單元組成一個組件，測試他們之間的接口，也就是說集成測試在單元測試的基礎之上，將單元測試中獨立的單元合並起來，驗證他們的協調性，合並后的組件又是一個新的單元，這樣逐步合並測試，最終形成完整的應用程序。這種類型的測試常用於B/S軟件和分布式系統。
26)負載測試
這是一種非功能性測試，負載測試的目的是檢查系統可以承受多少負載而不會降低性能，或者是說最大工作負載是多少負載測試有助於查找特定負載系統下最大容量以及導致軟件性能下降的任何原因，可以使用JMeter、LoadRunner、WebLoad、Silk執行程序等工具執行負載測試。 負載測試經常和性能測試、壓力測試、穩定性測試等聯系在了一起，上圖中的TPS(Transation Per Second)指的是每秒鍾系統可以處理的交易或者事務的數量；Server Resource指的是系統資源占有。 性能測試主要是位於a-b之間，在系統測試初期就會規划一個預期目標，比如給定資源Ax，a點就是性能期望值。也就是說在給定固定資源Ax的情況下，如果TPS可以達到a點甚至更高，就說明系統性能達到或者好於預期，通過性能測試可以驗證系統的處理能力有沒有達到預期。 負載測試：位於b-c之間。對系統不斷增加並發請求，直到系統的某項或者多項指標達到安全的臨界值，比如c，這個c就是所謂的最大負載量，后面再增加請求壓力，系統的處理能力不但不能提高，反倒會下降，通過壓力測試可以得出系統的最大安全負載值。 壓力測試可以得出系統最大的安全負載值。 壓力測試位於c-d之間，在超過安全負載的情況下，繼續對系統增加壓力，直到達到崩潰點，即上圖的d通過夜里測試可以得出系統的最大承受能力 穩定性測試，位於a-d之間，在a、b、c、d不同的點(代表特定的硬件、軟件和網絡環境)，讓系統運行一段較長的時間，檢測系統在不同條件下的系統運行的穩定性。
27)猴子測試
是由測試人員進行的，即把自己當成猴子，在沒有任何知識背景或者理解應用的前提下，隨意輸入和操作。目標是通過隨機輸入數據來檢查應用程序是否崩潰，猴子是隨機執行的，沒有測試用例，也沒有必要了解全部功能。
28)變異測試（可變性測試）
是一種白盒測試，這是一種和單元測試反着來的測試類型。通常單元測試是通過測試用例來驗證代碼是否可靠，而編譯測試是反過來，它首先是更改其中一個程序的源代碼，再跑單元測試，如果單元測試可以通過則可能說明測試用例沒有效果，或者測試用例沒有覆蓋到這處代碼的變異。所以說變異測試可以反過來驗證你的測試用例是否有效。還有就是可以幫助我們找出一些無法被當前測試所防止的潛在錯誤。
29）悲觀測試
和樂觀測試相反，它要求測試者要具有打破常規的思緒，考慮各種情況，使用各種邪惡的、不懷好意、不合法的操作來測試系統，悲觀測試會使用不正確的數據、無效的數據進行輸入來驗證，它來驗證系統是否可以識別異常情況並且按照預期進行。
30）非功能性測試
每一個大型組織都會有一個獨立的團隊，通常稱為非功能測試(NFT)或者性能團隊。其涉及測試肺功能的需求有負載測試、壓力測試、安全性、容量、恢復測試等。NFT的目標是確保軟件或者應用程序的響應時間是否滿足業務需求。例如在加載任何頁面或者系統都不應該花費太多的時間並且在負載峰值期間應該維持良好的運行狀態
31)性能測試
這個術語常常和壓力和負載測試，性能測試主要是用於檢查系統是否滿足性能需求，會使用不同的性能和負載工具來執行此測試。 性能測試這個范圍比較大，廣義上的性能測試包括上文提到的負載測試、壓力測試、穩定性測試、容量測試等，狹義的性能測試指的是在特定資源條件下，測試系統能否達到期望值，也就是基線測試(Baseline Test). 基線測試：在給定的資源下，測試最佳的性能，用作后續測量的參考基線。注意基線測試和基准測試是有區別的這么理解，基准是你想達到的，比如100短跑的世界紀錄，基線是你的成績。 負載測試：在預期峰值的生產負載下測量系統的性能。 穩定性測試：在指定負載下，長時間測量系統的穩定性 壓力測試：測試極端條件下的系統性能
32)恢復測試
用於驗證應用或者系統中崩潰或者災難中恢復的程度，確定系統是否能夠在災難發生后繼續運行。比如應用通過網絡電纜接收數據，突然斷開網絡的鏈接過一段時間再去連上網線，系統應該恢復由於網絡線纜拔出而丟失連接的數據。
33)回歸測試
在修改任意模塊或者功能后，將應用作為一個整體進行測試，稱為回歸測試。目的就是驗證在軟件原有的功能變動后是否保持完整性。有觀點認為回歸測試就是回歸測試，是指重復之前的全部或者部分相同的測試工作，其實是有點道理的，而且因為局部修改而牽動全身的意外在平時開發中並不少見，這種意外性就是回歸測試的存在的目的。 因為在回歸測試中很難覆蓋所有的的系統，通常最好是使用自動化測試工具進行這類測試，比如每次修改完代碼，跑單元測試來確保不影響其他軟件單元。
34)基於風險的測試
在該測試中，功能或者需求將根據其優先級進行測試。基於風險的測試會優先測試高度關鍵的功能，因為這些功能對業務影響最大或者故障概率非常高，。而優先級由業務需求決定，因此一旦為所有功能設置了優先級，則應該首先執行高優先級功能，然后再去執行低優先級功能，低優先級功能可以在時間充裕時測試或者不測試。 基於風險測試應該在“不夠時間來測試整個應用，但是又要按時交付軟件”的情況下執行，通常還需要客戶和高級管理層的討論和批准之后才進行。
35)完整性測試
完整性測試用於確定一個新的軟件版本是否可以開始正式的測試，如果一個應該在一開始使用時就崩潰，那么就說明系統還是不夠穩定，沒有必要進行下一步測試，這種情況應該給開發，以免浪費時間。 在軟件設計階段，測試就會編寫冒煙測試用例； 開發團隊在提交版本給測試之前會自己跑一下冒煙測試用例，檢查一下沒有重大意義的，影響測試進程的bug，如果有則退回開發。 如果通過了完整性測試，則進行冒煙測試，如果沒有通過冒煙測試也會立即打回開發。順利通過完整性測試和冒煙測試之后才會進入正式測試階段。 目的之一就是為了降低測試團隊的工作負擔
36)安全性測試
這也是一個龐大的學科，而且知識每天都在更新，所以安全測試一般由特殊的安全團隊執行，他們以各種黑客手段進行滲透測試。 安全測試旨在確保應用或者網站免受內部和外部威脅的侵害，這個測試包括預防惡意程序、病毒；檢驗授權和身份驗證過程的安全性。他還會檢查軟件對任何黑客攻擊和惡意程序的反應方式，以及在遭到黑客攻擊后如何維護軟件以保護數據安全。
37)冒煙測試
冒煙測試，每當開發團隊提交新的構建的時候，軟件測試團隊就會首先驗證構建，並不確保不存在重大問題，如果存在重大的問題會直接打回開發團隊。 如何通俗的理解冒煙測試呢？這個屬於硬件或者硬件組件進行更改或者修復后，直接給設備加電，如果沒有冒煙，則該組件就通過了測試。舉個例子，給三星Note7加電，如果沒有爆炸，就通過冒煙測試。測試團隊在確保構建穩定后才會進一步執行詳細的測試。冒煙測試會檢查構建中是否存在中斷缺陷，這將阻止測試團隊進一步詳細測試。即如果測試人員發現主要功能不能工作，他們會拒絕這次構建，並且退回給開發團隊。冒煙測試一般會在回歸測試或者其他詳細測試之前進行。
38)靜態測試
靜態測試有點類似於代碼review，在不執行任何代碼的情況下執行(也就是不運行應用),它涉對可交付成果審查(inspection)、review和演練(walkthrough).比如檢查代碼語法、命名約定、項目組織。 靜態測試不僅適用於代碼，也適用於測試用例、測試計划和設計文檔。如果在靜態測試階段發現缺陷，可以將缺陷成本降到最低。比如在設計階段就發現問題，相比到開發階段甚至到生產環境出現問題要好解決。 以前端為例，靜態測試可能包括： 使用Lint工具對程序進行規范檢查，相關的工具有ESLint、TSLint、Stylint等，甚至Typescript這些類型檢查也可以歸到這個范疇。代碼審查，有一些問題是無法通過Lint工具覆蓋的，比如代碼邏輯、異常捕獲、項目組織、內存泄漏等等，這些需要人工走審查。檢查代碼是否與設計一致，是否符合軟件需求、概要和詳細設計，不僅可以看出代碼問題，也可以反過來更早發現需求或者設計是否正確。
39)壓力測試
通過壓力測試，模擬系統收到超過其規格的壓力時失敗的方式和時間，找出系統的崩潰點。這個測試在高負載情況下執行的，例如存取超過容量限制的數據、執行復雜的數據庫查詢、連續暴力輸入到系統加載到數據。
40)系統測試
系統測試在完整的系統測試上進行測試，也就是說系統測試一般都在集成測試之后進行，集成測試之后系統成為了一個整體，整個系統測試是在這個基礎上、在真實運行環境驗證系統是否符合業務需求。這是一種黑盒測試類型的，基於總體需求規范，涵蓋系統的所有組合部分。 系統測試其實不是一個具體的測試技術，而是一個測試階段。這個階段會有很多種測試，一般包括：功能測試、非功能測試’歸類一下系統測試的目的： 確保應用可以作為一個整體良好的運行、確保符合業務需求、確保在真實情況下可以良好的運行，比如進行一些非功能測試，驗證系統的健壯性。其實系統測試和端到端測試類似，可以對比看下： 端到端測試一般針對被測應用本身的以及其依賴的的其它系統。重點關注前端、后端以及中間件之間的處理流程測試類型包含功能測試和非功能測試。
41)單元測試
測試獨立的軟件單元或者模塊可以稱為單元測試,通常是由開發者完成，不是測試人員完成，因為他需要詳細了解內部程序設計和代碼。 單元測試是和開發者最為密切的測試類型，它的測試對象是軟件單元，軟件單元可以是一個函數/方法、一個類或者一個GUI組件等。 這是一種白盒測試，所以要求開發者自己進行，因為只有開發者才知道單元的內部實現，單元測試一般會用測試覆蓋率來驗證單元測試的完成度。 主要是將邏輯出現的各個異常在測試的過程中全方位覆蓋，保證100%的覆蓋率
42)可用性測試
可用性測試用來檢測應用的用戶友好程度。它會驗證新用戶可以輕松理解應用流程，如果用戶陷入麻煩，測試人員要記錄好並提供幫助。可以認為可用性測試是在檢查系統的導航性。
43)漏洞測試
其涉及識別軟件、硬件和網絡中的漏洞。如果漏洞容易受到攻擊，或者容易受到病毒和蠕蟲感染，黑客或者惡意程序就會控制系統。
44)容量測試
非功能測試，會檢查應用在遇到大量數據的系統行為和響應時間，這種大量數據可能會影響系統的性能處理和處理時間的速度。
45)白盒測試
也稱為玻璃盒測試、結構測試、邏輯驅動測試或者是基於代碼的測試，基於應用程序代碼的內部邏輯。即測試人員應該知道內部軟件和代碼是如何工作的，對所有的邏輯路徑進行覆蓋測試，其中，單元測試和靜態測試就是典型的白盒測試，基本上白盒測試可以等同於單元測試。邏輯路徑包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋等。
這只是測試的一部分，實際上有超過100種的測試類型，但是並非所有的測試類型都會被所有項目使用。總的來說就是依據實際的需求來。
更多知識可以關注下面的公眾號查看：
