让自动化测试更“智能化”

上一篇 / 下一篇  2012-12-29 15:28:41 / 个人分类:自动化测试—工具思想

             让自动化测试更“智能化”

     序言:快元旦了,没想到世界末日居然也这么过去了,下一个世界末日,我是等不到了,呵呵,做完了部门整体自动化测试和性能测试方面的年度总结和下一年的具体计划后,今年还算部门测试自动化和非功能性测试整体上有所进步,很多点都有了,而且自动化已经算是正式上路了,但离大型的测试平台建设和改进过程却还得有一段距离,不过已经不是这么遥远了,有时间可以分享讨论一下,现在先偷得一小段时光,调侃一下如何让自动化测试更人性化吧,大家只当看着乐呵,不一定说的对,因为大部分没有经过项目实践,只是想法,能起到拓展大家的视野的作用,我就觉得不错了。

 

一、所谓“智能化”

 

   智能化一直是现在的一个趋势,记得大学曾做过一个课题,叫智能家居项目项目,其实简单理解就是将模拟电信号转换为数字信号,从而应用一定逻辑去控制我们的家居环境,例如:室温和照明,可以跟随随意调节或者根据天气变化而变化。

        在我们的互联网应用上,更重视这种智能化,现在流行的数据挖掘和机器学习技术,就是智能化的一个技术基础,直接表现在一些推荐功能和程序的自主学习功能,通过记录你平时的一系列操作作为输入数据,然后基于一定模型学习到你的喜好,达到主动推荐需求的效果。

  

二、调侃如何让测试更智能化

    

    简单思考了一下自动化测试的“智能化”表现,其实简单而言,就是如何让自动化测试更加贴近人的想法,一则更加像人一样思考,二则更贴近人的需求,提高人的测试效率。

     

   1、人具有变化性,让自动化测试更具有判断性与场景处理

  自动化测试一直不被用来提倡发现问题的最大原因在于他是将测试用例固化实现,只关注期望关注的,那为什么手工测试会比较容易发现问题,可以对以下场景进行想象:

   1) 手工测试遇到问题时,往往为了验证此问题,会进行一系列相关的操作,而根据测试中的一项现象就是:基于80/20原则的缺陷集群性,即版本发布前进行测试所发现的大部分缺陷是由于少数软件模块引起的,也许这样测试人员在验证过程往往容易发现更多的问题。而这种方式的话,首先,基于功能点进行关键字驱动封装,并且指定其关键字验证错误时,它的走向如何,即需要去调用哪些操作去验证功能,或者调用另外的关键字功能封装进行验证,这样一层一层套一层,直到某个关键字的验证完全通过为止或者开设另外一个线程规定和监测搜索的期限,否则容易造成搜索无止境。这种机制是为了对与之验证功能点相关的功能点进行探索,发现更多的发现问题。需要注意的是:这种机制是建立在关键字测试驱动框架上,而且调用的关键字注意的是在保证验证后恢复到调用前的初始环境,另外这种机制与程序异常机制还不一样的,异常机制是程序运行时候程序抛出的异常,当遇到异常时,测试脚本无法进行下去,则会基于异常跳转到异常处理部分,一般会是清除测试环境,由框架转到另外一个测试用例。

    2) 探索性测试,在写这篇文章的时候,突然简单的浏览分析了一下探索性测试的相关书籍,突然发现,探索性测试就是一种强调以人为主观的测试,但是却又基于一定的规则,具体实施可以围绕SMART规则,测试目标、指标评估、可实现性、当前语境的切换以及合理可接受的时间限度。而探索性测试,按我的理解,更多的是一种思维模型,个人觉得,测试自动化和探索性测试并不是相对的,各有优缺,能相互结合,也可以利用程序建模完成,基于自动化测试手段开展一些探索性测试,当然,这只是浅见,需要再好好的学习和实践探索性测试后,并基于实现一定的模型,才能有发言权。

   

    2、人具有学习性,让自动化测试更具有学习性

   当今业务脚本的很大的一个弊病在于缺少动态性,而软件测试是具有杀虫剂效应,而人在测试过程中是具有学习性的,能够感知软件和产品的变化,快速做出相应的调整,例如:哪些功能模块是非常稳定的,可以少测试,哪些是重点,需要多测试等。

     1) 学习是一个有特定目的的知识获取和能力增长过程,一个学习系统中可分为:环境—学习环节—知识库—执行环节—学习环节。而学习策略则可以简单分为记忆学习(即我们学习过程常见的死记硬背),归纳学习(即在学习过程,由大量的数据统计出规律,基于平均与概率求解),解释学习(分析学习过程,通过对某一个问题求解分析进行学习)

    2) 在自动化测试过程中,当测试功能模块越来越多,没有太多的时间去全部覆盖,我们可以采用归纳学习的方式,基于自动化测试的执行结果或者手工测试执行的结果为数据输入,然后基于一定的模型(例如:以通过率和模块的重要率计算的平均值)得出测试推荐模块,或者当要执行一个功能模块时,基于历史数据和模型(bug出现的错误相关性,功能相关性等)计算出与该功能模块相关性最大模块,并推荐测试。

     3) 还有一种机器学习广泛用于白盒测试中测试用例的自动生成,这个就不详细说了,有兴趣的可以查阅一下。

       

     总结:当然,以上说的都是个人想法,除了基于关键字框架中的探索测试外,其余的很多都没去写代码实现验证,更不用说实际项目应用了,因为这种学习过程是建立在大量的输入数据上的,而现在的自动化测试水平还不足以支撑起如何庞大的工程,所以大部分只能为想法,而且自动化测试需要从简单做起,一步一步一个脚印。测试是一个很好的领域,不闭门造车,放飞思维,跨领域结合,不实践不批判,共勉之。—散步的SUN

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


TAG:

引用 删除 18222033423   /   2016-03-31 15:21:25
5
flyskey的个人空间 引用 删除 flyskey   /   2013-03-30 11:23:44
感觉我真的还差很远
workbook的个人空间 引用 删除 workbook   /   2013-02-04 08:56:22
挺好挺好,推荐一下
workbook的个人空间 引用 删除 workbook   /   2013-02-04 08:56:08
5
引用 删除 ilanlin   /   2013-01-17 10:56:37
不错。
xin_晴的个人空间 引用 删除 xin_晴   /   2013-01-05 11:18:54
您好,我是51Testing软件测试网的编辑,您的本篇博文被推荐至51Testing软件测试网首页发表:http://www.51testing.com/html/83/n-831783.html
感谢您关注并支持51Testing博客,期待您更多的优秀原创博文。
文青山 引用 删除 wolaizhinidexin   /   2012-12-29 22:00:00
5
文青山 引用 删除 wolaizhinidexin   /   2012-12-29 21:59:57
有点意思,呵呵。。
 

评分:0

我来说两句

Open Toolbar