都说自动化测试才是测试人员的新出路，为什么要做自动化测试？

一、自动化测试

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
　　
个人认为，只要能服务于测试工作，能够帮助我们提升工作效率的，不管是所谓的自动化工具，还是简单的SQL 脚本、批处理脚本，还是自己编写的小工具等等，都属于自动化范畴。
　　
自动化是一个思想，而不是仅仅是某个工具的使用。
　　
自动化并非万能，人工测试还是不可或缺的。自动化的目的在于验证问题，手工测试的目的在于发现问题。
　　
很多朋友在做一段手工测试后，就厌了、烦了、倦了，信誓旦旦的说，自己的手工测试已经足够优秀，我要做自动化，再也不要也不想做纯手工的测试了。这种想法是存在误区的，重复也是一种极致，当你在重复里面找到灵感了，找到快乐了，你就比别人高一个境界。下面的内容供大家了解，也让大家在自己的内心建立起自动化的好与坏、利与弊。

二、为什么引入自动测试

直接一点的：就是为了节省人力、时间或硬件资源，提高测试效率，满足版本需求的快速迭代，提升产品测试质量。

三、自动化测试前提

1. 软件需求变动不频繁，相对稳定的功能模块或接口。
2. 项目周期足够长。
3. 自动化脚本可重复使用。
4. 手工测试无法完成的，或者需要投入较大时间人力的。

四、自动化测试的适用性

切入时机
　
以基本完成软件的程序界面开发、页面控件相对稳定为宜。
　
适用场景

1. 测试时间相对长，且存在大量重复性、机械性手工测试的项目。
2. 产品型软件，每发布一个新的版本或打补丁都需要对其他模块执行相同的测试。
3. 项目型软件，需求变更频繁，每变更一次，需要对原有的无争议的功能做测试。
4. 经常需要更换应用程序部署站点的软件，每更换一次需要对所有功能做验证测试。
5. 测试时间相对长，且存在大量需要执行回归测试的软件项目。
6. 系统界面稳定，需要对业务流程进行验证测试的软件。
7. 采用增量开发持续集成的项目，需要对频繁更新的程序执行验证测试。
8. 软件项目采用主流开发平台技术，且不存在物理交互的测试。

不适用场景

• 项目工期紧、测试周期短的项目不应采取自动化测试。
• 界面的美观、产品易用性测试不应采取自动化测试。

五、自动化测试过程

自动化测试需求分析》自动化测试框架选型、搭建》自动化测试用例、脚本编写》自动化测试结果分析(总执行用例数、成功用例数、失败用例数等)》版本更新迭代维护、持续集成。

六、自动化分类

UI自动化

维护成本高，受益最小。当然不是说UI自动化没有价值，适当的界面自动化还是有用的。

目前应用较多的场景是在版本发布、回归测试，可对功能稳定、基本无改动的模块开展UI自动化，从而缩短版本发布周期。

间接的，也让人工测试把重心放在产品的核心业务场景以及改动较大的功能模块上。

接口自动化

维护成本适中，受益适中，可以考虑覆盖大部分业务流程。

现在很多系统前后端架构是分离，后端接口服务开发是先行的，尽早介入可以从接口层发现更多的问题，预防和减少模块调用时才暴露问题。

单元测试

维护成本低，受益最大，价值最大。但是目前基本是开发在做，测试人员参与较少，而且对测试人员要求较高。

《Coogle软件测试之道》中提到单元测试、接口自动化、UI自动化的比例大概是70%、20%、10%，间接的也反应出不同阶段自动化能够给我们带来的价值。

大部分公司，日常工作中，手工测试的占比在百分之八十左右，能够实现并应用自动化的业务还是偏少的。自动化测试人员与功能测试人员的占比在1:10-20之间。做自动化要之前要做好调研，避免盲目的：我就是要做，要实现自动化。

当然，衡量自动化价值不能片面认识，需要综合各种因子一起考虑，只有适合自己的才是最好的。

绵薄之力

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走

​这些资料，对于想学习【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助，需要的朋友可以点击下方插件进群免费领取：