最近来了一个新项目，虽说样子做得大差不差，但是逻辑漏洞百出，体验也不好，存在很多比较明显的Bug，搞得我们测试部很崩溃，反复考虑是否直接给他们冒烟测试不通过。
测试过程中一直在思考是否需要引入GUI自动化测试，前天一直在思考是否需要加入，今天整理这篇文章时还是否定了之前的看法，这也是很多公司决定是否上GUI自动化的一些问题。
GUI自动化测试，可能是很多同学接触到最早的自动化测试类型，记得第一个接触的自动化软件是QTP，录制脚本然后增加断言等设置就行，使用很流畅，很感兴趣。但实际工作中很少使用GUI自动化测试，这期间放弃过、回头过、希望过、坚持过、迷茫过。
一直在思考，GUI自动化为什么不能在实际工作中使用，原因有以下几点：
- 成本高，当然这不是主要原因。现在开源的GUI自动化测试软件越来越多，但还是存在不适用自己公司业务的操作，需要二次开发，二次开发一个GUI自动化测试软件的成本高。
- 流程不规范。这里的流程不只能从开发、测试这二个部门来考虑，而是要从整个项目、整个公司的管理层面来考虑。说到这里我们需要先明白GUI自动化测试的原理：一是根据数据模型，对某些id或某些类型，直接提供各类数据支持。二是不同输入之间的笛卡尔积。说简单点就是获取UI控件，传值，抓取提示信息判断预期结果。很多公司没有控件命名规范，很多错误没有写提示信息，或者在用例执行过程中，操作系统或被测系统可能会突然弹出预期范围之外的对话框，GUI自动化测试有可能就会因此而失败。这些都是一眼能看见的问题，如果是一个很急切的项目，研发时间不够、测试时间不够，千万不能麻木上自动化。自动化测试是公司技术的积累凝聚的体现，不是上自动化而自动化，有了自动化就存在流程上和管理上的调整。
- GUI稳定性。如果页面控件的属性发生了变化，哪怕只是细微的变化，也必定会导致测试脚本的元素定位失败。随机的页面延迟造成控件识别失败，也是 GUI 测试防不胜防的。在实际的项目过程中，GUI测试几乎不可能做到100%稳定，根据我的经验，如果能够做到 90% 以上的稳定性，就非常不错了，这需要整个产品技术团队的共同努力才有希望达成。
- 展现端多，交互多。一个产品里面多个模块的耦合性高，比如，测试用例所依赖的数据被其他用例修改了，这就操作GUI测试失败。如果涉及APP端、PC端、Web端多端交互，没有一个大而全的软件来GUI测试。即使有，开发的复杂性大，不确定性大，开发出来的易用性、稳定性如何，能否跟上技术的迭代和变革，这些都需要打个问号。
界面自动化测试，它最接近用户真实场景，也容易发现问题，但实现成本最高且容易受外部依赖，影响脚本成功率。总体来说，适当的界面自动化测试是有必要的，没必要为了自动化而加入GUI自动化。
以上观点仅代表我当前观点，不代表我未来观点。
GUI自动化思考
原文：https://www.cnblogs.com/mingren666/p/14173296.html
