一、背景：
当前所有同学做性能测试方法不一，没有统一的规范指导文档可以参考。
二、目的：
形成性能测试整个流程的指导规范，以后做性能测试的同学可以依据此规范做性能测试。
三、具体流程：
（1）需求评估
目的：
评估是否需要做性能测试。
新产品要上线，预估单台机器QPS峰值超过100。
已经上线过的产品，由于接入了新的业务或者用户量增加，预估单台机器QPS峰值超过100。
单台机器QPS峰值低于50的需求。
有相同产品实现逻辑的产品，且已经做过性能测试。
例如：假如一个请求，每次用户开启应用时都会发送到服务器，服务器则会返回给客户端本账号在好友中的积分排名情况。从产品的角度认为，每次应用启动，都会触发服务器查询一次数据库。这样会数据库会造成很大压力。而测试再了解了具体实现后发现：针对每个用户机器码的排序数据是从redis服务器返回的，而redis服务器会每隔一小时请求存储的mysql服务器来更新账号排名信息，这样看来mysql服务器请求频率很低，没有任何压力。由于redis服务器的性能之前已经测试过类似的，没有性能问题，所以这次并不需要对mysql服务器做压力测试。
产品已经灰度或者上过线，可直接参考灰度数据来推算全量用户的QPS峰值。
产品未上过线，可通过类似已上线的产品来评估线上QPS
以上两种都不符合，可通过通用算法来推算QPS。
计算模型：
每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%)) / 服务器数量。
其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时，有80%的请求发生一天的9.6个小时当中（很适合互联网的应用，白天请求多，晚上请求少）。
简单计算的结果：
((80%*500万)/(24小时*60分*60秒*40%))/1 = 115.7个请求/秒
（2）逻辑了解：
目的：产品、开发、测试相互认识，便于后续的沟通。
方法：在逻辑了解时，组织产品、测试、开发做需求评审及产品实现讲解会。
讲解会需要了解的点：
-
了解整个性能测试的业务逻辑。一般需要了解请求个数，请求参数含义，请求参数可取值等。
-
了解服务器部署情况，主要要和线上服务器做明确隔离。不要简单认为所有的请求都是指向测试服务器，就认为是只向测试服务器打压。主要分为三种情况:1、测试请求会经过跳转链接到线上服务器。2、测试请求的js会异步请求线上资源。3、测试服务器会经过逻辑处理后返回给客户端，而这里的逻辑处理可能包括到线上服务器处理或查询数据。
-
了解本次性能测试的测试目标QPS及推断方法。
-
了解本次打压的请求间和参数间比例关系，这样便于后续写脚本时能够尽量模拟线上用户行为。
（3）测试方案：
主要用来评估本次性能测试的排期。并以邮件通知到各方。
发送时机：
开发实现讲解之后，用例设计之前。
模板参考：
（见附录一）
（4）环境搭建：
1) 测试服务器的搭建的搭建。测试环境可以有开发来搭建。原则上测试服务器配置不能高于线上服务器的配置，且测试服务器部署的服务要尽量接近线上服务器，比如说线上服务器上运行了3个服务，峰值时会占用30%的cpu，那么测试服务器也要运行同样类似，且打压时cpu最高只能打到70%。这样得出的结果才具有指导意义。
2) 打压环境的搭建：主要指linux打压机的部署。具体部署方法就不在此赘述了，具体可以参照：http://www.51testing.com/html/13/n-3715213.html
3) 如果没有条件来搭建测试服务器，可否直接用线上的？
（5）数据准备：
主要指性能测试有效数据的准备。请注意是有效数据？
举例：加入你手动写完脚本后，跑一下脚本，发现服务器返回没有报错。都是200的response。这是否就说明是有效的打压呢？未必！应该回放脚本时，通过抓包工具抓包看下，对比真正使用场景中返回的response。看下内容格式是否一致。如果你的打压脚本返回的是空的200请求或者仅仅有关键字，但是内容都是空的，而真正场景返回的是大小为15K的json。这说明你的打压场景是有问题的。
如果出现问题：应该和开发沟通原因，最后让打压请求返回正确的数据。
准备测试机的查看权限。服务器log位置及信息。主要信息包括服务器响应时间，出错log标示，具体客户端请求信息。
（6）脚本开发：
根据上面获取到的逻辑和数据进行脚本开发。视个人习惯，可以使用录制方式和手动写脚本。但是需要注意一点，在保证尽量模拟用户行为的前提下，尽量使脚本简单。如if语句和for循环。这类语句在高并发下，本身就可能导致压力机性能问题。
（7）打压过程：
打压过程并不是放那里不管，通过linux系统提供的命令，需要时刻关注被测服务器的性能指标，结合LoadRunner场景的曲线来动态判断是否存在瓶颈。LoadRunner场景曲线主要关注HPS、TPS、responsetime。服务端主要监控cpu、内存、磁盘IO、网络IO。然后从这几方面再层层深入查找问题。另外，值得强调的是，打压过程不仅需要关注被测服务器的指标，也需要关注打压agent的性能指标是否正常。比如说如果并发数一直上不去，可能是打压机本上连接数受限导致的。也可能是打压机自己出口带宽满了导致的。
（8）问题定位&修改优化&回归：
问题定位是一个比较考验个人综合技术能力的地方。也是整个性能测试的核心所在。需要强调的是，不是看到某个参数遇到问题了，就直接可以断定服务区的瓶颈就在这个地方。比如：
具体是哪个部分的问题，需要再根据具体的逻辑实现和推断来逐步缩小范围。主要的过程可以参考一下步骤层层深入。服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
最后就是开发优化，测试回归，这里需要强调一点：测试回归时，如果开发优化时修改了功能逻辑，则需要根据改动回归功能逻辑是否正常。不能只盯在性能指标满足了就OK了。
（9） 性能报告：
性能测试报告没有固定的格式，但是大体需要包括以下几个方面：
整体结论：
本次性能测试的整体结论。是否符合预期，是否可以上线。
具体推算方式：
主要指给出整体结论的参考数据、计算公式等。
具体性能图标：
服务器cpu、内存、网络IO、磁盘IO、TPS、responsetime等指标，涉及到数据库的还需要给出与数据库相关的指标。
......
源自《51测试天地》原创测试文章系列(四十四）
