iT邦幫忙

2026 iThome 鐵人賽

DAY 28
0
Software Development

你的自動化測試,大部分是在演戲|AI coding 時代的探索性測試 30 講系列 第 28

Day 28 從 Test Charter、JSON 到 Playwright:AI 正在重寫探索式測試流程

  • 分享至 

  • xImage
  •  

這段內容摘錄自 Gil Zilberfeld 的技術講座,探討如何將 AI(如 Claude) 整合至探索性測試中以提升效率。

Exploratory Testing with AI
https://www.youtube.com/watch?v=2VNhbkrmFwU&list=TLGGxAOy_nY7FlIyNTAyMjAyNg

作者強調 AI 並非要取代人類的判斷力,而是擔任協作夥伴,協助執行任務拆解、生成測試章程(Charters)及優先級建議。透過實例演示,文中展示了 AI 如何快速產出 API 測試數據、撰寫 Playwright 自動化腳本,以及模擬特定領域(如《星際爭霸戰》)的測試案例。

儘管 AI 偶爾會產生錯誤的選取器或邏輯,測試人員仍可藉此大幅縮短準備時間,進而達成更廣的測試覆蓋率。最終,成功的關鍵在於人類測試員的審核與引導,將重複性勞動委派給 AI,並由專家專注於決策與複雜問題的探索。

講者使用了兩個示範目標來展示 AI 的能力:

  • 案例一:名為 Swag Labs 的電商 UI 測試網站
  • 案例二:星艦迷航記(Star Trek)的 API

案例一:名為 Swag Labs 的電商 UI 測試網站

Swag Labs 包含了購物車、商品排序、登入等常見的電商功能。以下將分為五大階段,詳細說明如何結合 AI 在 Swag Labs 網站上進行深度且高效的探索性測試:

第一階段:利用 AI 快速生成Test Charters與發想

在進行探索性測試時,我們通常不會撰寫厚重的測試計畫書,而是使用輕量級的「Charters」來聚焦探索區域。面對像 Swag Labs 這樣一個全新的網站,AI 可以作為極佳的發想工具。

(1) 提供情境與提示詞:

講者將 Swag Labs 的首頁網址提供給 AI,並給予充分的背景資訊,例如:「這是一個電商網站,首頁包含登入憑證,你可以使用它登入,且可以在不使用真實金錢的情況下購買商品」。接著,講者要求 AI 針對登入情境、產品頁面、結帳流程(包含完成與未完成的情境)生成測試章程。

(2) AI 提供的測試建議與人類審查:

在短短 3 秒內,AI 就提供了非常豐富且結構化的測試建議。

  • 登入功能: 除了基本的有效與無效帳號密碼測試外,AI 甚至建議了「鍵盤導覽的無障礙測試(Accessibility)」以及「常見安全攻擊模式」。這對於測試人員來說是非常好的靈感啟發。

  • 結帳流程: AI 建議測試不同數量的產品、表單驗證,以及「放棄結帳」的情境。

  • 人類審查的關鍵: AI 建議測試「產品篩選(Filtering)」功能,但實際上 Swag Labs 網站並沒有這個功能。講者藉此強調,這就是為什麼流程中必須有人類參與的原因。測試人員必須清楚知道自己正在測試什麼,不能盲目聽從 AI 的建議,必須扮演審查員的角色。

第二階段:模擬使用者行為,進行測試優先級排序

在真實的軟體開發週期中,測試時間往往非常有限。測試人員必須根據風險與專案現況來排定測試的先後順序。

(1) 借用 AI 的大數據經驗:

由於 Swag Labs 是一個非常標準的電子商務網站架構,AI 已經吸收了大量相關的訓練數據,因此它的判斷力通常相當不錯。講者詢問 AI:「我沒有時間測試所有東西,如果你是一般使用者,你能根據電商網站的常見使用者行為,幫我排定這些測試建議的優先順序嗎?」。

(2) 聚焦轉換漏斗(Conversion Funnel):

AI 成功地將測試項目分為高、中、低優先級。它將「登入功能」、「瀏覽產品」、「加入購物車功能」以及「包含表單驗證的完整結帳流程」列為最高優先級。相對地,它將「登入錯誤處理」與「產品排序」列為較低優先級。

AI 的邏輯是聚焦於「主要轉換漏斗(Main conversion funnel)」,確保核心的認證與購物系統能正常運作。這對於不熟悉該系統的測試人員來說,提供了一個極佳的起始點與信心。

第三階段:動態導航與規劃下一步

探索性測試是一個「走一步、看一步」的過程。當測試人員完成某個區域的探索後,可以將現況回饋給 AI,讓 AI 協助規劃下一步。

(1) 提供當下狀態:

講者向 AI 描述目前的測試進度:「我現在在產品頁面,我已經測試完所有排序的情境了,現在頁面正處於『價格由高到低』的排序狀態。我接下來該測試什麼?」。

(2) AI 的情境推導:

AI 像拼圖一樣,根據當下的上下文給出了符合邏輯的後續步驟。它建議接下來可以測試:「加入購物車功能」、「產品詳細資訊」、「響應式設計(Responsive design)」以及「購物車互動」。雖然 AI 再次提及了不存在的篩選功能,但這個動態提問的過程,能幫助測試人員在測試陷入停滯時,快速獲得新的靈感並持續推進。請將這些視為建議,而非死板的指令。

第四階段:從手動探索無縫轉換為自動化測試腳本

探索性測試的其中一個目的是發現並確認系統的功能運作正常。當測試人員手動確認了一條關鍵路徑(例如成功登入並跳轉到商品頁)後,通常會希望將其記錄下來,甚至轉化為自動化腳本,以便未來加入自動化測試套件中重複執行。

(1) 生成 Python Playwright 腳本:

講者要求 AI 將剛剛成功執行的「有效憑證登入並導航至產品頁面」情境,直接寫成 Python 的 Playwright 測試腳本。AI 迅速生成了包含開啟網頁、填寫帳密、點擊登入按鈕,以及驗證頁面跳轉的程式碼。

(2) 處理 AI 的錯誤與技術門檻:

講者指出,雖然程式碼邏輯正確,但 AI 生成的「網頁元素選擇器(Selectors)」是錯誤的,導致程式碼無法直接執行。這點出了使用 AI 的一個關鍵:測試人員必須具備基礎的程式設計或自動化技能。如果你完全不懂 Python,你將無法理解腳本為何失敗,也無法動手修復這些選擇器錯誤。我們是 AI 的副駕駛,必須親自確認並修正它產出的結果。

(3) 重構為頁面物件模型(Page Object Model, POM):

為了解決實務上整合的問題,講者進一步要求 AI 將生成的腳本重構為「頁面物件模型(POM)」的設計模式。因為在企業環境中,自動化基礎設施通常已經具備特定的設計模式,我們需要 AI 產出符合團隊既有框架的程式碼(例如將登入頁面與產品頁面拆分為不同的物件),這樣才能真正無縫整合 到現有的測試套件中。

第五階段:自動化測試前置作業(Automating Test Setup),深入探索未知

在進行深度的探索性測試時,測試人員往往需要花費大量時間在「前置準備」上。例如,為了測試購物車的深層功能,每次都必須手動打開瀏覽器、登入帳號、點擊商品加入購物車,這非常耗時。

(1) 撰寫前置作業腳本:

講者利用 AI 寫了一段非標準測試的 Python 腳本。他給予 AI 的提示詞是:「我想要探索購物車頁面。請幫我寫一個腳本:登入應用程式、選擇兩個商品、前往購物車頁面,然後交給我接手。」。

(2) 保持瀏覽器開啟以利接手:

這段腳本最關鍵的地方在於,AI 成功撰寫了自動登入並加入兩件商品的流程,且腳本執行完畢後並不會關閉瀏覽器。這意味著,測試人員可以直接跳過繁瑣的登入與選購過程,直接面對準備好的購物車頁面(此時已深入系統三層頁面),從這個最佳狀態開始進行深度的手動探索。

透過 Swag Labs 的案例,我們可以看到 AI 在探索性測試中扮演了強大的輔助角色。然而,講者一再強調,我們不使用自主代理(Agents)來全權處理測試,因為軟體測試極度重視「正確性」與「未來執行的可重複性(Repeatability)」。將任務交給對話式的 LLM,能讓我們保留審查與修正的控制權。

導入 AI 的最終目的,並不是單純為了更快結束測試流程,而是為了在有限的時間內,將撰寫樣板程式碼、發想情境、準備前置作業等繁瑣工作交給 AI,藉此省下時間來探索更多未知的領域,達到更深、更廣的「測試覆蓋率(Coverage)」。測試人員未來的角色,將逐漸轉變為管理 AI、審查 AI 產出,並專注於發揮人類獨有洞察力的「管理者與審查員」。

案例二:星艦迷航記(Star Trek)的 API

有別於 UI 測試,API(應用程式介面)的測試通常較為抽象,缺乏視覺化的介面引導,因此測試人員在面對未知的 API 時,往往需要花費大量時間閱讀文件與梳理資料結構。

為了具體展示 AI 如何突破後端測試的盲點,講者特別選擇了「星艦迷航記(Star Trek)API」作為示範案例。這是一個真實存在的伺服器端 API 服務,主要用來搜尋星艦迷航記宇宙中的角色與相關資訊。

以下將分為五大階段,詳細拆解如何結合 AI,針對這個星艦迷航記 API 進行深度、高效且充滿驚喜的探索性測試:

第一階段:透過 Schema 綱要檔案,瞬間生成「Test Charter」

在 API 的探索性測試中,最困難的往往是「第一步該測什麼」。傳統上,測試人員必須逐行閱讀 API 文件;但在 AI 時代,我們有了更聰明的做法。

(1) 餵給 AI 結構化資料:

講者並沒有花時間向 AI 解釋這個 API 在做什麼,而是直接將該 API 官方提供的 OpenAPI YAML 綱要檔案(Schema)輸入給 AI。這個檔案包含了 API 的端點(Endpoints)、允許的方法(如 POST、GET)、參數定義以及資料型態。

(2) 自動提取Test Charters:

講者隨後要求 AI 針對其中的「角色搜尋 API(Character Search API)」提出測試章程建議。在短短 3 秒內,AI 讀懂了複雜的 YAML 結構,並自動生成了一系列極具專業深度的測試方向,包含:

  • 基礎搜尋功能: 使用不同的角色名稱來驗證搜尋精準度。
  • 分頁參數測試(Pagination): 驗證回傳資料的筆數控制。
  • 多重篩選器測試(Search Filters): 根據 Schema 的定義,測試「性別(Gender)」、「物種(Species)」與「狀態(Status)」等條件組合。
  • 邊界與異常測試: AI 建議測試「畸形請求(Malformed requests)」(即發送不符合格式的資料,看系統如何防護),以及測試特殊的 Unicode 字元。
  • 進階技術測試: AI 甚至提出了測試部分名稱匹配功能、併發搜尋請求(Concurrent search requests),以及 API 版本控制(API versioning)的影響。

透過這個步驟,測試人員瞬間獲得了一份全面且結構化的探索地圖,完全省去了前期摸索的時間。

第二階段:融合「領域知識」,生成極具真實感的測試範例

探索性測試不僅需要好的方向,更需要「好的測試數據(Test Data)」。人類測試員在發想數據時,往往受限於想像力,經常輸入 test1、abc 這種單調且缺乏真實情境的資料。這是 AI 展現其強大價值的關鍵時刻。

(1) 結合流行文化的背景知識:

講者要求 AI 根據剛剛生成的章程,提供具體的測試範例。由於大型語言模型已經吸收了全世界龐大的文本資料,它非常清楚「星艦迷航記」的世界觀。

(2) 突破常規的測試數據:

  • 基礎與邊界範例: AI 提出了搜尋寇克(Kirk)、畢凱(Picard)與史巴克(Spock)等經典角色。在分頁測試上,它精準抓出 Schema 中「最大允許值 100」的邊界,並建議測試「超出可用範圍的頁碼」。

  • 特殊字元與非拉丁語系的完美結合: 這是最令講者驚豔的一點。當 AI 建議測試特殊字元時,它並沒有隨便給一串亂碼,而是給出了 "Worf son of Mogh"(莫格之子武夫)。在星艦迷航記的設定中,克林貢人(Klingon)的名字往往包含特殊的拼寫或標點符號。

  • 家族關聯測試: AI 還建議搜尋 "Tom Paris"(湯姆·派瑞斯)與他的父親 "Owen Paris"(歐文·派瑞斯)。

講者強調,AI 將「軟體測試的邊界條件技巧」與「該應用程式的內容世界觀(Content World)」完美結合。這種具備高度真實感與脈絡的測試數據,能幫助測試人員更容易發現系統在處理真實業務邏輯時可能隱藏的缺陷。

第三階段:將構想具現化,自動準備複雜的 JSON 請求資料

在 API 測試實務中,即便我們想好了測試情境,要徒手撰寫符合格式的 JSON 請求主體(Request Body)依然是一件繁瑣且容易打錯字的工作。探索性測試強調流暢的節奏,不該被這類繁文縟節打斷。

(1) 提出具體的業務情境需求:

講者請 AI 幫忙準備兩組發送給搜尋 API 的輸入資料(Input Requests):一組是要尋找「來自鏡像宇宙的史巴克(Spock from the mirror universe)」,另一組則是尋找「史巴克 2 號(Spock 2)」。

(2) 自動生成精準的 JSON 負載(Payload):

AI 再次發揮解析 Schema 的能力,成功生成了兩個完美的 JSON 格式檔案。這兩個請求不僅包含了正確的搜尋關鍵字,還依據規範帶入了必要的分頁參數(Pagination parameters)。 講者拿著這份 AI 生成的 JSON 資料實際去打 API,雖然伺服器回傳了失敗(因為該系統資料庫存在 Bug),但這反而證明了 AI 準備的測試資料格式是完全正確的,成功協助測試人員揪出了系統底層的缺陷。

第四階段:預測「預期結果」,建立測試的比對基準

軟體測試的核心在於「輸入」與「輸出」的比對。當我們發送了一個充滿變化的搜尋請求後,我們必須知道「系統理應回傳什麼樣子」,這稱為預期結果(Expected Results)。

  1. 讓 AI 模擬後端回應: 講者詢問 AI:「針對剛剛那兩個史巴克的請求,請幫我準備一份可以用來比對的預期結果檔案。」

  2. AI 的限制與自我防護機制(免責聲明): AI 很快生成了龐大的 JSON 回應範例,但它非常聰明地給出了一段警告:「請注意,因為我沒有實際執行這個 API,所以實際的 API 回應可能會包含額外的欄位,或是有微小的差異。」 此外,AI 還主動扮演了顧問的角色,提醒講者:「在比對 API 回應時,建議您專注於核心欄位(如名稱 Name、鏡像狀態 Mirror Status 等),因為像 UID(唯一識別碼)這種欄位是動態的,每次都會改變,不應該納入絕對比對的標準。」

  3. 人類審查員的必要性(揪出 AI 的幻覺): 儘管 AI 表現優異,但講者在檢視 AI 生成的預期結果時,發現了一個經典的 AI 錯誤(幻覺)。對於「鏡像宇宙的史巴克」,AI 自作聰明地將預期回傳的角色名稱(Name)寫成了 "spock mirror";但實際上,系統正確的設計應該是名稱保持為 "spock",並將另一個布林值欄位設為 mirror=true。

這個失誤完美呼應了講者演講的核心理念:「我們必須成為 AI 的審查員與管理者(Reviewers and Managers)。」 AI 可以幫我們省下 90% 撰寫 JSON、發想情境的時間,但那最後 10% 的「正確性判斷」與「領域專業」,絕對必須掌握在人類測試員的手中。

結語:探索性測試的新境界

透過這個星艦迷航記的 API 案例,我們可以清晰地看到 AI 如何重塑後端探索性測試的流程。從瞬間解析 YAML 綱要檔案、結合劇集世界觀生成極具真實感的測試數據,一直到自動撰寫複雜的 JSON 請求與預期結果,AI 展現了驚人的生產力。

然而,講者一再提醒,導入 AI 的目的絕不是為了取代測試人員,也不是單純為了更早下班。相反地,軟體測試的終極目標是追求**「更高的測試覆蓋率(More Coverage)」**。當 AI 幫我們承擔了那些枯燥的資料準備與撰寫工作後,人類測試員終於能解放腦力,將省下來的寶貴時間,投入到更深層次、更具破壞性、更需要人類直覺與好奇心的「未知領域探索」中。這才是結合 AI 的探索性測試,所能帶給軟體品質保障的最大價值。


上一篇
Day 27 探索式測試 × AI:不是自動化一切,而是把腦力留給真正重要的事
下一篇
Day29 用 Claude Code + Playwright 做探索性測試
系列文
你的自動化測試,大部分是在演戲|AI coding 時代的探索性測試 30 講30
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言