为什么要做ui自动化？
你去到一家公司，你的组长给你安排的第一个任务就是说要做ui自动化，然后跟你说一下公司的app是怎么样的，让你看一下给出一个ui自动化的方案和一个完成时间，大概什么时候能把框架搭建好，什么时候能把功能用例转换成自动化用例；听了组长的任务，你可能会一脸懵逼，然后马上去baidu上找能够快速实现ui自动化的方案，可能你的运气比较好，在github上找到了一个别人开源的ui自动化框架，拿过来修修补补，几个星期后你跟你的领导说框架搭建完成了，用例也写了一部分，然后你的组长说要在业务组里推广ui自动化，让大家都来写自动化用例，但是这个自动化用例推广起来比想象的难，业务测试工程师根本不想写自动化用例，自己的业务测试任务就已经够多了，大家根本没有时间去学习这个，而且ui自动化有很多局限性，比如很多场景不能实现、需要一直去维护，到最后你写的这个ui自动化项目则会无疾而终。
这就是绝大多数公司为什么要做ui自动化的原因，没错就是因为领导的一句话，别人有ui自动化我们也要有，而上面这个就是我自己的真实经历，我称这种ui自动化为KPI的ui自动化。
为了避免上面的这种悲剧的再次发生，我们在做ui自动化之前就必须去思考一些事情，为什么要做ui自动化，ui自动化能给我们带来什么？你当前的项目适不适合做ui自动化？
最直观的来讲，就是因为ui自动化能去完成一部分功能测试，然后缩短项目的测试时间，缩短测试时间就等于节约了人力成本，如果ui自动化真正能够达到这种效果的话，那说明你们的ui自动化成功了。但是在真正去做ui自动化的时候你就会发现事情根本不是你想象的这么简单，随着ui自动化用例的执行，接下来就会发生一堆的问题，用例很多都实现不了(用例转换率低)，用例执行起来一堆的报错(用例成功率低)，还要花一堆的时间去看到底是用例写的有问题还是真正的bug，结果到头来ui自动化不仅没有带来正收益，还带来了一堆麻烦的问题，导致使用ui自动化的测试工程师失去信心，最后放弃ui自动化。
如何去做ui自动化？
前面说了一大堆ui自动化存在的问题，那么ui自动化到底还能不能去做，能做的话怎么样才能做好呢？
我觉得最重要的一点就是大家(领导,开发,测试,你自己)要相信ui自动化是能够做好的，而且做好了对所有的人都有益处，领导要支持这个项目，并且愿意给资源(人力，设备)给时间去做；app开发人员也愿意全力配合，规范控件id的编写，一些特殊场景愿意打印一些log辅助我们完成测试；业务测试人员能加入到自动化用例的编写中，因为自动化和业务是不可能分离的，自动化一旦脱离了业务将会变得空洞，毫无意义，而我们的业务测试人员是最了解app中的业务，他们编写自动化用例能够直击我们的业务重点。
有这么多人的支撑，那么我们就可以开始开展我们的工作了，整体的工作我们可能会分为三个阶段去完成：
-
第一阶段-初始期
1.ui自动化框架整体的设计
2.ui自动化选型，核心框架代码的实现
3.挑选部分手动用例，实现自动化
-
第二阶段-增强期
1.自动化测试开始介入到整个开发流程中，帮助业务测试人员减少测试任务
2.增加自动化测试用例转换率(80%-90%)，减少自动化测试用例的非bug失败率(5%)
3.ui自动化集成到自动化测试平台中，可以通过平台直接选择用例执行，查看测试报告
-
第三阶段-稳定期
自动化测试进入一个可持续发展的阶段，根据每个版本的需求去删减用例或者增加新用例
ui自动化的难点
app总是变化，一直要去适配
用例的失败率很高，怎么提高成功率？
多机型适配的问题如何去解决？
使用的开源框架不稳定，老是出各种问题，怎么解决？
很多用例实现不了，或者实现起来很困难，怎么解决？