文章篇幅較長,閱讀完大概20min,建議收藏閱讀, 讀完會有收穫。歡迎點贊關註 原文鏈接:https://www.softwaretestinghelp.com/types-of-software-testing/ 有多少軟體測試類型呢? 我們作為測試人員瞭解很多種不同的軟體測試類型,例如功能測試( ...
文章篇幅較長,閱讀完大概20min,建議收藏閱讀, 讀完會有收穫。歡迎點贊關註
原文鏈接:https://www.softwaretestinghelp.com/types-of-software-testing/
有多少軟體測試類型呢?
我們作為測試人員瞭解很多種不同的軟體測試類型,例如功能測試(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)
來看看這些測試類型的細節
顧名思義, A/B測試就是準備兩個(A/B)或兩個以上的版本,讓不同的用戶來隨機訪問這些版本,收集各群組的用戶體驗數據和業務數據,最後分析、評估出最好版本,正式採用。如上圖,谷歌使用A/B測試來決定導航應該是紅色還是藍色。
- 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的發佈計劃:
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) # -> 九月初,該發最終Beta版本了,相當於進入RC階段了
Mid-September 2019: iOS 13 likely to launch with new 2019 iPhones # -> 正式版本
現在很多開源項目,已經淡化了瀑布式的軟體版本周期,變成一種持續(Continuous)的、常態化的行為, 例如Firefox:
2) 驗收測試(Acceptance Testing)
驗收測試通常是部署軟體之前的最後一個測試操作, 也稱為交付測試, 由最終客戶執行,他們會驗證端到端(end to end)的系統流程是否符合業務需求,以及功能是否是滿足最終用戶的需求。只有當所有的特性和功能按照期望的運行,客戶才會接受軟體
這是測試的最後階段,在驗收測試之後,軟體將投入生產環境. 所以它也叫用戶驗收測試(UAT)
舉個例子,驗收測試就相當於收快遞, 包裹是軟體、你就是客戶,是驗收方,如果貨物不符合你的要求,是要退貨的。
-
臨時測試(Ad-hoc Testing)
Ad-hoc中文應該理解為臨時的意思。顧名思義,這種測試是在臨時基礎上進行的, 有時候也稱為隨機測試。即沒有參考測試用例、沒有針對該測試的任何計劃和文檔。Ad-hoc測試的目的就是通過執行隨意的流程或任意的功能來找出應用的缺陷和問題
Ad-hoc測試一種非正式的方法,可以由項目中的任何人執行。儘管沒有測試用例很難識別缺陷,但是有些時候在Ad-hoc測試期間發現的缺陷可能無法使用現有的測試用例來識別, 也就是說它一般用來發現‘意外’的缺陷. -
可訪問性測試(Accessibility Testing)
可訪問性測試的目的是確定軟體或應用程式是否可供殘疾人使用。殘疾是指聾人,色盲,智障人士,失明者,老年人和其他殘疾人群體。這裡會執行各種檢查,例如針對視覺殘疾的字體大小測試,針對色盲的顏色和對比度測試等等。
不同平臺、不同應用類型對可訪問性支持情況不太一樣,比如iOS相比其他操作系統則更重視可訪問, 而國外比國內更重視可訪問性。
5) Beta測試(Beta Testing)
上文Alpha測試已經提及Beta測試, Beta測試是一種正式的軟體測試類型,在將產品發佈到市場或者實際最終用戶之前,由客戶在真實的應用環境中執行。
執行Beta測試目的是確保軟體或產品中沒有重大故障,並且滿足最終用戶的業務需求。當客戶接受軟體時,Beta測試才算通過。
通常,此類測試由最終用戶或其他人完成。這是在將應用發佈作為商業用途之前完成的最終測試。通常,發佈的軟體或產品的Beta版本僅限於特定區域中的特定數量的用戶。
所以最終用戶實際使用軟體後會將一些問題反饋給公司。公司可以在全面發佈之前採取必要的措施。
Beta測試在正式版本之前也可能會迭代進行多次.
-
後端測試(Back-end Testing)
前端應用輸入的數據,一般都會存儲在資料庫,所以針對資料庫的這類測試稱為資料庫測試或者後端測試. 市面有不同的資料庫,如SQL Server,MySQL和Oracle等。資料庫測試會涉及表結構,模式,存儲過程,數據結構等。
後端測試一般不會涉及GUI,測試人員通過某些手段直接連接到資料庫,從而可以容易地運行一些資料庫請求來驗證數據。通過後端測試可以發現一些資料庫問題,比如數據丟失、死鎖、數據損壞。這些問題在系統投入生產環境之前進行修複至關重要 -
瀏覽器相容測試(Browser Compatibility Testing)
這是相容性測試的子類型,由測試團隊執行. 瀏覽器相容測試主要針對Web應用,用於確保軟體可以在不同瀏覽器或操作系統中運行; 或者驗證Web應用程式是否支持在瀏覽器的所有版本上運行, 以確定應用最終相容的範圍.
瀏覽器相容測試是前端開發者繞不開的坑。
我們有很多策略來應對瀏覽器相容性,比如漸進增強或者優雅降級, 還有制定瀏覽器相容規範;
為了撫平瀏覽器之間的差異,我們會使用各種特性檢測工具(Modernizr), 還有各種polyfill(CSS Normaliz, polyfill/shim, css-autoprefixer);
當然為了測試跨瀏覽器相容性,還要一些輔助工具,例如BrowserStack, 對於我們這些小團隊,只能下一堆Portable(Portable瀏覽器運行時相互隔離的, 所以不會存在配置文件等衝突問題) 瀏覽器,手工測試了。
-
後向相容測試(Backward Compatibility Testing)
向後相容測試, 用於驗證新開發或更新的軟體是否能在舊版本的環境中運行。
比如向後相容測試會檢查新版軟體是否可以正確地處理舊版本軟體創建的文件格式。例如新版的Office 2016是否可以打開2012創建的文件。
同理也可以檢查新版本是否可以相容舊版本軟體創建的數據表、數據文件、數據結構、配置文件。
任何軟體更新應該在先前版本的基礎之上良好地運行 -
黑盒測試(Black Box Testing)
黑盒測試不考慮軟體的內部系統設計,它基於需求和功能進行測試, 只關心系統的輸入/輸出以及功能流程。
換句話說黑盒測試從用戶的角度出髮針對軟體界面、功能及外部結構進行測試,而不考慮程式內部邏輯結構.
黑盒測試下麵有很多子類,例如集成測試、系統測試、大部分非功能性測試
-
邊界值測試(Boundary Value Testing)
邊界值測試, 測試應用處於邊界條件(boundary level)的行為。很多邊界條件開發者是很難考慮周到的,所以才有一個專門的測試類型來驗證這種情況
邊界值測試檢查應用處於邊界值時是否存在缺陷。邊界值測試通常用於測試不同範圍的數字, 每個範圍都有一個上下邊界,邊界測試則是針對這些邊界值進行測試。
比如數字範圍為1-500, 那麼邊界值測試會在這些值上進行驗證: 0、1、2、499、500、501 -
分支測試(Branch Testing)
這是白盒測試的子類型,在單元測試中實施. 顧名思義,分支測試表示測試要覆蓋程式代碼的各種條件分支, 避免遺漏缺陷。分支覆蓋是單元測試覆蓋率的一個指標之一 -
比較測試(Comparison Testing)
比較測試,將產品的優點和弱點與舊版本或者同類(競品)產品進行比較.
比如類似王自如這種數位測評欄目,評測一個手機或者其他數位產品時,一般會橫向和友商產品進行比較,有時候也會縱向和上一代產品比較.
還有一種比較典型的例子就是和行業的領導者比較,比如我們做IM的,會經常和微信比較: ‘你這個應用的啟動速度怎麼比微信慢這麼多?’
-
相容性測試(Compatibility Testing)
這是一個大類, 相容性測試用於驗證應用在不同環境、web伺服器、硬體、網路條件下的行為。相容性測試確保軟體可以在不同的配置、不同的資料庫、不同的瀏覽器,以及它們不同的版本下運行。相容性測試由測試團隊實施 -
組件測試(Component Testing)
組件測試(此組件非GUI組件, 取組合測試可能更好理解一點),一般也稱為模塊測試(Module Testing), 一般由開發者在完成單元測試後執行。組件測試將多個功能組合起來作為單一的整體進行測試,目的是發現多個功能在相互連接起來之後的缺陷。
組件測試可大可小,小到函數級別或者類級別的組合,大可以大到幾個單獨的頁面、模塊、子系統的組合。 舉一個前端例子,將多個頁面路由組合起來,測試它們的流程跳轉,就屬於組件測試。 -
端到端測試(End-to-End Testing)
端到端測試也是一種黑盒測試類型,類似於系統測試. 端到端測試在模擬的、完整的、真實應用環境下模擬真實用戶對應用進行測試,比如應用會和資料庫交互、會使用網路通信、或者在適當的情況下和其他硬體、應用、系統進行交互. 端到端是指從一個端點到另一個端點的意思,所以端到端測試重點用於測試模塊和模塊之間的協調性。
當應用是分散式系統或者需要和其他外部系統協同時,端到端測試扮演著非常重要的角色, 它可以全面檢查以確保軟體在不同平臺和環境產品能準確地交互。端到端測試有以下目的:
確保應用可以和外部系統之間良好的協調。對於前端來說,是確保頁面和後端之間良好協調
檢查從源系統到目標系統的所有系統流
從最終用戶角度驗證需求
識別異構環境中的問題
前端也有很多自動化的端到端測試工具,比如nightwatch,通過它們可以模擬用戶對頁面進行操作,從而檢驗整個應用流程是否正常和符合需求:
因為和系統測試很相似,所以它們也被經常拿來比較
- 等價劃分(Equivalence Partitioning)
等價劃分, 這是一種黑盒測試的測試技術. 通過等價劃分,可以將所有的輸入數據合理地劃分為多個分組,我們只需在每個分組中取一個數據作為測試的輸入條件, 這樣可以實現用少量代表性的測試數據取得較好的測試結果.
所以說這個測試的目的: 是在不導致缺陷的前提下,移除指定分組中的重覆的用例, 簡化測試的工作
比如一個程式應用接受-10到+10之間的值,使用等價分區方法可以劃分為三個分組: 0、負值、正值. 接下來的測試只需從這個三個分組中取一個成員進行測試, 而不需要-10到+10每個成員都測試一遍.
- 實例測試(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.
實例測試意味著實時測試。實例測試包含了實時場景、另外還涉及基於測試人員經驗的場景。