自动化的那些不为人知的事
可能对大多对测试的人来说都向往做自动化测试或者性能测试,因为在大家的理解中自动化测试轻松、工资高、不用每天都是手动,只需要写写脚本之类的就可以,其实这样理解不完全正确,自动化测试的优点是什么呢?那他的缺点又是什么呢?以及自动化测试的过程又是怎么样的呢?以及我们为什么要做自动化测试?什么样的项目适合做自动化测试?又需要选择什么样的工具进行自动化测试?做自动化测试需要具备什么样的知识呢? 可能之前大家都只是想但是从来没有想过这方面,根据自己的理解整理了一下。
一、自动化测试的优点是什么呢?
1、高效性:没有任何悬疑的就是相对手动测试高效率。但这只是建立在稳定的项目上。
2、可靠性:每次测试都可以准确的执行相同的动作,避免了人工测试的错误。
3、可重复性:可以重复执行相同的操作来测试应用程序,减少大量的体力劳动
4、可编程性:可以根据需要编写复杂的测试脚本,通过疲劳测试,找出潜在bug(这样的bug我找出的很少,以前在一个电商网站经常找到)
5、全面性:可建立一套完整的测试脚本来测试所有功能,将所有case进行组装。
6、重用性:可以重复使用测试脚本,即使应用程序使用的接口已经改变(目前貌似用到的少,可能项目有关系。)
二、自动化测试的缺点是什么呢?
1、脚本维护成本高
2、发现问题较少,主要是大多建立在比较成熟以及完整的系统上。
3、对软件的依赖较大
4、如果使用商业自动化工具购买成功高,不过可以选择开源的。
5、不能完全代替手动测试
6、自动化测试工具本身并无想象力,需要有想象力的人使用
三、我们为什么要做自动化测试?
以前看了一篇报道在整个测试行业手工测试占到的90%左右 ,相对开发来说,测试的门槛比较低,薪资也普遍较低,虽然要求的知识面要有一定广度,但缺乏深度,这是测试的普遍现状。
也正因为手功测试门槛不高,使大量的毕业生,甚至是非专业人员涌入这个行业。从而增加了这个行业的激烈竞争。对于工作几年扔处于手工测试的人员来说都会有强列的危机感。由于工作的技术含量不高,薪资的涨幅遇到瓶颈,另一方面受到新进入者的威胁,同样的工作公司花3K招来的人就可以做,那么就不会花8K 的招,你说对吗?如果你是老板可能也会这么做!这是大多测试人员不得不面对的一个问题。所以,从测试人员自身的发展来说,我其实非常需要通过自动化技术来增加自己有竞争力。当然,做到一定年限测试人员会选择转管理或其它岗位,这又是另一个话题了。
从测试行业的发展来说,国内产品由于产品特点,世界级的产品不多,技术含量相对不高,质量要求相对要求不高,外包国外项目,测试人力成本低廉,所以需要大量的手工测试人员。
所以,在不远的未来,我认为纯的工手测试人员的需求是递减,公司更需要更高技术能力的测试。质量需要测试,测试行为永远不会消失,但纯的手工测试人员是否消失这个真心不知道!
好吧,你可以说测试多朝阳的行业,我纯属在危言耸听。不管未来如何,我们都需要提升自身的技能对吧!孩子努力吧!
四、自动化测试的过程
自动化测试其实和开发一样,都是经过对测试需求的分析(软件过程中的需求分析),设计出自动化测试用例(软件过程中的需求规格),从而搭建自动化测试的框架(软件过程中的概要设计),设计与编写自动化脚本(详细设计与编码),测试脚本的正确性,从而完成该套测试脚本(即主要功能为测试的应用软件)。
1、自动化测试需求分析:当测试项目满足了自动化的前提条件,并确定在该项目中需要使用自动化测试时,我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据,并形成详细的文档,以便于自动化测试框架的建立。
2、 自动化测试框架的搭建:自动化测试框架便是像软件架构一般,定义了在使用该脚本时需要调用哪些文件、结构,调用的过程,以及文件结构如何划分。
而根据自动化测试用例,我们很容易能够定位出自动化测试框架的典型要素:
(1) 公用的对象:不同的测试用例会有一些相同的对象被重复使用,比如窗口、按钮、页面等。这些公用的对象可被抽取出来,在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时,只需要修改该对象属性即可,而无需修改所有相关的测试脚本。
(2)公用的环境:各测试用例也会用到相同的测试环境,将该测试环境独立封装,在各个测试用例中灵活调用,也能增强脚本的可维护性。
(3) 公用的方法:当测试工具没有需要的方法时,而该方法又会被经常使用,我们便需要自己编写该方法,以方便脚本的调用。
(4) 测试数据:也许一个测试用例需要执行很多个测试数据,我们便可将测试数据放在一个独立的文件中,由测试脚本执行到该用例时读取数据文件,从而达到数据覆盖的目的。
在该框架中需要将这些典型要素考虑进去,在测试用例中抽取出公用的元素放入已定义的文件,设定好调用的过程。
3、自动化测试脚本的编写
(1) 该编写过程便是具体的测试用例的脚本转化。初学的自动化测试人员均会使用录制脚本到修改脚本的过程。但专业化的建议是以录制为参考,以编写脚本为主要行为,以避免录制脚本带来的冗余、公用元素的不可调用、脚本的调试复杂等问题。
4、 脚本的测试与试运行
(1) 事实上,当每一个测试用例所形成的脚本通过测试后,并不意味着执行多个甚至所有的测试用例就不会出错。输入数据以及测试环境的改变,都会导致测试结果受到影响甚至失败。而如果只是一个个执行测试用例,也仅能被称作是半自动化测试,这会极大的影响自动化测试的效率,甚至不能满足夜间自动执行的特殊要求。
因此,脚本的测试与试运行极为重要,它需要祥查多个脚本不能依计划执行的原因,并保证其得到修复。同时他也需要经过多轮的脚本试运行,以保证测试结果得一致性与精确性。
五、什么项目适合做自动化测试
如果你已经决定要学习自动化测试了,如何学习是要面临的下一个问题?这个问题以被测试产品为出发点进行分析,假如你所学的技术不能得到应用(验证),将会使你的学习过程寸步难行。
首先考考虑产品是否适合做自动化测试。这方法比较普遍的共识是从三个方面进行权衡。
1、软件需求变动不频繁
测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁,测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本,而脚本的维护本身就是一个代码开发的过程,需要修改、调试,必要的时候还要修改自动化测试的框架,如果所花费的成本不低于利用其节省的测试成本,那么自动化测试便是失败的。
项目中的某些模块相对稳定,而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试,而变动较大的仍是用手工测试。
2、项目周期较长
由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程,需要较长的时间来完成。如果项目的周期比较短,没有足够的时间去支持这样一个过程,那么自动化测试便成为笑谈。
3、自动化测试脚本可重复使用
自动化测试脚本的重复使用要从三个方面来考量,一方面所测试的项目之间是否很大的差异性(如C/S系统和B/S系统的差异);所选择的测试工具是否适应这种差异;最后,测试人员是否有能力开发出适应这种差异的自动化测试框架。
六、选择什么样的工具进行自动化测试
说道这个问题也是比较头疼的,在之前我一直使用的是QTP,确实他使用起来是非常方便,但是有时候他不是很稳定,可能主要是因为没有花钱买吧!他的商用价值不得不说非常好,可是随着开源的越来越流行以及项目的需要就使用selenium了。不过自动化测试受限你要确定你项目是什么类型的?你所测试的产品是桌面程序(C/S)还是web应用(B/S)。
桌面程序的工具有:QTP、 AutoRunner
web应用的工具有:QTP、AutoRunner、Robot Framework、watir、selenium
由于B/S架构的诸多优势,早几年前大量C/S架构的应用转为B/S结构。从而也推动了web开发与测试技术的发展。假如,被测试有产品是C/S架构的,那么推荐QTP ,QTP在UI自动化测试领域占到了一半的试用率。所以,足以说明QTP在自动化领域强大,易用性等。学习主流的工具也可以使你获得更多的机会。市面上关于QTP的书籍也非常丰富。当然,要想学好QTP ,你必须要掌握VBS脚本语言。
如果,被测产品是B/S 结构,那么推荐selenium ,为什么不是QTP 或其它工具?因为selenium 对B/S应用支持很好,更重要的一点,它支持多语言的开发,真正的试用selenium ,你所要掌握的不仅仅是一个工具而已,你还需要学习一门语言。我为什么要选择selenium?还要学一门语言,这无疑增加了我的学习成本。增加成本的同时,也增加的你的竞争力,而且,在这个过程中你不单单只是学会了一个自动化工具而已,你完全可以使用所学的语言去做更多的事情。
好吧!假如你决定试用selenium 了之后,你又面临了一个新的问题,选择一门语言。selenium 是支持java、python、ruby、php、C#、JavaScript 。
从语言易学性来讲,首选ruby ,python
从语言应用广度来讲,首选java、C#、php、
从语言相关测试技术成度(及 资料)来讲:ruby ,python ,java
或者你可以考虑整个技术团队主流用什么语言,然后选择相应的语言。
看到这里时是不是已经头疼了?同感!
七、做自动化测试需要具备什么样的知识呢
其实这个很简单:
1、编程知识必须掌握这是毋庸置疑的,无论是python,vbs、ruby,java还是什么都得会一门
2、你得对被测应用进行了解,不单单是业务上的了解,你害的对他的布局、结构方面进行了解。
3、因为现在做自动化最多的应用一般都是web的,所以你得对html比较了解!
4、做自动化测试肯定会和数据库打交道,所以数据库的基本知识你得会!
现在发现整理这些挺累的,不过梳理一下发现还是有一定的收获,从杂乱的知识到系统!努力吧孩子!
如果转载请注明来源,否则追究法律责任!
posted on 2014-05-15 15:17 Mushishi_xu 阅读(346) 评论(0) 编辑 收藏 举报