测试 Web 2.0 程序所带来的挑战

最新推荐文章于 2023-07-03 04:06:26 发布

cslsa42868

最新推荐文章于 2023-07-03 04:06:26 发布

阅读量105

点赞数

转自

http://www.ibm.com/developerworks/cn/rational/10/testingweb2dot0applicationchallenges/index.html

Web 2.0 测试中存在的挑战

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/

cslsa42868

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
测试 Web 2.0 程序所带来的挑战

转自 http://www.ibm.com/developerworks/cn/rational/10/testingweb2dot0applicationchallenges/index.htmlWeb 2.0 测试中...
复制链接

扫一扫