Web 應用程式測試必須涵蓋的三種執行期錯誤
殘留狀態
彈出視窗關閉了，捲動鎖定卻沒解除。篩選條件留在完全不合理的地方繼續生效。
只有第二次互動才會出現，所以從乾淨狀態重現永遠抓不到。
畫面先繪製，資料後到
頁面已經畫出來，請求也回來了，畫面卻沒有重新繪製。
通常時有時無，所以能躲過程式碼審查。
第二位使用者
以開發者自己的登入狀態為基礎所建立的擁有權與可見性假設。
對做出這個功能的人來說，一切都正常。
能抓出大部分問題的檢查方式
同一個操作做兩次，用兩個不同的使用者身分，中間重新載入一次。光是這一個模式就同時打中上述三類問題，而它正是手動測試最容易略過的一步——因為第一次試的時候就成功了。
該驗證什麼
重新載入後仍然確認得到的東西。 一則成功訊息不能證明資料真的存下來了。把東西重新取回來看看。
不該存在的東西確實不存在。 刪除之後，那一列真的不見了。登出之後，資料真的看不到了。
換成別人時的行為。 第二個帳號看不到第一個帳號的紀錄。
本機開發如何銜接
Web 應用程式的開發，早在部署之前就已經在 localhost 上進行；只能對公開 URL 執行的檢查，來得太晚，改變不了你正在做的東西。跑前端測試時，CLI 可以透過通道連到跑在你自己機器上的應用程式，所以你還在開發的當下就能做這項檢查。詳細說明請見 CLI 儲存庫。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
不想在本機安裝的人，也可以在儀表板上完成同樣的事。
雙分頁測試
有一項手動檢查，值得在每次發布前做，回報遠高於成本，卻幾乎沒有人做：把應用程式開在兩個分頁裡。
在第一個分頁做點什麼，然後看第二個分頁。大多數 Web 應用程式在這裡都會出現某種不正常，而這些不正常很有參考價值。清單沒有即時更新，通常沒關係。但過期的操作居然成功了，還蓋掉比較新的資料，那就是真的 bug。工作階段在其中一個分頁更新 token 時把另一個分頁登出，那是真的 bug。樂觀更新之後永遠沒有回頭對齊實際狀態，那也是真的 bug。
這只要兩分鐘，不需要任何工具，而且剛好測到伺服器狀態、瀏覽器狀態與使用者預期彼此不一致的那條接縫。如果你只打算從這篇文章帶走一個習慣，就帶走這一個。
讓它持續執行
執行期的錯誤正是最容易一再出現的那種，因為造成它們的條件，很容易在不經意之間又被湊齊。
GitHub App 是你在 TestSprite 儀表板上設定的 webhook。它會監聽你的流程本來就會發出的部署事件，所以你的儲存庫完全不用改。
GitHub Actions 則是把這個步驟放進你自己的工作流程裡，從終端機完成設定。
TestSprite 如何實際操作執行中的應用程式
它會打開已部署的應用程式，像真人一樣使用；唯有如此，才看得到殘留狀態、資料比畫面晚到，以及第二位使用者的行為。測試案例以白話描述，並依據你的產品產生，驗證的是重新載入後仍能確認的結果，而不是前端畫出來的一則訊息。
第二位使用者的檢查本身就是正式的測試案例，而不是附帶的環境準備工作。這一點很重要，因為權限假設正是最容易流到客戶手上、也最不容易被功能開發者自己發現的一類錯誤。
之後每一次變更都會重跑這些檢查，讓曾經造成 bug 的那種三方狀態不一致，無法在分支合併後悄悄回來。
為什麼這些問題在程式碼審查時看不出來？
因為它們是伺服器狀態、瀏覽器狀態與操作歷程三者互動之下的性質，而 diff 這三樣一個都顯示不出來。
可以用單元測試來測嗎？
部分可以，但要寫大量 mock，而這些 mock 內建的假設，跟程式碼本身的假設是同一套。要打破這個僵局，只能實際跑真正的東西。
要怎麼穩定地測試第二位使用者？
在每個環境都準備第二個帳號，用兩個身分各跑一次同樣的流程。這是 Web 應用程式測試裡成本最低、效益最高的檢查。
那行動裝置瀏覽器呢？
可視區域的差異會帶出另一組版面與互動問題。如果你有行動裝置的流量，主要流程值得用行動裝置的尺寸再測一遍。
這些有多少可以在本機跑？
前端測試可以透過通道連到你機器上的應用程式。至於從外部連不到的後端目標，仍然需要一個對外開放的環境。