自動化測試類型

為不同類型的測試指定的名稱在各程式碼集中通常具有共通主題,但並沒有特別嚴謹的定義。本課程針對每種測試類型提供一些指引,但其他資源可能會提供不同的定義。

在先前的頁面提供「單元測試」和「元件測試」的範例 (在我們的範例中參照 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% 的程式碼涵蓋率,因為這可能會導致不必要的負擔,以及不涵蓋主要用途的簡化或設計不良的測試。

涵蓋率本身也在編寫或測試時也是有用的工具,特別是整合測試。顯示百分比或逐行細目,列出單次測試測試的程式碼,讓您深入瞭解缺少的項目或接下來可以測試的項目。

資源

隨堂測驗

下列哪些是已知的測試?

壓力測試
火災測試
視覺測試
差異化測試
混亂測試