設計視角
把需求、介面狀態與操作結果轉譯為使用者可理解的驗證條件。
Case 05 · UI Automation
將重複的 UI 驗收，
轉為可持續執行的
產品品質流程。
以 Playwright + Python 建立 UI 自動化測試，將頁面導覽、語言切換與後台管理流程整理成可重複執行的 Regression Testing。
PLATFORM MANAGER總覽
全部模型 今天
使用者Token 數
1
2
3
pytest00:21.84
$ python -m pytest -v
22 passed in 21.84s
公開說明
為保護內部資訊，產品介面以重製示意呈現；測試編號、技術架構與執行結果來自實際測試文件。
00 · Overview
從設計交付後的人工檢查，延伸到可以反覆驗證的產品流程。
功能持續迭代後，每次修改都要重新確認頁面顯示、操作流程與互動結果。我將這些有明確步驟與預期結果的工作整理成 Test Case，再交由瀏覽器自動執行。
設計不只停在 Figma；產品上線後的實際呈現與互動，也需要能被持續驗證。
工程方法
使用 Page Object、共用流程與語意化 Locator，降低測試重複與維護成本。
01 · Problem
問題不是「有沒有測」，而是每次改版都要從頭重做同一輪確認。
重複的人工作業
側邊導覽、語言切換與後台功能，每次修改後都需要逐頁重新操作確認。
回歸問題容易遺漏
人工驗收依賴記憶與當下注意力，功能增加後更難維持固定範圍。
設計品質缺少持續驗證
Figma 能定義預期，但正式產品的文字、狀態與互動仍需要在瀏覽器中確認。
測試經驗沒有被保存
若沒有 Test Case 與問題筆記，同樣的定位、登入或元件問題會重複處理。
02 · My Decision
先建立可維護、低風險的唯讀測試，再逐步擴充資料異動流程。
零散操作 vs. 正式 Test Case
判斷：只有自動操作腳本仍難以確認範圍與預期結果。
直接寫 Locator vs. Page Object Model
判斷：若每個測試都重寫元素定位，介面一改就要大量同步修改。
完整 CRUD vs. 唯讀驗證優先
判斷：共用測試站尚未準備專用資料，新增或刪除可能影響其他人。
03 · Test System
把操作、頁面與文件拆開，讓測試可以讀、可以改，也可以延伸。
測試不是一次性的錄製結果。我採用 Page Object Model，將測試意圖、頁面操作與共用環境分開管理。
Test Case
描述要驗證什麼與預期結果。
Page Object
集中管理頁面元素與操作。
Playwright
模擬使用者操作 Chromium。
Assertion
比對實際狀態與預期結果。
test_platform_manager.py
def test_interface_language_can_be_switched(page):
platform = PlatformManagerPage(page)
platform.goto()
platform.switch_language(
current_language="繁體中文",
target_language="English",
)
platform.expect_navigation_label(
"User Management"
)
LOCATOR PRINCIPLES
優先使用接近使用者理解方式的元素特徵。
- role 與 accessible name
- label、heading、placeholder
- 限定容器，避免同名元素衝突
- 過長且依賴版面的 CSS selector
04 · Test Evidence
從 9 項主要導覽開始，逐步擴充到頁面內容與互動狀態。
TC-001—003 Pass
網站連線與平台入口
3 tests
TC-004—011 Pass
9 項側邊導覽
8 tests
TC-012—015 Pass
總覽與區塊收合
4 tests
TC-016 Pass
繁中／英文切換
1 test
TC-017—019 Pass
使用者管理唯讀流程
3 tests
TC-020—022 Pass
群組管理唯讀流程
3 tests
ACTUAL DOCUMENT · TEST_CASES.MD
測試範圍、預期結果與維護狀態同步文件化。
每個案例都有固定編號、功能範圍、測試項目、預期結果與備註。文件不只記錄「有跑過」，也說明哪些操作刻意不執行，以及原因。
PLAYWRIGHT_NOTES.md另外保存 Locator、登入狀態與錄製問題，作為下一個專案可重用的基礎。
IDTestResult
TC-016繁中／英文切換Pass
TC-018新增使用者 DialogPass
TC-021新增群組頁面Pass
TC-022群組功能選單Pass
22 passedin 21.84 seconds
05 · Outcome
先建立一套可以反覆執行的基礎，讓每次改版都有一致的確認範圍。
以下為 2026/08/28 的階段成果，測試數量會隨後續管理頁與測試資料持續更新。
測試案例
涵蓋連線、導覽、總覽、語言與兩項後台管理流程。
全部通過
最近一次完整執行沒有失敗或略過項目。
完整回歸時間
可在每次產品修改後快速重新確認主要操作。
資料異動
現階段採唯讀策略，避免測試影響共用環境資料。
Before
依照記憶逐頁操作與檢查
Now固定 Test Case＋一行指令執行完整回歸
06 · Reflection
UI Automation 不是取代人的判斷，而是把重複確認交給工具。
這次實作讓我更清楚地把「設計預期」寫成可被驗證的條件。Page Object 與測試文件也讓經驗不只存在個人操作裡，而是能被維護與延伸。
目前仍以唯讀測試為主，適合確認頁面與互動是否正常；真正涉及新增、修改與刪除的流程，還需要專用測試資料與更清楚的環境隔離。