你可以通过很多可用的工具来对一个应用软件进行测试并可以得到有关性能级别和临界点等方面的报告。像大多数工具一样，你要先退出你所运行的东西并对测试做彻底的准备。我将讲到在执行正式负载测试之前要考虑的五点内容。
调整再调整
最近与我共事的测试顾问强调说他遇到的最大的问题是客户不了解功能性测试和负载测试之间的区别。我向他们解释了实际上我们完成了功能性测试并准备好开始进行负载测试。顾问所使用的工具中的一个小型演示表明我们还没有做好对多用户进行测试的准备。
在功能性测试中，只是专注在功能的使用上或是功能的完整性上而不是注重个别的性能表现，这是很容易做到的。在你可以进行测试之前，每一个单一用户都必须被优化。我们的问题是要从单一用户的角度而不是同时共存的用户来进行测试。
调整是一个重复性的处理，但是在搜集资源和长时间的负载测试之前做出彻底的工作将防止你完成过多的循环。
关于性能目标的一致意见
当你开始准备对商业活动的不同范围的代表进行测试规划时，你可能会对每个人关于性能方面的看法和商业情况已经被预知所感到惊讶。你将要对响应时间，每秒的采样数，可接受的错误级别和预期的同时用户的数目等问题进行讨论。
而这可能会搞乱非技术性的管理，不要束缚在数字之上，完成负载测试中性能表现方面的目标才是重要的。这包括：测试支持同时用户的能力，对性能的监控并设定可以用来量测级别的基准。
对负载测试量度很重要的一个理念就是虚拟用户。虚拟用户是在应用软件上模拟活动的测试工具用户。取决于你的负载工具和脚本设置，对虚拟用户和实际用户设定一个等值并不总是很容易的。而且在一个模拟中，100个虚拟用户可能会执行一个100个真实用户不可以或不可能执行的活动。
一些工具可以让你设置一个延迟时间来代表一个用户在点击或创建一个变换屏幕的事件之前，用户在每一个屏上所花的时间。或者，你可以不要任何延迟地执行脚本来代表可以比一组精神百倍的程序员更快地进行处理工作的超级用户。
稳定化并准备环境
你要确定你在执行负载测试时，处于一个运行环境，硬件和软件属性在测试期间都不会改变的标准之下。设置执行标准要求对产生数字的因素进行控制，他使得变换控制处理更加地重要。
除了对变换的控制，你必须确定运行环境对要负载内容做好了准备。这似乎是很显然的，但负载测试即使是在正常情况下也可能达到预期之外的容量。对于我们来说，这意味着对互联网更高带宽的使用，超过规划容量的活动登陆到我们的数据库。所有负责应用软件部件的人都应注意在测试中产生的负载容量。
从所有的开发组收集所有权
负载测试，作为一个在不同的商业领域中实现的独立任务的整合性的测试，将要求来自各个方面的合作来确定问题所在。你还需要有一些政治头脑来保证各个方面不会产生指责，对其他小组产生敌意，或是更糟的，根本对负载测试不予理睬。
应用软件在建构时，商业活动的每一个方面都将在完成其独立任务的问题上得到关注，这里面有诸如编码商业逻辑，设计HTML和XSLT或是建构防火墙和其他验证部件等的网络基础架构等方面的内容。要保持测试的进行，每一部分都要有做调试和实现变换工作的代表。如果这些部分中的一个不遵守它的职责，测试就是停止或是失败。
对反复测试处理的准备
在某种程度上说，你永远不可能完成负载测试。由于互联网应用软件和硬件的动态特性，许多因素不可避免的会导致性能的不断的变换。在负载测试规划的早期，逐步地确定测试可以进行重复且基准被记录，因而你可以把结果与先前的测试结果进行对比。
你还需要在测试失败时定义程序或是策略。计划包括问题是如何升级的，如何解决的，如何与用户沟通的。他还要包括一旦瓶颈问题得到解决时用来停止测试并恢复的可能性。在负载测试初期的基础工作将使团队获得不断的成功。