本文详细介绍了两种测试场景的设计方案：一是通过增加并发用户数来寻找系统性能瓶颈；二是模拟单一用户高频率操作下的系统稳定性。使用ABTest自制工具与LoadRunner进行请求发送与性能监控。
测试场景设计：
1. 从A对B下订单的webserivce
|
测试接口名称 |
并发用户数（个） |
运行时长（分钟） |
备注说明 |
|
AtoB |
20 |
15 |
20用户并发，设计10个集合点 |
|
30 |
15 |
30用户并发，设计10个集合点 | |
|
40 |
15 |
40用户并发，设计10个集合点 | |
|
50 |
15 |
50用户并发，设计10个集合点 | |
|
60 |
15 |
60用户并发，设计10个集合点 | |
|
70 |
15 |
70用户并发，设计10个集合点 | |
|
80 |
15 |
80用户并发，设计10个集合点 | |
|
90 |
15 |
90用户并发，设计10个集合点 |
通过并发数的增加来找到程序的性能瓶颈（并发比较小，所以就只需要一台测试机了，一个测试机上面并发用户最好少于200）
2. 从B对A下订单的webserivce
|
测试接口名称 |
并发用户数（个） |
运行时长（分钟） |
备注说明 |
|
BtoA |
1 |
60 |
1个用户迭代N次，持续60分钟 |
|
1 |
60 |
1个用户迭代N次，间隔相同时间持续发送60分钟 | |
|
1 |
60 |
1个用户迭代N次，间隔不同时间持续发送60分钟 | |
|
1 |
60 |
1个用户迭代N次，engine停掉时的情况 | |
|
1 |
60 |
1个用户迭代N次，外部发生异常的情况 |
测试工具：
ABTest 自制研发 模拟B发送A系统的服务请求，工具记录各个请求条数，包括成功与失败请求。
loadrunner 商业工具 用于测试连续发送不同数据量的请求的每秒请求数及B事务层处理响应时间，和资源监控指标
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
