02 | 容量测试与验证:怎样科学实施容量测试?
- 深入了解
- 翻译
- 解释
- 总结
容量测试与验证是一项重要的技术话题,相对于性能测试和压力测试,容量测试可能是一些人第一次听说。传统对容量测试的认知都希望获得一个瓶颈点,但现代化理解认为容量测试是验证手段,不是测试手段。在进行容量测试前,首先要确定测试的范围,包括专项场景和日常场景的服务。科学实施容量测试需要设计测试方案并进行评审,确保测试模型和数据合理,没有遗漏关键信息。容量测试工作需要全局视角,协作各个团队,以确保容量测试的全局流程。容量测试不是极限保障,而是有备而来的验证手段。 容量测试的实施过程包括测试准备、测试执行、测试反馈和持续跟进等六大工作内容。在测试准备阶段,需要根据评审过的场景撰写测试脚本,准备测试数据,并确保能够正常执行,服务无异常。在测试执行阶段,需要逐步对目标服务施加压力,严密监控各项指标,并在达到容量目标值后进行适当的摸高和脉冲,或对限流进行验证等工作。测试反馈阶段需要总结测试过程中的各项指标和数据,编写测试报告,输出结论。持续跟进阶段需要有效跟进暴露的问题,并在一定时间内跟踪解决,改进后确定时间再次进行验收,确保改进措施有效。 另外,文章还介绍了一种基线容量测试的方式,能够在测试环境以较低的成本先“定性”的识别出容量差异,以便提前发现可能存在的容量隐患。基线容量测试虽然没有办法对服务的容量进行定量分析,但可以一定程度上提前发现潜在的容量隐患,而问题早发现的修复和优化成本是最低的。 总的来说,本文详细介绍了容量测试的定义、范围和实施过程,提供了一套科学高效的容量测试流程,并探讨了基线容量测试的实施方式。文章内容丰富,适合技术人员快速了解容量测试的重要性和实施方法。
《容量保障核心技术与实战》,新⼈⾸单¥29
全部留言(4)
- 最新
- 精选
- 金时虽然说"容量测试是验证手段,不是测试手段",但一个服务的SLA不还是测试出来的吗?
作者回复: 我们并不反对“测试”这个行为,我们鼓励带着目标去测试(即验证),鼓励为了达到目标而做的改进工作先于测试进行,而不是纯粹靠测试去倒推这些改进工作。
2021-09-183 - 于加硕看到这一章,发现吴老师的容量保障思路是容量测试,通过压测检验当前系统能否承载输入的用户量,目前看到这里,还没有考虑资源利用率的问题。 另外同时也咨询下“基线容量测试”又在实践的吗?
作者回复: 你好,容量测试是一种验证手段,服务自身的优化和治理是需要前置的。资源利用率其实已经隐含在了容量保障的目标中,在第一章中我有提到:“服务容量充足,指的是服务的各项资源消耗和业务指标保持在一个相对安全的范围内”。也就是说,我们检验当前系统能否承载期望的访问量,是在资源利用率不出现瓶颈的情况下所实现的,例如某接口压到1000TPS时,CPU利用率不能超过90%。 关于基线容量测试,我们有一些团队在实践,效果还是不错的,如果有疑惑的话我们可以进一步交流。
2022-06-211 - 声东击西混合容量测试在jmeter中怎样设计应用工具中,需要什么插件会怎么设计???
作者回复: 你好,如果你指的“混合容量测试”是多场景的容量测试的话,可以使用JMeter的TestPlan,在里面放置多个线程组(Thread Group)来达到目的。如果想要一些更高级的功能(比如某个场景延迟一会启动,等),可以参考第七讲的工具实现原理。
2023-09-30归属地:山东 - Geek_722d27针对待发版的服务进行容量测试验证,验证通过隔离环境流量回放实现。根据本次回放各核心指标的与基线指标对比,来进行性能diff。2024-03-20归属地:北京