原标题： UI自动化测试该怎么办？
UI自动化测试总是有这样的烦恼。 自动化测试的初学者总是拿它入门，而一些经验丰富的人则对它毁誉褒贬，甚至抛出分层自动化测试这个经典的“金字塔”，表明用户界面自动化测试最好少做。
笔者从事产品研发7年后，受命于危机转向测试领域，至今又有7年多。 在此期间，最引人注目的是UI端/客户端的自动化技术。 从web App应用到移动App，从测试到机器人过程自动化(RPA )，从框架开发到APP应用普及。
本文主要讨论为什么要进行用户界面自动化测试，希望大家能分享用户界面自动化测试框架的设计要点、团队合作方式、推广注意事项和其他心得，给同行带来思想上的冲突。
要进行UI自动化测试吗？
如果一个组织真正重视软件质量，则需要UI自动化测试。 有以下理由
1 .任何自动化工具在简单、机械、迭代的任务场景中工作最多，UI测试非常符合这一特点。
2 .对许多组织来说，用户界面测试是目前消耗测试团队人员最多的环节，大多数专职测试人员的日常工作都是用户界面测试。 “如果想做正确的事，首先是对自己的利益”。 测试人员也需要自动化工具来提高日常工作效率。
3 .不管后台有多复杂多重要，用户接触的毕竟是前端接口。 现在的软件除了后台逻辑外，还有很多前端脚本逻辑和样式。 单纯依靠后台接口/单元测试是无法证明客户端可用性的。
4 .自动化测试确实是分层的(单元测试、接口测试、UI测试)，从测试团队的角度来看，需要足够的单元测试和接口测试来保证测试版本的质量，但开发团队维护的单元测试
所以，如果每个项目都要拿来“分层自动化测试”，让他们不要做UI自动化测试，首先让他们看看接口测试和单元测试，然后再研究自动化测试的实施策略。 但是，从实践的角度来看，为什么会有很多质疑的声音呢？
毕竟，三个字是“不稳定”的！ 测试环境建设不稳定，被测软件接口不稳定，测试框架运行不稳定。
事实上，只要适当的流程改进和开发团队合作，这些问题基本上就能解决，或者明显改善。 以测试环境为例，在纯手工测试阶段，部分项目的测试环境可以随时停止并自由更新。 这也会影响手工测试，但我能忍受。 自动化测试对测试环境提出了更规范的要求，至少不能随时停止。 因此，研发测试流程需要必要的改进。 但是，如果被测软件的接口不稳定，测试框架的工作不稳定，那么测试环境越不稳定，就越不容易解决。 这主要包括与开发团队的合作，测试框架的设计。
与开发团队合作提高UI端的测试性
分层自动化测试理论表明，单元测试和接口测试比较稳定，容易实现。 除了基本代码受用户需求变化的影响相对较小，编写自动化测试用例的成本较低之外，实际上还有很少提到的原因。 单元测试和接口测试通常是开发团队中的一项工作，如果发现一种方法或服务接口的设计不完善使得编写自动化测试用例变得困难，即使不直接对应一个缺陷，代码设计也将更加优化和规范
开发团队需要协助进行UI自动化测试，当然并不是不允许开发团队随意修改UI实现，而是主要承诺遵守良好的UI编码规范，及时修复不支持的功能缺陷，但是UI自动化测试UI自动化测试最重要的步骤是“页面对象定位”。 以下列举具体例子，说明开发团队几个部分内的简单合作对自动化测试是多么重要。
以上图中的接口为例，如果测试脚本希望如何使用上下文定位对象，则测试框架需要解决如何根据文本准确定位到以下输入字段/下拉框中的问题
实际上，如果开发团队遵守HTML的基本标准，并在规范中使用Label标记和for属性，则在测试框架中实现上述效果会更容易。 如果不遵循基本的UI编码规范，而是为每个开发人员自行编写前端代码，将显著提高UI自动化测试的成本和难度。
匹配模式设计自动化测试框架
自动化测试框架的设计方法有很多，笔者这几年一直坚持的自动化测试框架设计的核心思想是“与开发模式一致”。 以Web 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代码时，我们可以先了解哪些代码是开发人员写的、哪些代码是工具生成的、哪些信息是在开发框架中统一管理的。
在自动化测试框架设计时，充分利用这些资源可以大幅提升框架的易用性。
如下图所示，对接开发框架之后，我们可以轻易的一键获取项目完整菜单结构(作为测试用例大纲)，并且准确识别页面对象。
有了完整的测试用例大纲和页面对象之后，测试脚本的编写就会更加容易。另外，当未来项目版本升级之后，可以通过再次探测对比，识别页面对象的变更及影响的测试脚本，进而提醒测试人员批量修改脚本。降低在回归测试过程中发现脚本执行不过，带来的反复修改、反复回归验证的成本。
转载:https://weibo.com/ttarticle/p/show?id=2309404190239705954162返回搜狐，查看更多
责任编辑：