1、项目背景：
现有：广告发布平台--日均发布广告数量5万--PV 45万 ---数据库资源利用率35%---采用orcle 一主一从
日后希望通过，拆库等方式实现：日均发布量10万、单表最大500万广告、pv 150万和后续两年增长目标
2 、架构
3、 业务流程
主要功能点：
登录（无注册功能）
发布广告管理
计划/组/广告词管理
生效管理
报告管理三大核心模块
4 、性能需求分析，确定本次性能测试目标及目的
需要分析的是：包含多少用户，在什么时间或持续多久，在多大数据量基础上，进行了什么业务，最终关注怎样的指标，
以及获得性能需求的来源
1）性能需求的来源
开发过程相关文档（项目开发计划书、需求规格说明说、设计说明书测试文档等）
2）参照相似项目性能需求
根据公司其他产品或以往的项目累积的一些数据或者其它公司对外公布的数据，作为性能测试参考源
3）业界公认标准
2~5~10s内 或8~16~32s
4）分析用户使用模型
比如：早上8点会有200个用户在10分钟之内登录系统；每天查询交易高峰是早上9-11点和下午14-16点，
然后结合80/20原则计算并发量
5）80/20原则：系统在每个工作日有80%的业务在20%的时间内集中完成，或者系统80% 用户会在20%的时间内集中
操作。
6）建立业务分布图
7）系统日志
日志分析的重要性：分析日志可以获取系统参数，如并发量、响应时间、业务分部情况等，也能用于进行性能预警和容量规划工作。
web服务器的日志有两部分：
一是运行中的日志，它主要记录运行的一些信息，尤其是一些异常错误日志信息
二是访问日志信息，它记录的访问的时间，IP，访问的资料等相关信息。
配置tomcat访问日志：（默认没有打开）/tomcat/conf/server.xml
其中：“common”是Tomcat提供的一个标准设置格式。
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、确定实际运行环境
12、申请并搭建仿真性能测试环境
13、Mock Server的准备
14、操作系统性能监控分析工具与使用
1）Windows性能监控工具选择及监控详解
①Perfmon：windows自带的性能监控工具，在命令行输入“perfmon”就能打开该工具。
②Spotlight on Windows
2）Linux监控工具选择及监控详解
top、