为什么需要自动化测试？自动化有哪些优势？

本是古典何须时尚 2023-10-07 20:27 68阅读 0赞

**目录**

前言

一、为什么需要自动化测试

二、自动化的类型

三、搭建一个接口自动化框架需要的技能

四、自动化测试优劣的隐性指标

总结

--------------------

## 前言 ##

自动化测试，最近些年可谓是大火。招聘上的要求也好，培训班的广告也罢，比比皆是，足以说明它在业内的火爆程度。

虽然说会写自动化测试并不能说明你就很牛批，但是你不会的话，那么很抱歉，你的上升通道就会变得窄了。

![b6b2381c4752839c079c58b2800fbb3f.jpeg][]

## 一、为什么需要自动化测试 ##

**自动化的优势：**

> 1.自动化可以代替手工大量地重复的工作，测试可以把大量的时间放在用例设计和新功能上边
> 
> 2.自动化可以大量提升回归测试效率，特别适合敏捷开发
> 
> 3.自动化可以大量地利用无人值守的时间去执行用例，特别适合非工作是爱你执行测试，工作时间分析测试用例失败的工作模式
> 
> 4.自动化可以实现某种测试无法完成或者付出巨大的代价的测试类型，比如关键业务的测试7\*24持续运行系统的稳定性和高并发场景的压力测试;
> 
> 5.自动化可以保证每次执行的操作和验证的一致性和可重复性，避免认为的遗漏和疏忽;

**自动化的劣势和坑：**

> 1.自动化不能代替手工，他只能代替手工测试中执行频率高，机械化重复的步骤，千万不要奢望所有的测试都要自动化，否则会得不偿失;
> 
> 2.自动比起手工测试脆弱，无法对测试系统的变化做出识别，业界流传：开发者手一抖，自动化测试忙一宿，这也从侧面反应了，自动化测试一直居高不下的事实，原因自动化不具备智能识别，只能按部就班按的测试，没有任何的处理能力;
> 
> 3.自动化测试的开发工作量远远大于单次的手工测试，所以只有开发完成的手工测试大于5次，才能收回自动化测试的成本;
> 
> 4.手工测试发现的bug通常会比自动化发现的错误多，且自动化只能发现回归测试的缺陷;
> 
> 5.测试效率很大程度上依赖自动化用例设计以及实现质量，不稳定的自动化比没有自动化更糟糕;

**什么样的项目适合自动化：**

> 1.需求稳定不会频繁变更
> 
> 2.研发和维护周期长，需要频繁地回归测试;
> 
> 3.需要多个平台重复运行相同的测试场景;
> 
> 4.某些测试项目无法通过手工测试实现，或者手工的成本高;
> 
> 5.测试软件开发较为规范，能够保证系统的稳定可测试性;
> 
> 6.测试具备编码能力

## 二、自动化的类型 ##

大家通常会去选择做自动化的类型一般有2种：**一种是UI自动化、一种是接口自动化**。

那UI自动化中，又可以有web系统的自动化、APP的自动化等等。

笔者本人曾经开发维护过一套web自动化的服务，说实话，投入回报率不高，所以后来也就逐步放弃了。

回想起来，这也算是领导没弄清目的就盲目开展的典型案例了，不过这段开发经历对我来说还是很宝贵的。

到后来重点就转移到了接口自动化了，为什么呢?

首先声明，这里讲的接口是指协议接口了，比如http协议的接口，并不是程序接口，比如java里的interface。

**那么接口层相比于UI层，最大的优点是更接近底层逻辑，可以让测试更早的介入。于是更早的发现bug，修复的成本也就越低了。**

另外，接口测试也可以更容易发现UI测试中不容易发现的问题。

比如说，一个接口没有对非法传参进行处理，虽然UI在输入框进行了一些不合规的类型输入校验，但是只要抓个包修改下参数请求过来，就会立即暴露出问题。

## 三、搭建一个接口自动化框架需要的技能 ##

**编程语言**：既然做了这行，编程是跑不掉的。java、python 哪个熟悉用哪个吧，我个人偏向于脚本用python。

**单元测试框架**：不同语言有不同的测试框架，python有unittest、pytest等，java有testng、junit等。我个人偏向python的pytest。

**搜索解决问题**：其实有了前面2个点是基石，剩下的就是你遇到什么问题或者需求，知道如何去搜索解决实现的能力了。比如能找到合适的

第三方库，来增加自己的框架，拿pytest来说，可以用requests库来发送请求，用jmespath库来提取复杂的接口响应，以及用allure框架来

输出一个漂亮的报告等。

搞清楚了这些，基本上就可以开始做起来了。

一开始不用过度的考虑自己的框架的终极形态是什么样子的，因为我觉得没有最好的框架，只有最适合的框架。在你实现的过程中，会遇到不同的问题，

然后你不断迭代优化你的框架去解决这些问题，于是乎框架会一点点的变成大家心中的样子。

## 四、自动化测试优劣的隐性指标 ##

**1 、自动化的维护成本**

针对同一个业务，不同的自动化测试实现方案，对应的维护成本可能天壤之别。诚然，自动化的维护成本，受业务成熟度、迭代速度、项目规范程度影响，但不妨考虑以下情况下，你的维护成本如何：

新增了一些逻辑(如，接口/服务/应用)，对新增部分维护自动化，你需要多长时间;

删除了一些逻辑(如，接口/服务/应用)，对删除部分维护自动化，你需要多长时间;

修改了一些逻辑(如，接口/服务/应用)，对修改部分维护自动化，你需要多长时间;

在项目迭代速度加快时，并伴有增删改逻辑时，你的自动化脚本还能跟得上吗?其实，这是不少团队都会面临的严峻考验。 一个正处于快速发展的业务，每次业务测试、回归时，可能都会想放弃自动化测试，转而来手工执行测试。因为，自动化测试还要不断调试自动化代码，大概率来不及这次的测试，还不如直接手动测试的效率高。

![13b90c41716b9ee0262525675fbbe4ce.jpeg][]

**2、自动化运行成本**

这里的自动化运行成本是说，从想执行自动化到执行结束需要符合的能力&时间成本。一般的自动化运行过程大致如下：

> 1)创造一些自动化执行条件。比如，找运行数据，设置运行环境等等，这一步如果没有被自动化掉，需要花费人力&时间;
> 
> 例如，实现的自动化只能"一条腿走路"，即只实现了半自动化，并没有实现100%的自动化，运行前/中/后可能需要人为参与。
> 
> 2)执行自动化。这里主要是自动化运行所需时间，时间越长，导致的等待时间越长。可能你会说，自动化执行的时候，你可以去干别的事情啊，没必要一直等待执行结束。但既然执行了自动化，肯定想像手工测试一样，"马上"看到执行结果，得到及时反馈，才能避免在不同工作间来回切换。
> 
> 3)验证自动化结果。一般结果的验证都包含在上一个步骤里面了，但不排除有些验证仍然需要人工来check的情况。这种情况，其实也属于半自动化的一种实现形式。
> 
> 4)自动化失败问题排查。各种各样的原因，都会导致自动化运行失败了，比如，数据问题、环境问题、自动化维护不及时、第三方问题等等。自动化失败后，能否比较清晰地给出失败原因，甚至能根据自动化失败结果，直接定位到失败原因，这些做到位了，会让你对自动化爱不释手。

## 总结 ##

自动化的前景完全不必担忧，且不说人类社会发展的大方向就是自动化，难道我们如今不是把很多很多的工作都交给了各种工具么？

市场有没有前景是一回事，自己能否把握住，是另一回事。测试自动化是一定是未来的方向。

在以往的过程中，我无数次的问自己这些问题，思考了很多以前回避的、懒得去想的问题，也对自己、对未来有了更清楚的认识。这何尝不是一种成长呢？

**这篇贴子到这里就结束了，最后，希望看这篇帖子的朋友能够有所收获。欢迎留言，或是关注我的专栏和我交流。**

[b6b2381c4752839c079c58b2800fbb3f.jpeg]: https://img-blog.csdnimg.cn/img_convert/b6b2381c4752839c079c58b2800fbb3f.jpeg
[13b90c41716b9ee0262525675fbbe4ce.jpeg]: https://img-blog.csdnimg.cn/img_convert/13b90c41716b9ee0262525675fbbe4ce.jpeg