5年软件测试工程师分享的自动化测试经验，一定要看

今天给大家分享一个华为的软件测试工程师分享的关于自动化测试的经验及干货。真的后悔太晚找他要了，

纯干货。一定要看完！

1.什么是自动化测试？
用程序测试程序，用代码取代思考，用脚本运行取代手工测试。自动化测试涵盖:功能(黑盒)自动化测试、功能(白盒)自动化测试、性能测试、压力测试、GUI(Graphical User Interface)测试、安全测试等。

我个人的理解:

自动化测试是测试思想的延伸，为测试工程师提供了“触手”。它的行为可以看作是一种工具，但本质上，自动化测试还是一种思想。

顺带一提，狭义的自动化测试是指基于GUI的自动化测试，以及单元测试和API测试，你有没有想过没有任何工具的情况下如何手工完成？因此，它们自然属于测试自动化的范畴。

2.自动化测试的优势
回归测试更方便可靠；可以运行越来越繁琐的测试，而且快速高效；可以执行一些很难或者不可能执行的手工测试，比如大量并发用户；更好的利用资源，具有一致性和可重复性，自动化测试脚本完全可重用；提高软件的可信度；在多个环境中进行测试等。

我个人的理解:

自动化测试的优点是成功完成自动化测试的结论，而自动化测试的缺点是建立自动化项目的基础。

另一个优点:自动化测试可以将产品知识固化成脚本，从而减少测试人员流动对项目的影响。但这种优势的前提是这些脚本容易维护，需要一些必要的文档，这是另外一个话题。

3.自动化测试做不到什么及其缺点
它永远无法完全取代人工测试。自动化测试无法达到手动测试的覆盖范围。不是每个测试用例都适合自动化。如果你提供页面布局是否正确的建议，手工测试会发现比自动化更多的缺陷。

与手工测试相比，自动测试几乎找不到新的缺陷，最大的目的是实现回归测试，保证以前的bug不会在新版本中重现；另外，自动化测试工具已死，它没有任何想象力；自动化测试的质量完全取决于测试工程师。成本高，风险大；对测试人员的技术要求高，对测试工具也有要求。

4.适当引入自动化
项目周期长，系统版本不变，需求不会频繁变化，适合在这个时候引入自动化测试。

系统的测试对象是否可以正常识别，对于无法识别的控件是否可以提供解决方案。

系统中没有太多无法识别的第三方控件。

成千上万的系统测试需要重复测试，如可靠性测试和回归测试。

5.不适合自动化
项目周期短，需求变化频繁。即使是长期项目，如果需求变化频繁，也不适合自动化。

如果软件版本不稳定，主要功能或大量功能可能会再次更改，不适合自动化；

项目测试自动化没有明确的计划、度量和管理。大多数对象无法识别，脚本维护频繁且困难。其中之一就是自动化会失败。

6.自动化测试过程
合理的自动化突破点:通常一个项目只有经过完整的系统测试，才能满足引入测试自动化的基本条件。

我个人的理解:

不管什么样的测试，越早介入越有利于降低成本和风险。随着新开发模式的兴起，自动化测试也具备了尽快介入的条件。比如在敏捷开发中，一个核心模块的核心功能完成后，就可以开始对该模块的这个功能进行自动测试。

7.测试自动化分析
(1)可行性分析；

(2)采样demo分析，demo一般选择冒烟测试用例，检查脚本是否能成功运行，设计的测试点是否全部执行；

(3)测试需求分析，哪些功能点做好了自动化的准备。

8.测试流程和设计
测试计划定制:自动化测试计划越全面，后期实施越有规律，自动化测试成功率越高。

计划跟不上变化，有时候太全面，未必是好事。

自动化测试设计阶段:主要分为自动化测试框架和自动化测试用例。

(1)自动化测试框架的设计、开发和构建:针对各个独立项目的无人值守测试框架，可以保证测试的分布式执行、脚本模块化、数据驱动、日志分析、错误截图、报表恢复、共享对象库、公共函数库、环境配置、统一设计模式、异常处理、场景恢复。

(2)自动测试用例设计三部曲:手动测试用例从零开始，然后根据手动测试用例编写自动测试用例。首先，筛选手动测试用例。然后转化手动测试用例，最后添加和补充自动测试用例。

9.为什么自动化测试用例不能完全取代手工测试？
自动化测试用例的范围往往是核心业务流程或者重复执行率高，自动化测试的覆盖率达不到手工测试的覆盖率。一般自动化测试的用例选择主要是正向的，但也有很多逆向的案例，但并不是所有的逆向案例都会被自动化测试覆盖，而是有一部分筛选。

并非所有的手动测试用例都可以用于自动化，例如检查页面布局。手动测试可能不需要回到原点，但自动测试往往是必要的。与手动测试用例不同，自动化测试用例不需要在每一步都写出预期的结果。

我个人的理解:

通常我做自动测试的时候会写一个测试用例叫做shake-down test。这个测试用例会遍历系统中所有完成的表单，只需做一个Navigate操作就可以保证一个页面是否可用。

每次回归测试之前，可以运行shake-down test一次，就可以快速确定哪些函数是accessible，相当于对整个系统做了一次冒烟测试。

10、测试脚本设计与开发
测试脚本可以大致分为:

(1)线性脚本:通过录制直接生成的线性可执行脚本

(2)结构化脚本:具有顺序、循环、分支等结构的脚本

(3)共享脚本:可以被多个测试用例使用并被其他脚本调用的脚本(即模块化脚本)

(4)数据驱动脚本:将测试数据从业务流程控制中分离出来，通过读取数据文件来驱动流程的脚本。

(5)关键字驱动脚本:脚本、数据和业务分离，数据和关键字在不同的数据表中，测试业务逻辑由关键字驱动。关键字驱动的特点是更像是描述一个测试用例在做什么，而不是如何做。

(6)混合脚本:上述任意两种或多种

11.自动化测试执行
(1)无人值守测试:环境建设、部署、配置；自动化测试用例绑定到测试脚本；自动测试用例执行顺序的排列和组合

(2)异常处理和场景恢复

提交自动化测试产品:大致需要提交实施状态、测试结果、分析报告、测试报告、质量状况等。

测试脚本维护：严格来说，测试脚本维护是分阶段进行的。不值得维护的自动化测试项目不值得建立。

能看到这，说明你是真心想好好学习自动化测试的，那么必须给爱学习的朋友分享一些资料

绵薄之力~
为了帮助大家迅速建立测试思维能力，早日斩获大厂Offer、掌握职场话语权，下面这份《软件测试全栈学习路线图》应该会对你很有帮助

从测试概念到最后的测试开发，希望大家能照着这个体系，在3-4年内完成这样一个体系的构建，可以说，这个过程会让你痛不欲生，但只要你熬过去了，以后的生活就会轻松很多，正所谓完事开头难，只要迈出了第一步，你就已经成功了一半，古人说的好：不积跬步无以至千里，等到完成之后在回顾这段路程的时候，你肯定会感慨良多，掌握了以上技术，在任何一线互联网大厂测试岗位都能独挡一面

下面是一些配套的资源，希望能帮到大家

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取