什么是软件测试中的耐力测试? (附示例)

⚡ 智能摘要

耐久性测试是指在正常预期负载下长时间运行应用程序,以检测其性能是否会随时间推移而下降。这种测试能够发现一小时负载运行无法触及的缺陷。

  • 🕒 持续负荷: 预计生产流量将持续数小时甚至数天,而不是几分钟。
  • 📉 退化焦点: 问题在于响应时间是否会逐渐延长,而不是目标是否能一次性达成。
  • 💧 常见发现: 内存泄漏、连接池耗尽以及日志或缓存无限制增长。
  • 📊 监控设置: 在整个运行过程中,内存、CPU、响应时间、吞吐量和数据库连接数。
  • 🛠️ 工具: 标准负载工具驱动流量,而 APM 工具记录资源曲线。
  • 权衡: 结果很有价值,但获取速度较慢,这限制了测试的运行频率。

什么是耐久性测试

什么是耐力测试?

耐力测试 是一种非功能性软件测试,在相当长的时间内以高负载测试软件,以评估软件应用程序在持续使用下的行为。耐久性测试的主要目的是确保应用程序有足够的能力处理延长的负载,而不会降低响应时间。

这种类型的测试是在性能运行周期的最后阶段进行的。耐久性测试是一个漫长的过程,有时甚至持续一年。这可能包括施加外部负载,例如互联网流量或用户操作。这使得耐久性测试不同于 负载测试,通常会在几个小时左右结束。

耐力意味着容量,换句话说,您可以将耐力测试称为容量测试。

耐力测试的目标

  • 耐久性测试的主要目标是检查内存泄漏。
  • 了解系统在持续使用的情况下的表现。
  • 确保经过长时间测试后,系统响应时间保持与测试开始时相同或更好。
  • 确定给定系统将支持并满足性能目标的用户数量和/或交易数量。
  • 为了管理未来的负载,我们需要了解需要多少额外资源(如处理器容量、磁盘容量、内存使用情况或网络带宽)来支持未来的使用。
  • 耐久性测试通常通过使系统超载或减少某些系统资源并评估后果来完成。
  • 执行此操作是为了确保在相对“正常”的使用期后不会出现缺陷或内存泄漏。

耐力测试中需要监测哪些方面

耐力测试

在耐力测试中,要测试以下事项。

  • 测试内存泄漏– 检查应用程序中是否存在内存泄漏,这可能会导致系统或操作系统崩溃
  • 测试系统各层之间的连接闭合 – 如果系统各层之间的连接未成功关闭,可能会导致系统的部分或全部模块停滞。
  • 测试数据库连接关闭成功– 如果数据库连接没有关闭成功,可能会导致系统崩溃
  • 测试响应时间 – 对系统响应时间进行测试,因为随着系统使用时间的延长,应用程序的效率会降低。

如何进行耐久性测试

以下是耐力测试的基本测试方法

  • 测试环境 – 确定耐久性测试所需的硬件、软件、操作系统,分配团队内的角色和职责等。在执行测试之前,环境应该准备好。您还需要估计常见的数据库生产规模和年度增长。这是必需的,因此您需要测试您的应用程序在一年、两年或五年后会如何响应。
  • 创建测试计划、场景 – 根据测试性质(手动、自动化或两者结合), 测试用例 应该规划设计、评审和执行。系统压力测试、断点测试等也应成为测试计划的一部分。系统压力测试决定了应用程序中的断点。
  • 测试评估 – 提供完成测试阶段需要多长时间的估计。应根据涉及的测试人员数量和所需的测试周期数进行分析。
  • 风险分析 - 分析风险并采取适当的预防措施。根据风险因素对测试用例进行优先排序,并确定测试人员在耐久性测试期间可能遇到的以下风险和问题。
  • 随着时间的推移,性能是否会保持一致?
  • 还存在其他尚未发现的小问题吗?
  • 是否存在未解决的外部干扰?
  • 考试安排 – 确定预算、在规定时间内交付的成果。 耐力测试 在一段连续的时间内对系统/应用程序应用巨大但自然的交易负载安排。

耐久性测试示例

压力测试 将测试系统推向极限, 耐力测试 将应用程序推向极限 随着时间的推移.

例如,内存泄漏、数据库服务器利用率过高以及系统无响应等最复杂的问题,通常会在软件长时间运行后出现。如果跳过耐久性测试,那么在部署前发现此类缺陷的几率就非常低。

耐久性测试工具

耐久性测试的优势

  • 它有助于确定系统在负载下能够处理多少工作负载。
  • 提供准确的数据,客户可以使用这些数据来验证或增强他们的基础设施需求。
  • 识别系统长时间高水平运行后可能出现的性能问题
  • 典型问题在较小规模的目标性能测试中被识别,这意味着它能确保即使在很短的时间内负载巨大的情况下应用程序仍然可用。
  • 耐久性测试还用于检查长时间执行后性能是否下降

耐久性测试的缺点

  • 通常很难定义值得施加多大的压力。
  • 耐力测试可能会导致应用程序和/或网络故障,如果发生以下情况,可能会导致严重中断: 测试环境 并不孤立。
  • 系统压力过大可能会导致永久性数据丢失或损坏。
  • 压力消除后,资源利用率仍然很高。
  • 某些应用程序组件无法响应。
  • 最终用户观察到未处理的异常。

此测试如何融入性能测试系列

性能测试是一个统称。以下列出的各种测试方法仅在施加的载荷形式和保持时间上有所不同,因此它们经常被混淆。

测试类型 负载模式 它解答的问题
负载测试 预计峰值负荷,持续时间短 在正常高峰交通流量下,该系统能否达到其目标?
压力测试 超出负荷直至失效 它会在哪里出现故障?故障发生时是否体面?
尖峰测试 突然的极端激增,然后是撤退 它能否在交通冲击后幸存并恢复?
耐力测试 正常负荷持续数小时 性能会随着时间推移而下降吗?
浸泡测试 长时间持续负荷 是否存在内存泄漏或资源耗尽?
稳定性测试 不同条件下的负载变化 随着环境变化,系统是否仍能保持可靠性?
容量测试 普通用户,数据量非常大 随着数据库的增长,它能否应对?

耐久性测试和浸泡测试经常被视为同义词。 通常来说,耐久性测试和负载测试都是长时间持续高负载运行的测试。如果团队确实区分这两者,耐久性测试侧重于响应时间是否会逐渐延长,而负载测试则侧重于内存、文件句柄和连接池等资源消耗。运行其中一项测试通常就能提供这两项测试的结果。

测试期间需要收集的关键指标

性能测试的质量取决于测试过程中记录的数据。请在服务器端和客户端分别记录这六项数据,然后将其与基准数据进行比较,而不是仅凭直觉判断。

米制 它告诉你什么 警告牌
平均响应时间 典型用户体验 任何向上的漂移都会影响跑步路线。
第 95 百分位响应时间 最慢用户的体验 远高于平均水平,意味着不稳定
生产能力 每秒处理的请求数 负载保持不变时发生坠落
错误率 失败或超时请求的占比 任何超过约定阈值的涨幅
CPU 和内存使用情况 服务器资源余量 攀登而永不复返的记忆
数据库连接和线程 泳池耗尽 数量持续增长,却未释放

请将平均值和百分位数一起阅读。 平均延迟 800 毫秒,第 95 百分位数为 900 毫秒,表明系统运行稳定。如果平均延迟 800 毫秒,第 95 百分位数为 9 秒,则意味着每 20 个用户中就有 1 个用户体验不佳,而平均值掩盖了这一问题。

注意形状,而不仅仅是数值。 在任何长时间运行的测试中,资源消耗曲线平稳表示测试通过,而资源消耗曲线上升则表示测试存在泄漏,即使在测试结束时绝对值仍然在限制范围内。

耐久性测试:主要结论

  • In 软件工程,耐力测试是负载测试的一个子集。
  • 耐久性测试是一个漫长的过程,有时甚至持续一年
  • 检查是为了验证
  • 测试内存泄漏
  • 测试响应时间
  • 测试数据库连接等。

常见问题

负载测试验证系统在短时间内峰值负载下是否能达到目标性能。耐久性测试则在正常负载下运行数小时,以检验这些目标性能在运行结束时是否仍然有效。

响应时间或资源使用量持续上升的任何趋势,即使没有突破任何阈值,都属于缺陷。这种趋势本身就是缺陷,因为它最终会在生产环境中突破极限。

功能测试和负载测试都通过后,并且时间足够早,以便及时修复发现的漏洞。如果在发布前一晚运行测试,则没有时间根据结果采取相应措施。

基于人工智能的监控能够检测指标趋势发生变化的点,并将其与部署或计划作业关联起来,从而将数小时的图表转化为具体的嫌疑对象。

它可以帮助确定优先级。风险模型会突出显示哪些版本会修改容易出现漏洞的代码,因此完整的测试运行时间会留给最有可能需要完整测试运行的更改。

总结一下这篇文章: