| 万叶集 |
|---|
| 隐约雷鸣，阴霾天空。 |
| 但盼风雨来，能留你在此。 |
前言：
✌ 作者简介：渴望力量的哈士奇 ✌，大家可以叫我 哈士奇 ，致力于用白话讲解技术知识的博主 ✌
CSDN博客专家认证、新星计划第三季全栈赛道 top_1 、华为云享专家、阿里云专家博主
如果文章知识点有错误的地方，请指正！和大家一起学习，一起进步
人生格言：优于别人,并不高贵,真正的高贵应该是优于过去的自己。
如果感觉博主的文章还不错的话，还请关注、点赞、收藏三连支持一下博主哦
系列专栏：
Python全栈系列 - [更新中] 【 本文在该系列】
Python零基础入门篇
Python语法进阶篇
Python自动化办公篇
Python自动化测试实战篇
网安之路系列
网安之路踩坑篇
网安知识扫盲篇
Vulhub 漏洞复现篇
Shell脚本编程篇
Web攻防篇 2021年9月3日停止更新，转战先知等安全社区
渗透工具使用集锦 2021年9月3日停止更新,转战先知等安全社区
⭐️ 点点点工程师系列
测试神器 - Charles 篇
测试神器 - Fiddler 篇
测试神器 - Jmeter 篇
自动化 - RobotFrameWork 系列
自动化 - 基于 JAVA 实现的WEB端UI自动化
自动化 - 基于 MonkeyRunner 实现的APP端UI自动化
文章目录
- 浅谈为何要做自动化测试
- 初窥自动化测试
- 自动化测试的作用
- 领导心中的自动化测试
- 自动化测试的意义
书承上一章节，现在我们来聊一聊为什么现在的互联网企业迫切的需要大量的自动化测试。
如果有一定的代码基础，在测试领域会有很好的的发展前途。薪资水平呢也会不弱于甚至强于大部分的开发，这也算是很多测试愿意、或倾向于往自动化测试或者测试开发发展的原因之一吧。于我们测试人员而言有代码思维的测试，很容易走到更高的高度。
从另外一方面来说呢，自动化测试也是 敏捷 下的原产物。比如说 支付宝 ，这款产品看起来似乎非常的稳定，只是在大家不知道的情况下几乎没三到四天，后端都会迭代一次。
这么密集、快速发布的频率之下，单凭传统的手工测试去 点点点 已经满足不了这样的迭代需求，因为迭代的速度太快了。（只有三天的时间，需要多少人去点点点，才能完成验收）。
所以当下的测试人员的十六字方针就是：快速回归 、自动测试 、即时响应 、迅速定位 ，这样一来呢，自动化测试就变成了现阶段软件测试领域很重要的核心任务。
不仅仅是阿里如此，美团客户端的技术体系也是如此，看下图：
从上图可以看出美团在测试上也是以 自动化测试为主 ，他们会完成自动化测试用例来进行自动化测试框架的搭建最终来实现自动化的测试。实际上在一些比较完善成熟的小团队中，功能测试已经越来越少了越来越多的是用一些接口通过自动化测试来取代功能；然后利用线上监控自己的发布手段，用这些手段来解决掉可能存在的功能上的一些问题。从而保证项目的完整的实施。
初窥自动化测试通过前文及上一章节的了解，真真切切认识到了自动化测试对于我们来说非常的重要。所以这一块，暂时先不说技术，先来认识一下自动化测试到底是什么。（从三个方向逐步深入了解）
自动化测试的作用 领导心中的自动化测试把人为的测试行为转化为机器执行的一种过程，目标是为了节省成本，提高测试效率。
换而言之，就是通过代码的手段，把部分手动劳动转化为机器操作的方式，就是自动化测试。
尽管这个定义看起来非常的简单，但是推进自动化测试的过程中会产生很多的错误理解。
这个时候我们再来思考一个问题，做自动化测试的预期是什么？项目中进行自动化测试的目标是什么？
这样的问题我也问过不少测试同学、也在技术群里问过不少的同行。一点也不意外的收获了很多的回答：
我不知道为什么要做自动化测试。
领导让做的呗，
这就是根本不知道自动化测试的目的，就漫无目的的去做投入。所以很多公司的 自动化测试 走上了一条弯路。
1.按照功能测试用例用代码来实现。
- 通过 idea 工具，选好环境。
- 右键 —> Run As TestNG
- 一个人甚至两个人就一直盯着显示器
- 步骤如果不成功，回到编辑器，debug 找问题，修改代码
- 部分脚本执行的过程中卡住了，手动辅助点击，继续运行
这样的为了自动化而去自动化，即使这个用例覆盖率达到了 95%，也并没有真正的提升任何的效率；这也是很多公司里出现的场景，为了自动化而自动化。
而公司上下内部呢也并没有真正的理解自动化测试的意义，也没有对自动化测试有什么预期，自动化的产出也不应该就是一堆简简单单的代码，自动化的产出应该是更好的流程和更高的效率。
所以自动化测试也需要考虑一个东西 ROI ，也就是投入和产出。我们不能用很高的投入产出一个没有用的东西…
有幸曾经面试过某创业公司（业务还未开展），来自老板的需求：未来需要对自动化测试进行一个梳理。老板提了三个要求：
1、要求自动化测试要覆盖 100% 功能测试（这样的话后续就不需要再招聘功能测试人员了）。
2、自动化测试的团队未来可以达到二至三人，且自动化测试要稳定，不需要太大的维护（可真是个小可爱）
3、运行的结果可以自动报告 Bug ，不需要人工的接入…
好家伙、我真的是好家伙。说一句外行指挥内行，都算是客气的了，这是既想好，又想巧，还想买个毛驴不吃草啊。（生产队的驴也不兴这么使唤啊…）
尴尬一下："鄙人才疏学浅，能力有限..."
老板一愣："现在的年轻人啊... 和我们那个时候..."
一般情况下，像这种不太懂自动化的 老板 或者 VP 都会对 自动化抱有不切实际的幻想 ，觉得有了自动化测试就会省下很多的 人力成本 。自动化能做所有的事情，自动化能做一切…
这必然是不可能的，千万不要误认为 自动化 就是万能。实际上 自动化 只是我们工作中乃至职业生涯中的一个辅助工具，再优秀的测试用例，再稳定的系统也不可能百分之百的自动化，越是复杂的业务功能与业务逻辑，所涉及到的特殊操作唯一能够 “自动化” 实现的，其实是 测试工程师 的终极武器 —> 我们的大脑 [易] 。
自动化测试的意义对于自动化测试期望不能过高，也不能过低。所以自动化测试的意义到底是什么的？
谨慎一点来说就是把我们的自动化测试应用到项目中去，在保证质量的前提下，让项目的测试成本低于纯手工测试。如果真的能够满足这样的一个要求，我们才会认为这样的自动化测试是有意义的。
自动化测试的范畴有多大呢？在很多人看来，自动化测试其实就是那些可视化的 WEB端、UI层面的自动化，实际上远远不是，更不是很多人看来写个脚本就叫自动化测试。
就像我们写代码一样，并不是一味的堆积代码就是好的，就是很棒的，自动化测试一样也需要有自己的思路。
自动化测试核心的成本在于我们首次编写自动化测试脚本的时间，这是一部分；再有就是每一次迭代，每一次修改过程中维护自动化脚本的成本。就像前文说的，越是好的自动化设计越能够进一步降低自动化脚本的维护上面。
自动测试的基本要求就是成本要低于手工测试，所以如果用公式来描述的话就是下面这个样子的：
`收益 = 手工测试成本（自动化可覆盖部分）- 首次编写自动化测试脚本成本 - 自动化脚本维护成本``
当收益为正的时候，这样的 自动化测试才是卓有成效的 。但是呢，如果大家写过自动化测试脚本的话，就会发现特别是在不稳定或者是小项目下，这个收益的值很可能为负数，因为我们花了大量的时间去写脚本。
这就引出了另外一个话题，既然很容易出现 负收益 ，那么为什么做自动化测试，或者换句话问，到底什么样的项目适合于自动化。放眼国内外各大自动化比较成熟的公司都有一个共同的特点，那就是稳定与迭代。所以像 淘宝、京东 的这样的系统，一个版本发布之后要支持很多年，做的大多是 bug的修改或者活动的迭代，这样的情形下自动化的收益就会比较可观。这样的话，我们的收益公式就会变成这个样子：
收益PLUS = 手工测试成本（自动化可覆盖部分）* 迭代次数 - 首次编写自动化测试脚本成本 - 自动化脚本维护成本 * 迭代次数
这样就会发现，只要在每一次迭代中的维护成本小于手工回归的成本，随着迭代次数的提高，收益就会无限的增加。从这里也可以得到一个启示，一个项目的早起不适合自动化，是因为需求的不断变化业务逻辑的不断调整会让自动化的收益很低很难维护；
同时，并不是每个项目都适合高度的自动化，因为产品的 UI 是不断的变动的，用接口自动化来提升自动化的测试覆盖率也可能会更好，当然了这个描述也只是个大概，并不完全精确。有时候呢，在很多公司里还要再增加一项，那就是 延误成本 。
什么是 延误成本 呢？这里面很多时候都是管理、支持所带来的的困难。
所以自动化测试其实还是一个很专业的领域，一个优秀的测试架构对于技术、架构、管理规划都有很高的要求。
零零散散的聊了很多关于自动化的知识点，总结一下核心其实就那么几点。
- 不要为了自动化而做自动化，不是所有的项目都需要自动化，自动化测试一定要保证收益才有意义。
- 自动化测试不仅仅是脚本，而是设计，通过更好的设计来降低成本、提升收益。
- 国内大多数公司的自动化还在路上，不要用错误的思想去认识自动化，而要做专业的自动化专家。
