Playwright最开始是微软推出的一套Node.js开源API，用来自动化控制浏览器，对标就是谷歌的Puppeteer（历史渊源），之后Playwright引入了测试模块@playwright/test 逐渐聚焦到了Web自动化测试，现已经成为当今最流行的Web自动化测试框架。截止2023年5月GitHub已经有了51K的star。
Playwright速度快
天下武功，无坚不摧，唯快不破。确实在如今快速迭代的开发过程中，速度就是效率。当代码一提交，就应该快速跑完相关自动化测试，有问题能快速报告，持续保障代码的质量。
- 对比老牌测试框架，比如Selenium，如果单Web自动化测试来说，各种对比文章几乎一边倒的结论都是Playwright要快很多。
- 对比新型测试框架，比如Cypress，同样是Playwright更快。
- 笔者的公司也曾使用自我研发的Puppeteer+Mocha来代替Selenium，实际结果就是，同样的test cases，使用Selenium几乎要1-2个小时，而使用Puppeteer+Mocha则几乎在5-10分钟，而且无需多台服务器，使用多进程并行即可，而@playwright/test还有更多进一步的优化。之前写Selenium要懂Java还要懂JS，新工具只需懂JS，既简单，又快速还节约成本。
Playwright为什么快
- 首先Playwright使用websocket直接连接浏览器（DevTools Protocol），无需像Selenium一样先连接WebDriver
显然如果有成百上千的test cases，那么成千上万的通信，一个节约几毫秒，加起来也快很多
-
Playwright的并发机制。Playwright Test可以定义workers的数量，也就是如果你的CPU核数量够多，那么最大化的并行数量也就更多，理论上就能成倍的加快测试速度。 下图是workers为1的情况，也就是顺序跑，不并发
下图是workers为6的的情况，当然我这里使用test cases很快，实际的单个测试肯定要花多时间，那么并发就更能体现出优势，而且我的电脑就4核，理论上开4个workers可能更合理
这么多并发进程难道没有额外的消耗么，这就得益于Nodejs运行时非常小的优势了，在CPU内核剧增和内存廉价的今天，多进程的优势显而易见。 Playwright也可以使用顺序模式，比如测试一些有依赖的情况，默认是开启spec文件级别的并发模式。
更多关于并发的信息可以参考官方文档：Parallelism and sharding | Playwright
-
Playwright也支持sharding模式。也就是可以把测试分配到不同的机器上同时执行。比如有100个case，可以在两台机器上分别执行：
npx playwright test --shard=1/2
npx playwright test --shard=2/2
那么前50个就在第一台机器上运行，并且该机器也是多进程并发执行的，所以就进一步成倍的提高了测试速度。 现今的DevOps都是容器化，比如像GitHub Actions直接可以配置sharding，可以参考这里Continuous Integration | Playwright
- Playwright有强大的查询和定位器，支持自动等待且重试。在Puppeteer阶段采用的是类Jquery的查询定位元素，亦或xpath，而Playwright一开始继承了这一点，但现在推出了全新的
Locator类并淘汰了类Jquery的查询接口
谁用谁知道，新的Locator简化了写查询机制，至少无需自己写等待和重试，自然也提高了开发效率
当然Playwright还有很多优秀的功能和创新，比如UI模式，trace viewer，VS Code扩展，直接mock请求，还有针对组件的CT测试等等，下次一有机会再介绍。感谢阅读。
