性能测试主要验证应用程序的速度和可靠性，分为负载测试 （ 基于目标）和压力 测试。 自从 敏捷开发 方法兴起以来，能够重现 负载测试结果已成为重中之重。
压力测试的原因是什么？
配置性能测试的最简单方法是允许许多用户迭代地执行测试脚本。 这种类型的测试称为 压力测试 ，通常用于识别业务 应用程序中的中断点。 缺点是应用程序的实际响应时间主要负责模拟负载，并且无法控制实际吞吐量。 在可伸缩性测试中，这不是问题，但对于不同版本之间的性能比较，可能会有问题。
基于目标的性能测试的原因是什么？
此类测试的主要好处是，它允许在现实、可重复的条件和吞吐量边界下进行速度测量。 基于目标的性能测试通常用于在生产环境中验证服务级别协议。
请考虑以下情况：
假设 20 个并发用户将每小时在您的新 CRM 应用程序中创建 2，000 个事务。 您的任务是创建性能测试，以验证此应用程序的响应时间为 8 秒，可在未来四个版本中实现。 压力测试很可能不允许在四个发布性能测试中精确模拟预期吞吐量，因为您不能假定响应时间与实际版本中的响应时间相同。
解决 方案：
- 将思考时间添加到脚本中
- 查找基线和单个用户脚本运行时以获取会话时间
- 配置工作负载，包括最大用户、基于目标的事务速率和基于目标的事务时间
- 运行基于目标的性能测试以模拟预期负载
- 查看测试报告并验证受 测 应用程序是否能够在商定的响应时间范围内处理负载
- 在接下来的四个版本中重复此测试运行，并验证应用程序是否能够保持吞吐量和响应时间阈值
配置”每步”工具的提示
思考时间（必需）
在”每步 Web 记录器”（ThinkTimes） 中创建新关键字或重新使用现有关键字
确保允许的值是浮点 0.0 = 999.99
确保用户可以手动将 ThinkTimes 添加到脚本
请记住，ThinkTimes 是等待时间，由 EveryStep Web 记录器在记录用户操作期间自动添加。
一个脚本中可以有 N 个思考时间
在单个脚本测试运行中忽略 ThinkTimes
思考时间将用于校准 / 获取基线
ThinkTimes 不是响应时间测量的一部分
在压力测试中忽略思考时间
用户并发（可选）
“每步 Web 记录器”中的新”Waitfor（用户数量）”关键字
这是一个全局等待点，在脚本中某个点阻止模拟用户，直到预期的用户数到达脚本的此部分
响应时间阈值（可选）
“每步 Web 记录器”中的新 Set 边界关键字
语法：设置边界（计时器名称，边界 1，绑定 2）
基线/校准（所需）
LoadView 执行单个用户测试运行
思考时间将用作脚本
负载视图 将计算会话时间
会话时间 + 脚本执行时间 + 思考时间
配置工作负载/执行计划（必需）
客户设置增加时间
客户设定目标交易率
客户设定目标会话时间
系统计算用户数
客户决定是否计算增加期间的响应时间
运行测试（必需）
LoadView 根据配置的工作负载/执行计划运行测试
LoadView 收集模拟脚本或事务的响应时间
LoadView 动态调整 ThinkTime 以达到预期吞吐量，如果测试中的应用程序减慢了 ThinkTime 的速度。 如果 ThinkTimes 为零，并且会话 > 时间获取目标会话时间，将引发一条错误消息，指示无法达到预期吞吐量。
LoadView 计算实际事务和计时器的响应时间，无需思考时间。
与 Dotcom 监视器集成的提示
每步 Web 记录器
引入新的 ThinkTime 关键字
在单个用户测试运行期间忽略思考时间
在脚本录制期间添加思考时间
引入新的 WaitFor（数字用户）关键字
引入新的 Set 边界（计时器名称、B1、B2）关键字
WaitFor 关键字必须手动添加到创建的脚本
使用 Set 边界关键字
校准/获取基线
计算校准期间的会话时间
执行计划/工作负载
选项 1：
添加新的工作负荷配置功能
将执行计划替换为工作负载功能
创建工作负载配置对话框以支持压力测试、事务目标和其他类型
指定提升时间
选中该框以计算加速期间的响应时间（是/否）
选项 2：
使用增强的执行计划配置功能
选择测试类型（压力，基于目标）
设置事务目标详细信息
指定提升时间
选中该框以计算加速期间的响应时间（是/否）
运行测试
计算实际脚本执行时间/会话时间
根据实际会话时间动态调整思考时间
如果无法达到预期吞吐量，请引发警告
报告
为每个计时器配置响应时间、实际与阈值的节
为吞吐量、实际与预期配置节
什么是用户输入？
思考时间（浮点 > ，0）
每小时目标事务（整数）
最大用户数（整数）
上升时间（分钟）
计算加速期间的响应时间（是/否）
什么是”基线”？
设备或脚本的单个用户执行。 参数中使用思考时间。 脚本执行时间计算并存储为会话时间。 还计算其他详细信息，如所需的执行资源。
如果目标系统事务速度发生变化，如何动态调整负载测试？
计算校准期间的会话时间
使用 ThinkTimes 达到请求的目标会话时间
在测试执行期间重新计算实际会话时间
根据实际会话时间动态调整思考时间
如果脚本执行时间是目标会话时间， > 则记录错误消息
指定工作负载计算中的最大用户数
什么是等待关键字？
这有助于模拟复杂的用户方案，如并发情况。 如果必须测试某些功能是否正常工作（如果 x 个用户数量同时访问资源），则此功能非常有用。
什么是设置边界关键字？
SLA 为用户操作（如搜索客户）指定响应时间边界。 SetBoundBunary 关键字可帮助您验证特定操作或计时器的实际速度。 如果违反了允许的边界，将显示一条错误消息，并将记录在测试报告中。 使用此新的 SetBoundary 关键字，SLA 验证要容易得多
负载测试的目标是什么？
- 不同版本/执行的 100% 可比性能测试
- 用于模拟常规或峰值负载模式的功能
- 相信被测试的系统可以在商定的边界内处理预期负载
- 将性能优化重点放在违反约定边界的用户操作上
您应该配置什么类型的报表？
- 创建与当前报表类似的报表
- 平均、最小、最大、Stddev、百分位数响应时间
- 事务确定，事务失败
- 错误率
- 所有响应时间都应该没有思考时间
限制
高目标会话时间可能导致会话超时和误报。 考虑 Web 会话超时非常低的情况，例如 10 分钟。 如果使用执行登录和客户搜索的简单脚本运行基于目标的性能测试，则应在登录和搜索之间放置 ThinkTime。 在此假设情况下，会话时间应为 10 秒的目标会话时间 700 秒。 在这种情况下，ThinkTime 将高于受测试应用程序的会话超时。 所有模拟事务都将失败，因为脚本将在 Web 会话超时中运行，并且无法执行客户搜索。
如果我们不达到目标，会发生什么？
如果负载测试下的应用程序的响应时间变慢，会话时间高于目标会话时间，则无法达到预期的事务速率。
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