AI 測試的真正風險:虛假信心,而非錯誤

儀表板亮起了綠燈。所有冒煙測試都通過了。AI 助理產生了新的測試案例,清理了舊的測試案例,甚至在幾分鐘內報告了測試覆蓋率的改善情況。團隊在星期五滿懷信心地朝著發布邁進。

現在,是星期一早上。

支援部門收到了工單。客戶儲存的地址無法結帳。他們儲存的地址怎麼會出問題?在一般的行動裝置上,UI 看起來完全損壞了。一個關鍵的 API 沒有穩健的邊緣案例處理。綜合來看,所有這些問題都指向一個更大的威脅:團隊願意盲目依賴外部輸入,假設一切都是正確的。

這就是 AI 為 QA 帶來的真正危險。

並不是說 AI 會在我們的測試中引入錯誤。所有軟體都有錯誤。所有 QA 團隊都擅長識別和解決它們。然而,AI 更大的威脅在於,它可以讓團隊相信他們的測試是徹底的,即使事實並非如此。透過測試中的 AI,QA 團隊可能會產生一種虛假的安全感,認為一切都是準確的。

這種虛假的信心可能非常昂貴。這種過度自信可能導致巨大的財務責任。即使是經過充分測試的 AI 系統,在面對現實世界的複雜性時有時也會失敗。McDonald's 最近關閉了一個正在其得來速櫃檯測試的 IBM AI 系統,因為它在訂單中反覆出錯。這提醒我們,即使是可靠的技術也可能存在嚴重缺陷。

QA 中的虛假信心真正意味著什麼

真正的問題發生在團隊確信測試已經充分測試了特定系統時。這種虛假的安全感來自於相關的安全風險要麼沒有被發現,要麼沒有經過嚴格測試。

這長期以來一直是傳統自動化方法中的問題。在這些方法中,可能會執行大量測試,但測試深度並不足夠。流程報告顯示所有檢查都已通過(全部為綠色)的事實並不意味著系統本身必然會完美運作。

在實施 AI 時,自動化變得更加複雜。關於 AI 語言模型要知道的一件事是,它們可以以看似令人信服但實際上具有誤導性的方式呈現資訊。

我們可能會看到測試執行,甚至更好的測試覆蓋率,因為 AI 協助進行測試建構和分析任何測試執行的結果。所有這些都是有益的。

但並非所有好處都是完全可靠的。

由 AI 建構的測試可能會遺漏一些關鍵的業務邏輯。或者,它可能僅設計用於測試常見場景。這樣的測試看起來完全足夠。如果結果乾淨且表達清晰,團隊很可能會認為測試是足夠的,從而讓嚴重的缺陷未被發現。

這就是為什麼測試經常會為團隊創造做出錯誤假設的機會。

今天,對於任何參與使用人工智慧進行自動化軟體測試的人來說,更關鍵的問題不應該是「AI 是否更有效率地建構測試?」而應該是「AI 建構的測試真的可靠嗎?」

為什麼 AI 讓問題更難被注意到

糟糕的手動測試可以快速識別。編寫不當的腳本測試經常會出錯。

但是當由人工智慧(AI)建構的測試失敗時,很難一眼就看出來。它們可能做出看似非常準確的斷言,以及看似真實的名稱和場景。但它們可能會悄悄地遺漏最重要的因素。它們可能會誤解功能的真正目的。它們可能以不同的方式呈現相同的想法。AI 還可能在沒有充分證據的情況下對軟體發布做出過度自信的報告。

這在外表的流暢性和內在的品質之間創造了一個危險的差距。

在品質保證(QA)中,我們的信心應該來自測試的可追溯性、覆蓋深度、風險評估和可觀察的結果。而不是來自 AI 產生的資料看起來有多漂亮。

AI 在現代 QA 中創造虛假信心的五種方式

過度測試常見場景

AI 在有規律模式的地方表現出色。因此,它很容易被正常流程、預期輸入和常見使用者行為所吸引。

但嚴重的軟體缺陷往往隱藏在其他地方:

• 狀態轉換: 從一個狀態變更到另一個狀態期間。
• 時序問題: 流程時序中的錯誤。
• 重試和中斷: 當失敗的交易被重試或中斷時出現的問題。
• 權限邊界: 權限邊界中的安全漏洞。
• 部分失敗: 當系統僅部分失敗而沒有完全崩潰時。
• 不一致的現實世界輸入: 現實世界中客戶提供的隨機資訊。

如果 AI 產生的測試只遵循產品設計師設想的常見場景,它們將不會觸及風險路徑。這只會創造測試完整的錯覺。

創造不良斷言

測試的真正價值在於它證明了軟體的什麼。太多糟糕的測試涵蓋了應用程式上大量操作範圍,但沒有正確檢查這些操作對業務是否成功。測試只是一個動作,它所做的只是點擊按鈕、填寫欄位、點擊更多按鈕、查看螢幕,然後看到某些東西彈出。

AI 可以比人類更快地執行這種輕量級自動化測試。然而,如果您的測試條件(斷言)過於籠統、定義不清或與業務用例無關,那麼僅執行測試通過並不能為軟體發布提供太多安全保障。結帳中的測試通過可能只顯示成功橫幅,而不能確保訂單被正確處理(稅金、總計等)、發送了電子郵件或減少了庫存。

更多測試案例數量與更多缺陷

團隊可能會檢查 40 個手工編寫的測試案例。但他們可能不會對使用 AI 快速創建的 400 個採取相同的方法。這是基於 AI 的品質保證(QA)最大的陷阱之一:隨著數量增加,仔細測試自然會減少。

擁有更多測試案例可以給我們一種心理上的信心。當數量增加時,我們感覺測試套件非常廣泛,報告也無懈可擊。但增加測試案例的數量永遠無法替代它們的品質。

如果沒有適當的風險映射和需求可追溯性,AI 只會幫助記錄猜測,而不是檢查系統的真正品質。

創造對綠燈的盲目信任

當流程報告總是顯示綠色時,它給團隊帶來強烈的信心感並鼓勵快速決策。它消除了完成工作的障礙,因此當團隊開始使用 AI 建構、修復和優先處理自己的測試時,這種安全感很容易傳播。他們的本能從檢查和驗證結果轉變為只是盲目信任系統。表面上看起來很小,但它可以永遠改變 QA 文化。問題不再是「這個測試涵蓋了什麼風險?」而變成「AI 為此執行測試了嗎?」在這一點上,人們傾向於假設一切都很好並停止質疑品質。

讓甚至明顯的錯誤看起來也很智慧

現代 AI 系統最危險的特徵之一是,它們可以以極大的真實性呈現即使是最明顯的錯誤。這對品質保證(QA)非常重要。

即使 AI 測試是基於對需求的誤解或不完整的資訊編寫的,其輸出也會非常準確和精緻,看起來像是正確編寫的。典型的測試將無法快速發現錯誤。這裡的危險不僅在於錯誤本身,還在於錯誤多麼容易被相信。

明顯的錯誤可能會被快速修復。但看似可信的錯誤結論很可能在未經測試的情況下被發布。

聰明的 QA 團隊的不同做法

這並不意味著應該完全避免使用 AI。

解決方案是在不放棄判斷力給 AI 的情況下使用它。最好的品質保證(QA)團隊將 AI 視為助手,而不是盲目信任的東西。雖然他們使用它來提高速度,但他們不會給予它最終信任。也就是說,他們遵循一種工作方式,即只在驗證後才信任 AI 提供的輸出。

讓我們看看這在實踐中是如何運作的。

在建構測試之前了解風險

在創建測試案例之前,您應該清楚地定義可能影響業務或使用者的主要問題。

與金融交易、法律事務(合規性)、身分、權限和客戶信任相關的領域應該是首先關注的。很少發生但造成大量損失的錯誤是什麼?錯誤容易在哪裡被忽視?

AI 可以在這些領域提供新想法。但由人類決定風險更大的地方。

檢查測試斷言什麼,而不僅僅是步驟

AI 產生的測試案例中的每個步驟乍一看可能都是正確的。但真正的問題是測試是否實際測試了正確的結果。

在測試時養成一個簡單的習慣是個好主意:更多地關注測試證明了什麼,而不是它如何運作。

維持分層測試覆蓋

單一層測試本身無法保證系統是完整的。單元測試、API、整合、端到端(E2E)、探索性測試和生產反饋都暴露了不同類型的風險。

如果 AI 只測試一層,團隊不應該認為他們的系統是完全安全的。每一層都應該以其自身的重要性進行測試。

QA 的未來不是更少的人力

許多人擔心測試中的 AI 將成為一項無人化的工作。但實際上,相反的情況正在發生。

隨著 AI 接管重複性任務,人類干預變得更有價值。識別風險、消除歧義、質疑假設、測試複雜的邊緣案例,以及詢問「系統是否因為測試通過而安全?」所有這些都需要人類智慧。

這不是關於更少的工作,而是關於更好的品質。未來最好的團隊不是那些建構無數測試的團隊。而是那些能夠快速而仔細地工作,但在必要時提出質疑的團隊。

因為系統中的錯誤總是可見的。但過度自信往往導致我們忽視它們。

下一步行動的經驗教訓

AI 當然可以加快 QA 流程。它可以幫助團隊建構測試、減少重複性任務並更快地回應變更。

但這種無監督的速度可能導致新的品質問題。當 AI 產生的測試讓我們感到完整,當華麗的儀表板讓我們相信它們,當精美的報告優先於嚴格的評估時,QA 並不真正穩健。相反,它變得容易被愚弄。

最安全的團隊是那些記住簡單事實的團隊,即僅僅因為測試通過,並不是系統安全的絕對證明。它只是一個指示,仍然需要使用人類智慧來評估該指示。

因此,AI 對 QA 構成的真正威脅不是錯誤。而是它給予的虛假信心。