大家好，我是阿萨。
当任何软件开发项目接近完成时，它可能已经通过了大量的测试，特别是在测试和开发同时进行的敏捷测试环境中。但是无论您运行了多少测试，一旦您的应用程序接近完成，实际上只有一种方法可以知道您的软件是否能够处理大量最终用户的实际需求。它被称为负载测试，您可以使用像负载测试工具这样的工具来完成这项工作。负载测试是对软件、应用程序或网站施加模拟需求的过程，以测试或演示其在各种条件下的行为。
什么是负载测试?
负载测试是关于在应用程序或系统中创建生产模拟环境，使其尽可能接近于准备部署的最终环境。通过使用专门的测试软件，负载测试允许开发团队回答诸如“我的系统在这些条件下是否达到了我的预期?”以及“它的性能足够好吗?”正如微软的Web应用程序性能测试指南所述:
负载测试使您能够测量响应时间、吞吐量率和资源利用水平，并确定应用程序的断点(假设断点发生在峰值负载条件之下)。
在这里，“低于峰值负载条件”只是再次表明，一种测试方法属于负载测试的参数，而不是压力测试(根据定义，压力测试是在峰值负载下或超过峰值负载时测试系统)。负载测试可以识别系统延迟、页面负载问题，以及当多个用户访问应用程序或突然使用流量轰炸系统时可能出错的任何其他问题——在开发和测试环境中，这些问题很容易被忽略，因为在开发和测试环境中，代码通常是针对单个用户进行检查的。然而，当成百上千的人试图同时访问软件或发出命令时，那些在单独用例中可能没有被检测到的问题就会突然暴露出来。
为什么负载测试很重要?
负载测试确保您的应用程序可以在生产中按预期执行。仅仅因为您的应用程序将通过功能测试，这并不意味着它可以在负载下执行相同的测试。负载测试可以确定应用程序在何时何地出现故障，因此您可以在发布到生产环境之前修复问题。
企业和消费者严重依赖数字应用程序来实现关键功能，因此验证数字应用程序能够承受实际负载场景非常重要。随着数字应用程序的采用越来越多，对质量的期望也越来越高，如果应用程序在生产中失败，成本就会变得很高。根据Gartner的数据，网络停机的平均成本约为每分钟5600美元。平均每小时30万美元左右。避免生产中的停机是必不可少的，负载测试有助于确保您的应用程序为生产做好了准备。
负载测试工具(以及一般的性能测试工具)的最终目的始终是降低风险，无论是对软件成功功能的风险、对最终用户理智的风险，还是对公司底线的风险。当然，这三者紧密地交织在一起，所以了解它们之间的关系以及您作为开发人员或测试人员可以在哪些方面进行干预是很重要的。让我们大胆地建议，如果您专注于减轻中间标准，用户完整性，其他两个因素通常会得到解决，许多负载测试问题实际上归根结底更多地取决于用户的感知，而不是特定的理想页面加载时间和其他技术统计。
负载测试与压力测试
作为最著名和最常进行的性能测试类型，负载测试涉及对软件应用程序或IT系统施加普通压力，以查看它是否能在正常条件下按预期执行。它与更大、更残酷的“兄弟”压力测试有关，但负载测试确保给定的函数、程序或系统能够简单地处理其设计要处理的内容，而压力测试则是关于使事物超载，直到它们崩溃，应用不现实或不太可能的负载场景。
这两种实践都可以在确定给定的前端软件(如网站)或后端系统(如托管该网站的Apache服务器)在处理日常使用中可能遇到的实际负载方面发挥重要作用。压力测试故意诱导失败，这样您就可以分析崩溃点所涉及的风险，然后，也许可以选择调整程序，使它们更优雅地崩溃。压力测试有助于为意外情况做准备，并准确确定给定系统可以扩展到什么程度，探索性能能力的外部极限。但是，当涉及到简单地确保软件应用程序或物理网络能够承受在正常情况下可能遇到的用户请求和操作时，负载测试是完成该任务的正确方法。
如何开始负载测试
开始负载测试并不像过去那样困难。在过去，学习加载测试——创建一个真实的场景、编写测试脚本、重做测试和分析测试结果——需要大量的技能和时间。另外，每个负载测试工具都是不同的。因此，学习如何使用每个工具使测试运行按照您的意愿运行始终是一个挑战。
收集需求——你需要测试的最关键的功能是什么?是什么塑造了你的最终用户体验?
规划相关用户业务场景——确定用户如何与应用程序交互。这是利用来自您可能使用的任何APM工具的监视数据的绝佳机会。
建立基线—运行测试，为您的应用程序建立坚实的基线，以便进行测试。每当性能偏离这个基准时，您就会知道有必要深入研究测试数据。
自动化和集成——将负载测试作为CI/CD流程的一部分进行优先级排序，并与您已经使用的工具集成。
这些步骤将为开始应用程序的负载测试奠定良好的基础。
负载测试最佳实践
创造真实的场景
像用户一样思考。对你的用户群来说，什么是重要的?应用程序的哪些功能对他们至关重要?他们使用不同的设备吗?通过创建真实的负载测试，您可以更深入地了解应用程序的行为方式，或者应用程序在实际用户的生产环境中的行为方式。真正的用户在一定程度上是不可预测的，所以在评估测试中要采取的步骤时，要记住随机性和可变性。混合使用设备和浏览器类型，这样您就可以确信应用程序已经为部署做好了准备。
尽早测试，经常测试
无论您的团队采用敏捷、devops还是左移思维，尽早测试和经常测试都是必要的。性能测试通常是孤立的，在开发项目结束时才开始。然而，在过去的几年里，在软件开发生命周期中增加反馈的数量已经被证明在快速发现和修复问题方面非常有价值。优先考虑将性能测试，特别是负载测试作为敏捷、持续集成和自动化实践的一部分。
设定真实的基准
优化性能需要深入了解应用程序及其用户。确定能够反映现实情况的实用和现实的测试，无论这意味着选择设备、浏览器、用户数量等。另外，负载测试不能从零开始。在现实世界中，您希望更新的系统不太可能已经在负载下运行。因此，与其从零开始，慢慢地增加虚拟用户，直到达到所需的负载，不如尝试在系统已经处于负载之下之后运行测试。通过这种方式，您可以避免从零开始负载测试可能产生的“假阳性”。
利用真实生活数据
要实现现实的基准测试和场景，可以利用现有的数据。重用来自监视工具的数据有助于阐明在特定情况下“现实”的含义。在大多数情况下，监视工具是从主动和被动的角度运行的——这意味着您可以使用合成的和真实的用户数据来映射在生产中使用合成监视器失败的场景和/或将用户已经与应用程序进行的交互添加到您的测试场景中。这可以包括用户驱动的数据，比如浏览器、设备、用户路径、传输点，以及基于系统的数据，比如DOM加载、到第一个字节的时间等等。
分析测试数据以发现潜在问题
运行负载测试后，第一个明显的步骤是确定任何问题区域，并采取下一步最佳步骤来提高该组件的性能。这意味着将性能瓶颈与代码联系起来，以隔离问题的根本原因。通常情况下，如果你使用传统的测试工具，这可能会很困难，因为它需要将测试结果“转换”为你可以与开发团队分享(或使用自己)的指标，以更深入地挖掘引发问题的核心代码。如果你使用的是LoadNinja，这一步是没有问题的，因为你的负载测试结果是基于浏览器的指标，你可以实时检查和调试。
如何为您的组织选择最佳的负载测试方法
选择负载测试工具
找到一个可以支持您的团队的工具是至关重要的。我们知道，性能测试实践在发布周期中可能会花费一些时间，但它们通常是生产中成功的指标。通过性能测试，您可以了解应用程序在部署之前将如何在生产环境中执行，从而可以在正式发布之前发现并修复问题。测试可以揭示你的网站在负载下的性能是否不同，你的代码更改是否有意想不到的变化，并通过在问题变成昂贵的生产问题之前发现问题，从长远来看可以节省资金。在评估负载测试工具时，请务必牢记以下因素:
易用性——创建复杂、真实的负载测试是否容易?
准确性-它能在真正的浏览器中运行吗?
可伸缩性——你能增加或减少使用/用例、用户、实例吗?
集成——你能与你每天使用的工具集成吗?
了解什么工具最适合你的工作流程是至关重要的。
