负载测试类型
当系统承受负载时，很多事情都可能出错。系统必须同时运行大量操作，并响应来自不同数量用户的各种请求。为了应对这些性能风险，团队会进行负载测试。
但好的负载测试策略不仅仅是执行单个脚本。不同的流量模式会给应用程序带来不同的风险特征。为了全面准备，团队必须针对不同的 测试类型 对系统进行测试。
不同目标的测试
从冒烟测试开始，然后逐步增加负载和延长持续时间。
主要类型如下。每种类型都有对应的文章，概述其基本概念。
冒烟测试 验证您的脚本是否正常工作以及系统在最小负载下是否表现良好。
平均负载测试 评估您的系统在预期正常条件下的性能表现。
压力测试 评估系统在负载超过预期平均值时，在其极限下的性能表现。
浸泡测试 评估系统在长时间持续运行中的可靠性和性能表现。
峰值测试 验证系统在突发、短暂和大规模活动增加情况下的行为和生存能力。
断点测试 逐步增加负载以确定系统的容量极限。
测试类型备忘单
下表提供了一些大致的比较。
| 类型 | VUs/吞吐量 | 持续时间 | 何时？ |
|---|---|---|---|
| 冒烟 | 低 | 短 (秒或分钟) | 相关系统或应用程序代码更改时。检查功能逻辑、基线指标和偏差 |
| 负载 | 平均生产负载 | 中 (5-60 分钟) | 通常用于检查系统在平均使用下的性能是否稳定 |
| 压力 | 高 (高于平均) | 中 (5-60 分钟) | 系统可能接收到高于平均负载时，检查其管理能力 |
| 浸泡 | 平均 | 长 (小时) | 更改后检查系统在长时间连续使用下的表现 |
| 峰值 | 非常高 | 短 (几分钟) | 系统为季节性事件或频繁的流量高峰做准备时 |
| 断点 | 增加直至中断 | 所需时长 | 多次运行以找到系统的上限 |
一般建议
在 k6 中编写和运行不同测试类型时，请考虑以下几点。
从冒烟测试开始
从冒烟测试开始。在开始大型测试之前，验证您的脚本是否按预期工作以及系统在少数用户下是否表现良好。
在确认脚本正常工作且系统对最小负载响应正确后，您可以继续进行平均负载测试。然后，您可以逐步尝试更复杂的负载模式。
具体细节取决于您的用例
系统具有不同的架构和用户群。因此，正确的负载测试策略很大程度上取决于您组织的风险特征。避免绝对化思考。
例如，k6 可以通过 VU 数量或每秒迭代次数来模拟负载 (开放模型 vs. 封闭模型)。在设计测试时，考虑哪种模式适合该类型。
此外，没有单一的测试类型能消除所有风险。为了评估系统的不同故障模式，需要结合使用多种测试类型。您系统的风险特征决定了应侧重于哪种测试类型
- 有些系统因长时间使用面临更大风险，在这种情况下应优先进行浸泡测试。
- 另一些系统因高强度使用面临更大风险，在这种情况下压力测试应优先进行。
无论如何，任何单一测试都无法发现所有问题。
此外，这些类别本身相对于用例而言是相对的。某个应用程序的压力测试可能是另一个应用程序的平均负载测试。事实上，这些测试类型的名称甚至没有统一的共识（以下每个主题都提供了替代名称）。
力求设计简单、结果可复现
虽然具体细节很大程度上取决于上下文，但不变的是您需要生成可比较和可解释的结果。
坚持使用简单的负载模式。对于所有测试类型，方向性就足够了：爬升、平稳、下降。
避免负载多次增加和减少的“过山车”系列。这将浪费资源，并使得难以隔离问题。
