一些很实用的技巧提高自动化测试覆盖率

自动化测试一直是测试人员的核心技能，也是测试的重要手段之一。尤其是在今年所谓的互联网寒冬的行情下，各大企业对测试人员的技术水平要求的很高，而测试人员的技术水平主要集中在三大自动化测试领域，再加测试辅助脚本的编写，测试工具的开发，测试平台的开发等。而普通的测试人员想快速提升技术，自动化测试必是无可挑剔的选择。
但是由于业界一直存在着对自动化测试的误解，严重影响了自动化测试的发展，也影响了不少同学学习自动化测试的信心。主要集中在以下几点：

一，自动化测试是万能的

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

二，自动化测试无用论

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

三，自动化测试能速成

由于现在业界对自动化测试要求较高，已经有不少同学开始学习自动化测试。但是却对自动测试的认识不足，了解了自动化测试框架，能通过一门语言写一两个测试用例，就认为自己为自动化测试，相应的找工作的要求啊，薪资待遇提的就相当高。自动化测试是一套完整的测试理论，不是借助于自动化测试框架能写测试用例就掌握的事情。如果想要学习，还是要踏踏实实的打基础，掌握一门编码语言，学习相应的自动化测试框架，再了解自动化测试实施的原理，掌握自动化测试设计架构，以及为将来要做的事情提前规划；一两个月的学习只是入门，后续还是需要长期的实践，进行技术的积累和沉淀才行。
在明确自动化测试的误区后，我们来分析一下作为测试人员应该如何正确对待自动化测试。首先要对自动化测试有个明确的认知，自动化测试是测试人员必备的技能，除非你想在一家公司工作上几年，然后转行不做测试，否则你的测试之路必然会受其影响。

一，正确学习自动化测试

此处不再讨论自动化测试是不是应该学习，这是一项必备的能力。既然如此，所以我们还是需要掌握这个能力的，但是又不能盲目。不要认为自动化测试会变成必备的能力，所以就把接口，WebUI, App全面学习，也不管是java,还是python,这样就会越来越乱。首先要选择一个语言体系，如java,或是python,掌握好相应语言的基本能力；其次，安排好学习顺序，如先学习接口自动化测试，然后是WebUI自动测试，再接着就是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都有可能。其实施的自动化测试工程也就各有所长，这也说明自动化测试的技术有很大的提升空间。所以要沉下心来，不断地提升自己，不要刚刚学习了自动化测试就感觉自己能力很强，或是动不动就说测试发展遇到了瓶颈。不断的打好测试技术相关的基础，完善知识体系，提高解决问题的能力，开阔视野才能步步高升。

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：