UI自动化测试

搭建UI自动化测试框架前，我们先考虑几个问题：

1. 产品特性：产品是否是框架式的，几个产品是否复用一套框架？(一般内容为主的产品，都采用框架式的编码，app只是个载体，如果这样，几个产品可以共用一套测试框架)

2. 可行性： 产品是否长期迭代？是否已经稳定？对于短期项目，写脚本没什么意义。可能你脚本还没写完，产品都退市了，一点意义都没有。

   如果产品还不稳定，不停地改结构，那样脚本维护成本也很大，也没啥意义。

   产品是否适合用UI automation来跑？原生比例占多大？元素是否好定位？

   如果可行性不考虑清楚，后面的风险就比较大，脚本设计和维护的成本也比较高。

3. 复用性：如果有个新的项目，你的框架小改是不是也能用在新项目上？如果一个框架都复用性很差，那么它是失败的。

    组织结构：Case 如何组织? 如何展示报告？异常处理怎么处理等等，都是心里要有数的。

4. 扩展性： 是否兼容 Android, IOS? phone, tablet? 是否可以多机一起跑？是否可以监控性能？

    资源：包括时间资源，人手，公司的支持度。还有检查多少功能点？写多大规模？啥时候写？都要考虑清楚。

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操作检查的各个模块集成后模块之间的联动逻辑。是集成测试的有效手段，而单元测试是模块内部逻辑的检查。

框架优点