去年下半年我们团队接了一个挺头疼的活儿——给一套面向全球用户的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瞬间拉起了几百个实例并行执行整个过程完全自动不需要人工干预。几个坑和优化技巧1. 冷启动问题Serverless的冷启动是个老生常谈的问题。第一次调用函数时平台需要初始化运行环境加载依赖启动浏览器——整个过程可能耗时3秒以上。我们的优化手段有几个内存调大浏览器自动化对内存要求高建议至少分配1024MB推荐2048MB。内存越大CPU份额也越高启动速度会快不少。预热机制用CloudWatch定时触发一个空任务保持函数实例“活着”。Provisioned Concurrency对时效性要求高的测试任务可以预置并发实例。优化之后冷启动时间从3秒多降到了800毫秒左右接近热启动的水平。2. 超时控制Lambda单次执行最长15分钟。大部分端到端测试其实用不了这么久但如果遇到复杂的业务流程或者网络慢的页面15分钟确实可能不够。我们的做法是把长流程测试拆成多个步骤用Step Functions串起来。每个步骤独立成一个Lambda函数步骤之间传递上下文。这样既规避了超时限制失败重试也更灵活。3. 依赖打包playwright完整版会下载浏览器二进制文件体积巨大。在Serverless环境里强烈建议用playwright-core替代。playwright-core不包含浏览器需要自己提供浏览器可执行文件路径。另外要注意/tmp目录——这是Lambda里唯一可写的存储位置。如果测试过程中需要下载文件或者保存临时数据记得写到/tmp下面。4. VPC网络如果被测服务部署在VPC内网Lambda需要放到VPC里才能访问。但这样会带来额外的冷启动延迟大约5-10秒。我们的做法是内网服务通过API网关暴露出来Lambda不直接进VPC而是通过公网API访问。安全性靠API网关的认证和鉴权保障。这样既避免了VPC的冷启动惩罚架构也更干净。真实的收益最后说点实在的数据。这套架构上线跑了半年多几个关键指标的变化测试执行时间原来串行跑完所有用例要4个多小时现在并行跑12分钟左右搞定。月度成本从原来的次按测试次数计降到了8/次左右。测试稳定性flaky率从15%降到了2%以内因为每次都是干净的环境没有状态污染。运维投入原来需要专人维护测试机群、处理环境不一致的问题现在基本不用管了。当然这套方案也不是银弹。如果你的测试用例特别长比如超过10分钟或者对响应时间有极致要求毫秒级Serverless可能不是最优解。但对于绝大多数端到端测试场景来说Playwright Serverless的组合确实是一条值得认真考虑的路。
Playwright + Serverless：构建高效无服务器测试架构
去年下半年我们团队接了一个挺头疼的活儿——给一套面向全球用户的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瞬间拉起了几百个实例并行执行整个过程完全自动不需要人工干预。几个坑和优化技巧1. 冷启动问题Serverless的冷启动是个老生常谈的问题。第一次调用函数时平台需要初始化运行环境加载依赖启动浏览器——整个过程可能耗时3秒以上。我们的优化手段有几个内存调大浏览器自动化对内存要求高建议至少分配1024MB推荐2048MB。内存越大CPU份额也越高启动速度会快不少。预热机制用CloudWatch定时触发一个空任务保持函数实例“活着”。Provisioned Concurrency对时效性要求高的测试任务可以预置并发实例。优化之后冷启动时间从3秒多降到了800毫秒左右接近热启动的水平。2. 超时控制Lambda单次执行最长15分钟。大部分端到端测试其实用不了这么久但如果遇到复杂的业务流程或者网络慢的页面15分钟确实可能不够。我们的做法是把长流程测试拆成多个步骤用Step Functions串起来。每个步骤独立成一个Lambda函数步骤之间传递上下文。这样既规避了超时限制失败重试也更灵活。3. 依赖打包playwright完整版会下载浏览器二进制文件体积巨大。在Serverless环境里强烈建议用playwright-core替代。playwright-core不包含浏览器需要自己提供浏览器可执行文件路径。另外要注意/tmp目录——这是Lambda里唯一可写的存储位置。如果测试过程中需要下载文件或者保存临时数据记得写到/tmp下面。4. VPC网络如果被测服务部署在VPC内网Lambda需要放到VPC里才能访问。但这样会带来额外的冷启动延迟大约5-10秒。我们的做法是内网服务通过API网关暴露出来Lambda不直接进VPC而是通过公网API访问。安全性靠API网关的认证和鉴权保障。这样既避免了VPC的冷启动惩罚架构也更干净。真实的收益最后说点实在的数据。这套架构上线跑了半年多几个关键指标的变化测试执行时间原来串行跑完所有用例要4个多小时现在并行跑12分钟左右搞定。月度成本从原来的次按测试次数计降到了8/次左右。测试稳定性flaky率从15%降到了2%以内因为每次都是干净的环境没有状态污染。运维投入原来需要专人维护测试机群、处理环境不一致的问题现在基本不用管了。当然这套方案也不是银弹。如果你的测试用例特别长比如超过10分钟或者对响应时间有极致要求毫秒级Serverless可能不是最优解。但对于绝大多数端到端测试场景来说Playwright Serverless的组合确实是一条值得认真考虑的路。
