简介
如下图是大部分质量工程师都知道的分层测试体系,其中UI自动化所占的比例虽然看起来很小,但是其能发挥的价值还是很大的。
目前整个业内在自动化测试框架选型方面:大厂因为业务足够复杂,人力资源足够丰富,所以一般采用自研框架,中小厂由于人力资源有限,所以一般采用开源框架,比如Appium、Airtest、uiautomator2等。
另外在测试平台建设方面:头部大厂一般既有对外的公有云测服务又有对内的私有云测服务,比如阿里云测MQC、腾讯云测WeTest以及百度云测MTC等,中大规模的企业比如美团、B站、爱奇艺、携程等虽然没有对外的公有云测服务,但是一般也都是有自己的私有化云测服务的,小厂的话一般都是本地执行,或者基于Jenkins搭建一条简单的流水线外加几十台设备来跑,基本也可以满足一定程度的自动化测试需求。
应用场景
- 冒烟测试自动化:通过跟精准测试平台打通,在RD提测前对MR的改动进行精准自动化回归,为QA提供准入参考
- 功能回归测试自动化:在每次版本回归阶段替代QA自动回归功能测试用例
- 专项性能测试自动化:兼容性、稳定性、性能等底层都依赖UI自动化作为驱动
价值
主要从主观和客观来看
主观
可以帮助测试团队转型,从传统的手工测试团队转为测试开发团队
客观
首先是提高效率也就是更快的发现问题,比如:通过与CI/CD/DevOps结合来融入企业的迭代流水线为回归测试、功能测试等提速。
再有就是提高质量,也就是发现一些更深入的Bug,比如通过兼容性测试发现一些跟机型和操作系统有关的适配问题,通过专项测试,可以采用一些极限操作来测试那些人工很难覆盖到的场景,比如Fuzz、Monkey、智能遍历等等。
常见误区
在做自动化测试的这些年里,听到过很多不同的声音,其中不乏一些质疑和误区,今天就给大家分享一些我对这些误区的理解。
手工测试无用论
我们强调自动化并不代表说手工测试就没有用,相反手工测试是非常有必要的,只不过仅仅有手工测试是不够的,手工+自动化才是企业产品快速迭代的基石,但具体到两者的占比是没有一个所谓的行业标准的,具体跟企业的业务类型、发展阶段、团队规模、以及技术储备有关。
手工测试并不代表落后,只不过人更应该把精力投入到设计更好的用例、更好的测试策略以及探索性测试上面,让机器去做那些他们擅长的事情。
UI自动化测试无用论
这个是做自动化测试的时候经常听到的一种声音,但其实讲这种话的人大多数是自己经验能力达不到、搞不定,无非是从两个方面吐槽:
一是人力技术成本高,首先是觉得优秀的测试开发工程师难招,但其实说白还是钱给的不到位,我觉得对于一些中大型企业来说,花高价钱来招一个优秀的测试开发工程师其实收益是远大于成本的。
我最近几年前后应该面了有100多位做自动化测试的工程师,不乏有些简历上写着精通各种自动化测试的候选人,但说实话80%的候选人在自动化测试能力上都不及格,要么是对框架理解不够深入浮于表面,要么是自动化测试的落地能力以及工程能力都没有达到要求。
二是维护成本高,首先是用例的复用率不高,生命周期太短,这块主要是因为UI和业务流程的频繁变更,导致元素定位失败等,再有就是稳定性不足,导致误报率居高不下,从而使团队丧失耐心和信心,但这些问题都是可以解决的,具体的方法我之前有出过一系列的文章,可以翻回去看看,比如《移动端UI自动化过程中的难点及应对策略》、《提高Android自动化测试稳定性的方法(一)》、《提高Android自动化测试稳定性的方法(二)》、《提高Android自动化测试稳定性的方法(三)》、《提高iOS云真机稳定性的方法(一)》、《提高iOS云真机稳定性的方法(二)》等。
UI自动化测试只能模拟人工
我们都知道现在智能化测试是未来的一种趋势,UI自动化跟机器学习、计算机视觉算法等结合可以覆盖很多人工无法覆盖到的场景,比如在海量真机上的UI兼容性回归测试、线上UI异常智能巡检、视频卡顿检测、体感耗时评测等等。
合理地使用UI自动化
建议使用分层测试的策略来控制UI自动化测试的规模,比如:只将少数核心用例交给UI自动化测试,大部分的基础回归测试交给智能遍历,剩余的新功能测试交给人工测试。
自动化测试的演进
UI自动化测试作为“业务先赢”的一种重要手段一直在不断的演进,从泛终端与多端UI自动化的视角来看,行业内主要有以下或类似的解决方案: