性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
按照不同的目标，可以分为负载测试、压力测试、容量测试、稳定性测试。平时工作中如果不是专业的测试机构，开发人员或者运维人员做的基本上都属于压测。
压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
性能指标
QPS
目前在业界告诉别人我系统的性能指标，比较容易说的就是QPS。QPS有时也说TPS，指的是每秒钟request/事务。通常有人告诉你他的接口并发3000通常指的就是QPS=3000，可以理解为他的系统1秒钟接受并处理完毕3000个请求。
QPS的算法就是：完成请求的数量/完成请求所花费的时间
如果10秒的时间内，系统接受到了3000个请求，返回了2000个，剩下1000报错。它的QPS=2000/10=200个
响应时间
响应时间，从单个请求来看就是服务响应一次请求的花费的时间。但是在性能测试中，单个请求的响应时间并没有什么参考价值，通常考虑的是完成所有请求的平均响应时间及中位数时间。
平均响应时间很好理解，就是完成请求花费的总时间/完成的请求总数。但是平均响应时间有一点不靠谱，因为系统的运行并不是平稳平滑的，如果某几个请求的时间超短或者超长就会导致平均数偏离很多。可以参考读新闻的平均工资、平均房价等，你就知道为什么不那么靠谱了。因此有时候我们会用中位数响应时间。
所谓中位数的意就是把将一组数据按大小顺序排列，处在最中间位置的一个数叫做这组数据的中位数 ，这意味着至少有50%的数据低于或高于这个中位数。当然，最为正确的统计做法是用百分比分布统计。也就是英文中的TP – Top Percentile ，TP50的意思在，50%的请求都小于某个值，TP90表示90%的请求小于某个时间。
并发数
并发数是一个特别容易混淆的概念，因为他在各种语境下表示的含义可能并不相同，从性能测试结果的角度来看
并发指的是在某一时间点，服务器正在处理的请求数
但是我们在实际工作中，经常听到别的说法
举例来说：
工程师经常说1秒并发2000，其实他指的是QPS=2000。
而一个网站管理员说我们并发1000人，其实指的最大在线人数1000人。在线人数1000人并不意味每个人都同一时间在跟服务器做交互，因此服务器的并发数并未到1000.
运维人员说我设置的tomcat的并发数500，他指的是这个tomcat最多可以调用500个线程同时接受请求。也就是同一时间服务器能达到的最大并发数数是500，但是受限于CPU、OS等其他原因，并发数在实际中达不到这个数值。
性能测试人员说我在LR中设置了并发数3000，指的是他在测试工具中设置3000个并发模拟用户，只是理论上在单位时间内最多会有3000个的模拟请求到服务器上。但是从客户端角度出发，客户端有可能因为CPU、OS、等待时间等等限制，并不能达到此压力。即使客户端达到了此压力，但是从服务器的角度出发，会有排队机制以及部分请求异常溢出，并不能说服务器的并发就到了3000。
因此性能测试中的并发数指的是一个测试出来的结果计算值，其计算公式是
QPS*平均响应时间
吞吐量
吞吐量，是指在一次性能测试过程中网络上传输的数据量的总和。对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值。如一个大型工厂，他们的生产效率与生产速度很快，一天生产10W吨的货物，结果工厂的运输能力不行，就两辆小型三轮车一天拉2吨的货物，比喻有些夸张，但我想说明的是这个运输能力是整个系统的瓶颈。
提示，用吞吐量来衡量一个系统的输出能力是极其不准确的，用个最简单的例子说明，一个水龙头开一天一夜，流出10吨水；10个水龙头开1秒钟，流出0.1吨水。当然是一个水龙头的吞吐量大。你能说1个水龙头的出水能力是10个水龙头的强？所以，我们要加单位时间，看谁1秒钟的出水量大。这就是吞吐率。
最大并发量
在理解了上述几个指标之后，性能测试的目的就变成了在特定的条件下（固定硬件设备，通常要排除网络瓶颈），寻找系统的最大并发量的过程。当并发数增大到一定的程度，系统反应时间还在可以接受的范围之内，服务并没有出现失败，或者失败率在可接受的范围内，如果超过此并发量，系统的指标变得不可接受，则认为这个值是系统的最大并发量。
最大并发量的应用
系统的最大并发量只是一个技术上的理论值，往往在技术团队内吹吹牛，而鲜有业务同学感兴趣。在你对自己1000个最大并发量感到沾沾自喜的时候，客户质问：“你说的1000并发到底能承载多少个用户呀？”。这时你往往懵逼了，这时你往往要问客户一句：”你问的是注册用户，还是同时在线用户？“。现实的情况是单个功能模块的QPS及最大并发数，往往很难估算出全站的业务含义上的用户量，现实生活比计算机机房模拟的环境要复杂的多，需要考虑网络环境、用户对各个功能点的使用率、用户的操作习惯行为等，即使你使用LR等复杂的测试模拟工具，对不同的功能模块进行了综合的测试，往往也只能得出一个估算的值，而且你往往遇到的最大的问题是你没有那么强的扮演成千上万模拟客户端的测试机，即使你有，你往往又没有那么宽的带宽，在压力上去之后，网络首先成为了瓶颈（这也就是为什么阿里之类的PTS等测试服务存在的原因）。
不过幸运的是，我们往往并不用得到特别精确的值来服务我们的业务，往往是个大概的值就可以了，所以我们还是可以根据一些经验估算，比如按照之前项目的PV，按照自己的想法对每个模块加权计算。甚至于可以拿日常的PV数除一下高峰持续时间得到日常的QPS，再以最大的QPS估算能够支持的最大PV数，再推出UV数。
有个帖子贴了常见WEB网站的QPS等级分类，可以参考下
http://www.cnblogs.com/yiwd/p/3711677.html
按照帖子的描述：90%的网站其实都是在前两级别浮动
如何严谨地做性能测试
以下内容来自著名博主：左耳朵耗子
原文参见：https://coolshell.cn/articles/17381.html
一般来说，性能测试要统一考虑这么几个因素：Thoughput吞吐量，Latency响应时间，资源利用（CPU/MEM/IO/Bandwidth…），成功率，系统稳定性。
下面的这些性能测试的方式基本上来源自我的老老东家汤森路透，一家做real-time的金融数据系统的公司。
一，你得定义一个系统的响应时间latency，建议是TP99，以及成功率。比如路透的定义：99.9%的响应时间必需在1ms之内，平均响应时间在1ms以内，100%的请求成功。
二，在这个响应时间的限制下，找到最高的吞吐量。测试用的数据，需要有大中小各种尺寸的数据，并可以混合。最好使用生产线上的测试数据。
三，在这个吞吐量做Soak Test，比如：使用第二步测试得到的吞吐量连续7天的不间断的压测系统。然后收集CPU，内存，硬盘/网络IO，等指标，查看系统是否稳定，比如，CPU是平稳的，内存使用也是平稳的。那么，这个值就是系统的性能
四，找到系统的极限值。比如：在成功率100%的情况下（不考虑响应时间的长短），系统能坚持10分钟的吞吐量。
五，做Burst Test。用第二步得到的吞吐量执行5分钟，然后在第四步得到的极限值执行1分钟，再回到第二步的吞吐量执行5钟，再到第四步的权限值执行1分钟，如此往复个一段时间，比如2天。收集系统数据：CPU、内存、硬盘/网络IO等，观察他们的曲线，以及相应的响应时间，确保系统是稳定的。
六、低吞吐量和网络小包的测试。有时候，在低吞吐量的时候，可能会导致latency上升，比如TCP_NODELAY的参数没有开启会导致latency上升（详见TCP的那些事），而网络小包会导致带宽用不满也会导致性能上不去，所以，性能测试还需要根据实际情况有选择的测试一下这两咱场景。
（注：在路透，路透会用第二步得到的吞吐量乘以66.7%来做为系统的软报警线，80%做为系统的硬报警线，而极限值仅仅用来扛突发的peak）