Tag Archives: 测试自动化

用户界面测试的颠覆性技术-Sikuli

Sikuli绝对是一种颠覆性的技术,至少对于GUI的测试技术来说,是质的突破,比如它彻底解决了在这之前GUI自动化测试工具上的关键点-对象识别。 技术来自于从麻省理工学院计算机和艺术智能实验室的一个用户界面设计小组的研究项目,Sikuli脚本和Sikuli开发平台基于MIT License发布,是开源的。 什么是Sikuli ======== Sikuli是一种利用图片(快照)去搜索和自动化GUI的视觉技术,Sikuli的第一个release包含Sikuli脚本,也就是为Jython编写的一种视觉脚本API,同时包含了Sikuli IDE,一个可以非常容易的用快照书写视觉脚本的集成开发环境。Sikuli脚本可以自动化你在屏幕上看到的一切,而这不需要内部API的支持。你可以编程控制一个页面,一个运行在Windows/Linux/Mac OS X上的桌面应用程序,甚至于一个运行在模拟终端的iphone的应用程序。 Sikuli的必杀技 ======== 自动化所有你看到的一切 利用快照进行自动化 工作在Java平台(意味着可移植) Sikuli安装和使用 =========== 下载安装了一下,在Windows上需要JDK1.6以上环境,这里有一个简单的视频介绍(看不到youtube的同学翻墙吧)。 不会翻墙的地同学请从如下视频观看: 继续阅读论文 ========= GUI Testing Using Computer Vision Sikuli: Using GUI Screenshots for Search and Automation MIT news介绍图像驱动计算 一个例子快照 ========= 拭目以待!

Posted in 测试工具 | Tagged | 9 Comments

Three Key Tools for Test Automation

很久没有静下心来写写测试方面的总结了,打算忙完了这个重要的Release,就沉下心去,好好总结几篇,这两年在Oracle从事质量工作的一点体会,也不辜负长期以来一直关注和支持我的朋友。 前几天看到一篇非常不错的关于自动化测试架构的文章,分享一下。原文链接 文章讲的是自动化测试的三个关键:开发语言,平台和工具。这是自动化测试非常核心的三个关键点,但往往也不是那么容易把握或者考虑全面的。参考原文先: Three Key Tools for Automated Testing: Language, Driver, Harness When I started working on Watir, I was pushing a vision for automated testing. This vision still motivates my work with Watir. A couple of years ago, Brian … Continue reading

Posted in 测试自动化 | Tagged | 3 Comments

自动化测试和性能分析文章汇总

以前总结过很多测试的文章,而且都是断断续续的,现在时隔很久,找起来不很方面,现在做个汇总,方面大家查阅。(此处所列文章全部为原创,转载请注明作者和出处) 自动化测试计划和实施 测试自动化的计划和实施 测试自动化的计划和实施总纲 自动化测试的计划和实施第一阶段 自动化测试的计划和实施第二阶段 自动化测试的计划和实施第三阶段 自动化测试的计划和实施第四阶段 测试自动化需三思而后行 何时以及对什么进行自动化 自动化测试开展 自动化测试的思考和总结之开篇 自动化测试的思考和总结之有的放矢篇 自动化测试的思考和总结之天时地利篇 自动化测试的思考和总结之天下三分篇 自动化测试的思考和总结之平台利器篇 自动化测试的思考和总结之工具利器篇 自动化测试的思考和总结之功利篇 LoadRunner结果分析 利用LoadRunner进行性能测试和结果分析(连载一) 利用LoadRunner进行性能测试和结果分析(连载二) 利用LoadRunner进行性能测试和结果分析(连载三) 利用LoadRunner进行性能测试和结果分析(连载四) 利用LoadRunner进行性能测试和结果分析(连载五) 利用LoadRunner进行性能测试和结果分析(连载七) 测试入门必读 软件测试和质量管理推荐书目

Posted in 测试自动化 | Tagged | 1 Comment

自动化测试不是银弹

自动化测试到底是不是银弹? 关于银弹的说法,有这么一个传说: 美国人相信在月圆之美国人夜, 狼人便会出没, 而杀死狼人的唯一方法便是用银制的子弹(Silver Bullet)贯穿它的心脏. [There is no silver bullet]: 意为没有致命, 有效, 一击命中的方法 下面这篇文章,作者 Dawn Haynes 来自:IBM,2005年的一篇经典文章,分享给大家。 没有一种单纯的技术或管理上的进步,能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性。Brooks鼓励我们将技术和方法视作一种演进手段,而并非革命。将自动化技术引入测试工作时,我倾向于支持相同的观点。

Posted in 测试自动化 | Tagged | Leave a comment

自动化测试的计划和实施第四阶段

第四阶段,也是最后一个阶段了。在开始这个阶段之前,还想多说几句,今天又有朋友说他们公司打算实施自动化测试了,开发经理主导的。他们对测试自动化的认识还是停留在自动化测试工具上。只是十分要命的。自动化测试的初衷是要缩短测试周期,出发点是好的,但是步骤明显有问题,测试周期的缩短是可以靠提高测试效率,改进测试方法和引进测试工具来达到的,但是不是决定因素。测试流程的规范才是最根本的,如果一个组织测试流程不规范,想通过引入自动化测试来规范这一流程是很不现实的。 好了,现在开始正题。 自动化测试的第四阶段是收获和ROI(投资回报)

Posted in 测试自动化 | Tagged | Leave a comment

自动化测试的计划和实施第三阶段

进入到自动化测试的第三阶段,此时距离当初开始实施自动化测试的决定,两年三个月已经过去了,可见自动化测试的实施不是一蹴而就的,更不可急功近利。第三个阶段的标志是有点到面的全面铺开。 自动化测试开展的初期,可以是一个小组,几个人进行小面积的试点,这样投入的成本不是很大,即使失败了,也是可以理解和接受的,而要想取得投资回报或者大面积的试用和推广,前提的试点也是必须的。 但是仅仅靠几个人是不可能把自动化测试做起来的。自动化测试的开发工作是一个持续的过程,又是一个矛盾体。 持续的过程体现在:随着回归测试的不断进行,老的功能不断被自动化起来,就有一定的维护工作量,另外,新功能的测试不断完善和稳定,又变成可以进行自动化测试的老功能。所以自动化测试是一个持续进行的过程,另外,又是一个持续改进的过程,随着自动化测试技术的不断成熟和测试业务的不断丰富,以前的老功能的测试用例或者测试脚本也同样需要进行更新和维护。 矛盾体体现在两个方面:首先自动化测试的开发和维护本身需要对测试脚本和测试业务有一定的熟悉。实际情况往往并非如此,精通测试业务的测试工程师一般情况下对测试脚本甚至自动化测试一无所知。而对测试开发非常熟悉的自动化测试工程师又不熟悉业务,所以矛盾就这样产生了。另外,从整体来看,自动化测试工程师的数量肯定远远小于手工测试工程师,这样,对业务测试工程师熟悉自动化测试知识,了解测试平台和测试脚本就提出了更高的要求。如果有一半的测试工程师都能熟悉测试脚本,可以试用测试平台进行相关的自动化测试开发,那么可以肯定的说:自动化测试已经成功了一大半。

Posted in 测试自动化 | Tagged | Leave a comment

自动化测试的计划和实施第二阶段

自从上个月介绍了自动化测试的计划和实施第一阶段,这阵子一直都在忙别的事情,加上博客访问断断续续,所以没有接下去。打算利用这几天的时间把剩下的几个阶段完整的记录下来。也对打算实施自动化和已经在实施自动化过程中的朋友有点帮助吧。另外,也完成自己的承诺,五一之前完成这几篇文章。嘻嘻。 第二阶段的副标题:从烦杂到豁然开朗 其实这是我们经历的真实的过程,从一开始的没有完整的自动化平台和对平台重要性的认识不足,加上缺乏相关的经验,这个过程可谓吃尽了苦头。这这个阶段,即使有了测试平台的支持,随着脚本技术的进步,我们仍然要为以后的维护和扩展付出很大的代价。 这样的痛苦过程经历了大概半年左右的时间,当随着脚本技术的探索思路越来越清晰的时候。其中最关键的里程碑是API概念的提出,就是一个分层的概念。其实也没有多少创意而言,只是在自动化测试概念中提出来,颇有一些不同。

Posted in 测试自动化 | Tagged | 4 Comments