多年來身為一名電子工程師,我透過線路、訊號、方程式與電路來理解系統。我受過的訓練是看著電路圖問一些熟悉的問題:訊號從哪裡進入?它應該往哪裡去?如果這個元件失效會發生什麼事?還有,或許最重要的一點:為什麼會冒煙?

當我轉職成品質保證(QA)工程師、進入軟體開發領域時,我原以為這會是一門完全不同的學科。示波器被瀏覽器開發者工具、API、資料庫、日誌、CI 管線與測試環境取代。我不再追蹤電路中的電壓,而是開始追蹤軟體系統中的請求與資料。我不再尋找短路,而是尋找 bug。

工具變了,但底層的工程直覺卻出奇地熟悉:觀察系統、理解預期行為、引入可控的條件,然後在實際輸出不配合時進行調查。

接著 AI 進入了這個領域,讓整個過程變得有趣得多。

如今,AI 可以產生程式碼、草擬單元測試與整合測試、解讀需求、建議邊界案例、分析日誌、建立測試資料,並協助診斷失敗。若使用得當,它能大幅加速開發與 QA。但這種便利性帶出了一個我認為比「AI 能不能寫軟體」重要得多的問題:如果 AI 同時協助打造產品與驗證產品,那麼誰來驗證 AI 所認為的正確是真的正確?

情境

想像 Aurora Shop,一個虛構的電商平台,由大約十幾人的團隊營運,其中只有兩人分擔 QA 職責。公司上線了一個 AI 客服助理,用來回答客戶關於訂單、出貨與退貨政策的問題。上線三天後,一位客戶詢問某項商品能否退貨。助理充滿自信地回答可以。不幸的是,實際政策寫明該商品不可退貨。客戶嘗試退貨被拒,於是提出申訴。這張工單最後落到我桌上,伴隨主管一個令人不安的問題:「查出為什麼測試沒抓到這個。」

我的第一個直覺不是打開原始碼,而是打開儀表板。

一切皆是綠燈。CI 管線已通過,三百多個自動化測試全數成功,以我們的示例演練資料計算,程式碼覆蓋率約為 90%。從紙面上看,這次發布堪稱完美。如果軟體品質可以完全由儀表板決定,我們大可以恭喜彼此然後提早下班。不幸的是,一位真實的客戶剛剛執行了最重要的一項測試:在真實世界中使用這個產品。而那項測試失敗了。

理解出了什麼錯、錯在哪裡

一開始,顯而易見的問題似乎是:哪個指標說謊了? 更有用的答案是:或許它們都沒有說謊。CI 確實是綠燈。自動化測試套件確實通過了。覆蓋率數字可能完全準確。錯誤在於我們期待這些量測去證明它們從未被設計來證明的事情。一個通過的測試套件只能證明我們選定的情境符合我們的斷言(assertion)。它無法證明我們選對了情境、正確解讀了需求,或涵蓋了對使用者真正重要的風險。

當 AI 同時參與開發生命週期的兩端時,這個區別就變得格外重要。想像一個模型依據需求協助產生實作,然後再依據對同一份需求的相同解讀協助產生測試。實作中包含一個錯誤的假設,而測試原封不動地繼承了同一個假設。測試順利執行、管線轉綠,每個人都收到 CI/CD 傳來令人安心的通知。嚴格來說,這條鏈上沒有任何環節必然出錯。我們只是建造了一個與自己達成共識的高效回饋迴圈。

測試覆蓋率 vs. 需求覆蓋率

這就是為什麼測試覆蓋率與需求覆蓋率不是同一回事。 九成的程式碼覆蓋率告訴我,大部分被插樁(instrumented)的程式碼在測試期間被執行過。它無法告訴我是否做了有意義的斷言、是否演練過邊界條件、是否涵蓋了負向路徑,或預期結果是否反映了真實的業務規則。如同文件所指出的,覆蓋率衡量的是執行,而不必然是正確性。

同樣的問題也出現在測試 AI 驅動的功能時。API 回應 200 OK 只證明伺服器在 HTTP 層級成功處理了請求。它無法證明模型的答案在事實或語境上正確。Schema 驗證可以確認回應包含預期的欄位,卻完全漏掉欄位內容其實是錯的這個事實。延遲檢查則可以證明這個助理「非常有效率地」給出了錯誤答案。

正是在這裡,傳統的確定性斷言開始需要額外的驗證層。對於一個解讀退貨政策的 AI 助理,我會想要一份黃金資料集(golden dataset),其中包含具代表性的問題,以及經獨立驗證的預期結果。我會納入正向案例、負向案例、邊界條件、模糊措辭、特定產品的例外情況,以及對抗性或預期之外的輸入。在不適合使用精確字串斷言的地方,我會明確定義評估標準或可接受的區間,而不是任由「看起來合理」成為非正式的測試策略。

今日產出物:驗證缺口清單

這張驗證缺口表很好地捕捉了這個問題。AI 撰寫的程式碼可能只被原作者檢視,缺少邊界案例測試、靜態分析或獨立審查。AI 產生的測試可能帶來一次完美綠燈的 CI 執行,卻沒有人示範過這些測試真的能偵測到缺陷。AI 驅動的功能可能只由客服人員非正式地評判,沒有黃金資料集、定義好的驗收區間,也沒有留下人工評估紀錄。在每一種情況中,都有東西被驗證了,但證據鏈是不完整的。

特別是對 AI 撰寫的測試,我發現有一個問題極為有用:我能證明這個測試知道怎麼失敗嗎? 一個從未展示過對錯誤實作的敏感度的測試,值得存些懷疑。突變測試(mutation testing)、刻意設計的反例、負向測試與故障注入,都能幫助確認一個測試確實有能力偵測它聲稱要防護的那類缺陷。一套測試不應該只是演練應用程式;它應該能區分行為的正確與錯誤。

QA 的概念

電子工程教會我:一次正確的量測並不能證明整個電路是健康的;量測結果只有在我知道它是在哪裡、如何被量測,以及可接受的公差與相關條件時才有意義。軟體測試遵循同樣的原則。通過的 API 測試、很高的程式碼覆蓋率或綠燈的 CI 管線都是有價值的證據,但沒有任何一項能單獨證明系統正確運作。圍繞同一個錯誤假設建構的數百個測試,仍然可以產生一種非常令人信服的綠色。

AI 能強化 QA:協助產生測試情境、找出邊界案例、分析失敗原因並加速調查,但它不應成為評判自身輸出的唯一裁判。人類的 QA 判斷仍然不可或缺,用來決定事實的來源(source of truth)、找出驗證缺口,以及判斷現有證據是否真的足以支撐一次發布。歸根結底,我的職責不只是確認測試通過,而是提出更重要的問題:誰來驗證這個?還有什麼沒被測到?以及什麼證據能證明產品真的可用?

無論我看的是電路板還是 CI 儀表板,一次量測只有在我理解它究竟證明了什麼時,才是有意義的。

而在軟體中,綠燈應該意味著比「沒有東西失敗」更多。它應該意味著我們擁有足夠的獨立證據,來解釋為什麼我們相信這個系統是可用的。