什麼是測試

編寫軟體時,您可以透過測試確認軟體是否正常運作。 測試可廣泛定義為執行軟體的特定程序 確保應用程式可正常運作

測試成功後,您在加入新程式碼、功能或 甚至升級依附元件 確保運作方式符合預期進行測試也有助於保護 避免產生意外或非預期的輸入內容

針對網路上一些行為,建議您進行測試,包括:

  • 確保點選按鈕時網站功能可正常運作。
  • 確認複雜函式會產生正確的結果。
  • 完成需要使用者登入的動作。
  • 檢查表單輸入的資料格式有誤時,是否能正確回報錯誤。
  • 即便使用者有極大量的工作,仍可確保複雜的網頁應用程式仍可持續運作 頻寬不足或離線時也不成問題

自動和手動測試

一般測試軟體的方法有兩種:自動測試和手動測試 進行測試。

手動測試涉及人類直接執行軟體,例如載入 網站,確認運作正常。手動 建立或定義測試? 例如,是否可以載入網站?可以 執行這些動作?但每次執行後都會花費極高的 人類的時間雖然人類很有創意,但可以進行一種 也稱為探索性測試,我們可能還是無法掌握錯誤, 不一致的情況,尤其是在重複相同工作時。

自動化測試是指任何能讓測試編寫和執行的程序 電腦不斷重複確認軟體的預期行為, 要求真人執行任何重複步驟,例如設定或檢查結果。 重要的是,一旦設定自動化測試,就能頻繁執行。 這仍然是非常廣泛的定義 值得注意的是 測試會以各種形狀和形式進行。本課程大部分的問題 以自動化測試為基礎

手動測試可以確定,通常具備編寫自動化動作的前置作業 但若自動化測試變得不穩定、涵蓋範圍廣泛 或沒有手忙於寫

透過範例說明基本概念

對於網站開發人員來說,撰寫 JavaScript 或相關語言時, 自動化測試也可以是像每天執行一樣的指令碼 或在瀏覽器中載入程式碼:

import { fibonacci } from "../src/math.js";

if (fibonacci(0) !== 0) {
  throw new Error("Invalid 0th fibonacci result");
}
const fib13 = fibonacci(13);
if (fib13 !== 233) {
  throw new Error("Invalid 13th fibonacci result, was=${fib13} wanted=233");
}

這是提供以下洞察的簡化範例:

  • 這是一項「測試」,因為它可以執行部分軟體 (Fibonacci 函式),並確保其 運作原理是依照預期的方式運作 預期值如果行為不正確,就會發生錯誤。 JavaScript 表示會擲回 Error

  • 即使您是在終端機中手動執行這個指令碼 這項測試仍是自動化測試,因為此測試可重複執行 不必執行任何個別步驟下一頁 (其中 詳細說明。

  • 即使這項測試並未使用任何程式庫,而是可以 而且仍只是測試市面上有許多工具 編寫測試,包括本課程稍後會介紹的測試 但只要確保造成錯誤的原因 發生錯誤

實際測試程式庫

大部分的程式庫或內建測試架構都提供符合 可讓您更輕鬆地編寫測試:宣告,以及定義獨立測試的方法。 我們將在下一節宣言和 其他基元但大致來說 請特別注意,畫面顯示或編寫的絕大多數測試 運用這些基元

斷言是一種結合檢查結果的方式,如果發生下列情況,就會造成錯誤 發生錯誤例如,您可以讓先前的測試更加精簡 ,我們要導入 assert

import { fibonacci } from "../src/math.js";
import { assert } from "a-made-up-testing-library";

assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");

您可以視需求定義獨立測試,進一步改善這項測試。 依套件分組。下列套件獨立測試費波那契數 函式與 Catalan 函式

import { fibonacci, catalan } from "../src/math.js";
import { assert, test, suite } from "a-made-up-testing-library";

suite("math tests", () => {
  test("fibonacci function", () => {
    assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
    assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");
  });
  test("relationship between sequences", () => {
    const numberToCheck = 4;
    const fib = fibonacci(numberToCheck);
    const cat = catalan(numberToCheck);
    assert.isAbove(fib, cat);
  });
});

在軟體測試中,「測試」是指「測試案例」的名詞: 單一、獨立、可定址的情境,例如 序列用於先前範例的測試案例

個別命名的測試適合用於下列工作及下列工作:

  • 長期判斷測試的成功或失敗情形。
  • 依名稱標明錯誤或情況,以便更輕鬆地測試 解決問題
  • 獨立執行部分測試,例如透過 glob 篩選器。

其中一個測試案例的方法之一是使用「三個 A」單元測試: 編排、行動和斷言每個測試案例的核心將:

  • 排列部分值或狀態 (可能只是硬式編碼的輸入資料)。
  • 執行動作,例如呼叫方法。
  • 使用 assert 斷言輸出值或更新狀態。

測試規模

前一節的程式碼範例說明瞭單元測試,因為 測試軟體的小部分,通常只著重單一檔案 只會擷取來自單一函式的輸出結果。隨著您逐步增加測試的複雜度 可以考慮從多個檔案、元件 甚至不同相互連結之間取得的程式碼 系統 (有時是受到您控管的,例如網路服務或 外部依附元件的行為)。因此,測試類型通常已命名為 設定依據範圍規模

除了單元測試,還有一些其他測試類型包括元件 測試視覺測試整合測試。不包含這些名稱 意思是說,可能因為 所以請記得以這些程式碼庫做為參考,並找出 舉例來說,系統中測試的元件是什麼?適用對象 是反應開發人員,這個項目有可能對應至「React 元件」,但可能會 在其他情況下對開發人員有不同的意義

個別測驗的規模,可以將模型放在通常探討的 做為測試用的「測試金字塔」原則 包括檢查和執行方式

測試金字塔
    在頂端進行端對端 (E2E) 測試,中間的整合測試
    單元測試
測試金字塔。

我們重複了這個想法,現在也應用了其他各種形狀 熱門,例如測試鑽石或 來測試甜筒您的測試/業務 程式碼集不過,常見的功能是較簡單的測試,例如單元測試。 通常執行速度更快、編寫起來也更簡單 (所以您需要更多), 測試有限範圍,而端對端測試等複雜的測試則會比較 但可以測試更廣的範圍事實上,模型的頂層 測試「形狀」因為某些使用者互動 過於複雜,無法編寫成自動測試

這些類型日後將透過「自動化」類型的 測試

隨堂測驗

大多數測試程式庫和架構提供了哪些基本項目?

使用雲端服務供應商的執行器服務。
某些瀏覽器型執行器可讓您將測試外包,但 這不是測試程式庫的正常功能
導致不符合例外狀況的斷言。
雖然您可以擲回錯誤來讓測試失敗,assert() 而且其變化版本往往也包含在內,因為這樣比較方便檢查 以便寫入。
將測試分類為測試金字塔的方法。
這其實沒有標準做法。您可以在 或把測試放在不同的檔案中 大部分的測試架構其實並未內建分類功能。
能夠使用函式定義獨立測試。
幾乎所有測試都包含 test() 方法 跑者由於測試程式碼無法在頂層執行,因此請務必留意這一點 檔案,讓測試執行器將每個測試案例視為 獨立單位