基于目标的性能测试



基于目标的性能测试是软件测试(尤其是性能测试)中采用的一种策略,以确保软件系统在各种条件下满足特定的性能目标。 在基于目标的性能测试中,测试过程是由预定义的目标或目的驱动的,而不仅仅是为了测试而测试。

基于目标的测试使用以下步骤工作:

  1. 定义绩效目标: 第一步涉及定义哪些性能目标对被测试的软件系统很重要。 这些目标可能包括响应时间阈值、吞吐量要求、资源利用率目标和可伸缩性基准。
  2. 设计测试场景: 测试方案是根据您定义的性能目标设计的。 这些场景模拟不同的用户行为、负载和系统配置,以评估软件在各种条件下的性能。 例如,方案可能包括高峰使用期、繁重的事务负载或用户活动的突然激增。
  3. 执行测试: 根据测试要求,针对软件系统执行测试场景。 在此阶段,将测量和监控响应时间、吞吐量、资源利用率和系统可伸缩性等性能指标。
  4. 分析结果和改进: 对收集的性能数据进行分析,以评估系统是否满足预定义的目标。 此分析有助于确定性能瓶颈、可伸缩性限制以及系统可能无法满足性能要求的区域。 根据测试结果分析,对您的软件系统进行任何必要的改进和优化。
  5. 重复该过程: 基于目标的性能测试是一个迭代过程。 进行改进后,将重复测试周期,以验证是否已实现性能目标,并确定可能出现的任何新性能问题。

性能测试主要侧重于检查应用程序的速度和可靠性,分为负载测试(面向目标)和压力测试。 随着敏捷开发方法的兴起,确保负载测试结果可以轻松重现变得至关重要。

 

定义绩效目标的重要性

定义性能目标是基于目标的性能测试的基石。 这些目标是衡量软件性能的标准。 它们提供了一个有形的框架,用于评估软件在各种条件下是否满足其性能要求,包括正常使用、峰值负载和压力场景。

 

基于目标的性能测试的关键原因

  • 与利益相关者的期望保持一致: 通过定义特定的性能目标,可以确保软件的性能符合利益相关者(包括最终用户、客户和项目发起人)的期望。
  • 验证性能要求: 基于目标的测试有助于验证软件是否满足其性能要求,并提供具体指标来评估性能充分性。
  • 优化资源利用率: 基于目标的测试通过识别系统资源的低效或过度利用来帮助优化资源利用率,从而实现更有效的资源分配和成本节约。
  • 可扩展性: 通过测量负载增加或用户并发性下的性能,基于目标的测试可以评估软件的可伸缩性,确保它能够处理不断增长的用户群和工作负载。
  • 降低风险: 根据预定义的性能目标进行主动测试有助于在部署软件之前识别和缓解与性能相关的风险,从而减少停机、用户不满或财务损失的可能性。

 

基于目标的用例:问题

假设 20 个并发用户在新的 CRM 应用程序中每小时生成 2,000 个事务。 您的目标是设计一个性能测试,确保接下来的四个版本的响应时间为 8 秒。 压力测试可能无法精确复制这些即将发布的版本中的预期吞吐量,因为响应时间可能与当前版本不同。

 

基于目标的用例:解决方案

  1. 将 ThinkTimes 集成到您的脚本中,以在用户操作之间引入暂停。
  2. 确定基线并测量单用户脚本的运行时以计算会话时间。
  3. 配置工作负载参数,包括最大用户数、基于目标的事务速率和基于目标的事务时间。
  4. 执行基于目标的性能测试,以模拟应用程序上的预期负载。
  5. 查看测试报告,验证应用程序是否设法在预定义的响应时间范围内处理负载。
  6. 在随后的四个版本中重复测试运行,以评估应用程序是否在一段时间内保持吞吐量和响应时间阈值。

 

配置 LoadView 的每个步骤工具的建议和提示

ThinkTime(必填):

  • 在 The EveryStep Web Recorder (ThinkTimes) 中创建新关键字或重用现有关键字。
  • 确保允许的值为浮点 0.0 – 999.99。
  • 允许用户手动将 ThinkTimes 添加到脚本中。
  • 请记住,ThinkTimes表示等待时间,并在用户操作录制期间由每个步骤Web记录器自动添加。
  • 一个脚本中可以存在多个 ThinkTimes。
  • ThinkTimes 在单个脚本测试运行中被忽略。
  • ThinkTimes 将用于校准/获取基线。
  • ThinkTimes 对响应时间测量没有贡献。
  • ThinkTimes 在压力测试中被忽略。

用户并发(可选):

  • 在每个步骤 Web 记录器中引入新的“WaitFor (用户数)”关键字。
  • 此全局等待点阻止特定脚本部分的模拟用户,直到预期的用户数到达脚本的这一部分。

响应时间阈值(可选):

  • 在每个步骤 Web 记录器中实现新的 SetBoundary 关键字。
  • 语法:SetBoundary(Timername, Bound 1, Bound 2)。

基线/校准(必填):

  • LoadView 执行单个用户测试运行。
  • ThinkTimes 将按脚本使用。
  • LoadView 计算会话时间:会话时间 = 脚本执行时间 + ThinkTime。

配置工作负载/执行计划(必需):

  • 客户指定爬坡时间。
  • 客户定义他们的目标交易率。
  • 客户设定目标会话时间。
  • 系统计算用户数。
  • 客户决定是否在爬坡期间计算响应时间。

运行测试(必填):

  • LoadView 根据配置的工作负载/执行计划执行测试。
  • LoadView 收集模拟脚本或事务的响应时间。
  • LoadView 动态调整 ThinkTime 以实现预期吞吐量;如果被测应用程序速度变慢,则 ThinkTimes 会减少。 如果 ThinkTimes 为零且会话时间超过目标会话时间,则会引发一条错误消息,指示无法达到预期的吞吐量。
  • LoadView 计算实际事务和计时器的响应时间,无需思考时间。

 

与 Dotcom-Monitor 集成的建议和技巧

每步 Web 记录器

  • 引入新的 ThinkTime 关键字。
  • 在单用户测试运行期间忽略 ThinkTime。
  • 在脚本录制期间添加 ThinkTime。
  • 引入新的 WaitFor(Number user) 关键字。
  • 引入新的 SetBoundary(TimerName, B1, B2) 关键字。
  • 必须手动将 WaitFor 关键字添加到创建的脚本中。
  • 利用 SetBoundary 关键字。

校准/获取基线

  • 在校准期间计算会话时间。

执行计划/工作负载

选项 1:

  • 添加新的工作负载配置功能。
  • 将“执行计划”替换为“工作负载”功能。
  • 创建“工作负载配置”对话框以支持压力测试、事务目标和其他类型。
  • 指定爬坡时间。
  • 选中用于计算爬坡期间响应时间的框(是/否)。

选项 2:

  • 使用增强的执行计划配置功能。
  • 选择测试类型(压力、基于目标)。
  • 设置交易目标详细信息。
  • 指定爬坡时间。
  • 选中用于计算爬坡期间响应时间的框(是/否)。

运行测试

  • 计算实际脚本执行时间/会话时间。
  • 根据实际会话时间动态调整 ThinkTimes。
  • 如果无法达到预期的吞吐量,则发出警告。

报告

  • 为响应时间、每个计时器的实际阈值与阈值配置一个部分。
  • 配置吞吐量(实际吞吐量与预期吞吐量)部分。

 

与 Dotcom-Monitor 集成的提示:常见问题解答

什么是用户输入?

  • 思考时间(浮点 > ,0)
  • 每小时目标事务(整数)
  • 最大用户数(整数)
  • 上升时间(分钟)
  • 计算加速期间的响应时间(是/否)

 

什么是基线?

设备或脚本的单个用户执行,包括 ThinkTimes。 脚本执行时间被计算并存储为会话时间,以及其他详细信息,如所需的执行资源。

 

如果目标系统事务速度发生变化,如何动态调整负载测试?

  • 计算校准期间的会话时间
  • 使用 ThinkTimes 达到请求的目标会话时间
  • 在测试执行期间重新计算实际会话时间
  • 根据实际会话时间动态调整思考时间
  • 如果脚本执行时间是目标会话时间, > 则记录错误消息
  • 指定工作负载计算中的最大用户数

 

什么是等待关键字?

这模拟了复杂的用户方案,特别是并发情况,这对于测试某些功能在多个用户同时访问资源时是否正常工作非常有用。

 

什么是设置边界关键字?

帮助根据指定的 SLA 响应时间边界验证特定操作或计时器的实际速度。 如果违反了允许的边界,则会出现一条错误消息,并记录在测试报告中,从而简化 SLA 验证。

 

负载测试的目标是什么?

  • 确保在不同版本/执行之间进行 100% 可比的性能测试。
  • 包括用于模拟常规或峰值负载模式的功能。
  • 确保被测系统能够在商定的边界内处理预期负载。
  • 将性能优化重点放在违反商定边界的用户操作上。

 

您应该配置什么类型的报表?

  • 创建与当前报表类似的报表。
  • 包括平均值、最小值、最大值、标准值、百分位数响应时间。
  • 跟踪事务正常、事务失败和错误率。
  • 所有响应时间都应不包括 ThinkTimes。

 

限制

目标会话时间过长可能会导致会话超时和误报。 考虑 Web 会话超时较低的场景至关重要,确保 ThinkTimes 放置得当,以防止由于会话超时而导致故障。

 

如果我们没有达到目标会发生什么?

  • 如果负载测试中的应用响应时间变慢,会话时间超过目标会话时间,则无法达到预期的事务速率。
  • LoadView 在测试执行期间监控实际会话时间,并调整 ThinkTimes 以尝试达到预期的基于目标的事务速率。
  • 如果会话时间超过目标会话时间,LoadView 会在监视屏幕上显示错误消息。
  • 如果无法达到目标事务速率,LoadView 将继续执行测试,将测试运行标记为失败,并在报告中指示受影响的设备。

基于示例目标的工作负载看起来像什么?

脚本/设备

ST (秒)

不可编辑

消费税(秒)

用户输入

Tph

用户输入

用户

不可编辑

Search_User 25 10 500 72
Inser_User 25 60 1000 216
  • 加速时间:15 分钟
  • 测量斜坡期间的响应时间:是/否
    ST:会话时间
  • 消费税:目标会话时间
  • TPH:每小时交易
  • 用户: 按 LoadView 计算 (3600 / TPH ) * GST = 72