從業務流程到測試案例：Playwright 基礎操作與實務應用

UI 自動化測試 - 使用 Playwright x AI Agent 系列 #02

開始使用 Playwright 撰寫 UI 自動化測試時，往往會先將注意力放在 click()、fill()、Locator 與 Assertion 等基礎腳本語法。然而，真正影響測試能否穩定執行、重複驗證與持續維護的關鍵，通常不在語法本身，而在於是否已先明確界定測試範圍。

現實中的業務流程（Business Process）通常橫跨多個角色、作業活動與系統狀態，涵蓋範圍往往過大；Playwright 測試腳本則需要明確界定前置條件、操作步驟、測試資料與預期結果。若未先將業務流程轉換為具體的測試情境與測試案例，開發者或 AI Agent 便只能自行推測測試應從何處開始、驗證範圍到哪裡為止，以及符合哪些條件才算通過。

因此，進入 Playwright 腳本實作前，需要先處理兩個問題：

1. 如何從業務流程界定 Test Scenario、Test Suite 與 Test Case。
2. Playwright 測測試體系的三個核心組成（CLI、Skill 與 Test），以及他們在瀏覽器操作、Agent 協作與自動化測試中的分工。

這兩個問題釐清後，瀏覽器操作才可能從一次性的 UI 探索，轉換為可重複執行的自動化測試。

業務流程不等於測試案例

業務流程（Business Process）通常描述跨角色、跨活動與跨系統狀態的完整作業脈絡。例如：

建立申請
→ 主管審核
→ 退回補件
→ 再次送審
→ 核准
→ 查詢處理結果

這份流程適合用來理解系統如何運作，但不適合直接轉成一支 Playwright Test。流程中可能包含不同角色登入、人工判斷、等待事件、外部通知，以及無法在同一次瀏覽器操作中穩定完成的狀態轉換。

若直接把完整流程塞進一支測試，常見結果包括：

• 測試執行時間過長。
• 前置狀態與測試資料難以重建。
• 任一中間步驟失敗，後續驗證全部中斷。
• 失敗結果只能指出流程未完成，卻難以定位問題。

UI 自動化需要先從完整業務流程中找出可由單一角色連續操作、而且可以從畫面判定結果的範圍。

企業流程、活動與操作程序的區分

將業務描述轉換為 UI 測試之前，需先區分業務流程（Business Process）、業務活動（Activity）與操作程序（Operation Procedure）三個層級。

名稱	定位	範例
業務流程	跨角色與活動的完整作業脈絡	購買商品、付款、出貨與配送
業務活動	某個角色在特定節點完成的工作	顧客購買商品
操作程序	操作者在一次操作階段內完成的一連串 UI 步驟	登入、搜尋商品、加入購物車與完成結帳

以電子商務購物流程為例，可以拆分為：

Business Process：商品購物與訂單處理流程
　
Activity：訂購（購買）商品
Operation Procedure：
登入網站 → 搜尋商品 → 查看商品詳情 → 加入購物車
→ 填寫收件與付款資料 → 送出訂單
　
Activity：處理商品出貨
Operation Procedure：
登入後台 → 查詢待出貨訂單 → 檢視訂單內容
→ 建立出貨資料 → 更新訂單狀態

使用 Playwright 撰寫測試案例時，通常不會直接驗證完整的業務流程，而是選定其中某項業務活動所包含的操作程序，進一步界定為可執行、可驗證的測試範圍。

例如：

客戶登入電子商務網站
→ 搜尋並查看商品詳情
→ 將商品加入購物車
→ 填寫訂購資料並完成結帳
→ 確認畫面顯示訂單成立結果

這段操作程序具有明確的起點與終點，測試資料及前置狀態也可加以控制，最終結果則能透過畫面內容判定，因此較適合進一步轉換為自動化測試案例。

從業務情境轉換為測試情境、測試套件與測試案例

業務流程與使用者操作程序仍不屬於正式的測試規格。若要進一步轉換為可執行的使用者介面（UI）測試，需先區分測試情境（Test Scenario）、測試套件（Test Suite）與測試案例（Test Case）。

名稱	回答的問題	主要用途
測試情境	要驗證什麼情境？	描述使用者目標或主要業務情境
測試套件	如何組織相關案例？	依功能、流程或驗證目的管理一組測試案例
測試案例	如何進行具體驗證？	定義前置條件、測試資料、操作步驟與預期結果

三者的關係可簡化為：

• 測試情境：界定測試意圖
• 測試套件：組織相關測試案例
• 測試案例：界定可執行條件與預期結果

以一般電子商務網站為例：

測試情境：
已登入的客戶可以搜尋商品、加入購物車並完成結帳。
　
測試套件：
購物主流程 UI 驗證
　
測試案例：
1. 使用有效帳號登入後，可以進入商品列表。
2. 輸入指定關鍵字後，可以看到目標商品。
3. 將商品加入購物車後，商品數量與小計顯示正確。
4. 進入結帳頁面後，訂單總額與購物車金額一致。
5. 送出訂單後，畫面顯示訂單成立結果。

測試情境用於描述需要驗證的使用者目標，不必包含所有操作細節；測試案例則必須提供足夠資訊，使人工執行者、Playwright 測試腳本與 AI Agent 對驗證範圍及成功條件產生一致理解。

一個可執行的測試案例，至少需要回答下列問題：

• 要驗證哪一項使用者目標？
• 測試從什麼系統狀態開始？
• 使用哪些帳號與測試資料？
• 需要執行哪些 UI 操作？
• 操作程序在哪個階段結束？
• 應依據哪些畫面、文字、網址或資料判定測試通過？
• 測試失敗時，是否能定位至特定操作階段？

若缺少這些條件，內容仍只是業務流程或操作程序的描述，尚不能直接視為可供 Playwright 執行的測試規格。

測試資料與前置條件是測試案例的必要組成

測試需求若只描述為：

加入商品並確認折扣。

這段描述沒有明確指定商品單價、購買數量、折扣門檻與預期金額。執行者只能自行補充缺少的條件，最後可能只確認畫面出現「折扣」文字，卻未實際驗證折扣金額與訂單總額是否計算正確。

較完整的測試資料（Test Data）可以定義為：

商品單價：NT$ 500
購買數量：2
折扣規則：消費滿 NT$ 1,000 享 9 折
　
預期小計：NT$ 1,000
預期折扣金額：NT$ 100
預期訂單總額：NT$ 900

除了測試資料，測試案例也必須明確定義前置條件（Precondition）。以前述折扣案例為例，執行測試前應確認：

• 測試帳號可以正常使用。
• 使用者已完成登入，或測試案例包含登入步驟。
• 購物車處於空白狀態。
• 指定商品存在、庫存充足且可正常購買。
• 對應的折扣規則已啟用。
• 前一次測試未留下訂單、購物車或暫存資料。

測試資料決定「使用哪些數值進行驗證」，前置條件則決定「測試從什麼系統狀態開始」。兩者若未明確界定，即使 Playwright 腳本語法正確，測試結果仍可能因資料或環境狀態不同而不穩定。

這類問題不應只透過固定等待、重試（Retry）或延長逾時時間（Timeout）加以掩蓋，而應先確認測試資料是否隔離，以及每次執行前後的系統狀態是否已正確建立與清理。

從業務流程中裁適 UI Smoke Test 範圍

冒煙測試（Smoke Test）不是業務流程的同義詞，而是從既有測試情境與測試案例中，選出少量具代表性且可快速執行的基準測試，用於確認系統最重要的功能與使用者操作路徑仍可正常運作。

以電子商務網站為例，購物主流程可整理為：

登入
→ 搜尋商品
→ 查看商品詳情
→ 加入購物車
→ 進入結帳頁面
→ 送出訂單
→ 確認訂單成立

規劃第一組 UI Smoke Test 時，不需要同時涵蓋：

• 登入密碼錯誤。
• 商品搜尋無結果。
• 輸入無效購買數量。
• 多種折扣規則組合。
• 商品庫存不足。
• 付款處理失敗。
• 訂單取消或退款。

這些情境可能同樣重要，但應依不同驗證目的，分別整理為其他測試案例。若將所有正常流程、例外條件與業務規則都納入同一支測試案例，測試範圍會逐漸擴張成龐大的端到端回歸流程，不僅執行時間增加，失敗原因也更難定位，因而失去 Smoke Test 快速檢查核心功能的作用。

從業務流程中裁適 UI Smoke Test 範圍時，可依下列條件評估：

1. 代表性：是否涵蓋系統最重要的使用者目標與核心操作路徑。
2. 可重複性：測試資料與前置狀態是否能在每次執行前穩定建立。
3. 可判定性：是否具備明確且可由程式自動驗證的預期結果。
4. 可定位性：測試失敗時，是否能快速判斷問題發生在哪一個操作階段。
5. 執行效率：是否能在合理時間內完成，並適合頻繁執行。

因此，UI Smoke Test 應視為測試套件（Test Suite）中一組高優先級的基準測試案例，而不是將完整業務流程直接縮寫成單一測試案例。

明確界定測試意圖，避免 AI Agent 自行推測

AI Agent 可以協助操作瀏覽器、產生測試腳本與分析失敗原因，但不應自行決定測試範圍與業務規則。

模糊要求：

請測試購物流程是否正常。

Agent 可能自行選擇商品、忽略購物車前置狀態，或只確認頁面可以切換，卻沒有驗證金額與訂單結果。

較合理的輸入應明確界定：

驗證目標：已登入使用者可以完成一次商品結帳。
　
前置條件：
- 使用固定測試帳號。
- 測試開始前購物車必須為空。
　
操作範圍：
- 搜尋指定關鍵字。
- 開啟第一筆符合條件的商品。
- 加入 2 件商品。
- 進入結帳頁並送出訂單。
　
驗證項目：
- 購物車數量為 2。
- 小計與預期計算一致。
- 結帳頁總額與購物車一致。
- 送出後顯示訂單成立訊息或訂單編號。
　
限制：
- 不修改產品功能。
- 不降低 Assertion 條件。
- 若實際畫面與描述不一致，先回報差異。

這種輸入讓 Agent 的責任集中在依據實際 UI 完成驗證，而不是替需求補寫規則。

Playwright CLI、Skill 與 Playwright Test 的基本分工

Playwright CLI、Playwright Skill 與 Playwright Test 位於不同層次。三者不是互相取代，而是形成一個由觀察、規範到正式測試的流程。

Playwright CLI
→ 讓 AI Agent 操作瀏覽器與觀察 UI 狀態
　
Playwright Skill
→ 規範 AI Agent 如何正確使用 Playwright CLI
　
Playwright Test
→ 將使用者操作流程整理為可重複執行的測試案例

Playwright CLI 適合用來開啟頁面、取得 snapshot、執行操作與保留 screenshot。基本操作流程可以表示為：

playwright-cli open <target-url>
playwright-cli snapshot
playwright-cli screenshot
playwright-cli close

CLI 可協助確認：

• 實際頁面有哪些可互動元素。
• 預期按鈕或欄位是否存在。
• 操作後畫面如何變化。
• Locator 應根據哪些實際資訊建立。

圖：Playwright CLI 操作並取得頁面狀態

需注意一次 CLI 操作不等於正式測試。它通常沒有完整 Test Case 定義，也不會自然形成可版本控管、可重複執行的回歸驗證。

Playwright Skill：約束 Agent 的操作與回報

Playwright Skill 不會增加新的瀏覽器 API，也不會取代 Playwright Test。它主要用來規範 Agent：

• 必須實際開啟頁面。
• 先取得頁面狀態，再決定操作方式。
• 回報實際執行步驟與觀察結果。
• 必要時保留 snapshot 或 screenshot。
• 畫面與需求不一致時，停止猜測並回報差異。

圖：AI Agent 依 Playwright Skill 執行頁面驗證並回報結果

Skill 的價值，是降低 Agent 未實際操作瀏覽器就直接推測 UI 狀態的風險。

Playwright Test：UI 自動化測試框架

Playwright Test 是 Playwright 提供的測試框架與測試執行器（Test Runner），用於撰寫、執行及管理可重複的 UI 自動化測試案例。

它主要負責：

• 組織與執行測試案例。
• 管理瀏覽器生命週期與測試隔離。
• 執行操作步驟與斷言。
• 產出測試結果、HTML Report、Trace 與 Screenshot。

相較於 Playwright CLI 主要用於操作與觀察瀏覽器，Playwright Test 則負責承載正式的測試腳本，並提供一致、可重複的測試執行與結果判定機制。

頁面快照、畫面截圖、HTML 測試報告與追蹤記錄

UI 測試不只需要執行操作，也需要留下可供核對的測試證據（Evidence）。不同類型的測試證據，適合用於判斷不同問題：

測試證據	主要用途
頁面快照（Snapshot）	確認頁面文字、結構與可互動元素
畫面截圖（Screenshot）	確認實際視覺狀態、版面配置與錯誤訊息
HTML 測試報告（HTML Report）	彙整測試通過、失敗、錯誤訊息與相關附件
追蹤記錄（Trace）	還原失敗前後的操作、文件物件模型（DOM）、網路請求與頁面狀態

圖：Playwright HTML 測試報告集中呈現測試結果

例如：

• 確認按鈕是否存在，可先檢查頁面快照。
• 判斷按鈕是否被其他元素遮蔽，需要查看畫面截圖。
• 確認哪一支測試案例執行失敗，可以從 HTML 測試報告中檢查。
• 分析點擊後未跳轉的原因，通常需要透過追蹤記錄還原操作過程。

測試證據的目的不是增加附件數量，而是讓測試結果能夠被判讀、重現與分類。

從一次性 UI 操作轉為可重複執行的測試

將業務流程轉換為 Playwright 測試，可以依下列順序進行：

1. 確認 Business Process 與主要業務活動。
2. 選定單一角色的 Operation Procedure。
3. 定義 Test Scenario、Test Suite 與 Test Case。
4. 固定測試資料、帳號與前置狀態。
5. 使用 Playwright CLI 或 Agent 操作實際頁面。
6. 根據 snapshot 與 screenshot 核對 UI 狀態。
7. 修正錯誤的流程假設與 Locator 判斷。
8. 將穩定操作整理為 Playwright Test。
9. 執行測試並檢查 HTML Report 或 Trace。
10. 保留為可重複執行的基準驗證。

這個順序比直接要求 Agent 生成完整測試更可靠。Agent 先接觸實際頁面，再根據已界定的測試意圖撰寫腳本，可以降低錯誤 Locator、模糊 Assertion 與錯誤流程假設。

常見問題

將完整業務流程寫成單一測試案例

跨角色、跨系統或跨狀態的業務流程應分段驗證。若將完整流程寫成單一測試案例，任何中間步驟失敗，都可能使後續驗證失去意義，也會增加問題定位的難度。

將測試情境視為測試案例

「使用者可以完成結帳」只描述測試情境（Test Scenario），尚未明確定義前置條件、測試資料、操作步驟與預期結果，因此不能直接作為可執行的測試案例（Test Case）。

為了讓測試通過而降低斷言要求

例如，原本應驗證精確的折扣金額與訂單總額，最後卻只確認頁面出現「結帳成功」。測試雖然通過，卻未實際保護重要的業務規則。

調整斷言（Assertion）時，應確認驗證條件是否仍符合原始測試意圖，而不是單純降低通過門檻。

依靠固定等待掩蓋狀態問題

大量使用固定秒數等待，通常表示測試沒有依據實際 UI 狀態進行同步，或測試資料與前置狀態不穩定。

應優先依據實際 UI 狀態進行非同步等待，例如等待具體元素、文字、網址或網路狀態符合預期，而不是使用固定秒數等待。

將一次性的 AI Agent 操作視為回歸測試

AI Agent 成功完成一次操作，只能證明該流程在當時的環境與資料狀態下可能可用，不能直接視為可重複執行的回歸測試（Regression Testing）。

若要形成正式驗證，仍需將操作流程整理為明確的測試案例，並使用 Playwright Test 撰寫成具備固定資料、操作步驟、斷言與執行結果的自動化測試腳本。

在初期一次納入過多測試情境

初期應先建立一組穩定且具代表性的主要流程測試，再逐步增加錯誤情境、邊界值與替代操作路徑。

相較於一次建構所有分支，這種漸進式作法更容易驗證測試設計、控制執行範圍及維持後續可維護性。

結語

Playwright UI 自動化測試的起點，不是直接使用瀏覽器操作介面，而是先將業務流程轉換為明確、可執行且可驗證的測試案例。

業務流程（Business Process）用於理解完整的作業脈絡；業務活動（Activity）與操作程序（Operation Procedure）則用於找出可由單一角色執行的操作範圍。測試情境（Test Scenario）描述需要驗證的使用者目標，測試套件（Test Suite）負責組織相關測試案例，測試案例（Test Case）則明確定義前置條件、測試資料、操作步驟與預期結果。UI 冒煙測試（UI Smoke Test）是從這些測試案例中選出的高優先級基準測試，而不是完整業務流程的替代名稱。

進入實際操作後，Playwright CLI 可用於操作瀏覽器並觀察頁面狀態；Playwright Skill 用於規範人工智慧代理（AI Agent）的操作方式與結果回報；Playwright Test 則是 Playwright 提供的測試框架與測試執行器，用於撰寫、執行及管理可重複的 UI 自動化測試。頁面快照（Snapshot）、畫面截圖（Screenshot）、HTML 測試報告（HTML Report）與追蹤記錄（Trace），則提供結果判定與失敗診斷所需的測試證據（Evidence）。

只有先界定流程層級、測試範圍與各項工具的責任，定位器（Locator）、使用者操作（User Actions）與斷言（Assertions），才能共同形成可執行、可觀察且可維護的 UI 自動化測試。

延伸閱讀

• Playwright CLI + Skills：https://github.com/microsoft/playwright-cli
• Playwright Test CLI：https://playwright.dev/docs/test-cli
• Playwright for VS Code：https://playwright.dev/docs/getting-started-vscode