性能测试提示

将脚本拆分为可配置的方案，这些方案应包括，例如：

• 打开主页

• 打开类别页(PLP)

• 查看简单产品(PDP) — 每个迭代包含2个循环

• 查看可配置产品 — 每个迭代包含2个循环

  • 例如，将以上步骤设置为流量的60%

• 产品搜索

  • 例如，将搜索目录设置为流量的37%

• 购物车和结账

  • 例如，完成脚本的购物车和结账部分的用户应默认采用约3%的行业标准电子商务网站转化率
  • 由于结账流程不快取，并且通常是资源密集型操作，因此设置完成订单的人员数量与网站浏览器的数量之间的高数字会得出不可靠的结果，即您的网站可以处理的流量。

在每次测试运行前清理所有缓存：

• 应完全清理AEM调度程序缓存
• Adobe Commerce的Fastly和内部缓存应完全刷新和清理 — 这可以通过Adobe Commerce管理员中的缓存控制来完成。

在Jmeter测试中包含提升期：没有设置提升期意味着流量不会逐渐提升，网站也不可能缓存任何经常访问的页面和页面组件。 在实际情况中，所有流量峰值很少同时到达完全没有缓存的网站，因此Jmeter测试脚本中应包含斜坡时段，以允许缓存建立，就像在实际的电子商务网站上发生的情况一样。

应该使用迭代中每个步骤之间的“等待时间”，实际上，用户不会
在历程中立即跳转到网站上的下一个页面 — 用户需要等待一段时间，才能阅读页面并决定下一步操作。

将线程组设置为无限期循环，但在设定的时间x（例如60分钟）内，将提供一个可重复的测试，其中位响应时间可与以前的测试运行相比。 这意味着，在设置的启动时段之后，将存在同时运行的虚拟用户的目标数量，并且此数量将在设置的循环时间内继续存在。

应使用中间时间使平均响应时间提高/降低，而不是平均响应时间。 如果
有几个边缘结果比其它结果耗时长很多，这会扭曲这个平均结果，但我们感兴趣的是大多数用户的最终用户响应时间，它更适合中位数度量。

默认情况下，不会在jmeter中收集嵌入的资源（例如，当实际用户访问页面时下载的JS、CSS和其他资源）。 可以启用此功能，但仅针对您正在测试的域 — 仍应排除外部资源调用(例如，我们不想包含来自外部托管服务的响应时间，例如 google analytics代码)。

应该启用HTTP缓存管理器，以使Jmeter能够在历程中缓存页面元素，如下所示
真实用户的历程将在他们使用自己的浏览器浏览网站期间完成。 在访客访问网站期间，用户的浏览器将仅下载一次相关的嵌入式资源，然后用户的浏览器将缓存这些资源。 此外，如果同一用户在最初访问后又返回网站，则它仍可能是缓存这些资产的缓存。

监听器应保留在实际负载测试运行中（例如，“查看结果树”和“汇总报告”）。 在非GUI实际负载测试运行中包括此参数会影响Jmeter报告的性能结果，因为实际测试运行期间会使用资源来生成报告。 从测试脚本中删除这些监听器，以替换为JTL结果文件，然后可以使用Jmeter的报表仪表板功能对其进行处理。

评估的目标响应时间，以便仪表板报表的“Apdex分数”可以用作快速衡量两次测试运行之间更改对性能的影响。 Apdex得分基于一定数量的人能够在容许的时间内访问网站。 如果响应时间超过某个“令人沮丧”的量，分数就会降低。 可使用“apdex_satisfied_threshold”和“apdex_tolerated_threshold”参数设置时间。

将目标“每小时订单数”量度设置为向商业用户显示，而不是虚拟用户计数。 “虚拟用户”可能是一个复杂的主题，需要了解测试在现实生活中衡量的内容。 通过计算网站转化率、每小时订单数、用户在网站上的平均逗留时间以及考虑每次页面加载之间的间隔时间，可以使用行业标准计算根据每小时订单数呈现不同的加载测试场景。

最后，您的Jmeter测试服务器应在地理位置靠近大多数用户流量来源和云基础架构托管位置的服务器上运行 — 希望这两个位置相同。