当前一切UI自动化都是建立在selenium2的API基础上的，最底层都是调用的模式。

UI自动化主要的体现应该在易用性、稳定性、可读性、可维护性、可扩展性当中。

Rebotframework +Selenium2library模式

Robot Framework是验收测试和验收测试驱动开发（ATDD）的通用测试自动化框架。它具有易于使用的表格测试数据语法，并使用关键字驱动的测试方法。其测试功能可以通过用Python或Java实现的测试库来扩展，用户可以使用与创建测试用例相同的语法从现有的关键字创建新的高级关键字。

Robot Framework是基于python的测试框架，基本上python能做到的事情它都能做到，既然如此为什么我们不直接使用python呢? 因为ATDD主要主角是没有技术经验的用户，怎么利用好懂的自然语言让用户可以参与到测试流程之中就是Robot Framework 的一大卖点。

这个UI自动化框架应该说是市面上使用的最广泛的了，又有别称为“关键字”框架，因为其上手简单，只需要封装好关键字，使得不懂代码的人也可以快速写出用例，采用的是BDD设计思想。

它有三层结构：

• 适配层：用例使用 tsv 格式编写，采用的主要是关键字驱动的形式。

• 核心层：提供了 setUp，tearDown 方法，并有合适并足够的断言功能和异常捕获功能。

• 工具层：具有众多的 Library 可供选择，可以结合不同的工具测试各种领域的软件。

由于框架本身的强大扩展性，可以使得进行二次开发来完成符合自身业务的特性，而且自带的报告也非常好看。

选择Robot Framework的好处

• 启用易于使用的表格语法，以统一的方式创建测试用例。
• 提供从现有关键字创建可重复使用的更高级别关键字的功能。
• 提供易于阅读的结果报告和HTML格式的日志。
• 平台和应用程序是独立的。
• 提供一个简单的库API，用于创建自定义测试库，可以使用Python或Java本机实现。
• 提供命令行界面和基于XML的[输出文件，以便集成到现有构建基础架构（持续集成系统）中。
• 为Selenium提供Web测试，Java GUI测试，运行进程，Telnet，SSH等支持。
• 支持创建数据驱动的测试用例。
• 内置对变量的支持，特别适用于不同环境下的测试。
• 提供标记以分类和选择要执行的测试用例。
• 实现与源代码控制的轻松集成：测试套件只是可以使用生产代码进行版本控制的文件和目录。
• 提供测试用例和测试套件级别的设置和拆卸。
• 模块化架构支持创建测试，即使对于具有多种不同接口的应用程

高级架构设计

Robot Framework是一个通用的，应用程序和技术独立的框架。它具有高度模块化的架构，如下图所示。

Robot Framework架构

image.png

该测试数据是简单，易于编辑表格格式。启动Robot Framework时，它会处理测试数据，执行测试用例并生成日志和报告。核心框架对测试中的目标一无所知，与它的交互由测试库处理。库可以直接使用应用程序接口，也可以使用低级测试工具作为驱动程序。

截图、报告、日志

Robot Framework框架本身自带报告非常齐全，运行、截图、report 都不错。

rebot命令提供报告和日志生成功能

当用例运行结束，Robot Framework 生成三个文件：output.xml、log.html 和 report.html

output.xml 记录的测试结果是 XML 文件。根据特定的需要可以编写脚本读取 XML 文件并生成特定的测试报告。

log.html 会记录 Robot Framework 运行的每一步操作，主要用于编写测试脚本的过程中查看。

report.html 为测试报告，整理性的展示测试用例的运行情况。

通过浏览器打 log.html 文件查看。

image

不足之处

• 关键字很好用，但是后续的维护是一个麻烦。
• 缺少现在主流的遍历技术，和图像对比。

自研和Page Object封装模式

如果，业务特殊（特定组件，xpath都识别不了的控件）或者有强大的资源来进行支持的话，是可以直接采用代码方式来调用底层的webdriver的API来进行框架自己研发，这样的话就可以对业务进行定制，封装。国外使用的比较多的是UI自动化测试工具-- Selenide

这是一个比较新的工具，国内应该还没有多少人用它(资料也比较少)。如果需要使用需要去阅读英文文档。

Selenide是一个由SeleniumWebDriver驱动的自动化测试框架，具备以下优点：

• 简练的流式API

• 支持Ajax稳定性测试

• 强大的真正页面对象选择器

使用Selenium无需考虑怎样关闭浏览器、处理超时和StaleElement异常、搜索相关的日志信息以及调试测试代码。只需要关心业务逻辑，剩下的交给Selenide完成就好！

Selenide的团队自诩它是一个测试工具而不是一个测试框架。因为它只是webdriver的一个封装，只是他们封装了更好用的API，更稳定的控件搜索机制，更好的异常处理机制等等。底层的实现还是webdriver。所以他们认为并没有伟大到开发了一个测试框架，而仅仅是个测试工具（很谦虚的说~）。所以一切webdriver能做的selenide都能做。当然也可以扩展到只使用webdriver的API

Java版本是selenide，Python版本是selene

光有测试工具还不行，一般还需要TestNG这样的测试框架来执行，还有断言框架assertJ，报告框架Allure
或者其他的，把它们组合起来使用，才是最有效果的，不过这样的话，上手难度可能会非常大。

Page Object模式

image

• 用例层：测试人员编写测试用例代码的地方，可以调用page层和封装层。
• page层：一个页面一个类，包含该页面的业务逻辑封装以及部分控件定义。
• 封装层：根据业务需要，封装常用的业务逻辑(相比于page层的业务逻辑封装，它的范围更广，有些时候是跨页面的业务逻辑。 属于模块级的业务封装)

封装层设计规则

所有导航，页面辅助以及会跨越多个页面的逻辑均抽离为公共模块，进行封装。

image.png

如上图的导航，二级导航以及页面辅助功能都会在不同的主页面上出现。为几乎所有页面 一级导航都会用到， 二级导航为该模块下所有页面会用到。 页面辅助功能为不同的页面会用到不同的页面辅助功能。这些跨页面都会使用到的功能，我们进行封装。哪个页面需要用到就去调用。以此来达到代码复用的目的。

Page层设计规则

每个page类只负责自己页面的逻辑

page类遵循一个原则---- 产品UI上这个页面能做什么， 这个page就只能做什么。 不准许跨页面逻辑合并在一个中实现(页面可以有跨页面和模块级功能，但是具体每个页面的逻辑必须由每个页面自己实现)。 出现多个页面共用的功能参考上一条规则将其抽离为共用的模块封装。

页面的命名规则需要以Page为结尾。 封装层(共用逻辑)不得使用Page结尾
页面较多的时候用来区分页面和共用逻辑的规则

每个页面以封装业务逻辑为主，通过参数控制调用不同的业务逻辑。 无特殊情况下不要让外界知道控件的信息。

当一个页面中的功能模块之间有数据依赖的时候。每个模块自己负责提供对外接口。

比如测试模型中心或者预估服务的时候，首先必须要有模型事先产出。而产出一个模型需要在模型IDE中执行很复杂的步骤，跳转多个页面。 那么模型IDE负责对外提供一个封装了所有逻辑的简单接口对外使用。 调用方只需要传递一个模型训练算法的默认配置就可以产出相应算法的模型出来。 至于里面如何创建project和dag， 使用什么数据，怎么抽取特征等等都不是调用方关心的。 他们只要一个模型出来，至于这个模型怎么出来的逻辑，不要暴露给调用方。

用例编写规则

case中涉及UI上创建的实体名称，比如项目，数据，模型，用户等都需要使用随机名称。 不能使用固定名称。 以防一个环境多次运行的时候因为名称冲突而失败

case中不准许出现页面元素信息，所有页面元素的封装和业务逻辑的封装要写在page层中

在这样的划分当中所以，脚本在做什么一目了然。这就是可读性，我们做的事情跟之前没什么分别，但是我们把责任划分的更详细，脚本中只剩下业务逻辑。我们有一个原则就是脚本中只有业务逻辑。其他一切不相关的要不交给框架，要不交给其他层的模块。

macaca框架

介绍

structure

Macaca是一套完整的自动化测试解决方案，基于node.js开发。由阿里巴巴公司开源：

地址：https://github.com/macacajs/

特点：

同时支持PC端和移动端（Android、iOS）自动化测试。

支持JavaScript（Node.js）、Java、Python。

Macaca 是一套面向用户端软件的测试解决方案，提供了自动化驱动，环境配套，周边工具，集成方案，旨在解决终端上的测试、自动化、性能等方面的问题。

Macaca 是 Monkey 的一种，含义引自(Monkey Test)，取灵动、敏捷之意。

多端支持

随着移动时代和智能终端时代的到来，为给用户带来更优质、完整的体验，我们的产品已经遍布各终端，同时单一的运行时架构往往不能满足工程的需要。Macaca 支持主流的移动技术平台 iOS，Android，以及两大平台的混合运行时 Webview，也支持以往的桌面端浏览器。

Macaca 的底层设计便于端的横向扩展，会根据开发平台提供的测试驱动及时调整集成方案。

标准化

Macaca 提供了标准化的驱动层，消除了各技术平台测试技术栈的差异。用户只需要遵从 W3C webdriver 标准即可多端无忧，理解成本降低。

多语言栈支持

Macaca 提供 Node.js, Java, Python 三大主流的语言栈，方便工程师和所在团队选择合适的开发语言。由于 Macaca 的工具链基于 Node.js，这个因素使得 Node.js 技术栈提供的支持和周边工具会相对多。Java 与 Python 有大量用实践，社区共享与贡献较多，也是很好的选择。

集成和融合

Macaca 提供了多种持续集成方案和功能模块，方便集成到研发和测试的各个环节。

社区生态

Macaca 拥有庞大的用户群，自我生长的开源形态和优质的中文社区环境，更多请见帮助支持。

Macaca执行流程图

flow

优点

• 有强大的社区生态，开源，持续维护中。
• 环境有配套，可以解决很大一部分问题，并且容易上手。

不足之处

• 依赖太多，配置困难。
• 没有一个良好的设计模式。

总结

从UI自动化的价值来看，整个UI测试应该是测试金字塔中，最上层建筑，维护成本和执行成本也是最大的。

image.png

• 公司价值上：没有UI自动化测试并不影响公司和测试团队的生存
• 个人价值上：没有UI自动化并不影响找工作，但是会影响找大公司的工作
• 兼容性测试价值：没有UI自动化测试，最起码兼容性测试是不可能做好的。所以当你没有UI测试的时候，你只能祈祷你们的研发队伍很给力。本质只是看这几十万是怎么花的，要么是研发凭能力省下来、要么是测试凭能力省下来，要么是第三方公司凭能力挣的，要么是用户体验受损导致公司损失掉的。
• 非功能测试：内存泄漏、页面性能、弱网都需要对具体页面的访问，人手是否可以足够快的可以重复的在各种不同场景下巡回测试，或者有理由不测试，比如AB测试或者质量监控很好。
• 持续集成/持续交付：研发平均每几个小时就会打出来他觉得有信心的测试包，你如何快速的做出质量反馈。
• 政治价值观：你如何应对CXO们对测试团队执行效率的吐槽？减少承接的需求、降低公司的发展速度、加人、找外包还是提高手速？你需要有应对的策略。

如下场景可以不用UI自动化

• 你的产品单元测试、接口测试非常成熟，而前端团队很给力，基本不出UI问题，有靠谱的研发团队在为质量兜底
• 你的自动化水平很差，搞自动化非但不成功还让公司损失惨重，你用血一般的教训成功让领导接纳了UI自动化测试无用论。
• 你的公司2个月发布一个大版本，你有为期2周以上的测试时间可以充分的奢华浪费
• 你的公司是富甲一方的甲方，你有数十人的外包测试团队可以帮你甩锅
• 你的工作国企铁饭碗，即使用户骂娘你仍然可以高枕无忧，比如1230x（已经改版了）
• 你是CXO的小舅子

合理使用UI自动化

策略改进方案

• 使用分层测试策略，控制UI自动化测试规模
• 少数核心用例交给自动化测试
• 大部分的基础回归测试交给自动遍历
• 新功能测试交给人工测试

技术改进方案

• 良好的维护模型：PageObject或者其他更加简单的封装
• 更好的框架支持：增加Watch，智能等待，失败重试等机制。

打算采用的方案

考虑到生态环境和多平台的发展。
选择Macaca来进行UI自动化将会是不错的选择。
虽然会使用Macaca来做，也同时会采用分层模式的思想Page Object来进行。对于这样的结合，会对我们有着相当大的启发，使得项目更加容易进行维护。符合UI自动化的原则思想。

RF是一款非常不错的框架，在UI方面也有非常多公司采用，如果采用RF框架，我们将要做非常多的扩展，比如基础的功能遍历，更好的断言机制，支持Ajax等等，毕竟Selenium2library的API已经封装了很久了，现在的前端技术也是日新月异，如果需要二次开发这么久，也会非常消耗时间，并且做出来的成果也不见得会有多好。关于再次封装都可以选Selenide了。还不需要我们做这么多事情。这样会需要有更高的代码基础。不符合UI自动化测试的原则。