1、项目背景：
现有：广告发布平台--日均发布广告数量5万--PV 45万 ---数据库资源利用率35%---采用orcle 一主一从
日后希望通过，拆库等方式实现：日均发布量10万、单表最大500万广告、pv 150万和后续两年增长目标
2 、架构
测试之前，必须了解项目的架构，方便后面申请和准备测试环境，也为了了解性能测试各个功能数据的流向，方便监控各个数据流环节，从而不会遗漏性能瓶颈点，方便全面进行性能监控和分析。
3、 业务流程
主要功能点：
登录（无注册功能）
发布广告管理
计划/组/广告词管理
生效管理
报告管理三大核心模块
4 、性能需求分析，确定本次性能测试目标及目的
需要分析的是：包含多少用户，在什么时间或持续多久，在多大数据量基础上，进行了什么业务，最终关注怎样的指标，
以及获得性能需求的来源
性能测试需求自动获取：系统日志--------①
分析日志可以很精确地获取当前系统级别的最大并发量、各个功能的并发用户量、各个功能的响应时间、各个功能业务的占比（用于综合场景，减少遗漏性能测试场景）、系统并发用户量的增长情况等，这样得到的性能测试目标非常准确、项目其它人员也会直接认同。
通过日志分析工具来进行分析，比较常用的有：Webslizer、Awstats、Logstalgia
web服务器的日志有两部分：
一是运行中的日志，它主要记录运行的一些信息，尤其是一些异常错误日志信息
二是访问日志信息，它记录的访问的时间，IP，访问的资料等相关信息。
配置tomcat访问日志：（默认没有打开）/tomcat/conf/server.xml
其中：“common”是Tomcat提供的一个标准设置格式。
性能需求传统获取：
1）开发过程相关文档（项目开发计划书、需求规格说明书、设计说明书、测试计划等文档都可能涉及对性能的要求），以及与项目相关的干系人，比如客户代表、项目经理、需求分析员、系统架构师、产品经理等沟通交流。
2）相似项目性能需求-------⑥
根据公司其他产品或以往的项目累积的一些数据，或者其它公司对外公布的数据，也可以作为性能测试需求的参考源。比如要做为微博项目，那么可以参考新浪微博，比如，截至2017年9月，微博月活跃用户共3.76亿，与2016年同期相比增长27%，其中移动端占比达92%；日活跃用户达到1.65亿，较去年同期增长25%。
3）业界公认标准-------⑤---适用于没有做日志分析的
比如响应时间，根据服务器的不同和项目的具体情况可能有两类标准：
现在的标准1,3,5原则 ： 100 300 500 ms
以前的标准：
2s以内，用户感受良好
2~5s，用户觉得可以接受
5~10s，用户会觉得烦躁，会无法接受，从而导致频繁得刷新页面。
4）分析用户使用模型------④ 考虑用户使用习惯
性能测试也是通过模拟执行一系列场景来完成的，因此考虑哪些用户使用系统的哪些典型业务，在什么时段有多少用户进行了什么功能的操作。
比如：某OA系统早上8点会有200个用户在10分钟之内登录系统；每天查询交易高峰是早上9-11点和下午14-16点，
然后结合80/20原则计算登录及交易查询业务的并发量。
5）80/20原则：------②
系统在每个工作日有80%的业务在20%的时间内集中完成，或者系统80% 用户会在20%的时间内集中操作。如果已经获取到线上日志，可以直接通过编写shell脚本来统计系统单位时间内的最大并发量。
6）建立业务分布图-------③---已被日志分析所取代
是以一种直观的方式展示性能测试需求，描述一些交易任务在24小时内的交易情况。
5、性能测试场景的确定
通过日志分析，初步形成的需求 >> 考虑未来两年的性能指标 如下：
1）登录：最少支持 44>>70并发，响应时间在2s内
2）数据库单条写操作：最少支持 120>>180个并发用户数，响应时间在2s内
3）数据库批量写操作（一次往数据库插入/修改/删除200条数据）：最少支持 141 >> 191个并发，响应时间2s内
4）数据库读操作（默认查询，分页显示20）：最少支持 141 >> 220 个并发，rt在2s以内
5）数据库读操作（分页显示200）：最少支持 70 >> 110并发，rt在3s以内
6）数据库聚合及排序操作：最少支持 90 >> 160个并发，rt在3s内
7）整个系统1s内最大并发数位 337 >> 612，对应混合场景。在进行混合场景测试时，不同功能按比例分配337并发用户数。
完成初步需求分析后，还要考虑未来两年业务增长量带来的性能增长，分析日志，从而确定最终的性能目标。
6、性能测试场景获取及用例设计
性能测试场景选取方法如下：
1）用户访问量比较大的功能
2）与金钱相关比较重要的场景
3）影响业务主流程的场景
4）开发人员认为可能存在性能问题的场景
5）应该考虑综合场景，防止线程争用导致线程死锁以及数据库死锁
6）应该做稳定性场景测试，防止长时间运行导致的内存泄露情况的发生
场景确定：通过日志分析，获取到那些模块用户访问量比较大，初步提取测试场景如下，
1）广告按照每页展示20个进行查询（广告默认查询）
2）广告按照每页展示200个进行查询（广告批量查询）
3）单条广告发布
4）多条广告发布（一个用户一次发布200个广告）
5）用户登录
6）用户新建计划
7）用户新建组
8）广告生效
9）用户报告查询（分别设置查询维度为：昨日、最近7天、本月、上月、一年的场景；统计维度为：按月、按日统计）
10）修改广告词的价格操作
11）修改计划预算操作
12）综合场景测试、稳定性测试
确定性能目标与场景之后，需要进行评审工作。评审人员可以是产品、性能测试人员、开发、运维、数据库管理人员、项目管理者。经过性能需求和场景评审后，新增了以下场景：
13）广告审核（开发人员认为可能存在性能问题，需求是130万条未审核数据再600s内完成）
14）广告组的查询
15）广告计划的查询
7、性能测试数据确定
如果测试时不考虑数据量，那么性能测试结果是不准确的。
性能测试数据如果获取？根据“明年日均广告发布数量10万条、最大单表最大广告量500万条”，参考现有线上数据库表的数据量，然后按照目前统计的数据增量分别计算出各个项目测试场景对应的数据量如下：
1）广告查询：广告默认查询、广告批量查询、广告发布、广告词改价等功能对应---mysql广告表---2年后，拆库后单库单表的数据量为230万条（拆库前230w*64w条）
2）用户登录：对应---oracle的user表，数据量90w条（未拆分）
3）新建计划：计划的新增、查询及改价---Mysql的plan表，单库单表数据量10w条
4）新建组：广告组的新建、查询----mysql的group表，单库单表数据量为50万
5）广告生效：---mysql的广告表，单库单表数据230w
6）报告查询:---MongoDB的report表，数据量为1.6TB
7）广告审核：---mysql的审核表，积压待审核数据最大为130万
8、性能测试用例设计
性能测试场景有：单场景、混合场景、稳定性场景、全链路测试
1）单场景
用例编号：T1
场景描述：模拟用户进行登录操作
并发量：分别模拟并发用户数为1、44、70三种情况进行测试
压测时间：每次15分钟
数据量：Oracle的user表有90万账户
集合点：不使用集合点
加压方式：全部立即初始化、全部立即退出
场景运行时设置：think time=2s、continue when error
重点关注指标：
响应时间、事务成功率、
应用服务器资源使用情况（CPU、内存、I/O）、
Oracle数据库资源使用情况（CPU、内存、I/O）、
应用日志是否有死锁等错误、数据库日志是否有死锁等错误
JVM内存使用情况和GC情况
预期指标：
响应时间在2s内、事务成功率100%
应用服务器和数据库服务器CPU使用率≤60%
没有内存泄漏现象
没有死锁等情况发生
其它：略
2）混合场景
单场景测试用例设计完成之后，因为实际线上很多操作都是并行发生的，所以需要考虑综合（混合）场景的用例设计。
混合场景不是把所有的测试场景糅合在一起，而是应该考虑不同的混合场景组合。如数据库查询操作混合场景、数据库写操作的混合场景、数据库查询与写操作都包含的大混合场景。
用例编号：T12
场景描述：模拟不同用户进行数据库操作的混合场景，场景包括广告词默认20条查询、广告词批量查询（200条）、广告组查询、广告计划查询、广告报告按日查询、广告报告按月查询、广告词按价格排序查询的混合操作
并发量：总共模拟并发用户数为337个用户进行同时操作，几种操作的占比分别为20%、16%、17%、10%、14%、12%、11%。
压测时间：每次15分钟
数据量：Mysql的cpc表有230万条数据、plan表有10万条数据、group表有50万条数据、MongoDB的DB的report表有1.6TB数据。
集合点：不使用集合点
加压方式：全部立即初始化、全部立即退出
场景运行时设置：think time=2s、continue when error
重点关注指标：
响应时间、事务成功率、
应用服务器资源使用情况（CPU、内存、I/O）、
Oracle数据库资源使用情况（CPU、内存、I/O）、
应用日志是否有死锁等错误、数据库日志是否有死锁等错误
JVM内存使用情况和GC情况
预期指标：
响应时间：广告词默认查询在2s内、广告词批量查询在3s内、广告组查询在2s内、广告计划查询2s内、广告报告按日查询3s内、广告报告按月查询3s内、广告词按价格排序查询3s内
事务成功率100%
应用服务器和数据库服务器CPU使用率≤60%
没有内存泄漏现象
没有死锁等情况发生
其它：略
3）稳定性场景
持续时间：2*24小时
9、性能测试环境的准备与搭建
性能测试环境包括：软件环境、硬盘环境和网络环境。
这三大环境指：应用服务器环境、数据库服务器环境、缓存服务器、文件服务器及其他中间应用服务器环境。
硬件环境：CPU、内存、硬盘等因素
软件环境：软件版本号、位数、配置文件等。比如JDK版本及位数、数据库版本、Tomcat版本。配置文件包括JVM设置、线程池设置、数据库配置文件等。
网络环境：网络协议及网络带宽等。
集群环境包括：应用相关服务器（包括文件服务器等）的负载均衡环境、数据库（包括缓存数据等）的热备或者主从环境、集群环境等。
10、性能测试环境的重要性
1）性能测试环境尽可能保证硬件环境与线上生产环境一致，包括CPU、内存、硬盘等基本因素。
2）性能测试环境中，必须保持软件版本（精确到小版本号）与线上生产环境一致，如JDK版本、web容器（如Tomcat）版本、OS版本、数据库版本等。
3）保持涉及的配置项与生产环境一致，如web容器（如Tomcat）线程属性配置、数据库配置项、JVM配置、OS配置（如网络参数）等。
4）保证网络环境与线上一致，包括网络协议以及网络带宽等。
5）尽可能保持集群环境与生产环境一致，如数据库的集群、应用服务器的集群等。（大型集群环境，测试环境，可能无法满足，申请搭建仿真测试环境）
11、确定实际运行环境
1）硬件环境：
应用服务器：linux虚拟机，8核CPU、16G内存、200G硬盘，总共4台做负载均衡
代理转发服务器：linux虚拟机，8核CPU、16G内存、200G硬盘，总共1台，安装nginx进行反向代理
mysql数据库服务器：linux实机，16核CPU、48G内存、1.4TB硬盘，一主三从，总计8组，总共32台
MongoDB数据库服务器：
日志mysql数据库服务器
其它支撑应用服务器及数据库，申请3台虚拟机备用
网络：千兆带宽
2）软件环境
12、申请并搭建仿真性能测试环境
13、Mock Server的准备
14、操作系统性能监控分析工具与使用
1）Windows性能监控工具选择及监控详解
①Perfmon：windows自带的性能监控工具，在命令行输入“perfmon”就能打开该工具。
②Spotlight on Windows
2）Linux监控工具选择及监控详解
top、vmstat
iostat
sar
netstat
工具：nmon、Spotl on Linux
3）数据库系统性能监控工具的选择
关系型数据库Oracle和mysql的监控
15、Oracle监控分析
工具：Spotlight on Oracle（连接Oracle需要有DBA权限）
16、Mysql监控分析
工具：MysqlMTOP
17、中间件性能监控工具
中间件（web容器）很多，比如Apache、Tomcat、Resin等
监控Tomcat可以使用自带的status监控、Lambda Probe
18、JVM性能监控工具
19、性能测试数据准备与制作
20、测试脚本的开发与优化
21、监控对象
– 测试活劢中的所有服务器，测试机、应用服务器、数据库服务器、缓存服务器、依赖服务等资源监控
– 所有被测的应用服务监控，Nginx、tomcat、MySQL等
22、监控工具
运行场景之前，需要对被测系统各个维度以及响应时间进行监控。
1）Linux操作系统，用top、sar等命令进行监控
•平台类监控工具： zabbix、nagios
•Linux原生监控工具：Sysstat（iostat、sar、mpstat）、top等
• 其它第三方监控工具
‒IBM nmon，免费，实时监控，可存储为数据文件，幵生成图表
‒Perfease，灵活轻便，基于iostat、vmstat、sar生成图表
2）业务指标监控
Grinder、Jmeter、LR等自带实时TPS、响应时间等趋势图
3）数据库用MysqlMTOP进行监控，并结合慢查询日志进行分析
3）JVM监控采用jvisualvm
5）Tomcat采用
23、性能问题的发现、定位、分析
24、性能回归测试与结果