如果一个组织真正重视软件质量，UI自动化测试是有必要做。有如下几点理由:
1.任何自动化工具都是在简单、机械、重复的任务场景下最能发挥作用，UI测试非常符合这个特点。
2.对于很多组织来说，UI测试是当前耗费测试团队人力最多的环节，大部分专职测试人员日常工作就是UI测试。“工欲善其事必先利其器”，测试人员也需要自动化工具来提升其日常工作效率。
3.无论后台多复杂、多重要，用户接触的终究还是前端界面。现在的软件除了后台逻辑之外，还有很多前端脚本逻辑和样式，单纯靠后台接口/单元测试，无法证明用户端的可用性。
4.自动化测试确实是要分层的(单元测试、接口测试、UI测试)，从测试团队的角度来说，非常希望有足够充分的单元测试和接口测试来保证提测版本的质量，但实际情况往往是开发团队所维护单元测试和接口测试也是非常不充分、甚至几乎没有。

归根结底就是三个字“不稳定”!测试环境构建不稳定、被测软件界面不稳定、测试框架运行不稳定。
其实只要适当的过程改善和开发团队配合，这些问题基本都是能够解决或者明显改善的。以测试环境为例，在纯手工测试阶段，有些项目的测试环境可以被随时停止、随意更新。这样对手工测试也是有影响的(工作进度受干扰、测试计划被打乱)，但是可以忍受。自动化测试会对测试环境提出更规范的要求，至少不能随时停止，这就需要对研发测试过程进行必要的改善。然而被测软件界面不稳定、测试框架运行不稳定，就没有测试环境不稳定那么容易解决了。这里面主要涉及与开发团队的配合、测试框架的设计。

与开发团队配合提高UI端的可测试性
在分层自动化测试理论中，提到单元测试和接口测试是比较稳定和容易实现的。除了底层代码受用户需求变化影响相对较少、编写自动化用例成本较低之外，其实隐含了一个很少被提及的原因:单元测试和接口测试通常是开发团队内部的工作，当发现一个方法或服务接口设计的不合理导致自动化测试用例编写困难的时候，即便没有直接对应到一个缺陷上，他们也通常会进行调整，使代码设计实现更加优化、更规范。
UI自动化测试需要开发团队配合指的当然不是不允许开发团队随便修改UI实现，指的主要是约定并遵守良好的UI编码规范、及时修正未对应功能缺陷但却影响UI自动化测试的编码问题等。UI自动化测试最关键的步骤是“定位页面对象”

匹配开发模式设计自动化测试框架
自动化测试框架的设计方法有很多，现在主要有两类模式:
一是采用统一UI类库
企业或项目组采用统一的前端UI组件库进行开发，如，JQuery。
二是采用统一开发框架
企业采用统一开发框架，包括UI开发工具(甚至采用UI模型驱动开发)，在采用统一UI类库的基础上，通过工具或模型来确保UI代码的规范性和一致性。
在这两种模式下由于大量的UI类库，前端会解析出大量的、动态的、机器生成的页面源码，不再适合采用传统的脚本录制和页面对象识别的方式来制作测试脚本。
对应这两种开发模式，笔者经常采用的自动化测试框架设计模式是UI组件封装模式。
PageObject模式是自动化测试最常采用的模式，但是在基于UI类库开发的系统中，页面对象数量太多，而且很多工具识别页面对象也变得更加的不准确和不智能。
所谓UI组件封装模式，指的是根据开发所采用UI类库提供的UI组件类型(比如，input、select、date、button、tree、grid等)对应提供相应的自动化测试控件。
将每类UI控件的定位方式和交互逻辑都封装到对应的自动化测试控件中，测试人员通过简单的DSL语言即可描述测试过程，具体的解析执行交给测试框架进行统一处理。
通过这种测试框架设计模式，可以降低脚本编写难度和脚本代码量，提高对象识别和执行稳定性，将UI类库变更带来的影响限制到测试框架中，不往测试脚本中扩散。
开发框架对接模式。当企业采用了统一开发框架，特别是通过工具生成大量UI代码时，我们可以先了解哪些代码是开发人员写的、哪些代码是工具生成的、哪些信息是在开发框架中统一管理的。
在自动化测试框架设计时，充分利用这些资源可以大幅提升框架的易用性。
如下图所示，对接开发框架之后，我们可以轻易的一键获取项目完整菜单结构(作为测试用例大纲)，并且准确识别页面对象。
有了完整的测试用例大纲和页面对象之后，测试脚本的编写就会更加容易。另外，当未来项目版本升级之后，可以通过再次探测对比，识别页面对象的变更及影响的测试脚本，进而提醒测试人员批量修改脚本。降低在回归测试过程中发现脚本执行不过，带来的反复修改、反复回归验证的成本。