去年下半年，我们团队接了一个挺头疼的活儿——给一套面向全球用户的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分钟左右搞定。
月度成本：从原来的
次
（
按
测
试
次
数
计
）
降
到
了
8/次左右。
测试稳定性：flaky率从15%降到了2%以内，因为每次都是干净的环境，没有状态污染。
运维投入：原来需要专人维护测试机群、处理环境不一致的问题，现在基本不用管了。
当然，这套方案也不是银弹。如果你的测试用例特别长（比如超过10分钟），或者对响应时间有极致要求（毫秒级），Serverless可能不是最优解。但对于绝大多数端到端测试场景来说，Playwright + Serverless的组合，确实是一条值得认真考虑的路。
