Web UI自动化的设计和实践

背景

UI 自动化测试，即通过自动化的手段来控制机器模拟人进行手工操作。随着 GrowingIO 业务的不断发展，新需求的不断增加，回归测试的任务越来越重，现有测试的资源已经不足以应对繁重的回归测试任务，亟需 UI 自动化来代替人手工进行回归测试，解放回归测试的人力去做更精准的测试。因此，引出下文在 GrowingIO 的Web UI 自动化的建设，本文主要就以下两个方面展开介绍：

1.框架搭建

2.集成质量平台

框架搭建

PageObject

众所周知，UI 自动化测试，是位于测试金字塔塔尖的位置，ROI 低。其痛点主要体现在：

1.测试用例维护成本高，页面元素定位方式或者布局有一些细微的变动，之前写好的代码可能就有很大的改动；

2.代码冗余，复用性低，可读性不好。

针对以上痛点，同时也通过大量调研，决定使用 PageObject 设计模式，其核心思想为六大原则：

• 公共方法代表页面提供的服务

• 不要暴露页面细节

• 不要把断言和操作细节混用

• 方法可以 Return 到新的页面

• 不要把整页内容都放到 PageObject 中

• 相同的行为产生不同的结果，可以封装不同结果

依据以上六大原则，并结合 GrowingIO 具体业务的情况，目录层级设计如下：

• BasePage 层：封装对网页的一些基础操作的方法，比如打开浏览器、查找元素、截屏等

• Component 层：继承 BasePage 层，封装了对页面中公共组件的操作方法，比如时间组件

• Page 层：继承Component层，该层中的每个方法都对应当前页面的一个功能，方法里可以调用Component 层中的方法或调用 BasePage 层中封装的方法

• TestCase 层：调用业务 Page 层中封装的方法，编写业务 Case，并做断言

实际项目的目录分层如下：

├── basepage
│   └── base_page.py
├── component
│   └── element_design.py
├── conf
│   ├── conf.py
├── datas
├── log
│   └── all.log
├── log.py
├── page
│   ├── home_page.py
│   ├── login_page.py
│   ├── main_page.py
│
├── pytest.ini
├── report
│  
├── requirements.txt
├── run_all_cases.py
├── testcase
│   ├── conftest.py
│   ├── testcase.py
│
└── util
    └── util.py

Selenium + Python

语言选择 Python，对于新人友好且组内人员比较熟悉，可以迅速上手；

目前市场上的 Web UI 自动化测试方案百花齐放，基于底层技术的不同大体上分为以下几类：

1.WebDriver Protocol 类：

如 Selenium 3，WebdriverIO，Protractor，Nightwatchjs

2.Proxy JS 注入类：

如 Selenium RC，TestCafe，Cypress

3.DevTool Protocol 类：

如 Puppeteer, Playwright t

我们选择使用 Selenium 3，优势如下：

• 开源、免费

  </