今天给大家带来一个自动化测试平台 ATP-UI 自动化篇

点赞再看，养成习惯，微信搜一搜【程序员一凡】关注这个喜欢码字的文艺程序员。

本文公众号程序员一凡 已收录，有一线大厂面试完整考点、资料以及我的系列文章。

自动化测试对于企业的存在价值与意义

1.敏捷开发，版本迭代快，上线时间紧急,接口和功能问题重重。
⒉.测试用例不断增加，用例臃肿，用例管理问题，批量分布式执行用例
3.大面积的自动化回归测试，尽早发现 bug
4.自动化冒烟测试
5.造测试数据
6.批量更改数据库脚本
7.爬虫
8.自动生成美观的测试报告

前言：

ATP(Auror Test Platform) 是一个集成接口-UI 自动化的一体化测试平台，关于 ATP 和如何对服务端接口测试方案已介绍了，这篇推文将介绍 ATP 对于 UI 自动化测试的解决方案。

你是否曾想过，不使用任何自动化框架，不写代码的情况下，写好功能测试用例后，点击某个按钮，一个 web 系统/app 就自动点来点去；并能按你的思路，在线执行 UI 自动化测试、回归测试；解决日常工作中一些重复繁琐，无聊费事的工作。

没错，ATP 已实现可在线执行 web/手机的 UI 自动化测试。它让测试工程师在做 UI 自动化测试时：

脱离测试框架、代码、环境依赖在线运行

无需连接 usb 的在线真机运行

UI 测试与 api 测试用例互相调用串场景运行

脱离 Jenkins 定时运行冒烟测试，测试计划

先看一个移动端 UI 自动化用例运行效果：点击执行按钮→自动跳转真机远程控制界面，运行测试用例

本文将从以下几点依次介绍：

UI 自动化简介与痛点所在

整理架构与设计思想

web 端使用说明与开发思路

安卓端使用说明与开发思路

未来规划路线

UI 自动化测试简介：

其实早在 2004 年 ThoughtWorks 公司，一个测试工程师就实现了基于 JavaScript 代码库的自动化测试工具，Selenium1.0 诞生了。

误区：UI 自动化仅限对于界面的排版，按钮，颜色等 UI 测试，但其实是通过界面 UI 来验证系统业务逻辑

原理：通过脚本语言或者工具，模拟用户行为操作，最接近用户真实场景，实现对 web/app 自动测试

真实价值：代替大量的 UI 重复操作，让测试用例重复使用，缩短反馈周期，为企业减少了时间和劳力成本。因为从测试的行为本质上看，人工 UI 测试和自动化 UI 测试没有区别，唯一的区别是一个由人来执行点击，一个由代码或者工具执行

UI 自动化的痛点-ATP 的优势：

不过我感觉到，大家极度关心的 UI 自动化测试离我们越来越远。因为在实践中，经常是这样的画面：

熟悉某套自动化测试框架花了多久

熟悉某个组织用例和代码的框架花多少天

写完一大推自动化用例代码后，多人协作，项目如何整合

各种运行环境依赖，如何可持续集成

行成完整的 UI 自动化体系耗时很长...

我们先看一个简单 web 端自动化测试用例，

如图所示：

以上仅是一个测试用例，未涉及到数据、版本、项目整合、持续集成等，何况还有移动端 UI 自动化，选择的自动化测试框架可能又不同.......

想要做好 UI 自动化，基于拥有一些经验丰富,熟悉一门开发语言和主流自动化测试框架的测试工程师的前提下。 这也是为什么 UI 自动化测试是处于测试金字塔最上层，因为它确实投入成本大，专业性要求高

所以，当你还纠结选择用什么开发语言，用什么测试框架来进行 UI 自动化的时候，越纠结，ATP 研发对 UI 自动化测试的解决方案想法越是强烈，下面分析下俩者的利弊：

换句话说，用 ATP 进行 UI 自动化测试，“低投入，高回报”。

说出来你还有可能不相信，ok，接下来，我们就来了解一下 ATP 的一些设计思想、实现过程以及功能效果展示，看它是如何来进行 web 和 app 的 UI 自动化测试，然后快速上手吧

ATP 对于 UI 自动化前后端交互架构设计：

整体框架采用的是前后端分离：

前端：vue.js+elementUI

服务端：flask

数据库：mysql，Redis

UI 自动化框架：web 端-seleniunm 移动端 automator2

ATP 对于 UI 自动化一些设计思想：

测试环境与测试用例分离

测试用例与被测页面对象分离

页面元素管理采用 POM 模型

用例管理：项目→系统→模块 (1~n)→用例集→测试用例

用例相互串联：UI 与 UI 用例，UI 与接口用例串联，实现业务串场景需求

web 运行环境：Selenium grid 分布式用户本地浏览器 ；chrome 的 headless 模式、基于 Docker 的 selenium/hub 镜像容器

app 运行环境：用 atx-serve 对测试安卓真机进行集群管理,仅需要知道测试机的 ip，无需连接数据线，就可以进行真机自动化了

用例组织框架：unittest

测试报告：HTMLTestRunner 库

用例实时推送日志：前后端建立 WebSocket 连接，在线调试与实时日志

测试计划：linux 中 Crontab 命令触发，批量定时执行用例

ATP 平台 UI 自动化核心功能：

测试用例增删改查

用例支持 (xmind、excel) 导入/导出

页面元素对象采用 POM 模型

用例批量复制

UI 用例与 UI 用例之间可相互进行业务调用

UI 用例与接口用例之间可相互调用

app 可扫描用户在 ATP 上传的二维码图片

用例支持分布式用户本地/服务器运行/真机运行

支持用例批量运行

测试结果报告展示，附带错误操作截图

测试计划，定时执行，发送 email 警告邮件

功能介绍和开发思路：

1.用例运行如何区分 Web/App-环境与用例分离:

ATP 是同时支持 web 端/app 端的 UI 自动化测试，所以第一步先配置环境信息：被测系统的类型、URL/APP 包名

思路：分别定义运行 web/app 俩个测试类，运行用例时前端调用一个 run 接口，根据前端请求参数中系统类型，然后添加相应的测试类至 unittest.TestSuite 然后运行

如图所示：设置系统类型 web，录入网站的 url

2.众多的页面对象元素如何管理-POM 模式：

UI 自动化原理是模拟用户操作页面上各种元素，换句话说首先得定位元素，因此第二步配置被测页面的元素，ATP 支持常见 8 种定位元素方法，先了解一下 POM 以及 xpath 定位控件

POM（Page Object Modle）: 页面根据系统来管理，而元素对象根据页面来管理，可以将测试用例与被测页面对象分离，页面元素与系统分离

POM 优势：页面元素对象根据系统统一管理，可重复利用；易于维护。例如，前端某个按钮或名称修改，所有操作到该按钮的测试用例不需要修改，仅修改按钮的元素值

思路：前端配置好页面对象，以 key-value 的方式存储于数据库表中。当用例的操作步骤用到该页面对象，将对象属性作为参数，去调用一个返回 webElement 的公共方法，此时就可进行 click、move、send_keys 等操作

灵活运用 xpath：xpath 虽可通过浏览器开发者工具直接复制，但是复制的往往是绝对路径而且不稳定。所以我们可以根据 Dom 节点属性、文本值等方式相对路径定位；把复杂的位置描述封装到一条短短的字符串里面，灵活、稳定且万能

例如：同一元素，前者是复制的 xpath,后者是写的相对路径 xpath；这样写让用例稳定且容易阅读

如图所示：配置某被测系统页面元素，该系统下的用例就可直接引用这些对象，进行点击、输入操作

3.用例信息何如管理 - 以一个字典存储,运行时再加载

配置系统环境和页面对象之后，第三步就可新增测试用例；也证实上文提到的设计思想：测试环境、被测页面对象都和测试用例分离，用例主要包括：

基本信息：添加用例标题，描述信息等

前置操作：初始化数据，数据库操作、执行其它前置 UI 用例，让用例更灵活，串联成一些流程场景

操作步骤：支持元素点击、键盘输入、鼠标移动、执行 javascript(例如滑动滚动条，切换窗口)、切换 frame、执行接口测试用例、app 扫描二维码等等

预期结果：当前元素在页面可见/不可见，可见的次数、元素可操作/不可操作、数据库校验等

实现思路：将前端配置好的测试用例所有信息以字典列表 (因为可能批量执行用例) 的形式存储于数据库表中，运行用例的时候再去组装和加载用例信息，再调用 unittest 中 subTest 方法和 selenium API 去执行用例

如图所示：就是配置测试用例的过程

配置完成后，将直接以表格的形式展现整个用例的操作过程，一目了然，这个用例 what to do,，仔细一看其就是一个功能测试用例，因为 ATP 已将功能测试用例和 UI 自动化用例合二为一:

如图所示：就是一个登录用例的过程

4 .用例运行环境 (web 端)-本地浏览器 grid/headless

ok，所有配置工作都已就绪，我们就可在线执行 UI 自动化测试了，有点跃跃欲试！

如图所示：可知被测系统类型是 web 端，它的 URL

点击执行用例按钮，会自动弹出一个浏览器，当然如果你只关心运行结果，可以选择不弹出本地浏览器，它会在服务器上默默的运行，而且测试报告每步操作都附带截图

思路：运行环境本地浏览器 grid/无头模式 headless

本地浏览器：使用 Selenium Grid，远程操作浏览器。服务器作为 hub，用户本地浏览器作为运行 Node,

hub: 参数值表示管理中心的 url 地址

Node:连接 hub 进行节点注册

通过 SeleniumGrid 可控制多台机器多浏览器执行测试用例,如图所示我在一台机器上注册 5 个浏览器 node

也可选择浏览器无 UI 界面在后台运行：

chrome 的 headless 模式

如图所示：ATP 在 loading 中，正在本地执行测试用例，然后自动弹出浏览器，打开了快递 100 网站登录

用例执行完成后：ATP loading 完成，浏览器自动关闭，然后会显示一个查看测试报告的按钮

5.测试失败如何在报告加截图-HTMLTestRunner

测试报告使用第三方库 HTMLTestRunner

思路：使用 selenium 中 get_screenshot_as_base64 方法， 获取页面截图的 base64 编码

点击显示截图按钮：可循环查看操作过程，如图所示，登录测试用例，第一步：输入了用户名

6.app 用例如何在线运行 - 集群管理

app 测试用例的配置与 web 测试用例配置完全一样

实现思路：将测试机用 atx-serve 进行集群管理，再远程控制手机界面。

在服务器上启动 rethinkdb，再将测试机进行初始化：

$ rethinkdb --http-port 8090

$python -m uiautomator2 init 服务器 ip

这时打开 url：测试机 ip 地址:7912/remote 就能访问手机远程控制界面

如图所示：点击运行按钮，可选需要运行的测试机

点击确定运行，自动进入远程控制测试真机界面，运行了被测 APP，且实时查看 app 的运行状态

7.app 如何进行扫描操作 - 二维码 push 至手机 sd 卡

在编辑测试用例时，操作步骤选择方式为：扫描二维码，然后上传本地图片，即可扫描二维码

实现思路：用户在前端上传被扫描的二维码图片，后端储存于服务器，再推送至测试手机 sd 卡的指定文件夹下

app 扫描时从相册中去选择，该指定文件夹下用户上传的二维码图片，实现扫描，之后再删除图片，保证每次该文件夹是用户最新上传的二维码

8.如何定时测试计划-Crontab 命令

测试用例不仅可在线运行，可定时执行冒烟测试、测试计划，然后发送邮件测试报告

思路：通过 linux 中 Crontab 命令触发定时批量执行

如图所示：每周 1-5 中午 12 点半，定时执行某个系统下的自动化测试用例

了解这些功能和效果展示后，对于 ATP 的 UI 自动化测试是不是能快速上手，不仅在项目交付中实现 UI 自动化测试，且将 UI 自动化用例与功能测试用例已合二为一

未来规划路线：

IOS 移动端 UI 自动化

移动端 app 多维度的性能测试

用例多线程、并发执行，提高效率

支持视频回放操作，快速定位出错原因

结语：

ATP 一体化测试平台，让接口和 UI 测试用例变得更简单，让 QA 更专注于测试用例本身的设计

ATP 已经介绍了接口测试方案，UI 自动化测试，APP 自动化，然而 ATP 远不止这些功能，还有接口压测、基准测试等等，请继续关注我们，不要吝啬你们的需求和建议，我们会不断的完善优化。

2019 年初开始的，目前测试平台项目研发已经完成并且在 Github 开源，有兴趣的朋友可以去 Github 下载https://github.com/ooqitech/ATP

大家有兴趣可以下载来玩一玩 我是 testhome 程序员一凡，软件测试，与你同行！陪你成为优秀的测试工程师！

听说点赞的人都拿了大厂 offer

絮叨

另外，一凡把自己的面试文章整理成了一本电子书，共 216 页！目录如下，还有我复习时总结的面试题以及简历模板现在免费送给大家

链接: https://pan.baidu.com/s/1lZjqDFMFPZJ26OI1SmnaAg 提取码: ipcc

双重福利，自研开源项目 + 免费资源，大家把那啥都点一下吧，……那啥？……

好的，我们下期再见，也不知道下次是啥时间，总之，很高兴认识你！