大家好,我是阿萨。昨天的负载测试只包含概念介绍。今天继续。
方法
在我们开始负载测试之前,我们需要了解是否已经对系统进行了负载测试。如果之前有做过任何负载测试,那么我们需要知道响应时间是多少,收集到的客户端和服务器指标是多少,用户负载能力是多少等等。
此外,我们还需要了解当前应用程序的处理能力如何。如果是一个新的应用程序,我们需要了解需求,目标负载是什么,预期的响应时间是什么,以及它是否真的可以实现。
如果它是一个现有的应用程序,你可以从服务器日志中获得负载要求和用户访问模式。但如果它是一个新的应用程序,那么你需要联系业务团队来获得所有的信息。
一旦我们有了需求,我们就需要确定我们将如何执行负载测试。是手动完成还是使用工具?手动做负载测试需要大量的资源,而且也非常昂贵。此外,重复测试,一次又一次,也会很艰难。
因此,为了克服这个问题,我们可以使用开放源码工具或商业工具。开源工具是免费的,这些工具可能不具备其他商业工具的所有功能,但如果项目有预算限制,那么我们可以选择开源工具。
而商业工具有许多功能,它们支持许多协议,而且非常方便用户使用。
我们的负载测试方法将如下。
1) 确定负载测试的验收标准比如说:
即使在最大负载条件下,登录页面的响应时间也不应该超过5秒。
CPU利用率不应超过80%。
系统的吞吐量应该是每秒钟100个交易。
2) 确定需要测试的业务场景。不要测试所有的流程,尝试了解预计在生产中会发生的主要业务流。如果它是一个现有的应用程序,我们可以从生产环境的服务器日志中获得他的信息。
如果它是一个新建立的应用程序,那么我们需要与业务团队合作,了解流程模式、应用程序的使用等。有时,项目组会举行研讨会,对应用程序的每个组件进行概述或详细介绍。
我们需要参加应用研讨会,并注意所有需要的信息,以进行我们的负载测试。
3)工作负载建模一旦我们掌握了关于业务流、用户访问模式和用户数量的细节,我们就需要以这样的方式设计工作负载,即模仿生产中的实际用户导航,或者在应用进入生产后的预期。
在设计工作负载模型时,需要记住的关键点是看一个特定的业务流需要多少时间来完成。在这里,我们需要以这样一种方式来分配思考时间,即用户将以一种更现实的方式来浏览整个应用程序。
工作负荷模式通常会有一个斜坡上升、斜坡下降和一个稳定状态。我们应该慢慢地对系统进行加载,因此要使用斜升和斜降。稳定状态通常是一个小时的负载测试,上升15分钟,下降15分钟。让我们举一个工作负荷模型的例子。应用程序的概述 - 我们假设一个在线购物,用户将登录到应用程序,有各种各样的衣服可供选购,他们可以在每个产品上导航。要查看每个产品的细节,他们需要点击产品。如果他们喜欢该产品的成本和制作,那么他们可以添加到购物车,通过结账和付款来购买该产品。下面列出了一些情况。浏览 - 在这里,用户启动应用程序,登录到应用程序,浏览不同的类别并退出应用程序。浏览,产品查看,添加到购物车 - 这里,用户登录应用程序,浏览不同的类别,查看产品细节,将产品添加到购物车并退出。浏览、查看产品、添加到购物车和结账 - 在这种情况下,用户登录应用程序,浏览不同的类别,查看产品的详细信息,将产品添加到购物车,进行结账并退出。浏览,查看产品,添加到购物车,结账和付款 - 在这种情况下,用户登录到应用程序,浏览不同的类别,查看产品的详细信息,将产品添加到购物车,进行结账,付款并退出。
S.No | 业务流程 | 交易数量 | 虚拟用户负载 | 响应时间(秒) | 允许的故障率% | 每小时交易量 |
1 | 浏览 | 17 | 1600 | 3 | 低于2% | 96000 |
2 | 浏览,产品查看,添加到购物车 | 17 | 200 | 3 | 小于2% | 12000 |
3 | 浏览、产品浏览、添加到购物车和结账 | 18 | 120 | 3 | 少于2% | 7200 |
4 | 浏览,查看产品,添加到购物车,结账,付款 | 20 | 80 | 3 | 小于2% | 4800 |
上述数值是根据以下计算得出的。
每小时交易量=用户数*单个用户在一小时内的交易量。
用户数=1600。
浏览方案中的交易总数=17。
每个交易的响应时间=3。
单个用户完成17个交易的总时间=17*3=51,四舍五入为60秒(1分钟)。
每小时的交易量=1600*60=96000次交易。
4)设计负载测试 - 负载测试应该根据我们到目前为止收集的数据来设计,即业务流、用户数量、用户模式、要收集和分析的指标。此外,测试应该以一种非常现实的方式设计。
5)执行负载测试 - 在我们执行负载测试之前,确保应用程序已经启动并运行。负载测试环境已经准备好了。应用程序在功能上经过测试,并且是稳定的。检查负载测试环境的配置设置。它应该与生产环境相同。确保所有的测试数据是可用的。确保添加必要的计数器,以监测测试执行期间的系统性能。总是从低负载开始,逐渐增加负载。不要从满负荷开始,破坏系统。
6) 分析负载测试结果 - 有一个基线测试,以便与其他测试运行进行比较。在测试运行后收集指标和服务器日志,找到瓶颈。一些项目在测试运行期间使用应用性能监测工具来监测系统,这些APM工具有助于更容易地确定根本原因,并节省大量时间。这些工具非常容易找到瓶颈的根本原因,因为它们有一个广阔的视野,可以准确地指出问题所在。市场上的一些APM工具包括DynaTrace, Wily Introscope, App Dynamics等。
7)报告 - 一旦测试运行完成,收集所有的指标,并将测试总结报告连同你的意见和建议发送给有关团队。
最佳实践
下面列出了一些负载测试的最佳实践。
1)在开始负载测试之前,一定要检查应用程序的稳定性。应用程序应该由功能测试团队签署功能稳定,所有的主要缺陷应该在构建复制到负载测试环境之前被修复和测试。
2)确保负载测试环境是一个副本或接近生产环境,包括服务器的数量、负载平衡器、服务器配置和防火墙。
3) 检查测试数据是否是唯一的,在进行负载测试之前,我们已经把所有的测试数据复制到了负载环境中。
4)设计测试场景,使其模仿生产中发生的实时用户操作。
5)根据生产中的用户负载和业务流来设计工作负载,如果是一个旧的应用程序,看看它是否是一个新的与业务团队讨论的业务流和用户负载。
6)收集所有重要的指标,如响应时间、每秒点击量、吞吐量、Cpu、内存、网络和运行中的Vusers。
推荐市场上可用于进行独家负载测试的性能测试工具列表。
总结
在本教程中,我们已经了解到负载测试在应用程序的性能测试中如何发挥重要作用,它如何帮助了解应用程序的效率和能力等。
我们还了解到它如何帮助预测应用程序是否需要任何额外的硬件、软件或调整。