編寫軟體時,您可以透過測試確認軟體是否正常運作。 測試可廣泛定義為執行軟體的特定程序 確保應用程式可正常運作
測試成功後,您在加入新程式碼、功能或 甚至升級依附元件 確保運作方式符合預期進行測試也有助於保護 避免產生意外或非預期的輸入內容
針對網路上一些行為,建議您進行測試,包括:
- 確保點選按鈕時網站功能可正常運作。
- 確認複雜函式會產生正確的結果。
- 完成需要使用者登入的動作。
- 檢查表單輸入的資料格式有誤時,是否能正確回報錯誤。
- 即便使用者有極大量的工作,仍可確保複雜的網頁應用程式仍可持續運作 頻寬不足或離線時也不成問題
自動和手動測試
一般測試軟體的方法有兩種:自動測試和手動測試 進行測試。
手動測試涉及人類直接執行軟體,例如載入 網站,確認運作正常。手動 建立或定義測試? 例如,是否可以載入網站?可以 執行這些動作?但每次執行後都會花費極高的 人類的時間雖然人類很有創意,但可以進行一種 也稱為探索性測試,我們可能還是無法掌握錯誤, 不一致的情況,尤其是在重複相同工作時。
自動化測試是指任何能讓測試編寫和執行的程序 電腦不斷重複確認軟體的預期行為, 要求真人執行任何重複步驟,例如設定或檢查結果。 重要的是,一旦設定自動化測試,就能頻繁執行。 這仍然是非常廣泛的定義 值得注意的是 測試會以各種形狀和形式進行。本課程大部分的問題 以自動化測試為基礎
手動測試可以確定,通常具備編寫自動化動作的前置作業 但若自動化測試變得不穩定、涵蓋範圍廣泛 或沒有手忙於寫
透過範例說明基本概念
對於網站開發人員來說,撰寫 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 元件」,但可能會 在其他情況下對開發人員有不同的意義
個別測驗的規模,可以將模型放在通常探討的 做為測試用的「測試金字塔」原則 包括檢查和執行方式
我們重複了這個想法,現在也應用了其他各種形狀 熱門,例如測試鑽石或 來測試甜筒您的測試/業務 程式碼集不過,常見的功能是較簡單的測試,例如單元測試。 通常執行速度更快、編寫起來也更簡單 (所以您需要更多), 測試有限範圍,而端對端測試等複雜的測試則會比較 但可以測試更廣的範圍事實上,模型的頂層 測試「形狀」因為某些使用者互動 過於複雜,無法編寫成自動測試
這些類型日後將透過「自動化」類型的 測試。
隨堂測驗
大多數測試程式庫和架構提供了哪些基本項目?