前言

本文主要分享做简单的UI自动化测试简介、为何要做UI自动化测试、什么情况下适合做UI自动化测试以及其他的心得体会，希望能给各位同行带来思想上的碰撞。

1、about自动化测试

定义：把人为驱动的测试转化为机器执行的一种过程，重点在于持续集成这个概念；

优势：节约人力和时间成本；

测试金字塔：

如上图所示，敏捷大师Mike Cohn提出该概念，然后由Martin Fowler大师在此基础上提出了测试分层概念，以区别于传统的自动化测试。

2、自动化测试分层

单元自动化测试（数据处理层）：指对软件中最小的可测试单元进行检查和验证，一般需要借助单元测试框架，如java的Junit、TestNG，python的unittest，常见的手段是code review等；

接口自动化测试（业务逻辑层）：主要检查验证模块间的调用返回以及不同系统、服务间的数据交换，常见的接口测试工具有postman、jmeter、loadrunner等；

UI自动化测试（GUI界面层）：UI层是用户使用产品的入口，所有功能通过这一层提供给用户，测试工作大多集中在这一层，常见的测试工具有UFT、Robot Framework、Selenium、Appium等；

性价比：按照测试金字塔模型以及投入/产出比，越向下，回报率越高；

Google的自动化分层投入占比：

小测试（Unit）：占比70%；

中测试（Service）：占比20%；

大测试（UI）：占比10%；

自动化测试面临的挑战：面临的最大挑战就是变化，因为变化会导致测试用例运行失败，所以需要对自动化脚本不断debug，如何控制成本、降低成本是对自动化测试工具以及人员能力的挑战。

3、什么样的项目适合自动化测试

如上图所示，真正工作中无法全部满足以上条件，所以需要作出权衡，一般来说，只需要满足以下几点，就可以对项目开展自动化测试（图中红色框标注的选项）：

①需求稳定，不会频繁变更

自动化测试最大的挑战就是需求的变化，而自动化脚本本身就需要修改、扩展、debug，去适应新的功能，如果投入产出比太低，那么自动化测试也失去了其价值和意义；

折中的做法是选择相对稳定的模块和功能进行自动化测试，变动较大、需求变更较频繁的部分用手工测试；

②多平台运行，组合遍历型、大量的重复任务

测试数据、测试用例、自动化脚本的重用性和移植性较强，降低成本，提高效率和价值；

③软件维护周期长，有生命力

自动化测试的需求稳定性要求、自动化框架的设计、脚本开发与调试均需要时间，这其实也是一个软件开发过程，如果项目周期较短，没有足够的时间去支持这一过程，那自动化测试也就不需要了；

④被测系统开发较为规范，可测试性强

主要出于这几点考虑：被测试系统的架构差异、测试技术和工具的适应性、测试人员的能力能否设计开发出适应差异的自动化测试框架；

4、常见的自动化测试工具简介

UFT（Unified Functional Testing）

即原来的QTP（Quick Test Professional Software）与ST（Service Test）合并而来，由HP公司开发，是一个企业级的商业自动化测试工具，提供了强大易用的录制回放功能，

同时兼容对象识别模式与图像识别模式，支持B/S和C/S两种架构的软件测试；

Robot Framework

一款基于python语言编写的自动化测试框架工具，具备良好的扩展性，支持关键字驱动，支持多种类型的客户端和接口，可进行分布式测试；

Selenium

应用于web的自动化测试工具，支持多平台、多浏览器、多语言来实现自动化，优点如下：

①开源、免费；

②多浏览器支持：chrome、Firefox、IE、Edge等；

③多平台支持：Linux、Windows、MAC；

④多语言支持：java、python、Ruby、C#、JavaScript、C++；

⑤对web界面有良好的支持；

⑥简单（API简单）、灵活（开发语言驱动）；

⑦支持分布式测试用例执行；

5、UI自动化测试要不要做？

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

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

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

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

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

所以任何项目中有人拿“分层自动化测试”跟我讲不要做UI自动化测试的时候，我都会先请他们把接口测试和单元测试展示给我看看，然后再跟他们探讨自动化测试的实施策略。但是从实践的角度，为什么很多质疑的声音呢？

归根结底就是三个字“不稳定”！测试环境构建不稳定、被测软件界面不稳定、测试框架运行不稳定。

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

6、什么样的项目更适合做自动化测试

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

所以关于什么类型的项目适合做自动化测试，我想回答的并不是什么项目周期长、需要长期维护、采用敏捷开发模式、组织推行DevOps、测试团队有基本编码技能，balabala…这些年笔者建议不要做UI自动化测试的项目也有很多，一些被我拒绝支持的项目也符合上述特点。后来我在评估一个项目是否适合做自动化测试时，引入了一些非技术指标：

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

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

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

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

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

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

作者：锦都不二

原文链接：https://blog.csdn.net/weixin_67553250/article/details/127128797