面向初学者的完整负载测试指南：
在本教程中，我们将学习为什么要进行负载测试，测试的结果是什么，架构，成功执行负载测试的方法是什么，如何建立一个负载测试环境，最佳实践，以及市场上最好的负载测试工具。
我们听说过功能测试和非功能测试两种类型。 在非功能测试中，我们有不同类型的测试，如性能测试、安全测试、用户界面测试等。
因此，负载测试是一种非功能类型的测试，是性能测试的一个子集。
因此，当我们说我们正在测试一个应用程序的性能时，我们在这里测试的是什么呢？ 我们正在测试应用程序的负载、数量、容量、压力等。
什么是负载测试？
负载测试是性能测试的一个子集，我们通过模拟多个用户同时访问应用程序，测试系统在不同负载条件下的响应。 这种测试通常测量应用程序的速度和容量。
因此，每当我们修改负载时，我们就会监测系统在各种条件下的行为。
例子 : 假设我们的客户对登录页面的要求是2-5秒，而且这个2-5秒在整个过程中应该是一致的，直到负载达到5000个用户。 那么我们应该观察到什么呢？ 这只是系统的负载处理能力，还是只是响应时间要求？
答案是两者都有。 我们希望系统能够处理5000个用户的负载，所有并发用户的响应时间为2-5秒。
那么，什么叫并发用户和虚拟用户呢？
并发用户是指那些登录到应用程序并同时进行一系列活动并同时注销应用程序的用户。 另一方面，虚拟用户只是跳入和跳出系统，不考虑其他用户的活动。
负载测试架构
在下图中，我们可以看到不同的用户是如何访问应用程序的。 在这里，每个用户都是通过互联网发出请求，然后通过防火墙。
在防火墙之后，我们有一个负载平衡器，它将负载分配给任何一个网络服务器，然后传递给应用服务器，随后传递给数据库服务器，在那里它根据用户的请求获取必要的信息。
负载测试可以手动完成，也可以使用工具。 但不建议进行手动负载测试，因为我们不会在较小的负载下测试应用程序。
例子：假设我们想测试一个在线购物应用程序，看看每个用户点击的响应时间，即步骤1 -启动URL，响应时间，登录到应用程序并注意响应时间，等等，如选择产品，添加到购物车，付款和注销。 所有这些必须为10个用户完成。
所以，现在当我们需要测试10个用户的应用程序的负载时，我们可以通过手动将10个来自不同机器的物理用户的负载来实现，而不是使用一个工具。 在这种情况下，最好是进行手动负载测试，而不是投资于一个工具并为该工具建立一个环境。
而想象一下，如果我们需要对1500个用户进行负载测试，那么我们就需要根据应用程序的技术和我们的项目预算，使用任何可用的工具来自动进行负载测试。
如果我们有预算，那么我们可以选择商业工具，如Load runner，但如果我们没有太多的预算，那么我们可以选择开源工具，如JMeter等。
无论是商业工具还是开源工具，在我们最终确定工具之前，都必须与客户分享细节。 通常，我们会准备一个概念证明，即使用该工具生成一个样本脚本，并在最终确定工具之前向客户展示样本报告，供其批准。
在自动化负载测试中，我们在自动化工具的帮助下取代用户，模拟用户的实时操作。 通过自动化负载，我们可以节省资源和时间。
以下是描述用户如何使用工具被替换的图表。
为什么要进行负载测试？
让我们假设有一个在线购物网站，在正常的工作日里做得很好，即用户能够登录到应用程序，浏览不同的产品类别，选择产品，将物品添加到购物车，在可接受的范围内结账和注销，没有页面错误或巨大的响应时间。
同时，有一个高峰日，比如说感恩节，有成千上万的用户登录到系统中，系统突然崩溃，用户的反应非常慢，有些人甚至无法登录到网站，一些人无法添加到购物车，有些人无法结账。
因此，在这个大日子里，该公司不得不面临巨大的损失，因为它失去了许多客户和许多业务。 所有这一切的发生只是因为他们没有预测高峰期的用户负载，即使他们会预测，也没有对公司网站进行负载测试，因此他们不知道应用程序在高峰期能够处理多少负载。
因此，为了处理这种情况，为了克服巨大的收入，建议对这种类型的应用程序进行负载测试。
- 负载测试有助于建立强大和可靠的系统。
- 在应用程序上线之前，系统中的瓶颈已被提前确定。
- 它有助于确定应用程序的能力。
负载测试期间会实现什么？
通过适当的负载测试，我们可以对以下情况有一个确切的了解：
- 系统能够处理或能够扩展的用户数量。
- 每个交易的响应时间。
- 整个系统的每个组件在负载下是如何表现的，如应用服务器组件、网络服务器组件、数据库组件等。
- 什么样的服务器配置最适合处理负载？
- 现有的硬件是否足够，或者是否需要额外的硬件。
- 像CPU利用率、内存使用量、网络延迟等瓶颈被确定。
环境
我们需要一个专门的负载测试环境来进行测试。 因为大多数时候，负载测试环境将与生产环境相同，而且负载测试环境中的数据也将与生产环境相同，尽管它不是相同的数据。
会有多个测试环境，如SIT环境、QA环境等，这些环境与生产环境不同，因为与负载测试不同，他们不需要那么多服务器或那么多测试数据来进行功能测试或集成测试。
例子：
在生产环境中，我们有3个应用服务器、2个网络服务器和2个数据库服务器。 在QA中，我们只有1个应用服务器、1个网络服务器和1个数据库服务器。 因此，如果我们在QA环境中进行负载测试，而QA环境不等于生产环境，那么我们的测试是无效的，也是不正确的，因此我们不能根据这些结果。
因此，总是尝试有一个专门的环境进行负载测试，与生产环境类似。
此外，有时我们的系统会调用第三方应用程序，因此在这种情况下，我们可以使用存根，因为我们不能总是与第三方供应商合作进行数据更新或任何其他问题或支持。
一旦环境准备好了，就试着拍一个快照，这样，每当你想重建环境时，就可以使用这个快照，这将有助于时间管理。 市场上有一些工具可以用来设置环境，如Puppet、Docker等等。
办法
在开始负载测试之前，我们需要了解是否已经在系统上做过任何负载测试。 如果以前做过任何负载测试，那么我们需要知道响应时间是多少，收集的客户和服务器指标是多少，用户负载能力是多少等等。
此外，我们还需要了解当前应用的处理能力如何。 如果是新的应用，我们需要了解需求，目标负载是什么，预期响应时间是什么，是否真的可以实现。
如果是一个现有的应用程序，你可以从服务器日志中获得负载要求和用户访问模式。 但如果是一个新的应用程序，那么你需要联系业务团队以获得所有信息。
一旦我们有了需求，我们就需要确定我们将如何执行负载测试。 是手动完成还是使用工具？ 手动完成负载测试需要大量的资源，也非常昂贵。 同时，重复测试，一次又一次，也会很艰难。
因此，为了克服这个问题，我们可以使用开源工具或商业工具。 开源工具是免费的，这些工具可能不具备其他商业工具的所有功能，但如果项目有预算限制，那么我们可以选择开源工具。
而商业工具有许多功能，它们支持许多协议，而且非常方便用户使用。
我们的负载测试方法将如下：
#1）确定负载测试的验收标准
例如 ：
- 即使在最大负载条件下，登录页面的响应时间也不应超过5秒。
- CPU利用率不应超过80%。
- 系统的吞吐量应该是每秒钟100个交易。
#2）确定需要测试的业务场景。
不要测试所有的流程，尝试了解预计在生产中会发生的主要业务流。 如果是现有的应用程序，我们可以从生产环境的服务器日志中获得他的信息。
如果它是一个新建立的应用程序，那么我们需要与业务团队合作，以了解流程模式、应用程序的使用等。有时，项目团队会举行研讨会，以概述或详细介绍应用程序的每个组件。
我们需要参加应用研讨会，并注意所有需要的信息，以进行我们的负载测试。
#3）工作负荷模型
一旦我们掌握了关于业务流、用户访问模式和用户数量的细节，我们就需要以这样的方式来设计工作负载，即模仿生产中的实际用户导航，或者在未来应用进入生产后的预期。
在设计工作负荷模型时，需要记住的关键点是看一个特定的业务流程需要多少时间才能完成。 在这里，我们需要以这样的方式分配思考时间，即用户将以更现实的方式浏览整个应用程序。
工作负荷模式通常是上升、下降和稳定状态。 我们应该慢慢地给系统加载，因此使用上升和下降。 稳定状态通常是一小时的负荷测试，上升15分钟，下降15分钟。
让我们举一个工作负荷模型的例子：
应用程序的概述 - 让我们假设一个在线购物，用户将登录到应用程序，有各种各样的衣服可供选购，他们可以在每个产品上进行导航。
如果他们喜欢该产品的成本和制造，那么他们可以添加到购物车，通过结账和付款来购买该产品。
下面列出了一些情况：
- 浏览 - 在这里，用户启动应用程序，登录到应用程序，浏览不同的类别并退出应用程序。
- 浏览, 产品查看, 添加到购物车 - 在这里，用户登录到应用程序，浏览不同的类别，查看产品细节，将产品添加到购物车并退出。
- 浏览、产品查看、添加到购物车和结账 - 在这种情况下，用户登录到应用程序，浏览不同的类别，查看产品细节，将产品添加到购物车，进行结账并退出。
- 浏览、查看产品、添加到购物车、结账和付款 - 在这里，用户登录到应用程序，浏览不同的类别，查看产品细节，将产品添加到购物车，进行结账，付款并退出。
| 编号 | 业务流程 | 交易数量 | 虚拟用户负载 | 响应时间（秒） | 允许的失败率百分比 | 每小时交易量 |
|---|---|---|---|---|---|---|
| 1 | 浏览 | 17 | 1600 | 3 | 低于2% | 96000 |
| 2 | 浏览, 产品查看, 添加到购物车 | 17 | 200 | 3 | 低于2% | 12000 |
| 3 | 浏览、产品查看、添加到购物车和结账 | 18 | 120 | 3 | 低于2% | 7200 |
| 4 | 浏览、查看产品、添加到购物车、结账和付款 | 20 | 80 | 3 | 低于2% | 4800 |
上述数值是根据以下计算得出的：
- 每小时交易量=用户数*单个用户在一小时内的交易量。
- 用户的数量=1600。
- 浏览情景下的交易总数=17。
- 每个交易的响应时间=3。
- 一个用户完成17个交易的总时间=17*3=51，四舍五入为60秒（1分钟）。
- 每小时的交易量=1600*60=96000笔交易。
#4）设计负载测试 - 负载测试应该根据我们目前收集到的数据来设计，即业务流、用户数量、用户模式、要收集和分析的指标。 此外，测试应该以一种非常现实的方式设计。
#5）执行负载测试 - 在我们执行负载测试之前，确保应用程序已经启动并运行。 负载测试环境已经准备好了。 应用程序的功能已经测试完毕，并且是稳定的。
检查负载测试环境的配置设置。 它应该与生产环境相同。 确保所有的测试数据都可用。 确保添加必要的计数器，以便在测试执行期间监控系统性能。
始终从低负荷开始，逐渐增加负荷。 千万不要从满负荷开始，破坏系统。
#＃6）分析负载测试结果 - 有一个基线测试，总是与其他测试运行进行比较。 在测试运行后收集指标和服务器日志，以找到瓶颈。
一些项目在测试运行期间使用应用性能监控工具来监控系统，这些APM工具有助于更容易地确定根本原因，并节省大量时间。 这些工具非常容易找到瓶颈的根本原因，因为它们有广阔的视野来确定问题的所在。
市场上的一些APM工具包括DynaTrace、Wily Introscope、App Dynamics等。
#7）报告 - 一旦测试运行完成，收集所有的指标，并将测试总结报告连同你的意见和建议发送给有关团队。
最佳实践
市场上可用的性能测试工具列表 用于进行专用负载测试。
总结
在本教程中，我们已经了解了负载测试如何在应用程序的性能测试中发挥重要作用，以及它如何帮助了解应用程序的效率和能力，等等。
我们还了解到它是如何帮助预测一个应用程序是否需要任何额外的硬件、软件或调整的。
阅读愉快