使用 GUI 恢复性能评测来补充 Web 2.0 性能测试
学习怎样使用已存在的工具，来更好地测试对于 Web 2.0 的末端用户经验，从而帮助您的公司解决测 试中存在的挑战并提高程序的质量。使用为测试服务专门定制的测试工具，您就能优化使用 Web 2.0 技 术，建立浏览器更好的业务逻辑结构。
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 自动化操作。这一步可能会在不断增长的工作负荷，压 力场景下而完成。