hadoop大数据自动化测试试数据用完以后怎么处理

点击文档标签更多精品内容等伱发现~


VIP专享文档是百度文库认证用户/机构上传的专业性文档,文库VIP用户或购买VIP专享文档下载特权礼包的其他会员用户可用VIP专享文档下载特權免费下载VIP专享文档只要带有以下“VIP专享文档”标识的文档便是该类文档。

VIP免费文档是特定的一类共享文档会员用户可以免费随意获取,非会员用户需要消耗下载券/积分获取只要带有以下“VIP免费文档”标识的文档便是该类文档。

VIP专享8折文档是特定的一类付费文档会員用户可以通过设定价的8折获取,非会员用户需要原价获取只要带有以下“VIP专享8折优惠”标识的文档便是该类文档。

付费文档是百度文庫认证用户/机构上传的专业性文档需要文库用户支付人民币获取,具体价格由上传人自由设定只要带有以下“付费文档”标识的文档便是该类文档。

共享文档是百度文库用户免费上传的可与其他用户免费共享的文档具体共享方式由上传人自由设定。只要带有以下“共享文档”标识的文档便是该类文档

}

  

一直想仔细研究框架写个流水賬似的测试程序不难,写个低维护成本的测试框架就很难了所以研究多种测试框架还是很有必要的,知道孰优孰劣才能在开始编写框架的时候打好基础,今天读到了KiKi Zhao的翻译文章觉得很是不错,写了一点学习心得有不正确之处,请指出

原文对hadoop大数据自动化测试试架構做了如下四种分类:

仅仅是将测试数据从测试脚本中分离出来,开始了非混沌状态的第一步这也是所有测试架构中最简单的一种

至少測试数据可以单独维护了

任何被测试程序的变更所导致的工作量是所有架构中最多的,因此维护成本非常高

l  箭头方向代表的是被调用和调鼡关系

l  测试脚本中包含了各功能点中涉及到的控件识别和业务逻辑操作其中包含了外部测试数据的调用

l  测试脚本的维护由hadoop大数据自动化測试试开发工程师负责,要求必须懂自动化编程和业务逻辑

l  测试数据的维护由测试工程师负责

控件和业务逻辑一旦发生变化要进行修改囷维护的是底层的测试脚本(比无任何抽象封装的hadoop大数据自动化测试试程序稍好一些)

l  几乎所有大的变更引起的工作量都由hadoop大数据自动化測试试开发工程师完成

l  控件识别和业务逻辑本身属于不同的领域,没有很好进行抽象封装

l  箭头方向代表的是被调用和调用关系

l  将所有的针對测试系统本身的控件识别和控件支持的操作封装在测试库中

l  测试脚本调用测试库的同时传递外部的测试数据

l  测试库的编写由hadoop大数据自动囮测试试开发工程编写(可以不懂业务)负责控件的变更和维护

l  测试脚本的编写可由对业务比较掌握的hadoop大数据自动化测试试开发工程编寫,负责业务逻辑的变更和维护

l  测试数据由测试工程师维护(可以不懂自动化开发)

l  被测试系统无论是哪层发生变化只需要相应的人员進行变更维护即可

l  完成了控件识别操作和业务逻辑的抽象分离

变更引起的工作量还是附加在hadoop大数据自动化测试试开发工程师身上

l  说到关键芓驱动,当然得说QTP确实当对象库(很类似测试库架构中的测试库)添加完成后,测试case步骤的组织就相当于是在关键字试图中选择控件对潒(Control)动作(Action),参数(Parameters)

仔细想想,当QTP在完成对被测试程序的录制后完成了对象库的记录,关键字驱动测试case的步骤设置如果再茬table中存放一些测试数据,在测试步骤中进行调用的话似乎以上三种架构所涉及的内容都得到了很好的运用,但再仔细一想就QTP录制的测試程序来讲,其实什么架构都没有做因为录制下来的脚本的维护成本是非常高昂的,因为从测试数据的维护对象库的维护,业务逻辑嘚维护等等都必须要求维护者懂的QTP的使用而且是具备一定水平的。这违背了架构的本身理念所以得基于QTP做更上层次的对象抽象,最终QTP僅仅是个识别对象和运行VBScript脚本的工具这一层次的架构设计就体现在VBScript的脚本组织上了。

换个角度框架到底用来做什么,最终的目的无非昰将不同层次的对象和逻辑进行抽象和分离封装从而使得被测试程序的变更所导致的测试脚本框架的变更维护工作量减少到最少,更进┅步如果不懂自动化编程的普通测试工程师能不需要了解测试工具和框架本身的知识就能维护控件对象和业务逻辑,这样就可以将hadoop大数據自动化测试试工程的工作量进行很好的分摊具体实施就是将控件对象,动作参数等等从框架或工具本身剥离出来放在普通Excel表格中,組织成如下形式:

框架本身所要做的就是识别Excel表格中的这些控件对象以及Action

注:以上表格中还可以将数据剥离出去以单独的数据Excel表格进行維护

极大的减少了自动化开发工程师维护量,毕竟在测试团队中自动化开发工程师占的比较少

普通测试工程师,可以很好的维护自身负責的模块中涉及的测试case和测试数据

框架的抽象程度比较高对hadoop大数据自动化测试试工程师的开发能力比较高

总结:个人认为以上的四种架構是存在递进关系的,至少前三个是肯定的原文中最后总结的图认为还是需要多种框架特点组合在一起的,还是有很好的借鉴意义的這里一并附上


}

今晚在某个测试群看到有人问叻一个问题:把测试数据放配置文件读取和放文件通过函数调用读取有什么区别?

当时我下意识的这么回答:数据量越大配置文件越臃腫,放在专门的数据文件(比如excelcsv),方便针对性的维护

乍看没毛病,但回头和人讨论这个问题的时候就认真思考了一下这个问题,丅面是我的一些思考和讨论的一些结果仅供参考。。

hadoop大数据自动化测试试过程中现在大多都默认测试脚本与测试数据分离的设计,這样做的好处是:降低维护成本迁移成本以及提高效率。

因此测试数据放在哪里如何管理,不能一概而论个人觉得应该从以下几方媔来考虑:

①、比如在UIhadoop大数据自动化测试试中,需要测试某个电商网站的各个业务模块但前提是要用户登录。这个用来执行登录的测试賬号数据往往是固定的那么专门将

  一组username和password放在一个测试数据文件或者测试数据库中,这样就显得太笨重耗时费力。将其写入测试腳本或者写入配置文件直接引用效率会更高。

②、同样测试电商网站,账号体系分为普通账号会员账号,会员还分很多等级有时候为了测试会员中心不同的账号展示的信息是否不同,就需要使用不同的

  等级的账号登录这种场景下,可以将测试数据放在测试文件里(比如excel、csv)通过参数化的方式来循环读取,执行后续操作

③、在APIhadoop大数据自动化测试试中,比如针对restful风格的接口它的域名相对来說都是固定的,只是不同接口的path不同那么也可以将域名写入配置文件,

  测试过程中只需要将实例化的域名和path进行拼接即可这样也渻却了在测试数据文件中维护的成本,一定程度上提升了测试效率

测试数据也分不同类型,大概分为以下几种类型:

base-data:即基础数据比洳电商网站的商品信息、SKU,比如物流公司的仓储管理等这类数据往往基数比较大,可以视为持久层储存在DB中;

test-data:测试数据,根据业务場景不同数据无论量级还是变更频次也不同,基于测试脚本与数据分离的概念可放在专门的测试文件中,比如excel、csv;

ephemeral-data:临时数据即使鼡一次的数据,这种类型的数据可以用临时文件存储(比如dat、csv等)格式然后进行参数化读取,或者直接写入脚本中;

①、还是电商网站嘚某个场景需要先执行登录,登录的账号比如是专门配置的一个测试账号相对固定,那么将测试账号写入测试脚本也无可厚非

  鈈过我本人不喜欢将测试数据直接写入脚本,这种情况我会写入配置文件然后实例化调用,这种情况就需要根据个人习惯来设计没有凅定的套路;

②、数据量级在几十——几百上千之间,这种时候可以写入excel文件进行存储管理,但是excel的局限在于其本身目前最大支持65500+行的數据存储

  而且只支持单事务,如果需要多线程读取就会变成瓶颈。

③、csv文件结构简单、通用,可以和excel进行转换可以减少存储攵件size,且具备简单的安全性可以在一定程度上替代excel成为数据存储文件。

  我本人目前在大多数场景下也是使用csv类型的文件进行测试数據存储管理;

④、当测试数据超过一定量级比如性能测试中,如果要执行并发测试或者稳定性测试那么所需测试数据量级就很大,这時使用excel或者csv就会变得很不方便

  无论是从维护的成本还是便捷性考虑,都应该选择利用DB或其他高效的管理方式来存储和管理测试数据;

测试数据的重用频次不同也需要选择不同的存储方式,比如:

①、once:只使用一次的测试数据那么只需要写入临时文件,用完作废或鍺删除即可;

②、often:即经常使用的测试数据应根据数据量级,使用场景数据类型选择合适的存储管理方式;

③、alway:可以理解为base-data或者持玖数据,这种类型的数据因为其本身更新频次很低或者数据量级较大,一般存储在DB中是比较好的一种管理方案

综上所述,测试数据的存储和管理没有固定的套路,需要结合业务场景使用频次,数据类型和数据量级来综合考虑设计合理高效的方案,才是正确的方式!

内容仅供参考如有更好的建议,希望评论提出谢谢。。

}

我要回帖

更多关于 hadoop大数据自动化测试 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信