自动化测试细节设计之道

上一篇 / 下一篇  2011-07-06 20:27:11 / 个人分类:自动化测试—框架思想

  序言:自动化测试,个人以为,很重要的两个方面:一是能够做到无人值守的情况,自动化测试过程能够顺利进行。二是能够做到有详细的结果报告。将其具体在细节上分,则有几个重要的部分,一是:自动化测试用例的组织管理。二是:自动化测试的执行方式。三是:自动化测试对异常的处理。四是自动化测试的日志。五是自动化测试的报告反馈形式。接下来,结合RFT来从技术实现上说明自动化测试细节的设计之道。

 

一、自动化测试工具的应用方向

个人觉得,RFT的优点就在于其丰富和开放的API,你完全可以基于这些API,脱离RFTIDE,因此,最好的方式是尽量将RFT提供的功能进行删减。

 

个人认为:伴随着这么些强大工具的推出,为什么还有好多一些公司的自动化测试一直不能规模化,究其原因是因为自动化测试的具体“战术”是根据环境变化的,而自动化测试工具设计的时候只是为了做出一款集成的测试工具,是根据工具设计人员对自动化测试理念设计出来面向大众的,大多中小公司拿到工具之后,以自动化工具为中心去做自动化测试,而渐渐脱离了做自动化测试的本质。

所以,做自动化测试,需以公司需求为中心,尽量将自动化测试工具给拆离(拆离的方法便是从底部开始,例如RFT,就可以从其API入手),然后将其满足需求的部分应用到自身的自动化框架中。

 

二、自动化测试框架重要方面简述

其重要方面,一为执行无人值守。二为结果定位准确,

其实,自动化测试,个人认为,分为两种情况:一是辅助手工测试;二是回归版本测试。第一种情况就是在手工测试的执行过程中,有一些重复的测试步骤或者很繁琐的步骤(做自动化比手工测试执行的时间和效率高),这种自动化测试其实也可以认为是半自动化测试,它主要是帮助测试人员解决一些无味的工作。第二种自动化测试可以俗称为“例行测试”,它必须做到无人值守的情况下执行,其主要作用是回归版本,加速产品发布速率,并且保障产品质量。因此在这种测试过程中,其结果的定位尤其重要,在例行执行完毕之后,需要有一份总的结果报告,并且有问题的情况下能够根据LOG记录详细定位问题。

 

三、自动化测试框架的具体细节设计

  1、 自动化测试用例的组织管理

这是自动化测试框架设计很重要的一个方面,管理的方式可以通过“EXCEL表、CSV文件、数据库等”,然后应用“自动化测试框架执行引擎”去解析“自动化测试用例表”去执行自动化测试。而其中自动化测试用例表中可以依靠一些关键字对自动化测试用例的执行方式和状态进行定义和查看。

  2、 自动化测试执行方式

通过“执行引擎”去解析自动化测试用例表,根据其用例表的“执行状态”的关键字判断其是否需要执行。并且下一个测试用例的执行还需要读取上一个用例的“完成状态”为“完成”之后,才执行,否则,一直处于等待过程。

  3、 自动化测试对异常的处理

自动化测试过程中往往会出现一些异常造成自动化测试过程的中断,因此如何去处理这些异常,保证自动化测试的不间断执行,个人设计的方式是:在具体的测试用例中加入异常判断处理(try-catch,然后判断过程为只要抓到Exception,测试过程则会关闭整个测试过程,并且在“自动化测试用例表”中将相应的“测试完成”状态置为“完成”,将“测试结果”置为“失败”,并且进行下一个测试用例。

  4、 自动化测试日志

RFT的日志反馈太过于凌乱,并且不好与自动化测试框架的结合,因此,个人认为,可以将其日志去掉,建立自己的LOG机制,在每个方法中设计其LOG的输出,而当遇到异常时,则进行异常的输出,这样的话,就能够从全局上把握其测试的结果了。

  5、 自动化测试结果

对于结果的查看,可以在“自动化测试用例表”中进行统一查看,由关键字“result”定义,若有错误的,则再根据具体的日志去定位问题。

 

 

 总之,以上只是一些自动化测试设计的细节想法,当然,一定还有人有更好的方式,希望能够共同探讨。但是,个人坚信,工具本身是为测试需求服务的,所以,大家一定要警惕自动化测试工具的陷阱,不能陷入以“自动化测试工具”为中心的漩涡中,而要以自身的自动化测试框架为中心,将自动化测试框架插入其中,这样你才能做到“收发自如”。

 

顺便一句:其实我们的人生又何尝不是这样呢,吾以为:人生的最大追求为能够掌握自己的内心,真正做到“收发自如”,但若限制太多,抓不住本质,又何能做到此呢。

正所谓:

  花开花谢,云卷云舒,静看日出日落,卧听雨滴天明 

 以何吾能达此状态矣?吾问吾心,答曰:自然而为之~

 与君共勉之

                                            —散步的SUN


更多测试技能在线学习,更多测试文章,请访问http://www.zhibokeji.com/


TAG:

xin_晴的个人空间 引用 删除 xin_晴   /   2011-07-14 13:38:09
您好,我是51Testing软件测试网的编辑,您的本篇博文被推荐至51Testing软件测试网首页发表:http://www.51testing.com/html/98/n-240798.html
感谢您关注并支持51Testing博客,期待您更多的优秀原创博文。
散步的SUN的个人空间 引用 删除 散步的SUN   /   2011-07-14 10:38:50
恩,因为本身自动化设计框架其实就是一种面向于系统测试人员的软件产品,其实大家很容易忽略这个想法,总是为了做自动化而自动化了
因此,首先把其当成一款产品
1、调研
2、需求分析和设计
3、小规模试产
4、完善改正
5、发布
(而且以上都是一个迭代的过程,其实自动化测试也许也可以参考RUP开发过程,个人愚见)
阁下看看我给你发的短消息~
原帖由rossini23于2011-07-14 10:15:39发表
另外,博主在好多文章里都提到了流程管理,有一点小的想法,在这里跟大家聊一下。
  我觉得为什么要强调.
引用 删除 rossini23   /   2011-07-14 10:15:39
另外,博主在好多文章里都提到了流程管理,有一点小的想法,在这里跟大家聊一下。
  我觉得为什么要强调流程管理,一个重要的原因就是很多做自动化的人都没有意识到“测试自动化也是一种软件开发”,既然是软件开发,你就得遵循软件开发过程中的一些流程、规范。软件开发中的需求、设计、编码、测试、维护以及配置管理(源码、文档的版本控制)、BUG管理等等同样适用于自动化开发,没有这些流程、规范的约束,普通软件开发过程中遇到的问题你一样会遇到。
  Weinberg(1992)提出了一种评估机构开发级别的方法。与类似的分级一样,第一级是无序机构,第二级是重复级,一直到最高的第五级。但他在最下层还加了一级:第零级是忘却机构,即甚至没有意识到自己在开发软件的机构。很多测试小组都没有意识到测试自动化是软件开发,因此属于这一级。
  因此,做好测试自动化得需要程序设计、项目管理、测试等方面的技能。做好自动化测试并不是只有编码,涉及的东西很多。认为编码好就一定能做好自动化的人估计会失望,但是编码却是自动化过程中很关键的一环。
  所以,下次公司内有软件工程方面的培训自动化开发人员应该毫不犹豫地参加,呵呵。
散步的SUN的个人空间 引用 删除 散步的SUN   /   2011-07-14 09:14:40
不乱,写的很好,谢谢阁下分享 ~
看来,基本的框架设计细节都是相似的,关键是如何去满足自己的需求。
原帖由rossini23于2011-07-13 18:11:57发表
to bobdog520,
无人值守和定位准确的问题之前也遇到过。然后我们通过一些方法解决/部分解决了这些问题.
引用 删除 rossini23   /   2011-07-13 18:11:57
to bobdog520,
无人值守和定位准确的问题之前也遇到过。然后我们通过一些方法解决/部分解决了这些问题,把我们的经验分享一下,欢迎大家讨论。

前者通过修改测试框架解决,后者一半靠测试框架,一半靠日志解析工具。
说一下我们的测试情况:我们的测试主要是通过cli,脚本通过tcl实现。
之前的自动化框架是每个测试用例对应一个文件,最后用一个主文件通过source的方式调用所有的tcl文件来执行,这种方式的最大问题是:如果一个文件中遇到错误,整个过程就停止了。这样当然就不能无人值守了,因为你没办法保证脚本不遇到错误。
我们的解决办法是定义testcase,一个testcase对应一个测试用例,然后框架去调用testcase执行,同时框架会通过tcl里面的catch命令来捕捉错误,遇到错误的时候框架会记录错误,然后调用下一个testcase。至于testcase的组织方式,正如楼主所说,csv,excel,xml的方式都可以。
这样就解决了testcase执行出错时停止全部测试过程的问题。

然后在testcase内部,提供函数来设置testcase结果,比如set_pass/set_fail/set_error,设置的函数可以封装,比如做成JUnit/CPPUnit之类里提供的assertTrue/assertFalse/assetEqual之类的函数,或者Expect期待返回结果不正确时主动通过set_fail来设置用例执行结果。
出错的打印采用统一的格式,这个是为了方便日志定位。记录时间点,然后后面是定义的打印。
这样,一个testcase执行结束后框架根据这个testcase的结果生成Report,当然格式也是Report可以控制的。
同时,脚本执行过程中的所有打印信息记录到日志文件中。

至于日志文件中错误检索,首先是框架提供了统一的出错格式,然后通过其它工具的搜索功能就很容易找到出错的位置进行定位。

楼主说的“自动化测试框架的具体细节设计”在我们的框架中基本都有体现,确实,做好一个框架需要考虑的东西很多,对于特定的测试可能还有一些其它东西需要考虑,比如:
测试环境的管理,如果做到测试环境和脚本的分离,也就是环境信息不要硬编码到脚本中。对于通信/网络系统测试来说,管理的设备很多,这方面确实需要相应的设计。
测试数据的管理,同上,现在我们的一些测试数据是直接在testcase里定义的,没有独立出来。就想着某一天测试数据也可以独立出来,然后不熟悉编程的手工测试人员也可以直接修改数据,然后执行自动化测试。

说的有点乱,见笑了。
@槽神刘叫兽 引用 删除 lyscser   /   2011-07-12 10:39:11
原帖由散步的SUN于2011-07-07 18:11:47发表
山兄客气……

你该称之为“文兄”,哈哈
散步的SUN的个人空间 引用 删除 散步的SUN   /   2011-07-11 09:33:10
hi,谢谢您的分享
原帖由guoguo2005于2011-07-10 18:40:17发表
原帖由bobdog520于2011-07-08 21:12:14发表
楼主,非常赞成你说的这两句:其重要方面,一为执行无人值守.
散步的SUN的个人空间 引用 删除 散步的SUN   /   2011-07-11 09:31:22
hi,谢谢你的留言,我觉得这样的问题是很多人遇到的问题以及自动化中关于重用性和维护性最大的问题。
这个关键怎么解决,我觉得要看你们的业务流程,你们自动化的调用方式?这样的话才能从根本上出发去想问题
个人建议:
如果你们是cli形式,那些经常变动的命令行,那就得提取出来或者干脆不做,宁精不缺,不能为做自动化而自动化
如果你们是gui形式,那些经常变动的控件,一定要在属性上把握其变动性,最好用动态搜索提取那些属性变动性较少的方式
反正这样下去,对自动化开展的效果很不好,还不如停下来好好思量一下,越到后面越是积累的问题多,我加你,可以一起简单探讨下
原帖由bobdog520于2011-07-08 21:12:14发表
楼主,非常赞成你说的这两句:其重要方面,一为执行无人值守。二为结果定位准确。
我现在很痛苦,公司自.
引用 删除 guoguo2005   /   2011-07-10 18:40:17
原帖由bobdog520于2011-07-08 21:12:14发表
楼主,非常赞成你说的这两句:其重要方面,一为执行无人值守。二为结果定位准确。
我现在很痛苦,公司自.

我用QTP,大致的方法如下:
在界面上的每一次操作,录制成一个ACTION。
每个ACITON都被标准化:标准化的名称,标准化的参数传出传入格式。
被测对象有关的所有ACTION操作被作为基础操作单元被保留下来。
我们另有一套流程控制脚本来调用这些ACTION。
流程控制脚本里,基本上由LOADANDRUNACTION这个语句组成。
而且流程控制脚本里不使用EXCEL的这样的数据驱动方式,所有参数完全写在脚本里,两个相似的流程,我们使用拷贝、粘贴、调整的方式复用脚本,流程控制脚本的功能通过标准化的脚本名称进行标识。
如果业务的流程变化了,就调整这些流程控制脚本就行了。
如果操作对象的属性变化了,就修改底层的那些ACTION。
什么变化了,修改什么。

开始时,测试人员认为和书本上讲的方法不同,也有的说没有用到QTP提供的那些“便利”的功能,更多的人觉得过于惊世骇俗了。

但是在我的强力推行下,这半年多取得了良好的效果:
脚本编写人员再也不怕业务流程变化,也不怕被测控件的属性发生变化了。
而我也不用在为测试人员的变动造成的测试脚本构架培训发愁了。因为只要会QTP,就能生产项目需要的自动化脚本。修改流程控制脚本的,只要懂得LOADANDRUNACTION的使用方法,修改底层ACTION脚本的人,懂得QTP的基本控件属性识别和操作方法就行了。
至于自动化执行,我们是用QC调用QTP的。

希望我的方法能对你有用。
除虫药 引用 删除 bobdog520   /   2011-07-08 21:12:14
楼主,非常赞成你说的这两句:其重要方面,一为执行无人值守。二为结果定位准确。
我现在很痛苦,公司自己开发的自动化框架,第一做不到无人值守,第二不能及时捕获信息。完全是半自动,一边跑脚本一边看错误信息,还要具体分析到底是工具本身的问题还是产品的 BUG。最痛苦的是,自动化测试被视为孤立的一部分,因为我们的行业性质较为特殊,专业业务很重要,软件一个流程变了,脚本就需要改很多。但是,多数改动没人通知我们,只是跑脚本的时候发现有问题了,一确认才知道是软件改动了,快哭了整天,烦呐
散步的SUN的个人空间 引用 删除 散步的SUN   /   2011-07-07 18:11:47
山兄客气
后面人生感悟挺深的
原帖由wolaizhinidexin于2011-07-07 11:42:52发表
不管用啥工具,最终的方法都差不多.我以前怎么没有想到,执行方式这种状态来管理action呢?在此谢了哈.

.
文青山 引用 删除 wolaizhinidexin   /   2011-07-07 11:42:52
不管用啥工具,最终的方法都差不多.我以前怎么没有想到,执行方式这种状态来管理action呢?在此谢了哈.

人正直地活着就挺好!快乐地活着就很好了..嘿嘿...
散步的SUN的个人空间 引用 删除 散步的SUN   /   2011-07-07 10:59:50
逍遥兄何处出言?是进步还是退步?
求教导
原帖由xiaoyaoke于2011-07-07 09:57:40发表
这篇文章不是你的水平
逍遥客 引用 删除 xiaoyaoke   /   2011-07-07 09:57:40
这篇文章不是你的水平
散步的SUN的个人空间 引用 删除 散步的SUN   /   2011-07-06 21:52:50
这个我还真不知道...
看看谁能帮你解决
原帖由ganqian19850904于2011-07-06 21:39:48发表
你好,我想问一下怎么在mp3里面创建mtp播放列表?
ganqian19850904的个人空间 引用 删除 ganqian19850904   /   2011-07-06 21:39:48
你好,我想问一下怎么在mp3里面创建mtp播放列表?
 

评分:0

我来说两句

Open Toolbar