測試類型

驗收測試

此類型的測試旨在確定功能或系統是否符合客戶的期望和需求。這種測試通常需要客戶的合作或回饋，是一種驗證活動，回答以下問題：

我們是否正在建構正確的產品？

對於 Web 應用程式，此測試的自動化可以直接使用 Selenium 模擬使用者預期的行為來完成。這種模擬可以透過錄製/回放或透過本文件中說明的不同支援語言來完成。注意：驗收測試是功能測試的一個子類型，有些人也可能這樣稱呼它。

功能測試

此類型的測試旨在確定功能或系統是否在沒有問題的情況下正常運作。它在不同層級檢查系統，以確保涵蓋所有情境，並且系統執行其應執行的功能。這是一種驗證活動，回答以下問題：

我們是否正確地建構產品？

這通常包括：測試運作時沒有錯誤（404、例外狀況…），以可用的方式（正確的重新導向），
以可存取的方式並符合其規格（請參閱上方的驗收測試）。

對於 Web 應用程式，此測試的自動化可以直接使用 Selenium 模擬預期的回傳值來完成。
這種模擬可以透過錄製/回放或透過本文件中說明的不同支援語言來完成。

整合測試

整合測試驗證系統不同組件或模組之間的互動。多個模組一起進行測試。整合測試的目的是確保所有模組整合在一起並如預期般運作。自動化整合測試有助於確保這些互動如預期般運作，並且整合的組件能夠一起正常運作。

例如，測試在電子商務網站中下訂單的流程，包括付款。

系統測試

系統測試是對完整整合產品的測試。這是一種端對端測試，其中測試環境與生產環境類似。在這裡，我們瀏覽軟體的所有功能，並測試最終的業務/最終功能是否運作。我們只測試最終功能，而不檢查資料流程或執行功能測試等等。

例如，測試從登入到下訂單，然後在「我的訂單」頁面中重新檢查訂單，最後從電子商務網站登出的端對端流程。

效能測試

顧名思義，效能測試旨在衡量應用程式的效能表現。

效能測試主要有兩個子類型

負載測試

負載測試旨在驗證應用程式在不同定義的負載下（通常是一次連接的特定使用者數量）的運作情況。

壓力測試

壓力測試旨在驗證應用程式在壓力下（或高於最大支援負載）的運作情況。

一般而言，效能測試是透過執行一些 Selenium 編寫的測試來完成的，這些測試模擬不同的使用者點擊 Web 應用程式上的特定功能並檢索一些有意義的度量。

這通常由其他工具完成，這些工具檢索指標。其中一個工具是 JMeter。

對於 Web 應用程式，要測量的詳細資訊包括輸送量、延遲、資料遺失、個別組件載入時間等。

注意 1：所有瀏覽器在其開發人員工具區段中都有一個效能標籤（可以透過按下 F12 存取）

注意 2：是非功能測試的子類型，因為這通常是按系統而不是按功能/特性來衡量的。

迴歸測試

此測試通常在變更、修復或新增功能後執行。

為了確保變更沒有破壞任何現有功能，會再次執行一些已執行的測試。

重新執行的測試集可以是完整的或部分的，並且可以包含幾種不同的類型，具體取決於應用程式和開發團隊。

測試驅動開發 (TDD)

TDD 不是一種本身的測試類型，而是一種迭代開發方法，其中測試驅動功能的設計。

每個週期都從建立一組單元測試開始，這些測試是功能最終應該通過的（它們在第一次執行時應該失敗）。

在此之後，進行開發以使測試通過。再次執行測試，開始另一個週期，並且此過程持續進行，直到所有測試都通過。

這旨在根據缺陷發現得越早成本越低的原則，加速應用程式的開發。

行為驅動開發 (BDD)

BDD 也是一種基於上述 TDD 的迭代開發方法，其目標是讓所有參與者參與應用程式的開發。

每個週期都從建立一些規格（應該失敗）開始。然後建立失敗的單元測試（也應該失敗），然後進行開發。

重複此週期，直到所有類型的測試都通過。

為了做到這一點，使用了規格語言。它應該是所有參與者都能理解的，並且簡單、標準和明確。大多數工具使用 Gherkin 作為這種語言。

目標是透過針對潛在的驗收錯誤，並使各方之間的溝通更順暢，從而檢測到比 TDD 更多的錯誤。

目前有一組工具可用於編寫規格並將其與程式碼功能匹配，例如 Cucumber 或 SpecFlow。

一組工具建立在 Selenium 之上，透過將 BDD 規格直接轉換為可執行程式碼，使此過程更加快速。其中一些工具是 JBehave、Capybara 和 Robot Framework。