转自
http://www.ibm.com/developerworks/cn/rational/10/testingweb2dot0applicationchallenges/index.html
Web 2.0 是一种新的很实用的技术,用于构建 Internet 的多客户程序。具体来说取决于谁来描述它,在需求动态内容或者一系列其他事情上它可以是社交网络的,mashups。
从测试的角度来看,目前的主要关注点是使用的新技术,以及这些新技术更改测试方案的方式。Web 2.0 技术通过 Javascript,FLEX, Ajax,Dojo 以及其他 Web 2.0 技术,将 Web 程序转化为使用客户端技术创建的对浏览器(例如,客户端)来说完善的程序逻辑结构。因为大多数的性能测试工具得到了优化,以决定服务器的响应时间,这就使得使用这些新技术的 Web 2.0 程序的功能性测试与性能测试之间,产生了隔阂。
这种模式转移所造成的后果之一,便是增加了对从末端客户端进行测试的依赖性,特别是在浏览器中的图形化用户界面(GUI)中导航时更是这样。对于 Java 脚本操作的功能性确认来说,这一点确实是存在的,因为对于测试程序的响应时间来说。没有 API 界面层。
从前,在浏览器中交付 GUI 的时间与服务器处理时间相比,被认为是 0。现在这样想就错了。用户经验可以定义为“什么时候我可以再次点击一些什么东西呢?”当性能测试依赖服务器响应时间以预测 Web 2.0 程序中的用户经验时,通常会遇到的一个问题是,“什么程序持续了这么长的时间?”事实上,人们不再能够假设,服务器响应时间已经足够预测响应时间的用户经验了 。
这些问题对提供规模指南的团队也会造成影响。决定服务器配置,以确保预期服务器负载足够的响应时间得到了完善的记录。但是当服务器不再是主要的瓶颈时,团队是怎样作出部署推荐的呢?通过这种方式,超出您控制之外的浏览器性能,已经变得更加重要。但是人们仍然没有注意到程序构建的问题。
测试员都要做些什么呢?现在 Web 2.0 性能测试需要考虑 GUI 交付问题,以及一些性能工具不需要完成的工作。
- 设计一个有意义的用例以确认 GUI 响应时间。
- 实施一个执行用例的性能工具的性能测试。
- 对于相同的用例使用定时器(稍后会有更多信息)来创建 GUI 自动化。
- 在单一用户模式下运行 GUI 自动化(系统上没有负载)以创建一个对工具负载负责的基线。
- 使用性能自动化来载入服务器并重新运行 GUI 自动化操作。这一步可能会在不断增长的工作负荷,压力场景下而完成。
GUI 恢复的原始基线数据并不应该被当做是“绝对”的数值。任意定量化 GUI 恢复时间的操作都有来自自动化代码和自动化工具方面的负荷,除非您使用单个的用户来创建一条基线。因为该负荷是静态的,所以比较是有效的,而且性能测试应用中标准偏差的典型使用也是有效的。在这种方法下,如果一次 GUI 操作单个用户需要 1 ms 的时间,而在服务器出于一定负荷下重复操作(或者作为平均值)需要 10 ms 的时间,负荷下的 GUI 有 10 倍的性能降级。
通过将 GUI 恢复时间评测与使用相似方式载入服务器的操作合并起来,可以获得关于 预期 性能一定程度的自信心(此时用户可以执行下一次点击操作)。
范例:Rational Functional Tester 方案
为了测试完成一次操作之后恢复 GUI 所需要的时间,您需要执行一些操作。
作为一个团队,需要决定去评价什么。您不需要在 GUI 评测事务,以匹配在性能测试工具中创建的性能脚本所评测的性能事务,这些性能测试工具例如有 IBM® Rational® Performance Tester 方案。 但是,团队应该就测试应该得到的目标达成一致意见。
但是,在 GUI 端,让所有外部的负荷保持在评价之外是 非常重要的 。将所有的工具负荷删除是不可能的(原则性的原因,这些值不是绝对的响应时间),但是您可以采取一些措施,去最低化负荷所造成的影响。例如,当您在使用 IBM® Rational® Functional Tester 工具时,您可以完成以下的操作:
- 如果使用动态搜索,那么您需要确定在定时器内部控制的所有控件,都需要在开始评价之前搜索到。
- 所有需要得到实例化的 Java™ 对象都需要在开始评价之前完成
- 点击事务中的某个对象
- 一旦 GUI 为下一次点击做好了准备,就立即停止计时。例如,在 Eclipse 中确认进度条窗口得到了关闭,或者向导对话框得到了关闭。对于 Web 程序,您可能会确定出现了一个控件,或者载入了一个新的页面。尽可能少地确认 ,并且确认机理等待/重试确认继续之后就存在的支持。在这里并不推荐更改运行期间的等待/重试时间,所以您要确定它们是评价事务中的“硬代码”。
- 当您在设计一个类以进行评价时,您要确认一旦计时开始就没有对象执行,计时器启动方法中也没有其他操作了。与之类似,停止方法所完成的处理应该在获取停止时间之后执行。
下面是一个调用事务定时器的范例伪代码,以显示正确的用法:
ShellTestObject topShell = (ShellTestObject)getRootTestObject().find(atDescendant("class", "org.eclipse.swt.widgets.Shell", ".captionText", "My application"))[0]; GuiTestObject projectDlg = (GuiTestObject)topShell.find(atDescendant("class", "org.eclipse.swt.widgets.Shell", ".captionText", "New Project"))[0]; GuiTestObject finishButton = (GuiTestObject)projectDlg.find(atDescendant("class", "org.eclipse.swt.widgets.Button", ".text", "Finisht"))[0]; TransactionTimer timeCreate = new TransactionTimer ("Creating project: " + " project name:"); timeCreate.startTimer(); finishButton.click(); vpDynamic("Check dialog", projectDlg).performTest(false); timeCreate.stopTimer(); |
值得注意的一件重要事情是,搜索与其他的对象初始化操作是在事务计时器的外部执行的。只有 GUI 已经就绪的操作和确认才能继续保持在计时器之内。
在这个类中,会初始化一个 CSV 文件,并且所有的交易时间都会使用一份用户定义的描述来用毫秒记录。
PerformanceLogger 类支持在运行时指定,而不管测试员是否对记录性能结果感兴趣。通过这种方式,可以将计时代码添加到感兴趣的事务中,但是这些事务只会根据兴趣进行评测。Performance 日志文件同样是可配置的,而且测试员可以指定文件的位置和名字。所有提供的文件名都有一个日期/时间标签以确保一个独一无二的文件名 。
在开始一项测试之前,应该先指定创建文件的信息,并且初始化 PerformanceLogger INSTANCE 。初始化代码如下所示:
if (PerformanceLogger.isEnabled()){ String logDir = "C:\temp\perfLogs"; String logPrefix = "Application1Performance"; PerformanceLogger.INSTANCE.setDirectoryPath(logDir); PerformanceLogger.INSTANCE.createPerformanceLogfile (logPrefix+"_Performance"); } |
不论是在什么时候,对趋势与这些结果的分析理解,需要考虑到基线并不是一个绝对的响应时间。我们并没有一种机制,以精确地定量化工具(Rational Functional Tester)或者 Java 代码实施所引入的负荷。上面所描述的计时方法学,目的就是降低这个负荷,并允许将负荷当做只会轻微变化的静态成本处理。有意义的分析是随其他变量而变化的行为,这些变量例如有沿着一个操作的循环,对系统所施加的负荷等等。当您在报告和分析结果时,您所报告和分析的数据,对于这些值所代表的意义要十分的清楚,这一点很重要。任意真正响应时间的指示都可能会产生错误的结论,并对那些实际上并不能改进产品的方面进行讨论。
每一个从 Rational Functional Tester 中运行测试脚本的个人,都会创建它自己的 CSV 文件。为了比较行为,需要对数据进行合并。但是,为了确定所有的运行都用相同的脚本完成,计时器描述(基于 TransactionTimer 的名字)也需要是相同的。
采用以下的范例场景 :
- 运行脚本作为单个用户,服务器上没有负载
- 向服务器添加 10 个虚拟用户的负载,重新运行脚本
- 向服务器添加 50 个虚拟用户的负载,重新运行脚本
- 向服务器添加 250 个虚拟用户的负载,重新运行脚本
- 向服务器添加 500 个虚拟用户的负载,重新运行脚本
结果,会产生五个扩展卡。打开单个的用户基线扩展卡,并删除掉起始/终止列。重新设定消失时间列,以指定基线时间。使用合适的标签来为其余的 4 个扩展卡创建列,以运行测试目标。从每一个扩展卡中复制消耗的时间数据到相应的列中。将文件使用新名字作为一个 Microsoft® Excel® 扩展卡保存。
现在您就可以使用五列的数据,以提供显示 GUI 行为趋势的图表,这个提供的图表基于位于服务器上的负载/压力情况。
现在我们推荐您重复上述的测试步骤几次,以为分析提供一些测试用的数据。
在我们前面的例子中,如果新的项目对话框需要 10 ms 来关闭,而不用对服务器造成什么负荷,那么我们需要记得实际上并不是 10ms。这个时间包括了一些 Rational Functional Tester 负荷,以及一些确认负荷。我们说,行列上的值是 10,12,15,50 以及 100。您可以理直气壮地说,对于 50 多个用户,在用户的响应时间上并不会发生什么大的变动。但是在 250 与 500 用户时,时间就会翻倍。还有一个要注意的是,在达到 250 个用户以后,需要的时间会有一个较大幅度的跃升。
另外,标准的性能分析原则用以理解这些结果。
测试工具完整地达到 Web 2.0 的标准,以及为测试新的 Web 2.0 结构提供完整的方案,都需要一些时间。同时,我们可以使用像在上面概括过的一些创新性方案,将已存在的工具合并起来,以继续满足测试的目标,帮助我们的客户得到使用 Web 2.0 程序的积极经验。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14780873/viewspace-662592/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/14780873/viewspace-662592/