浅谈自动化测试的价值和常见误区

阅读本文大约需要1分钟。

点击👆小卡片，回复 “合集” 获取系统性的学习笔记和测试开发技能图谱

简介

如下图是大部分质量工程师都知道的分层测试体系，其中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自动化的视角来看，行业内主要有以下或类似的解决方案：