并行运行浏览器测试时，如何避免代理IP 会话与测试数据互相干扰

并发测试最难排查的情况，是结果通过了但用例实际共享了状态。浏览器上下文、服务端账号状态、代理会话和日志归属是不同隔离层，必须分别核对。本篇用并发矩阵、请求标记和分组负对照验证隔离，不把共享出口本身当成会话串扰证据。

并行测试为什么会出现会话串扰

• 数据串：A 用例写入的 cookie、localStorage 或登录态，出现在 B 用例的请求里。
• 出口串：B 用例的请求从 A 用例那条代理会话的出口 IP 发出，地区或身份标签随之错位。
• 记录串：埋点、日志或测试数据归属到错误的 run id、用例 id，事后无法回溯。

数据串和出口串会让断言"恰好通过"，最难发现；记录串通常先暴露，因为它不依赖业务逻辑。判定顺序建议是先看记录归属，再核对出口，最后才查数据本身。

如何把用例、浏览器上下文和代理会话分开

并发一提高，组合就会失控。用例、浏览器上下文和代理IP会话三个维度写进同一张矩阵，每个格子只允许一种合法组合——任意一格填了两种组合，就等于把串扰写进了测试。

每个测试用例应该绑定哪些资源

• 用例 × 浏览器上下文：通常为每个用例创建独立 context。storageState 文件是创建时载入的初始状态快照；多个 context 读取同一只读快照，不会因此自动共享之后的 Cookie 更新。避免并发写同一状态文件。
• 上下文 × 代理会话：一个上下文绑定一条会话，用例结束时释放，不跨用例借用。这是本套测试的约束，不是平台默认——连接池、持久化上下文和代理服务的粘性策略都可能打破它。
• 工作进程 × 出口：同一 worker 内允许轮换出口，但轮换点必须写进日志；验收时同时记录上下文 ID、会话 ID 与连接/出口变化，才能证明轮换没有落到别的用例上。

为什么只隔离浏览器上下文还不够

Playwright 的独立 BrowserContext 默认隔离本地 Cookie、缓存和存储状态；storageState 用于初始化上下文。代理既可按浏览器启动配置，也可在支持的 API 中按 context 配置。具体选项受 Playwright 版本及浏览器类型影响，应核对BrowserContext API并用最小脚本实测，记录每个 context 的代理分配及实际请求出口。

代理池回收错位会怎样影响下一条用例

上下文池和会话池回收节奏不同会增加错绑风险，但不代表编号必然错位。判定时用 run/case/context、供应商会话标识、分配时间和实际连接记录共同核对；相同出口 IP 可能是合法共享，不能单独作为错绑证据。

• 隔离层：浏览器上下文 ｜ 隔离手段：每用例独立 context；状态文件只作初始快照 ｜ 串扰证据：B 收到仅在 A 的 context 内写入的唯一 Cookie ｜ 判定：串扰
• 隔离层：代理会话 ｜ 隔离手段：按测试设计绑定并记录会话分配 ｜ 串扰证据：会话标识、分配记录和实际连接显示 B 被错绑到 A 的会话 ｜ 判定：串扰；仅出口 IP 相同不足以判定
• 隔离层：日志归属 ｜ 隔离手段：请求头携带 run / case 标记 ｜ 串扰证据：标记与用例不匹配 ｜ 判定：串扰
• 隔离层：服务端测试数据 ｜ 隔离手段：按 run id 前缀写入并清理 ｜ 串扰证据：查出其他 run 的记录 ｜ 判定：串扰

表里每一层都要留下可检索的证据，只有结论没有证据的条目，等于没隔离。

并发量、连接池和会话复用应在测试计划中分别记录；配置参数按实际代理产品文档确认。

如何给每条请求加上唯一标记

标记要同时满足唯一和可穿透。启动时生成 run id（时间戳加随机串），每个请求带 X-Test-Run: <run>-<case>-<seq>，回显服务把头原样写回日志。断言只认自己前缀的数据，见到别的前缀就直接判失败。

不可复用是关键：固定字符串会让上一轮的残留看起来像本轮通过。每轮重新生成 run id，测试数据按前缀写入，清理也按前缀删除，避免把并发中的其他轮次一起删掉。

如何关闭浏览器侧的隐式共享

显式配置容易对齐，隐式共享才是漏洞来源：

• 持久化上下文：launchPersistentContext 复用 user data 目录，cookie 与缓存天然共享，不适合并发用例。
• Service Worker 与 HTTP 缓存：同源资源被缓存后，表现为"没发请求却拿到了结果"。
• 共享 storageState 文件：多个 context 读取同一只读文件只会得到相同初始状态；风险在于并发写同一文件或共享服务端账号状态。
• DNS 与连接复用：进程内连接池复用，出口切换后仍可能走旧连接。

处理办法不是逐个打补丁，而是规定并发用例不落盘、不共享目录，把持久化留给串行场景。抓包或代理日志里若出现用例 B 复用了用例 A 的连接，先查上下文是否共用，再查连接池。

浏览器实例准备独立代理参数时，可对照代理设置帮助。

如何用一次可控串扰验证隔离是否生效

检测手段本身也要验证。在自建环境分开做三组负对照，每次只注入一种错误：①故意共用同一 context，在 A 写入唯一 Cookie，确认 B 能观察到该状态且隔离断言失败；②故意把 B 绑定到错误会话，用供应商会话标识和实际连接记录确认错绑断言失败；③故意篡改 case 标记，确认日志归属断言失败。共享初始 storageState 或出口 IP 相同，不保证发生 Cookie 交叉或标记错乱。对照结束后恢复配置，以新 run id 重跑。Playwright 的认证状态文档说明了状态快照的使用方式。

测试结束后如何清理并确认隔离结果

每轮收尾按固定顺序：关闭上下文与浏览器实例、释放代理会话、删除本轮前缀的测试数据、归档日志。顺序反了会出现"浏览器还开着、会话已释放"，重连请求落到新会话上。

验收看四件事：全量重跑结果与首次一致；日志中没有跨 run 标记；出口 IP 与矩阵记录逐条对得上；测试数据清理后计数归零。四项都过，才能说这一轮并发是干净的。

FAQ

Q：串扰只在并发高时出现，低并发是不是不用管？

A：低并发不代表不存在状态或账号共享问题。独立 context 可隔离本地状态；仍应检查共享服务端账号、并发写状态文件和实际复用 context 等风险。

Q：代理IP会话由池自动分配，还能做到一会话一上下文吗？

A：可以。把会话获取放在上下文创建处，随上下文销毁释放；池只负责供给，不负责跨用例复用。

Q：用回显服务判断出口，和看代理后台记录哪个更可靠？

A：两者互补。回显服务证明请求实际从哪里出去，后台记录证明会话被谁使用，对不上时先查会话分配环节。