AI Agent 已经开始接管一部分 Web 自动化测试工作。
过去，测试工程师需要自己编写登录脚本、维护浏览器环境。现在，Agent 可以根据测试需求操作页面，连续执行多条测试任务，甚至同时运行不同账号的业务流程。
但并发任务一多，问题也出现了。
管理员刚完成订单审批，普通用户的测试页面却显示了管理员信息；上一条用例退出登录，下一条用例仍然携带旧的身份凭证。
有些团队已经使用 Playwright CLI 的 Storage State 保存登录状态，也创建了不同的浏览器会话，测试过程中依然会发生数据冲突。
问题到底出在哪里？
目录
一、并行测试为什么容易串号
二、浏览器会话隔离了哪些状态
三、Storage State 如何复用登录身份
四、多角色并行测试如何避免数据污染
五、状态管理如何在项目中落地
六、AI Agent 对测试隔离提出了什么新要求
一、并行测试串号，往往从环境复用开始
传统自动化测试通常有明确的执行边界：启动浏览器、执行用例、关闭浏览器。
Agent 的执行方式更加灵活。一个 Agent 可能连续处理多个任务，多个 Agent 也可能同时访问同一个测试环境。
如果浏览器状态没有管理好，就可能产生三类问题：
Cookie、LocalStorage 残留，导致账号身份混乱。
多条用例使用相同账号，互相修改用户状态。
不同任务操作同一批订单，导致断言结果不稳定。
其中，前两类经常被误认为是脚本定位或等待时间的问题。
浏览器隔离解决客户端状态污染，业务数据隔离解决并发操作冲突。两者缺一不可。
二、浏览器会话隔离了哪些状态
Playwright CLI 支持通过 -s 参数创建命名浏览器会话。
每个会话维护独立的浏览器实例，拥有各自的 Cookie、LocalStorage、SessionStorage、IndexedDB、缓存和页面。
Storage State 则可以把认证状态保存成文件，供新会话恢复使用。
图 1：Playwright CLI 多会话与 Storage State 隔离架构
图中，Admin Session 与 User Session 互不共享浏览器存储，但它们访问的仍然是同一个业务系统。
这也解释了为什么两个浏览器已经隔离，测试数据仍可能发生冲突。
三、Storage State 如何复用登录身份
假设需要测试一个订单管理系统，包含管理员和普通用户两种角色。
如果每条用例都重新登录，会增加执行时间，也容易受到验证码、登录接口波动等因素影响。
可以先准备两份认证状态。
以测试环境 test.example.com 为例：
打开管理员登录页面
playwright-cli -s=admin-setup open https://test.example.com/login --headed
完成管理员登录并确认成功后保存
playwright-cli -s=admin-setup state-save .playwright/.auth/admin.json
打开普通用户登录页面
playwright-cli -s=user-setup open https://test.example.com/login --headed
完成普通用户登录并确认成功后保存
playwright-cli -s=user-setup state-save .playwright/.auth/user.json
这里使用可视化浏览器完成首次登录，实际项目也可以通过 CLI 的元素定位和交互命令自动完成登录。
准备好状态文件后，为测试任务创建新会话：
管理员任务
playwright-cli -s=case-admin open https://test.example.com
playwright-cli -s=case-admin state-load .playwright/.auth/admin.json
playwright-cli -s=case-admin goto https://test.example.com/admin/orders
playwright-cli -s=case-admin snapshot
普通用户任务
playwright-cli -s=case-user open https://test.example.com
playwright-cli -s=case-user state-load .playwright/.auth/user.json
playwright-cli -s=case-user goto https://test.example.com/admin/orders
playwright-cli -s=case-user snapshot
通过页面快照检查两种身份的实际权限。管理员应能进入订单管理页，普通用户则应被拒绝访问或跳转至无权限页面，具体以系统的权限设计为准。
Storage State 保存的是 Cookie、LocalStorage 等认证信息，并不包含全部浏览器运行状态。SessionStorage 不会随上述命令自动恢复。
同时，状态文件也不能延长服务端令牌的有效期。令牌过期后，需要重新登录生成状态。
四、浏览器隔离后，还要处理业务数据污染
假设管理员和普通用户使用不同的浏览器会话，却同时修改同一笔订单。
管理员将订单标记为已审核，普通用户随后取消订单。
此时，即使两个会话完全隔离，订单状态仍然可能影响测试结果。
图 2：多角色并行测试的数据隔离与清理流程
并行测试可以采用独立账号、订单编号和测试数据集。执行结束后，通过测试接口或数据清理程序恢复环境。
浏览器会话相互独立，不代表它们访问的服务端数据也相互独立。
五、项目落地需要管理状态的完整生命周期
实际项目中，可以按测试环境和角色管理认证状态文件。
例如：
.playwright/
└── .auth/
├── admin.json
├── user.json
└── auditor.json
工程落地时，需要明确状态的生成、使用、失效和销毁规则。
生成阶段，必须确认登录成功后再保存。执行阶段，每个独立任务使用自己的命名会话，避免在已有业务状态的会话中反复加载不同账号的认证文件。
失效阶段，如果出现登录重定向或身份校验失败，应检查令牌有效期并重新生成状态文件。
销毁阶段，可以使用：
playwright-cli -s=case-admin close
playwright-cli -s=case-user close
关闭浏览器后，仍需单独清理服务端测试数据。
认证状态文件可能包含有效凭证，应加入 .gitignore，禁止直接提交代码仓库。
对于持续集成环境，还应将状态文件的有效期、访问权限和清理机制纳入统一管理。
六、AI Agent 会提高测试状态管理的复杂度
随着 AI Agent 从单任务执行转向多任务协作，浏览器会话、账号身份和测试数据都需要明确归属。
例如，测试生成 Agent 创建用例，执行 Agent 操作浏览器，诊断 Agent 分析失败现场。如果多个 Agent 共用同一个会话，某个任务产生的状态变化就可能影响其他任务。
Playwright CLI 的命名会话适合处理交互式浏览器任务，Storage State 可以减少重复认证的成本。
对于大规模自动化回归，还需要结合 Playwright Test 的浏览器上下文隔离、独立测试账号、数据初始化和环境清理机制。
当 AI Agent 开始并行执行几十条甚至上百条 Web 自动化测试时，你目前的测试框架，能否准确判断一次失败究竟来自业务缺陷、登录状态失效，还是测试数据相互污染？
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
