软件浸泡测试：含义及示例
托马斯·汉密尔顿
什么是浸泡测试？
浸泡测试 是一种非功能性测试，用于测量长时间高负载下软件应用程序的性能。浸泡测试的目的是确保软件应用程序是否能够承受高使用量，并检查超出其设计预期的情况。
下图描述了一个测试周期，显示了浸泡测试在哪个阶段（性能测试类型) 在应用程序上执行。
在这种类型的测试中，主要监控的是系统中应用程序的内存使用情况。这是在系统级别进行的测试，目的是确定系统是否能够承受非常高的使用量，并查看超出其设计预期会发生什么情况。
为什么要做浸泡测试？
系统在使用 2 小时后可能会正常运行，但当连续使用同一系统 10 小时或更长时间时，它可能会失效或出现异常/随机行为/崩溃。为了预测此类故障，需要进行浸泡测试。
何时进行浸泡测试？
浸泡测试应在以下情况下进行：-
- 在将构建好的应用程序部署到客户端之前，即在特定平台上发布任何应用程序之前，它需要在高流量或同等流量水平下成功通过一系列负载测试。之后 进行浸泡测试。它帮助我们确定如何长时间运行任何特定应用程序。如果在 Soak 期间发现内存泄漏/内存损坏等问题，则应立即报告。
- 进行浸泡测试的最佳时间是周末，因为应用程序需要运行长达一天或一夜。这完全取决于测试情况的限制。浸泡测试是最重要的合规要求之一，每家公司都需要严格遵守。
浸泡测试策略
长时间浸泡测试是一种让系统长时间处于负载下的策略。
一个简单的例子是，用户登录系统数小时并执行多项业务交易。这样，就会产生大量数据。系统/数据库服务器上可能会有大量负载，这可能会导致系统/数据库服务器停转/崩溃。
在长会话浸泡测试中，在有限的时间范围内（比如 30 天）执行多天（比如 2 天）的活动。在这个有限的时间范围内的交易数量应该等于或超过多天的交易量。重点应该放在处理的交易数量上。浸泡测试最重要的部分是检查 CPU 中的可用内存以及将要使用的内存量。我们需要记录浸泡测试开始和结束时的内存使用情况。如有必要，则记录以下设施的内存使用情况： Java 虚拟机也很重要，需要受到监控。
以下是任何用户/测试人员在开始浸泡测试之前需要完成的一些检查：
a) 监控数据库资源消耗。
b) 监控服务器资源消耗（例如 CPU 使用率）。
c) 浸泡测试应以真实的用户并发度运行。
浸泡测试的特点
标准浸泡测试方法应具有以下特点：-
- 大多数浸泡测试的持续时间通常由可用时间决定。
- 如果需要延长运行时间，任何应用程序都必须不间断地运行。
- 它应该涵盖利益相关者同意的所有场景。
- 几乎每个系统都有一个定期维护窗口时间段，并且这些窗口期之间的时间是确定浸泡测试范围的关键驱动因素。
浸泡试验示例
- 对于银行领域，当商家有大量数据时，测试人员将使系统连续负载 70 小时到 150 小时，以检查应用程序在此加载期间的行为。
- 假设有 33,000 次登录需要通过系统，这代表了七天半的活动。在这种情况下，可以在星期五晚上 60 点左右开始 70-6 小时的浸泡测试，并可以在 Monday 早上 6 点。只有通过这样的测试，才有可能在受控条件下观察到性能的任何下降。
- 就电子游戏而言， 电话 应用程序等涉及让游戏或应用程序长时间处于运行状态，处于各种操作模式 - 例如空闲、在标题屏幕暂停等，以确定应用程序是否可以处理持续的预期负载。
浸泡测试期间观察到的常见问题
- 内存分配（内存泄漏最终会导致内存危机或仅随着时间的推移而显现的舍入错误）。
- 数据库资源利用率（在某些情况下无法关闭数据库游标，最终导致整个系统停滞）。
- 它还会导致性能下降，即确保长时间持续活动后的响应时间与测试开始时一样好。
- 在某些情况下无法关闭多层系统的各层之间的连接，这可能会导致系统的部分或全部模块停滞。
- 由于在长时间测试过程中内部数据结构的效率降低，某些功能的响应时间会逐渐缩短。
此测试如何融入性能测试系列
性能测试是一个统称。以下列出的各种测试方法仅在施加的载荷形式和保持时间上有所不同，因此它们经常被混淆。
| 测试类型 | 负载模式 | 它解答的问题 |
|---|---|---|
| 负载测试 | 预计峰值负荷，持续时间短 | 在正常高峰交通流量下，该系统能否达到其目标？ |
| 压力测试 | 超出负荷直至失效 | 它会在哪里出现故障？故障发生时是否体面？ |
| 尖峰测试 | 突然的极端激增，然后是撤退 | 它能否在交通冲击后幸存并恢复？ |
| 耐力测试 | 正常负荷持续数小时 | 性能会随着时间推移而下降吗？ |
| 浸泡测试 | 长时间持续负荷 | 是否存在内存泄漏或资源耗尽？ |
| 稳定性测试 | 不同条件下的负载变化 | 随着环境变化，系统是否仍能保持可靠性？ |
| 容量测试 | 普通用户，数据量非常大 | 随着数据库的增长，它能否应对？ |
耐久性测试和浸泡测试经常被视为同义词。 通常来说，耐久性测试和负载测试都是长时间持续高负载运行的测试。如果团队确实区分这两者，耐久性测试侧重于响应时间是否会逐渐延长，而负载测试则侧重于内存、文件句柄和连接池等资源消耗。运行其中一项测试通常就能提供这两项测试的结果。
测试期间需要收集的关键指标
性能测试的质量取决于测试过程中记录的数据。请在服务器端和客户端分别记录这六项数据，然后将其与基准数据进行比较，而不是仅凭直觉判断。
| 米制 | 它告诉你什么 | 警告牌 |
|---|---|---|
| 平均响应时间 | 典型用户体验 | 任何向上的漂移都会影响跑步路线。 |
| 第 95 百分位响应时间 | 最慢用户的体验 | 远高于平均水平，意味着不稳定 |
| 生产能力 | 每秒处理的请求数 | 负载保持不变时发生坠落 |
| 错误率 | 失败或超时请求的占比 | 任何超过约定阈值的涨幅 |
| CPU 和内存使用情况 | 服务器资源余量 | 攀登而永不复返的记忆 |
| 数据库连接和线程 | 泳池耗尽 | 数量持续增长，却未释放 |
请将平均值和百分位数一起阅读。 平均延迟 800 毫秒，第 95 百分位数为 900 毫秒，表明系统运行稳定。如果平均延迟 800 毫秒，第 95 百分位数为 9 秒，则意味着每 20 个用户中就有 1 个用户体验不佳，而平均值掩盖了这一问题。
注意形状，而不仅仅是数值。 在任何长时间运行的测试中，资源消耗曲线平稳表示测试通过，而资源消耗曲线上升则表示测试存在泄漏，即使在测试结束时绝对值仍然在限制范围内。
