為什麼 Web App 測試 MCP 連線勝過讀程式碼
靜態閱讀一個 Web 應用程式，只能知道程式碼想做什麼，卻看不出瀏覽器實際會怎麼處理它。多數使用者看得見的缺陷，都住在這兩者之間的落差裡；而當越來越多程式碼來自一個從未看過畫面實際渲染的 AI Agent，這道落差只會越拉越大。
程式碼審查抓不到的問題
殘留下來的狀態
彈出視窗關掉後留下捲動鎖定，篩選條件被帶進一個根本不合理的情境。
只有在第二次互動時才看得到，在 diff 裡永遠看不見。
資料還沒到就先渲染
頁面畫好了，請求也回來了，畫面卻沒有重新渲染。
實際操作應用程式就能穩定重現，否則幾乎看不出來。
第二個帳號
那些只在開發者自己的登入狀態下成立、換個人就不成立的擁有權與可見性假設。
本機開發
Web App 的開發工作，在任何東西被部署之前就已經在 localhost 上進行了；只能連到公開 URL 的檢查來得太晚，改變不了你正在做的東西。本機目標是支援的，所以你還在動手時就能用這項檢查，而不是等到部署之後。目前的運作細節請見 說明文件。
設定方式
MCP 伺服器與 CLI 是分開的套件，發佈名稱為 @testsprite/testsprite-mcp。你用儀表板取得的 API 金鑰把它加進編輯器的 MCP 設定，編輯器會以子行程的方式執行它。Claude Code、Cursor、Windsurf、VS Code、GitHub Copilot 與 Trae 都支援；實際設定方式因用戶端而異，詳見 MCP 安裝說明文件。
先涵蓋哪些流程
註冊、登出、登入。 生成出來的 Web App 最常見的全面失效。
建立一筆資料，然後重新整理頁面。 區分「畫面更新了」與「紀錄真的存在」。
以第二個帳號走一次主要流程。 抓出那些內建在開發者自己登入狀態裡的權限假設。
三種狀態的陷阱
Web App 特別的地方在於，同一個功能可以同時處在三種互相不一致的狀態，而大多數執行期的 bug 就是它們之間的歧異。
伺服器上有一筆紀錄。瀏覽器的記憶體裡有一份副本。而使用者心裡有一個以剛才看到的畫面建立起來的認知模型。一個刪除動作若移除了紀錄與記憶體中的副本，畫面上那一列卻還在，使用者就會確信刪除失敗了。反過來，一個只更新畫面、沒有更新伺服器的儲存動作，結果正好相反。
實際的後果是：只看其中一種狀態的檢查，證明不了什麼。動作之後馬上驗證畫面，測的是瀏覽器裡的那份副本；重新整理之後再驗證，測的是伺服器；把同一個動作做兩次，測的是第一次有沒有留下什麼。這三者加起來，就涵蓋了大部分真正會傳到使用者手上的問題，而且沒有一項需要讀程式碼。
接著，讓它在工作階段結束後依然有效
MCP 連線顧的是改動發生的那一刻。回歸測試則需要同樣的檢查持續執行，不管有沒有人坐在鍵盤前。
GitHub App 是一個在 TestSprite 儀表板裡設定的 webhook。它會監聽你的 pipeline 本來就會產生的部署事件，所以你的儲存庫完全不用改。
GitHub Actions 則把這個步驟放進你自己的 workflow，從終端機完成設定。目前的指令請見 CLI 儲存庫。
TestSprite 能檢查、而 diff 做不到的事
它會打開執行中的應用程式並實際操作，而這是看見上述三種失效的唯一方式。互動之後殘留的狀態、永遠追不上資料的渲染，以及換第二個帳號就不一樣的行為，在原始碼裡全都看不見，一用起來卻一目了然。
因為這條連線就位在 AI Agent 的循環裡，檢查是改動過程的一部分，而不是事後才補。AI Agent 會建立測試案例、執行、讀出落差、再迭代，而你看到的是結果，不是中間來回的過程。
最後你得到的，是一組每次改動都會重新驗證的流程；於是那個權限假設、那個過期的篩選條件，不會在發現它的那次工作階段結束後，又悄悄跑回來。
它需要我的原始碼嗎？
不需要。它透過介面操作執行中的應用程式並回報行為。你的 AI Agent 本來就有程式碼。
它可以測試本機的開發伺服器嗎？
前端測試可以，透過從你機器建立的通道。純後端的本機目標仍然需要一個可連線的 URL。
那些需要真實電子郵件或付款的流程呢？
用測試模式和專用帳號。任何會造成真實第三方副作用的流程，更適合當成刻意安排的人工檢查來處理。
一個 Web App 該有多少項檢查？
先從上面那三項開始，之後每遇到一個真正踩到的 bug 就加一項。跟著真實失效走的涵蓋率，勝過為了衝百分比而做的涵蓋率。
這跟 CLI 是同一回事嗎？
能力相同，入口不同。MCP 適合在編輯器裡進行的工作，CLI 適合腳本與 pipeline。