用户一般不会使用同样的一组数据，每位用户通常与服务器进行不同的交互。模拟用户应该也这样做，如果在交互的关键点，脚本可以从一组数据中选择数据，则可以更容易地让您的模拟用户表现出使用不同数据的行为。
从手工执行的会话记录脚本
相对于编写脚本，用浏览器手工运行会话并记录这个会话然后再编辑会容易得多。
JavaScript
一些应用程序大量使用 JavaScript 并且需要模拟客户机支持它。不过，使用客户端 JavaScript 可能会增加对测试系统上系统资源的需求。
分析工具
测量性能只是成功的一半。另一半是分析性能数据。谁能比编写测试工具的人能更好地开发这种分析工具呢?是的，至少理论是这样。无论如何，您的工具箱提供的分析工具越多，您就能做得越好。
测量服务器端统计数字
基本负载测试程序测量客户机/服务器交互中基于客户机的响应时间。如果同时收集其他统计数字，如 CPU 使用情况和页面错误率就更好了。您得到的统计数字越多，您用负载测试系统可以做的就越多。如果有这种数据，那么就可以做一些有用的工作，如查看服务器负载上下文中的客户机响应时间和吞吐量统计。
结束语
用任何一种工具可以完成的工作常常受到人的技能、知识和想像力的局限。在描述用负载测试工具查看什么内容的时候，我们也展示了使用这种工具的各种可能性。现在，您可以运用您的想像力去开拓更多的可能性。
参考资料
阅读 Jack Shirazi 和 Kirk Pepperdine 所写的的全部“关注性能 系列”。
Java Performance Tuning 站点包含上千个性能调优提示和技巧。
“ review of stress testing tools”这篇文章比较了几个免费工具和商业工具。
从 PushToTest 的首席执行官 Frank Cohen 所写的 performance testing SOAP-based applications 一文( developerWorks，2001 年 11 月)学习相关技巧。
教程“IBM Web performance tools”( developerWorks，2002 年 12 月)提供了一些很好的实用建议。
学习如何 stress test your software without stressing out your testers (developerWorks，2001 年 2 月)。
Web 服务是分布式计算的核心，它们之间的交互通常是难于测试的。在“ Stress testing Web services”这篇文章(developerWorks, 2003 年 8 月)中，Chris Wilkinson 表明了压力测试是发现代码缺陷的高效方法，但是其前题条件是这些是有效设计的压力系统。
“ Proofing Web applications for performance and scalability” ( developerWorks，2001 年 6 月)是一个为负载测试开发脚本框架的案例分析。
Apache JMeter 是一个免费的负载/回归测试工具。
The Grinder 是一个免费的工具，它可以用一个图形控制台应用程序来协调测试脚本在多台计算机上的活动。
有关 Web 站点测试和站点管理工具的信息请参阅 Software Q/A Test Resource Center。
在 developerWorks Java 技术专区 可以找到关于 Java 编程各个方面的数百篇文章。
文章来源于领测软件测试网 https://www.ltesting.net/
