负载测试应该是每项 Web 开发工作的一部分，并且应在开发过程的早期进行。然而，如果您认为可以利用开发环境进行负载测试，那么当您发布应用程序时多少会感到惊讶。在本文中，作者将对规划负载测试工作、考虑使用哪些计算机、模拟用户的数量、适用的工具以及如何解释结果这一过程进行概述。
让我们设想以下场景。您即将结束为期 6 个月的对某项复杂的 Internet 应用程序或 Web 服务的开发工作，并且已准备对其进行部署。开发团队小心翼翼地就松散耦合的n层 Web 应用程序进行了设计。从工作的第一天开始，所有可伸缩、稳定的和高性能的应用程序所必需的要素就已悉数构建到系统的体系结构之中。质量保证团队已对系统进行了彻底地测试、解决掉了大部分的严重错误并仔细考虑了那些待发现的剩余错误。因此，您的开发工作应该进行得相当顺利，对吗?请再想一下。
您已将负载测试作为开发工作的一部分进行实施了吗?如果没有，那么您应接受这样的事实：即，在复杂的设计当中，您将需要就某些地方的性能、可伸缩性和可靠性方面予以关注。瓶颈是系统中阻碍正常通信量流量的元素。尽管良好的设计对于构建成功的 Web 应用程序而言至关重要，但是经验告诉我们，大部分这些种类的错误只能在系统处于较大负载的情况下才会被发现。这些是您作为单个用户在开发过程期间，通过测试系统无法发现的问题。尽早地实施负载测试计划有助于确保将在开发时出现的意外情况降至最低限度。
在本文中，我们将介绍基于实际经验的测试方法，但这并非抛开传统的负载测试策略。由于带领过众多的负载测试团队，我们汲取了一些教训，它们可能会对您有所帮助。
我们将讨论较早开始测试工作的优点，并概述设置测试环境的注意事项。我们将帮助您确定适于自己的实现的度量标准，并介绍一些实施这些度量标准的工具。此外，我们将向您说明，为什么“我的站点能同时处理x名用户吗?”这样的问题太过含糊而无法精确回答。最后，我们将讨论一些针对您的特定需要选择适当的负载测试工具的重要注意事项，并对跟踪测试结果提出一些建议。
我们将使用术语“负载测试”来描述性能、可伸缩性和可靠性测试。人们往往过于频繁地使用术语“可伸缩性测试”来描述上述这三项，而您的团队所做的很可能不仅限于此。图 1描述了这些目标。
尽早开始
您应在设计阶段就开始规划负载测试工作。根据我们的经验，建议您采取“无惊讶”方法来进行开发工作。工作时始终抱着会发现问题的想法。分布式 Web 应用程序和 Web 服务的体系结构日趋复杂，使得潜在问题成为应用程序设计中的固有现象。
最近，我们在复杂的n层 Web 体系结构的开发阶段中，进行的负载测试效果不错。但我们对其中的两个问题估计不足。第一，我们低估了测试开始后将会发现的问题数量。我们的第一次测试运行在只处理了 2 名用户和 100 份定单后就告失败了。第二，我们低估了设置测试环境所需要的时间。幸运的是，由于我们开始规划测试足够早，从而有时间解决在部署日期之前发现的问题，或将问题降到最少。通过密切关注设计，成功地解决最初的几个问题后，系统的可伸缩性很快就得到了提高。
通过定义测试环境，您就可以开始规划测试工作。根据测试工作的规模，这可能是很重要的任务。
定义环境
在定义测试环境的过程中，第一个任务就是估计需要何种工作。我们用于资源成本的一条通用指南是，将实现时间的 15% 至 20% 用于测试，其中的大约三分之一用于负载测试。
重要的是创建单独的测试环境，该环境应与生产环境类似。如果计算机的配置、速度和设置均不相同，那么要推断出生产环境中的性能几乎是不可能。换言之，对于诸如“向系统添加更多硬件是否能提高可伸缩性”这样的问题，您能给出确定回答，但是对于“在生产环境中一台 Web 服务器能处理多少用户?”之类的问题，您却无法准确回答。您的主要任务之一就是降低不确定性，并通过结论性的证据来回答问题。如果没有类似的硬件，在迫不得已的情况下，您充其量也只能根据经验进行猜测。
文章来源于领测软件测试网 https://www.ltesting.net/