【全栈学习笔记】自动化测试概述(一)

引言

这是一篇自我理解性质的自动化测试概述性质的文章，也算是这么久工作的一篇追溯。仅是一家之言!

何为自动化测试

引用百度百科的定义:

一般是指[软件测试]的自动化，软件测试就是在预设条件下运行系统或[应用程序]，评估运行结果，预先条件应包括正常条件和异常条件。

通俗点说就是机器替代人工，就是这么的朴实和直白。

自动化测试自出现至今有多少年，历史已不可考，伴随着"大规模工业化式"的软件发展，软件自动化测试也在不断更新自身的理论体系，但实质今日可追溯的自动化测试理论体系也不过是两三种，也从侧面说明自动化测试依然太年轻。

本文并不追溯历史，闲话扯完，回归本体

自动化测试体系介绍

1.1冰淇淋模式(ice cream cone)

这个冰淇淋模式是2012年被提出来的，这是一种非常典型的依赖手工测试完成业务的测试，通过手工测试来测评产品的质量。从手动测试到单元测试依次向下，比重依次降低；这种模式在传统软件公司非常常见，甚至绝大部分软件公司都是这样的结构。

1.2 金字塔模式

这是现在非常流行的一种自动化测试分层理念，这个是由Mike Cohn提出的，所以这个模型其实也是敏捷测试模型。 这个模型上，我们看一看到金字塔的底部是 Unit 而且占了绝大多数位置，中间这层是 Service 有时我们也叫接口层API层，而金字塔的顶部是 UI 层，占有空间最小 。

1.3 橄榄模式（不倒翁模式）

到底谁最好？

如果说现在最流行、最无脑追求的就是金字塔模式；配合敏捷开发的路子，让非常多的公司直接出现裁撤独立的测试团队，将测试人员分散并入到各个Scrum 团队的风潮但很多公司根本没有做敏捷开发的能力，一众小公司或公司内的开发部门内的人员配置根本达不到全部都是TOP的水平，就直接莽敏捷，造成的劣势就是徒有其表，配合狂热的互联网的996，只能被动加班，来让自己"敏捷"起来。

敏捷并不是万能的，狂热的敏捷氛围大行其道，但也要想清楚自己的公司或部门有没有这个能力？是否有一个不错的架构师？遭受上层、市场的压力是否巨大？软件整体功能是否会不断变化？自动化测试是否已具有基础？各个员工是否都能独当一面？任何一条达不到标准，都请不要随意执行"敏捷"，996就是这么被迫建立起来的。

实际上当前一众公司往往都是走冰淇淋的模式，也许在很长时间内，冰淇淋模式都是主流的存在；但现实之中往往出现"不尊重"手动测试工程师的状况，认为手动测试是一种低下的，毫无技术的表现。但实际上，任何一家公司内正经做测试工作的人都不敢得罪手动测试工程师；因为当一家公司开始上自动化测试后，会在相当长的时间内出现 手动测试新功能，自动化测试迭代老功能的情况。

在管理层看来，手动测试可以被自动化测试最终取代；但在实际测试工作中，手动测试人员才是"真大腿"。很多"自动化测试工程师"人员已经丧失了编写完整手动用例编写的能力，写出的手动用例基本质量普遍不高；而在"当前手动用例—>自动化脚本"模式下，往往需要依靠纯粹的手动测试工程师编写手动用例；

同时有部分自动化测试人员也眼高于顶，认为自动化就能覆盖一切，但实际就是基本覆盖基本功能，虽然大幅度减少了测试时间但也没有发现太多的Bug。因此，要"善待"身边的手动测试人员，没有他们的默默奉献，项目连自动化测试的基本基础都没有。

至于不倒翁模式，在我看来，更加适合WEB测试和"中端"测试，基于UI的往往是展示层，基于"后端"的往往是业务处理，大量针对接口的测试在WEB测试中，性价比是最高的。

如果对软件测试有兴趣，想了解更多的测试知识，解决测试问题,以及入门指导，帮你解决测试中遇到的困惑，我们这里有技术高手。如果你正在找工作或者刚刚学校出来，又或者已经工作但是经常觉得难点很多，觉得自己测试方面学的不够精想要继续学习的，想转行怕学不会的， 都可以加入我们
，群内可领取最新软件测试大厂面试资料和Python自动化、接口、框架搭建学习资料！

其实无论哪种测试模式都有它自身的价值，和在某种阶段内能够呈现最高的"性价比"，因此不能无脑吹任一一个测试模式，其实就是一句话"不要听风就是雨"，适合自己的才是最好的。