Playwright 1.62 加入 AbortSignal 與隔離重試：代理測試如何安全停止與恢復
代理測試的失敗方式與一般介面測試不同：頁面本身可能正常，但某個出口極慢；隧道可能已建立，卻遲遲收不到回應正文；驗證重試也可能在結果早已失去商業價值後繼續占用 worker。Playwright 1.62 帶來兩項高度相關的控制能力：多數操作及 Web-first 斷言可接收 AbortSignal，測試設定新增 isolated 重試策略。
它們不會讓代理本身變得可靠，但能讓失敗邊界更清楚。團隊可在商業時限到達時主動終止工作，區分「被取消」與「網路故障」，並避免大量失敗工作階段與健康的首輪測試爭用資源。
這次更新帶來什麼
多數動作、導覽、等待及 Web-first 斷言現在可接收 AbortSignal。信號觸發後，操作可在自身逾時之前取消；除非明確關閉，原有預設逾時仍然有效。
testConfig.retryStrategy 新增 isolated 模式。啟用後，失敗案例會在主測試輪次結束後，由單一 worker 逐一重試。預設策略仍是在 worker 可用時立即重試。
對代理驗證而言，兩者處理不同層次：
AbortSignal限制單一操作或完整商業流程的最長有效生命期；- 隔離重試決定失敗案例在何時、何種資源條件下再次執行。
為什麼一般逾時仍不夠
一個測試通常同時存在連線、導覽、斷言、案例及整批工作等多個時間預算。如果每一層只認識自己的計時器，請求即使技術上仍未逾時，也可能早已超過商業允許的時間窗。
例如，區域可用性檢查必須在 20 秒內完成。導覽最多等待 15 秒，後續斷言又可等待 10 秒。沒有共享取消信號時，整個流程可能耗時 25 秒，而它在第 20 秒就已失去商業價值。
import { test, expect } from '@playwright/test';
test('區域路線符合購買流程時限', async ({ page }) => {
const controller = new AbortController();
const deadline = setTimeout(() => controller.abort('workflow deadline'), 20_000);
try {
await page.goto('https://en.98ip.com/', {
waitUntil: 'domcontentloaded',
timeout: 15_000,
signal: controller.signal,
});
await expect(page.locator('body')).toBeVisible({
timeout: 5_000,
signal: controller.signal,
});
} finally {
clearTimeout(deadline);
}
});只測試你有權存取的目標。代理帳號應放在環境變數或祕密管理系統中，不得寫入程式碼、trace、截圖或測試名稱。
「取消」應成為獨立結果
不要把所有中止操作都合併為籠統的「代理錯誤」。至少記錄：
- 操作名稱與路線標籤；
- 計畫截止時間與實際耗時；
- 由商業預算、人工操作或父工作清理觸發；
- 不含憑證的代理工作階段識別碼；
- 可取得時記錄出口區域與網路協定族；
- 最後完成階段：隧道、TLS、回應標頭、本文或斷言；
- 重試輪次及最終處置。
這對採購決策非常重要。持續無法滿足 20 秒預算的路線、驗證被拒的路線，以及收到目標站政策回應的路線，需要採取完全不同的措施。
隔離重試何時有價值
立即重試適合偶發瞬時故障，但也可能放大問題。若多個 worker 同時遇到慢出口池，立即重試會在資源已異常時增加流量、消耗新工作階段、扭曲成功率並提高成本。
import { defineConfig } from '@playwright/test';
export default defineConfig({
retries: 1,
retryStrategy: 'isolated',
workers: 6,
});首輪反映正常並行條件；隔離輪次則判斷移除資源爭用後故障是否仍存在。若六個 worker 時失敗、單一 worker 時通過，更像並行、配額或共享資源問題；若隔離後仍失敗，則更可能與路線、目標相容性、設定或確定性測試缺陷有關。
代理測試套件的落地步驟
1. 先定義商業截止時間
為登入、搜尋、結帳、資料蒐集及廣告驗證分別設定「仍有價值」的最長時間，不要直接採用最大的技術逾時。
2. 保留分層逾時
AbortSignal 應補充而非取代連線、導覽、斷言及案例逾時。除非另有強制截止機制，否則不要把預設逾時設為零。
3. 使用結構化取消原因
採用 workflow_deadline、quota_guard、operator_cancelled 等穩定原因碼，不要只依賴例外文字。
4. 分開統計首輪與重試
分別報告首輪成功率、重試恢復率及最終成功率。最終 99% 成功率可能掩蓋昂貴的 15% 重試率。
5. 比較立即重試與隔離重試
保持目標、並行與工作階段規則一致，比較恢復率、延遲、出口重用、傳輸位元組及每個可用結果成本。
6. 按路線小批量上線
先選少量區域與流程，確認取消操作能關閉頁面、釋放工作階段，且不留下背景請求。
採購與維運檢查清單
- 每個關鍵流程是否都有明確商業時限？
- 能否區分主動取消與代理連線失敗？
- 是否分別報告首輪和重試結果？
- 重試時是刻意保留工作階段，還是刻意更換出口？
- 是否按帳號、區域及目標執行並行上限？
- 被取消請求是否納入頻寬及成本？
- 能否在隔離 worker 中保持其他變數不變地複測？
- trace、截圖、日誌及範例中是否完全沒有憑證？
常見錯誤
把取消當成資源清理。 頁面、context、資料流及計時器仍應在 finally 中釋放。
對所有取消自動重試。 超過商業時限的流程可能不值得重試。
同時改變出口與並行。 這會讓恢復原因無法判斷。
只報告最終成功率。 採購方還需要首輪成功率、延遲分布、重試恢復率及單位有效結果成本。
合規說明
僅在獲得授權的系統與資料範圍內進行代理測試，並遵守目標站條款、速率限制、隱私義務及區域規則。取消與重試控制應減少無意義流量，而非用來繞過存取控制。
FAQ
AbortSignal 會取代 Playwright 逾時嗎？
不會。它增加一條獨立取消路徑。仍需保留合理的操作和案例逾時，才能準確診斷。
所有代理失敗都應隔離重試嗎？
不應該。只重試瞬時且冪等的工作。驗證失敗、政策拒絕、無效設定及主動取消通常應先檢查。
隔離重試失敗就能證明是代理問題嗎？
不能。目標站、測試邏輯、DNS、TLS 及工作階段策略仍可能導致失敗。
採購時應比較哪些指標？
在同一矩陣下比較首輪成功率、p50/p95 延遲、意外輪換、重試恢復率、取消率、傳輸位元組及每個有效流程成本。
