压测的需求调研
1.确认系统用户数、在线用户数、并发用户数（来源于需求预估或者线上已有的监控在线人数等）
2.确认压测业务：业务的压测点、并发用户数、响应时间、每秒事务数、
3.确认压测业务关联的数据量，是否需要进行铺底数据，预估系统支持几年的业务、每年业务的增长率多少，计算压测时需要的铺底数据
4.确认压测环境的架构、服务、服务器配置
5.确认是否有缓存机制，缓存机制与压测业务之间的联系
6.确认压测的工具
7.确认压测的监控，监控指标：cpu、内存、io、磁盘、网络
8.确认日志的增长量、清理机制（关注上线后，日志量的增长是否会导致服务器磁盘空间是否够用）
9.测试场景分为：
1）单业务场景：响应时间稳定情况下，场景运行10-15min
2）混合业务场景：在单业务通过的情况下执行，场景运行30min
3）稳定性场景：在混合场景通过的情况下执行，场景运行至少12h
系统架构详细信息（架构图、用到的服务、中间件、日志存放、数据存放）
首先需要知道的信息
1.系统的架构是怎样的，有什么服务（redis，支付，图纸转换，文件服务等），每个服务在服务器中怎么放置的，包括测试环境和线上环境的数据存放有什么区别，线上服务器和测试服务器的配置（需要保证测试环境的服务器和线上环境的服务器相差不是太多，这样测试的结果才有参考性）
2.服务器的硬件配置，有几台服务器，有几核的CPU，内存多大，带宽和IO有多少
3.系统里面的数据库，每个数据库分别存放有什么表，数据库放在哪的，表格内的数据存在哪里，日志信息存放在哪里（dokcer），日志有没有清理机制
4.需要确定在线并发用户，当前预计的用户数是1W+，在线用户数不知。目前打算使用平均并发用户数进行测试，公式 C = nL/T，因此需要知道登录的token的有效期是多少或者是用户平均时间是多少，当前的n假设为1W，T是8小时，然后得出C
计算在线并发数的公式：
1）平均并发用户数为 C = nL/T
2）并发用户数峰值 C‘ = C + 3根号C
C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度
C’是并发用户数峰值
举例1，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系统。那么，
平均并发用户数为：C = 4004/8 = 200
并发用户数峰值为：C‘ = 200 + 3*根号200 = 243Thread = BC*[t/(60*T)]
T： 考察的时间段，本例 T=30min
t： 单用户单次业务消耗时间，尽可能模拟用户的真实行为
BC： 业务量，本例 BC=5000
5.确认一下用户平常的操作，比如创建表格和保存表格的时候有什么数据量，用哪个表格去操作比较能模拟用户的操作，然后用户一般会创建几个项目，每个项目大概有几个表，当前已付费的，用户留存有多少人，大概留存多久
具体情况具体分析，网关负载策略，缓存情况，数据库读写策略，服务恢复机制，都有关，总体方式就是模拟各个环节，要么服务器部分挂掉，要么缓存丢失，要么数据库部分挂掉，观察分析恢复机制，补偿手段，和数据情况+系统拓扑图
混合场景、单业务场景、稳定性场景、异常场景设计
目前的性能测试场景有：
1.多用户同时加载目录树，目录树的响应时间（一个用户打开2000张表格，加载时间）
2.多个用户同时进行自动保存的操作
3.多个用户分别创建10张表格（10个用户分别创建10张表）
4.统计最大在线用户数
单场景：
①加载 ②保存 ③创建④最大在线用户
混合场景：
1-4组合跑，需要配置一下各个场景的比例（需要根据目前线上用户的使用情况，来分配各个场景的主要用户，比如在线的用户有1W个，此时正在使用表格加载的用户有1000个，创建表格的用户有2000个，实时保存的用户有2000个）
接口加载方式：
加载目录树时，加载目录树的接口是异步请求，因此需要用线程组设置；
自动保存的接口需要知道的是，表格存放的json在哪个数据表里；
创建表格的接口，创建的表哪个表具有代表性，哪个表要放什么数据会比较符合用户常规的操作；
数据存放方式：
目录树：目前的目录树，数据存放方式是目录树和文件夹放在redis，表格放在数据库；因为程序设置方式是，只要一个用户使用了目录树，后续其他的用户都可以从redis读取目录树，因此redis测试时不做断开模拟。
模板：模板的数据存放在哪里
表格：表格内的数据存放在哪里
数据铺底：因为表格存放在数据库，数据库中的表格假设之前就已经有数据量，这个数据量大概有多少，假设一万个用户至少创建1张表格，1万个用户至少要创建1个项目，那么是否需要提前做数据1万张表格和一万个项目。另外再加上表格的数据量和表格的
性能指标：
tps（每秒处理事务数，这里都是通过的事务）、art（平均响应时间）及并发数，加上服务器资料利用率的要求（cpu、内存、IO、网络等）、各个服务的资源情况。
内存相关参数优化：
1、缓冲池内存大小配置 （通过InnoDB 缓存性能评估 ）
2、配置多个buffer pool实例
3、chunk(块)大小配置
4、Page管理相关参数
5、Change Buffer相关参数优化
6、日志相关参数优化、IO线程相关参数优化
建龙为例场景设计
目前的业务需求有：
1.最大用户同时加载2000目录树，目录树的响应时间
2.最大用户同时进行自动保存的操作
3.最大用户分别创建10张表格
4.统计最大在线用户数（目前服务器能承受的最大用户）
单场景：
①加载 ②保存 ③创建④最大在线用户
混合场景：
1-4组合跑，需要配置一下各个场景的比例（需要根据目前线上用户的使用情况，来分配各个场景的主要用户，比如在线的用户有1W个，此时正在使用表格加载的用户有1000个，创建表格的用户有2000个，实时保存的用户有2000个）
需求分解：
1.注册用户有2000-3000
2.需测试最大系统并发和每秒最大的用户并发数
测试模型构建&用例设计
一、模型构建
1.加载-操作流程
2.保存-操作流程
3.创建-操作流程
二、场景用例设计
测试场景类型
单业务基准测试
单业务压力测试
单业务负载测试
综合业务基准测试
综合业务压力测试
综合业务负载测试
业务量线程数的确定
1.加载-线程数确定
2.保存-线程数确定
3.创建-线程数确定
测试场景用例设计
三、测试脚本用例设计
1.加载-操作流程
打开登录页，登录成功后选择一个项目，加载该项目的目录树
登录是同步的，新建项目是同步，加载目录树是异步的，建表的操作是异步的，保存是同步的
2.保存-操作流程
打开登录页，登录成功后选择一个项目，加载该项目的目录树，加载完成后新建一张表格，打开该表格，在表格中输入数据，移开鼠标自动保存
3.创建-操作流程
打开登录页，登录成功后选择一个项目，加载该项目的目录树，加载完成后新建一张表格，
