讀完這一章，你會知道如何把「看起來可以用」變成「有證據證明可以用」。你會學會在 Lovable 裡選擇 Browser testing（瀏覽器測試）、Frontend tests（前端測試）、Direct edge function calls（直接呼叫 Edge Function）和 Edge tests（Edge 自動化測試），並把它們放進真實產品流程：登入、dashboard（儀表板）、RLS（Row Level Security，列層級安全）、Paddle checkout（結帳）、Resend email、AI summary 和外部 API。
這章的重點不是建立一個龐大的測試金字塔。重點是每次改動後，你知道該用哪一種驗證方法，得到什麼證據，避免用錯工具測錯層。
AI agent 很擅長快速產生功能，也很擅長根據錯誤訊息修正程式。但這不代表結果一定正確。
你需要把問題從：
Lovable 說它做好了
提升成：
我有驗證證據，知道它在指定情境下真的運作
前面幾章的 LaunchNote 已經不是簡單頁面。它有：
任何一個環節壞掉，都可能讓使用者無法登入、看不到資料、被錯誤收費、收不到信、或看到不該看的資料。
測試與驗證，是把 Lovable 從 prototype（原型）工作流推向 production（正式上線）工作流的核心能力。
不要一開始就說：
測試我的應用程式。
這太模糊。測試前先問：
我要證明哪一件事？
這件事發生在哪一層？
失敗時會造成什麼風險？
需要一次性驗證，還是長期回歸保護？
Lovable 的 testing 文件可以用這個簡化判斷：
使用者看得到的流程 -> Browser Testing
使用者介面規則要長期穩定 -> Frontend Tests
後端函式要快速隔離 -> 直接呼叫 Edge Function
後端商業規則要防回歸 -> Edge Tests
你不需要每次都跑所有測試。你要讓測試方法對準風險。
圖 13-1：驗證工具要依問題層級選擇：使用者流程用 Browser testing、UI regression 用 Frontend tests、後端邏輯先 direct call 再補 Edge tests。
圖 13-2：Browser testing 操作目前 project preview，可點擊、填表、切頁並收集 screenshots、console 與 network 證據。
Browser testing（瀏覽器測試）讓 Lovable 在真實 browser 裡操作 app。它可以 click（點擊）、fill form（填表）、navigate（導覽）、submit（送出）、capture screenshots（截圖），也可以查看 console logs（主控台紀錄）和 network requests（網路請求），並測試不同螢幕尺寸。
適合：
缺點是比較慢，也可能卡在複雜互動，例如 canvas、drag-and-drop、custom upload widget 或 icon-only buttons。
Frontend tests（前端測試） 用 Vitest、React Testing Library、jsdom 驗證 UI（使用者介面）行為。它不是操作真實 browser，而是在 simulated browser environment 裡快速跑 assertion。
適合：
如果某個 UI（使用者介面）規則很明確，而且未來不該壞掉，就應該加 frontend test（前端測試）。
Direct edge function calls（直接呼叫 Edge Function） 讓 Lovable 直接呼叫 edge function，傳入指定 input，檢查 response。這能把 backend（後端）issue 從 UI（使用者介面）裡拆出來。
適合：
它是 debugging 和快速驗證工具，不一定是長期 regression test。
Edge tests（Edge 自動化測試） 用 Deno built-in test runner 和 TypeScript，針對 edge function 寫自動化測試。
適合：
直接呼叫 edge function 是「快速確認」。Edge tests（Edge 自動化測試） 是「長期保護」。
開始本章前，請先準備：
Lovable browser testing 文件提醒：如果 app 使用 authentication，browser testing 會使用你目前在 preview（預覽） 裡登入的同一個 app user。你要明確說哪些區域不要點、哪些 action 不要真的觸發。
另外，文件也提醒：不要在同一個提示詞裡要求「做一個大變更並測試」。比較安全的流程是：
先建置
-> 再用後續提示詞測試
-> 根據測試結果修正
-> 必要時加自動化測試
對 LaunchNote，我們先建立測試矩陣：
功能 最適合的驗證方式
公開更新日誌 Browser Testing
行動版價格方案頁 Browser Testing
登入表單驗證 Frontend Tests + Browser Testing
帳務橫幅狀態 Frontend Tests
Paddle 結帳流程 Browser Testing 搭配測試模式
訂閱權益判斷 Edge Tests + Browser Testing
AI 摘要產生 直接呼叫 Edge Function + Edge Test
Resend 信件發送 直接呼叫 Edge Function + 紀錄
RLS 存取規則 Browser Testing + 資料庫／安全檢查
儀表板篩選器 Frontend Tests
你可以請 Lovable 先產生這份矩陣：
請為 LaunchNote 建立驗證矩陣。
功能：
- 公開更新日誌。
- 登入與註冊。
- 儀表板項目管理。
- 依角色控管存取。
- Paddle 結帳與訂閱狀態。
- 帳務橫幅。
- Resend 信件工作流程。
- AI 摘要產生。
- 行動版價格方案頁。
針對每個功能，請建議：
- 應使用 Browser Testing、Frontend Test、直接呼叫 Edge Function、Edge Test，或多種方式組合。
- 需要哪些證據才能證明它可用。
- 需要哪些資料或測試帳號。
- 測試時哪些按鈕、付款、通知或外部動作不應該被點擊或觸發。
先不要執行測試。
這一步會防止你用「測一下」這種模糊指令浪費時間。
Browser testing（瀏覽器測試） 最適合驗證使用者真的會走的流程。
例如 LaunchNote 的 signup flow：
請用 Browser Testing 驗證註冊與第一個專案流程。
測試步驟：
1. 開啟公開首頁。
2. 點擊「免費開始使用」。
3. 建立新的測試帳號。
4. 確認使用者進入儀表板。
5. 建立名為「Browser Test Project」的新專案。
6. 建立一筆更新日誌草稿。
7. 確認草稿出現在儀表板。
8. 確認草稿不會出現在公開更新日誌頁面。
請在關鍵步驟截圖。
請回報主控台錯誤、網路失敗或非預期重新導向。
這次不要測試付款。
好的 Browser testing（瀏覽器測試）提示詞要包含：
不要只說：
驗證註冊功能可以正常運作。
這會讓 agent 猜流程。
很多 Lovable app 在 desktop 看起來完整，但 mobile 有問題：
Mobile 測試提示詞：
請用 Browser Testing 驗證 LaunchNote 價格方案頁的行動版和桌面版。
檢查：
- 價格方案卡片容易閱讀。
- Pro 和團隊版的行動呼籲清楚可見。
- 方案比較表在行動版不會溢出。
- 帳務週期切換按鈕可以使用。
- Paddle 測試模式橫幅不會遮住重要控制項。
- 頁尾的隱私權政策、服務條款和退款政策連結清楚可見。
測試畫面尺寸：
- 行動裝置。
- 平板電腦。
- 桌面裝置。
請回報截圖和所有版面問題。
不要啟動結帳流程。
注意最後一句。如果你只是測 layout，不要讓 browser testing 真的進 checkout（結帳）。
Browser testing（瀏覽器測試） 能告訴你流程現在能不能走。Frontend tests（前端測試） 能保護特定 UI（使用者介面）規則不再壞掉。
例如 billing banner：
請為 BillingBanner 撰寫前端測試。
規則：
- active 顯示「你的 Pro 方案已啟用」。
- trialing 顯示試用結束日期。
- past_due 顯示付款警告和「更新付款方式」行動呼籲。
- canceled 且 current_period_end 尚未到期時，顯示存取權限保留至該日期。
- expired 顯示付費功能已鎖定。
- 免費使用者看到升級行動呼籲。
請使用 Vitest 和 React Testing Library。
請執行測試並回報失敗項目。
除非測試發現錯誤，否則不要修改帳務邏輯。
這種 test 很值得寫，因為 billing 狀態容易在後續改版時被弄壞。
Frontend tests（前端測試） 特別適合：
如果 AI summary 按鈕壞了，問題可能在 UI（使用者介面）、network、edge function、AI connector、credits、rate limit、database write。直接從 UI（使用者介面）猜會很慢。
先直接呼叫 function：
請直接呼叫 AI 摘要 Edge Function。
輸入：
- title：「全新團隊帳務儀表板」
- content：「我們新增了帳務儀表板，管理員可以查看訂閱狀態、開啟客戶入口網站，以及查看付款失敗警告。」
- language：「繁體中文」
預期結果：
- 請回傳精簡繁體中文摘要。
- 不要發布項目。
- 除非函式原本設計為儲存草稿，否則不要修改資料庫。
回報：
- 請求酬載
- 回應狀態
- 回應內容
- 所有後端紀錄或錯誤
這種 direct call 可以快速回答：
如果 direct call 成功，但 UI（使用者介面）按鈕失敗，問題就更可能在 frontend（前端）wiring 或 state handling。
付款和權益邏輯不適合只靠手測。
例如：
請為訂閱權益邏輯撰寫 Edge Tests。
案例：
- active Pro 開放 Pro 功能。
- trialing Pro 開放 Pro 功能。
- past_due Pro 保留讀取權限，但顯示帳務警告。
- canceled Pro 保留存取權限直到 current_period_end。
- canceled 且已超過 current_period_end 時變成 expired。
- 免費使用者不能使用自訂網域。
- 團隊版開放 Slack 通知和團隊成員功能。
請使用 Deno test runner。
測試應聚焦於權益計算，不要測使用者介面顯示。
請執行測試並回報結果。
這種 test 的價值很高，因為 entitlement（權益）bug 可能直接影響收入或使用者權益。
Paddle checkout（結帳） 一定要在 test mode 先跑完整生命週期。
Browser testing（瀏覽器測試） 提示詞：
請用 Browser Testing 驗證 LaunchNote 的 Paddle 測試結帳流程。
前置條件：
- 只使用付款測試模式。
- 請使用測試使用者帳號。
- 不要使用真實信用卡資料。
流程：
1. 以測試使用者身分登入。
2. 開啟價格方案頁。
3. 選擇 Pro 月繳方案。
4. 使用可成功付款的測試卡完成結帳。
5. 回到儀表板。
6. 驗證訂閱狀態為 active 或同等狀態。
7. 驗證 Pro 專屬功能已解鎖。
8. 開啟帳務頁面。
9. 驗證「管理訂閱」按鈕清楚可見。
回報：
- 截圖。
- 主控台錯誤。
- 網路失敗。
- 應用程式中觀察到的訂閱狀態。
不要把金流測試和真實 live mode 混在一起。測試完成後，還要檢查 Payments tab 的 transaction 和 subscription data。
權限測試不能只用一個帳號。
請 Lovable 建立或使用測試資料：
請為 LaunchNote 建立權限驗證計畫。
角色：
- 公開訪客。
- 使用者 A：專案 A 的管理員。
- 使用者 B：專案 B 的編輯者。
- 使用者 C：沒有專案成員關係的已驗證使用者。
資料：
- 專案 A 有一筆草稿和一筆已發布項目。
- 專案 B 有一筆草稿和一筆已發布項目。
請驗證：
- 公開訪客只能讀取已發布項目。
- 公開訪客不能存取儀表板。
- 使用者 A 可以讀取和編輯專案 A 的草稿。
- 使用者 A 不能讀取專案 B 的草稿。
- 使用者 B 可以編輯專案 B 的草稿，但不能管理成員。
- 使用者 C 不能存取任何專案儀表板。
請建議哪些檢查應使用 Browser Testing，哪些應使用後端或資料庫驗證。
暫時不要修改 Policy。
權限測試常常需要 browser testing、database inspection、RLS（Row Level Security，列層級安全） policy review 和 security scan 搭配。第 15 章會完整處理安全治理；第 13 章先建立驗證習慣。
測試失敗是好事，因為它提供證據。不要看到 failure 就直接要求 Lovable 大改。
先要求分析：
修改前，請先分析失敗的測試執行結果。
請摘要：
- 哪個步驟失敗。
- 預期行為。
- 實際行為。
- 相關主控台紀錄。
- 相關網路請求。
- 問題看起來屬於使用者介面、後端、身分驗證、資料，或測試互動限制。
- 最小且安全的修正方式。
先不要編輯程式碼。
這會避免 agent 因為一個模糊 failure 改太多。
圖 13-3：Details Timeline 保留 agent 實際讀取與操作的軌跡；驗收時應搭配測試輸出、截圖與 logs，而不是只相信完成訊息。
你可以把每次功能改動分成：
規劃
-> 建置
-> 驗證
-> 必要時新增回歸測試
-> 審查
-> 發布
驗證不是最後才做。它應該緊跟在 build 後面。
實務節奏：
請為這個功能建立驗證矩陣。
功能：
[描述功能]
請建議：
- 使用 Browser Testing、Frontend Tests、直接呼叫 Edge Function、Edge Tests，或多種方式組合。
- 需要哪些證據證明功能可以運作。
- 所需測試資料。
- 所需測試帳號。
- 測試期間應避免哪些操作。
- 是否應新增回歸測試。
先不要執行測試。
為什麼有效：
請用 Browser Testing 驗證這個使用者流程。
流程：
1. [步驟一]
2. [步驟二]
3. [步驟三]
預期結果：
- [可觀察的預期結果]
收集：
- 截圖。
- 主控台錯誤。
- 網路失敗。
- 非預期重新導向。
不要：
- [應避免的操作]
為什麼有效：
請為 [元件或使用者介面行為] 撰寫前端測試。
要驗證的規則：
- [規則一]
- [規則二]
- [規則三]
請使用 Vitest 和 React Testing Library。
請執行測試。
回報：
- 新增的測試。
- 通過和失敗的案例。
- 任何必要的程式碼變更。
為什麼有效：
直接呼叫這個 Edge Function：
[函式名稱]
輸入：
[JSON 或結構化輸入]
預期結果：
- [預期狀態]
- [預期回應結構]
- [預期副作用，如有]
回報：
- 請求酬載。
- 回應狀態。
- 回應內容。
- 紀錄或錯誤。
先不要修改程式碼。
為什麼有效：
請為 [後端規則] 撰寫 Edge Tests。
案例：
- [案例一]
- [案例二]
- [案例三]
請使用 Deno test runner。
測試應聚焦於後端邏輯。
請執行測試並回報結果。
不要修改無關函式。
為什麼有效：
替 LaunchNote 建立一套驗證流程。
使用 Pattern 1，針對 billing、auth（驗證）、AI summary 和 public changelog 產生驗證矩陣。
預期結果：
使用 Pattern 2 測 signup、create draft、public page 不顯示 draft。
預期結果：
使用 Pattern 3 替 BillingBanner 寫 tests。
預期結果：
使用 Pattern 4 direct call AI summary function。若 function 規則穩定，再使用 Pattern 5 寫 edge tests（Edge 自動化測試）。
預期結果：
完成訊息不是驗證。你需要 screenshots、test output、logs、network observation 或 edge function response。
Browser testing（瀏覽器測試） 很有價值，但慢，且不適合所有情境。UI（使用者介面）規則用 frontend tests（前端測試），backend（後端）logic 用 direct calls 或 edge tests（Edge 自動化測試）。
先 build，再 follow-up 測試。大變更和 browser testing 放在同一 提示詞，失敗時比較難定位，也可能丟失測試步驟中的工作。
測 payment、email、delete、publish、notify 這些功能時，要明確說哪些 action 不要觸發。
Production（正式上線） bug 常在 failure path。要測 failed payment、invalid input、permission denied、AI rate limit、email failure。
如果一個 bug 很重要，修完後要加 frontend test（前端測試） 或 edge test，否則它可能在下次改版回來。
自動化測試不是每個 prototype（原型）的第一天都需要。
可以先不加 automated tests，如果：
但這些情境應該加測試：
規則越穩、風險越高，越應該寫測試。
讀完本章後，建議用自己的專案情境繼續追問 Lovable 或本書作者：
嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。我熱衷於研究 AI Agent、n8n 自動化工作流及全端開發架構，致力於將 AI 技術轉化為實際的生產力工具。
如果你喜歡這篇文章，歡迎透過以下方式與我交流，獲取更多技術實戰內容：
📚 技術著作：《實用的 Gemini API 開發點子書》，帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。
📝 技術部落格：歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。
🎤 技術講座：我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。曾於 2026 年 6 月 26 日的 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。
如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊與我聯繫、洽談講座合作！
🎁 免費送 Lovable 額度給讀者！
我每個月會開放 10 個名額，每人 50 點 Lovable 額度，讓大家實際動手打造自己的網站或 App。
參加方式：
確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！
iThome鐵人賽
看影片追技術