性能测试中最容易被误解的部分之一就是负载测试。大多数人认为所有性能测试就是负载测试,但这是不准确的。有许多类型的测试组成性能测试。
负载测试是许多并发用户运行同一程序,以查看系统基础结构是否在不影响功能或性能的情况下处理了负载。
以下是准备进行负载测试时要考虑的N种策略。
针对正确的测试量
首先,不要在没有实际需要的情况下进行大规模测试。无需向软件施加超出实际预期的压力。
当然产生环境比预期拥有更高的流量负载始终是一件好事,但要保持现实和高效,应该专注于评估应用程序在生产中将遇到的正确工作负载。
以方便取决于周期性性事件,网站或APP可能会在一个以上高峰或高峰负载时间内遇到流量峰值。但是建议在着重负载测试之前首先通过模拟或者监控正常一天的吞吐量来开始负载测试。
这里的关键词是吞吐量,这是另一个经常被误解的性能测试。系统吞吐量是指系统在单位时间内所处理的信息量,它以每小时或每天所处理的进程数来度量。
提出工作负载事务测试配置时,请考虑以下事项:
平均而言,一个典型的小时内执行多少次操作。高峰期呢?
该测试的目的是什么?
您的服务器或数据库活动规律通常是什么样的?
在选择要模拟的任务时,是否专注于对业务最大风险的任务?
将跟踪或需要哪些具体指标?
花一些时间正确执行此步骤,因为它是创建适当的负载测试的基础。
负载生成器
确保负载生成器准备好承受工作量。负载生成器就是运行虚拟用户测试的计算机。虚拟用户可以采用脚本或者应用软件,其行为与真实用户同时向被测应用程序和系统发出请求时的行为一样。
这里有一些要考虑的事情:
从计算机中暂停不需要的任何软件。
确认已连接到网络并具有足够的网络带宽等。
如果要运行许多虚拟用户,则需要许多负载生成器。
了解所有这些都是很重要的,因为如果过度利用负载生成器本身,则始终存在风险,可能会导致测试结果的不可靠。
编写脚本
仅创建一个模拟实际场景的测试是不够的,还需要确保脚本不会使测试工具本身过载。
确保已针对测试方案优化了设置、时间、运行时间、选择监视器和记录的信息量等,这些因素在负载测试过程中至关重要。
考虑需要参数化的任何硬编码或动态数据,排除由于脚本编写不当而导致生成无效的测试的代码。确保生成正确数量的数据,并按照测试计划执行测试方案。
用户思考时间
思考时间是脚本逻辑的重要组成部分。所有工具都应具有通过指定希望虚拟用户等待多少秒来增加思考时间的逻辑。
思考时间对于根据虚拟用户的实际行为模仿正确的工作负载很有用。不能正确利用思考时间是另一个常见的性能测试错误。
人们要么忘记添加它们,要么设置花费花费几毫秒。负载测试确实需要创建一个实际的测试方案,以模拟真实用户将如何与软件进行交互。查看一下该工具,然后问确认:在此页面上做出决定需要多加?执行相关操作需要多久?
监控和诊断
进行大型负载测试时,肯定需要考虑监视和诊断。
在正常测试期间捕获的诊断信息意味着将捕获大量数据。但是,对于具有许多虚拟用户的测试,捕获的数据可能会有很多困难。这样做的副作用是测试工具可能难以应对所有这些信息。
性能监视也是如此。许多测试方案选择看似随机的测量值,却不知道每个计数器的功能,甚至不知道是否需要监视它,更不用提如何记录、统计这些数据。
一般来说,捕获尽可能多的监视数据并不是一个坏主意,但是要最大程度地减少收集的测试数据,仅选择基本性能计数器至关重要。
在执行负载测试时,需要省去一些麻烦的过程,并坚持使已经有成功经验的统计工具,以后再使用它们来解决和隔离性能问题。
分析测试数据
准备分析您的负载测试数据。测试时间越长,在测试过程中捕获的事件数量就越多,并且无论使用何种工具,对其进行分析都将更具挑战性。
负载测试会生成大量数据。深入研究测试结果并找到所需的一切并不容易。即使有一种简单的方法来分析数据(或自动分析),它仍然是一个非常具有挑战性的过程。
需要提前预估有关如何处理此问题,然后指定相关的计划。软件数据的错误分析会产生错误的结果。如果没有正确分析数据,不能着急下结论。从负载测试产生的数据中提取相关结论需要经验和技巧。
下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
每个人都有机会成为自己想要成为的样子,只需要不断努力和坚定信念,就能够迎接成功的到来。无论遇到什么困难和挑战,都要勇敢面对,因为你的努力和坚持最终一定会得到回报。
只要你有一份真正想做的事业,就要为之奋斗到底;只有经历过磨难和挫败,才能获得真正的成功;不要让失败打败你,坚持下去才是胜利的关键。
只要你有梦想和决心,就能超越自我、突破困难。不要停下脚步,朝着目标努力奋斗,成功就在前方等待着你。每一次的挑战都是成长的机会,相信自己,坚持到底,你一定会收获辉煌的人生。