1.订票系统常用的场景：
登录
注册
订票
三个业务
2.注册
open_index
into_register
submit_register
3.登录
open_index
submit_login
sign_off
4.订票
open_index
submit_login
into_flight
find_flight
select_flight
pay_flight
sign_off
5.
单交易基准测试
注册、登录、订票分别进行测试
单交易负载测试
注册、登录、订票分别进行测试
单交易压力测试
注册、登录、订票分别进行测试
综合基准测试
注册、登录、订票一起综合
综合稳定性测试
注册、登录、订票一起综合
6.
单交易基准测试
注册支持1小时5000用户注册，并发数不少于30，响应时间不超过5秒，业务成功率100%，服务器CPU及内存资源使用率不超过80%
登录支持1小时1万用户登录，并发数不少于100，服务器响应时间不超过5秒，业务成功率100%，服务器CPU及内存资源使用率不超过80%
峰值时，订票支持1小时2000用户订票，并发数不少于20，服务器响应时间不超过5秒，业务成功率100%，服务器CPU及内存资源使用率不超过80%
单交易负载测试
注册功能验证30，50，80个并发时，性能表现
登录功能验证100，120，150个并发时，性能表现
订票功能验证20，50，80个并发时，性能表现
单交易压力测试
注册功能验证在30（可根据实际业务推算并发，在此并发情况下持续运行）个并发情况下，1小时，4小时，8个小时，性能表现
登录功能验证在100个并发情况下，1小时，4小时，8个小时，性能表现
订票功能验证在20个并发情况下，1小时，4小时，8个小时，性能表现
综合基准测试
根据实际业务情况分解，各个业务占比，设计综合场景的指标：
例如统计：某一段时间内，登录多少，注册多少，订票多少，各个占比多少，设计综合场景
假如，通过历史数据分析，在2017年4月15号上午11点21分到12点21分，业务量达到峰值，且注册占比23%，登录占比38%，订票占比39%
系统扩容后，期望目标是现有业务的两倍，占比不变，业务量加大
综合稳定性测试
在基准测试的基础上，持续运行相对较长的时间周期，验证服务器的稳定性（如：100个并发持续运行8个小时，验证服务器的持续服务能力）
7.并发测试：瞬时并发，并发上来了，可以，测试退出
持续时间：设置持续时间后，迭代次数是不生效的，迭代次数的优先级是低于持续时间的
8.以登录基准测试为例：
单交易基准测试
登录支持1小时1万用户登录，并发数不少于100，服务器响应时间不超过5秒，业务成功率100%，服务器CPU及内存资源使用率不超过80%
需求更改为（方便模拟测试）：登录支持10分钟300用户登录，并发数不少于20，服务器响应时间不超过5秒，业务成功率100%，服务器CPU及内存资源使用率不超过80%
分成两个业务测试类型：并发测试、业务量测试（交易量）
并发测试：并发数20，系统至少有20个已存在的可用账户
业务量（交易量）测试：10分钟300个用户，系统至少存在300个可用账户，需测试出单次登录消耗时间，从而计算出所需的vuser数量
例如：通过lr统计，单次登录消耗6秒左右（大概统计时间），10分钟为10*60/6=100次，即10分钟单个vuser可以模拟登录100次，则总共需要的vuser个数为300/100=3个vuser