UI 效能測試工具的兩大家族
實驗室型、合成式
在受控條件下載入頁面並評分。
可重複執行、可互相比較。量測的是乾淨環境搭配乾淨資料的情況。
現場型、真實使用者
從實際的使用者工作階段收集時間數據。
誠實反映現實。但它告訴你的時候，已經有人先受害了。
夾在兩者之間的是什麼
實驗室工具跑在測試環境上，也就意味著資料量很小；現場工具看得到真實的資料量，卻要等到真實使用者已經受害之後才回報。於是一個在十筆資料下很快、在兩千筆資料下難以使用的畫面，會先通過實驗室，再出現在現場——這是最糟糕的順序。
要補上這個斷層，不需要新的工具類別，而是需要一個規模比照大型客戶、預先灌好資料的帳號，並在發布前用同一批流程對它實際跑過一遍。
在各家族中如何挑選
實驗室工具： 優先選擇會量測互動延遲、而不只是初次載入的工具。載入在每個工作階段只付出一次成本，互動卻時時刻刻都在發生。
現場工具： 確認能不能依帳號規模分群。把所有客戶平均起來，藏起來的正好就是那些正在受苦的客戶。
兩類皆然： 拿自己的歷史數據來比較，而不是比對一個絕對分數。從別處借來的門檻值，很少能在不同產品之間通用。
把現場資料分群，數字才有意義
真實使用者監控是兩大家族中比較誠實的一種，但只要看錯彙總方式，它就很容易變得毫無用處。
把所有使用者平均起來，等於把只有五十筆紀錄的客戶和有五萬筆紀錄的客戶混在一起，而後者才是全部的訊號所在。混合不同裝置、混合不同地區、把內部使用者和客戶混在一起，也都是同樣的問題。整體數字可以一路變好，同時你最大的那幾個帳號卻持續惡化——這正是會賠掉續約的失效模式。
請依照你的產品真正會產生差異的維度來分群；對多數商用軟體而言，那是帳號規模，而不是裝置或網路。如果工具沒辦法這樣分群，它回報的數字量測的就不是你在意的東西。
沒有人列出來的前提條件
一個因為請求默默失敗而瞬間就渲染完成的畫面，在實驗室工具裡會拿到漂亮的分數。正確性是所有效能數字底下的那條底線，而驗證正確性的成本，比上述任何一種工具都低。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想在本機安裝任何東西，TestSprite 儀表板裡也有同樣的設定方式。CLI 其餘的功能都收錄在 CLI 儲存庫。
各自該在哪裡執行
實驗室工具放在管線裡，每一個 pull request 都跑一次，並和你的基準線比較；現場監控則是全天候開著。功能驗證要針對資料量貼近真實的帳號執行，同樣每次變更都跑，因為那正是另外兩者留下的斷層。
觸發方式比機制更重要。把它掛在你的部署事件上，就代表每一次變更都會被檢查，不需要任何人特地決定要跑； GitHub App 可以從儀表板做到這件事，而一個 GitHub Actions 步驟則是在你的工作流程內部完成同一件事。
TestSprite 落在實驗室與現場之間的哪個位置
就在兩者共同留下的斷層裡：在發布前，針對擁有貼近真實資料的環境實際執行真實流程。測試覆蓋是從你的產品產生出來的，而且每次變更都會執行，所以一個在十筆資料下正常、在兩千筆資料下壞掉的畫面，是靠行為被抓出來，而不是靠某個百分位數字。
它同時補上了兩個家族都不會檢查的前提條件。一個因為抓取資料失敗而瞬間渲染完成的頁面，是又快又錯，而實驗室分數不會告訴你這件事。
實驗室工具繼續量測載入與互動的時間，現場監控繼續回報使用者實際經歷了什麼。這裡的好處是：那種只有在你最大客戶的資料量下才會出現的失效，會在那位客戶發現之前先被找出來。
TestSprite 屬於這個類別嗎？
不屬於。它驗證的是流程行為是否正確，而這是任何效能數字要有意義的前提。
實驗室工具和現場工具都需要嗎？
需要。實驗室工具在發布前給你可重複的訊號，現場工具告訴你實際發生了什麼事。單靠其中一種都不夠。
那合成監控呢？
那是依排程對正式環境執行的實驗室工具。用來監控可用性很有用，但它跑的依然只是那個帳號剛好擁有的那些資料。
預先灌入資料的測試帳號該做到多大？
和你最大的真實客戶一樣大。只要再小一點，你測的就是一個在正式環境中並不存在的情境。
效能分數應該用來擋下合併嗎？
如果是相對於自家基準線的大幅退步，應該擋。如果是某個絕對分數門檻，通常不該，因為那追蹤的是跑分標準，而不是你的產品。