负载测试应该是每项 Web 开发工作的一部分，并且应在开发过程的早期进行。然而，如果您认为可以利用开发环境进行负载测试，那么当您发布应用程序时多少会感到惊讶。在本文中，作者将对规划负载测试工作、考虑使用哪些计算机、模拟用户的数量、适用的工具以及如何解释结果这一过程进行概述。

　　让我们设想以下场景。您即将结束为期 6 个月的对某项复杂的 Internet 应用程序或 Web 服务的开发工作，并且已准备对其进行部署。开发团队小心翼翼地就松散耦合的n层 Web 应用程序进行了设计。从工作的第一天开始，所有可伸缩、稳定的和高性能的应用程序所必需的要素就已悉数构建到系统的体系结构之中。质量保证团队已对系统进行了彻底地测试、解决掉了大部分的严重错误并仔细考虑了那些待发现的剩余错误。因此，您的开发工作应该进行得相当顺利，对吗？请再想一下。

　　您已将负载测试作为开发工作的一部分进行实施了吗？如果没有，那么您应接受这样的事实：即，在复杂的设计当中，您将需要就某些地方的性能、可伸缩性和可靠性方面予以关注。瓶颈是系统中阻碍正常通信量流量的元素。尽管良好的设计对于构建成功的 Web 应用程序而言至关重要，但是经验告诉我们，大部分这些种类的错误只能在系统处于较大负载的情况下才会被发现。这些是您作为单个用户在开发过程期间，通过测试系统无法发现的问题。尽早地实施负载测试计划有助于确保将在开发时出现的意外情况降至最低限度。

　　在本文中，我们将介绍基于实际经验的测试方法，但这并非抛开传统的负载测试策略。由于带领过众多的负载测试团队，我们汲取了一些教训，它们可能会对您有所帮助。

　　我们将讨论较早开始测试工作的优点，并概述设置测试环境的注意事项。我们将帮助您确定适于自己的实现的度量标准，并介绍一些实施这些度量标准的工具。此外，我们将向您说明，为什么“我的站点能同时处理x名用户吗？”这样的问题太过含糊而无法精确回答。最后，我们将讨论一些针对您的特定需要选择适当的负载测试工具的重要注意事项，并对跟踪测试结果提出一些建议。

　　我们将使用术语“负载测试”来描述性能、可伸缩性和可靠性测试。人们往往过于频繁地使用术语“可伸缩性测试”来描述上述这三项，而您的团队所做的很可能不仅限于此。图 1描述了这些目标。

　　尽早开始

　　您应在设计阶段就开始规划负载测试工作。根据我们的经验，建议您采取“无惊讶”方法来进行开发工作。工作时始终抱着会发现问题的想法。分布式 Web 应用程序和 Web 服务的体系结构日趋复杂，使得潜在问题成为应用程序设计中的固有现象。

　　最近，我们在复杂的n层 Web 体系结构的开发阶段中，进行的负载测试效果不错。但我们对其中的两个问题估计不足。第一，我们低估了测试开始后将会发现的问题数量。我们的第一次测试运行在只处理了 2 名用户和 100 份定单后就告失败了。第二，我们低估了设置测试环境所需要的时间。幸运的是，由于我们开始规划测试足够早，从而有时间解决在部署日期之前发现的问题，或将问题降到最少。通过密切关注设计，成功地解决最初的几个问题后，系统的可伸缩性很快就得到了提高。

　　通过定义测试环境，您就可以开始规划测试工作。根据测试工作的规模，这可能是很重要的任务。

　　定义环境

　　在定义测试环境的过程中，第一个任务就是估计需要何种工作。我们用于资源成本的一条通用指南是，将实现时间的 15% 至 20% 用于测试，其中的大约三分之一用于负载测试。

　　重要的是创建单独的测试环境，该环境应与生产环境类似。如果计算机的配置、速度和设置均不相同，那么要推断出生产环境中的性能几乎是不可能。换言之，对于诸如“向系统添加更多硬件是否能提高可伸缩性”这样的问题，您能给出确定回答，但是对于“在生产环境中一台 Web 服务器能处理多少用户？”之类的问题，您却无法准确回答。您的主要任务之一就是降低不确定性，并通过结论性的证据来回答问题。如果没有类似的硬件，在迫不得已的情况下，您充其量也只能根据经验进行猜测。

　　面对将生产用计算机用于负载测试环境的成本，您可能会畏缩不前。但请您考虑考虑在生产环境中查找与硬件相关的问题所需的成本，以及精确预测单台 Web 服务器能处理的负载的价值。诸如处理器速度和可用的 RAM 之类的变量会影响可用系统资源，并随之可能更改可伸缩性问题表明它们自身的方式。在实验室中，环境变量是不可抗拒的因素。该种变量数量太多，而您无法确定问题的根源。如果不可能使用单独的环境，那么请考虑加速生产硬件购买以用于负载测试实验室中。一旦部署了系统，实验室设备就还可以用作生产设备的备用品。另一个好处是，用不着等到发布之日前，您就能消除系统缺陷。

　　关于为何您不应使用开发环境进行测试，有几点原因。有关详细信息，请参阅提要栏“Dont Use Your Dev Environment for Load Testing”。对于质量保证团队所使用的系统测试环境，情况亦是如此。这适用于想要跟踪似乎与系统负载无关的功能错误的单个用户测试。这种测试对系统测试环境中使用的硬件类型放宽了限制。它从开发团队接收的软件更新也更频繁。在负载测试中，应只安装影响系统性能的版本，以将修改负载脚本的耗时缩至最短。

　　除了可伸缩性实验室运转所必需的资源以外，负载测试工作是否能成功还取决于组织中的其他角色。

　　实验室以外最重要的角色是具有很大权限的数据库管理员 (DBA)，这个事实无需我们过分强调。可伸缩性问题最可能的根源就在于数据库、数据访问策略（例如，存储过程、预处理语句或内联 SQL）或数据访问技术（例如，ADO、ODBC 等等）。DBA 能够帮助识别和解决与数据库相关的问题，例如建立索引成本过高、过度锁定以及事务超时。理想情况是，您应有一位专门的称职的 DBA 来作为负载测试工作中关键点的全职资源。

　　我们还建议您让开发团队中的成员轮流负责测试实验室，以便每名团队成员都能参与到这项测试工作中。如果这样做，您将取得极佳的交叉培训的效果，并持续地向实验室提供最新的理念。