UI自动化测试一直都是如此的令人纠结，自动化测试初学者总是拿它入门，但有些经验丰富者对其又是毁誉参半，抑或抛出分层自动化测试那个经典的“金字塔”，来说明UI自动化测试还是少做为好。

笔者在从事7年产品研发之后，临危受命转向测试领域，至今又7年有余。期间最关注的一直是UI端/用户端的自动化技术：从Web应用到移动App、从测试到RPA（机器人流程自动化）、从框架研发到应用推广。

本文主要分享为什么要做UI自动化测试、UI自动化测试框架设计要点、团队合作方式、推广注意事项以及其他的心得体会，希望能给各位同行带来思想上的碰撞。

1.UI自动化测试要不要做？

如果一个组织真正重视软件质量，UI自动化测试是有必要做。有如下几点理由：

任何自动化工具都是在简单、机械、重复的任务场景下最能发挥作用，UI测试非常符合这个特点。

对于很多组织来说，UI测试是当前耗费测试团队人力最多的环节，大部分专职测试人员日常工作就是UI测试。“工欲善其事必先利其器”，测试人员也需要自动化工具来提升其日常工作效率。

无论后台多复杂、多重要，用户接触的终究还是前端界面。现在的软件除了后台逻辑之外，还有很多前端脚本逻辑和样式，单纯靠后台接口/单元测试，无法证明用户端的可用性。

自动化测试确实是要分层的（单元测试、接口测试、UI测试），从测试团队的角度来说，非常希望有足够充分的单元测试和接口测试来保证提测版本的质量，但实际情况往往是开发团队所维护单元测试和接口测试也是非常不充分、甚至几乎没有。

所以任何项目中有人拿“分层自动化测试”跟我讲不要做UI自动化测试的时候，我都会先请他们把接口测试和单元测试展示给我看看，然后再跟他们探讨自动化测试的实施策略。

但是从实践的角度，为什么很多质疑的声音呢？

归根结底就是三个字“不稳定”！

测试环境构建不稳定、被测软件界面不稳定、测试框架运行不稳定。

其实只要适当的过程改善和开发团队配合，这些问题基本都是能够解决或者明显改善的。

以测试环境为例，在纯手工测试阶段，有些项目的测试环境可以被随时停止、随意更新。这样对手工测试也是有影响的（工作进度受干扰、测试计划被打乱），但是可以忍受。自动化测试会对测试环境提出更规范的要求，至少不能随时停止，这就需要对研发测试过程进行必要的改善。

然而被测软件界面不稳定、测试框架运行不稳定，就没有测试环境不稳定那么容易解决了。这里面主要涉及与开发团队的配合、测试框架的设计。

2.与开发团队配合提高UI端的可测试性

在分层自动化测试理论中，提到单元测试和接口测试是比较稳定和容易实现的。除了底层代码受用户需求变化影响相对较少、编写自动化用例成本较低之外，其实隐含了一个很少被提及的原因：单元测试和接口测试通常是开发团队内部的工作，当发现一个方法或服务接口设计的不合理导致自动化测试用例编写困难的时候，即便没有直接对应到一个缺陷上，他们也通常会进行调整，使代码设计实现更加优化、更规范。

UI自动化测试需要开发团队配合指的当然不是不允许开发团队随便修改UI实现，指的主要是约定并遵守良好的UI编码规范、及时修正未对应功能缺陷但却影响UI自动化测试的编码问题等。

UI自动化测试最关键的步骤是“定位页面对象”，下面举一个具体的例子，说明开发团队一些分内的、简单的配合，对自动化测试是多么的重要。

定位页面对象的方法有很多，除了ID、XPath、CSS等之外，笔者推荐根据上下文文本定位对象。

以下图界面为例：

如果测试脚本想要使用上下文文本定位对象的方法（如下所示）：

在测试框架中就要解决怎么根据文本准确定位到后面的输入域/下拉框的问题。

其实只要开发团队遵守HTML的基本标准，规范使用Label标签及for属性（如下所示），测试框架中实现上述效果就会变得很容易的。

如果不遵守基本的UI编码规范，每个开发人员都随意编写前端代码，UI自动化测试的成本和难度就会明显增加。

3.匹配开发模式设计自动化测试框架

自动化测试框架的设计方法有很多，笔者这些年一直坚持的自动化测试框架设计核心思想是要“与开发模式匹配”。

以WebUI开发为例，现在主要有两类模式：

采用统一UI类库，企业或项目组采用统一的前端UI组件库进行开发，如，JQuery。

采用统一开发框架，包括UI开发工具（甚至采用UI模型驱动开发），在采用统一UI类库的基础上，通过工具或模型来确保UI代码的规范性和一致性。

在这两种模式下由于大量的UI类库，前端会解析出大量的、动态的、机器生成的页面源码，不再适合采用传统的脚本录制和页面对象识别的方式来制作测试脚本。

对应这两种开发模式，笔者经常采用的自动化测试框架设计模式有：UI组件封装模式、开发框架对接模式等。

1）UI组件封装模式

PageObject模式是自动化测试最常采用的模式，但是在基于UI类库开发的系统中，页面对象数量太多，而且很多工具识别页面对象也变得更加的不准确和不智能。

所谓UI组件封装模式，指的是根据开发所采用UI类库提供的UI组件类型（比如，input、select、date、button、tree、grid等）对应提供相应的自动化测试控件。

将每类UI控件的定位方式和交互逻辑都封装到对应的自动化测试控件中，测试人员通过简单的DSL语言即可描述测试过程（如下所示），具体的解析执行交个测试框架进行统一处理。

通过这种测试框架设计模式，可以降低脚本编写难度和脚本代码量，提高对象识别和执行稳定性，将UI类库变更带来的影响限制到测试框架中，不往测试脚本中扩散。

2）开发框架对接模式

当企业采用了统一开发框架，特别是通过工具生成大量UI代码时，我们可以先了解哪些代码是开发人员写的、哪些代码是工具生成的、哪些信息是在开发框架中统一管理的。

在自动化测试框架设计时，充分利用这些资源可以大幅提升框架的易用性。如下图所示，对接开发框架之后，我们可以轻易的一键获取项目完整菜单结构（作为测试用例大概），并且准确识别页面对象。

有了完整的测试用例大纲和页面对象之后，测试脚本的编写就会更加容易。另外，当未来项目版本升级之后，可以通过再次探测对比，识别页面对象的变更及影响的测试脚本，进而提醒测试人员批量修改脚本。降低在回归测试过程中发现脚本执行不过，带来的反复修改、反复回归验证的成本。

4.什么样的项目更适合做自动化测试

在有些人看来，质量不高的原因是没有采用先进的测试技术，比如自动化测试。

但质量不高的真正原因是项目本身的质量要求就是不高的。否则哪怕堆人肉，也要实现充分的回归测试。如果在这种情况下，如果采用适合的测试框架和实施策略推行自动化测试，通常会取得比较明显的成效。

所以关于什么类型的项目适合做自动化测试，我想回答的并不是什么项目周期长、需要长期维护、采用敏捷开发模式、组织推行DevOps、测试团队有基本编码技能，balabala…

这些年笔者建议不要做UI自动化测试的项目也有很多，一些被我拒绝支持的项目也符合上述特点。后来我在评估一个项目是否适合做自动化测试时，引入了一些非技术指标：

当前测试覆盖度、质量风险及测试投入；

目标测试覆盖度、质量风险，以及如果不引入自动化手段需要的测试投入；

这个目标是谁制定的或者是向谁承诺要达成的？

如果项目没有制定一个在当前人力资源下无法达成的回顾覆盖范围目标，或者仅仅是项目组内定的目标，都没有向老板汇报或向客户承诺此目标。我觉得在这种情况下说要做自动化测试都是不太有诚意的。

对于真心实意要做自动化测试的项目，接下来我会引导他们把现有所有测试用例拿出来，具体分析每个（每类）用例的自动化执行可行性、实现技术方案（UI、接口），以及前期需要投入的成本。

在做完自动化测试ROI分析之后，如果确定要引入自动化测试，那么再辅以适当的自动化测试框架，实施成功的可能性是非常大的。

更多UI测试文章，请前往51Testing软件测试网。