相比Selenium，Playwright好用在哪里？

lsekfe

　最近发现微软出了一个用于Web UI自动化的python库——Playwright，很感兴趣，所以做了一些研究，和大家分享一下。
　　说到UI自动化，可能大家和我一样，主要是用Selenium。毕竟Selenium可是UI自动化方面的王者。而且Selenium上手很快，使用者广泛，社区活跃，遇到问题随时可以找到一大堆相关的网页给你提供帮助。
　　那既然这样，为什么新出的这个Playwright还能掀起一阵热潮呢？
　　一方面这是IT技术领域的一个趋势，从业人需要时刻关注业内的新技术，新方向，不断提升自己的能力，或者给公司，团队带来新的idea，这样才能不断在职业生涯中稳步向前。
　　另一方面，Selenium虽然有着各种突出的优势，但是弊端也很明显：
　　它依赖多种不同的driver，根据浏览器的不断更新，就要不断去维护这些driver，以及处理相应的适用性问题。
　　比如chromedriver升级到适用chrome version: 88，关于之前Ctrl+a的调用就不支持了，需要调整相应code。
　　稳定性不够好。
　　Selenium本身提供的方法，并不能保证test case稳定通过，因为element状态有时候并不可用，这个时候的actions肯定会有问题。
　　虽然使用人员会封装Selenium方法，加入一些等待，甚至是元素状态轮询判断，但是稳定性增加的同时，运行时间也同时大幅增加。
　　录制代码不稳定。
　　因为Selenium IDE录制的代码是基于coordinate 或者DOM 层级结构，所以极其不稳定，也就导致IDE基本无人问津。
　　Selenium的劣势，或许也就是Playwright能够快速崛起的抓住的机会吧。我们来看看Playwright到底有什么魔力，能撼动Selenium的王者地位？
　　首先，Playwright同样适用于多浏览器、多语言，这样对于准备过渡到这个工具的用户是非常友好的。
　　其次，Playwright可以使用基于css、xpath、text这些常用的元素定位方式进行录制生成代码，能大幅度的减少写代码的时间，同时代码稳定性也可以保证。
　　再有就是playwright使用api方式操作浏览器内核，速度快，而且可以和浏览器双向沟通，元素操作可以在元素ready的情况下进行，稳定性很好。
　　最后，支持UI和非UI方式运行，节省了debug、 run时间。
　　好处多多，可是又有人望而却步了，毕竟我们之前那么多的测试代码都是基于Selenium的， 完全切换到Playwright的成本不可想象。别担心，我们是可以同时使用Selenium和Playwright的。
　　怎么做呢？我这里以python为例：
　　Playwright和Selenium可以基于不同的Python Package， 因为他们都能很好的与pytest测试框架集成，所以只需要单独封装setup / teardown methods即可。
　　结构：

　　For Selenium:

　　For Playwright:

　　Test cases:
　　Playwright test case

　　Selenium test case

　　Running Cases:

　　这样，我们既可以保留之前基于Selenium写的case和方法，还可以单独添加新的基于Playwright cases、methods，是不是很棒呢？
　　之后有新的想法和学习成果，会随时和大家沟通。让我们一起探索Playwright给我们UI自动化带来的更多可能性吧。

川逝水

前排留名