不同场景下的前端自动化测试要点以及策略选择

前端自动化测试的应用场景众多，常见的包括自动化冒烟，自动化回归，版本自动化测试以及环境的自动巡检。对于自动化冒烟来说，效率可能需要排在第一位，因为往往自动化冒烟都是集成在pipeline中，pipeline中的节点众多，自动化冒烟很容易成为整条pipeline的运行瓶颈（运行时间过长）。对于自动化回归，版本测试以及环境的自动巡检来说，效率可能并不是第一位，因为往往这部分自动化测试要求的时效性并不高，以自动化回归为例，通常我们会找一台独立的服务器运行，不会影响到测试人员手中的正常工作，主要消耗的是机器资源。

对于策略选择，自动化冒烟以效率为先，因此在自动化冒烟测试的用例选择中需要非常谨慎，对于一些测试预期结果不可控的用例尽量不要加在自动化冒烟测试用例库中，而对于自动化回归，版本测试等使用场景，用例的选择则可以稍微粗放一些，只要选择的自动化测试框架能够帮助我们快速的排错，那么在时间允许的情况下，应该尽可能运行所有的自动化测试用例。环境巡检属于比较特殊的使用场景，稳定性肯定第一位，因为谁都接受不了一堆的误报。而如果效率过低，对于快速发现问题不利，特别对于生产环境的巡检来说，效率的要求也极高，因此对于这种场景，我们应该采取特殊策略对待，尽量在高稳定性的同时保障高效率。

常见的可能影响稳定性和效率的因素

稳定性和效率往往是相悖的，为了解决稳定性的问题，往往就会牺牲效率。最常见的，不确定元素多久才会出现，则在脚本中加入足够长的绝对等待，这对于效率的影响是非常大。还有在前端自动化测试的元素定位上，在自动化测试设计时往往图方便，会直接用浏览器的插件完成元素的定位信息的提取，通常是xpath，这样对于当前的自动化测试实施确实节约了时间，但是xpath的维护性非常差，一个层级的变动可能影响整个定位信息失效，这对于维护的工作量是致命的。还有一些常见的在前端自动化测试中可能影响到脚本运行的原因，例如服务器上的其他服务影响到浏览器的运行，导致运行失败等。

提升前端自动化测试稳定性和效率的常用技巧

减少服务器上其他服务对浏览器的影响

针对这点有三种方案，第一种也是最简单的就是准备一台专门用于你这一个项目的前端自动化测试运行的服务器，不允许运行其他项目；第二种是用docker容器来代替运行服务器，例如常见的selenium grid+docker的方案，容器是一个独立的进程，服务器上的各个进程间都是隔离的，不存在互相影响的情况；第三种是使用无头浏览器。
第一种方案无需介绍，重点介绍第二种和第三种方案：

RF应用selenium grid+docker启动浏览器的关键脚本如下：

即在open browser关键字的第四个参数输入grid_hub服务地址即可，目前部门已经提供了两个hub可供使用：

RF应用无头浏览器的关键脚本如下：

核心脚本为第二行在chrome的启动参数中加上–headless

对于不确定弹框的捕获

所谓不确定弹框，不是指由于环境异常导致的各种弹框（例如网络连接中断，服务器异常等），而是指在不同合理的外部条件下出现的弹框，例如在网速慢的时候，可能会出现的缓冲图标。针对弹框内容的捕获，由于网络条件的不确定性，往往很难捕捉。这个时候就可以借助抓包利器-fiddler。fiddler的rule中设置请求断点，一条一条的发送请求。

待获取到弹框内容后，再取消断点设置。

对于等待时间的处理

不建议绝对等待，只建议相对等待。所以的相对等待是基于某个条件来做等待时间的设置，常见的关键字有：wait until系列。

对于不确定是否出现的元素的处理

对于不确定是否会出现的元素，可以增加一个前置关键字先判断是否存在，然后再决定是否对这个元素进行处理，例如不确定是否会出现的缓冲图标，可以先定义一个关键字获取元素是否存在：

然后再在脚本中调用这个关键字先获取是否存在，再决定是否对元素进行处理：

核心关键字是Run Keyword And Return Status和Run Keyword If。