场景测试

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