軟體測試主要種類大全

測試的主題是廣泛的。從外面看起來可能很簡單，但事實並非如此。例如，人們可以將測試定義為檢查軟體是否適合其目的。

1. 單元測試

單元測試是一門有據可查的學科：無論使用哪種語言，都已經出版了大量關於該主題的書籍。他們通常重複相同的事情。

[… ] 單元測試是一種軟體測試方法，通過該方法測試各個原始碼單元 [… ] 以確定它們是否適合使用。

—維基百科

唯一有爭議的點是什麼構成了一個單元：在OOP 中，有些人認為它是類；其他人認為它是一個模組， 即一組協作類。

2. 整合測試

雖然單元測試的定義和理解相當好，但相比之下，整合測試似乎是處女地。

整合測試 [… ] 是軟體測試的階段，在該階段中，各個軟體模組被組合在一起並作為一個組進行測試。

—維基百科

整合測試背後的核心概念之一是被測系統。在單元測試中，SUT是單元（即類或模組，如上所述）。在整合測試中，需要為每個測試定義 SUT：它可以小到兩個協作的單元，大到整個系統。

關於單元測試與整合測試存在激烈的爭論。有的只考慮前者，有的只考慮後者。

3. 端到端測試

在大多數應用程式都是人對機器的時候，端到端測試意味著測試從使用者介面到資料庫的流程，然後再返回。由於 Web 應用程式幾乎無處不在，這涉及到瀏覽器。因此，E2E測試與之前的方法有很大不同。自動化使用者與瀏覽器的互動並非易事，即使可用工具隨著時間的推移而改進。

E2E 測試中最大的問題來自UI層的脆弱性。現代架構清晰地分為基於 JavaScript 的前端和REST後端。為了應對提到的脆弱性，它有助於首先通過整合測試測試REST 層。

使用E2E 測試，有一個從單元測試到整合測試的完整連續體。

4.系統測試

隨著時間的推移，越來越多的應用程式針對機器對機器互動而不是H2M互動。端到端測試之於 H2M 就像系統測試之於M2M。

好處是不涉及瀏覽器。因此，可以重用來自單元測試和整合測試的相同自動化技術。

5. 效能測試

以前的大多數方法都側重於測試功能需求。很容易忘記軟體元件的適用性包括功能需求和非功能需求。效能作為NFR 的一部分，以及可靠性等。

請注意，效能測試中的SUT可以是整個系統，也可以只是被視為關鍵的子元件。然而，在這種情況下，斷言每個單獨元件的效能可能不足以保證整個系統的效能。

[… ] 效能測試通常是一種測試實踐，用於確定系統在特定工作負載下的響應能力和穩定性方面的表現。

—維基百科

根據我的經驗，術語效能測試被過度使用，而且過於籠統。它有很多方面：這裡是最常見的方面。

6.  負載測試

負載測試通常是人們談論效能測試時隱含的意思。在這種情況下，可以為測試設定不同的引數。這些引數模擬來自生產環境的代表性負載。在現實中，大多陣列織無法提供生產負載的質量樣本，而負載是推斷出來的。

例如，在電子商務環境中，測試引數將包括：

• 不同型別的請求：瀏覽目錄、檢視不同的產品、將它們新增到購物車、結賬、付款等。
• 它們之間的重新分配，例如70% 的瀏覽、20% 的檢視、6% 的購物車操作、3% 的結帳和 1% 的付款
• 併發請求數
• 併發使用者會話的數量，以及它們如何在請求之間分佈
• 等等。

7. 耐力測試

在常規負載測試中，測試執行直到它們完成執行。目標是檢查系統在特定負載下的行為是否符合人們的預期。

在耐久性測試也被稱為浸泡測試，目的是檢查有系統的行為演變隨著時間的。相比之下，這些測試的持續時間更多是幾天，甚至幾周。

耐力測試涉及在連續可用性期間測試具有典型生產負載的系統，以驗證生產使用下的系統行為。

—維基百科

8. 壓力測試

壓力測試是對系統進行測試，直到它崩潰。負荷逐漸增加。壓力測試的目標是瞭解系統的效能限制。

壓力測試（有時稱為酷刑測試）是一種有意進行的密集或徹底測試，用於確定給定系統、關鍵基礎設施或實體的穩定性。它涉及超出正常操作能力的測試，通常會達到一個臨界點，以觀察結果。

—維基百科

此類實驗的結論是：在x請求負載/秒內，一y小部分請求返回5xx錯誤程式碼。

9. 混沌測試

混沌測試，也稱為混沌工程，是一種隨機移除系統元件以瞭解其崩潰方式並檢查其在脅迫下的整體彈性的實踐。

混沌工程是在生產中對軟體系統進行試驗的學科，目的是建立對系統承受動盪和意外情況的能力的信心。

—維基百科

混沌測試的定義屬性是它通常在生產環境中執行。這並不意味著在其他環境中進行的實驗不能帶來可操作的反饋，恰恰相反。但是，每個人都在生產中遇到過以前環境中從未發生過的問題。根本原因可能是架構略有不同、資料資料不同、負載更高等：最終，唯一需要經過實戰測試和防彈的環境是生產環境。

雖然起初違反直覺，但這個想法現在已經在成熟的組織中根深蒂固，這些組織非常重視系統的彈性。

10. 安全測試

就像效能測試是一個過於寬泛的術語一樣，安全測試涵蓋了許多不同的領域。最著名的安全測試形式是滲透測試。

滲透測試 [...] 是對計算機系統進行的授權模擬網路攻擊，用於評估系統的安全性。

執行測試是為了識別兩個弱點 [...]，包括未經授權方訪問系統功能和資料的可能性，以及優勢，從而能夠完成完整的風險評估。

—維基百科

11.突變變異測試

大多數形式的測試側重於軟體部分或整個系統的適用性。Mutation Testing的獨特之處在於它的目標是對單元測試進行後見之明，更具體地說是在誤導性程式碼覆蓋率指標上。

變異測試 [… ] 用於設計新的軟體測試和評估現有軟體測試的質量。

—維基百科

12. 探索性測試

許多測試方法側重於迴歸錯誤，即出現在以前工作的軟體中的錯誤。為此，測試是自動化的：它們在每次構建時執行。如果之前執行的測試失敗，構建也會失敗。

探索性測試的目標是捕捉測試工具無法觸及的錯誤。為了實現這一點，人們以新的和意想不到的方式與系統互動。

探索性測試是一種軟體測試方法，簡明地描述為同步學習、測試設計和測試執行。

—維基百科

由於其探索性，此過程是手動的。我的經驗告訴我，探索性測試被低估了。很遺憾，因為我親眼目睹了測試人員在系統中發現了以前自動化步驟沒有發現的問題。

儘管具有手動性質，探索性測試並不是要到處點選。這是一種工程實踐，需要紀律和嚴格的方法來記錄導致問題的步驟。最好的測試人員還能夠：

• 隔離問題
• 重現導致它的步驟
• 以一種可以減輕需要修復錯誤的開發人員的工作的方式來建立問題

13. 使用者驗收測試

大多數形式的測試由技術人員執行：開發人員、自動化測試人員等。相反，驗收測試由非技術人員執行，例如業務分析師或終端使用者。顧名思義，目標是評估他們是否接受適合其使用的軟體。

使用者驗收測試包括驗證解決方案是否適合使用者的過程。

—維基百科