（23）测试专项丨自动化测试理解
1 定义
把以人为驱动的测试行为转化为机器执行的一种过程。
- 简单讲：比如使用自动化测试框架、脚本、工具等自动打开测试对象（引用），自动去执行测试用例（此过程中包含自动化查找元素、控件等），自动输入测试数据、自动生成测试报告等一系列的自动化过程；
- 通俗讲：用机器来模拟用户的实际行为，如键盘、鼠标等操作，来达到预期。
2 做自动化的目的是什么？
- 测试工作量比较大，使用自动化来完成一部分工作；
- 测试过程有大量重复的工作，使用自动化来进行提升效率；
- 手工测试难以覆盖的场景，需要自动化造数据等来完成；
- 有些测试结果，可能自动化比手工更为精确。
3 自动化测试的优缺点
| 优点 | 缺点 |
|---|---|
| 重复执行、频繁操作 | 不能100%替代人工测试 |
| 模拟手动测试无法覆盖的场景 | 不能达到100%覆盖率 |
| 利用空闲时间执行 | 需要时间去分析结果 |
| 释放一部分测试人员精力 | 对软件质量依赖大（前提是软件稳定、改动小等） |
| 测试结果客观公正 | 需要专业的工程师投入专门的时间开发 |
| / | 投入成本可能会大一些 |
4 自动化测试的前提条件（重要）
即做自动化前先对软件进行分析，是否满足或者要不要做自动化，有几个前提条件需要注意。
4.1 需求变动不频繁
- 脚本的稳定性最直观的决定要素是需求的变动，如果需求变化大，隔三差五的进行需求更改，那脚本势必也要进行同步更新，这样投入的维护成本就很大，得不偿失，还不如不做。
4.2 项目周期比较长
- 自动化测试和普通的测试一样，需要前期的规划、框架设计、脚本开发、人员选择、脚本执行、后期维护以及结果跟踪分析等，是一个比较全的且投入较多的一个过程，如果项目周期很短，就不适合做自动化，其实也没必要；
- 另外项目周期短，手动测试都无法保证的前提下，更不用谈及做自动化了。
4.3 脚本的重复使用率高
- 我们投入了较大的人力、物力、财力等最终完成了一套比较完美的自动化脚本、框架或者平台，但是复用率很低，只能在单个产品单独使用，那么这样的代价就太大了。此时我们需要评估是否必须要进行自动化测试，如果非必须，可以不做；
- 相反的，如果自动化的一系列东西都能迁移到其他的产品测试，那这样的投入是值得的，也是必要的。我们也应该投入更多的精力进行测试开发。
4.4 团队实力
- 做自动化，不是随便摘抄一些代码拿来用，他是一个专项测试，需要投入专门的人力去研究及测试，那么我们要想做好自动化，先要对自己的团队进行评估，团队的人员、技术能力等是否满足要求；
- 另外，自动化需要不断的进行迭代和优化，不能拿着脚本运行看看结果，那其实很多时候，并不能给产品带来客观的价值。我们需要进行不定期的升级维护，针对项目业务要进行优化，根据测试过程和结果的数据反馈要进行稳定性的升级等等。所以这也需要专门投入人力进行研究。
4.5 部门的规划和上级的支持
这个是我加的，根据个人的经验的总结；
- 部门的规划：如果自动化是在部门规划中，以及有考核目标，那肯定是要做的。如果不是规划，也没有纳入计划，那就要根据实际情况定，毕竟这不会直接影响你团队的实际考评。你的重点应该是在其他的地方，优先保证工作重点内容的完成；
- 上级的支持：这个很重要，做自动化无非是为了提升效率和质量，但是如果没有得到应有的效果，领导看不到成绩，也无感知，那么做自动化也许不会长久。这个得慢慢体会了，哈哈。
5 应用场合
自动化测试主要应用在以下场合，具体还要根据项目以及自动化的实际开发情况开定：
| 场景 | 说明 |
|---|---|
| 测试周期 | 项目周期长，轮次较多的软件 |
| 数据量级 | 需要制造大量的测试数据 |
| 软件稳定性 | 使用稳定和成熟阶段的产品测试 |
| 回归测试 | 需要进行简单回归的测试 |
| 冒烟测试 | 主线功能的冒烟 |
| 巡检测试 | 线上环境的定期巡检 |
| 发布验证 | 主线功能的发布验证测试 |
6 自动化认识误区（重点）
6.1 自动化可100%覆盖
- 概率不大，要使得自动化的测试覆盖率达到100%，需要投入专门的人力、物力、财力等，成本比较大；
- 某些业务的特殊性，或者场景的复杂性，用自动化是无法进行覆盖的；
- 项目的周期限制，不允许投入更多的精力去开发；
6.2 自动化可替代人力
- 领导的口头禅：你就告诉我，自动化能干掉多少人力？！====每次听到这样的话，不知道你们怎么想的，反正我是很无奈。但从领导的角度来思考，也不为错；
- 这里存在一些误区，自动化测试是辅助功能测试的，或者说是为了解决某些人工不能覆盖的场景；
- 另外，不存在完完全全的自动化，都是需要人工参与的；
- 遇到类似的认识，建议自动化测试人员需要进行解释，不能任由这个观点滋生，不然===你猜会咋办！！
6.3 自动化很牛逼
- 任何的事情，都是看谁先知道而已，与其说牛逼的技术，不如说牛逼的人。
- 自动化只是一门技术，我们不能脱离业务搞自动化；
- 很多人认为自动化很厉害，就脱离了工作的重心，天天喊着自动化、自动化，最后到头来啥也不是，啥也没得到。当然如果是专业、专门搞自动化测试开发的那就另说了。因为他们的工作就这，就是转、精。
6.4 万物皆可自动化
- 这个其实和前边的提到的一致，搞自动化，先要符合一些前提条件以及明白他的应用场景，不是所有软件都要搞自动化。
- 盲目的自动化，只会适得其反。
6.4 自动化很简单
- 这是一个很复杂的但是又简单的话题，对自动化的方向、工具、技能等研究的程度不同，对他的认识就不一样；
- 如果只是解决一些简单的问题，你掌握他很简单。如果是复杂的一些东西，可能需要深入研究；
- 自动化方向也是很多，不论是功能、性能，还是面向接口、UI、GUI、协议，更或是自动化工具开发等，都需要不同的技能和知识，入门或许简单，要做的很专一，还是需要点积累的。
6.5 自动化尽早做
不一定。不同的自动化，介入时间可能有差异，比如
- UI的，建议软件稍微稳定或者需求变更不频繁的时候再去开发；
- 接口的，可以在开发阶段同步进行；
7 自动化测试工具
太多了，举个例子，不代表所有的。事例而已：
『全栈测试技术，分享，共勉，共进，提升』
【特别说明】：知识来源于网络、各种资料、书本、网站等，本文仅用于学习使用，不做他用，如果涉及版权问题，请联系博主删除，谢谢