文章篇幅較長，閱讀完大概20min，建議收藏閱讀， 讀完會有識訓，歡迎點贊關注，
有多少軟體測驗型別呢?
我們作為測驗人員了解很多種不同的軟體測驗型別，例如功能測驗(Functional Test)、非功能測驗、自動測驗、敏捷測驗、以及它們的各種子型別. 盡管在我們的測驗程序中會接觸很多種測驗型別, 或者聽說過某些測驗型別，但是很少人敢說精通所有的測驗型別.
每個測驗型別都有自己的特點、優勢和劣勢，所以我寫這篇文章，科普一下我們今天最常用的測驗型別.
不同的軟體測驗型別
下面是軟體測驗的通用型別串列
功能測驗型別:
單元測驗(Unit testing)
集成測驗(Integration testing)
系統測驗(System testing)
健全性測驗(Sanity testing)
冒煙測驗(Smoke testing)
介面測驗(Interface testing)
回歸測驗(Regression testing)
Beta/驗收測驗(Beta/Acceptance testing)
非功能測驗型別:
性能測驗(Performance Testing)
負載測驗(Load testing)
壓力測驗(Stress testing)
容量測驗(Volume testing)
安全測驗(Security testing)
兼容性測驗(Compatibility testing)
安裝測驗(Install testing)
恢復測驗(Recovery testing)
可靠性測驗(Reliability testing)
可用性測驗(Usability testing)
一致性測驗(Compliance testing)
本地化測驗(Localization testing)
來看看這些測驗型別的細節
如果對軟體測驗、介面、自動化、性能測驗、測驗開發、面試經驗交流，感興趣可以1079636098，群內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站搜集、整理出來的，如果你有好的學習資料可以私聊發我，我會注明出處之后分享給大家，
0) A/B測驗(A/B Testing)
顧名思義， A/B測驗就是準備兩個(A/B)或兩個以上的版本，讓不同的用戶來隨機訪問這些版本，收集各群組的用戶體驗資料和業務資料，最后分析、評估出最好版本，正式采用，如上圖，谷歌使用A/B測驗來決定導航應該是紅色還是藍色，
1) Alpha測驗(Alpha Testing)
Alpha測驗這是軟體工程中很常見的測驗型別，它的目標就是盡可能地在發布到市場或交付給用戶之前找出所有的問題和缺陷，
Alpha測驗一般在開發的末段且在Beta測驗之前進行，在這個測驗程序中可能會驅動開發者進行一些小(minor)的設計變動. Alpha測驗一般在開發者網站進行，即只對開發者或內部用戶開放，一般可以為此類測驗創建內部虛擬的用戶環境，
一般大型的軟體專案都有規范化的軟體版本周期:
Pre-alpha: 有時候軟體會在Alpha或Beta版本前先發布Pre-alpha版本, 相比Alpha和Beta，這是一個功能不完整的版本
Alpha: Alpha版本功能還沒完善，需要進一步測驗，Alpha版本通常會發送到開發軟體的組織或某群體中的軟體測驗者進行內部測驗，
Beta: 一般Beta版本會包含所有功能，但可能又有一些Bug，需要除錯反饋， Beta版本是軟體最早對外公開的軟體版本，由公眾（通常為公司外的第三方開發者和業余玩家）參與測驗，
Release Candidate(rc): 發布候選版本，如果沒有出現問題則可發布成為正式的版本，這個版本包含完整且比較穩定的功能
舉一個典型的例子, 最近把我坑得有點慘的iOS13的發布計劃:
une 3: iOS 13 beta 1 and first look at WWDC 2019 # -> WWDC后就可以裝的，相當于pre-alpha或Alpha階段吧
June 17: iOS 13 beta 2 launched for developers
June 24: iOS 13 public beta release date for adventurous testers # -> 公開Beta版本，相當于上面說的Beta階段
July 3: iOS 13 developer beta 3 launch with some new features
July 8: iOS 13 public beta 2 release date
Early September 2019: iOS 13 Golden Master (final dev beta) # -> 九月初，該發最終Beta版本了，相當于進入RC階段了
Mid-September 2019: iOS 13 likely to launch with new 2019 iPhones # -> 正式版本
現在很多開源專案，已經淡化了瀑布式的軟體版本周期，變成一種持續(Continuous)的、常態化的行為, 例如Firefox:
2) 驗收測驗(Acceptance Testing)
驗收測驗通常是部署軟體之前的最后一個測驗操作, 也稱為交付測驗, 由最終客戶執行，他們會驗證端到端(end to end)的系統流程是否符合業務需求，以及功能是否是滿足最終用戶的需求，只有當所有的特性和功能按照期望的運行，客戶才會接受軟體
這是測驗的最后階段，在驗收測驗之后，軟體將投入生產環境. 所以它也叫用戶驗收測驗(UAT)
舉個例子，驗收測驗就相當于收快遞, 包裹是軟體、你就是客戶，是驗收方，如果貨物不符合你的要求，是要退貨的，
3) 臨時測驗(Ad-hoc Testing)
Ad-hoc中文應該理解為臨時的意思，顧名思義，這種測驗是在臨時基礎上進行的, 有時候也稱為隨機測驗，即沒有參考測驗用例、沒有針對該測驗的任何計劃和檔案，Ad-hoc測驗的目的就是通過執行隨意的流程或任意的功能來找出應用的缺陷和問題
Ad-hoc測驗一種非正式的方法，可以由專案中的任何人執行，盡管沒有測驗用例很難識別缺陷，但是有些時候在Ad-hoc測驗期間發現的缺陷可能無法使用現有的測驗用例來識別, 也就是說它一般用來發現‘意外’的缺陷.
4) 可訪問性測驗(Accessibility Testing)
可訪問性測驗的目的是確定軟體或應用程式是否可供殘疾人使用，殘疾是指聾人，色盲，智障人士，失明者，老年人和其他殘疾人群體，這里會執行各種檢查，例如針對視覺殘疾的字體大小測驗，針對色盲的顏色和對比度測驗等等，
不同平臺、不同應用型別對可訪問性支持情況不太一樣，比如iOS相比其他作業系統則更重視可訪問, 而國外比國內更重視可訪問性，
5) Beta測驗(Beta Testing)
上文Alpha測驗已經提及Beta測驗, Beta測驗是一種正式的軟體測驗型別，在將產品發布到市場或者實際最終用戶之前，由客戶在真實的應用環境中執行，
執行Beta測驗目的是確保軟體或產品中沒有重大故障，并且滿足最終用戶的業務需求，當客戶接受軟體時，Beta測驗才算通過，
通常，此類測驗由最終用戶或其他人完成，這是在將應用發布作為商業用途之前完成的最終測驗，通常，發布的軟體或產品的Beta版本僅限于特定區域中的特定數量的用戶， 所以最終用戶實際使用軟體后會將一些問題反饋給公司，公司可以在全面發布之前采取必要的措施，
Beta測驗在正式版本之前也可能會迭代進行多次.
6) 后端測驗(Back-end Testing)
前端應用輸入的資料，一般都會存盤在資料庫，所以針對資料庫的這類測驗稱為資料庫測驗或者后端測驗. 市面有不同的資料庫，如SQL Server，MySQL和Oracle等，資料庫測驗會涉及表結構，模式，存盤程序，資料結構等，
后端測驗一般不會涉及GUI，測驗人員通過某些手段直接連接到資料庫，從而可以容易地運行一些資料庫請求來驗證資料，通過后端測驗可以發現一些資料庫問題，比如資料丟失、死鎖、資料損壞，這些問題在系統投入生產環境之前進行修復至關重要
7) 瀏覽器兼容測驗(Browser Compatibility Testing)
這是兼容性測驗的子型別，由測驗團隊執行. 瀏覽器兼容測驗主要針對Web應用，用于確保軟體可以在不同瀏覽器或作業系統中運行; 或者驗證Web應用程式是否支持在瀏覽器的所有版本上運行, 以確定應用最終兼容的范圍.
瀏覽器兼容測驗是前端開發者繞不開的坑，
我們有很多策略來應對瀏覽器兼容性，比如漸進增強或者優雅降級, 還有制定瀏覽器兼容規范;
為了撫平瀏覽器之間的差異，我們會使用各種特性檢測工具(Modernizr), 還有各種polyfill(CSS Normaliz, polyfill/shim, css-autoprefixer);
當然為了測驗跨瀏覽器兼容性，還要一些輔助工具，例如BrowserStack, 對于我們這些小團隊，只能下一堆Portable(Portable瀏覽器運行時相互隔離的, 所以不會存在組態檔等沖突問題) 瀏覽器，手工測驗了，
8) 后向兼容測驗(Backward Compatibility Testing)
向后兼容測驗, 用于驗證新開發或更新的軟體是否能在舊版本的環境中運行，
比如向后兼容測驗會檢查新版軟體是否可以正確地處理舊版本軟體創建的檔案格式，例如新版的Office 2016是否可以打開2012創建的檔案，
同理也可以檢查新版本是否可以兼容舊版本軟體創建的資料表、資料檔案、資料結構、組態檔，
任何軟體更新應該在先前版本的基礎之上良好地運行
9) 黑盒測驗(Black Box Testing)
黑盒測驗不考慮軟體的內部系統設計，它基于需求和功能進行測驗, 只關心系統的輸入/輸出以及功能流程，
換句話說黑盒測驗從用戶的角度出發針對軟體界面、功能及外部結構進行測驗，而不考慮程式內部邏輯結構.
黑盒測驗下面有很多子類，例如集成測驗、系統測驗、大部分非功能性測驗
10) 邊界值測驗(Boundary Value Testing)
邊界值測驗, 測驗應用處于邊界條件(boundary level)的行為，很多邊界條件開發者是很難考慮周到的，所以才有一個專門的測驗型別來驗證這種情況
邊界值測驗檢查應用處于邊界值時是否存在缺陷，邊界值測驗通常用于測驗不同范圍的數字, 每個范圍都有一個上下邊界，邊界測驗則是針對這些邊界值進行測驗，
比如數字范圍為1-500, 那么邊界值測驗會在這些值上進行驗證: 0、1、2、499、500、501
11) 分支測驗(Branch Testing)
這是白盒測驗的子型別，在單元測驗中實施. 顧名思義，分支測驗表示測驗要覆寫程式代碼的各種條件分支, 避免遺漏缺陷，分支覆寫是單元測驗覆寫率的一個指標之一
12) 比較測驗(Comparison Testing)
如果對軟體測驗、介面、自動化、性能測驗、測驗開發、面試經驗交流，感興趣可以1079636098，群內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站搜集、整理出來的，如果你有好的學習資料可以私聊發我，我會注明出處之后分享給大家，
比較測驗，將產品的優點和弱點與舊版本或者同類(競品)產品進行比較.
比如類似王自如這種數碼測評欄目，評測一個手機或者其他數碼產品時，一般會橫向和友商產品進行比較，有時候也會縱向和上一代產品比較.
還有一種比較典型的例子就是和行業的領導者比較，比如我們做IM的，會經常和微信比較: ‘你這個應用的啟動速度怎么比微信慢這么多?’
13) 兼容性測驗(Compatibility Testing)
這是一個大類, 兼容性測驗用于驗證應用在不同環境、web服務器、硬體、網路條件下的行為，兼容性測驗確保軟體可以在不同的配置、不同的資料庫、不同的瀏覽器，以及它們不同的版本下運行，兼容性測驗由測驗團隊實施
14) 組件測驗(Component Testing)
組件測驗(此組件非GUI組件, 取組合測驗可能更好理解一點)，一般也稱為模塊測驗(Module Testing), 一般由開發者在完成單元測驗后執行，組件測驗將多個功能組合起來作為單一的整體進行測驗，目的是發現多個功能在相互連接起來之后的缺陷，
組件測驗可大可小，小到函式級別或者類級別的組合，大可以大到幾個單獨的頁面、模塊、子系統的組合， 舉一個前端例子，將多個頁面路由組合起來，測驗它們的流程跳轉，就屬于組件測驗，
15) 端到端測驗(End-to-End Testing)
端到端測驗也是一種黑盒測驗型別，類似于系統測驗. 端到端測驗在模擬的、完整的、真實應用環境下模擬真實用戶對應用進行測驗，比如應用會和資料庫互動、會使用網路通信、或者在適當的情況下和其他硬體、應用、系統進行互動. 端到端是指從一個端點到另一個端點的意思，所以端到端測驗重點用于測驗模塊和模塊之間的協調性，
當應用是分布式系統或者需要和其他外部系統協同時，端到端測驗扮演著非常重要的角色, 它可以全面檢查以確保軟體在不同平臺和環境產品能準確地互動，端到端測驗有以下目的:
確保應用可以和外部系統之間良好的協調，對于前端來說，是確保頁面和后端之間良好協調
檢查從源系統到目標系統的所有系統流
從最終用戶角度驗證需求
識別異構環境中的問題
前端也有很多自動化的端到端測驗工具，比如nightwatch，通過它們可以模擬用戶對頁面進行操作，從而檢驗整個應用流程是否正常和符合需求:
因為和系統測驗很相似，所以它們也被經常拿來比較，
16) 等價劃分(Equivalence Partitioning)
等價劃分, 這是一種黑盒測驗的測驗技術. 通過等價劃分，可以將所有的輸入資料合理地劃分為多個分組，我們只需在每個分組中取一個資料作為測驗的輸入條件, 這樣可以實作用少量代表性的測驗資料取得較好的測驗結果.
所以說這個測驗的目的: 是在不導致缺陷的前提下，移除指定分組中的重復的用例, 簡化測驗的作業
比如一個程式應用接受-10到+10之間的值，使用等價磁區方法可以劃分為三個分組: 0、負值、正值. 接下來的測驗只需從這個三個分組中取一個成員進行測驗, 而不需要-10到+10每個成員都測驗一遍.
17) 實體測驗(Example Testing)
It means real-time testing. Example testing includes the real-time scenario, it also involves the scenarios based on the experience of the testers.
實體測驗意味著實時測驗，實體測驗包含了實時場景、另外還涉及基于測驗人員經驗的場景，
18) 探索測驗(Exploratory Testing)
探索性測驗有點類似于Ad-Hoc測驗. 探索性測驗是由測驗團隊進行的非正式測驗，此測驗的目的是探索應用并查找應用中存在的缺陷，像探險一樣，在測驗期間是有一定幾率發現的重大、甚至可能導致系統故障的缺陷.
在探索性測驗期間，建議跟蹤記錄好測驗的流程、以及開始該流程之前的活動記錄, 方便復現bug.
探索測驗不需要任何檔案和測驗用例.
20) 功能測驗(Functional Testing)
功能測驗是一個大類, 又稱為行為測驗， 功能測驗會忽略內部實作而關注組件的輸出，目的是驗證是否符合需求，這是一種面向功能需求的黑盒測驗型別，
功能測驗是相對非功能測驗而言的, 功能測驗需要關心功能或者業務，需要業務耦合程度高；而非功能測驗則是通用的，比如壓力測驗、負載測驗，這些測驗都有通用的工具來支持，不需要或很少定制化操作.
21) GUI測驗(Graphical User Interface (GUI) Testing)
GUI測驗的目的是根據業務需求驗證GUI，在詳細設計檔案和GUI模型(UI設計檔案)中一般會提到應用期望的GUI.
常見的GUI測驗包括測驗螢屏上顯示的按鈕和輸入欄位的大小、表格中所有文本、表格或內容的對齊規則等等. 如果團隊有UI設計規范，還會驗證是否符合設計規范
22) 大猩猩測驗(Gorilla Testing)
大猩猩測驗是由測驗人員執行的測驗型別，有時也由開發人員執行，在大猩猩測驗中，對模塊中的一個模塊或功能進行了徹底和嚴格的測驗，原文沒有說出大猩猩測驗的精髓，大猩猩測驗會對一個功能或模塊進行重復‘上百次’的測驗, 人類根本受不了這樣子的測驗方式，所以大猩猩測驗的另一個別名是‘令人沮喪的測驗(Frustrating Testing)’
這種測驗的目的是檢查應用程式的穩健性(robustness)
23) 樂觀路線測驗(Happy Path Testing)
樂觀路線測驗的目標是在正常流程上成功測驗應用，它不會考慮各種負面或例外情況，重點只關注于驗證應用在有效和合法輸入的條件下生成期望的輸出. 比如銀行付款，只考慮賬戶有錢的正常狀態
24) 增量集成測驗(Incremental Integration Testing)
增量集成測驗是一種自下而上的測驗方法，即在添加新功能時立即集成應用程式進行連續測驗，應用程式功能和模塊應該足夠獨立，以便單獨測驗，這通常由程式員或測驗人員完成，
25) 安裝卸載測驗(Install/Uninstall Testing)
http://windows.com/stopcode (二維碼自動識別)
安裝和卸載測驗是在不同硬體或軟體環境下的不同作業系統上的進行完整/部分的安裝、升級、卸載、回滾等測驗. 常用于桌面端應用
26) 集成測驗(Integration Testing)
集成測驗是指將所有模塊集成之后，驗證合并后的功能. 模塊通常是代碼模塊、單個應用、網路上的客戶端和服務器應用等等，
集成測驗一般在單元測驗之后，所以單元測驗是集成測驗的基礎，沒有進行單元測驗的集成測驗是不靠譜的，所以最簡單的形式是：‘把兩個已經測驗過的單元組合成一個組件，測驗它們之間的介面’，也就是說集成測驗在單元測驗的基礎之上，將單元測驗中獨立的單元合并起來，驗證它們的協調性, 合并后的組件又是一個新的‘單元’，這樣逐步合并測驗，最終形成完整的應用程式，
這種型別的測驗常用于B/S軟體和分布式系統，
27) 負載測驗(Load Testing)
它是一種非功能性測驗，負載測驗的目的是檢查系統可以承受多少負載而不會降低性能, 或者說確定最大作業負載是多少，
負載測驗有助于查找特定負載下系統的最大容量以及導致軟體性能下降的任何原因，可以使用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不同的點(代表特定的硬體、軟體和網路環境)，讓系統運行一段較長的時間，檢測系統在不同條件下的系統運行的穩定性，
28) 猴子測驗(Monkey Testing)
猴子測驗是由測驗人員進行的，即把自己當成猴子，在沒有任何知識背景或者理解應用前提下，隨意輸入和操作，
猴子測驗的目標是通過提供隨機輸入值/資料來檢查應用程式或系統是否崩潰， 猴子是隨機執行的，沒有測驗用例, 也沒有必要了解系統的全部功能
29) 變異測驗(Mutation Testing)
變異測驗(或者說可變性測驗)是一種白盒測驗，這是一種和單元測驗反著來的測驗型別，
通常單元測驗的思路是通過測驗用例來驗證代碼是否有效可靠，而變異測驗是反過來. 它首先更改其中一個程式的源代碼，再跑單元測驗，如果單元測驗通過則可能說明測驗用例沒有效果，或者測驗用例沒有覆寫到這處代碼變異.
所以說變異測驗可以反過來驗證你的測驗用例是否有效, 還有可以幫助我們找出一些無法被當前測驗所防止的潛在錯誤.
30) 悲觀測驗(Negative Testing)
悲觀測驗和樂觀路線測驗相反, 它要求測驗者要具有“打破”常規的態度，考慮各種例外情況, 使用各種邪惡的 、不懷好意、不合法的操作來測驗系統，悲觀測驗會使用不正確的資料、無效資料或輸入來進行驗證，它驗證系統是否可以識別例外情況，并按預期運行，
31) 非功能測驗(Non-Functional Testing)
每個大型的組織都有一個獨立的團隊，通常稱為非功能測驗（NFT）團隊或性能團隊，
非功能性測驗涉及測驗非功能性需求，如負載測驗、壓力測驗、安全性、容量，恢復測驗等等. NFT測驗的目標是確保軟體或應用程式的回應時間是否滿足業務需求，
例如加載任何頁面或系統都不應該花費太多時間，并且在負載峰值期間應該維持良好運行狀態，
32) 性能測驗(Performance Testing)
這個術語通常與“壓力”和“負載”測驗互換使用，性能測驗用于檢查系統是否滿足性能要求，它會使用不同的性能和負載工具來執行此測驗，
性能測驗這個范圍比較大，廣義上的性能測驗包括了上文提到的負載測驗、壓力測驗、穩定性測驗、容量測驗等等，狹義的性能測驗則是指在特定資源條件下，測驗系統能否達到期望值, 也就是基線測驗(Baseline Test).
總結一下性能測驗的型別:
基線測驗(Baseline Test): 在給定的資源下，測驗最佳的性能，用作后續測量的參考‘基線’，注意基線測驗和基準測驗是有區別的, 這么理解，基準是你想達到的，比如100短跑世界紀錄，基線是你的成績，
負載測驗(Load Test): 在預期峰值的生產負載下測量系統的性能，上文負載測驗已經大概介紹了
穩定性測驗(Endurance Test): 在指定負載下，長時間測量系統的穩定性
壓力測驗(Stress Test): 測驗極端條件下的系統性能
33) 恢復測驗(Recovery Testing)
恢復測驗用于驗證應用或系統中崩潰或災難中恢復的程度. 確定系統是否能夠在災難發生后繼續運行，
比如應用通過網路電纜接收資料，突然斷開了網路電纜的連接, 過一段時間，再插上網線, 系統應該開始恢復由于網路電纜拔出而丟失連接的資料
34) 回歸測驗(Regression Testing)
在修改任意模塊或者功能后，將應用作為一個整體進行測驗，稱為回歸測驗，回歸測驗的目的就是驗證在軟體原有的功能變動后是否保持完整性.
有觀點認為回歸測驗就是回歸測驗是指重復執行以前的全部或部分相同的測驗作業, 其實不是不無道理，而且因為區域修改而牽一發動全身的意外在平時開發中并不少見，這種意外性就是回歸測驗的存在的目的.
因為在回歸測驗中很難覆寫所有系統，通常最好使用自動化測驗工具進行這些類測驗，比如每次修改完代碼，跑單元測驗來確保不影響確保其他軟體單元，
在前端中組件快照測驗(Snapshot Testing)和一些CSS UI測驗，都是屬于回歸測驗型別,它們的原理都是和上一次測驗生成的結果進行比對，以確保沒有意外的修改:
35) 基于風險的測驗(Risk-Based Testing (RBT))
在基于風險的測驗中，功能或需求將根據其優先級進行測驗，基于風險的測驗會優先測驗高度關鍵的功能，因為這些功能對業務影響最大或者故障概率非常高. 而優先級由業務需求決定，因此一旦為所有功能設定了優先級，則應該首先執行高優先級功能或測驗用例，然后再執行低優先級功能， 低優先級功能可以在時間充裕時測驗，或者不測驗，
基于風險的測驗應該在‘不夠時間來測驗整個應用，但是又要按時交付軟體’的情況下執行，通常還需要客戶和高級管理層的討論和批準之后才進行
36) 完整性測驗(Sanity Testing)
完整性測驗用于確定一個新的軟體版本是否可以開始進行正式的測驗，如果一個應該在一開始使用時就崩潰，那么就說明系統還不夠穩定，沒有必要進行下一步測驗，這種情況應該打回給開發，以免浪費時間
以我們公司為例:
在軟體設計階段，測驗團隊就會為撰寫冒煙測驗用例;
開發團隊在提交版本給測驗之前會自己跑一下冒煙用例, 確保沒有重大故障；
將版本提交給測驗團隊后，測驗團隊就會先跑一下完整性測驗，檢查一下有沒有重大的，影響測驗行程的bug，如果有則退回開發
如果通過了完整性測驗, 則進行冒煙測驗，如果冒煙測驗沒有通過也會立即打回開發，
順利通過完整性測驗和冒煙測驗之后才會進入正式測驗階段，
這么做的目的之一就是為了降低測驗團隊的作業負擔，因為他們要對接多個開發團隊的測驗任務，
37) 安全測驗(Security Testing)
安全也是一個龐大的學科，而且知識每天都在更新，所以安全測驗一般由特殊的安全團隊執行，他們以各種黑客手段對系統進行滲透測驗，
安全測驗旨在確保應用或網站免受內部和外部威脅的侵害，這個測驗包括預防惡意程式、病毒； 檢驗授權和身份驗證程序的安全性，
它還會檢查軟體對任何黑客攻擊和惡意程式的反應方式，以及在遭到黑客攻擊后如何維護軟體以保護資料安全
38) 冒煙測驗(Smoke Testing)
冒煙測驗，每當開發團隊提交新的構建時，軟體測驗團隊就會先驗證構建, 并確保不存在重大問題, 如果存在重大問題會直接打回開發團隊.
如何通俗地理解冒煙測驗呢？這個屬于來源于硬體行業，對一個硬體或硬體組件進行更改或修復后，直接給設備加電，如果沒有冒煙，則該組件就通過了測驗，舉個例子，給三星Note7加電，如果沒爆炸，就說明通過了‘冒煙測驗’(感覺當手機測驗者不容易，容易有生命危險 )?
測驗團隊在確保構建穩定后才會進一步執行詳細的測驗， 冒煙檢查會檢查構建中是否存在中斷缺陷(stopper defect, 即影響繼續測驗的缺陷)，這將阻止測驗團隊進一步詳細測驗， 即如果測驗人員發現主要功能不能作業，他們會拒絕這次構建，并退回給開發團隊，
冒煙測驗一般在回歸測驗或其他詳細測驗之前進行
39) 靜態測驗(Static Testing)
靜態測驗有點類似于代碼Review，在不執行任何代碼的情況下執行(也就是不運行應用)，它涉及對可交付成果審查(inspection)、review和演練(walkthrough). 比如檢查代碼語法、命名約定、專案組織，
靜態測驗不僅適用于代碼, 也適用于測驗用例、測驗計劃和設計檔案. 如果在靜態測驗階段發現缺陷，可以將缺陷成本降到最低，比如在設計階段就發現問題，相比到開發階段甚至到生產環境出現問題要好解決
舉前端的例子，靜態測驗可能包括:
使用Lint工具對程式進行規范檢查，相關的工具有ESLint、TSLint、Stylint等, 甚至Typescript這些型別檢查器也可以歸到這個范疇
代碼Review，有一些問題是無法通過Lint工具覆寫的，比如代碼邏輯、例外捕獲、專案組織、記憶體泄露等等，這些需要人工進行走查Review
檢查代碼是否與設計一致，是否符合軟體需求、概要和詳細設計，這不僅可以看出代碼問題，也可以反過來更早發現需求或設計是否正確，
40) 壓力測驗(Stress Testing)
通過壓力測驗，模擬系統受到超出其規格的壓力時失敗的方式和時間, 找出系統的崩潰點. 這個測驗在高負載情況下執行的，例如存取超過容量限制的資料、執行復雜的資料庫查詢、連續暴力輸入到系統或加載到資料庫，
41) 系統測驗(System Testing)
系統測驗在完整的集成系統上進行測驗，也就是說系統測驗一般在集成測驗之后進行，集成測驗之后系統成為了一個整體，系統測驗在這個基礎上、在真實的運行環境中驗證系統是否符合業務需求， 這是一種黑盒型測驗，基于總體需求規范，涵蓋系統的所有組合部分，
系統測驗其實不是一個具體的測驗技術，而是一個測驗階段， 這個階段會進行很多種測驗，一般公司的測驗團隊的作業就集中在這一塊， 一般包含:
功能測驗: 即上面講的，從系統的整體上測驗是否符合業務需求
各種非功能測驗：例如恢復測驗、性能測驗、壓力測驗、安全測驗等等，
歸納一下系統測驗的目的:
確保應用作為一個整體可以良好地運行.
確保應用符合業務需求
確保應用在真實的環境可以良好地運行，比如進行一些非功能測驗，驗證系統的健壯性
其實系統測驗和上文說的端到端測驗很像，它們要求系統作為一個整體進行測驗，可以簡單展開對比一下
系統測驗端到端測驗測驗范圍一般針對被測應用本身一般針對被測應用以及其依賴的其他系統，正如其名，端到端，即從一端點到另一端點，重點關注前端、后端以及中間件之間的處理流程測驗型別包含功能測驗和非功能測驗一般涵蓋所有源系統和目標系統之間的介面級別的測驗測驗時機一般在集成測驗之后一般在系統測驗之后
42) 單元測驗(Unit Testing)
測驗獨立的軟體單元或模塊稱為單元測驗，它通常由開發者完成，而不是由測驗人員完成，因為它需要詳細了解內部程式設計和代碼，
單元測驗是和我們開發者最密切相關的測驗型別，它的測驗物件是軟體單元，軟體單元可以是一個函式/方法、一個類或者一個GUI組件等，
這是一種白盒測驗，所以要求由開發者自己進行，因為只有開發者才知道單元的內部實作，單元測驗一般會使用測驗覆寫率來驗證單元測驗的完成度.
前端常見的單元測驗工具有Jest、Mocha、Jasmine等等. 下面是典型的BDD風格的單元測驗組織:
43) 可用性測驗(Usability Testing)
可用性測驗用于檢測應用的用戶友好程度(User-friendliness). 它會驗證新用戶受可以輕松理解應用流程，如果用戶陷入麻煩，測驗人員要記錄好并提供幫助，可以認為可用性測驗是在檢查系統的導航性(navigation)，
44) 漏洞測驗(Vulnerability Testing)
漏洞測驗，涉及識別軟體、硬體和網路中的漏洞，如果漏洞容易受到攻擊，或者容易受到病毒和蠕蟲感染，黑客或惡意程式就可以控制系統，
因此有必要在投入生產環境之前檢查這些系統是否存在漏洞，
45) 容量測驗(Volume Testing)
容量測驗是由性能測驗團隊執行的一種非功能測驗，容量測驗會檢查應用程式遇到大量的資料時的系統行為和回應時間，這種大量資料可能會影響系統的性能和處理時間的速度，
46) 白盒測驗(White Box Testing)
白盒測驗, 它也被稱為玻璃盒測驗、結構測驗、邏輯驅動測驗或基于代碼的測驗, 基于應用程式代碼的內部邏輯，即測驗人員應該知道內部軟體和代碼是如何作業的, 對所有的邏輯路徑進行覆寫測驗，上面提到的單元測驗和靜態測驗就是典型的白盒測驗, 基本上白盒測驗可以等價于單元測驗，
邏輯路徑包括陳述句覆寫、判定覆寫、條件覆寫、判定/條件覆寫、條件組合覆寫和路徑覆寫等等.
總結
上面提到的軟體測驗型別只是測驗中的一部分，實際有超過100種的測驗型別，但是并非所有測驗型別都會被所有專案使用，所以我這里只是列舉一些比較常見的軟體測驗型別，
如果對軟體測驗、介面、自動化、性能測驗、測驗開發、面試經驗交流，感興趣可以1079636098，群內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站搜集、整理出來的，如果你有好的學習資料可以私聊發我，我會注明出處之后分享給大家，
另外不同的組織中可能會有不同的定義或程序，但是基本概念在任何地方都是相同的，當專案、需求和范圍發生變化時，這些測驗型別、程序及其實作方法會不斷演變，
以上內容就是本篇的全部內容以上內容希望對你有幫助，有被幫助到的朋友歡迎點贊，評論，
如果對軟體測驗、介面測驗、自動化測驗、面試經驗交流，感興趣可以關注我，我們會有同行一起技術交流哦，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/194458.html
標籤：其他