本人在某大型国企从事软件测试工作10年,研究自动化测试9年,绝大多数自动化测试工具都使用过。
sikuli是我唯一一个使用后大呼过瘾,爱不释手的工具。特地推荐给大家。
后续我将贴出使用sikuli做手机APP 和 Web自动化测试的实战帖子。
Sikuli介绍
MIT的研究人员设计了一种新颖的图形脚本语言Sikuli,计算机用户只须有最基本的编程技能(比如会写print"hello world"),他不需要去写出一行行代码,而是用屏幕截图的方式,用截出来的图形元素组合出神奇的程序。OS的GUI的出现并没有给程序员带来便利,他们仍然需要借助代码来实现相应的功能,比如Selenium。如果要让不同的软件相互配合,也同样要进行代码调用。
而麻省理工学院开发的Sikuli项目则可以使得这一过程变得更加简单,只需要略懂一点编程语言即可完成简单的编程和程序间的调用。利用 Sikuli,用户要使用其他的界面元素,或调用其他程序,不必输入代码,只需要插入相应的按钮或图标截图即可。使用者只要对Python语言有基本的了解,Sikuli可以利用图形用户界面的截图元素自动的完成大多数编程任务。
据麻省理工学院的研究人员介绍,Sikuli的工作模式与人眼一样,直接识别图像,而不是底层代码,因此不会产生不兼容的问题。Sikuli在墨西哥维乔印第安人(Huichol Indians)的语言里是上帝之眼的意思。目前,只有一个叫Raiman的老头在维护Sikuli。
优劣分析
1、使用QTP
QTP作为最有名的自动化测试工具,是作者最早接触的工具之一。但是长期使用后,发现有很多弊端:
1、QTP是商用软件,如果不交钱,很多功能都无法使用;
2、使用QTP的最常见场景就是Web测试(对应用程序进行测试支持不太好)。但是Web技术更新很快,很多新技术,QTP不一定能够跟上。比如Ajax技术就是升级后才支持的。
3、开发不一定为了配合测试,在Web前端代码中对各种元素添加ID等关键属性,QTP识别Web元素很容易误识别,导致需要手动修改。
4、QTP是通过浏览器的API来进行操作。但是对于弹出式窗口,常常就无法识别了。这种情况碰到了,常常束手无策。
2、使用Selenium
1、相比QTP,Selenium的优势是它是开源软件。但是QTP的缺点,它全有。
2、相比QTP,Selenium的易用性更低,无法实现高效的脚本录制,脚本基本上都要自己写。我曾经用过Selenium,因为不像使用QTP,可以深入到最底层去,恍惚间感觉自己无所不能,什么问题都可以搞定。但是使用过后,发现定位元素位置真是一个坑爹的工作。
3、Selenium也有QTP一样的问题,对于弹出式窗口,常常就无法识别了。
3、使用Sikuli
一直到现在,Sikuli使用的人都还不多。所以作者在决定是否引入Sikuli来解决项目自动化测试难题的时候,也很犹豫。直到某天做了一次尝试:作者为另外一个项目编写了一个Web自动化测试的用例。使用的是Selenium。这个用例花了作者1天半的时间。大量的时间都花到定位Web上的元素,和各种容错上了。接触Sikuli后,作者尝试使用Sikuli来完成同一个测试用例。结果作者只花了半个小时就完成了!有了如此高效的自动化测试工具,作者就毫不犹豫地想使用Sikuli来做项目的自动化测试了。
采用Sikuli方案有如下的优点:
1、 维护简单。Sikuli是唯一的一款使用图像识别来做自动化测试的工具。由于这个特点,使得它的上手难度相比其他的自动化测试工具(QTP、AutoIt、Selenium等)低了很多。如果运行出错,可以方便地找到错误的地方。如果是测试脚本的问题,因为使用了python(jython)语言,所以可以立即进行修改,并立即生效。2、 由于SikuliIDE采用的是截图可见模式,脚本编写非常直观,极大降低了普通测试人员上手的门槛。由于脚本都是截图生成的,所以阅读的时候,所有的测试流程都是可视的。不像Selenium或者Robotium做测试的时候,参数都是元素的特征值。如果对流程和界面元素的属性不熟悉,后期维护的时候,就无法读懂代码。 下图是网上某Sikuli脚本的界面。大家可以感受下其易读性:
3、 因为是完全模拟测试人员手动操作,纯界面驱动,所以整个测试过程直观可见,与手动测试可以紧密配合。 4、 我们业务产品的自动化测试一直无法有效开展的一个重要原因是界面变化快,导致自动化测试脚本跟不上界面变化的速度。但是Sikuli由于是界面截图进行操作,它的代码编写工作量相比以往的工具(QTP、Selenium等)大幅降低,相应的,应对界面变化的维护工作量也大幅降低。这使得敏捷开发中,自动化测试脚本的开发跟上版本开发进度成为可能。
当然,Sikuli也有它的缺点,作者认为正是因为这些缺点导致Sikuli这个好东西,到现在也没有得到大规模的应用。 1、由于原理是针对截图的识别进行操作,所以对运行脚本的测试环境有要求,不能随便迁移到另外一台机器。将一个机器上的脚本放到另外一个机器上运行的时候,常常会报错。失败的原因很多,比如:配色方案有差异,系统字体有差异。更多的是浏览器不同,导致渲染出来的Web效果不同。 2、由于是做界面识别,而界面图像识别有一定的错误率,而且Windows操作系统本身也有不稳定性(比如开机时间长了后,程序界面可能会图像错乱),导致Sikuli脚本的稳定性不如消息类的测试脚本。 3、Selenium、QTP做测试的时候,有些动态生成的值(比如Web操作后,新增的字段ID等)可以获取到。但是Sikuli就只能截取到图片,获取不到图片中的文本内容。Sikuli自带的OCR功能成功率低。
幸运的是,通过本项目的实践,作者已经找到了避免这两个缺点影响的方法。
|