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

Posted 2020-12-03

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了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的不同而需要重写大部分的查找和操作方法。造成较大的替换成本。那么设计一套自定义的控件接口，与控件识别驱动解耦是一个好的选择，上层统一调用自定义接口进行操作，而控件的实现类可以根据你需要的驱动类进行选择或封装。