想要创建一个性能测试计划?在决定模拟负载之前,有一些事情需要考虑。

当谈到如何制定性能测试计划时,我指的不是一个文档,而是我们在分配给测试的时间内要执行什么,以便在运行尽可能少的执行之后能够回答有关系统性能的问题。

首先,有必要知道我们将回答什么样的问题从测试的结果。以下是一些最常见的例子:

  • 压力测试在可接受的用户体验下,系统支持的最大并发用户数是多少?突破点是什么?
  • 负荷试验考虑到当前的系统负载场景,应用程序将如何运行?对于预期情景,我们看到了哪些改进机会?
  • 耐久性试验系统运行一段时间后(比如一整天后)将如何工作?(在某些情况下,这包括每天晚上重新启动服务器,直到找到系统中存在的某些泄漏的最终解决方案。听起来很糟糕,但这可能会发生!)
  • 峰值测试如果我的正常系统正常工作,并且出现了一个压力峰值(这种机动性使得在同一时间匹配的请求比正常情况更多,这意味着响应时间可能会变得比可接受的更差),那么系统恢复的速度有多快?

性能测试类型

在任何情况下,关于性能测试,我们总是会遇到一个问题:主要的瓶颈是什么?然后,我如何解决这些潜在的问题或限制?我们甚至会有这样的问题:

  • 我的团队是否准备好在生产中发生类似的事情,还是我需要学习其他东西?
  • 我们以多快的速度找到性能问题的解决方案?
  • 我有哪些物质资源可用,或者获得这些资源有多困难?

有了这些问题,我们已经有很多工作要做了;通常有必要检查系统访问日志,以了解每天连接的用户数量,或者我们必须估计和询问我们希望有多少用户。在设计测试时,这被进一步细化,因为有必要调查每个用户做什么(什么测试用例,什么数据,等等)。

在这篇文章中,我想重点讨论的是:一旦我知道预期的负载是什么,我如何运行负载场景?

性能测试计划:我要运行多少并发用户?

有一件事我已经重复了很多次了(肯定是真的!):如果我们设计/定义了X数量的用户的负载场景,我们就不能从运行一个模拟全部数量并发用户的测试开始。如果我们这样做,正如经验告诉我们的那样,几个问题肯定会同时出现,我们不知道从哪里开始——因此,对我们的性能测试计划应用增量的、迭代的方法的想法。

它是迭代的,因为执行了不同的测试迭代,并且是增量的,因为我们从减少并发用户开始,解决出现的问题,并在进行过程中增加并发性。

例如:负载测试

我们将在第一个示例中考虑负载测试,其中测试的目的是分析系统是否支持1000个并发用户。

  1. 第一个测试:1个没有并发的用户这可以作为以后比较的基线;它可以是1、5、10,或者更多,但它必须比系统中实际期望的低得多)。
  2. 第二次测试:200个并发用户(或预期负荷的20%)。在这里,你可以得到很多信息,特别是关于按时完成测试有多困难以及以什么方式完成测试。

在执行这些初始测试时,我们将解决较重的问题和默认配置(例如连接池或Java堆大小),并且我们将了解如何通过比较响应时间和基线来扩展系统。完成分析和故障排除后,将反复运行此测试,直到获得可接受的时间。

根据这些结果的紧密程度,我们将决定第三个测试是40%(继续增加20)还是50%的负载(考虑增加75和100)。另一方面,如果系统的反应非常好,我们可能会被鼓励直接去做更多。在任何情况下,我们希望在最后得到的是一个图表,它向我们展示每个测试获得的响应时间(预期负载的每个百分比),这样我们就可以看到系统是如何由于我们的工作而发展的。

计划- de -功能- de -性能- resultados - 768 - x553

在这个示例图中,我们看到如何执行不同的测试,将负载增加20%。此外,很容易观察到测试是重复的,直到在每种情况下都达到预期的SLA,并且在达到SLA后立即采取下一步。

例如:压力测试

作为第二个示例,假设我们希望通过压力测试找到系统的断点。为此,我们希望对不同数量的用户执行不同的测试,分析提高并发性是否会继续提高吞吐量。如果增加并发性不会增加每秒的事务数,则表明我们达到了断点,因为它在某个点使系统饱和,而没有扩展。

如果我们开始使用随机数量的用户进行测试,这就像蒙住我们的眼睛,我们会损失很多时间。我们认为最好的策略是运行一个我们称之为探索性性能测试的测试,因为我们运行它来获得断点在哪里的初步想法。为此,我们运行一个从0到X的增量测试,其中X是大量用户(假设一个负载发电机有1000个用户),我们认为破坏必须在这个范围内。

能做些什么在任何运行测试负载仿真工具建立统一的过渡期间,测试时间——也就是说,如果我们想要测试的最后一个小时,我们设置测试并发用户为零的开始,一个小时后,有1000人。在这里,我们将能够有一个第一个近似,看看什么时候系统的吞吐量下降。如果我们观察到它大约有650个用户,我们就可以开始改进,为这个目标运行特定的测试。

例如,我们可以用500运行一个测试,用600运行另一个测试,用700运行另一个测试。如果700个用户的测试的吞吐量实际上小于600,那么我们必须改进并执行一个650用户的测试,因此我们继续使用中点来提高准确性。

例如:耐力测试

对于一个耐力测试,我会说在可接受的条件下运行一个恒定的负荷,介于系统所承受负荷的50-70%之间。在这种情况下,更小的负载也可以为我们服务,这完全取决于准备测试数据以使其运行数小时的复杂程度。

通常,这些测试在压力或负载测试完成后执行,以试图识别其他类型的问题(内存泄漏、挂起连接等)。如果您有时间、数据和为此所需要的东西,您可以增加用于测试的负载,长时间运行它们。

示例:峰值测试

对于峰值测试,正如我们前面所说的,其目的是查看在峰值发生后恢复系统所需的负担。如果出现峰值,那么系统是否正确响应或挂起?10秒后,它恢复了吗?两小时后?还是怎样为此,有必要知道系统的断点,以便能够准备低于该阈值的测试,并通过提高负载一分钟,然后再降低负载,生成峰值。

这里可以应用的增量方法是在峰值本身。您可以先试验小的峰值(短时间或低负载),然后研究系统如何对较大的峰值做出反应。在任何情况下,这都应该基于对用户行为的研究进行建模,特别是基于您可能拥有的访问日志。

结论

如何制定性能测试计划依赖于特定类型的测试你会基于运行特定的关于你的系统,你想回答的问题,但它们都有一个共同点:我们想要减少我们执行的测试,优化测试的成本和收益。为此,我们的想法是遵循一种迭代的、增量的方法(用于负载、耐力和峰值测试)和一种改进方法(用于压力测试)。

你对此有何看法?让我在下面知道你的经历!


在性能测试方面寻求帮助?我们的100多名质量工程师团队可以提供帮助!请立即与我们联系。


推荐给你

何时是开始性能测试的最佳时间?
Apptim Review:移动性能测试工具

连续测试指南