怎么提高自动化测试的覆盖率

前言

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

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

一:对自动化测试的误解

1,自动化测试是万能的

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

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


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

二:如何正确对待自动化测试


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

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

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

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


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

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

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


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


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


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


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

3,如何提高自动化测试的覆盖率
     实施自动化测试最重要的就是要保证其可用性,而不少同学写了不少自动化测试用例,但感觉到其可用性不高。究其原因,不是自动化测试本身的问题,是实施自动化测试的时候没有考虑周全。


(1),不合事宜地引入自动化测试
     在公司业务发展稳定前,或是产品变动频繁的阶段,为了自动化测试而做自动化测试。此时的自动化测试失败率会非常高,不仅维护成本高,而且没有达到自动化测试回归与监控的目的。于是,就会造成放弃自动化测试,或是怀疑自动化测试的作用。在此时,不要急于引入自动化测试,如果确实需要引入自动化测试时,需要把测试粒度设置的粗一点儿,覆盖核心和变动不大的业务线。


(2),没有统筹进行自动化架构设计
     自动化测试用例不能是简单的测试用例的集合,如果将一个个单独的自动化测试用例放在一起,就组成自动化测试工程的话,那后期的管理与执行就会相当复杂。投入产出比与预期相差太远,这也不是一个正常的自动化测试工程的实施过程。正常情况下,需要先对自动化测试工程进行架构设计,选择合适的设计模式,对代码做分层架构设计,自主选择要执行的测试用例集等。


(3),测试用例选择不合理
     在实施自动化测试用例之前,没有对测试用例进行合理的选择,拿着手工测试用例一个个转化自动化测试用例。如果在此情况下,测试用例肯定覆盖不全面。所以需要前期对测试用例进行合理的选择,做智能化处理,如根据业务需求,选择核心业务的测试用例;或是如前面提到的,通过最短路径算法,选择覆盖率较高的测试用例集合。先从用例选择的角度来分析用例覆盖率,而后再转化成自动化测试用例,从而更好的提高自动化测试用例覆盖率。

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

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

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值