没有什么事情比这更糟了，采纳一个新的应用程序，而它的性能是如此的糟糕，导致业务在一片惊叫声中暂停。这并不是新出现的现象；这就是事实，我经常遇到这样的事实。我打赌你也曾经经历过。那么如何防止这些性能问题，有什么解决方案？
在这些应用程序“在惊叫声中暂停”的情况中，应用程序通常都已经在按照功能性分配的短暂的测试时间内进行过适当的测试了。但是充分吗？由于竞争和全球经济的原因，迅速应用于业务意味着只进行了最小化的测试。同样，最小化的测试也成为按时将应用程序发布给用户群体的可接受的风险之一。另一点需要注意的是，负载测试太贵了，所以修正产品问题的成本也是也通常是比较小的――至少在发布应用程序的时候它不会妨碍进展和创新性，对不对？
不幸的是，我具有相反的经历：企业为运行得极其糟糕的应用程序所付出的有形的和无形的代价超过了采用可靠的负载测试方法在人力、程序，以及技术上面的投资。因此，我愿意提供以下对你的应用程序进行负载测试的清单，它将会成为防止你的SQL Server性能调整问题的魔法弹。
清单：负载测试――SQL Server性能调整的魔法棒
项目管理
平衡项目管理方法学，确保项目按照一个确定的过程进行，尽量减少或者避免遗漏步骤，包括对每个版本的应用程序进行负载测试。
管理层的支持
在负载测试的需求和收益的基础上与IT经理们合作。获得他们对正确分配时间为每个应用程序进行负载测试的支持。
性能需求
了解系统应该支持的用户、事务、数据集和可接收的处理时间等信息。如果这些信息没法确定，与企业进行沟通，了解在现有的硬件和软件基础上，应用程序的生命周期中能够支持多少用户。
用户期望
确定用户和业务期望――为了保证应用程序正确运行，需要进行功能性和负载的测试。
任务时间表
按照你的团队具有的严格意义上的资源，计算完成这些负载测试和代码检查任务所需的时间，在你的项目计划中，为其安排充分的时间。
负载测试工具
对你要用来进行负载测试的工具进行标准化。以下是一个简短的列表，如果你对产品不熟悉的话。点击每一条都会进入该工具的说明页。
WebLOAD (负载测试)
Web 性能测试工具
QuotiumPRO
Empirix e-Load
Quest Benchmark Factory for Databases
Mercury LoadRunner
Knowledgestorm
Scandiasoft DbValidator
WAPT 3.0
OpenLoad
负载测试过程
将你的应用程序负载测试过程标准化，建立文档模板，对测试过程的流线进行编码，同时记录应用程序涉及的结果。考虑在软件版本的基础上采用迭代的方式。
代码检查
所有的代码都会让开发人员和数据库管理员进行测试，以确认明显的功能，但是还要安排第二个人来进行测试。如果你没有预算请一位全职或者兼职的测试人员的话，那么可以考虑让开发团队互相检查。如果你有测试人员的预算，那么就让你的团队一起来为应用程序增加负载吧。
将负载测试过程流水线化
当应用程序发布为产品时确定一些对系统性能起作用的因素，然后将其用在每一次的应用程序发布版本上。
需要进行负载测试的时候进行负载测试
虽然对每个应用程序都进行负载测试是很好的，但是成本通常是有限的。因此，从那些出现过性能问题的单个应用程序开始，并且从这个应用程序中吸取教训。将知识扩展开来，在你的企业中创建一个最好的实践指南，以此在应用程序的开发阶段防止性能问题的出现，这也会负载测试过程流水线化。
通过各种方式，避免将性能问题引入产品环境中。实际情况是，不能每个场景都经过测试，但是可以定位你的应用程序中的核心内容，并且随着你的经验积累而日益提高。考虑将上面的清单作为进行负载测试的开始点，并且与你的团队讨论一下什么选项可以获得高性能。你在负载测试方面有什么经验？告诉我，然后调整状态，准备阅读下一部分的SQL Server性能调整贴士，我们将会提供更多本领域的观察报告，并且简单推荐可能改善整体系统性能的方法。
