自动化测试初介

 自动化测试

        自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。

        个人认为，只要能服务于我们，能够帮助我们提升工作效率的，不管是所谓的自动化工具，还是写个sql脚本、写个批处理、做个小工具等等，都属于自动化范畴。

        自动化是一个思想，而不是工具，需要刚入手的朋友们注意。

        自动化并非万能，人工测试还是必须的。自动化的目的是验证问题，手工测试的目的是发现问题。很多朋友做一段手工测试后，就厌了、烦了、倦了，口口声声说，我要做自动化，再也不要，也不想做手工测试了。这种想法是存在误区的，重复也是一种极致，当你你在重复里面找到灵感了，找到快乐了，你就比别人高一个境界。下面的内容供大家了解，也让大家在自己的内心建立起自动化的好与坏、利与弊评判。

为什么引入自动测试

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

自动化测试前提

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

自动化测试的适用性

切入时机

        以基本完成软件的程序界面开发、页面控件相对稳定为宜。

适用场景

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

不适用场景

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

自动化测试过程

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

 自动化分类

UI自动化

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

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

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

接口自动化

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

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

单元测试

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

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

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