Rational 公司邀请我看了看它们的新产品,Rational PobotJ。它们邀请我有两个原因。一个原因很明显,就是由于我长时间进行测试自动化的工作,了解大量的人们正确使用(以及误用)这些测试工具的方式。第二个原因就是由于我从来没有使用过Rational Robot或者该公司的Test Manager模型,所以凭借我的自动化背景可以清晰地洞察出他们是如何设计软件测试自动化解决方案的。
Rational 公司邀请我看了看它们的新产品,Rational PobotJ。它们邀请我有两个原因。一个原因很明显,就是由于我长时间进行测试自动化的工作,了解大量的人们正确使用(以及误用)这些测试工具的方式。第二个原因就是由于我从来没有使用过Rational Robot或者该公司的Test Manager模型,所以凭借我的自动化背景可以清晰地洞察出他们是如何设计软件测试自动化解决方案的。
我拿到了一份Rational RobotJ的β版,然后就急于开始研究Rational 的最新工具会给软件测试带来什么样的变化。多年来,我已编写了很多Rational Visual Test自动化脚本,我很想看看这个工具在测试基于Web的应用程序领域中会取得什么样的成就。
我花了几分钟安装该工具,到处点击来熟悉界面的内容,主要是想看看这到底是个什么东西,最后我决定先使用一下工具栏中的Record new RobotJ script 按钮。这东西到底怎么样,我暗自思忖,且看看它会创建出什么样的冗长脚本来,既可以准确地记录我的操作,还可以保持同步,以保证回放功能确实好使。当使用记录和回放(record-and-playback)工具时,我稍稍有点嘲讽心理。
虽然更喜欢旧式优秀的匆匆编写代码的方式,但是我还是渴望了解这个工具的更多功能。不过,使用记录器是了解有关自动化工具以及正确使用该工具的最佳方式之一。您马上就会发现,记录器不仅仅曾经是(现在也是)深入学习RobotJ的伟大工具,它也是Rational所希望的帮助人们创建大量测试脚本的最佳方式。它也确实做得很棒!
我曾经听到过有关测试自动化的传言,据说Rational 准备发布一种新产品,主要用于测试HTML与基于Java 的web 应用程序。而且,考虑到面向对象编程语言的特有优点,准备使用Java 作为其编程语言。我很想看到它的面世,越快越好。这肯定是一种新型有关编程的玩具语言,我已经等不及要使用它了。
多年来我一直选择Rational Visual Test 编写软件测试自动化的脚本。它使用类似Visual Basic 的语言,编程进行起来简单直接,同时它也具备使用指针处理复杂数据结构的高级功能,这也使它成为一种真正的语言。Visual Test 甚至在版本6.0中加入了测试网页的功能。该功能确实好使,而且一直在发挥着作用,但是在测试工具中加入此功能的最初目的是用来测试Microsoft 的Windows 程序的。Visual Test 一直努力成为终极的、无所不能的软件测试自动化工具,而且可以肯定地说,多年来它一直如此。
现在,我仍然使用VT ,即使对于那些非测试的解决方案。但是,当一种主要用于测试web应用程序的新型工具即将发布的时候,我确实想看看它到底能够实现什么功能,而且我也十分喜欢使用Java 作为脚本语言。
我一直尽力将良好的编程实践教授给我的学生和客户,同时还有创建类似面向对象脚本的方法,以及使用并不是那么面向对象的语言完成数据隐藏、封装和简单形式的继承。这些方法都十分有效,但是如果使用面向对象语言的话,就不仅仅是鼓励使用这些方法那么简单了,而是可以加强进行这些实践。这就是我为什么喜欢RobotJ 使用Java 作为其脚本语言的原因了。
我想我还是从简单的地方开始吧:单击一些链接来看看它在屏幕显示不下时是否较好地处理了浏览器窗口的滚动以及页面加载的滞后时间是否较长。但是,随后我又从另一个角度进行了一下思考:如果测试驾驶一辆承诺具有强大发动机和超速悬挂装置的新型轿车,我能仅仅坐在那里来验证转弯信号是否好使吗?或者来检验车载音响中的噪声程度吗?好,是的,确实如此。但是除此之外,我肯定想要亲自驾驶它,经过大量的弯道,同时收听广播中的Talk of the Nation。
显然,我不会第一次驾驶就经过太多的弯道,因为我不想撞到墙上。我只想让我记录的源代码确实可以进行工作;我还是对记录的脚本有点怀疑,不知道它是否能够正常工作。于是,我单击了记录按钮,并且按照下述步骤进行操作:
作为一名测试自动化程序员,我对于使用RobotJ 记录器预想了很多概念。这些概念都是通过使用Visual Test 和其他测试自动化工具得出的。我预先考虑了许多问题,尤其是:
兼容性:最初,我有点担心它与Microsoft Internet Explorer 6.0的兼容性问题。Microsoft 不断快速地推出其浏览器的更新版本,我不知道RobotJ 是否能够跟得上节奏。Rational 肯定在使用IE API 提供的内部对象模型,Visual Test 团队也是如此,但是Microsoft 的内部二进制数字并不总是如预期那样的有效,还需要开发团队再进行大量的工作。我设想对于RobotJ 开发人员也是如此。
脚本长度:我担心可能会创建出很长的脚本,里面还带有大量的延迟或者休眠语句,用来模拟我在键入和单击过程中的实际延迟。我也在期待着有大量的命令检验浏览器窗口的大小和位置、屏幕分辨度以及其他有时可能造成致命故障的错误,并且创建出很长的脚本。
延迟的问题:我预想脚本仅仅可以在理想状态下运行,服务器可以在记录创建时或者比其更快地进行响应。在服务器滞后时,我预想肯定需要在特定点暂停,例如在单击链接以跳离当前页时,并使用附加源代码调整脚本。
不过,我所得到的给了我一个惊喜,让我非常高兴:
兼容性:点击链接,键入多个<input type=text>输入框控件、<textarea> 控件、<select><option>下拉列表框、<input type=submit>按钮,使用post和get方法提交表单,所有这些都工作正常,没有问题。我还没有使用其他的浏览器进行测试,但是我很高兴地发现它正确地识别了测试状态下网页上的许多不同控件,而且更重要的是,回放功能也成功运行。
简洁的源代码:源代码是简洁的,并且具有良好的可读性。通过使用Helper 的基类,所有的外部源代码都从视图中隐藏起来,只剩下我感兴趣的源代码。正如预料的那样,加入了注释帮助指导自动化程序员了解源代码中的每行都进行了什么操作。不过,还有些我没有预料到的附加信息也包括于注释中,特别是按下Place Order Now 按钮所提交的信息。
同步性:由于源代码中没有明显地加入休眠或者延迟信息,同时Helper 基类也可以处理所有的控件识别问题,所以操作只有在单击控件时才得以执行。如果是这样的话,脚本就不会记录填写表单和点击恰当控件的信息。不过,如果页面仍处于装载状态或者仍在识别页面上的控件和链接时,它也可以耐心等待。
为了让您更加明白,我尝试在本文档的开始几页中创建一些示例脚本。创建的源代码展示于下一页的清单1 中。(注意:必须进行一些细小的格式操作,使本文档中的代码更加可读,包括移去一些自动创建的注释)。在随后几页中,我会教您如何使用RobotJ 创建这些脚本,并讨论一些有关创建脚本的关键问题,然后研究运行脚本得到的结果。