传统的企业级软件产品和互联网产品性能测试，在原理和测试方法上基本一致，最大的区别体现在并发数量的数量级上，以及互联网
软件产品的性能测试还需要直接在生产环境下进行特有的全链路压测。而全链路测试其实是在传统的企业级软件产品的性能测试基础上
又进行了一些扩展。
性能基准测试（performance benchmark test）
是每次对外发布产品本嫩前必须要完成的测试类型。
性能基准测试，会给予固定的硬件环境和部署架构（比如专用的服务器、固定的专用网络环境、固定大小的集群规模、相同的系统配置、相同的
数据库背景数据等），通过执行固定的性能测试场景得到系统的性能测试报告，然后与上一版本发布时的指标进行对比，如果发现指标有恶化的
趋势，就需要进一步排查。
典型的恶化趋势，主要表现在以下几个方面：
同一事务的响应时间变慢了。
比如，上一版本中，用户登录的响应时间时2s，但是在最新的被测版本中这个响应时间要成了4S；
系统资源的占用率变高了。
比如，上一版本中，平均CPU占用率是15%，但是在最新被测版本中平均CPU占用率变成了30%
网络带宽的使用量变高了。
比如，上一版本中，发送总字节数是20MB，接收总字节数是200MB，但是在新版本中发送总字节数变成了25MB，接收总字节数变成了250MB
这里需要注意的是，这些恶化的趋势前提是：完全相同的环境以及测试负载。不同恶化指标的排查，有不同的方法。我以最常见的事务响应时间
变慢为例，和你说明一下排查方法。
假设，通过性能基准测试的比较结果得知，用户登录的响应时间从2s变成了4s。那么我们首先要做的是验证在单用户的情况下，是否会出现响应时间
变长的问题。具体做法是，将用户登录的虚拟 用户脚本单独拿出来，建立一个单用户运行的性能测试场景并执行，观察用户登录的响应时间是否变慢
，如果变慢了，就说明这是单用户登录场景就可以重现的性能问题，后续的处理也相对简单了。解决办法是：分析单用户登录的后端日志文件，看看完成
登录的后端日志文件，看看完成登录操作时间具体花在哪些步骤上，相比之前哪些步骤话费时间变长了，或者是多出了哪些额外的步骤。
如果没有变慢，则说明我们必须尝试在有压力的情况下重现这个性能问题。为此，我们要基于用户登录的虚拟用户脚本构建并发测试的场景，但是我们
并不清楚在这个场景设计中到底应该采用多少并发用户，加入多长的思考时间。这时，通常的做法是，直接采用性能基准测试中的并发用户数和思考
时间，去尝试重现问题。如果无法重现，我们可以适当的逐步加大测试负载，并观察响应时间的变化趋势。
这里需要注意的是，千万不要使用过大的测试负载。因为测试负载过大的话，系统资源也会成为性能瓶颈，一定会是响应时间变长。但这时，响应时间变长
主要是由资源瓶颈造成的，而不是你开始要找的那个原因。
如果此时可以重现问题，那就可以进一步去分析并发场景下，用户登录操作的时间切片，找到具体原因。如果此时还是不能重现问题的话，情况就比较复杂了
，也就是登录操作的性能可能和其他的业务操作存在依赖，或者某种资源竞争关系，这就是具体问题具体分析了。
一般来说，当定位到性能“恶化”的原因并修复后，我们还会再执行一轮性能基准测试，以确保系统对外发布前的性能基准测试指标没有变坏。可以说
通过对每个预发布版本的性能基准测试，我们可以保证新发布系统环境的整体性能不会下降，这也就是性能测试最终要达到的目的。
很多大型传统软件公司都有专门的性能测试团队，这个团队会建立标准的性能基准测试场景，并把性能基准测试的结果作为产品是否可以发布的依据
之一。比如，我曾工作过的HP软件，就由性能测试卓越中心负责维护，执行性能基准测试，并分析测试结果。
从性能基准测试的设计角度来看，你需要特别注意以下三点：
1.性能基准测试中虚拟用户脚本的选择以及配比，需要尽可能地匹配实际的负载情况；
2.总体的负载设计不宜过高，通常被测系统的各类占用率指标需要控制在30%以内，尽量避免由于资源瓶颈引入的操作延时；
3.每次性能基准测试前，一般需要对系统资源以及网络资源做一轮快速的基准测试，以保证每次被测试环境的一致性，同时也要保证数据库的数据量在
同一级别上。总之，你需要采用一切可能的手段，来确保多次性能基准测试之间的环境一致性。
稳定性测试
稳定性测试，又称可靠性测试，主要是通过长时间模拟被测系统的测试负载，来观察系统在长期运行过程中是否有潜在的问题。通过对系统指标的监控
，稳定性测试可以发现诸如内存泄漏、资源非法占用等问题。
很多企业级的服务器端产品，在发布前往往都要进行稳定性测试。稳定性测试，通常直接采用性能基准测试中的虚拟用户脚本，但是性能测试场景的设计
和性能基准测试场景会有很大不同：一般采用“波浪式”的测试负载，比如先逐渐加大测试负载，在高负载情况下持续10多个小时，然后在逐渐降低负载
这样就构成一个“波浪”，整个稳定性测试将由多个这样的波浪连续组成。
稳定性测试成功完成的标志，主要有以下三项：
系统资源的所有监控指标不存在不可逆转的上升趋势；
事务的响应时间不存在逐渐变慢的趋势；
事务的错误率不超过1%
实际工程项目中，由于稳定性测试执行的时间成本很高，往往需要花费3-7天的时间，所以我们一般是在其他所有测试都已经完成，并且所有问题都已经
修复之后才开始稳定性测试。
另外，有些企业为了缩短稳定性测试时间，往往还会采用“时间轴压缩”的方法，具体的做法就是：在加大测试负载的前题下，适当缩短每个“波浪”
时间，从而减少整体的测试执行时间。
最后，需要强调的一点是，虽然很多时间尤其是产品版本已经逐渐走向成熟期时，稳定性测试并不会发现问题，但是千万不要小看稳定性测试带来的价值
因为稳定性测试一旦发现问题，那么这些问题都是很严重而且非常隐蔽的大问题。
所以，很多大型的企业级软件企业都会执行严格的稳定性测试，并把稳定性测试的结果作为产品是否可以发布的硬性要求。
并发性测试
并发测试，是在高并发情况下验证单一业务功能的正确性以及性能的测试手段。高并发测试一般使用思考时间为零的虚拟用户脚本来发起具有“集合点”
的测试。并发测试，往往被当作功能测试的补充，主要用于发现诸如多线程，资源竞争，资源死锁之类的错误。要执行并发测试，就需要加入“集合点”
所以往往需要修改虚拟用户脚本。加入集合点一般有两种做法：
1.在虚拟用户脚本的录制过程中直接添加；
2.在虚拟用户脚本中，通过加入lr_rendezvous()函数添加。
容量规划测试
容量规划测试，是为了完成容量规划而设计执行的测试。那什么是容量规划呢？所谓容量规划，是软件产品为满足用户目标负载调整自身生产能力的过程。
所以容量规划的主要目的是，解决当系统负载将要达到极限处理能力时，我们应该如何通过垂直扩展（增加单机的硬件资源）和水平扩展（增加集群中的机器数量）
增加系统整体的负载处理能力的问题。目前来讲，容量规划主要方法是基于水平扩展。但是，具体应该增加多少机器，以及增加后系统的负载处理能力是否会
线性增长，这些问题都需要通过容量规划进行验证。
那么，容量规划测试具体要怎么做呢？我们可以使用性能基准测试中的虚拟用户脚本，以及各个业务操作脚本的百分比，压测单机部署的被测系统。我们会采用
人工的方式不断增加测试负载直到单机系统的吞吐量指标到达临界值，由此就可以直到单台机器的处理能力。
总结
四类性能测试方法，如何在实际项目中完成这些测试，确保软件的性能。
性能基准测试，可以保证新发布系统的整体性能不会下降；
稳定性测试，主要通过长时间模拟被测系统的测试负载，观察系统在长期运行过程是否存在问题；
并发性测试，往往被当作功能测试的补充去发现多线程，资源竞争，资源死锁之类的问题。
容量规划测试，主要用于确定给定负载下的系统集群规模，其测试结果可以被用作系统容量设计的依据。
