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

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

纯干货。一定要看完！

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)共享脚本:可以被多个测试用例使用并被其他脚本调用的脚本(即模块化脚本)

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

ps://bbs.csdn.net/topics/618631832)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！