性能测试流程

一、准备工作

1.系统基础功能验证

　　性能测试在什么阶段适合实施？一般而言，只有在系统基础功能测试验证完成，系统趋于稳定的情况下，才会进行性能测试，否则性能测试是无意义的。

2.测试团队的组建

　　根据项目的具体情况，组建一个几人的性能测试团队，需要DBA和系统开发人员（前端、后台）等人员的配合。

3.工具的选择

　　综合系统设计、工具成本、测试团队的技能来考虑，选择合适的测试工具。

二、测试计划

1 .确定性能目标

　　如果是新产品，我们可以根据类似的产品的业务量、用户活跃时间、访问评率、场景交互、日活量等各个方面分析，并结合2/8原则来预估测试需求：

　　80/20原理就是系统在每个工作日有80%的业务是在20%的时间内集中完成，或者系统80%的用户会在20%的时间内集中进行应用操作。下面我们来举两个例子说明：

（1）某网站每日的总访问人数为10万，其中浏览单品页占30%，搜索业务占20%，登录+购买业务占50%。采用80~20原则，8小时的20%作为基准时间，计算各个业务的并发数。

• 搜索业务：（100000*20%*80%）/（8*3600*20%）=2.78取整为3
• 浏览单品页：（100000*30%*80%）/（8*3600*20%）=4.17取整为5
• 登录+购买：（100000*50%*80%）/（8*3600*20%）=6.94取整为7

（2）系统每年的业务集中在8个月完成，每个月平均有20个工作日，每个工作日8小时，按照80/20原则，即每天80%的业务在1.6小时完成。去年全年处理业务约100万笔，其中15%的业务处理中每笔业务需对应用服务器提交7次请求，其中70%的业务处理中每笔业务需对应用服务器提交5次请求，剩余15%的业务处理中每笔业务需对应用服务器提交3次请求。根据以往的统计结果，每年的业务增长量为15%，考虑到今后3年的业务发展需要，测试需按现有业务量的两倍进行请求数来计算系统应该达到的TPS。

• 每年的总请求数=(100万*15%*7+100万*70%*5+100万*15%*3)*2=1000万
• TPS=(10000000*80%)/(8*20*8*3600*20%)=8.68，取整即TPS=9

　　如果是在原产品上更新，则根据之前的业务场景表来为测试脚本开发提供依据。

　　其他性能指标：

　　①响应时间一般不能超过3秒；

　　②报表审核提交的页面响应时间不能超过5秒；

　　③文件的上传、下载页面响应时间不超过8秒；

　　④服务器的CPU平均使用率小于70%，内存使用率小于75%；

2 .制定测试计划

　　预设本次性能测试各子模块的起止时间，产出，参与人员等。

三、测试脚本设计与开发

1 .测试环境准备

　　性能测试环境包括软件环境、硬件环境和网络环境。这三大环境不仅是指应用服务器环境，还包括数据库服务器、缓存服务器、文件服务器以及其他中间应用服务器环境。

• 硬件环境包括：CPU、内存、磁盘等基本因素。
• 软件环境包括：操作系统版本号、配置，Linux磁盘分区、JDK版本、位数、厂商，中间件版本号、位数，数据库版本号、位数，以及这些软件的安装路径也最好与线上环境一致。配置文件包括JVM配置、中间件配置、数据库配置文件等。
• 网络环境包括：网络协议及网络带宽。
• 集群环境包括：应用相关服务器的负载均衡环境、数据库的热备或主从环境、集群环境等

申请线下仿真测试环境的时候，应遵循以下原则：

（1）硬件环境尽可能地保持与生产环境一致

（2）如果是集群环境，测试环境就不可能申请到那么多台服务器，那么可以考虑申请3台与线上生产环境一致的机器来作为线下的性能测试机器。在性能测试的过程中，可以分别测试单机、双机和三机负载均衡时候的性能表现，然后根据3种情况下性能表现计算出线上生产环境（比如说100台）进行负载均衡时的性能损耗率，从而较为真实的计算出线上100台机器进行负载均衡时候的性能指标。

（3）如果数据库集群环境太庞大，比如数据库是8组32台，那么线下测试不会申请32台机器进行性能测试。一般这种情况只会申请一组数据库（一主三从）作为性能测试的数据库即可。因为大型数据库的集群基本都是采用拆库分表策略，所以会导致数据库集群庞大。申请一组数据库机器就可以开展性能测试，只需要保证性能测试所用的用户数据都落在申请的这组数据库即可。

（4）如果实在无法保证硬件环境与线上一致，那么只能按照低配置环境进行测试，如果低配置环境测出的结果能满足线上要求，那么线上高配置环境肯定也能满足既定的性能要求。如果无法满足，则不建议做建模估算，因为如果CPU颗粒数、高速缓存、物理内存大小、磁盘转速不同，性能建模得出的性能结果也不够准确。如果在低配置的机器测试达不到要求，则要在测试报告中写明测试环境，并说明不能保证因为测试环境的提升而达到要求。

Mock Server准备：

在互联网行业叫Mock Server，在银行等金融行业叫做性能测试挡板。有时候系统的业务联调需要调用到其他系统的接口，但是其他系统的开发并未完成。对于这种情况，常见的解决方案是搭建一个临时的server，模拟那些服务，提供数据进行联调和测试。Mock Server的使用通常会带来以下好处：

（1）隔绝由其他模块或系统出错引起的本模块的测试错误。

（2）隔绝其他模块的开发状态，只要定义好接口，不用管开发有没有完成。

（3）一些速度较慢的操作，可以用Mock Object代替，快速返回。

2 .测试场景设计

　　根据测试需求可以分别测试单场景测试，混合场景测试，还有系统稳定性测试，例如以下三个场景：

  （1）、单场景

场景描述：模拟用户进行登录操作

并发量：分别模拟并发用户数为1、10、50三种情况进行测试

压测时间：每次15分钟

数据量：MySQL的user表中有70万账户

集合点：不使用集合点

重点关注指标：响应时间、事物成功率、应用服务器资源使用情况(CPU、内存、IO)、MySQL数据库资源使用情况(CPU、内存、IO)、应用日志是否有死锁等错误、数据库日志是否有死锁等错误、JVM内存使用情况和GC情况

预期指标：响应时间在2秒内、事物成功率为100%、应用服务器和数据库服务器CPU使用率≤60%、没有内存泄漏、数据库死锁、线程死锁等现象

  （2）、混合场景

混合场景不是把所有的测试场景糅合在一起形成一个大的场景，而应该先考虑不同的混合场景组合，如数据库查询操作的混合场景、数据库写操作的混合场景、数据库查询与写操作都包含的大混合场景。如下：

场景描述：模拟系统不用用户进行数据库读写操作的混合场景，场景包括用户登录、广告词默认查询、新建广告组、广告词默认创建、广告审核、广告生效、广告词按价格排序。

并发量：总共模拟300个用户同时操作，其中登录操作占比20%、广告词默认查询占比25%、新建广告组占比15%、广告词默认创建8%、广告审核10%、广告生效15%、广告词按价格排序7%

压测时间：每次15分钟

数据量：MySQL的cpc表有150万条数据、plan表有10万条数据、group表有50万条数据、audit表有100万条数据，MongoDB的report表有1TB数据、user表有90万条数据。

集合点：不使用集合点

重点关注指标：响应时间、事物成功率、应用服务器资源使用情况(CPU、内存、IO)、MySQL数据库资源使用情况(CPU、内存、IO)、应用日志是否有死锁等错误、数据库日志是否有死锁等错误、JVM内存使用情况和GC情况

预期指标：登录、广告词默认查询、新建广告组等操作响应时间在2秒内，广告词默认创建、广告审核、广告生效、广告词按价格排序等操作响应时间在3秒内，事物成功率为100%、应用服务器和数据库服务器CPU使用率≤60%、没有内存泄漏、数据库死锁、线程死锁等现象

  （3）、稳定性场景

场景描述：模拟系统不用用户进行数据库读写操作的混合场景，场景包括用户登录、广告词默认查询、新建广告组、广告词默认创建、广告审核、广告生效、广告词按价格排序。

并发量：总共模拟300个用户同时操作，其中登录操作占比20%、广告词默认查询占比25%、新建广告组占比15%、广告词默认创建8%、广告审核10%、广告生效15%、广告词按价格排序7%

压测时间：持续2*24小时

数据量：MySQL的cpc表有150万条数据、plan表有10万条数据、group表有50万条数据、audit表有100万条数据，MongoDB的report表有1TB数据、user表有90万条数据。

集合点：不使用集合点

重点关注指标：JVM内存使用情况和GC情况

预期指标：无内存泄漏现象或迹象发生

3 .测试脚本开发和调试

　　这里就不做详细描述。

三、测试执行和管理

1 .执行测试脚本

　　根据已经设计好的测试用例来执行。

2 .测试结果记录　　

　　根据测试采用的工具不同，结果的记录也有不同的形式；现在大多的性能测试工具都提供比较完整的界面图形化的测试结果，当然，对于服务器的资源使用等情况，可以利用一些计数器或

　　第三方监控工具来对其进行记录，执行完测试后，对结果进行整理分析。

四、测试分析和调优

　　每一个调优后，配置信息及测试结果都需要详细的记录下来。

1 .测试环境的系统性能分析

　　根据我们之前记录得到的测试结果（图表、曲线等），经过计算，与预定的性能指标进行对比，确定是否达到了我们需要的结果；如未达到，查看具体的瓶颈点，然后根据瓶颈点的具体数据，

　　进行具体情况具体分析（影响性能的因素很多，这一点，可以根据经验和数据表现来判断分析）。

2 .硬件设备对系统性能表现的影响分析

　　由于之前设计了几个不同的测试环境，故可以根据不同测试环境的硬件资源使用状况图进行分析，确定瓶颈是再数据库服务器、应用服务器抑或其他方面，然后针对性的进行优化等操作。

3 .其他影响因素分析

　　至于其他诸如网络带宽、操作动作、存储池、线程实现、服务器处理机制等一系列的影响因素，具体问题具体分析，这里就不一一表述了。

五、回归测试

　　回归测试后，全部的目标达成后编写性能测试报告并发送给项目组成员。

六、性能测试报告

　　1、测试目标

　　　　哪些场景、并发用户数、响应时间、TPS

　　2、测试结论

　　　　通过/不通过

　　3、本次测试的优化

　　　　某某场景：开始测试的时候TPS为5，优化后TPS达到30，发现了什么问题，怎么解决的。

　　4、优化改动项

　　　　代码

　　　　JVM

　　　　数据库

　　　　中间件

　　　　Linux服务器

　　5、具体测试情况

　　　　系统架构

　　　　测试环境

　　　　测试方法

　　　　测试结果

　　6、后续优化建议