去年下半年，一个技术团队接手了一项颇具挑战性的任务——为面向全球用户的SaaS产品构建端到端自动化测试体系。产品每周发布两个版本，每次发版前需要执行上千条UI测试用例，覆盖三种主流浏览器及五种移动设备尺寸。最初的方案是在ECS上租用几台服务器，每天凌晨定时执行任务，但问题逐渐暴露：计算资源闲时浪费、忙时严重不足、环境不一致导致测试结果不稳定（flaky），且运维成本持续攀升。
后来团队彻底重构了测试基础设施，采用 Playwright + Serverless 技术栈。上线运行一个月后，测试成本下降了约75%，并发处理能力提升了十几倍，最关键的是，测试稳定性从此前的85%左右跃升至98%以上。
本文并非“Hello World”式的入门教程，而是从一线实战视角出发，系统梳理了从技术选型、方案落地到踩坑填坑的完整经验，希望能为正在调研类似方案的同行提供有价值的参考。
为什么选择 Playwright？
在探讨Serverless之前，先聊聊为何选中Playwright。
团队之前使用过Selenium，也短暂尝试过Cypress。Selenium的痛点在于过于“笨重”——需要单独管理WebDriver，不同浏览器版本还得操心驱动兼容性，维护成本较高。Cypress在当时仅支持Chrome系浏览器，跨浏览器测试的能力短板比较明显。
Playwright是微软开源的项目，原生支持Chromium、Firefox、WebKit三大浏览器内核，无需额外安装驱动程序。对于需要同时验证Chrome与Safari兼容性的产品而言，这一特性非常关键。此外，其“智能等待”机制也相当实用——在元素出现前自动等待，无需在代码中手动添加大量 sleep 或 waitFor 语句。
更值得一提的是，Playwright在设计之初就考虑到了无服务器环境的适配需求，这一点后续会详细展开。
为什么选择 Serverless？
再来说说Serverless。
原先的ECS方案，本质上是“不管有没有测试任务在跑，机器都得持续运行”。一个月下来，仅计算资源的账单就相当可观。而且并发测试一多，扩容还得手动操作，响应总是慢半拍。
Serverless的核心优势在于按需付费、自动弹性扩缩容。测试任务触发时才启动计算资源，任务完成后立即释放，没有任务时成本为零。AWS Lambda每月提供100万次免费调用额度，单次执行成本低到几乎可以忽略。根据实际测算：同样的测试规模，Serverless方案的成本仅相当于原来ECS方案的25%左右。
另外还有一个容易被忽视的优势——环境隔离。Serverless每次调用都是独立的运行环境，测试之间不会相互污染。以前用ECS跑并发测试，经常出现A测试修改了某个状态导致B测试失败的情况，排查起来极其痛苦。切换到Serverless后，这个问题自动消失了。
核心挑战：浏览器如何集成？
理想很丰满，现实却很骨感。将Playwright部署在Serverless上，最大的难题就是：浏览器的二进制文件体积太大了。
以Chromium为例，完整安装包超过280MB。而AWS Lambda的部署包限制为50MB（压缩后），即便使用容器镜像，冷启动时加载这么大的浏览器也会带来明显延迟。Vercel的Serverless环境同样面临类似问题。
如何解决？团队尝试了几种方案，最终沉淀出两条可行路径：
方案一：Lambda Layer + 轻量级Chromium
如果使用AWS Lambda，最便捷的方式是采用社区已经打包好的Chromium二进制文件，通过Lambda Layer挂载进来。
推荐使用 @sparticuz/chromium 这个包，它是专门为无服务器环境优化的Chromium构建版本，体积控制得相当出色。配合 playwright-core（不包含默认浏览器二进制文件的轻量版）一起使用：
const chromium = require('@sparticuz/chromium');
const playwright = require('playwright-core');
exports.handler = async (event) => {
const browser = await playwright.chromium.launch({
args: chromium.args,
executablePath: await chromium.executablePath(),
headless: true
});
// ... 执行测试逻辑
await browser.close();
};该方案的优点是部署简单，缺点是Lambda Layer有250MB的解压后大小限制，如果浏览器版本更新频繁可能会触及上限。
方案二：容器镜像部署
如果觉得Layer方案空间局促，或者使用的不是AWS，可以考虑容器镜像方案。
微软官方提供了带Playwright和浏览器的Docker基础镜像 mcr.microsoft.com/playwright。直接以此镜像为基础，将测试代码打包进去，部署到支持容器的Serverless平台（如Google Cloud Run、Azure Container Apps）即可。
团队后来将部分测试迁移到了Google Cloud Run上，采用的就是这套方案。Cloud Run的容器镜像上限为10GB，完全够用。部署时需要注意添加几个启动参数，防止Chromium在容器内出现问题：
const browser = await chromium.launch({
headless: true,
args: [
'--no-sandbox', // Cloud Run必需
'--disable-dev-shm-usage', // 防止内存问题
'--disable-gpu',
'--single-process' // 规避Lambda安全限制
]
});--no-sandbox 参数在容器化环境下几乎是必加的。--single-process 在Lambda上运行时特别有用，可以规避某些安全限制导致的启动失败。
架构设计：三层分离
聊完技术选型，再来说说整体架构。
最终采用的设计是三层结构：
- 触发层：通过API Gateway接收测试请求，或使用EventBridge配置定时任务。例如每天凌晨2点自动触发全量回归测试。
- 执行层：Serverless函数池负责执行Playwright测试。每个测试用例独立作为一个函数调用，互不干扰。当并发量较大时，平台会自动扩展实例。
- 存储层：测试报告、截图、视频录屏统一存储到S3或OSS，方便后续回溯和问题定位。
这套架构的突出优势在于水平扩展能力极强——单个函数实例可以并发执行多个测试用例。在一次压力测试中，同时触发了500多个测试任务，Lambda瞬间拉起数百个实例并行执行，整个过程完全自动化，无需任何人工干预。
常见坑点与优化技巧
冷启动问题
Serverless的冷启动是一个老生常谈的问题。第一次调用函数时，平台需要初始化运行环境、加载依赖、启动浏览器——整个过程可能耗时3秒以上。
优化手段主要有以下几种：
- 增大内存：浏览器自动化对内存资源要求较高，建议至少分配1024MB，推荐2048MB。内存越大，CPU份额也越高，启动速度会有明显提升。
- 预热机制：通过CloudWatch定时触发一个空任务，保持函数实例处于“活跃”状态。
- Provisioned Concurrency：对于时效性要求较高的测试任务，可以预置并发实例。
经过优化后，冷启动时间从3秒多降到了800毫秒左右，已接近热启动水平。
超时控制
Lambda单次执行最长持续15分钟。大部分端到端测试其实用不了这么久，但如果遇到复杂的业务流程，或者页面加载较慢，15分钟确实可能不够。
解决方案是将长流程测试拆解为多个步骤，通过Step Functions串联起来。每个步骤独立成一个Lambda函数，步骤之间传递上下文信息。这样既规避了超时限制，失败重试也更加灵活。
依赖打包
playwright 完整版会下载浏览器二进制文件，体积非常庞大。在Serverless环境下，强烈建议使用 playwright-core 替代。playwright-core 不包含浏览器，需要自行提供浏览器可执行文件的路径。
另外需要特别注意 /tmp 目录——这是Lambda中唯一可写的存储位置。如果测试过程中需要下载文件或保存临时数据，务必写到 /tmp 目录下。
VPC网络
如果被测服务部署在VPC内网，Lambda需要放入VPC才能访问。但这会带来额外的冷启动延迟（大约5-10秒）。
实践中采用的做法是：内网服务通过API网关暴露出来，Lambda不直接进入VPC，而是通过公网API进行访问。安全性依靠API网关的认证和鉴权机制来保障。这样既避免了VPC带来的冷启动惩罚，架构也更为简洁清晰。
实际收益数据
最后分享一些真实的运营数据。
这套架构上线运行了半年多，几个关键指标的变化如下：
- 测试执行时间：原来串行执行所有用例需要4个多小时，现在采用并行执行，12分钟左右即可完成。
- 月度成本：从原来的$3800/月降到了$900/月左右（按测试次数计费），单次执行成本低至$0.008/次。
- 测试稳定性：flaky率从15%降到了2%以内，因为每次执行都是干净的环境，不存在状态污染问题。
- 运维投入：原来需要专人维护测试机群、处理环境不一致的问题，现在基本实现了零维护。
当然，这套方案也并非银弹。如果你的测试用例特别长（比如超过10分钟），或者对响应时间有极致要求（毫秒级），Serverless可能不是最优选择。但对于绝大多数端到端测试场景来说，Playwright + Serverless 的组合，确实是一条值得认真考虑的路径。
