当涉及到负载测试时,总是有一个价值百万美元的问题,“就性能而言,客户希望用他们的 应用程序和系统做什么? 我敢肯定,你永远不会得到一个简单的答案,这个问题,我们大多数人总是假设一些事情,并执行性能测试,这可能最终错过测试关键部分,最终与一个不满意的客户。 不满意的客户意味着您的组织失去业务,以及绩效工程师的职业生涯不断下降。 但不要担心,在这篇文章中,我们将讨论创建一个清单,这将有助于你这些问题。
此清单更像是一个分步过程,您可以遵循并适应 您的性能测试生命周期。 在讨论的场景中,我们不能总是责怪我们的客户,因为最初他们可能不知道他们想要的确切性能结果,但他们清楚地了解应用程序在不同条件下的工作方式。 一个好的绩效 测试 人员可以通过定义明确的问卷来管理这种模糊性。 这是清单上的第一个项目,即需求收集问卷。
需求收集问卷
以下是您可以在项目中遵循的调查问卷格式。 我们需要为这些问题获得尽可能多的答案。 如果你能打电话讨论这些问题就更好了。 确保应用程序架构师或开发人员与您和客户端一起加入呼叫。 拥有额外的人员可以帮助提供洞察力和发现您以前可能没有考虑过的问题。 下面的问题为您提供了创建更高效、更有效的负载测试的路线图。
不 | 主题 | 问题 |
1 | 应用 | 要考虑用于测试的应用程序类型(例如,Web 应用程序/移动应用程序等)。 |
2 | 应用程序架构和技术/平台。 | |
3 | 使用负载平衡技术。 | |
4 | 客户端和服务器之间的通信协议(例如:HTTP/S、FTP)。 | |
5 | 性能测试目标。 要监视的性能指标(例如,每个操作的响应时间、并发用户等)。 | |
6 | 性能测试需要考虑的关键方案。 | |
7 | 后台计划作业/流程的详细信息(如果有)。 | |
8 | 用于会话管理和支持的并行会话数的技术。 | |
9 | 客户 SLA/要求 | 预计并发用户数和总用户群。 作用域中方案的用户分布。 |
10 | PT 范围内的所有事务的 SLA(预期吞吐量、响应时间等)。 | |
11 | 要执行的性能测试类型(负载测试、耐久性测试等)。 | |
12 | 系统/环境 | 测试环境详细信息(Web/应用/数据库等,以及节点数)。 建议使用生产环境执行性能测试。 |
13 | 生产环境和性能测试环境的比较。 | |
14 | 是否在性能测试执行期间隔离应用程序以避免与其他应用程序的交互。 | |
15 | 内置日志记录机制或监视机制的详细信息。 | |
16 | 别人 | 应用程序性能基线结果。 |
17 | 当前性能问题(如果有)。 |
这些问题的答案将帮助您创建质量测试策略/测试 计划。 如果客户端无法提供所有这些问题的答案,则无需担心。 我们随时可以探索测试的应用程序并找到答案。 例如,如果 APM/log 工具已到位,我们可以从生产系统中获取 并发用户、吞吐量和响应时间。 永远不要假设你会得到你需要的不问。
查找合适的性能测试工具
性能测试人员应仔细选择最佳性能测试工具。 在最终确定和提出该工具之前,需要考虑许多因素。 请记住,在 选择性能测试工具时,客户预算始终是一个主要因素。
如果你正在寻找一个性能测试工具,是经济高效,易于使用,可以提供一个完整的性能解决方案,你绝对应该尝试负载 视图。 与传统的负载测试工具相比,LoadView 不需要任何昂贵的投资、耗时的设置或以前的脚本 框架知识。 此外,该平台还提供 20 多个全球位置,以旋转负载喷油器,因此您可以在每次测试期间从多个位置测试和测量性能。
所有类型的性能测试都需要时间和精力。 执行负载测试可以拯救组织免受潜在的羞辱,但同时对免费开源工具(如 JMeter)进行测试并不能证明投资的合理性。 当涉及到从最终用户的角度真正了解网站或应用程序性能时,基于协议的 测试是不够的。 您还必须测量客户端交互和步骤的性能。 下面是 LoadView 与其他性能/负载测试解决方案的比较 ,以及为什么要选择 LoadView 以满足性能测试要求。
当涉及到缓慢的加载站点和应用程序,客户可能会很快变得不耐烦,并离开,并找到一个替代,如果您的网站/应用程序不符合他们的期望。 由于各种原因,了解您的网站/应用程序可以处理多少非常重要,但 LoadView 平台可以协助使用以下几种重要方案:
- 适应性和可扩展性。 确定当多个用户访问网站或应用程序时,网站或应用程序会变慢的原因。
- 基础设施. 了解需要哪些硬件升级(如果有)。 实施额外的硬件和维护它的成本可能是潜在的资源浪费。
- 性能要求。 您的网站或应用程序可以正确处理少数用户,但在实际情况下会发生什么?
- 第三方服务。 了解在正常甚至峰值负载条件呈现时外部服务的行为。
性能测试计划/策略
一旦您收集了客户的要求并选择了合适的性能测试工具,我们需要记录我们的测试计划/测试策略。 在开始任何性能活动之前,请确保从客户端获取测试计划签号。 这是非常重要的,它将有助于你避免任何不必要的故障以后。 这些是需要包含在测试计划中的一些要点。
- 性能测试目标。 我们要达到的目标。
- 项目范围。 项目的范围是什么,例如: 脚本数量,我们需要测试多长时间等。
- 应用程序体系结构。 应用程序详细信息此类应用服务器、数据库服务器,如果您有,可以包括体系结构关系图。
- 环境详细信息。 有关我们将要测试的环境的详细信息。 有一个隔离的环境进行性能测试总是好的。
- 基础设施设置。 性能测试的初始设置(例如,云环境、工具安装等)。
- 性能测试方法。 我们如何进行测试。 我们应该从数量较少的基线测试开始,然后逐步增加用户,执行不同类型的测试,如压力、耐力等。
- 进入和退出标准。 这一点非常重要。 当没有功能缺陷时,我们应始终开始性能测试。 同样,我们应该记录何时可以停止性能测试。
- 缺陷管理。 我们应遵循客户端遵循的相同工具和实践,以记录与性能测试相关的缺陷。
- 角色和责任。 在性能测试期间参与不同活动的股份持有人的详细信息。
- 假设和风险。 如果存在可能危及性能测试的目标,我们应将其记录下来。
- 测试数据策略。 有关测试数据策略以及如何提取它的详细信息。
- 测试计划时间表和关键交付。 脚本编写、测试执行、分析和交付结果的时间表,用于客户端审阅。
实际的性能测试依赖于 多种技术的组合。 为了实现预期目标,我们需要针对不同的性能测试要求制定不同的策略。 在规划负载之前,需要考虑不同的指标,如用户负载、并发用户、工作负载模型等。 如果你以前做过工作量建模,你就会听说过 利特尔定律。 在计划测试以获得预期结果之前,您应该先了解并实施它。
实时性能脚本/方案
一旦我们与客户就性能计划/战略达成协议,我们就开始使用商定的性能测试工具编写脚本。
以下项目是我们需要记住的一些要点,以建立高质量的脚本:
- 执行脚本时,始终使用记录的测试用例步骤。
- 对单个用户进行重播和更正相关要求。
- 对单个用户进行重播并更正参数化要求。 参数化可以是标题、cookie 和正文参数的任意位置。
- 脚本成功使用单个用户数据后,使用不同的用户运行多个迭代。 不同的用户数据可能需要额外的关联/参数化。
- 在某些情况下,要实现某些使用案例,我们可能需要编写代码块。 例如,为用户选择特定的响应数据并操作它到另一个请求。
- 根据工作负载模型为脚本添加思考时间、起搏、错误处理。
- 文本检查/图像检查在脚本中也非常重要。
除了上述步骤外,还需要模拟缓存/cookies 和网络条件。 一个好的性能工程师在开始执行之前应考虑所有这些因素。 性能测试工程师还应开发最真实的虚拟用户行为模式。 为此,通过需求收集调查问卷获得正确答案至关重要。
- 假设每个工作时间的平均用户数,使用该应用程序的用户总数是多少?
- 用户执行哪些操作以及执行一次操作?
- 在加载高峰期,有多少用户正在使用该应用程序?
可以通过需求收集调查问卷或借助网络分析工具(如 APM 工具/Google 分析)收集的统计数据获得上述问题的答案。 交易分析允许查找重要的业务交易并设计用于性能测试执行的性能测试场景。
工作负载建模
我们可以以不同的方式规划我们的工作负载模型。 在选择工作负载模型之前,性能工程师应学习和实践”小定律”的概念。 以下是一些现有的工作负载模型。 同样,性能工程师应该根据手头的要求选择工作负载模型。
工作负载模型 1。 这只是一个简单的模型,随着测试的进行,用户数量将不断增加。 示例:在测试完成之前,每秒钟一个用户。
工作负载模型 2. 在此模型中,用户数将增加,就像整个测试持续时间的一个步骤一样。 例如,前 15 分钟为 100 个用户,后 15 分钟为 200 个,等等。 我们可以计划这种类型的耐力测试测试。
工作负载模型 3. 这是最常见的性能测试模型。 用户数量将在一定时间内持续增加(我们称之为提升期)。 之后,用户将在一定持续时间内保持稳定状态。 然后,用户将开始向下斜坡,测试将完成。 例如,如果我们计划进行 1.5 小时的测试,我们可以给 15 分钟来增加用户,15 分钟用于斜坡向下。 稳定状态为一小时。 当我们分析结果时,我们将只考虑稳定状态。
工作负载模型 4. 在此模型中,用户数量将在整个持续时间内突然增加和减少。 这种类型的测试有不同的名称,如猴子测试,尖峰测试等。
我们需要为性能测试建立一套全面的目标和要求。 定义性能测试参数,以及每个参数的接受标准。 如果您既不知道测试要求,也不知道所需的 结果,那么性能测试就是浪费时间。
收集数据
以下是在性能工作负载建模过程中要观察的一些非常重要的指标。
响应时间: 响应时间是服务器响应客户端请求的时间。 影响服务器响应时间的因素很多。 负载测试将有助于发现和消除那些降低响应时间的因素。
平均响应时间: 这将是负载测试中整个稳定状态持续时间的响应时间平均值。
90 百分位响应时间: 第 90 个百分位响应时间意味着 90% 的响应时间低于该值。 例如,如果您有 500 个请求,并且每个请求的响应时间不同,则第 90 个百分位数是任何其他值的 90% 低于 90 百分位的任何值。 只有 10% 的响应时间将高于 90 百分位值。 如果某些请求具有巨大的响应时间,并且它们扭曲了平均响应时间结果,则此功能非常有用。
每秒钟的请求数: 我们需要从 APM 工具或借助生产日志查找此值。 根据并发用户,我们可以计划对服务器的秒请求。
内存利用率: 这些是基础架构端指标,可帮助您发现瓶颈。 此外,您应该尽可能实时地规划您的工作量。 确保我们没有用连续的请求轰炸服务器。
CPU 利用率: 与内存相同,在运行性能测试时需要关注此指标。
错误率: 我们应该跟踪通过/错误交易比率。 错误率不应超过已传递事务的 2%。 如果错误率随着并发用户的增加而增加,则可能是潜在的瓶颈。
并发用户: 我们需要从 APM 工具或借助生产日志查找此值。 通常,我们根据典型的工作日找到此值。
吞吐量: 吞吐量将显示处理并发用户的服务器容量。 并发用户与吞吐量之间有直接连接。 吞吐量应随着访问应用程序的用户数量的增加而增加。 如果吞吐量随着用户数量的增加而下降,则可能是瓶颈的迹象。
用户负载分布: 用户负载分布是设计工作负载时需要考虑的重要因素之一。 如果我们有五个脚本执行应用程序的五个不同功能,我们需要根据我们对生产或 APM 工具的调查,将用户负载拆分为实际值。
这些是我们在设计工作负载模型时应该记住的非常重要的指标。 将还有其他指标,以及取决于客户端应用程序体系结构和要求。
性能测试环境清单(执行前)
下面的清单示例通常遵循企业级端到端性能测试,其中涉及大量系统。 始终建议遵循环境清单进行 小规模性能测试。 活动将因应用程序环境而变化,因为当我们将其与云上的应用程序与本地应用程序进行比较时,活动会有很大的不同。
结论:负载测试准备清单
成功的软件性能测试不是偶然发生的。 在评估软件之前,建筑师、产品所有者、开发人员和性能测试团队必须共同努力并解决性能测试要求。 有关 LoadView 平台上的更详细背景,请阅读我们的 技术概述 文章,了解如何最大限度地利用您的性能测试。 性能测试应该是一个持续的过程。 当您的网站或 Web 应用程序开始增长时,您需要进行更改以适应更大的用户群。 在任何应用程序和测试中,始终存在改进的机会。
我们希望这能让您深入了解性能测试的最佳实践。 如果您想全面演示 LoadView 解决方案,请与性能工程师 一起注册演示 。 它们将带您逐步完成流程的每个部分,从创建负载测试脚本和测试配置,到测试执行和结果分析。
或注册 加载视图免费试用 版,立即开始运行负载测试。 我们将为您提供免费的负载测试以开始使用! 负载测试愉快!