转载:https://www.jianshu.com/p/3a03a0e87aba?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation
当前一切UI自动化都是建立在selenium2的API基础上的,最底层都是调用的模式。
UI自动化主要的体现应该在易用性、稳定性、可读性、可维护性、可扩展性当中。
Robot Framework是验收测试和验收测试驱动开发(ATDD)的通用测试自动化框架。它具有易于使用的表格测试数据语法,并使用关键字驱动的测试方法。其测试功能可以通过用Python或Java实现的测试库来扩展,用户可以使用与创建测试用例相同的语法从现有的关键字创建新的高级关键字。
Robot Framework是基于python的测试框架,基本上python能做到的事情它都能做到,既然如此为什么我们不直接使用python呢? 因为ATDD主要主角是没有技术经验的用户,怎么利用好懂的自然语言让用户可以参与到测试流程之中就是Robot Framework 的一大卖点。
这个UI自动化框架应该说是市面上使用的最广泛的了,又有别称为“关键字”框架,因为其上手简单,只需要封装好关键字,使得不懂代码的人也可以快速写出用例,采用的是BDD设计思想。
它有三层结构:
适配层:用例使用 tsv 格式编写,采用的主要是关键字驱动的形式。
核心层:提供了 setUp,tearDown 方法,并有合适并足够的断言功能和异常捕获功能。
工具层:具有众多的 Library 可供选择,可以结合不同的工具测试各种领域的软件。
由于框架本身的强大扩展性,可以使得进行二次开发来完成符合自身业务的特性,而且自带的报告也非常好看。
选择Robot Framework的好处
高级架构设计
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
不足之处
如果,业务特殊(特定组件,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
封装层设计规则
所有导航,页面辅助以及会跨越多个页面的逻辑均抽离为公共模块,进行封装。
image.png
如上图的导航,二级导航以及页面辅助功能都会在不同的主页面上出现。为几乎所有页面 一级导航都会用到, 二级导航为该模块下所有页面会用到。 页面辅助功能为不同的页面会用到不同的页面辅助功能。这些跨页面都会使用到的功能,我们进行封装。哪个页面需要用到就去调用。以此来达到代码复用的目的。
Page层设计规则
每个page类只负责自己页面的逻辑
page类遵循一个原则---- 产品UI上这个页面能做什么, 这个page就只能做什么。 不准许跨页面逻辑合并在一个中实现(页面可以有跨页面和模块级功能,但是具体每个页面的逻辑必须由每个页面自己实现)。 出现多个页面共用的功能参考上一条规则将其抽离为共用的模块封装。
页面的命名规则需要以Page为结尾。 封装层(共用逻辑)不得使用Page结尾
页面较多的时候用来区分页面和共用逻辑的规则
每个页面以封装业务逻辑为主,通过参数控制调用不同的业务逻辑。 无特殊情况下不要让外界知道控件的信息。
当一个页面中的功能模块之间有数据依赖的时候。每个模块自己负责提供对外接口。
比如测试模型中心或者预估服务的时候,首先必须要有模型事先产出。而产出一个模型需要在模型IDE中执行很复杂的步骤,跳转多个页面。 那么模型IDE负责对外提供一个封装了所有逻辑的简单接口对外使用。 调用方只需要传递一个模型训练算法的默认配置就可以产出相应算法的模型出来。 至于里面如何创建project和dag, 使用什么数据,怎么抽取特征等等都不是调用方关心的。 他们只要一个模型出来,至于这个模型怎么出来的逻辑,不要暴露给调用方。
用例编写规则
case中涉及UI上创建的实体名称,比如项目,数据,模型,用户等都需要使用随机名称。 不能使用固定名称。 以防一个环境多次运行的时候因为名称冲突而失败
case中不准许出现页面元素信息,所有页面元素的封装和业务逻辑的封装要写在page层中
在这样的划分当中所以,脚本在做什么一目了然。这就是可读性,我们做的事情跟之前没什么分别,但是我们把责任划分的更详细,脚本中只剩下业务逻辑。我们有一个原则就是脚本中只有业务逻辑。其他一切不相关的要不交给框架,要不交给其他层的模块。
介绍
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自动化
策略改进方案
技术改进方案
考虑到生态环境和多平台的发展。
选择Macaca来进行UI自动化将会是不错的选择。
虽然会使用Macaca来做,也同时会采用分层模式的思想Page Object来进行。对于这样的结合,会对我们有着相当大的启发,使得项目更加容易进行维护。符合UI自动化的原则思想。
RF是一款非常不错的框架,在UI方面也有非常多公司采用,如果采用RF框架,我们将要做非常多的扩展,比如基础的功能遍历,更好的断言机制,支持Ajax等等,毕竟Selenium2library的API已经封装了很久了,现在的前端技术也是日新月异,如果需要二次开发这么久,也会非常消耗时间,并且做出来的成果也不见得会有多好。关于再次封装都可以选Selenide了。还不需要我们做这么多事情。这样会需要有更高的代码基础。不符合UI自动化测试的原则。
作者:我为峰2014
链接:https://www.jianshu.com/p/3a03a0e87aba
来源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。