前言

自动化测试一直是测试人员的核心技能，也是测试的重要手段之一。尤其是在今年所谓的互联网寒冬的行情下，各大企业对测试人员的技术水平要求的很高，而测试人员的技术水平主要集中在三大自动化测试领域，再加测试辅助脚本的编写，测试工具的开发，测试平台的开发等。而普通的测试人员想快速提升技术，自动化测试必是无可挑剔的选择。

但是由于业界一直存在着对自动化测试的误解，严重影响了自动化测试的发展，也影响了不少同学学习自动化测试的信心。主要集中在以下几点

一、自动化测试是万能的

由于对自动化测试的认识不足，或是对使用场景不够明确，认为只要开展了自动化测试，就能尽可能地发现更多的bug,有的甚至认为只要自动化测试做的好，完全可以替代手工测试。这个是过度地夸大了自动化测试的作用，自动化测试主要的作用是代替人工，做一些儿繁复的工作，如回归测试，监控等，针对的是核心业务或是成熟的功能。在开展自动化测试之前，要对自动化测试有个清晰的认识，否则后期会对自动化测试失望的。

二、自动化测试无用论

另一种对自动化测试的错误认识就是，自动化测试根本没有用处。这个认识的来源是，有些同学在公司开展了自动化测试，也连续跑了起来，可是根本发现不了任何bug,每次跑都通过了，所以就认为自动化测试没有用。其实自动化测试的实施是有先决条件的，针对成熟的业务，覆盖核心业务。同时，根据需求，自动化测试覆盖的粒度也不会是非常精细的。自动化测试是用来保障核心业务不出问题，或是第一时间发现问题。所以长时间发现不了bug是正常的。如果你的自动化测试三天两头发现Bug,要不是公司业务发展不够稳定，就是你写的自动化测试有问题。要对自动化测试有清晰的认识，不能过度夸大其功能，也不必贬低其作用。

三、自动化测试能速成

由于现在业界对自动化测试要求较高，已经有不少同学开始学习自动化测试。但是却对自动测试的认识不足，了解了自动化测试框架，能通过一门语言写一两个测试用例，就认为自己为自动化测试，相应的找工作的要求啊，薪资待遇提的就相当高。自动化测试是一套完整的测试理论，不是借助于自动化测试框架能写测试用例就掌握的事情。如果想要学习，还是要踏踏实实的打基础，掌握一门编码语言，学习相应的自动化测试框架，再了解自动化测试实施的原理，掌握自动化测试设计架构，以及为将来要做的事情提前规划；一两个月的学习只是入门，后续还是需要长期的实践，进行技术的积累和沉淀才行。

在明确自动化测试的误区后，我们来分析一下作为测试人员应该如何正确对待自动化测试。首先要对自动化测试有个明确的认知，自动化测试是测试人员必备的技能，除非你想在一家公司工作上几年，然后转行不做测试，否则你的测试之路必然会受其影响。

四、正确学习自动化测试

既然如此，所以我们还是需要掌握这个能力的，但是又不能盲目。不要认为自动化测试会变成必备的能力，所以就把接口，Web UI, App全面学习，也不管是java,还是python,这样就会越来越乱。首先要选择一个语言体系，如java,或是python,掌握好相应语言的基本能力；其次，安排好学习顺序，如先学习接口自动化测试，然后是Web UI自动测试，再接着就是App自动化测试。当能进行自动化测试实施的时候，需要提高一下能力，学习自动化测试的架构设计，持续化集成的实施等等，步步为营，稳扎稳打。

五、根据实际工作需求实施自动化测试

学习要和实际工作相结合才能更好地提升，如果一家公司有自动化测试相关技术建设，是一个很好的发展平台。如果公司没有这方面的投入，我们需要从零开始做起自动化测试。如何从零开始做自动化测试呢？

1、分析自动化测试的目的，发布前回归测试或是线上产品监控等；通过分析以往遇到问题，如果采取自动化测试，能避免哪些问题，以数据手段说服领导来推动自动化测试的实施。

2、分析与选择自动化测试覆盖的用例范围。自动化测试要么回归测试，要么进行线上数据的监控，所以不是所有的测试用例都要转化成自动化测试。选择覆盖核心业务的测试用例，或是根据测试的需求，对功能测试用例先进行预先的处理，如通过最短路径算法，选择覆盖率较高的测试用例，转化成自动化测试用例，以提高自动化测试用例的覆盖率。

3、探讨自动化测试实施参与人员。自动化测试工程是你单独实施，还是有团队成员一起参与实施？如果是个人的话，就选择自己熟悉的知识体系进行实施，如果是团队一起参考，就要考虑团队成员的技术水平，选择转化成本最低的技术栈，以保证投入产出比最高。

4、根据参与人员做技术选型。根据确认好的自动化测试的实施人员，做好技术选型，如使用java语系，还是python语系？当然自动化测试框架是固定的，如接口自动化的python+requests, java+HttpClient; WebUI自动化测试就是Webdriver;App自动化测试的Appium等等。

5、设计自动化测试架构。自动化测试不管技术栈如何选择，在开始写自动化测试之前，不可能是一个个自动化测试用例的简单罗列，需要先进行自动化测试架构的设计。选择PageObject模式，还是数据驱动模式？封装好公用函数，设计好测试用例的管理，测试数据的管理，测试用例集，日志，测试报告管理等等。

6、编写与调度自动化测试用例。根据前面选择的自动化测试用例需要覆盖的范围，将相应的测试用例转化成自动化测试代码。在编写自动化测试用例的过程中，不断完善公用函数的封装，调度并编写自动化测试用例。

7、根据自动化测试的目的，设置自动化测试执行策略，实施持续化集成。在编写完自动化测试用例后，根据需求组织测试用例集，并设置自动化测试用例集的执行策略。借助于jenkins等任务调度工具，实施持续化集成，如开发提测后触发执行自动化测试，做回归测试；或是设置定时任务，在相应的测试环境下定时执行自动化测试，监控业务流程。

8、指定后期维持与扩展策略。自动化测试需要不断地维护才能保证其可用性，如被测对象优化，架构重组，增加新功能等，都需要优化相应的自动化测试用例，才能保证自动化测试的时效性。同时需要对指定相应的人员进行培训，做定时维护，维护与编写对应的文档，做好技术积累和传承工作。

六、如何提高自动化测试的覆盖率

实施自动化测试最重要的是保证它的可用性，而很多同学写了很多自动化测试用例，但觉得它的可用性不高。究其原因，并不是自动化测试本身的问题，而是在实现自动化测试时缺乏考虑。具体包括以下几点：

1、不恰当地引入自动化测试

在公司业务发展稳定之前，或者产品变化频繁的时候，进行自动化测试。这个时候，自动化测试的失败率会很高，不仅维护成本高，而且自动化测试回归和监控的目的也不会达到。因此，会导致自动化测试的放弃，或者怀疑自动化测试的作用。这个时候，先不要急着引入自动化测试。如果你真的需要引入自动化测试，你需要将测试粒度设置得更粗，覆盖那些变化不大的核心和业务线。

2、自动化架构设计没有整体规划

自动化测试用例不能是简单测试用例的集合。如果把单个的自动化测试用例放在一起，形成一个自动化测试项目，后期的管理和执行将相当复杂。投入产出比与预期相差太远，这也不是一个正常的自动化测试工程的实现过程。通常情况下，需要先设计自动化测试项目的架构，选择一个合适的设计模式，为代码设计一个分层的架构，独立选择要执行的测试用例集，等等。

3、测试用例的选择不合理

在实施自动化测试用例之前，没有合理地选择测试用例，手工测试用例一个接一个地转化为自动化测试用例。如果是这样的话，测试用例一定不能完全覆盖。因此，需要在早期对测试用例进行合理的选择，并进行智能化处理，如根据业务需求选择针对核心业务的测试用例。或者如前所述，通过最短路径算法，选择一个覆盖率高的测试用例集。首先从用例选择的角度分析用例覆盖率，然后将其转换为自动化测试用例，从而更好地提高自动化测试用例的覆盖率。

七、结束语

从事自动化测试的测试开发同学很多，但是相应的级别也不尽相同，从T3到T6都有可能。其实施的自动化测试工程也就各有所长，这也说明自动化测试的技术有很大的提升空间。所以要沉下心来，不断地提升自己，不要刚刚学习了自动化测试就感觉自己能力很强，或是动不动就说测试发展遇到了瓶颈。不断的打好测试技术相关的基础，完善知识体系，提高解决问题的能力，开阔视野才能步步高升。

如果文章对你有帮助，记得点赞，收藏，加关注。会不定期分享一些干货哦......

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

这些资料，对于想做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助……加入我的学习交流群一起学习交流讨论把！！！！