性能测试之场景设计和结果判断

简单来说：在复杂多变情况下，保证系统稳定

百度百科说：

评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。
识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。
检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。

ELK获取TPS时间分布

场景设计：根据实际的数据容量，业务类型比例，业务时段，业务量来综合设计性能测试场景。举例来说，某APP在12点-14点是交易峰值，占用全天交易的80%，那可以抽取这个时间段内的业务类型比例，产生的比例是，登录:加入购物车:交易:查询订单=10:3:1:6，那在做性能测试场景设计的时候可以采用这一比例进行测试。
监控模型建立：

超时概率：小于0.5‰
错误概率：小于0.5‰
TPS：大于期望高峰值
CPU利用率：小于75%
响应时间：小于期望时间
Load负载：平均没核CPU的Load小于1
JVM内存使用率：小于80%
FullGC频率：平均大于半小时1次

TPS和响应时间曲线抖动不能过于强烈，具备一定梯度，整体趋势应该是趋近与平稳

如下图在线程数增加的时候，TPS一个比较正常的图示，持续增加后，在13000TPS的位置趋近平稳，有一定梯度

如下TPS和响应时间的图例，可以用作正常类参考

如下图在线程数增加的时候，响应时间在1s一下缓慢增涨，当TPS到达高点13000以后，随时线程持续增加，响应时间增速加剧

不太合理的TPS图

波动幅度剧烈，找不到TPS的稳定峰值，不利于问题分析，性能测试结果不准确

梯度不明显，可以考虑增加Ramp-up，让TPS增幅变缓，否则响应时间的图也不会出现稳定期，较难做出峰值判断

TPS在某些点有突然下降，需要做出排查

扫一扫，关注我

性能测试之场景设计和结果判断的更多相关文章