w1100n
This site is best viewed in Google Chrome
6/30/2013 22:58

基于界面的软件自动化测试经历了4个发展阶段。 (1).无框架阶段(即简单的录制/回放) 在早期,自动化测试并没有框架这一说,自动化测试只是简单的录制/回放,由工具录制并记录操作的过程或数据,并形成脚本。通过对脚本的回放重复人工操作的过程。这种模式脚本与数据混合在一起。站在软件开发的角度来看,这种开发耦合度高,我们知道软件工程的思想,是高内聚低耦合。而简单的录制回放完全违背了这一思想,简单的录制回放,重用性非常低,同时维护成本非常高。 (2).数据驱动框架阶段 无框架阶段最大的缺点就是脚本与数据混合在一起。为了解决这一问题,自动化测试框架发展到了数据驱动框架阶段。该框架从数据文件中读取数据,通过参数化的方式将数据文件中读取数据写入到脚本中(好比从数据库中读数据),由于不同的数据对应着不同的测试用例,将脚本与数据彻底地分离,因此提高了脚本的使用率,大大降低了脚本的维护成本。虽然数据驱动框架解决了脚本与数据的问题,但并没有将被测试对象与操作分离。 (3).关键字驱动框架阶段 关键字驱动框架是在数据驱动框架的基础上改进的一种框架模型。它将测试逻辑按照关键字进行分解,形成数据文件与关键字对应封装的业务逻辑。主要关键字包括3类:被测试对象(Item)、操作(Operation)和值(Value).用面向对形式将其表现为Item.Operation(Value)。关键字驱动的主要思想是:脚本与数据分离、界面元素名与测试内部对象名分离、测试描述与具体实现细节分离 最初用QTP就是简单的录制,然后修改脚本,缺点如下: 1. 应用软件必须具备一定的稳定性,并且在整个业务流程上都必须完整的实现了,否则顺序录制整能实现? 2. 自动化脚本的维护性成本非常的高 3. 自动化脚本的可重用性比较差 随之出现了关键字驱动的概念,一切都以对象为出发点,这有点像编程语言中从过程化向面向对象转化,在QTP中的具体实现方法是: 1. 在单个程序界面上将测试所涉及到的对象手工添加到对象库中 2. 在专家视图中基于对象库中的对象编写自动化测试脚本 以上这样做的明显的优点在于: 1. 脚本的可控性非常的强,模块化组织也比较好 2. 可以在开发完全实现所有的业务流程功能前就建立测试脚本,占据了比较大的主动性,为时间上的安排提供了更大的空间,一个词概括:“测试先行” (4).混合模型框架阶段 关键字驱动框架将自动化测试框架带入了一个新的阶段,自动化测试工具QuickTest也很好地使用了该理念,但在实际开展自动化测试的时候,发现测试工具所带来的关键字驱动框架还是无法很好地完成测试任务。该框架虽然将数据与脚本进行了分离,但是如果要更灵活地调用测试用例中的数据或输出测试结果,该框架无法做到;并且如果需要读取其他文件存储格式中的数据时也无法很好地解决。因此,在自动化测试开始的前期,工程师会开发一个符合实际测试的框架来支持后期的测试工作,这就是通常所说的混合模型自动化测试框架。 参考资料:黄文高的 《QTP自动化测试与框架模型设计》 转自: http://www.cnblogs.com/jasonteststudy/archive/2011/08/01/2123450.html 关于数据驱动和关键字驱动

6/30/2013 19:50

http://blog.csdn.net/baggioan/article/details/4577602 我从毕业到现在, 曾在大小不同的三个公司就职: 有民营的、有外资的、也有上市公司。 但以前大多都是做项目,从事软件开发工作,绝大部分公司对测试都不重视,即使有也没有成规模, 更谈不上建立测试体系。总之,重开发轻测试的管理思想在中国延续了几十年、并且还要继续,看看他们给测试工程师开的低工资和老师在课堂上讲到测试时一笔带过就知道测试被中国的老板所忽略。 最近两年,我从事CRM软件产品的测试、项目管理工作。 由于公司对软件的质量要求特别高, 这必然引起了大家对测试工作的重视,不但要求有强大的测试团队,该团队必须具备在业务方面、测试技能方面的专业水平, 而且在软件开发过程方面经常由于测试而作持续不断地调整。 幸运的是,随着软件开发技术和工具的提高,软件工程和软件过程实践的推广, 软件测试日益得到重视和专业化。 我从事测试工作期间,一直研究CMM、测试理论、自动化测试工具,并建立了一套完整的测试体系。 在此并不介绍整个测试体系,而是介绍测试方面最值得探讨的部分:持续集成与测试自动化。目的是与大家共同进步。当然已经有很多关于持续集成和自动化测试方面的介绍,但我要介绍的不只是持续集成,也不只是自动化测试,而是测试如何的自动化. 二、测试自动化 自动化测试就是希望能够通过自动化测试工具或其他手段,按照测试工程师的预定计划进行自动的测试,目的是减轻手工测试的劳动量,从而达到提高软件质量的目的。自动化测试的目的在于发现老缺陷。而手工测试的目的在于发现新缺陷。 测试自动化涉及到测试流程、测试体系、自动化化编译、持续集成、自动发布测试系统以及自动化测试等方面整合。也就是说要让测试能够自动化,不仅是技术、工具的问题,更是一个公司和组织的文化问题。首先公司从资金、管理上支持您,其次要有专门的测试团队去建立适合自动化测试的测试流程、测试体系;其次就是把原代码从受控库中取出、编译、集成、发布可运行系统、进行自动化的单元测试和自动化的功能测试的过程。 (一)、自动化测试的好处 1、 对新版本执行回归测试--测试每个特征 对于产品型的软件,每发布一个新的版本,其中大部分功能和界面都和上一个版本相似或完全相同,这部分功能特别适合于自动化测试, 从而可以让测试达到测试每个特征的目的。 2、 更多更频繁的测试--沉闷、耗时 我们的产品向市场的发布周期是3个月,也就是我们的开发周期只有短短的3个月,而在测试期间是每天/每2天都要发布一个版本供测试人员测试,一个系统的功能点有几千个上万个,人工测试是非常的耗时和繁琐,这样必然会使测试效率低下。 3、替代手工测试的困难--300个用户有些非功能性方面的测试:压力测试、并发测试、大数据量测试、崩溃性测试,用人来测试是不可能达到的。 在没有引入自动化测试工具之前,为了测试并发,研发中心的一、两百号人在研发经理的口令:1-、2-、3!, 大家同时按下同一个按钮。回想起这中情景也蛮有意思的。 4、具有一致性和可重复性 由于每次自动化测试运行的脚本是相同的, 所以每次执行的测试具有一致性, 人是很难做到的. 由于自动化测试的一致性,很容易发现被测软件的任何改变。 5、更好的利用资源--周未/晚上 理想的自动化测试能够按计划完全自动的运行, 在开发人员和测试人员不可能实行三班倒的情况下, 自动化测试可以胜任这个任务, 完全可以在周末和晚上执行测试. 这样充分的利用了公司的资源,也避免了开发和测试之间的等待. 6、解决测试与开发之间的矛盾 … Continue reading

6/27/2013 19:49

关于数据驱动,以下这篇帖子还是给了很大的启发:http://bbs.51testing.com/viewthread.php?tid=113729&extra=&highlight=%CA%FD%BE%DD%C7%FD%B6%AF&page=1 摘录一些精妙的论点:  51testing论坛的phililschen: “什么是数据驱动呢?很大一部分人肯定认为数据驱动就是把需要参数化的东西写在EXCEL里,然后在跑脚本时调用。如果我告诉你,这其实不是数据驱动,而只是较高级的参数化,你肯定会很惊讶!现在我来解释一下:首先为什么叫数据驱动呢,那么它肯定有驱动的含义,比如你用EXCEL可以控制测试的业务流吗?回答是不能的。那又如何作到驱动呢?所以说我们将测试数据放在独立的文件里只是高级的参数话。而数据驱动,你必须有数据来控制测试的业务流。比如你测一个WEB程序,有很多页面,你可以通过一个数据来控制每次是再哪个页面下工作的(即通过数据来导航到相应的页面)。它是关键字驱动的低级版本,他控制的是函数级的,而关键字是控制动作级的。所以数据驱动应该是可以控制整个测试的”   51testing论坛的dreamever: “数据驱动本身不是一个工业级标准的概念,因此在不同的公司,都会有好几个解释版本。首先我同意楼主的关于数据驱动的观点,也就是说如果我们仅仅是把测试数据放在数据文件里,这只是一种比较高级的参数化而已。其实我更倾向于把数据驱动理解为一种模式或者一种思想 对于数据驱动的讨论,我们不妨先抛开QTP来进行。无论是进行自动化测试还是手工测试时,我们都需要设计测试用例,准备测试数据,并且把测试用例与数据分开,在一套测试用例上运行多套测试数据是比较有效率的。我相信这一点大家应该都认同吧。 那么我们不妨再看一下手工测试的场景:当一个手工测试人员A发现在测试数据存储目录下多了一套测试数据时,他就会意识到应该马上执行测试用例,并输入这套新的测试数据。其实是测试数据的变化触发了A的测试行为。(有人可能说了我们公司不是这么做的,注意,我们不是在讨论实际的测试管理,我们在对测试模型进行抽象)。如果我们更抽象一下,可以这样来看:当测试数据变化时,测试用例就会被执行(无论是A主动还是leader打电话通知),并且按照预先定义的规则去读取测试数据并执行测试用例。那么这种情况我们是不是可以理解为一种数据驱动呢?也就是说只要有了新的测试数据或者测试数据发生了变化,那么A就会去执行测试用例。这一过程的目的就是为了让所有的测试数据都得到输入并返回相应的输出结果。 如果大家同意上面的情景是一种数据驱动测试的例子,那么我们可以对自动化测试中的数据驱动进行同样的解释:由机器自动读取测试数据,然后测试用具运行测试脚本执行测试用例,并按照预先设置好的参数化字段读取测试数据,返回测试结果。目的就是使所有的测试数据都得到输入,并返回输出,验证数据的输入和输出是否符合预期值。这里的测试数据不仅包括业务数据,还包括一些动作关键字或决策关键字,以提供足够的信息,让测试工具知道该调用什么样的脚本,应该如何处理各种情况。相对于不同的测试工具,其表现形式有可能不同,QTP提供了关键字视图和数据表,robot提出了决策表的概念,Watir的话本身没有什么特殊的模式,完全看测试人员把框架设计成什么样了。其实本质上都是消息驱动的不同表现而已,例如刚才的手工测试的例子,测试数据发生变化我们可以把它看成一种消息,接收到这个消息A就开始执行测试。”   51testing论坛的jackmail: “数据驱动中的 driven 一词,你可以简单的理解成导向,导向什么?结果。就是测试数据决定了测试结果,这就是所谓数据驱动,QTP实现了数据驱动的功能,模型,feature,特征,无非是个词汇而已,怎么说都没问题,用QTP你可以简单的完成你想实现的数据驱动方法的测试,他就是实现了xx功能。 还有关键字驱动,就是 关键字决定了结果。 在QTP里关键字就是step中的测试对象名称(对象方法属性,或者值(测试数据))。测试对象名称的改变,就决定了结果的变更。以前有些人写的所谓框架是把对象从Excel表格中导入导出的,他们实现的就是关键字驱动。 什么驱动,就是什么决定结果。本来结果是固定的,由于驱动数据的变更,导致了结果的不同,没那么复杂。其实概念都是人定的,少去钻牛角尖,理解个大概意思就行了。”   最后引用一下一篇关键字驱动的理解的文章,毕竟这是QTP主推的东西 最初用QTP就是简单的录制,然后修改脚本,缺点如下: 1. 应用软件必须具备一定的稳定性,并且在整个业务流程上都必须完整的实现了,否则顺序录制整能实现? 2. 自动化脚本的维护性成本非常的高 3. 自动化脚本的可重用性比较差 随之出现了关键字驱动的概念,一切都以对象为出发点,这有点像编程语言中从过程化向面向对象转化,在QTP中的具体实现方法是: 1. 在单个程序界面上将测试所涉及到的对象手工添加到对象库中 2. 在专家视图中基于对象库中的对象编写自动化测试脚本 以上这样做的明显的优点在于: 1. 脚本的可控性非常的强,模块化组织也比较好 2. 可以在开发完全实现所有的业务流程功能前就建立测试脚本,占据了比较大的主动性,为时间上的安排提供了更大的空间,一个词概括:“测试先行”

6/24/2013 20:24

http://blog.csai.cn/user1/37581/archives/2007/20689.html 如果要搭建自动测试体系,需要完成以下几个工作: 1、规范测试脚本的配置管理 2、制定测试脚本的编码规范,QTP脚本还要制定对象仓库和VBS的规范 3、创建自动测试实验室,通过控制台指挥各个测试机分布式执行脚本,并集中收集测试结果 4、健全测试脚本的维护机制,脚本责任到人   下面先讲一下第一点:脚本的配置管理,因为QTP本身提供了和QC集成的功能,使用QC作为配置管理工具非常合适,而且在组建测试实验室的时候,QC也有很强的优势,后面会讲到。   只要利用QTP的QC连接功能,就可以直接把Test、对象仓库等资源保存在QC服务器上,这里我主要讲一下QC的目录分类管理。在根目录下可以建一个common目录,里面主要存放vbs脚本文件,这些脚本文件提供了各个Test需要调用的公共方法,比如和数据库交互。   然后在根目录按照功能模块的名称建立文件夹,下面保存每个功能模块的所有Test和资源。建议每个功能模块目录下面建三个大目录,分别是work、主要流程、功能点。   work里面保存对象仓库文件和此功能Test私有的vbs文件;“主要流程”和“功能点”保存测试脚本也就是Test。“流程”里的每个Test,都覆盖了一个完整的、正常的、独立的流程,Test的名称就是流程的名称,比如“注册用户”、“发布新帖子”。注意不要一个Test包含多个流程。“功能点”中每个Test只覆盖一个功能点,比如“检查用户是否已存在”、“密码长度不能小于6字节”。总之,每个Test要做到独立,请参考这篇文章: 《测试脚本的独立性》   我们只要执行了“流程”的Test,就能保证基本的功能OK。但是这还远远不够,还有一些重要的功能点需要覆盖。其实我们的测试脚本并不需要覆盖100%的功能点,根据28原则和我们的历史经验,大部分的bug都是集中在那一小部分(大约20%)主要的功能点中。我们的脚本要以这些功能点为主。当然,以后在回归过程中,如果需要增加功能点的Test,就直接在这个目录下新建Test即可,这一点非常重要,通过对功能点Test的不断积累,就能让我们的自动测试越来越完善。而流程的Test一般改动不多。   关于第二点测试脚本编码规范,本文不做详细介绍。大家需要注意的是,测试脚本就是我们的测试代码,是代码就需要编码规范。如果要实现一个团队的合作,必须有规范。关于对象仓库的规范,请参考这篇文章: 《管理QTP测试脚本的对象仓库》   构建测试实验室的工作是比较开心的,我们可以准备一批PC作为测试机,也可以购买配置较好的服务器,安装虚拟机,将虚拟机作为测试机。关于QC远程调用QTP的相关设置,请参考这篇文章: 《QC远程调用QTP》   通过以上的工作,技术问题基本解决了,我们还需要管理流程,来保证测试体系的健康。这里我只讲一点:测试脚本责任到人。比如A君负责几个模块的自动测试,那么他需要做什么呢?这里总结了几点: 1、主要流程的脚本编写 2、确定主要功能点的范围和组织团队成员编写脚本 3、保证QC中的脚本始终可用 4、如果需要增加功能点的Test,需要他来跟踪并保证脚本质量 5、当脚本出现问题时负责解决问题   负责人并不需要完成所有的脚本编写工作,他可以组织大家一起做,但是他需要保证脚本库的健康,最好也能保证脚本的编码规范。

TDD
12/10/2012 21:37

测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践,但不只适用于XP(Extreme Programming),同样可以适用于其他开发方法和过程。TDD的基本思路就是通过测试来推动整个开发的进行,但测试驱动开发并不只是单纯的测试工作,而是把需求分析,设计,质量控制量化的过程。 TDD的重要目的不仅仅是测试软件,测试工作保证代码质量仅仅是其中一部分,而且是在开发过程中帮助客户和程序员去除模棱两可的需求。TDD首先考虑使用需求(对象、功能、过程、接口等),主要是编写测试用例框架对功能的过程和接口进行设计,而测试框架可以持续进行验证。 优缺点 优点:在任意一个开发节点都可以拿出一个可以使用,含少量bug并具一定功能的产品。 缺点:增加代码量。测试代码是系统代码的两倍或更多。 TDD = TFD + Refactoring (TFD — Test First Development) 计算机领域: Test Drived Develop

QTP
12/10/2012 21:01

QTP是quicktest Professional的简称,是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试,主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试,例如要测试那些功能、操作步骤、输入数据和期望的输出数据等Mercury QuickTest 企业级自动化测试工具! 现在已经被惠普收购,正式名字为HP QuickTest Professional software ,最新的版本为HP QuickTest Professional 11.0 HP QuickTest Professional 提供符合所有主要应用软件环境的功能测试和回归测试的自动化。采用关键字驱动的理念以简化测试用例的创建和维护。它让用户可以直接录制屏幕上的操作流程,自动生成功能测试或者回归测试用例。专业的测试者也可以通过提供的内置脚本和调试环境来取得对测试和对象属性的完全控制。 1)QTP是一个侧重于功能的回归自动化测试工具;提供了很多插件,如:.NET的,Java的,SAP的,Terminal Emulator的等等,分别用于各自类型的产品测试。默认提供Web,ActiveX和VB。   2)QTP支持的脚本语言是VBScript,这对于测试人员来说,感觉要“舒服”得多(如相比SilkTest采用C语言)。VBScript毕竟是一种松散的、非严格的、普及面很广的语言。   3)QTP支持录制和回放的功能。录制产生的脚本,可以拿来作为自己编写脚本的template。录制时,还支持一种lower level 功能,这个对于QTP不容易识别出来的对象有用,不过它是使用坐标来标识的,对于坐标位置频繁变动的对象,采用这种方式不可行。另外,QTP的编辑器支持两种视图:Keyword模式和Expert模式。Keyword模式想法是好的,提供一个 描述近似于原始测试用例的、跟代码无关的视图(我基本很少用,除了查看、管理当前test中各个action的完整流程),而Expert就是代码视图,一般编写脚本都在这个区域。   4)一个有用的工具:Object Spy,可以用来查看Run-time object和Test object属性和方法。   5)QTP通过三类属性来识别对象:a)Mandatory; b)Assitive; c)Ordinal identifiers。大部分情况下,通过对象的一些特定属性值就可以识别对象(类型a)。这些属性可以通过Tools->Object Identification 定义。   6)Object Repository(OR)是QTP存储对象的地方。测试脚本运行后,QTP根据测试脚本代码,从这个对象库中查找相应对象。每个Action可以对应有一个或者多个OR,也可以设置某个OR为 sharable的,这样可以供其他Action使用。注意,使用QTP录制功能时,默认将被测对象放在local OR中,可以通过 Resources->Object Respository,选择Local查看。   7)说到QTP的要点,不得不说Action。Action是QTP组织测试用例的具体形式,拥有自己的DataTable和Object Repository,支持Input和output参数。Action可以设置为share类型的,这样可以被其他test中的Action调用(注意:QTP是不支持在一个test中调用另外一个test的,只有通过sharable … Continue reading

10/24/2012 15:15

在世面上的自动化测试工具很多。有开源的,有商业化的,各有各得特色,各有各得优点!下面我就介绍几个我用过的开源自动化测试工具。 1 测试 WEB SELENIUM可以说是测试WEB最全面的开源自动化工具, 它可以在WINDOWS, LINUX, MAC 和 SOLARIS 上运行, 而且可以几乎用任何一种编程语言进行构建, 你可以用你熟悉的语言包括 JAVA, C#, PERL, PHP, PYTHON 和 RUBY。 它可以测试的浏览器有IE, FIREFOX, OPERA 和 SAFARI。 SELENIUM 家族成员有:SELENIUM, SELENIUM RC, SELENIUM IDE, SELENIUM CORE, SELENIUM GRID 和 SELENIUM ON RAILS。 GOOGLE 每天都要在他的TESTING FARM上跑几万个SELENIUM测试CASE,现在也些会更多,你如果想学习SELENIUM, … Continue reading

9/3/2012 10:51

http://www.parasoft.com/jsp/products/jtest.jsp Parasoft Jtest is an integrated Development Testing solution for automating a broad range of practices proven to improve development team productivity and software quality. It focuses on practices for validating Java code and applications, and it seamlessly integrates with Parasoft SOAtest to enable end-to-end functional … Continue reading

8/31/2012 15:52 | Tag:

  GetToProperty:Returns the value of the specified property from the test object description. GetTOProperties:Returns the collection of properties and values used to identify the object. GetROProperty:Returns the current value of the test object property from the object in the application. … Continue reading

5/26/2012 19:50 | Tag:

字符 描述 将下一个字符标记为特殊字符或字面值。例如”n”与字符”n”匹配。”n”与换行符匹配。序列”\”与””匹配,”(“与”(“匹配。 ^ 匹配输入的开始位置。 $ 匹配输入的结尾。 * 匹配前一个字符零次或几次。例如,”zo*”可以匹配”z”、”zoo”。 + 匹配前一个字符一次或多次。例如,”zo+”可以匹配”zoo”,但不匹配”z”。 ? 匹配前一个字符零次或一次。例如,”a?ve?”可以匹配”never”中的”ve”。 . 匹配换行符以外的任何字符。 (pattern) 与模式匹配并记住匹配。匹配的子字符串可以从作为结果的Matches集合中使用Item[0]…[n]取得。如果要匹配括号字符(和),可使用”(“或”)”。 x|y 匹配x或y。例如”z|wood”可匹配”z”或”wood”。”(z|w)oo”匹配”zoo”或”wood”。 {n} n为非负的整数。匹配恰好n次。例如,”o{2}”不能与”Bob中的”o”匹配,但是可以与”foooood”中的前两个o匹配。 {n,} n为非负的整数。匹配至少n次。例如,”o{2,}”不匹配”Bob”中的”o”,但是匹配”foooood”中所有的o。”o{1,}”等价于”o+”。”o{0,}”等价于”o*”。 {n,m} m和n为非负的整数。匹配至少n次,至多m次。例如,”o{1,3}”匹配”fooooood”中前三个o。”o{0,1}”等价于”o?”。 [xyz] 一个字符集。与括号中字符的其中之一匹配。例如,”[abc]”匹配”plain”中的”a”。 [^xyz] 一个否定的字符集。匹配不在此括号中的任何字符。例如,”[^abc]”可以匹配”plain”中的”p”. [a-z] 表示某个范围内的字符。与指定区间内的任何字符匹配。例如,”[a-z]”匹配”a”与”z”之间的任何一个小写字母字符。 [^m-z] 否定的字符区间。与不在指定区间内的字符匹配。例如,”[m-z]”与不在”m”到”z”之间的任何字符匹配。 b 与单词的边界匹配,即单词与空格之间的位置。例如,”erb”与”never”中的”er”匹配,但是不匹配”verb”中的”er”。 B 与非单词边界匹配。”ea*rB”与”never early”中的”ear”匹配。 d 与一个数字字符匹配。等价于[0-9]。 … Continue reading

5/3/2012 12:46

Selenium WebDriver, Watir, Sahi

5/2/2012 23:05

Benchmark Tools Phoronix Test Suite Comprehensive testing and benchmarking platform IOzone Filesystem benchmark tool that measures a wide variety of file operations netperf A network performance benchmark LLCbench Low Level Architectural Characterization Benchmark Suite HardInfo System Profiler and Benchmark GtkPerf … Continue reading

3/14/2012 12:38

Google开源了WindowTester Pro 作者 Abel Avram 译者 曹如进 发布于 2012年3月10日 http://www.infoq.com/cn/news/2012/03/WindowTester-Pro Google在Eclipse公共许可1.0版本下开源了WindowTester Pro。 WindowTester Pro是一款用于SWT和Swing GUI自动化测试的Java工具。该工具可在Eclipse 3.5、3.6、3.7中和使用Ant时创建和执行JUnit测试。WindowTester拥有记录模式,它可以记录每一次按键、每一次鼠标点击,并通过自动地反复执行整个过程来测试应用程序的GUI。 WindowTester与WindowBuilder Pro以及CodePro AnalytiX同属一类应用程序套件,起初由Instantiations, Inc.公司开发,而后在2010年8月被Google接手。在继免费开放这些工具之后,Google又将它们开源并于2010年12月将WindowBuilder和CodePro捐赠于Eclipse基金会。 WindowBuilder是一款深受Java开发人员喜爱的GUI构建工具,它在2009年荣获了Eclipse最佳商业开发工具奖。CodePro则是一款Java代码分析工具。 查看英文原文:http://www.infoq.com/news/2012/03/WindowTester-Pro

2/9/2012 4:41

loadUI 是一个企业级的负载测试工具,测试可分布式运行并可实时修改,与 soapUI 紧密集成,使用高度图形化接口,使得测试变得很简单而且运行迅速。

11/11/2011 2:46 | Tag:

Set objWindow = Window(“micclass:=Window”,”nativeclass:=ConsoleWindowClass”,”index:=0″)

8/8/2011 3:41 | Tag:,

set objElement = objPage.WebElement(“html tag:=TD”,”innertext:=xxxxxx”, “index:=1”).object logger(objElement.outerHtml) Set objElement = objElement.parentElement logger(objElement.outerHtml) Set objElement = objElement.firstChild logger(objElement.outerHtml) Set objElement = objElement.firstChild logger(objElement.outerHtml) logger(objElement.status) objElement.checked=true logger(objElement.status)

辽ICP备14012896