接到性能测试需求阶段需要做的事

接到性能测试需求阶段需要做的事

举个例子：假如一个请求，每次用户开启应用时都会发送到服务器，服务器则会返回给客户端本账号在好友中的积分排名情况。从产品的角度认为，每次应用启动，都会触发服务器查询一次数据库。这样会数据库会造成很大压力。而测试再了解了具体实现后发现：针对每个用户机器码的排序数据是从redis服务器返回的，而redis服务器会每隔一小时请求存储的mysql服务器来更新账号排名信息，这样看来mysql服务器请求频率很低，没有任何压力。由于redis服务器的性能之前已经测试过类似的，没有性能问题，所以这次并不需要对mysql服务器做压力测试。

其次，如果确定要进行性能测试，就需要评估性能测试的方案。包括环境搭建、逻辑了解、数据准备、脚本编写、测试过程、问题定位、修改优化、回归、出报告的时间。需要强调的是，性能测试开始的时间一定是功能测试已经通过了。否则进行性能测试会存在修改功能逻辑导致性能发生变化，性能测试就没有任何指导意义了。

环境搭建：

这里主要指测试服务器的搭建和打压环境的搭建。测试环境可以有开发来搭建。原则上测试服务器配置不能高于线上服务器的配置，且测试服务器部署的服务要尽量接近线上服务器，比如说线上服务器上运行了3个服务，那么测试服务器也要运行同样类似，包括打压脚本上的设计也要考虑(后面会讲)，这样得出的结果才具有指导意义。再就是linux打压机的部署。具体部署方法就不在此赘述了。

逻辑了解：

这里主要开始着手了解整个性能测试的业务逻辑。一般需要了解请求个数，请求参数含义等。除此之外，在这里要强调几个新手容易忽视的问题：就是打压测试服务器时，要和线上服务器做明确隔离。不要简单认为所有的请求都是指向测试服务器，就认为是只向测试服务器打压。主要分为三种情况:1、测试请求会经过跳转链接到线上服务器。2、测试请求的js会异步请求线上资源。3、测试服务器会经过逻辑处理后返回给客户端，而这里的逻辑处理可能包括到线上服务器查询数据。

数据准备：

这里主要指性能测试有效数据的准备。为什么说是有效数据呢?举个例子：加入你手动写完脚本后，跑一下脚本，发现服务器返回没有报错。都是200的response。这是否就说明是有效的打压呢?未必!应该回放脚本时，通过抓包工具抓包看下，对比真正使用场景中返回的response。看下内容格式是否一致。如果你的打压脚本返回的是空的200请求或者仅仅有关键字，但是内容都是空的，而真正场景返回的是大小为15K的json。这说明你的打压场景是有问题的。应该结合服务器逻辑和询问开发。构造出可以让服务器认为是正常的请求来处理。从而返回正常的数据。