基于目标的性能测试

基于目标的性能测试是一种软件测试策略，特别是在性能测试中使用，旨在确保软件系统在各种条件下满足特定的性能目标。在基于目标的性能测试中，测试流程由预先定义的目标或目的驱动，而不仅仅是为了测试而测试。

基于目标的测试按以下步骤进行：

1. 定义性能目标：第一步是定义对被测试软件系统重要的性能目标。这些目标可能包括响应时间阈值、吞吐量要求、资源利用率目标和可扩展性基准。
2. 设计测试场景：根据您定义的性能目标设计测试场景。这些场景模拟不同的用户行为、负载和系统配置，以评估软件在各种条件下的性能表现。例如，场景可能包括高峰使用期、大量交易负载或用户活动的突发激增。
3. 执行测试：根据测试需求执行测试场景。在此阶段，测量和监控性能指标，如响应时间、吞吐量、资源利用率和系统可扩展性。
4. 分析结果并改进：分析收集的性能数据，评估系统是否满足预定义目标。此分析有助于识别性能瓶颈、可扩展性限制以及系统在性能要求方面可能失败的地方。根据测试结果分析，对软件系统进行必要的改进和优化。
5. 重复该过程：基于目标的性能测试是一个迭代过程。改进后，重复测试周期以验证是否已达到性能目标，并识别可能出现的新性能问题。

性能测试主要关注应用程序的速度和可靠性，分为负载测试（基于目标）和压力测试。随着敏捷开发方法的兴起，确保负载测试结果易于复现变得至关重要。

定义性能目标的重要性

定义性能目标是基于目标性能测试的基石。这些目标作为衡量软件性能的标准，为评估软件在各种条件下（包括正常使用、高峰负载和压力场景）是否满足性能要求提供了具体的框架。

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

• 与利益相关者期望保持一致：通过定义具体的性能目标，确保软件性能符合包括最终用户、客户和项目赞助人在内的利益相关者的期望。
• 验证性能需求：基于目标的测试帮助验证软件是否满足性能需求，提供具体指标评估性能是否充分。
• 优化资源利用：基于目标的测试通过识别系统资源的低效或过度使用，帮助优化资源分配，实现更高效的资源利用和成本节约。
• 可扩展性：通过测量在增加负载或用户并发时的性能，基于目标的测试评估软件的可扩展性，确保其能处理不断增长的用户和工作负载。
• 风险缓解：通过提前针对预定义性能目标进行测试，有助于识别和缓解性能相关风险，减少软件部署后的停机时间、用户不满或经济损失的可能性。

基于目标的使用案例：问题

假设您的新的CRM应用中有20个并发用户每小时生成2000笔交易。您的目标是在接下来的四个版本中确保响应时间在八秒以内。压力测试可能无法精确模拟这些版本中的预期吞吐量，因为响应时间可能与当前版本不同。

基于目标的使用案例：解决方案

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

配置LoadView的EveryStep工具的建议和提示

ThinkTime（必需）：

• 在EveryStep Web Recorder中创建新的关键字（ThinkTimes）或重用现有关键字。
• 确保允许的值为浮点数，范围为0.0 – 999.99。
• 允许用户手动向脚本添加ThinkTimes。
• 请记住，ThinkTimes代表等待时间，并由EveryStep Web Recorder在录制用户操作时自动添加。
• 一个脚本中可以存在多个ThinkTimes。
• 单脚本测试运行时会忽略ThinkTimes。
• ThinkTimes将在校准/获取基线时使用。
• ThinkTimes不计入响应时间测量。
• 压力测试时忽略ThinkTimes。

用户并发（可选）：

• 在EveryStep Web Recorder中引入新的“WaitFor（用户数）”关键字。
• 该全局等待点阻止模拟用户在脚本的特定部分继续，直到预期用户数达到该部分。

响应时间阈值（可选）：

• 在EveryStep Web Recorder中实现新的SetBoundary关键字。
• 语法：SetBoundary(定时器名称, 边界1, 边界2)。

基线/校准（必需）：

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

配置工作负载/执行计划（必需）：

• 客户指定启动时间。
• 客户定义目标交易率。
• 客户设置目标会话时间。
• 系统计算用户数。
• 客户决定是否在启动期间计算响应时间。

运行测试（必需）：

• LoadView根据配置的工作负载/执行计划执行测试。
• LoadView收集模拟脚本或交易的响应时间。
• LoadView动态调整ThinkTime以达到预期吞吐量；如果被测应用变慢，ThinkTime会减少。如果ThinkTime为零且会话时间超过目标，会显示错误消息，提示未达到预期吞吐量。
• LoadView计算实际交易和定时器的响应时间，不包含ThinkTimes。

集成Dotcom-Monitor的建议和提示

EveryStep Web Recorder

• 引入新的ThinkTime关键字。
• 单用户测试运行时忽略ThinkTime。
• 录制脚本时添加ThinkTime。
• 引入新的WaitFor(用户数)关键字。
• 引入新的SetBoundary(定时器名称，B1，B2)关键字。
• WaitFor关键字需手动添加到创建的脚本中。
• 使用SetBoundary关键字。

校准/获取基线

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

执行计划/工作负载

方案一：

• 新增工作负载配置功能。
• 将执行计划替换为工作负载功能。
• 创建支持压力测试、交易目标及其他类型的工作负载配置对话框。
• 指定启动时间。
• 勾选是否计算启动期间的响应时间。

方案二：

• 使用增强的执行计划配置功能。
• 选择测试类型（压力、基于目标）。
• 设置交易目标详情。
• 指定启动时间。
• 勾选是否计算启动期间的响应时间。

运行测试

• 计算实际脚本执行时间/会话时间。
• 根据实际会话时间动态调整ThinkTimes。
• 若未达到预期吞吐量，发出警告。

报告

• 配置响应时间部分，显示实际值与阈值的比较（每个定时器）。
• 配置吞吐量部分，显示实际与预期的比较。

集成Dotcom-Monitor的提示：常见问题

用户输入都有哪些？

• ThinkTimes（浮点数，>0）
• 目标每小时交易数（整数）
• 最大用户数（整数）
• 启动时间（分钟）
• 是否计算启动期间响应时间（是/否）

什么是基线？

设备或脚本的单用户执行，包含ThinkTimes。计算脚本执行时间并存储为会话时间，并包含所需执行资源等详细信息。

如果目标系统上的交易速度变化，如何动态调整负载测试？

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

什么是WaitFor关键字？

该关键字模拟复杂的用户场景，特别是并发情形，有助于测试多用户同时访问资源时某些功能是否正常工作。

什么是SetBoundary关键字？

帮助验证某个动作或定时器的实际速度是否符合指定的SLA响应时间边界。如果违反允许边界，则显示错误信息并记录在测试报告中，简化SLA验证。

负载测试的目标应设置为何？

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

应配置哪些类型的报告？

• 创建类似当前报告的报告。
• 包括平均值、最小值、最大值、标准差、百分位数响应时间。
• 跟踪成功交易数、失败交易数和错误率。
• 所有响应时间均不包含ThinkTimes。

限制

较高的目标会话时间可能导致会话超时和误报。必须考虑网页会话超时较短的情况，确保ThinkTimes适当放置，以防止因会话超时导致的失败。

如果未达到目标会怎样？

• 如果应用的响应时间变慢且会话时间超过目标会话时间，则无法达到预期交易率。
• LoadView在测试执行期间监控实际会话时间并调整ThinkTimes以尝试达到预期的基于目标的交易率。
• 如果会话时间超过目标，会在监控界面显示错误信息。
• 如果无法达到目标交易率，LoadView仍继续测试，标记测试失败，并在报告中注明受影响的设备。

示例基于目标的工作负载示例是什么？

• 启动时间：15分钟
• 在启动期间测量响应时间：是 / 否
  ST：会话时间
• GST：目标会话时间
• TPH：每小时交易数
• 用户数：由LoadView计算 (3600 / TPH) * GST = 72