文章篇幅較長，閱讀完大概20min澳泵，建議收藏閱讀实愚， 讀完會有收獲。歡迎點贊關(guān)注兔辅。

有多少軟件測試類型呢?

我們作為測試人員了解很多種不同的軟件測試類型腊敲，例如功能測試(Functional Test)、非功能測試维苔、自動測試碰辅、敏捷測試、以及它們的各種子類型. 盡管在我們的測試過程中會接觸很多種測試類型, 或者聽說過某些測試類型介时，但是很少人敢說精通所有的測試類型.

每個測試類型都有自己的特點没宾、優(yōu)勢和劣勢。所以我寫這篇文章沸柔，科普一下我們今天最常用的測試類型.

不同的軟件測試類型

下面是軟件測試的通用類型列表

• 功能測試類型:

  • 單元測試(Unit testing)
  • 集成測試(Integration testing)
  • 系統(tǒng)測試(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)

來看看這些測試類型的細節(jié)

0) A/B測試(A/B Testing)

顧名思義循衰， A/B測試就是準備兩個(A/B)或兩個以上的版本，讓不同的用戶來隨機訪問這些版本褐澎，收集各群組的用戶體驗數(shù)據(jù)和業(yè)務數(shù)據(jù)会钝，最后分析、評估出最好版本工三，正式采用顽素。如上圖咽弦，谷歌使用A/B測試來決定導航應該是紅色還是藍色。

1) Alpha測試(Alpha Testing)

Alpha測試這是軟件工程中很常見的測試類型胁出。它的目標就是盡可能地在發(fā)布到市場或交付給用戶之前找出所有的問題和缺陷。

Alpha測試一般在開發(fā)的末段且在Beta測試之前進行段审。在這個測試過程中可能會驅(qū)動開發(fā)者進行一些小(minor)的設計變動. Alpha測試一般在開發(fā)者網(wǎng)站進行全蝶，即只對開發(fā)者或內(nèi)部用戶開放，一般可以為此類測試創(chuàng)建內(nèi)部虛擬的用戶環(huán)境寺枉。

一般大型的軟件項目都有規(guī)范化的軟件版本周期:

• Pre-alpha: 有時候軟件會在Alpha或Beta版本前先發(fā)布Pre-alpha版本, 相比Alpha和Beta抑淫，這是一個功能不完整的版本
• Alpha: Alpha版本功能還沒完善，需要進一步測試姥闪。Alpha版本通常會發(fā)送到開發(fā)軟件的組織或某群體中的軟件測試者進行內(nèi)部測試始苇。
• Beta: 一般Beta版本會包含所有功能，但可能又有一些Bug筐喳，需要調(diào)試反饋催式。 Beta版本是軟件最早對外公開的軟件版本，由公眾（通常為公司外的第三方開發(fā)者和業(yè)余玩家）參與測試避归。
• Release Candidate(rc): 發(fā)布候選版本荣月，如果沒有出現(xiàn)問題則可發(fā)布成為正式的版本。這個版本包含完整且比較穩(wěn)定的功能

舉一個典型的例子, 最近把我坑得有點慘的iOS13的發(fā)布計劃:

June 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)       # -> 九月初，該發(fā)最終Beta版本了账锹，相當于進入RC階段了
Mid-September 2019: iOS 13 likely to launch with new 2019 iPhones # -> 正式版本
復制代碼

現(xiàn)在很多開源項目萌业，已經(jīng)淡化了瀑布式的軟件版本周期，變成一種持續(xù)(Continuous)的奸柬、常態(tài)化的行為, 例如Firefox:

2) 驗收測試(Acceptance Testing)

驗收測試通常是部署軟件之前的最后一個測試操作, 也稱為交付測試, 由最終客戶執(zhí)行生年，他們會驗證端到端(end to end)的系統(tǒng)流程是否符合業(yè)務需求，以及功能是否是滿足最終用戶的需求鸟缕。只有當所有的特性和功能按照期望的運行晶框，客戶才會接受軟件

這是測試的最后階段，在驗收測試之后懂从，軟件將投入生產(chǎn)環(huán)境. 所以它也叫用戶驗收測試(UAT)

舉個例子授段，驗收測試就相當于收快遞, 包裹是軟件、你就是客戶番甩，是驗收方侵贵，如果貨物不符合你的要求，是要退貨的缘薛。

3) 臨時測試(Ad-hoc Testing)

Ad-hoc中文應該理解為臨時的意思窍育。顧名思義卡睦，這種測試是在臨時基礎上進行的, 有時候也稱為隨機測試。即沒有參考測試用例漱抓、沒有針對該測試的任何計劃和文檔表锻。Ad-hoc測試的目的就是通過執(zhí)行隨意的流程或任意的功能來找出應用的缺陷和問題

Ad-hoc測試一種非正式的方法，可以由項目中的任何人執(zhí)行乞娄。盡管沒有測試用例很難識別缺陷瞬逊，但是有些時候在Ad-hoc測試期間發(fā)現(xiàn)的缺陷可能無法使用現(xiàn)有的測試用例來識別, 也就是說它一般用來發(fā)現(xiàn)‘意外’的缺陷.

4) 可訪問性測試(Accessibility Testing)

可訪問性測試的目的是確定軟件或應用程序是否可供殘疾人使用。殘疾是指聾人仪或，色盲确镊，智障人士，失明者范删，老年人和其他殘疾人群體蕾域。這里會執(zhí)行各種檢查，例如針對視覺殘疾的字體大小測試到旦，針對色盲的顏色和對比度測試等等旨巷。

不同平臺、不同應用類型對可訪問性支持情況不太一樣厢绝，比如iOS相比其他操作系統(tǒng)則更重視可訪問, 而國外比國內(nèi)更重視可訪問性契沫。

5) Beta測試(Beta Testing)

上文Alpha測試已經(jīng)提及Beta測試, Beta測試是一種正式的軟件測試類型，在將產(chǎn)品發(fā)布到市場或者實際最終用戶之前昔汉，由客戶在真實的應用環(huán)境中執(zhí)行懈万。

執(zhí)行Beta測試目的是確保軟件或產(chǎn)品中沒有重大故障，并且滿足最終用戶的業(yè)務需求靶病。當客戶接受軟件時会通，Beta測試才算通過。

通常娄周，此類測試由最終用戶或其他人完成涕侈。這是在將應用發(fā)布作為商業(yè)用途之前完成的最終測試。通常煤辨，發(fā)布的軟件或產(chǎn)品的Beta版本僅限于特定區(qū)域中的特定數(shù)量的用戶裳涛。 所以最終用戶實際使用軟件后會將一些問題反饋給公司。公司可以在全面發(fā)布之前采取必要的措施众辨。

Beta測試在正式版本之前也可能會迭代進行多次.

6) 后端測試(Back-end Testing)

前端應用輸入的數(shù)據(jù)端三，一般都會存儲在數(shù)據(jù)庫，所以針對數(shù)據(jù)庫的這類測試稱為數(shù)據(jù)庫測試或者后端測試. 市面有不同的數(shù)據(jù)庫鹃彻，如SQL Server郊闯，MySQL和Oracle等。數(shù)據(jù)庫測試會涉及表結(jié)構(gòu)，模式团赁，存儲過程育拨，數(shù)據(jù)結(jié)構(gòu)等。

后端測試一般不會涉及GUI欢摄，測試人員通過某些手段直接連接到數(shù)據(jù)庫熬丧，從而可以容易地運行一些數(shù)據(jù)庫請求來驗證數(shù)據(jù)。通過后端測試可以發(fā)現(xiàn)一些數(shù)據(jù)庫問題剧浸，比如數(shù)據(jù)丟失锹引、死鎖、數(shù)據(jù)損壞唆香。這些問題在系統(tǒng)投入生產(chǎn)環(huán)境之前進行修復至關(guān)重要

7) 瀏覽器兼容測試(Browser Compatibility Testing)

這是兼容性測試的子類型，由測試團隊執(zhí)行. 瀏覽器兼容測試主要針對Web應用吨艇，用于確保軟件可以在不同瀏覽器或操作系統(tǒng)中運行; 或者驗證Web應用程序是否支持在瀏覽器的所有版本上運行, 以確定應用最終兼容的范圍.

瀏覽器兼容測試是前端開發(fā)者繞不開的坑躬它。

我們有很多策略來應對瀏覽器兼容性，比如漸進增強或者優(yōu)雅降級, 還有制定瀏覽器兼容規(guī)范;

為了撫平瀏覽器之間的差異东涡，我們會使用各種特性檢測工具(Modernizr), 還有各種polyfill(CSS Normaliz, polyfill/shim, css-autoprefixer);

當然為了測試跨瀏覽器兼容性冯吓，還要一些輔助工具，例如BrowserStack, 對于我們這些小團隊疮跑，只能下一堆Portable(Portable瀏覽器運行時相互隔離的, 所以不會存在配置文件等沖突問題) 瀏覽器组贺，手工測試了。

8) 后向兼容測試(Backward Compatibility Testing)

向后兼容測試, 用于驗證新開發(fā)或更新的軟件是否能在舊版本的環(huán)境中運行祖娘。

比如向后兼容測試會檢查新版軟件是否可以正確地處理舊版本軟件創(chuàng)建的文件格式失尖。例如新版的Office 2016是否可以打開2012創(chuàng)建的文件。

同理也可以檢查新版本是否可以兼容舊版本軟件創(chuàng)建的數(shù)據(jù)表渐苏、數(shù)據(jù)文件掀潮、數(shù)據(jù)結(jié)構(gòu)、配置文件琼富。

任何軟件更新應該在先前版本的基礎之上良好地運行

9) 黑盒測試(Black Box Testing)

黑盒測試不考慮軟件的內(nèi)部系統(tǒng)設計仪吧，它基于需求和功能進行測試, 只關(guān)心系統(tǒng)的輸入/輸出以及功能流程。

換句話說黑盒測試從用戶的角度出發(fā)針對軟件界面鞠眉、功能及外部結(jié)構(gòu)進行測試薯鼠，而不考慮程序內(nèi)部邏輯結(jié)構(gòu).

黑盒測試下面有很多子類，例如集成測試械蹋、系統(tǒng)測試出皇、大部分非功能性測試

10) 邊界值測試(Boundary Value Testing)

邊界值測試, 測試應用處于邊界條件(boundary level)的行為。很多邊界條件開發(fā)者是很難考慮周到的朝蜘，所以才有一個專門的測試類型來驗證這種情況

邊界值測試檢查應用處于邊界值時是否存在缺陷恶迈。邊界值測試通常用于測試不同范圍的數(shù)字, 每個范圍都有一個上下邊界，邊界測試則是針對這些邊界值進行測試。

比如數(shù)字范圍為1-500, 那么邊界值測試會在這些值上進行驗證: 0暇仲、1步做、2踊赠、499马昙、500股缸、501

11) 分支測試(Branch Testing)

這是白盒測試的子類型攻询，在單元測試中實施. 顧名思義巧颈，分支測試表示測試要覆蓋程序代碼的各種條件分支, 避免遺漏缺陷烂琴。分支覆蓋是單元測試覆蓋率的一個指標之一

12) 比較測試(Comparison Testing)

比較測試误堡，將產(chǎn)品的優(yōu)點和弱點與舊版本或者同類(競品)產(chǎn)品進行比較.

比如類似王自如這種數(shù)碼測評欄目铆农，評測一個手機或者其他數(shù)碼產(chǎn)品時佑颇，一般會橫向和友商產(chǎn)品進行比較顶掉，有時候也會縱向和上一代產(chǎn)品比較.

還有一種比較典型的例子就是和行業(yè)的領導者比較，比如我們做IM的挑胸，會經(jīng)常和微信比較: '你這個應用的啟動速度怎么比微信慢這么多?'

13) 兼容性測試(Compatibility Testing)

這是一個大類, 兼容性測試用于驗證應用在不同環(huán)境痒筒、web服務器、硬件茬贵、網(wǎng)絡條件下的行為簿透。兼容性測試確保軟件可以在不同的配置、不同的數(shù)據(jù)庫解藻、不同的瀏覽器老充，以及它們不同的版本下運行。兼容性測試由測試團隊實施

14) 組件測試(Component Testing)

組件測試(此組件非GUI組件, 取組合測試可能更好理解一點)螟左，一般也稱為模塊測試(Module Testing), 一般由開發(fā)者在完成單元測試后執(zhí)行啡浊。組件測試將多個功能組合起來作為單一的整體進行測試，目的是發(fā)現(xiàn)多個功能在相互連接起來之后的缺陷路狮。

組件測試可大可小虫啥，小到函數(shù)級別或者類級別的組合，大可以大到幾個單獨的頁面奄妨、模塊涂籽、子系統(tǒng)的組合。 舉一個前端例子砸抛，將多個頁面路由組合起來评雌，測試它們的流程跳轉(zhuǎn)，就屬于組件測試直焙。

15) 端到端測試(End-to-End Testing)

端到端測試也是一種黑盒測試類型景东，類似于系統(tǒng)測試. 端到端測試在模擬的、完整的奔誓、真實應用環(huán)境下模擬真實用戶對應用進行測試斤吐，比如應用會和數(shù)據(jù)庫交互搔涝、會使用網(wǎng)絡通信、或者在適當?shù)那闆r下和其他硬件和措、應用庄呈、系統(tǒng)進行交互. 端到端是指從一個端點到另一個端點的意思，所以端到端測試重點用于測試模塊和模塊之間的協(xié)調(diào)性派阱。

當應用是分布式系統(tǒng)或者需要和其他外部系統(tǒng)協(xié)同時诬留，端到端測試扮演著非常重要的角色, 它可以全面檢查以確保軟件在不同平臺和環(huán)境產(chǎn)品能準確地交互。端到端測試有以下目的:

• 確保應用可以和外部系統(tǒng)之間良好的協(xié)調(diào)贫母。對于前端來說文兑，是確保頁面和后端之間良好協(xié)調(diào)
• 檢查從源系統(tǒng)到目標系統(tǒng)的所有系統(tǒng)流
• 從最終用戶角度驗證需求
• 識別異構(gòu)環(huán)境中的問題

前端也有很多自動化的端到端測試工具，比如nightwatch腺劣，通過它們可以模擬用戶對頁面進行操作绿贞，從而檢驗整個應用流程是否正常和符合需求:

因為和系統(tǒng)測試很相似，所以它們也被經(jīng)常拿來比較橘原。

16) 等價劃分(Equivalence Partitioning)

等價劃分, 這是一種黑盒測試的測試技術(shù). 通過等價劃分樟蠕，可以將所有的輸入數(shù)據(jù)合理地劃分為多個分組，我們只需在每個分組中取一個數(shù)據(jù)作為測試的輸入條件, 這樣可以實現(xiàn)用少量代表性的測試數(shù)據(jù)取得較好的測試結(jié)果.

所以說這個測試的目的: 是在不導致缺陷的前提下靠柑，移除指定分組中的重復的用例, 簡化測試的工作

比如一個程序應用接受-10到+10之間的值，使用等價分區(qū)方法可以劃分為三個分組: 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.

實例測試意味著實時測試。實例測試包含了實時場景耻警、另外還涉及基于測試人員經(jīng)驗的場景隔嫡。

18) 探索測試(Exploratory Testing)

探索性測試有點類似于Ad-Hoc測試. 探索性測試是由測試團隊進行的非正式測試。此測試的目的是探索應用并查找應用中存在的缺陷甘穿。像探險一樣腮恩，在測試期間是有一定幾率發(fā)現(xiàn)的重大、甚至可能導致系統(tǒng)故障的缺陷.

在探索性測試期間温兼，建議跟蹤記錄好測試的流程秸滴、以及開始該流程之前的活動記錄, 方便復現(xiàn)bug.

探索測試不需要任何文檔和測試用例.

20) 功能測試(Functional Testing)

功能測試是一個大類, 又稱為行為測試， 功能測試會忽略內(nèi)部實現(xiàn)而關(guān)注組件的輸出募判，目的是驗證是否符合需求荡含，這是一種面向功能需求的黑盒測試類型。

功能測試是相對非功能測試而言的, 功能測試需要關(guān)心功能或者業(yè)務届垫，需要業(yè)務耦合程度高释液；而非功能測試則是通用的，比如壓力測試装处、負載測試误债，這些測試都有通用的工具來支持，不需要或很少定制化操作.

21) GUI測試(Graphical User Interface (GUI) Testing)

GUI測試的目的是根據(jù)業(yè)務需求驗證GUI。在詳細設計文檔和GUI模型(UI設計文檔)中一般會提到應用期望的GUI.

常見的GUI測試包括測試屏幕上顯示的按鈕和輸入字段的大小寝蹈、表格中所有文本李命、表格或內(nèi)容的對齊規(guī)則等等. 如果團隊有UI設計規(guī)范，還會驗證是否符合設計規(guī)范

22) 大猩猩測試(Gorilla Testing)

大猩猩測試是由測試人員執(zhí)行的測試類型躺盛，有時也由開發(fā)人員執(zhí)行项戴。在大猩猩測試中，對模塊中的一個模塊或功能進行了徹底和嚴格的測試槽惫。原文沒有說出大猩猩測試的精髓周叮，大猩猩測試會對一個功能或模塊進行重復‘上百次’的測試, 人類根本受不了這樣子的測試方式，所以大猩猩測試的另一個別名是‘令人沮喪的測試(Frustrating Testing)’

這種測試的目的是檢查應用程序的穩(wěn)健性(robustness)

23) 樂觀路線測試(Happy Path Testing)

樂觀路線測試的目標是在正常流程上成功測試應用界斜。它不會考慮各種負面或異常情況仿耽。重點只關(guān)注于驗證應用在有效和合法輸入的條件下生成期望的輸出. 比如銀行付款，只考慮賬戶有錢的正常狀態(tài)??

24) 增量集成測試(Incremental Integration Testing)

增量集成測試是一種自下而上的測試方法各薇，即在添加新功能時立即集成應用程序進行連續(xù)測試项贺。應用程序功能和模塊應該足夠獨立，以便單獨測試峭判。這通常由程序員或測試人員完成开缎。

25) 安裝卸載測試(Install/Uninstall Testing)

安裝和卸載測試是在不同硬件或軟件環(huán)境下的不同操作系統(tǒng)上的進行完整/部分的安裝、升級林螃、卸載奕删、回滾等測試. 常用于桌面端應用

26) 集成測試(Integration Testing)

集成測試是指將所有模塊集成之后，驗證合并后的功能. 模塊通常是代碼模塊疗认、單個應用完残、網(wǎng)絡上的客戶端和服務器應用等等。

集成測試一般在單元測試之后横漏，所以單元測試是集成測試的基礎谨设，沒有進行單元測試的集成測試是不靠譜的。所以最簡單的形式是：'把兩個已經(jīng)測試過的單元組合成一個組件缎浇，測試它們之間的接口'扎拣。也就是說集成測試在單元測試的基礎之上，將單元測試中獨立的單元合并起來华畏，驗證它們的協(xié)調(diào)性, 合并后的組件又是一個新的‘單元’鹏秋，這樣逐步合并測試，最終形成完整的應用程序亡笑。

這種類型的測試常用于B/S軟件和分布式系統(tǒng)侣夷。

27) 負載測試(Load Testing)

它是一種非功能性測試，負載測試的目的是檢查系統(tǒng)可以承受多少負載而不會降低性能, 或者說確定最大工作負載是多少仑乌。

負載測試有助于查找特定負載下系統(tǒng)的最大容量以及導致軟件性能下降的任何原因百拓∏俣В可以使用JMeter，LoadRunner衙传，WebLoad决帖，Silk執(zhí)行程序等工具執(zhí)行負載測試。

負載測試經(jīng)常和性能測試蓖捶、壓力測試地回、穩(wěn)定性測試等聯(lián)系在一起。如上圖(來源于淘寶性能白皮書). 其中TPS(Transation Per Second)指的是每秒鐘系統(tǒng)可以處理的交易或事務的數(shù)量; Server Resource指的是系統(tǒng)資源占有.

• 性能測試. 主要位于a-b之間. 在系統(tǒng)設計初期就會規(guī)劃一個預期目標, 比如給定資源Ax俊鱼，a點就是性能期望值刻像。也就是說在給定固定資源Ax的情況下，如果TPS可以達到a點甚至更高并闲，就說明系統(tǒng)性能達到或者好于預期. 通過性能測試可以驗證系統(tǒng)的處理能力有沒有達到預期
• 負載測試. 位于b-c之間细睡。對系統(tǒng)不斷增加并發(fā)請求，直到系統(tǒng)的某項或者多項指標達到安全的臨界值帝火，如上圖中的c溜徙，這個c就是所謂的最大負載量。后面再增加請求壓力犀填，系統(tǒng)的處理能力不但不能提高蠢壹，返回會下降. 通過壓力測試可以得出系統(tǒng)最大的安全負載值
• 壓力測試. 位于c-d之間。在超過安全負載的情況下九巡，繼續(xù)對系統(tǒng)增加壓力知残，直到達到崩潰點, 即上圖的d. 通過壓力測試可以得出系統(tǒng)的最大承受能力
• 穩(wěn)定性測試. 位于a-d之間。在a比庄、b、c乏盐、d不同的點(代表特定的硬件佳窑、軟件和網(wǎng)絡環(huán)境)，讓系統(tǒng)運行一段較長的時間父能，檢測系統(tǒng)在不同條件下的系統(tǒng)運行的穩(wěn)定性神凑。

28) 猴子測試(Monkey Testing)

猴子測試是由測試人員進行的，即把自己當成猴子何吝，在沒有任何知識背景或者理解應用前提下溉委，隨意輸入和操作。

猴子測試的目標是通過提供隨機輸入值/數(shù)據(jù)來檢查應用程序或系統(tǒng)是否崩潰爱榕。 猴子是隨機執(zhí)行的瓣喊，沒有測試用例, 也沒有必要了解系統(tǒng)的全部功能

29) 變異測試(Mutation Testing)

變異測試(或者說可變性測試)是一種白盒測試，這是一種和單元測試反著來的測試類型黔酥。

通常單元測試的思路是通過測試用例來驗證代碼是否有效可靠藻三，而變異測試是反過來. 它首先更改其中一個程序的源代碼洪橘，再跑單元測試，如果單元測試通過則可能說明測試用例沒有效果棵帽，或者測試用例沒有覆蓋到這處代碼變異.

所以說變異測試可以反過來驗證你的測試用例是否有效, 還有可以幫助我們找出一些無法被當前測試所防止的潛在錯誤.

30) 悲觀測試(Negative Testing)

悲觀測試和樂觀路線測試相反, 它要求測試者要具有“打破”常規(guī)的態(tài)度熄求，考慮各種異常情況, 使用各種邪惡的??、不懷好意逗概、不合法的操作來測試系統(tǒng)弟晚。悲觀測試會使用不正確的數(shù)據(jù)、無效數(shù)據(jù)或輸入來進行驗證逾苫。它驗證系統(tǒng)是否可以識別異常情況卿城，并按預期運行。

31) 非功能測試(Non-Functional Testing)

每個大型的組織都有一個獨立的團隊隶垮，通常稱為非功能測試（NFT）團隊或性能團隊藻雪。

非功能性測試涉及測試非功能性需求，如負載測試狸吞、壓力測試勉耀、安全性、容量蹋偏，恢復測試等等. NFT測試的目標是確保軟件或應用程序的響應時間是否滿足業(yè)務需求便斥。

例如加載任何頁面或系統(tǒng)都不應該花費太多時間，并且在負載峰值期間應該維持良好運行狀態(tài)威始。

32) 性能測試(Performance Testing)

這個術(shù)語通常與“壓力”和“負載”測試互換使用枢纠。性能測試用于檢查系統(tǒng)是否滿足性能要求。它會使用不同的性能和負載工具來執(zhí)行此測試黎棠。

性能測試這個范圍比較大晋渺，廣義上的性能測試包括了上文提到的負載測試、壓力測試脓斩、穩(wěn)定性測試木西、容量測試等等。狹義的性能測試則是指在特定資源條件下随静，測試系統(tǒng)能否達到期望值, 也就是基線測試(Baseline Test).

總結(jié)一下性能測試的類型:

• 基線測試(Baseline Test): 在給定的資源下八千，測試最佳的性能，用作后續(xù)測量的參考‘基線’燎猛。注意基線測試和基準測試是有區(qū)別的, 這么理解恋捆，基準是你想達到的，比如100短跑世界紀錄重绷，基線是你的成績沸停。
• 負載測試(Load Test): 在預期峰值的生產(chǎn)負載下測量系統(tǒng)的性能。上文負載測試已經(jīng)大概介紹了
• 穩(wěn)定性測試(Endurance Test): 在指定負載下昭卓，長時間測量系統(tǒng)的穩(wěn)定性
• 壓力測試(Stress Test): 測試極端條件下的系統(tǒng)性能

33) 恢復測試(Recovery Testing)

恢復測試用于驗證應用或系統(tǒng)中崩潰或災難中恢復的程度. 確定系統(tǒng)是否能夠在災難發(fā)生后繼續(xù)運行星立。

比如應用通過網(wǎng)絡電纜接收數(shù)據(jù)爽茴，突然斷開了網(wǎng)絡電纜的連接, 過一段時間，再插上網(wǎng)線, 系統(tǒng)應該開始恢復由于網(wǎng)絡電纜拔出而丟失連接的數(shù)據(jù)

34) 回歸測試(Regression Testing)

在修改任意模塊或者功能后绰垂，將應用作為一個整體進行測試室奏，稱為回歸測試。回歸測試的目的就是驗證在軟件原有的功能變動后是否保持完整性.

有觀點認為回歸測試就是回歸測試是指重復執(zhí)行以前的全部或部分相同的測試工作, 其實不是不無道理劲装。而且因為局部修改而牽一發(fā)動全身的意外在平時開發(fā)中并不少見胧沫，這種意外性就是回歸測試的存在的目的.

因為在回歸測試中很難覆蓋所有系統(tǒng)，通常最好使用自動化測試工具進行這些類測試占业。比如每次修改完代碼绒怨，跑單元測試來確保不影響確保其他軟件單元。

在前端中組件快照測試(Snapshot Testing)和一些CSS UI測試谦疾，都是屬于回歸測試類型,它們的原理都是和上一次測試生成的結(jié)果進行比對南蹂，以確保沒有意外的修改:

35) 基于風險的測試(Risk-Based Testing (RBT))

在基于風險的測試中，功能或需求將根據(jù)其優(yōu)先級進行測試念恍×基于風險的測試會優(yōu)先測試高度關(guān)鍵的功能，因為這些功能對業(yè)務影響最大或者故障概率非常高. 而優(yōu)先級由業(yè)務需求決定峰伙，因此一旦為所有功能設置了優(yōu)先級疗疟，則應該首先執(zhí)行高優(yōu)先級功能或測試用例，然后再執(zhí)行低優(yōu)先級功能瞳氓。 低優(yōu)先級功能可以在時間充裕時測試策彤，或者不測試。

基于風險的測試應該在‘不夠時間來測試整個應用匣摘，但是又要按時交付軟件’的情況下執(zhí)行店诗，通常還需要客戶和高級管理層的討論和批準之后才進行

36) 完整性測試(Sanity Testing)

完整性測試用于確定一個新的軟件版本是否可以開始進行正式的測試，如果一個應該在一開始使用時就崩潰音榜，那么就說明系統(tǒng)還不夠穩(wěn)定必搞，沒有必要進行下一步測試。這種情況應該打回給開發(fā)囊咏，以免浪費時間

以我們公司為例:

• 在軟件設計階段，測試團隊就會為編寫冒煙測試用例;
• 開發(fā)團隊在提交版本給測試之前會自己跑一下冒煙用例, 確保沒有重大故障塔橡；
• 將版本提交給測試團隊后梅割，測試團隊就會先跑一下完整性測試，檢查一下有沒有重大的葛家，影響測試進程的bug户辞，如果有則退回開發(fā)
• 如果通過了完整性測試, 則進行冒煙測試，如果冒煙測試沒有通過也會立即打回開發(fā)癞谒。
• 順利通過完整性測試和冒煙測試之后才會進入正式測試階段底燎。

這么做的目的之一就是為了降低測試團隊的工作負擔刃榨，因為他們要對接多個開發(fā)團隊的測試任務。

37) 安全測試(Security Testing)

安全也是一個龐大的學科双仍，而且知識每天都在更新枢希，所以安全測試一般由特殊的安全團隊執(zhí)行，他們以各種黑客手段對系統(tǒng)進行滲透測試朱沃。

安全測試旨在確保應用或網(wǎng)站免受內(nèi)部和外部威脅的侵害苞轿。這個測試包括預防惡意程序、病毒逗物； 檢驗授權(quán)和身份驗證過程的安全性搬卒。

它還會檢查軟件對任何黑客攻擊和惡意程序的反應方式，以及在遭到黑客攻擊后如何維護軟件以保護數(shù)據(jù)安全

38) 冒煙測試(Smoke Testing)

冒煙測試翎卓，每當開發(fā)團隊提交新的構(gòu)建時契邀，軟件測試團隊就會先驗證構(gòu)建, 并確保不存在重大問題, 如果存在重大問題會直接打回開發(fā)團隊.

如何通俗地理解冒煙測試呢？這個屬于來源于硬件行業(yè)失暴，對一個硬件或硬件組件進行更改或修復后坯门，直接給設備加電。如果沒有冒煙锐帜，則該組件就通過了測試田盈。舉個例子，給三星Note7加電缴阎，如果沒爆炸允瞧，就說明通過了‘冒煙測試’(感覺當手機測試者不容易，容易有生命危險??)?

測試團隊在確保構(gòu)建穩(wěn)定后才會進一步執(zhí)行詳細的測試蛮拔。 冒煙檢查會檢查構(gòu)建中是否存在中斷缺陷(stopper defect, 即影響繼續(xù)測試的缺陷)述暂，這將阻止測試團隊進一步詳細測試。 即如果測試人員發(fā)現(xiàn)主要功能不能工作建炫，他們會拒絕這次構(gòu)建畦韭，并退回給開發(fā)團隊。

冒煙測試一般在回歸測試或其他詳細測試之前進行

39) 靜態(tài)測試(Static Testing)

靜態(tài)測試有點類似于代碼Review肛跌，在不執(zhí)行任何代碼的情況下執(zhí)行(也就是不運行應用)艺配，它涉及對可交付成果審查(inspection)、review和演練(walkthrough). 比如檢查代碼語法衍慎、命名約定转唉、項目組織。

靜態(tài)測試不僅適用于代碼, 也適用于測試用例稳捆、測試計劃和設計文檔. 如果在靜態(tài)測試階段發(fā)現(xiàn)缺陷赠法，可以將缺陷成本降到最低。比如在設計階段就發(fā)現(xiàn)問題乔夯，相比到開發(fā)階段甚至到生產(chǎn)環(huán)境出現(xiàn)問題要好解決

舉前端的例子砖织，靜態(tài)測試可能包括:

• 使用Lint工具對程序進行規(guī)范檢查款侵，相關(guān)的工具有ESLint、TSLint侧纯、Stylint等, 甚至Typescript這些類型檢查器也可以歸到這個范疇
• 代碼Review新锈。有一些問題是無法通過Lint工具覆蓋的，比如代碼邏輯茂蚓、異常捕獲壕鹉、項目組織、內(nèi)存泄露等等聋涨，這些需要人工進行走查Review
• 檢查代碼是否與設計一致晾浴，是否符合軟件需求、概要和詳細設計牍白，這不僅可以看出代碼問題脊凰，也可以反過來更早發(fā)現(xiàn)需求或設計是否正確。

40) 壓力測試(Stress Testing)

通過壓力測試茂腥，模擬系統(tǒng)受到超出其規(guī)格的壓力時失敗的方式和時間, 找出系統(tǒng)的崩潰點. 這個測試在高負載情況下執(zhí)行的狸涌，例如存取超過容量限制的數(shù)據(jù)、執(zhí)行復雜的數(shù)據(jù)庫查詢最岗、連續(xù)暴力輸入到系統(tǒng)或加載到數(shù)據(jù)庫帕胆。

41) 系統(tǒng)測試(System Testing)

系統(tǒng)測試在完整的集成系統(tǒng)上進行測試，也就是說系統(tǒng)測試一般在集成測試之后進行般渡，集成測試之后系統(tǒng)成為了一個整體懒豹，系統(tǒng)測試在這個基礎上、在真實的運行環(huán)境中驗證系統(tǒng)是否符合業(yè)務需求驯用。 這是一種黑盒型測試脸秽，基于總體需求規(guī)范，涵蓋系統(tǒng)的所有組合部分蝴乔。

系統(tǒng)測試其實不是一個具體的測試技術(shù)记餐，而是一個測試階段。 這個階段會進行很多種測試薇正，一般公司的測試團隊的工作就集中在這一塊片酝。 一般包含:

• 功能測試: 即上面講的，從系統(tǒng)的整體上測試是否符合業(yè)務需求
• 各種非功能測試：例如恢復測試挖腰、性能測試雕沿、壓力測試、安全測試等等曙聂。

歸納一下系統(tǒng)測試的目的:

• 確保應用作為一個整體可以良好地運行.
• 確保應用符合業(yè)務需求
• 確保應用在真實的環(huán)境可以良好地運行。比如進行一些非功能測試鞠鲜，驗證系統(tǒng)的健壯性

其實系統(tǒng)測試和上文說的端到端測試很像宁脊，它們要求系統(tǒng)作為一個整體進行測試断国。可以簡單展開對比一下

42) 單元測試(Unit Testing)

測試獨立的軟件單元或模塊稱為單元測試。它通常由開發(fā)者完成赊琳，而不是由測試人員完成街夭，因為它需要詳細了解內(nèi)部程序設計和代碼。

單元測試是和我們開發(fā)者最密切相關(guān)的測試類型躏筏。它的測試對象是軟件單元板丽。軟件單元可以是一個函數(shù)/方法、一個類或者一個GUI組件等趁尼。

這是一種白盒測試埃碱，所以要求由開發(fā)者自己進行，因為只有開發(fā)者才知道單元的內(nèi)部實現(xiàn)酥泞。單元測試一般會使用測試覆蓋率來驗證單元測試的完成度.

前端常見的單元測試工具有Jest砚殿、Mocha、Jasmine等等. 下面是典型的BDD風格的單元測試組織:

43) 可用性測試(Usability Testing)

可用性測試用于檢測應用的用戶友好程度(User-friendliness). 它會驗證新用戶受可以輕松理解應用流程芝囤，如果用戶陷入麻煩似炎，測試人員要記錄好并提供幫助》踩耍可以認為可用性測試是在檢查系統(tǒng)的導航性(navigation)名党。

44) 漏洞測試(Vulnerability Testing)

漏洞測試，涉及識別軟件挠轴、硬件和網(wǎng)絡中的漏洞传睹。如果漏洞容易受到攻擊，或者容易受到病毒和蠕蟲感染岸晦，黑客或惡意程序就可以控制系統(tǒng)欧啤。

因此有必要在投入生產(chǎn)環(huán)境之前檢查這些系統(tǒng)是否存在漏洞。

45) 容量測試(Volume Testing)

容量測試是由性能測試團隊執(zhí)行的一種非功能測試启上。容量測試會檢查應用程序遇到大量的數(shù)據(jù)時的系統(tǒng)行為和響應時間邢隧。這種大量數(shù)據(jù)可能會影響系統(tǒng)的性能和處理時間的速度。

46) 白盒測試(White Box Testing)

白盒測試, 它也被稱為玻璃盒測試冈在、結(jié)構(gòu)測試倒慧、邏輯驅(qū)動測試或基于代碼的測試, 基于應用程序代碼的內(nèi)部邏輯。即測試人員應該知道內(nèi)部軟件和代碼是如何工作的, 對所有的邏輯路徑進行覆蓋測試。上面提到的單元測試和靜態(tài)測試就是典型的白盒測試, 基本上白盒測試可以等價于單元測試纫谅。

邏輯路徑包括語句覆蓋炫贤、判定覆蓋、條件覆蓋付秕、判定/條件覆蓋兰珍、條件組合覆蓋和路徑覆蓋等等.

總結(jié)

上面提到的軟件測試類型只是測試中的一部分，實際有超過100種的測試類型询吴，但是并非所有測試類型都會被所有項目使用掠河，所以我這里只是列舉一些比較常見的軟件測試類型。

另外不同的組織中可能會有不同的定義或過程猛计，但是基本概念在任何地方都是相同的唠摹。當項目、需求和范圍發(fā)生變化時有滑，這些測試類型跃闹、過程及其實現(xiàn)方法會不斷演變。
以上內(nèi)容就是本篇的全部內(nèi)容以上內(nèi)容希望對你有幫助毛好，有被幫助到的朋友歡迎點贊望艺，評論。
如果對軟件測試肌访、接口測試找默、自動化測試、面試經(jīng)驗交流吼驶。感興趣可以關(guān)注小編惩激，會有同行一起技術(shù)交流哦。