Puppeteer之总结回顾

上篇博客介绍了如何提高UI层测试代码的可读性，此篇博客是puppeteer框架部分的最后一篇博客。首先，会回顾puppeteer框架特点，接着会介绍如果选用puppeteer框架，如何搭建完善的UI层自动化脚本。为了完成此次课程目标拆分了2个task。

• 回顾puppeteer框架特点
• 使用puppeteer时如何搭建完善的UI层自动化脚本

接下来，就开始第一个task吧。

回顾puppeteer框架特点

前面学习了puppeteer框架的相关内容后，我们再回顾看下puppeteer框架特点，其中标注了红色小星的为该框架的突出优势。

充分了解一个框架的特点、优势，有利用为项目选择合适的测试框架。那如何为项目选择合适的UI层框架呢？上图中左边的纬度几乎涵盖了选择框架的所有点，选择框架时只需判断在某个纬度上是否达到项目要求即可。例如，如果项目用IE浏览器进行测试，而puppeteer只支持Chrome和firefox，显然不合适。再比如，如果被测项目多个场景需要在多tab页上切换操作，那么puppeteer是合适的，相反，前面讲过的cypress不合适，因为cypress不支持多tab页间操作。

上面重点列举了Puppeteer的优势，那么选择此框架是否有局限性呢？当然有。官网对Puppeeteer的定义是：提供了高级别的控制浏览器的API，所以，严格说Puppeteer并不是专门用于UI层自动化测试的测试框架，只是可以用Puppeteer完成UI层自动化测试而已。故如果选择Puppeteer，编写和调试测试脚本方面成本会大一些。

除了判断框架是否满足项目基本需求外，还需要考虑使用框架的成本。例如调试成本，以puppeteer和cypress为例进行比较，cypress调试显然要优于puppeteer。再比如，UI层测试脚本编写成本中定位页面元素是投入成本比较大的部分，故选择框架时还需考虑框架是否提供了丰富的定位页面元素的方法，就puppeteer和cypress比较而言，cypress提供了更多定位页面元素的api。使用puppeteer定位页面元素时有时候要借助document对象，编写脚本成本上要稍稍大一下。

最后，还需看框架的社区支持，尽量选择start数比较高的框架，或者有大厂支持的框架，这样当遇到框架自身的issue时能得到及时解决。上面回顾了puppeteer框架特点，接下来我们看看如果使用pupeeteer，如何搭建完善的UI层自动化脚本。

使用puppeteer时如何搭建完善的UI层自动化脚本

我们先看下编写UI层自动化测试时我们期望达到的目标，列举的目标如下所示

• UI层自动化测试能自动准备测试数据，自动执行，自动完成校验，自动清理测试数据

• UI层自动化测试能多环境自动切换

• UI层自动化测试能并发运行，运行时间控制在X分钟内，这里X可根据实际项目而定。做到并发运行，就要求用例之前无相互依赖，无执行顺序要求。

• 按照测试金字塔，UI层自动化覆盖重要场景的正向流程。

• UI层测试稳定性好，例如CICD平台上成功率达到95%以上（issue导致的失败除外）。

• UI层测试代码结构清晰、UI层测试脚本自身分层清晰，便于维护。

• UI层测试代码中函数粒度合适，既能复用，又能控制函数大小。

如果完成了上面的目标，实际也就达到了搭建完善UI层自动化脚本的目标。那上面的目标如何转换为可落地的脚本编写策略呢？请看下面的内容。

至此，此篇博客就结束了，此篇博客介绍了可以从哪些纬度了解测试框架特点，根据框架特点选择适合项目的测试框架。另外，还介绍了如何搭建完善的自动化脚本，这里需要强调一点，上面的策略只是通用性的指导策略，每个系统千差万别，每个公司项目运作也不同，在通用性指导策略基础上，还需结合自己的项目实际情况进行思考，持续优化。