可自动扩缩容的云系统需做压力测试吗？压力测试与可扩展性测试辨析

问题背景 #

来自k6官方文档的定义：压力测试通过将系统推向崩溃临界点来验证其容量。文档中包含一个扩缩容测试示例，但图表未显示任何请求失败。

核心疑问 #

若云系统支持无限自动扩缩容，似乎不存在崩溃临界点，这种情况下的测试还能称为压力测试吗？是否更适合归类为可扩展性测试？二者本质是否相同？

解答 #

1. 无限自动扩缩容场景下仍可属于压力测试范畴 #

即使系统能无限扩缩容，依然可以开展压力测试——只是测试目标不再是找「系统崩溃临界点」，而是验证这些关键内容：

• 扩缩容机制的响应速度：高负载冲击下，系统能不能在预期时间内完成扩容，避免短暂的性能劣化
• 扩缩容过程中的稳定性：扩容/缩容时会不会出现请求延迟突增、会话丢失、数据不一致等问题
• 上游依赖的承压能力：哪怕应用层能无限扩缩，数据库、消息队列、第三方API等上游组件可能存在瓶颈，压力测试能暴露这些隐藏的临界点

2. 与可扩展性测试的边界区分 #

这种场景下的测试确实和可扩展性测试高度相关，但二者核心目标不一样：

• 压力测试：聚焦「极端负载下的系统表现」，会持续加压，哪怕扩缩容无限，也要验证系统在负载峰值下的稳定性、上游依赖的极限，甚至测试扩缩容机制的极限（比如扩容频率上限、资源调度延迟）
• 可扩展性测试：更关注「系统随负载增长平滑扩容的能力」，通常逐步增加负载，观察性能指标（延迟、吞吐量）是否线性提升，验证扩缩容策略的合理性

3. 二者本质不同 #

压力测试和可扩展性测试的核心目标存在本质差异：

• 压力测试的核心是验证系统的极限承压能力（包括显性和隐性瓶颈），就算系统能无限扩缩，也要挑战链路里最薄弱的环节
• 可扩展性测试的核心是验证系统的弹性适配能力，重点确认系统能否在负载变化时平稳调整资源，保持性能达标

内容的提问来源于stack exchange，提问作者stormtrooper