介绍
任何软件开发项目接近完成的时候,它可能已经经过无数次测试了,特别是在测试和开发同时发生的敏捷测试环境下。不管你已经进行过多少轮测试,一旦你的应用程序已接近完成,那么只有一个办法知道你的软件是否能够知足真实用户群的实际需求,它就是负载测试。你可使用负载测试工具来完成这项工做。负载测试是指给软件、应用程序或网站加上模拟的需求,以测试其在不一样的环境下的运行状态的过程。html
负载测试和性能测试
做为你们最了解且最多见的一种性能测试类型,负载测试即包括将常规压力施加到软件应用或 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/