APP的UI自动化测试框架及平台化探索

顾铮,10年+测试及测试开发相关经验,2014年加入京东,曾主导设计开发UI测试框架,参与CI测试平台建设,现负责iOS侧的工具,框架建设。在UI自动化,性能测试,单元测试方面有较深入研究,在App,web端等有较丰富的测试开发和设计经验。

>>>>

写在前面

关于UI测试的文章,多数是通过架构的演进,或是重构,或是推翻重做来讲述的。今天我想讲述我的“一步到位”的测试框架设计。当然,这个“一步到位”是加引号的,并不是说没有持续的优化或改进,而是指基础结构的稳定;这个“一步到位”是基于之前的失败经历和很多思考而得出的,总结个人经验,避免其他接触不多的同学走弯路、踩坑。

UI自动化测试,即通过模拟手动操作用户UI界面的方式,以代码方式实现自动操作和验证的一种自动化测试手段。在十年前,那时候还是PC web的天下,以Selenium驱动web UI的自动化测试还是主流。五年前,当测试人员逐渐熟悉了Selenium API编写UI自动化用例时,互联网的主战场已经从web端逐渐过渡到了app端。现在,app在UI自动化方面的框架已经比较成熟,例如我们已经使用了三年多的appium,还有诸如uiautomator、espresso、robotium等等。

>>>>

UI能解决什么问题?

1、重复性的功能测试及验证

2、避免疲惫操作时的人为测试遗漏

3、通过UI自动化操作获取其他测试数据的能力

>>>>

UI的优缺点是什么?

在实际应用中,UI自动化可以帮助我们节省人工测试成本,提高功能测试的测试效率。

缺点也是比较明显,随着敏捷迭代的速度越来越快,UI控件的频繁变更导致控件定位不稳定,提高了用例脚本的维护成本,同时定位的不稳定导致用例的可信度降低。

>>>>

UI的应用场景

主要应用于冒烟测试、回归测试、Dailybuild等阶段。

>>>>

UI存在的意义

存在即合理,我们可以先看下软件测试的金字塔模型。

这个模型描述了从单元测试、集成测试,到UI测试的渐进式测试过程。越是底层,用例的执行速度越快,维护成本越低。到了最上层的UI时,执行速度处于比单元测试、接口测试慢,比手工测试快的这种阶段。维护成本上比单元测试,接口测试要高。

那么为什么需要做UI呢?

 

1、实施起来较容易:很多同学都有过这种经历,刚开始接触测试开发时,都是先接触UI的自动化。UI的框架比较成熟,容易上手,相关学习文档比较全面。实施起来一般都不依赖于源码,是比较容易落地的一种自动化测试手段。

2、覆盖范围广:此项是重点。UI上的一次操作的函数触发数量可能会非常多,点击一个按钮,可能触发了内部的几十个或者更多的函数调用。从函数调用数量来看,和单元测试的一个单测用例检查一个函数的逻辑是不同的。UI操作检查的各个模块集成后模块之间的联动逻辑。是集成测试的有效手段,而单元测试是模块内部逻辑的检查。

>>>>

框架优点

>>>>

框架如何避免或降低UI的问题呢?

首先看下架构图

1、用例编写简单,降低上手门槛

由于测试人员的代码编写能力参差不齐,让业务同学可以快速上手编写是基本诉求。在operation层,使用了业界通用的Page-Object模式,即针对页面或模块封装操作方式,这也符合我们的正常认知,在哪个模块应该有什么样的功能操作。所以我们在case层调用operation提供的接口时是非常方便的。下图是一条比较复杂的购物车测试用例。page是模块集合,main是首页接口,switchView为封装的切换操作。

2. 降低用例维护成本

当UI控件发生改动时,我们需要对对应的控件定位方式进行修改。一般地,一个控件会被多条甚至几十条用例引用到,那么维护成本与引用数量成正比,引用的地方越多,维护成本越大。如何降低控件修改成本是非常关键的。

首先,需要做的是当封装的逻辑发生改变时,不会影响我们用例层的逻辑组织。解决办法:

抽取各个模块的功能接口,在用例层调用统一接口进行操作,与具体的实现无关。具体是执行android的操作逻辑,还是iOS的操作逻辑需要在运行时判断来选择对应的实现类。既能保持调用的一致性,也可以屏蔽不同端的逻辑差异性。当android和iOS操作逻辑一致时可以卸载Adaptor里,当两端操作逻辑不一致时,需要分别在各自端的Operation中实现。

然后,当控件定位发生改变时,不会影响我们在操作层的方法封装代码,把一处控件改动对应多处引用修改的一对多关系变为一对一关系,即无论引用了多少处此控件,只需要修改一处代码。

解决办法:为了使操作层在获取控件时与控件的定位方式解耦,在操作层通过获取自定义ID的方式来得到控件对象。此ID需要在控件的配置文件中定义好,再通过操作层之下的代理层来统一处理。

操作层的操作封装示例如下:

如上图所示,自定义ID为SearchBar,通过调用代理层的getTextBox方法来得到一个文本输入框类型的对象,并调用该接口的清除文本方法。

然后,在对应模块的XML配置文件中添加ID名及控件的定位方式。

其中dependMethod为控件查找方式,内嵌元素为查找的值。由于在编写操作方法时引用的是自定义ID,且ID不会改变。所以在Operation层封装的所有操作是不会因为控件改变而修改代码的。一对一的关系即:控件修改 —> xml配置修改。

通过以上这些设计,大大降低我们在用例编写完成之后的维护成本。

3、底层识别框架(Appium)的可替换性,屏蔽不同框架的差异性API

有的时候,我们需要不止一套控件的识别驱动来帮助我们定位控件或执行操作。比如:如果不用appium,那么使用其他框架势必会带来一些底层的改动,比如由于API的不同而需要重写大部分的查找和操作方法。造成较大的替换成本。那么设计一套自定义的控件接口,与控件识别驱动解耦是一个好的选择,上层统一调用自定义接口进行操作,而控件的实现类可以根据你需要的驱动类进行选择或封装。

4、失败重试机制,提高用例稳定性

由于用例执行的稳定性直接决定用例在业务落地时的可信度,所以提高用例稳定性是必要的,框架提供了失败重试的机制来间接保证稳定性。即当监听到用例执行失败异常时,重新执行当前用例逻辑,如果执行成功,覆盖当前用例的执行结果;如果失败,重新执行,直到超过重试次数。

5、协助快速定位问题的能力

框架提供了日志和失败时截图进行分析和定位问题的能力。

6、数据统计的能力

用例的执行信息等数据都是由TestNG提供,再做自定义处理。

>>>>

UI测试的落地指标

1、用例执行通过率(稳定性)

一般地,执行通过率达到95%以上时,对功能测试同学的帮助才是有意义的。通过率达不到的时候会大大增加执行用例同学的运维成本。把大量时间放在了排查不稳定用例的问题上。

通过率的定义:(成功数 / 成功+失败+跳过数 )* 100%

2、核心用例覆盖率

覆盖率定义:已实现自动化用例数 / 功能测试核心用例总数 * 100%

一般地,总有一小部分手工用例是无法通过UI来实现的,或者就算实现了也非常不稳定。也就是说达到100%的覆盖率是基本不可能的。此项指标的意义在于可以客观的反应通过自动化手段代替手工劳动的覆盖比例。一味的提高覆盖率是不可取的,保持用例的通过率,提高用例的稳定性是重点。

3、资源投入度

这个指标其实是一个通用指标,但它与我们具体的落地密切相关。更多的时候,前2个指标都会依赖于此项指标。自动化测试需要的是持续资源投入,只有自上而下的推动才能取得更好的效果,体现它该有的作用。

>>>>

UI测试对接CI平台

由于appUI框架是线下本机环境执行和操作手机,可以搭建一个线上的公共平台来选择和触发UI的执行。作为一种常规的,自动化得测试类型嵌入到敏捷测试流程中。

以下是对接CI平台的执行简图:

原文地址:https://www.cnblogs.com/yunfeioliver/p/9285904.html

时间: 2024-10-14 04:55:08

APP的UI自动化测试框架及平台化探索的相关文章

数据驱动 vs 关键字驱动:对搭建UI自动化测试框架的探索

UI自动化测试用例剖析 让我们先从分析一端自动化测试案例的代码开始我们的旅程.以下是我之前写的一个自动化测试的小Demo.这个Demo基于Selenium与Java.由于现在Selenium在自动化测试的统治地位,并且随着Selenium 4的即将发布,在未来很长的一段时间里这种统治地位应该还会持续,所以我的这篇文章还都是基于Selenium与Java的. 自动化测试小Demo 它要测试的东西其实是要看一下百度搜索能不能返回兴业银行的官网.我们分析一下这段代码都包含些什么东西. 第一,这段代码包

Python+Selenium搭建UI自动化测试框架

Python语言是非常强大的编程语言,很多时候也拿来当脚本语言用. Selenium是web应用测试工具,支持Java.Python等多种语言脚本,支持Chrome.Firefox等多种主流浏览器.主要实现的就是模拟人使用web应用,自动的打开浏览器.打开应用.进入应用进行各种模拟业务操作等等. 接下来,一步一步带领大家实现下Python+Selenium实现使用脚本自动发微博的功能. 1.Python安装 一般Linux系统自带了Python,Windows系统可以参考本人之前文章 [Pyth

基于python语言下的UI自动化测试框架搭建(一)

pycharm工程展示 最近在搭一个UI自动化测试框架,想把整个搭建过程分享出来,如果有不对的地方,希望大家能够指正,首先创建一个名称为,antomation_framework_demo的工程文件, pycharm中工程及文件如下图所示: config:文件中包含调用的浏览器驱动及打开的URL地址 framework: 1.包含定义的页面基类,封装常用的页面操作方法 2.包含打开浏览器操作以及在相对路径下获取浏览器driver 3.日志处理方法 logs:执行日志以时间格式保存在该文件夹下,如

简单Web UI 自动化测试框架 pyse

WebUI automation testing framework based on Selenium and unittest. 基于 selenium 和 unittest 的 Web UI自动化测试框架. 特点 默认使用CSS定位,同时支持多种定位方法(id\name\class\link_text\xpath\css). 基于Selenium二次封装,使用更简单. 提供脚手架,快速生成自动化测试项目. 自动生成/reports/目录,以及HTML测试报告生成. 自带断言方法,断言tit

避免重复造轮子的UI自动化测试框架开发

一懒起来就好久没更新文章了,其实懒也还是因为忙,今年上半年的加班赶上了去年一年的加班,加班不息啊,好了吐槽完就写写一直打算继续的自动化开发 目前各种UI测试框架层出不穷,但是万变不离其宗,驱动PC浏览器的基本上底层都是selenium,驱动无线app和浏览器基本是appium.monkey之类的,底层都是基于官方支持的自动化测试框架开发而来,然后上层又做了各种封装 首先在开始计划开发自动化时,第一步是了解目前已有的自动化开发技术,上面说了,最底层的就那几种,根据实际要去测试的业务需求选择合适的自

UI自动化测试框架之Selenium关键字驱动

一.原理及特点 1. 关键字驱动测试是数据驱动测试的一种改进类型 2. 主要关键字包括三类:被操作对象(Item).操作(Operation)和值(value),用面向对象形式可将其表现为Item.Operation(Value) 3. 将测试逻辑按照这些关键字进行分解,形成数据文件. 4. 用关键字的形式将测试逻辑封装在数据文件中,测试工具只要能够解释这些关键字即可对其应用自动化 二.准备 使用工具:eclipse 用到的第三方jar包:poi.jar(操作excel);selenium.ja

一个简单的Web UI自动化测试框架Java实现

简介 原创文章,转载请注明出处 这个框架的名字叫OAT,全称Object-Oriented  Automation Test.这个框架的思想借助于Tellurium框架.他的主要功能是将页面信息及行为存储在Java 对象中,然后在脚本中引用页面的行为.自动化程序最终由许多的页面行为组成.这个框架默认使用Selenium1驱动,并且可以通过编程使用其他驱动,因 为OAT是面向接口的. 以下以google home page的demo为例,介绍这个基于Annoation和反射的框架基本运行原理. p

《软件测试自动化之道》- 基于反射的UI自动化测试框架 - UI Automation Test Framework

测试自动化程序的任务 基于反射的ui测试自动化程序,要完成的6项任务: 通过某种方式从测试套件程序中运行待测程序(AUT: Applicaton Under Test),以便于两个程序之间进行通信 操纵应用程序的窗体,从而模拟用户对窗体所实施的moving和resizing操作 检查应用程序窗体,确定应用程序的状态是否准确 操纵应用程序控件的属性,从而模拟用户的一些操作,比如模拟在一个TextBox控件里输入字符 检查应用程序控件的属性,确定应用程序的状态是否准确 调用应用程序的方法,从而模拟一

基于APPIUM测试微信公众号的UI自动化测试框架(结合Allure2测试报告框架)

框架初衷 前两周组内的小伙伴跟我说她现在测试的微信公众号项目(保险)每次上新产品时测试起来很费时,存在大量的重复操作(点点点),手工测试每个产品可能需要半天到一天的时间,复杂的产品需要两天. 由于保险下单的过程中字段比较多,输入费劲的同时测试用例也很多(不同年龄段.工种.有无社保等),且!每个产品的页面都有部分差异! 问我能否基于UI自动化提高她测试新产品的测试速度,同时用于上线时生产的验证. 因为我写过微信公众号页面的UI监控脚本,也尝试过基于appium的多机并发测试,于是我就想,能否搭建一