昨天談到折扣金額：逐筆打折後取位數，與先加總再打折，可能得到不同總額。今天接著看測試：即使案例依SRS撰寫、預期答案也正確，測試通過後，我們能確認到哪裡？

從同一份SRS，分別實作與驗證

假設一套支援小數金額的訂單系統，要調整折扣計算。SRS寫每筆明細先打九折，再依一般四捨五入取至小數第二位，最後加總。

這次由兩個Agent分工。實作Agent依SRS與既有專案完成修改；測試Agent則在獨立的對話脈絡中，依同一版SRS、介面契約與驗收條件建立測試案例，再接上測試環境執行。

測試Agent先推導輸入與預期結果，不先接收實作Agent對算法的解釋。介面、資料格式與環境資訊可以共享，業務答案則以SRS為依據。這樣分工，是讓驗證多一個獨立的判斷來源。

實作Agent仍可撰寫單元測試、執行測試與除錯。另一個Agent負責的，是從需求角度確認功能表現；兩者的工作可以互補。

答案正確，還要看資料能分辨什麼

檢查測試時，看到其中一個案例使用兩筆100元的明細，預期總額為180元。這個答案符合SRS，測試也通過了。

但這組資料有個限制：逐筆打折，得到90元加90元；先加總再打折，則是200元乘以0.9。兩種做法都得到180元。單看這個案例，還無法分辨程式是否遵守「逐筆取位數後加總」。

這不表示案例沒有用。它可以核對這組輸入的折扣總額，只是要驗證取位數的時機，還需要另一組資料。

沿用昨天的兩筆10.05元，差異就會出現：

依這份SRS，預期答案是18.10元。這組測試資料讓兩種算法產生不同結果，才能檢查程式有沒有把取位數放在規定的步驟。

差異也可能由測試Agent主動指出。我們與AI討論時，便能具體問：「目前哪些案例能分辨逐筆計算與整張計算？」而不是只看新增了幾個測試、通過率是多少。

隔離的是推導脈絡，規格仍要能對得回去

兩個Agent分開工作，可以減少直接沿用彼此解釋的機會，但它們仍可能對同一條規格做出相同解讀。因此，測試交付時，除了執行結果，也可以留下對應的SRS條件、輸入與預期結果，以及這組資料要驗證的差異。

在這個案例裡，檢查重點很明確：答案是否依逐筆計算得出？資料是否讓取位數時機影響結果？執行時是否真的呼叫了要驗證的訂單計算功能？有了這些對應，才看得出測試通過支持了哪一條需求。

如果結果是18.09元，就把差異交回實作端追查；若懷疑測試答案有誤，也回到同一版SRS核對。獨立驗證不代表測試永遠正確，而是讓雙方有共同依據可以討論，不必由其中一邊的輸出決定答案。

測試除了要依SRS算出正確答案，也要選用能讓錯誤做法露出差異的資料。否則，就算程式沒有照規格計算，測試仍可能通過。

從GPT‑6 Sol 升到 6.1，只花了一週
我們的測試資料倒是很穩定
三年了還是用那兩筆100元
至今沒讓任何一個模型為難過