介绍
任何软件开发项目接近完成的时候，它可能已经通过无数次测试了，特别是在测试和开发同时发生的敏捷测试环境下。无论你已经进行过多少轮测试，一旦你的应用程序已接近完成，那么只有一个办法知道你的软件是否可以满足真实用户群的实际需求，它就是负载测试。你可以使用负载测试工具来完成这项工作。负载测试是指给软件、应用程序或网站加上模拟的需求，以测试其在不同的环境下的运行状态的过程。
负载测试和性能测试
作为大家最了解且最常见的一种性能测试类型，负载测试即包括将常规压力施加到软件应用或 IT 系统，去看它们是否在正常条件下可以按照预期执行。相对于施压更大，更残酷的压力测试，负载测试确保了在给定参数范围内，程序或系统不超过其预期设计的处理能力，而压力测试是有关超载的事情，直到系统崩溃，应用不能运行或不太可能出现的负载场景。这两种测试方法在验证给定的前端软件如一个网站、后端系统如托管该网站的Apache 服务器是否能够很好的处理真实负载起着重要的作用。压力测试故意诱导失败，这样你就可以分析所涉及的突破点的风险，然后，也许你会选择调整方案，使它们更优雅地被打破。压力测试对于应对突发情况做准备，以及确定给定系统性能承载能力上限是很有价值的。但是，当涉及到简单地确保软件应用程序或物理网络在一般情况下可以承载用户请求和操作，负载测试是完成任务的正确方法。
当然，应该指出的是，如果你的应用程序没有做好预期，那么这意味着发布前的负载测试，在它发布后将变成一次压力测试。阅读我们的负载测试最佳实践来避免这些常见陷阱。一旦负载启动引发崩溃，从那一刻起，根据定义，就变成了压力测试。这是负载测试和压力测试经常被混淆的主要原因，因为完全相同的测试在某些情况下可能会从负载测试变成压力测试。
了解负载测试
负载测试是为一个应用或系统尽可能地接近成品部署并在用户群中创建的模拟环境。通过利用专业的测试软件，负载测试可以让开发团队来回答这样的问题“我的系统在这些环境下按照预期运行了吗？”，“它的性能足够好吗？”正如微软应用性能测试指南所说：一个负载测试可以测量响应时间，吞吐率和资源利用率，并确定应用程序的性能瓶颈，假设性能瓶颈的出现低于负载峰值。
在这里，“低于负载峰值”再次简单地表明，负载测试的参数落在压力测试（根据定义，指测试系统在或超出最大负载时的运行状况）范围内。负载测试可以发现系统延时，页面加载问题，以及当多个用户访问一个应用程序或高并发致使系统崩溃，这类问题在开发和测试环境中容易被忽视即便代码已经检查了很多遍。成百上千人同时访问软件时，一些探测不到的问题可能会突然出现。
举例来说，假设你正在开发一个新的在线投票平台，并且希望它在负载高峰时段能承受每分钟10,000次用户提交请求。在开发软件时，写代码阶段你可能就执行了单元测试，周期性回归测试，以确保在新功能开发进程中没有破坏已有的功能。但你在什么时候开始做大规模用户测试？什么时候你开始测试程序接受成百上千的重叠字段项，表单提交和其他命令？
从技术角度讲，在一个项目生产的末期，才会进行有真实用户参与的能够精确模拟系统性能的负载测试。这与汽车生产类似：你可以修复和测试引擎，但如果引擎没有安装，则不能测试汽车在道路上的表现。其实，在软件开发项目中的早期，你就能以一个集中的方式来测试特定组件的负载，例如测试后端性能问题，同时用户输入，在延长的时间周期里输入的耐力，或其他任何可以给系统施压，造成延时，内存泄漏或功能崩溃的方式。那就意味着你已经进行了负载测试，只不过是以一种受限的形式，并且已经在探索多用户访问对系统的影响了。在一个不完整的系统上进行少数用户输入测试，性能测试专家 Scott Barber ，上述微软资源的合著者之一，更愿意称其为“多用户功能测试。”再次强调，正确的负载测试需要一个几乎完整的系统，并且通常要求使用可以真实模拟数千用户的测试软件。
但有一个对所有规则的例外。对互联网应用而言有一个很明确的多用户问题，从智能电话的 GPS 应用，到在线多人视频游戏，负载测试可以在系统上进行，而不必通过众多用户，因为多个用户不是负载的唯一可能来源。有时负载可能是由大文件，大量的计算，甚至是弱网连接造成的。想想在 Acrobat 中打开 PDF ，或在 Photoshop 中打开一个 PSD 。系统遇到压力时负载便产生。执行打开文件的速度够快吗？如果文件过大，会使应用程序崩溃吗？你用什么标准来判断你的应用打开文件的“速度够快”？能打开文件是可以接受的，但如果需要5分钟呢？谁制定了系统的理想承载能力的标准，又依据什么呢？负载测试人员绘制的用户的主观偏好和系统的目标功能之间的界限又在哪里呢？
要成为一个优秀的负载测试人员并能分析负载测试结果，往往还需要具备超过软件工程和测试专业知识的东西，要深谙用户体验。
**负载测试的未来：了解用户的真实想法
负载测试工具和性能测试工具的最终目的一般总是为了降低风险**，无论是对于软件成功功能的风险，最终用户感知的风险，或对公司底线的风险。当然，所有这三个是紧密交织在一起，所以，对于一个开发人员或测试人员知道它们是如何相互关联的是很重要的。要敢于提出建议，如果你专注于减少中间标准，那么用户感知和其他两个因素通常会水到渠成。许多负载测试的问题归根结底，更多的在于用户感知，而非具体理想的页面加载时间和其他技术统计数据。
实际上，虽然反复进行负载测试通常需要专门的软件，但由于人为复杂因素的存在，数据解读并不会像看起来那么简单。例如，如果有人来到一个只加载文本的网站，那么用户期待它立即加载，即便是一两秒钟的加载时间也是很难容忍的，但如果他们期望加载嵌入的视频，那么用户对响应时间将更宽容。宽带时代的到来，我们已经逐渐习惯接收这些。随着心理学对用户体验要素更深入的探索，发现了很多微妙的细节，实际上人们更倾向于网站内访问速度均匀一致的缓慢，例如，整体加载速度较快，但有内部速度不一致的心理。因此，没有这种心理层面的认知，真正了解用户的愿望和期望，再多的负载测试数据也不会以最大的感知效果来自动帮你改进软件。
换句话说，如果你不理解人类的心理、用户的行为和反应，你就不可能实现一个很真实的负载测试，并且更糟的是，你可能会误解测试结果。这就是为什么在执行负载测试时尽可能地模拟真实的终端用户体验很重要的原因，重复模拟用户在接近最大负载时访问一个网站或应用程序，分析测试结果，然后对系统进行相应的，尽最大可能来减少用户体验中的不愉快因素。由于开发周期越来越短，软件公司可以通过简单地专注于特定的故障以使用户体验更平稳和高效，而不是解决高负载情况下遇到的所有问题，这样可以节省时间和金钱。
本文由 OneAPM 张宇编译自 SMARTBEAR 网站的文章《 What is LOAD TESTING ?》
本文转自 OneAPM 官方博客
原文链接：https://smartbear.com/learn/performance-testing/what-is-load-testing/