做简单的UI自动化测试、什么情况下适合做
发表时间：2023-10-20 11:05:04
文章来源：炫佑科技
浏览次数：163
菏泽炫佑科技
做简单的UI自动化测试、什么情况下适合做
本文主要分享简单的UI自动化测试的介绍、为什么要做UI自动化测试、什么情况下适合做UI自动化测试等经验。 希望能给各位同仁带来思想上的碰撞。
1.关于自动化测试
定义：将人驱动测试转化为机器执行的过程，重点关注持续集成的概念；
优点：节省人工和时间成本；
测试金字塔：
如上图所示，敏捷大师Mike Cohn提出了这个概念，随后大师在此基础上提出了测试分层的概念，以区别于传统的自动化测试。
2.自动化测试分层
单元自动化测试（数据处理层）：是指对软件中*小可测试单元的检查和验证。 一般需要使用单元测试框架，比如Java的Junit，常见的方法就是代码等；
接口自动化测试（业务逻辑层）：主要检查和验证模块之间的调用返回以及不同系统和服务之间的数据交换。 常见的接口测试工具有、等；
UI自动化测试（GUI界面层）：UI层是用户使用产品的入口。 所有的功能都是通过这一层提供给用户的。 大多数测试工作都集中在这一层。 常见的测试工具有UFT、Robot等；
性价比：根据测试金字塔模型和投入产出比，越往下回报率越高；
自动化分层投资比例：
小测试（Unit）：占70%；
中测试()：占20%；
大测试（UI）：占比10%；
自动化测试面临的挑战：*大的挑战是变更，因为变更会导致测试用例失败，所以自动化脚本需要不断调试。 如何控制和降低成本，是对自动化测试工具和人的能力的挑战。
3. 什么样的项目适合自动化测试？
如上图所示，上述条件在实际工作中都无法满足，因此需要进行权衡。 一般来说，只需要满足以下几点就可以对项目进行自动化测试（图中红框标注的选项）：
①需求稳定，不频繁变化
自动化测试*大的挑战是需求的变化，自动化脚本本身需要修改、扩展、调试，以适应新的功能。 如果投入产出比太低，那么自动化测试就失去了价值和意义；
一种折中的做法是选择相对稳定的模块和功能进行自动化测试，对于变化较大、需要频繁变更的部分则采用手动测试；
② 多平台操作，结合遍历和大量重复性任务
测试数据、测试用例、自动化脚本具有高度的可重用性和可移植性，降低成本，提高效率和价值；
③软件维护周期长，有生命力
自动化测试的需求稳定性要求、自动化框架的设计、脚本开发和调试都需要时间。 这实际上是一个软件开发过程。 如果项目周期短，没有足够的时间来支持这个过程，那么自动化测试也就没必要了；
④被测系统的开发比较规范，可测试性强。
主要出于这些考虑：被测系统的架构差异、测试技术和工具的适应性以及测试人员的能力是否能够设计和开发适应差异的自动化测试框架；
4.常用自动化测试工具介绍
超快速傅里叶变换( )
即原来的QTP（Quick Test）和ST（Test）的合并，由HP开发，是一个企业级商用自动化测试工具，提供强大且易于使用的记录和回放功能。
兼容物体识别模式和图像识别模式，支持B/S和C/S两种架构的软件测试；
机器人
基于语言编写的自动化测试框架工具，具有良好的扩展性，支持关键字驱动，支持多种类型的客户端和接口，可以进行分布式测试；
应用于Web的自动化测试工具，支持多平台、多浏览器、多语言，实现自动化。 优点如下：
①开源、免费；
②多浏览器支持：、、IE、Edge等；
③多平台支持：Linux、MAC；
④多语言支持：java、Ruby、C#、C++；
⑤对Web界面有良好的支持；
⑥简单（API简单）灵活（开发语言驱动）；
⑦支持分布式测试用例执行；
你需要做UI自动化测试吗？
如果一个组织真正重视软件质量，UI自动化测试是必要的。 有以下几个原因：
1. 任何自动化工具在简单、机械和重复的任务场景中效果*好。 UI测试非常符合这个特点。
2、对于很多组织来说，UI测试是目前消耗测试团队人力*多的一个环节。 大多数全职测试人员的日常工作就是UI测试。 “工欲善其事，必先利其器”。 测试人员还需要自动化工具来提高日常工作效率。
3、无论后端多么复杂、多么重要，用户*终接触到的还是前端界面。 现在的软件除了后端逻辑之外，还有很多前端脚本逻辑和样式。 单纯依靠后端接口/单元测试并不能证明用户端的可用性。
4.自动化测试确实需要分层（单元测试、接口测试、UI测试）。 从测试团队的角度来看，非常希望有足够的单元测试和接口测试来保证测试版本的质量，但现实中的情况往往是开发团队维护的单元测试和接口测试也非常不足，甚至几乎不存在。
所以当任何项目中有人谈到“分层自动化测试”并告诉我不要做UI自动化测试时自动化软件开发，我都会先让他们给我展示一下界面测试和单元测试，然后和他们讨论自动化测试的实施策略。 。 但从实际角度来看，为何会有如此多的疑虑呢？
归根结底就是三个字：“不稳定”！ 测试环境搭建不稳定，被测软件界面不稳定，测试框架运行不稳定。
事实上，只要有适当的流程改进以及开发团队的配合，这些问题基本上都可以得到解决或者显着改善。 以测试环境为例，在纯手工测试阶段，部分项目的测试环境可以随时停止，随意更新。 这对手动测试也有影响（工作进度受到干扰，测试计划被打乱），但还可以忍受。 自动化测试将对测试环境提出更加标准化的要求，至少不能随时停止，这就需要对研发测试流程进行必要的改进。 但被测软件界面不稳定、测试框架运行不稳定等问题并不像测试环境不稳定那么容易解决。 这主要涉及到开发团队的配合以及测试框架的设计。
什么样的项目更适合自动化测试？
在一些人看来，质量低下的原因是没有使用先进的测试技术，例如自动化测试。 但质量低下的真正原因是项目本身的质量要求不高。 否则，即使有很多人肉，也必须进行足够的回归测试。 在这种情况下，如果采用合适的测试框架和实施策略来实施自动化测试，通常会取得更明显的效果。
那么关于什么类型的项目适合自动化测试，我要回答的不是项目周期长、需要长期维护、采用敏捷开发模式、有组织实施、测试团队有基本编码技巧...近年来，我建议不要做UI自动化。 测试过的项目很多，我拒绝支持的一些项目也符合上述特征。 后来我在评估一个项目是否适合自动化测试时做简单的UI自动化测试、什么情况下适合做，引入了一些非技术指标：
1、当前测试覆盖范围、质量风险和测试投入；
2. 目标测试覆盖率、质量风险以及不引入自动化时所需的测试投资；
3. 谁设定了这个目标或承诺实现它？
如果项目没有设定现有人力资源无法实现的回顾性覆盖目标，或者只是项目组设定的目标，则这个目标不会报告给老板或承诺给客户。 我认为在这种情况下说需要自动化测试是不真诚的。
对于认真做自动化测试的项目，我会指导他们把现有的所有测试用例拿出来，详细分析每个（每种类型）用例自动化执行的可行性、实现技术方案（UI、界面）、所需的初始成本。
完成自动化测试ROI分析后，如果确定要引入自动化测试，那么再加上合适的自动化测试框架，成功实施的可能性非常高。
学习安排！
感谢所有认真阅读我文章的人。 下面的网盘链接也是我花了几个月整理的很全面的。 希望也能帮助到有需要的你！
这些资料对于想转行【软件测试】的朋友来说应该是*全面、*齐全的准备仓库了。 这个仓库也陪伴我走过了*艰难的一段路程。 希望也能帮到你！ 凡事都要趁早，尤其是技术行业，技术能力更要提高。 我希望对您有所帮助……
如果你不想独自疯狂，找不到系统信息，遇到问题得不到帮助，坚持几天就放弃了，你可以点击下面的小卡加入我们的群。 大家可以一起讨论、交流。 会有各种软件测试资料和技术交流。 同时，我也将上面我花了几个月时间整理的材料也收入其中。 赶快来加入吧。
打字并不容易。 如果本文对您有帮助，请点赞、收藏、关注，给作者一个鼓励。 也方便您下次快速搜索。
