為不同類型的測試指定的名稱在各程式碼集中通常具有共通主題，但並沒有特別嚴謹的定義。本課程針對每種測試類型提供一些指引，但其他資源可能會提供不同的定義。
在先前的頁面提供「單元測試」和「元件測試」的範例 (在我們的範例中參照 React 元件)。我們可以同時將兩者放在測試金字塔 (或其他形狀！) 上，因為其複雜度較低且執行速度快，但實用性可能不如更複雜的整合測試。
常見測試類型
單元測試
單元測試是範圍內的最小。通常用於測試程式碼的小部分，或純無狀態的程式碼，對於幾乎是數學方式：如果我提供輸入 X、Y 和 Z 的程式碼，則輸出內容應為 A、B 和 C。
包含單元測試的程式碼通常不會有外部依附元件，例如從網路擷取，或以隱含方式使用任何其他函式或程式庫。就像程式碼的樹狀結構節點，可以自行「切除」和測試。
雖然單元測試的撰寫和執行速度通常很快，但還是有可能只測試少量程式碼，無法獲得實用資訊。通常，如果程式碼單元沒有與其他程式碼互動，您最好不要在更高層級進行測試來降低風險。
元件測試
對網頁開發人員來說，「元件」名稱會超載，這通常代表使用者可以看到的元件，例如 React 元件或網頁元件。其一般定義是可測試的工作區塊，例如具有外部依附元件的類別。如要有效測試，這個元件的依附元件必須模擬或略過。
由於現代網頁開發做法是以元件的概念為基礎，因此元件測試是考量測試的實用做法：例如，您可能會決定每個元件都需要測試。如果單一開發人員或小型團隊對某個元件聲明擁有權，元件測試也很容易追蹤。不過，要模擬複雜的依附元件可能並不容易。
整合測試
通常會對一小群的元件、模組、子系統或程式碼的其他重要部分進行測試，確保其可正常運作。這個定義非常模糊對網頁開發人員來說，想像一下您要測試的程式碼，不是網站的實際實際工作環境 (或相近)，但仍會連結系統的各種相關元件。
這甚至可能包含「實際」依附元件，例如測試模式的外部資料庫，而非純模擬。例如，與其說 query() 一律會傳回相同的兩個項目，整合測試可以確認測試資料庫裡是否包含「東西」。資料本身較不重要，但您現在正在測試資料庫可以連線並成功進行查詢。
您可以編寫相對簡單的整合測試，並在其中運用斷言進行檢查，因為單一動作連結到不同元件，可能會造成一系列可衡量的效果。因此，整合測試可以有效證明複雜系統將依照預期的方式執行。不過，可能會難以撰寫及維護
而且可能帶來許多不需要的複雜性舉例來說，為整合測試編寫 FakeUserService，會新增其和 RealUserService 必須實作 UserService 的要求。
煙霧測試
這些測試應很快完成，並判斷程式碼集是否處於合理狀態。實務上，這主要是指對能大幅影響體驗的程式碼執行簡單的測試。
舉例來說，在大型登入的網頁應用程式中，這可能可確保登入和驗證系統正常運作，因為如果沒有應用程式，就無法使用，相關測試則不相關。
在大型程式碼集中，使用 package.json 的 test 指令碼執行煙霧測試。手動測試也可視為煙霧測試。
迴歸測試
迴歸測試是一種煙霧測試，可確保現有功能在新版本或其他功能開發完成後仍可持續運作，或是不會重新導入舊錯誤。
這與測試導向開發 (TDD) 的概念有關。為明確觸發錯誤而撰寫的測試案例，在之後用於確保錯誤已修正，則算為迴歸測試案例，因為這類測試的存在應可避免相同錯誤傳回。
不過，迴歸測試可能是個問題，但沒有優異的解決方案。這一術語經常是業務需求引用：在功能開發期間，舊功能必須要能保持完整不變。經完善測試的程式碼集應足以維護這一點，但真正的程式碼集不一定永遠達到理想狀態。我們會在後續章節中進一步說明。
視覺測試
視覺測試涉及擷取網站狀態的螢幕截圖或影片，以便與目前的測試執行作業檢查已知的良好狀態 (例如先前的螢幕截圖)。瀏覽器本質上需要運作才能運作，才能轉譯 HTML、CSS 和網站的其他部分，
與其透過視覺方式測試執行整個程式碼集的端對端測試，建議您建構僅轉譯特定元件 (尤其是在不同螢幕大小) 中，觸發回應式 UI 的「善用」HTML。這比單純使用 JSDOM 或類似架構更加複雜。
影像測試失敗可能是其他類型的毀損信號。不過，複雜的 UI 可能會因為與您嘗試測試的功能無關的原因而無法進行視覺測試，例如其他新功能會變更 UI 外觀，或甚至是新的 OS 版本轉譯表情符號，與舊版不同。
端對端測試
端對端測試通常位於測試金字塔的頂端。它們描述了與您的網頁應用程式/網站整體體驗 (可能以特定功能為中心) 的整個體驗，通常會在由 WebdriverIO、Selenium 或 Puppeteer 等代理程式控制的瀏覽器中執行，這可以如同在實際工作環境中部署程式碼集 (儘管通常是在本機主機上運作)。
視您的網站而定，這可能包括以測試使用者身分登入、執行多項重要動作，並確認網站或系統處於正確的狀態。我們將在接下來的章節中說明更多這類測試的範例，因為這項功能可能非常強大，但有時很難維護。
有些簡化的策略包括縮小範圍，或模擬相關的特定元件。舉例來說，如果使用者需要登入網站，但登入並非您測試的功能，建議您為測試環境設定標記，讓測試控制器不必登入或建立相關 Cookie，就能以使用者身分執行動作。
雖然端對端測試是非常強大的方法，可以一次針對程式碼集的廣大跨區段進行測試，但大規模測試可能會因為外部系統依賴而變得不穩定或不穩定。舉例來說，如果每次測試會建立或修改項目，則它們通常也會在資料庫中留下大量測試資料。累計像這樣的剩餘資料可能會導致很難判斷測試失敗的方式。
API 測試
API 測試可確認您的軟體提供的 API 行為，或存取實際 (可能是運作中的) API 來確認其行為。無論如何，這往往都會測試系統之間的「抽象」(即最終如何互相通訊)，而不必實際在「整合測試」中整合這些抽象層級。
這些測試可以針對整合測試提供基本的前置作業，而不需要預先執行要測試連線的系統。然而，實地系統的測試有時並不容易。
其他類型
視來源而定，還有各種不同的測試方法可能很實用。以下列舉幾個值得參考的範例：
- 手動測試。
- 接受測試 (Agile 方法常見的手動測試) 可以確認產品「符合使用者需求」。
- 混沌測試是指會輸入隨機資料來瞭解發生的情況，確保網站不會在輸入錯誤資料後當機。
- 故障測試會刻意模擬複雜系統 (例如網路故障) 中的失敗情形，確保測試用的程式碼能以受控的方式回應。
- 建構測試會檢查程式碼集的存在或內容，以確認程式碼集的建構構件可產生。這個測試類型非常適合用來檢查複雜 CMS 的輸出內容。
程式碼涵蓋率
您可以評估經過自動化測試測試的程式碼百分比，並隨著時間的統計資料，將其回報為統計資料。我們不建議將目標放在 100% 的程式碼涵蓋率，因為這可能會導致不必要的負擔，以及不涵蓋主要用途的簡化或設計不良的測試。
涵蓋率本身也在編寫或測試時也是有用的工具，特別是整合測試。顯示百分比或逐行細目，列出單次測試測試的程式碼，讓您深入瞭解缺少的項目或接下來可以測試的項目。
資源
隨堂測驗
下列哪些是已知的測試？