测试 Web 2.0 程序所带来的挑战：使用 GUI 恢复性能评测来补充 Web 2.0 性能测试

核心提示： 这些问题对提供规模指南的团队也会造成影响，决定服务器配置，测试 Web 2.0 程序所带来的挑战：使用 GUI 恢复性能评测来补充 Web 2.0 性能测试(2)，以确保预期服务器负载足够的响应时间得到了完善的记录，但是当服务器不再是主要的瓶颈时，可以获得关于 预期 性能一定程度的自信心（此时用

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

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

这个问题的解决方法：

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

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

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

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

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

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

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

范例：Rational Functional Tester 方案

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