看了那么多文章，我们不谈虚的，今天就聊点实际的，我们什么阶段需要引入AutoTest呢？
毋庸置疑的告诉你是当case越来越多，而产品迭代周期不变的情况下，总有一天，现有团队无法在上线之前把所有的case执行完，此时我们需要更有效率的用例执行方式。同时测试人员总是需要重复执行同样的TestCase，时间长了会产生疲惫感，我们此时就会想办法把一些枯燥的工作交给自动化程序去执行。
在web自动化测试中，用得较多的主要有以下框架Selenium、Cypress、Playwright、Puppeter....以下是Selenium在各方面技术/特性与其他测试框架的对比
脚本语言支持方面，Selenium、Playwright支持的最多。因为不同的公司、不同的技术栈，程序员使用的语言都不一样，支持的语言更多占据的优势就更大，因此Selenium拥有了更多的潜在用户群体
从浏览器的支持程度来看，TestCafe支持的最多，Selenium与其他几个框架则大同小异，而Cypress支持的相对较少，且不支持运用广泛的IE和Safari浏览器
多Tab，iFrame支持及并行测试方面，Selenium也都是支持的，而Cypress则都不支持
原生DOM选择器方面，虽然Playwright（到底是微软）支持的最多，但Selenium也能够支持主流的两种选择器CSS和XPath
在录制插件和解决方案方面，Selenium也是做得比较好的。Protractor、WebDriverIO因为和Selenium同宗同源，所以差异不大。而Cypress、TestCafe、Playwright在这两方面则相对较差，都没有比较好的解决方案。
开源软件：源代码开放可以根据需要来增加工具的某些功能
跨平台：Linux、windows、mac
支持多种浏览器：Firefox、Chrome、IE、Edge、Opera、Safari等
支持多种语言：Python、Java、C#、JavaScript、Ruby、PHP等
成熟稳定：目前已经被Google、百度、腾讯等公司广泛使用
功能强大：能够实现类似商业工具的大部分功能吗，因为开源性，可实现定制化功能
当然，作为软件开发的从业者，选择某一种技术必然要承担其技术负债。Selenium虽然具备以上提及的多种优点，但Selenium有以下4个方面的困难。而这4个困难恰恰是当今UI自动化不被看好的主要原因
元素定位困难。随着打包编译等技术的不断发展，使用了新的现代化的条件渲染引擎后，页面元素定位复杂多变，依靠Selenium中原有的ID、CSS、XPath等选择器编写的脚本有时候不能很好地工作，原先的定位方式不再适用
等待元素无法做到自动等待。当测试运行的服务发生异常、资源不够或者网络拥堵时，页面元素的渲染时间会受到影响。由于Selenium是通过WebDriver控制浏览器，需要用户自己去管理等待时间，而这个时间通常都是不太固定的
插件录制会把不必要的步骤录制下来。所有的录制插件都会录制非常多的不必要步骤，比如点击一个按钮，插件会把鼠标移动的过程也录制进去
人工维护元素定位非常困难，工作量非常大。当UI测试的用例数量愈加庞大，元素定位的维护就会变得相当困难，当需求发生变更时，页面也可能随之发生改变。而这一改变对于不熟知前端代码的测试人员来说通常是难以察觉的
Selenium在脚本语、浏览器持、并发、分布式，以及插件录制、视频录制都有完整的案例，开源、多平台、多浏览器、API齐全、技术架构也在不停的演化升级维护，你有任何技术问题在搜索引擎去检索基本都可以搜索到解决方案，目前就企业测试团队使用selenium的用户群体居多，所以选择了selenium！