Web-UI 自动化实践

概述

• Bee 是由有赞 QA 开发的 UI 自动化工具，并以此实现了 web 端和 wap 端的核心业务的自动化。旨在简化开源工具提供的接口，方便 UI 自动化测试用例的设计。
• Bee 整个框架是基于 selenium 和 selenide 设计的。框架对 selenium 和 selenide 提供的接口进行了二次封装以满足日常的用例设计，二次封装后的接口解决了一些元素加载，元素定位解析等问题，可以让用例设计变得更加简便。
• Bee 能支持 Web 和 Wap 页面的元素定位以及操作，其中 Selenide 主要支持 Web 页面的元素操作，Selenium 支持 Wap 页面的元素操作。

Bee 为什么会采用 Selenide+Selenium 的模式：

原因一： 其实框架设计的初衷是想全部依赖 Selenide 来完成 Web 和 Wap 的自动化，Selenide 对于作者来说是一个全新的开源框架，很想窥探一二；

原因二： Selenium 可无缝接入。在实践过程中发现 Selenide 还不能支持 Wap 页面，满足不了日常的测试需求，好在框架可以很容易的嵌入 Selenium 从而实现了 Wap 页面的自动化，也正是 Selenide 和 selenium 有这个特性，所以在框架设计初期才敢放心的尝试采用Selenide；

原因三： 在实践中的切身体会 Selenide 对页面元素的处理会比 Selenium 平滑的多，因为 Selenide 其本身也是对 Selenium 的一个二次封装，对 Selenium 的接口也做了很多的优化。

Bee 目前支持的环境为：mac、chrome，整个框架支持可扩展。对于 Selenide 和 Selenium 的原理不在本文中赘述，大家可以到网上学习了解。

用例设计

按照实际的业务流程调用对应接口来实现 WEB-UI 自动化测试用例。case 层可调用 service 层和 pageObject 层的接口，pageObject 是对每一个页面元素的一个封装，service 是对一个常用的业务模块功能的封装。比如一个营销秒杀的测试用例，需要依赖登入、创建商品，这两个业务功能就可以直接调用 service 中的接口。秒杀活动的创建就可以调用 pageObject 中的接口，然后按照秒杀的业务流程，在测试用例中把这些接口串起来就形成了一个 UI 自动化测试用例，详细细节接下去会举例说明。

设计用例的灵活度取决于 pageObject 封装的颗粒度，颗粒度越小越容易在用例层设计出新流程的测试用例。用例层使用了 testng，可按照实际的需求灵活设计一个测试用例。推荐在封装 pageObject 接口的时候，颗粒度定义的越小越好，方便用例的扩展和维护。pageObject 封装的接口就相当于一个原子，原子粒度越小越方便组装成新的用例。相反如果粒度太粗维护上会不太方便。参考代码：

创建活动之前，需要登入有赞微商城后台，登入操作已封装到 loginService，直接调用 service 层的接口，不需要在意这个步骤的细节； 登入之后要指定一个商品参与秒杀活动，普通商品创建已封装到 goodsService，直接调用 service 层的接口，不需要在意这个步骤的细节； 接着是创建秒杀活动，创建秒杀活动的所有业务步骤都封装到 seckillPage，这就是个 pageObject 的实现，也是用例设计中最主要的环节； 最后把这几个步骤串起来就形成了一个秒杀活动的测试用例。用例结构清晰，组装简单。

框架介绍

1、工程结构

整个工程基于 selenide & selenium，采用 pageObject 模式搭建起来。技术结构：selenide+selenium+testng+reportng+spring。下面对工程中的几个重要模块做介绍。

1.1 dataprovider — 数据层

为了实现测试数据和测试用例分离而采取的一种方法，数据模型在 model 中定义，具体的测试数据则在 dataprovider 中初始化。

1.2 driver — 接口层

对 web 页面所有元素的操作都是在这里定义接口并实现的。driver 对 selenide&selenium 提供的接口做了二次封装，对外提供封装后的接口。common 实现了一些和接口相关的公共方法，比如模拟键盘按钮等，目前 common 封装的方法不多，大多功能都可以通过 selenide&selenium 实现。driver 层对开源工具接口做了二次封装，想要驱动一个浏览器还有一个必不可少的工具 —— 浏览器驱动，这个驱动放在 resources 里，驱动的版本必须与被测浏览器版本相匹配。

1.3 listeners — 监听器

为了提高框架本身的容错能力监听一些事件。目前实现了：1. 监听用例测试结果，可对不同的测试结果监听器做不同的处理；2. 失败测试用例重试的监听，一个 fail 的用例最多可重试3次。

1.4 model — 数据模型

为了实现测试数据和测试用例分离而采取的一种方法，具体的测试数据在 dataprovider 中初始化。可以对一个业务流程中需要测试数据的元素在一个 model 中定义出来，方便管理和代码阅读。

1.5 pageObject — 业务层

pageObject 模式，接口形式封装每一个页面需要用到的元素，实现上只要做两步：确定元素的定位方式；调用 driver 中对应的操作接口。driver 的接口实现包含了一定的容错能力，但并不是全面的，有些页面独特性或者组件的独特性单纯调用 driver 的接口并不能保证测试用例的稳定性，此时就需要在 pageObject 的接口实现中加入一些容错算法，确保用例稳定性。

实际操作的经验是 pageObject 对元素封装的颗粒度越小，在用例设计层设计测试用例就越灵活，可以像组装工具那样组装出一个新的测试用例。参考代码：

1.6 service — 提供业务功能

一个业务流程很多时候依赖其他业务模块功能，为了方便设计一个测试用例，也为了避免重复造轮子，service 层就提供了一些常用的业务功能，比如登入、创建商品等。依赖方只需要在 service 层调用即可。

2、功能优化

Bee 对 selenide&selenium 做二次封装的同时也对接口做了些优化，框架的初衷是使设计一个 UI 用例尽可能的易设计、易读、易维护。

2.1 接口优化

直接调用 selenide 或者 selenium 的接口经常会遇到些令人头疼的问题，比如网络问题使页面 loading 太慢，需要操作的元素还没展示出来，这种情况就会经常报元素找不到的 error，用例执行失败，但实际上这种报错不是一个 bug，测试结果是无效的。为了提高误报率 driver 层接口实现了等待元素加载的功能，使用的关键接口：Selenide.$(elementLocator).waitUntil(Condition.appears, timeout)。参考代码：

/**
     * 检查元素加载情况
     * @param elementLocator
     * @param timeout
     * @return
     */
    private boolean checkElementLoad(By elementLocator, long timeout){
        try {
            Selenide.$(elementLocator).waitUntil(Condition.appears, timeout);
            return true;
        }catch (Exception ex){
            throw new RuntimeException(ex);
        }
    }
/**
     * 如果没有找到元素抛null异常
     * @param element
     * @param timeout
     * @param elementType
     * @return
     */
    private By isElementLoaded(String element, long timeout,String ...elementType){
        By elementLocator = null;
        int count = 4;
        long partTimeout = timeout/count;
        for(int i=0; i