UI自动化测试是什么?什么项目适合做UI自动化测试

前言

本文主要分享做简单的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简单)、灵活(开发语言驱动);

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

UI自动化测试要不要做?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

学习安排上!

感谢每一个认真阅读我文章的人,下面这个网盘链接也是我费了几个月时间整理的非常全面的,希望也能帮助到有需要的你!
在这里插入图片描述
这些资料,对于想转行做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!凡事要趁早,特别是技术行业,一定要提升技术功底。希望对大家有所帮助……

如果你不想一个人野蛮生长,找不到系统的资料,问题得不到帮助,坚持几天便放弃的感受的话,可以点击下方小卡片加入我们群,大家可以一起讨论交流,里面会有各种软件测试资料和技术交流,同时我也把上面花几个月整理的资料放里边了,赶快加入吧。

敲字不易,如果此文章对你有帮助的话,点个赞收个藏来个关注,给作者一个鼓励。也方便你下次能够快速查找。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

代码小怡

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值