如何才能让UI自动化收益更大？

      在公司推行AppUI自动化的时候，有同学反馈说UI自动化维护成本大，也不发现Bug，没有什么意义？在网上也看到不少类似的论调，但是为什么UI自动化一直存在呢？其实任何事物的存在都是有其价值的，只是我们没有正确理解和使用才会感觉到没有价值。那如何才能让UI自动化的收益最大呢，那我们就先来分析一下UI自动化，正确理解它才能更好的使用它。

一，何为没有意义？

      在测试开发同学当中，有一部分这样的同学，他们要开发个什么工具或是平台，总想着能解决多少问题或是改变业务同学的测试习惯，或是有什么颠覆的突破。然后就规划出一个宏大的项目，几乎什么都要包含进来，结果就是长时间没有产出，最终的绩效啊，领导的支持啊，都不能如愿，自己也没有做下去的动力了。

       我们开发工具或是平台的初衷肯定是解决问题的，但是解决问题是有针对性的，一般万能的东西是不存在的，也不要想着去做出什么有颠覆的突破或是意义重大的东西。先不怀疑自己的能力，就从时间和资源配置方面来说，领导就不会支持你的，公司也不允许。与其构思去做一艘航空母舰，不如先开发一个打火机，先解决业务测试中的点火问题，这就是有意义。至于那些能提高多少测试效率，降低多少Bug，提高多少覆盖率等指标，这个可以作为评估的标准，但不要期望一下子就能达到理想的效果，因为前后相关影响因素太多，不要因此就怀疑自己。

二，UI维护成本大，投入产出比小

      无论你公司的产品是ToB还是ToC，只要是与客户进行交互的，都会经常变动的，这是产品特点决定的。如果你的产品十年如一日地没有任何变化，那也就意味着走到了尽头。同时加上各种节日的运营活动，添加的各种新功能，产品界面肯定会变化的，再加上发版什么的，变化的就无法控制了。了解了这些，就知道如果要保持你的UI自动化可用，必须经常维护，这也是没有办法的事情。

      这就要求在做UI自动化测试的时候，前期就必须考虑到自动化介入的时机，覆盖率范围，维护的难易程度等等，不是说写了自动化测试用例，能执行就万事大吉了。在考虑完这些事情后，再加上自动化用例的使用场景，使用方式，使用频率等方面的优化，就能提高投入产出比，而不是直接就否定UI自动化的价值。

三，正确认识UI自动化

      自动化测试的介入是有特定的时机的，它的使用场景和使命也是有限制的，先前讨论过自动化测试不是万能的，也介绍自动化测试的使用方式。这里就再介绍一下UI自动化测试，UI自动化测试有如下特点：

1，UI自动化必须在产品稳定后再介入，同时开发核心业务流程的用例；对于容易变化的业务，就不要写用例了，维护的太频繁成本过高。

2，UI自动化用例注重页面的展示检测，会在特定的流程下去遍历相关页面，所以不要把太重的业务逻辑放到UI自动化测试中，会影响执行时间，可以结合接口自动化用例来提高执行速度。

3，UI自动化在集成测试阶段进行核心业务场景的检测，兼容性测试的检测，结合多线程并发可以同时测试多个流程器或是手机设备，以提高执行效率。

4，不要期望UI自动化能发现很多bug，这样是不正常的；如果在集成测试阶段还能发现很多bug,那测试流程就不能进入集成测试，正常的测试阶段就不合格。

      了解了UI自动化测试的特点后，在正常的业务场景就知道如何使用了；只要正确使用UI自动化测试，你就不会抱怨它没有什么使用，带不来什么价值了。你可以想一下一个App的发版，Android和iOS两系统，每个系统需要兼容Top10的机型，集成测试的checklist有500条用例，你就知道工作量有多大了？而这些工作可以在晚上自动完成，第二天看一下结果，想想是不是挺爽的？

四，如何开发收益高的UI自动化测试用例？

如果在公司对应的业务中要开展UI自动化测试，应该如何才能让领导认可，同时也能达到收益较高呢？这其实是一个比较全面的过程，我们逐步分析一下：

1，与领导交流，达成共识

       从UI自动化的特点，公司现有的业务情况，遇到的能用UI自动化解决的问题，自动化实施后最终能达到的收益等方面与领导进行讨论，帮助他了解这个项目的全部情况。这样一来不会让领导对项目产生过多的期望，比较说能发现多少bug ,替代多少人工等超出UI能力的预期。同时也能很好的表达出你这个项目能达的到收益 ，带来的效果。

2，分析业务，选择合适的切入点

      UI自动化测试达不到预期的一个很重要的影响点就是测试用例选择的不合理，在不少同学开发自动化用例的时候，没有先对用例进行筛选，就拿一个功能模块来一个用例一个用例地去写。最后发现用例执行时间长，而且还没有发现什么问题。

     UI自动化原理决定了它不可能像接口自动化那么快，所以也不能像接口一样进行全面覆盖。在开发自动化用例前，我们需要对用例进行筛选：（1）选择稳定的业务，对那些处于探索期，需要经常变化的业务模块，不建议开发自动化测试用例。（2）UI自动化用例要针对核心业务，核心界面进行测试；（3）针对核心业务的用例进行筛选，第一步选择P0级别的，适合做自动化测试的用例。然后有计划地去逐步覆盖其他的用例，以提高用例覆盖率。

3，合理规划项目架构

       一个好的自动化项目不是能写出自动化用例，执行没有问题就可以了。如果项目规划不好，后期随着用例的越来越多，你会掉进痛苦的深渊，而且很难出来。一个好的自动化项目必须考虑以下几点：

（1）选择大众化的自动化测试框架。现在无论何种自动化测试项目，业界对应的开源框架就多如牛毛，而我们要选择大众化的框架，这样的框架经过了多个项目的检验，可用性强bug少，而且你将来可能遇到的问题，也容易找到答案。如果使用小众的框架，框架级别的bug就能让你疯掉，而且你也找不到解决办法。比如，WebUI自动化必须选择WebDriver，如果你选择了Karate,你就知道什么叫坑了？

（2）开发语言的选择也必须主流，如java或python，不仅框架对应的支持包完善，而且遇到的问题也有比较好的解决办法。早期我做WebUI自动化测试的时候，选择了PHP,虽然也能编写用例，执行起来也没有问题，但是开发过程中遇到了问题解决起来非常麻烦。

（3）写第一行代码前做好架构设计，这是不少人不会注意的问题。虽然不做精心设计的项目也能执行起来没有问题，但是后期的团队开发，用例维护就非常麻烦了，更不用说二次开发或是接入测试平台了。所以前期做架构设计的时候就必须考虑，如何管理用例，如何维护测试数据，如何跟踪问题，如何命令行执行所有用例，如果何定制化执行用例等等问题。

4，灵活编写用例

测试用例的编写，尤其是UI自动化用例，基本上 就是把手工用例一步步转化成自动化用例，调试执行即可。当然要先对常规的业务操作做抽象封装成类，从而减化操作。但是经过多年编写UI自动化的经验，发现以下经验还是非常有用的：

（1）合理规划用例，减少操作步骤。众所周知，UI自动化用例执行起来比较慢，所以在提高执行速度的时候，不仅可以使用多线程，也可以优化用例执行步骤。如合理规划用例执行步骤，在WebUI自动化测试时，通过打开指定的URL代码一步步进入相应的页面；通过接口构造数据，代替页面级别的操作构建数据。

（2）灵活选择定位方法，提高元素查找速度。自动化测试框架一般会提供非常多的元素定位方法，我们常用的ID，CSS, Xpath，Name等等，你要了解这些定位方法实现的原理，以属性值定位为首选，xpath定位相对来说就较慢。再者，也可以与开发合作，让他们将我们要做自动化的元素加上固定的元素属性。

（3）灵活设置检测点。检测点是我们判断用例执行结果的，也是决定用例通过率的关键。所以在设置检测点的时候，要根据用例来针对性地，灵活设置检测点。不要设置的太多，以模糊检测来代替完全匹配，通过图像识别来检测等，不能检测动态变化的元素或是数据，以此来提高用例的通过率，让用例真正能发现Bug.

     一块璞玉对于普通人来说，可能就是一块石头，对于高明的玉石匠人来说，才是艺术品是珍品。所以能否发挥出UI自动化的价值，和UI自动化并没有太大的关系，只要你能灵活使用，就可以帮助你完成很多日常繁琐的工作。而且可以用来做性能测试，稳定性测试，竞品分析等等需要反复测试才能拿到结果的测试。掌握扎实的UI自动化测试知识，结合你的业务特点，多了解一下业务相关的技术，使用方法，然后加上你自己的想像力，就能让它大放异彩！