什麼是測試，以及為什麼需要測試

Claude Code 修改了程式碼，並回報："測試通過"。這句簡短的話背後，代表有檢查用的檔案、執行指令，以及具體結果。先來看看測試有哪些類型、哪些事情可以手動檢查，再了解自動測試，以及如何解讀測試結果。

用一個簡單的點數計算範例就夠了。您不必先熟悉測試函式庫：我們會先手動走過情境，再列出自動測試的預期結果，最後讀懂執行報告。

測試有哪些類型

測試能幫助您了解程式如何運作、是否符合需求，以及問題出在哪裡。例如，點數是否正確增加、空白欄位的申請能否送出、錯誤訊息是否清楚。為此，先設定檢查條件、執行操作，再查看結果。

測試可以依照不同面向分類。先從由誰執行操作並判斷結果開始：

• 手動測試 - 由人親自操作，並判斷結果如何；
• 自動化測試 - 將部分檢查交給程式執行：程式會照指定步驟操作並比較結果。這類檢查本身通常稱為自動測試。

這是依照執行方式所做的分類。還有另一個問題：究竟檢查什麼。功能測試關注行為，例如點數是否按規則增加；非功能測試則關注應用程式的特性，例如回應速度或使用是否方便。這兩種分類彼此獨立：同一項功能可以手動檢查，也可以自動檢查。

自動化並不代表不再需要人參與。您仍要挑選值得檢查的情境、設定預期結果，並了解實際結果與預期的差異。程式只是接手重複性的工作。

什麼是手動測試

手動測試時，由您親自操作，並確認結果是否符合預期。這不需要撰寫測試程式碼，只要有清楚的條件，以及想回答的問題就行。

假設某個教學平台每次配對成功會得到 10 點，三次就是 30 點。您可以這樣手動檢查點數是否正確增加：

1. 開啟要測試的平台版本，準備一位點數為零、尚未領過獎勵的使用者；
2. 準備一筆有三次配對成功的申請，並只送出一次；
3. 查看送出後的餘額：預期是 30 點；
4. 記下實際結果。如果數字不同，保存操作步驟，必要時也截圖。

起始餘額很重要。如果原本已有 20 點，增加獎勵後預期會是 50 點，而不是 30 點。沒有明確的起始條件，很容易把正確結果當成錯誤，或反過來。

您可以簡短記下檢查結果："送出前餘額為 0，三次配對成功，只送出一次，預期 30 點，實際得到 3 點"。其他人或 Claude Code 就能依照這段紀錄重現情境。"點數好像怪怪的"可說明不了這些細節。

手動測試也可以是探索式的：您一邊了解應用程式，一邊想出新的檢查方式。例如，您注意到送出後按鈕仍可使用，於是再測試一次點擊會發生什麼事。這種測試沒有預先列好的逐步流程，但仍有明確目標：了解行為並記錄發現的問題，而不只是隨手點點。

過程中使用工具也完全沒問題。您可以開啟瀏覽器主控台、查看伺服器回應、截圖，或記錄檢查清單。"手動"指的是由人控制檢查並判斷結果，不是說不能使用工具。

當您要探索新的行為，或評估介面是否好懂，手動檢查很方便；而需要重複執行已描述的操作並比較結果時，自動測試就很實用。這不是"介面只能手動檢查，計算只能靠程式"的硬性分界：瀏覽器中的操作也能自動化，計算結果也能手動檢查。

按下自動測試的執行按鈕，並不算手動測試，因為啟動後由程式負責檢查。相反地，如果 Claude Code 為您列出步驟，而您親自操作平台並判斷結果，這仍然是手動檢查。代理只是協助您準備流程。

什麼是自動測試

想像您正在檢查計算機。輸入 2 + 2，事先預期答案是 4，再把螢幕上的數字與預期比較。如果看到 5，就知道這個例子的結果錯了。無論計算機顯示什麼，您都知道正確答案。

自動測試會用程式完成類似的工作。它是一段小程式，會設定起始條件、執行操作並檢查結果。比較的工作由程式碼代替人來做。接下來我們會把這類自動測試簡稱為測試。

回到有獎勵的教學平台：每次配對成功得到 10 點，三次應得 30 點。可以先用文字描述檢查方式：

1. 設定配對成功次數：3；
2. 計算獎勵；
3. 確認獎勵點數等於 30。

這就會成為一個測試。它包含事先已知的範例和預期答案。"每次配對成功得 10 點"是我們這個教學平台的規則，其他應用程式可能採用不同規則。

測試不會自行推算使用者應得多少點數。必須有人根據需求寫下預期結果。可以由開發人員完成，也可以依照您的要求交給 Claude Code，但仍要確認預期結果符合任務要求。

為什麼要重複檢查

手動檢查一次點數計算並不麻煩。問題會在之後出現：您新增獎勵類型、修改申請處理方式，或請代理簡化某個函式。每次修改後，都得再次確認：三次配對成功仍然會得到 30 點嗎？

您可以每次重新準備申請、操作並查看結果，也可以把檢查寫成程式碼，之後重複執行。在準備條件相同時，測試會重做指定操作並比較結果，不必每次重新說明要按哪裡、什麼才算正確。

專案越大，這類規則就越多。沒有配對成功時不應增加點數；重複送出的申請不能計算兩次；獎勵清單必須依照指定順序排列。您可以一次執行所有檢查，看看修改後哪些預期結果不再成立。

自動化的好處就在這裡：重新檢查已描述的行為，可以減少手動操作。撰寫測試同樣需要時間，而且需求變更時也要重新檢視。但對於經常需要確認的規則，反覆執行測試就能省回這些工夫。

測試檔案放在哪裡

測試儲存在一般的專案檔案中。在小型 JavaScript 專案裡，將檢查放在它所呼叫的程式碼旁邊會很方便：

reward-example/
├── package.json
└── src/
    ├── reward-flow.js
    └── reward-flow.test.js

reward-flow.js 存放獎勵計算邏輯。reward-flow.test.js 則存放呼叫計算邏輯並檢查答案的程式碼。package.json 用來描述專案設定和指令，也包括測試指令。

檔名中的 .test.js 可幫助您辨認測試檔案。這是測試工具支援的慣例，不是 JavaScript 語言本身的規則。其他專案可能使用不同命名方式，或把測試放在獨立的 tests/ 資料夾。一個檔案可以包含多項測試，不一定要每個原始碼檔案旁邊都放一個測試檔。

如果 Claude Code 正在處理您不熟悉的專案，可以先請它找出現有的點數計算測試，並提供檔案路徑。即使您還不熟悉所有資料夾，也能將檢查內容與想確認的行為對照起來。

如何把需求轉成檢查

"修好點數計算並用測試確認"這個要求，讓代理同時面對兩個問題：怎樣才算計算正確？又要如何證明結果正確？最好先說明您希望系統呈現什麼行為。例如："每次配對成功可得 10 點。三次配對成功時，獎勵應為 30 點。"

不需要寫任何程式碼，也能把這個需求整理成檢查方式。請描述以下三件事：

可以把它濃縮成一句話："如果有三次配對成功，計算出的獎勵應該是 30 點。"這樣的資訊足以討論測試的意義。至於在這個專案中要用什麼程式碼實作，就交給代理處理。

請先選定究竟要確認什麼。"計算出的獎勵是 30 點"和"使用者的餘額變成 30 點"是不同的預期結果。後者需要設定起始餘額，並執行增加點數的操作，就像前面的手動檢查。因此，與其說"檢查點數"，不如描述明確可觀察的結果。

接著想想相近的情境。依照我們的規則，可以先從一張小表格開始：

不必一開始就想出幾十種情境。先從出問題的情境，以及幾個可能受修改影響的相近情境開始。如果不清楚重複送出申請時應該怎麼處理，就先確認規則。代理可以提出建議，但那還不代表預期結果已經取得共識。

如何請 Claude Code 協助檢查

說明預期行為後，就可以依此安排工作。代理會先確認專案中已有的檢查，再與您的情境比對。您需要的檢查可能已經存在；這時要做的是執行測試並讀取結果。如果還沒有，代理就需要新增測試。

第一個要求可以這樣寫：

請修正獎勵計算方式。
規則：每次配對成功可得 10 點。
要檢查的情境：3 次配對成功得到 30 點，
0 次得到 0 點，5 次得到 50 點。

修改前，先找出這些情境已有的檢查。
簡短說明目前檢查了什麼、還缺少什麼，
以及您建議新增或修改哪些測試。
如果需求有不清楚的地方，請指出來。
先不要修改檔案。

請把回覆當成對預期成果的描述來看。每個情境中的數字都符合您的規則嗎？檢查的是獎勵點數，還是其他內容？代理有沒有提議修改規則，讓目前的行為看起來符合規則？這個階段是在釐清需求，您不必閱讀測試的實作程式碼。

確認情境後，再請代理執行工作：

依照剛才討論的規則修正計算方式。
使用專案目前採用的工具，
為已確認的情境補上缺少的檢查。
不要只為了讓測試通過而修改既有預期結果。
如果您認為某項預期有誤，請先說明原因。

按照專案指示執行相關測試。
列出指令、工作資料夾和實際輸出。
對於三種情境，分別指出由哪項測試檢查，
以及測試如何結束。請另外列出略過和未執行的檢查。

代理會從專案文件和設定中找出執行指令。在 JavaScript 專案中，通常是 npm test：npm 會執行 package.json 檔案中 scripts.test 欄位所指定的指令。這個名稱背後可能執行各種檢查。您要確認的是，這次執行確實包含需要的情境。

撰寫測試和執行測試是工作中的兩個不同階段。"新增了三項檢查"只代表檔案有所變更，還不能說明結果。要評估結果，必須實際執行測試。如果無法執行，例如缺少相依套件，代理就應說明原因，以及哪些檢查尚未執行。

在回覆中找出"我們的情境 → 對應的測試 → 結果"這條線索。如果討論的三種情境中只有一種有執行，目前也只能確認那一種，即使摘要顯示通過也一樣。

如何閱讀測試結果

以下是使用 Node.js 20.18.0 和 npm 10.8.2 執行一項教學測試的真實結果。它只檢查三次配對成功時的獎勵計算，並未涵蓋前面提出的所有情境。為了方便閱讀，省略了時間資訊和報告中的一些格式內容：

> reward-example@1.0.0 test
> node --test --test-reporter=tap

# Subtest: three matches give 30 points
ok 1 - three matches give 30 points

# tests 1
# suites 0
# pass 1
# fail 0
# cancelled 0
# skipped 0
# todo 0

前兩行顯示套件名稱和執行的指令，接著是測試名稱。ok 1 表示第 1 項測試通過；失敗的測試則會以 not ok 開頭。pass 1 和 fail 0 表示一項測試通過，沒有測試失敗。即使終端機沒有用顏色顯示，這也稱為"綠燈"結果。

在錯誤版本中，三次配對成功只得到 3 點，雖然規則說應該得到 30 點。同一項測試會輸出以下片段；檔案路徑、呼叫堆疊、時間資訊和部分系統訊息已省略：

not ok 1 - three matches give 30 points
  error: |-
    Expected values to be strictly equal:

    3 !== 30

  code: 'ERR_ASSERTION'
  name: 'AssertionError'
  expected: 30
  actual: 3
  operator: 'strictEqual'

# tests 1
# pass 0
# fail 1
# cancelled 0
# skipped 0
# todo 0

先找到測試名稱，再比較 expected 和 actual。前者表示"預期值"，後者表示"實際值"。這裡預期是 30，實際得到 3。fail 1 這一行總結了結果：有一項測試失敗。

這種失敗表示實際結果與寫下的預期不符。接下來要找出原因：可能是計算錯誤、起始資料有誤，或測試本身的預期不正確。不能只為了讓報告顯示通過就修改檢查中的數字，應先核對任務規則。

也可能因為其他原因失敗，例如測試無法載入函式檔案。這時測試甚至還沒比較點數，報告也可能看不到相關測試名稱，而是標記整個檔案失敗。因此，單看 fail 1 還不能得出"計算錯誤"的結論。請查看摘要上方的訊息。

略過的測試

測試還有另一種重要狀態：檢查可能被標記為略過，例如在 Node.js 中使用 test.skip。略過的測試不會執行。報告中出現測試名稱，不代表該情境已經檢查過。

在另一輪範例執行中，被略過的測試會顯示以下行和統計結果：

ok 1 - three matches give 30 points # SKIP

# tests 1
# pass 0
# fail 0
# cancelled 0
# skipped 1
# todo 0

請留意一個容易忽略的細節：這一行以 ok 開頭，卻以 # SKIP 結尾。這個格式就是這樣標記略過的。不能只看第一個詞；pass 0 的統計結果表示沒有任何測試通過。

我們把同一個情境的三種執行結果整理如下：

較大的報告還會顯示其他項目。在我們的範例中，cancelled 和 todo 都是零。如果看到非零數值，請查明哪些測試被取消或標記為未完成；不要把它們算成已成功檢查。suites 代表測試群組：我們的範例沒有群組。

還有一件小事。如果報告顯示測試數量為零，即使沒有測試失敗，也不能證明點數計算正確。需要的檢查可能根本沒有執行。情境名稱和實際執行的檢查數量，比終端機顏色帶來的整體印象更重要。

綠燈結果代表什麼

報告中的測試回答了一個範圍很小的問題："三次配對成功時，獎勵計算正確嗎？"它沒有檢查零次配對成功、重複送出申請，或頁面上顯示的數字。只因為您在要求中提過這些情境，不代表它們就已經受測。

要檢查零次配對成功，需要另外新增一個預期結果為 0 的情境。要檢查重複申請，就必須描述再次執行操作後的預期結果。測試不會從相鄰的程式碼自行推斷這些規則，只會檢查明確寫在測試中的內容。

沒有測試和略過測試並不一樣。被略過的測試會在報告中以 skipped 顯示；至於完全沒有撰寫檢查的情境，報告通常不會提到。即使所有現有測試都通過，未檢查的行為仍可能有錯。

最後，比較結果成功，不代表預期值本身正確。如果我們的規則是 30 點，卻誤把預期值寫成 3，而計算結果也正好是 3，測試還是會通過。因此，討論檢查方式時，最好回答兩個問題：測試確認了什麼行為？預期結果是根據什麼得出的？

了解"測試通過"這句話的適用範圍後，它就很有用。它表示某次執行中的特定檢查已成功完成，但不能保證"應用程式裡再也沒有錯誤"。