性能测试包括：基准测试、负载测试、强度测试、容量测试和压力测试
> 基准测试：按百度百科中的定义：基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试。
> 负载测试：（Load Test）：负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。通 过逐步增加系统负载，确定在满足性能指标的情况下，系统所能承受的最大负载量。
关注点：how much
> 强度测试（Stress Test）： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。包括
Spike testing：短时间的极端负载测试
Extreme testing：在过量用户下的负载测试
Hammer testing：连续执行所有能做的操作
> 容量测试(Volume Test)：确定系统可处理同时在线的最大用户数,使系统承受超额的数据容量来发 现它是否能够正确处理。
关注点：how much（而不是how fast）
> 压力测试：通过逐步增加系统 负载，确定在什么负载条件下系统处于失效状态，以此来获得系统能提供的最大服务级别。
以上关于基准测试、负载测试、强度测试、容量测试、压力测试的定义来源于网上内容(http://blog.csdn.net/yyu0315/article/details/4017268)。
我们在开始性能测试时，首先应该制订一份完整的测试计划，建立一套模拟生产环境的测试环境，以及可能用到的模拟器等，根据测试要求建立性能测试数据，测试数据要包括基础性数据和业务数据。之后通过基准测试建立一份测试基线。得到测试基线数据后，性能测试前期的准备工作就基本完成了。
在正式测试过程中，应尽可能地建立两套测试环境，一套用于加载，模拟生产环境进行测试。另外一套用于进行对比测试。对比测试的目的在于帮助我们拆分问题、隔离现场，定位性能瓶颈。
测试过程
第一步：计划测试
1、明确测试基线，建立必要的测试指标。
2、明确压力点，根据压力点设计出各种测试场景的组合，并进行文档化，给出测试场景的描述、条件、测试结果。
3、如果需要监测UNIX机器，那么需要在被监测的机器上安装监测Unix的进程
4、准备测试数据，包括初始化环境的脚本程序。
第二步：生成测试脚本，建立测试场景
根据不同的测试工具（我们的测试环境通常会使用loadrunner），生成自动化的测试脚本。
第三步：运行测试场景
运行场景前需要注意的事项：每个组的虚拟用户数、迭代次数、think time、参数化时的取值间隔、执行恢复数据的脚本、确认虚拟机的LoadRunner Agent Service打开
如果监测Unix，运行场景前需要启动监测Unix进程，启动的命令“rpc.rstatd”、查看这个进程是否启动的命令“rpcinfo –p”
运行前使Generator机器处理Ready状态
确认被监测的机器已经连接上去，并且添加自己所需要的计数器
运行之前一定要确认系统中压力点的数据量是多少
确认以上都正确时再运行测试场景
第四步：监视场景，观察运行状态
第五步：分析测试结果
每次测试结束后确认所做的操作是正确的，确认正确后把每次运行的情况记录下来，特别是运行错误的原因，形成测试报告，最后再分析结果。
测试工具
略。。增加一个对测试工具的简单简介一节
测试数据收集
测试过程中需要收集各个测试点的数据，下面主要介绍一些主要的资源使用情况的采集，包括CPU、Memory、I/O。如：
1。CPU使用：
记录计算机CPU的使用情况 nohup top -s 60 –o time -d 3600 > top.txt &
记录每个CPU的使用情况 mpstat –p all 60 > mpstat.txt &
2。Memory使用：
记录计算机内存使用情况 nohup top -s 60 –o time -d 3600 > top.txt &
软件系统Memory使用情况，包括每个GC
在启动脚本中增加-Xloggc参数，如“…/java –Xloggc:FileName –server…”
3。I/O使用：
记录计算机I/O的使用 nohup top -s 60 –o time -d 3600 > top.txt &
记录每个disk的outputs/inputs情况
iostat -xnc 60 3600 > iostat.txt &
关于资源利用的收集，更多可参考《高级 Linux 命令精通指南 第 3 部分：资源管理》：http://www.oracle.com/technetwork/topics/linux/part3-096227-zhs.html
关于JVM参数细节，可参考：http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
性能测试结果的分析
对性能测试结果的分析是建立在测试记录上的，它包括
- 测试过程中的错误信息
- 测试过程中所收集的各类指标监控数据
- 测试过程中的各种日志信息
错误信息分析
1．数据库错误信息
通常有可能会出现数据库的连接拒绝、失败等错误提示，可能原因是数据库连接超过了最大连接数， 很多连接处于等待状态（如Oracle会提示ORA-12519错误，Mysql会提示1040错误）等。此类数据库提示的错误可参考使用的数据库手册来解决。
另外还可能出现数据库响应变慢等现象，这时需要辅助数据库服务器的CPU、Memoery运行情况，以及数据库的日志等信息来分析。
2．应用服务器/Web服务器
通常有可能会出现连接拒绝(Connection refused错误)，登录不上的情况，以及Connection timed out的错误。
3．OutofMemeroy错误，CPU处于100%运行状态
这两个是常见的错误的信息，可能的原因很多，需要具体来分析
4．其他如网络等运行环境出现的错误信息
比如操作系统的文件句柄数量限制，会出现如Socket/File: Can’t open so many files等错误信息，
监控数据分析
1．CPU：
针对CPU利用率(CPU utilization)，一般原则是任何操作都不能使CPU长时间达到100%，希望能将平均利用率能控制在70%左右。
对CPU时间我们主要从CPU空闲时间，用户CPU时间，系统CPU时间，运行进程队列这几个方面去考察，如果从测试数据反映出的CPU占用率过高，我们还需要分析运行进程队列来帮助确认是否存在CPU瓶颈。
2．内存：
内存是影响软件系统性能的主要因素之一，内存资源的充足与否直接影响软件系统的使用性能。一般地，空闲内存与物理内存的比在70%左右时，内存资源是充足的，对软件系统使用性能几乎无影响。而小于20%时，则存在内存瓶颈。
对内存，我们主要从内存页的交换率来考察，当交换率持续走高，则应考虑内存访问命中率下降。
3．磁盘I/O：
针对磁盘I/O，我们希望能将磁盘利用率控制在70%左右，主要从IOPS，磁盘活动时间百分比，I/O 等待队列长度等方面来考察。当出现过高的磁盘利用率，较长的等待队列时，说明存在一定的磁盘瓶颈。此时，我们可以考虑应用数据缓存，降低I/O操作，也可以考虑调整数据布局，选择合适的RAID。
4．业务操作的响应时间：
以往我们的测试都要求：操作反应时间超过6s一般都应该有等待时钟对话框、一般配置操作反应时间不超过15s；对业务逻辑操作响应时间，我们可以从Loadrunner事务图中来分析，主要考察平均事务响应时间，事务性能摘要图，事务响应时间图，确定测试中响应时间过长的事务。
5．数据库服务器：
在出现数据库服务器CPU高企不下，数据库查询过慢等情形下，我们可以使用一些数据库提供的方法来对数据库的运行状态进行评估。
6．系统吞吐量评估：
系统的吞吐量与事务对CPU时间、IO、内存等的需求相关联。单个事务占用CPU时间越多，IO操作越频繁，系统吞吐能力越低，反之越高。系统的吞吐量主要受单位事务数量和并发数两个因素的影响，这两个因素的某项值达到最高值时，系统的吞吐量就无法提高，如果继续增大压力，系统的吞吐量反而会下降，压力越大，下降越利害。
此时我们需要从不同的角度来分析系统吞吐量，从系统运行环境层面上，我们需要考察网络基础设施、软件运行平台、应用服务器等的能力，排除运行环境层面的瓶颈。从业务层面上，考虑并发等因素来确定系统瓶颈。
日志信息分析
在实际系统中，我们常用日志来帮助我们跟踪系统运行状态，定位系统问题。在性能测试过程，日志信息也有利于我们调查出现的性能问题，下面就几个常见问题进行分析：
1。内存占用/泄露
在我们发现内存存在使用过大的情况下，严重会出现Outofmemery错误，我们需要查看内存消耗的时间分布，在使用较多内存的时间段内系统在进行什么样的操作，这些操作中有无存在大量内存占用或数据读写的操作。确定这些特定的操作后，我们再来观察这些操作后内存是否在回落。如果在进行这些特定操作后，每次回落幅度并不显明，且内存占用在缓慢持续增长中，我们就需要详细调查这些操作。
2。线程数目过多
在我们观察到线程在持续增长时，严重时会出现java.lang.OutOfMemoryError: unable to create new native thread错误，我们需要查看持续增长的线程在做什么工作。除了我们的日志外，我们还可以打印出dump信息来帮助分析。理想的状态，是每个创建的线程都有自己的名称，这样，我们可很快定位出增长的线程。确定增长的线程后，继续分析创建的原因。
3。线程死锁
线程死锁在外观上是较难判定的。当出现操作过慢，系统不响应，内存使用增长过快的情况时，其中可能的原因之一就是存在线程死锁。确定死锁需要我们前后对比多次打印的dump信息，同时调查相关日志来初步确认。在Thread dump 信息中，出现一些Java Thread 处于长时间等待状态，那么问题就可能出现在这些线程中。当发现相关的操作/线程后，继续在代码中分析线程的使用情况。
在对测试结果进行分析时，结合系统打印的日志信息可以帮助我们定位出系统可能的瓶颈位置，有利于我们进行一步的分析工作。