负载压力测试是在一定约束条件下测试系统所能承受的并发用户量、运行时间、数据量，以确定系统所能承受的最大负载压力。
负载压力测试有助于确认被测系统是否能够支持性能需求，以及预期的负载增长等。负载压力测试不只是关注不同负载场景下的响应时间等指标，它也要通过测试来发现在不同负载场景下会出现的，例如速度变慢、内存泄漏等问题的原因。负载压力测试是性能测试的重要组成部分，负载压力测试包括并发性能测试、疲劳强度测试、大数据量测试等内容。一般包括如下：
1、性能测试
性能测试用来保证产品发布后系统的性能能够满足用户需求。其中系统性能包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等。
2、性能评测
性能评测包括：在真实环境下，检查系统服务等级的满足情况，评估并报告整个系统的性能；对系统的未来容量作出预测和规划。
负载压力测试结构剖析
3、性能调优
性能调优一般的步骤为首先查找形成系统瓶颈或者故障的根本原因，其次是进行性能调整和优化，最后便是评估性能调整的结果。
4、负载测试
负载测试时通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。
5、压力测试
压力测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并以此来获得系统能提供的最大服务级别的测试。
6、并发性测试
并发性测试的过程，是一个负载测试和压力测试的过程。即逐渐增加并发用户数负载，直到系统的瓶颈或者不能接收的性能点。并发性测试分为三类：
a、应用在客户端性能的测试；
b、应用在网络上性能的测试；
c、应用在服务器上性能的测试；
7、疲劳强度测试
8、大数据量测试
大数据量测试包括独立的数据量测试和综合数据量测试两类。
负载压力测试的目的：
1.在真实环境下检测系统性能，评估系统性能以及服务等级的满足情况
例如电信计费软件，众所周知，每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动。收费过程一般分为两步，首先要根据用户提出的电话号码来查询出其当月产生费用，然后收取现金并将此用户修改为已交费状态。一个看起来简单的两个步骤，当成百上千的终端同时执行这样的操作时情况就大不一样了，如此众多的交易同时发生，对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者需要模拟系统负载压力，预见软件的并发承受力，这是在测试阶段就应该解决的重要问题。
一个企业自己组织力量或委托软件公司代为开发的应用系统，在生产环境中实际使用起来以后，往往会产生这样一个问题，即这套系统能不能承受大量的并发用户同时访问，这个问题是系统负载压力需求的体现。
这里强调在真实环境下检测系统性能，在实施过程中大家认为这样做会遇到很多阻力，比如系统上线运行之后，真实环境下不允许负载压力测试为系统带来大量的垃圾数据，测试数据与真实业务数据混在一起无法控制测试结果，负载压力测试如果使服务器宕机会给系统带来巨大损失等。那么在这种条件下不允许的情况下，应该采用什么肃然措施弥补呢？我们可以使用一种“模拟环境”来做测试，这种环境是指与实际真实应用环境基本等级保持一致的测试环境。
2.预见系统负载压力承受力，在应用实际部署之前，评估系统性能。
目前的大多数公司企业需要支持成百上千名用户，各类应用环境，以及由不同供应商的元件组装起来的复杂产品。难以预知的用户负载和越来载复杂的应用程序，使公司时时担忧会发生投放性能差，用户遭受反应慢，系统失灵等问题。其结果就是导致公司收益的损失。
检测系统性能强调对系统当前性能的评估中，通过评估，可以在应用实际部署之前，预见系统负载压力承受力。这种测试的意义在于指导系统总体设计，既可以避免浪费不必要的人力、物力和财力，又避免硬件和软件的设计不匹配，使系统具有更长、更健壮的生命力。
如何确定系统的“负载压力承受力”是一个非常复杂且关键的问题。
对于系统性能检测，有时我们所从事的工作仅仅是被动监控一些性能指标，而预见系统负载压力承受力，则不可避免地会借助自动化的负载压力测试工具。
3.分析系统瓶颈、优化系统
系统性能检测和预见为分析系统瓶颈和优化提供了原始数据，打好了基础。
系统瓶颈即应用系统中导致系统性能大幅下降的原因。
瓶颈大大降低了系统性能，一般情况下，发现瓶颈并找出原因并不是件容易的事。很多时候你可能无法准确定位系统瓶颈之所在。瓶颈可能定位在硬件中，也可能定位在软件中，对于后者，是无能为力的。硬件中的瓶颈可能会非常容易排除,一般来讲，解决硬件瓶颈的方法只是简单地向系统中添加CPU、磁盘或者内存等，如果硬件瓶颈是由于系统缓冲区设计或内存总线造成的，那么通常情况下就无能为力了。硬件瓶颈与软件瓶颈相比，更建议先解决软件瓶颈，原因有三，其一是软件瓶颈往往导致系统性能衰减更快，反过来讲，消除软件瓶颈，系统性能提升更快；其二是人为因素更易导致软件瓶颈，要消除软件瓶颈，开发人员会更主动，并且可以节省资源；其三，盲目增加硬件则无形中增加维护费用，将来，软硬件不匹配的问题终究还会暴露出来。
优化调整系统是在发现瓶颈，故障定位之后要完成的事情，实现优化之后即可消除瓶颈，提高性能。
性能测试指标：
通用指标（指Web应用服务器、数据库服务器必需测试项)
| 指标 | 说明 |
| ProcessorTime | 服务器CPU占用率，一般平均达到70%时，服务就接近饱和 |
| Memory Available Mbyte | 可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重 |
| Physicsdisk Time | 物理磁盘读写时间情况 |
Web服务器指标
| 指标 | 说明 |
| Requests Per Second（Avg Rps） | 平均每秒钟响应次数＝总请求时间 / 秒数 |
| Avg time to last byte per terstion （mstes） | 平均每秒业务脚本的迭代次数 ,有人会把上面那个混淆 |
| Successful Rounds | 成功的请求 |
| Failed Requests | 失败的请求 |
| Successful Hits | 成功的点击次数 |
| Failed Hits | 失败的点击次数 |
| Hits Per Second | 每秒点击次数 |
| Successful Hits Per Second | 每秒成功的点击次数 |
| Failed Hits Per Second | 每秒失败的点击次数 |
| Attempted Connections | 尝试链接数 |
数据库服务器性能指标
| 指标 | 说明 |
| User 0 Connections | 用户连接数，也就是数据库的连接数量 |
| Number of deadlocks | 数据库死锁 |
| Butter Cache hit | 数据库Cache的命中情况 |
系统的瓶颈定义
| 性能项 | 命令 | 指标 |
| CPU限制 | vmstat | 当%user+%sys超过80%时 |
| 磁盘I/O限制 | vmstat | 当%iowait超过40%(AIX4.3.3或更高版本)时 |
| 应用磁盘限制 | iostat | 当%tm_act超过70%时 |
| 虚存空间少 | lsps，-a | 当分页空间的活动率超过70%时 |
| 换页限制 | iostat, stat | 虚存逻辑卷%tm_act超过I/O(iostat)的30%，激活的虚存率超过CPU数量(vmstat)的10倍时 |
| 系统失效 | vmstat, sar | 页交换增大、CPU等待并运行队列 |
稳定系统的资源状态
| 性能项 | 资源 | 评价 |
| CPU占用率 | 70% | 好 |
| 85% | 坏 | |
| 90%+ | 很差 | |
| 磁盘I/0 | <30% | 好 |
| <40% | 坏 | |
| <50%+ | 很差 | |
| 网络 | <30%带宽 | 好 |
| 运行队列 | <2*CPU数量 | 好 |
| 内存 | 没有页交换 | 好 |
| 每个CPU每秒10个页交换 | 坏 | |
| 更多的页交换 | 很差 |