Web 2.0 测试中存在的挑战

　　Web2.0是一种新的很实用的技术，用于构建Internet的多客户程序。具体来说取决于谁来描述它，在需求动态内容或者一系列其他事情上它可以是社交网络的，mashups。

　　从测试的角度来看，目前的主要关注点是使用的新技术，以及这些新技术更改测试方案的方式。Web2.0技术通过Javascript，FLEX，Ajax，Dojo以及其他Web2.0技术，将Web程序转化为使用客户端技术创建的对浏览器（例如，客户端）来说完善的程序逻辑结构。因为大多数的性能测试工具得到了优化，以决定服务器的响应时间，这使得使用这些新技术的Web2.0程序的功能性测试与性能测试之间，产生了隔阂。

　　这种模式转移所造成的后果之一，便是增加了对从末端客户端进行测试的依赖性，特别是在浏览器中的图形化用户界面（GUI）中导航时更是这样。对于Java脚本操作的功能性确认来说，这一点确实是存在的，因为对于测试程序的响应时间来说。没有API界面层。

　　从前，在浏览器中交付GUI的时间与服务器处理时间相比，被认为是0。现在这样想错了。用户经验可以定义为“什么时候我可以再次点击一些什么东西呢？”当性能测试依赖服务器响应时间以预测Web2.0程序中的用户经验时，通常会遇到的一个问题是，“什么程序持续了这么长的时间？”事实上，人们不再能够假设，服务器响应时间已经足够预测响应时间的用户经验了。

　　这些问题对提供规模指南的团队也会造成影响。决定服务器配置，以确保预期服务器负载足够的响应时间得到了完善的记录。但是当服务器不再是主要的瓶颈时，团队是怎样作出部署推荐的呢？通过这种方式，超出您控制之外的浏览器性能，已经变得更加重要。但是人们仍然没有注意到程序构建的问题。

　　测试员都要做些什么呢？现在Web2.0性能测试需要考虑GUI交付问题，以及一些性能工具不需要完成的工作。

　　这个问题的解决方法：

　　设计一个有意义的用例以确认GUI响应时间。

　　实施一个执行用例的性能工具的性能测试。

　　对于相同的用例使用定时器（稍后会有更多信息）来创建GUI自动化。

　　在单一用户模式下运行GUI自动化（系统上没有负载）以创建一个对工具负载负责的基线。

　　使用性能自动化来载入服务器并重新运行GUI自动化操作。这一步可能会在不断增长的工作负荷，压力场景下而完成。

　　GUI恢复的原始基线数据并不应该被当做是“”的数值。任意定量化GUI恢复时间的操作都有来自自动化代码和自动化工具方面的负荷，除非您使用单个的用户来创建一条基线。因为该负荷是静态的，所以比较是有效的，而且性能测试应用中标准偏差的典型使用也是有效的。在这种方法下，如果一次GUI操作单个用户需要1ms的时间，而在服务器出于一定负荷下重复操作（或者作为平均值）需要10ms的时间，负荷下的GUI有10倍的性能降级。

　　通过将GUI恢复时间评测与使用相似方式载入服务器的操作合并起来，可以获得关于预期性能一定程度的自信心（此时用户可以执行下一次点击操作）。

　　范例：RationalFunctionalTester方案

　　为了测试完成一次操作之后恢复GUI所需要的时间，您需要执行一些操作。

　　计时的方法学

　　作为一个团队，需要决定去评价什么。您不需要在GUI评测事务，以匹配在性能测试工具中创建的性能脚本所评测的性能事务，这些性能测试工具例如有IBM?Rational?PerformanceTester方案。但是，团队应该测试应该得到的目标达成一致意见。

　　但是，在GUI端，让所有外部的负荷保持在评价之外是非常重要的。将所有的工具负荷删除是不可能的（原则性的原因，这些值不是的响应时间），但是您可以采取一些措施，去低化负荷所造成的影响。例如，当您在使用IBM?Rational?FunctionalTester工具时，您可以完成以下的操作：

　　如果使用动态搜索，那么您需要确定在定时器内部控制的所有控件，都需要在开始评价之前搜索到。

　　所有需要得到实例化的Java?对象都需要在开始评价之前完成

　　点击事务中的某个对象

　　一旦GUI为下一次点击做好了准备，立即停止计时。例如，在Eclipse中确认进度条窗口得到了关闭，或者向导对话框得到了关闭。对于Web程序，您可能会确定出现了一个控件，或者载入了一个新的页面。尽可能少地确认，并且确认机理等待/重试确认继续之后存在的支持。在这里并不推荐更改运行期间的等待/重试时间，所以您要确定它们是评价事务中的“硬代码”。

　　当您在设计一个类以进行评价时，您要确认一旦计时开始没有对象执行，计时器启动方法中也没有其他操作了。与之类似，停止方法所完成的处理应该在获取停止时间之后执行。