软件性能测试的目标：
1、测试系统的最佳用户数（随着用户数量的增多系统的响应时间并没有受到影响，直到某个数量的用户数响应时间开始明显增长）
2、测试系统的最大用户数（随着用户数量的增多，系统的响应时间开始延迟，直到某个数量的用户数时，系统开始响应失败或崩溃）
3、a、找到目前系统的性能瓶颈（依次测试系统的数据库、服务层各个接口、直到web端，分析找到最大用户数值最小的那几个部分，即是系统的瓶颈）
b、找到软件以外的性能瓶颈则可以在广域网中进行测试，结合软件的测试数据分析网络和硬件！
4、系统的稳定性测试（较高数量的用户持续访问系统较长的时间长度，期间系统一直能有效响应，并没有明显的响应时长起伏或死机）
注：本人在实际测试过程中发现，目前所测试的系统的响应时长是随着用户数量的增多正比例增加的，并没有一个增长点的存在；响应失败的出现也并非不常见，在数据量很小的情况下，就有可能出现偶尔失败的情况，当数据量很大时，响应失败的情况并没有显著增加。这也许跟本公司的框架处理机制有关系，具体问题具体分析，不可拘泥于教条。
性能测试的环境因素：
1）硬件环境
服务器硬件配置，客户端的硬件配置，如：CPU内存等
2）软件环境
系统的架构，前端、中间件、服务器（这里指运行系统软件服务器，如tomcat）、数据库，以及他们的部署位置。用于加压的客户端采用什么性能测试工具进行加压。
3）网络环境
网络环境很重要。在上面的几个目的中，除了找出系统性能瓶颈可以在广域网进行，因为这个目的可以不用设置太多的虚拟用户，只要找出系统哪个地方影响了整个系统的性能就行。 其他目的的测试都需要在，局域网进行，不然你压力工具所发送的请求都会卡死在网络的传输过程中。
确定系统的压力点：
我们需要对系统的哪个页面或业务进行加压。系统的首页？系统的登录？还是系统的交易过程？各个业务的用户比例是多少？只有获得有效的性能需求，才容易寻找和定位压力点
并发的两种情况：
1、所有的用户在同一时刻做同一件事或操作，这种操作一般指做同一类型的业务。比如，所有用户同一时刻做并发登录，同一时刻做表单提交。
2、多个用户对系统发出了请求或者进行了操作，但这些请求或操作可以是相同的，也可以是不同的。比如，在同一时刻有用户在登录，有用户在提交表单。
测试思路：
测试最佳用户数和最大用户数的思路：（有点黑盒性能测试的感觉）
1、首先分析压力点，通过直接录制脚本的方式录制出想要的脚本,比如要测试静态页面则录制静态页面的脚本，要测试登陆则录制登陆的接口，要全系统分析则录制全系统所有功能的脚本。
2、处理让脚本可以按照自己的思路（设计何种并发、添加哪些测试元件、压力点的设定）顺利执行。要注意屏蔽图形验证码，以及1.6jdk不支持https控件等常见问题，具体问题具体分析解决。
3、执行脚本分析数据。
性能瓶颈测试思路：（有点白盒性能测试的感觉）
1、首先要熟悉软件的架构，比如：web--服务层--DB。
2、根据软件的架构采用从前往后或从后往前的测试思路逐层测试，在测试服务层的每个接口时需要知道内部接口的入参、出参手动编辑脚本。这一步也叫接口性能测试。
3、分析测试数据，主要对web前端的性能、每个接口的性能、数据库性能等进行分析，对中间件如：redis、nginx、tomcat，以及数据库要能够简单调优。最终将测试结果反馈给对应开发负责人。
稳定性测试：
这里与最佳用户数以及最大用户数的测试方法类似，用户数设置为最佳用户数与最大用户数之间的多组数据，将线程设置为循环，指定循环时间为12小时以上。
测试数据的分析：
1、Work Load = Virtual Users 工作负荷 = 虚拟用户数
对服务器产生多大压力，可以由多少用户同时对服务器发送请求来衡量。也就是服务器的性能可以看它同时处理多少用户发送来的请求来衡量。
虚拟用户数可以用进程或线程的方式进行模拟。
2、response time 响应时间
从客户端将数据包发出，到接收到服务器端发来的请求。这个过程的总体时间叫response time
这个时间用来衡量的处理请求的速度（抛出网速限制的前提下）
3、Response/Successful Response 响应/成功的响应
4、throughput ~Ti & To 吞吐率
“吞吐率”，就是单位时间的吞吐量，比如吞吐量/秒。
站在服务器端，T-in表示“吞”；T-out表求“吐”
Ti：T-in 主要衡量客户端的能力，看客户端往服务器发送的请求数据包的吞吐率。
To： T-out 主要衡量的服务器端的能力，看服务器处理返回请求数据包的吞吐率。