加载速度慢或网页响应不灵敏对财务收入有直接影响。 确保使用正确的负载 模拟设置性能测试至关重要。 如果做对了，可能会产生灾难性的影响。 沮丧的用户很可能会放弃他们正在做的事情，而不是返回。 即使您和您的团队解决了此问题，也可能为时已晚。 他们可能已经找到了另一种解决方案。 一旦他们这样做了，他们不太可能会回来。
你不仅要担心收入损失，而且其他因素，如消费者信心、品牌诚信等，可能对企业更不利。 问题持续的时间越长，就越难以恢复消费者的信心。 不仅如此，您对产品、团队和组织的投资回报需要更长的时间才能实现（如果有的话）。 因此，性能测试（和监控）已成为软件和应用程序开发链的基本和关键部分。 需要一种能够正确、准确地执行与用户体验密切相关的性能测试的解决方案。这一点非常需要。
性能测试平台提供广泛的负载模拟方法，如 HTTP/S、无头和基于浏览器的实时测试。 在这篇文章中，我们将概述每个方面的主要方面，然后是一个比较矩阵，您可以使用该矩阵来选择适当的模拟方法。
基于 HTTP 的负载模拟
在我们数字时代的早期，基于HTTP的测试非常流行。 随着富Web客户端技术的兴起，这种方法变得越来越过时（ 使用JMeter等工具进行性能测试 也变得有点过时）。 典型的基于 HTTP 的测试驱动程序执行服务请求并分析响应。 现代 Web 2.0 应用程序由许多客户端脚本组成，这些脚本完全被忽略，并且在这种类型的测试执行中不进行测量。 由于客户端生成的会话 ID 短缺，无法在协议级别模拟复杂的用例。
由于其要求和响应性质，负载喷射机的开销非常低。 典型的负载测试服务器可以同时模拟多达 800 个会话。 复杂的基于协议的用例可能难以实现。 性能工程师需要处理 Cookie、会话 ID 和其他动态参数。 根据所测试系统的技术，某些 Web 表单名称通常会在部署新版本后更改，这将导致基于 HTTP 的 脚本失败。
下面的示例脚本展示了这些脚本的技术性质。 如果应用程序的技术属性发生变化，则必须重写整个脚本，这说起来容易做起来难。
//sample protocol level script
transaction TMain
var
hContext: number;
begin
WebPageUrl("https://lab3/st/", "Greetings");
WebPageStoreContext(hContext);
WebPageLink("Join the experience!", " - New Visitor");
WebPageSubmit("Continue", CONTINUE001, "Main menu");
WebPageLink("Products", "ShopIt - Products");
WebPageLink(NULL, "ShopIt - Product", 3);
WebPageSubmit("Search", SEARCH001, " - Search", 0, NULL, hContext);
end TMain;
dclform
继续001：
“名称”：”插孔”，
“新名称按钮”：”继续”;
搜索001：
“搜索”：”启动”;
毕竟，协议级脚本适用于持续 集成环境中的组件级测试，并且由于它们在负载注入机器上的占用空间小，是压力测试的完美设置。
无头浏览器负载模拟
随着web 2.0技术的兴起，测试业务面临着严峻的挑战。 由于脚本重播期间缺少客户端逻辑，无法在协议级别测试或模拟丰富的浏览器应用程序。 因此，引入了多个无头浏览器，如 HtmlUnit、PhantomJS 或 SlimerJS。 它们通常建立在WebKit之上，WebKit是Chrome和Safari背后的引擎。
无头浏览器具有真实浏览器的所有优点，无需重 GUI 即可运行得更快。 许多测试自动化和性能测试平台都使用无头浏览器，因为它们允许进行真实的用户模拟。
一些提供商已经建立了自己的无头浏览器引擎，但遇到了维护陷阱，因为他们必须跟上新的浏览器版本。 在这种情况下，强烈建议使用任何免费提供的无头浏览器工具包，因为有一个广泛的社区致力于 改进。
客户端渲染的模拟不是免费的。 典型的负载注入服务器可以模拟多达八个同时无头浏览器会话。
测试脚本实现和自定义不是太难。 如果您具有基本的开发人员技能，您将能够创建简单的脚本。 并非所有无头浏览器都提供可视重播功能，如果没有可视重播、脚本调试和错误分析，可能会变得非常棘手。
在下面的示例脚本中，将执行一个简单的后请求。 您需要 Java 编程技能来自定义此类测试脚本。
//sample phantomjs script
"use strict";
var page = require('webpage').create(),
server = 'https://posttestserver.com/post.php?dump',
data = 'universe=expanding&answer=42';
page.open（服务器，’后’，数据，功能（状态）|
如果 （状态！ = “成功”） =
控制台.log（”无法发布！”）;
[否则]
控制台.log（页面内容）;
}
幻像. 退出 （）;
});
考虑到这一点，如果您有编程技能，并且您使用的是允许可视脚本重播的解决方案，那么无头浏览器就是要走的路。
真正的基于浏览器的负载模拟
Web 2.0 应用程序充满了爪哇脚本、闪存、AJAX、CSS 等。 如果没有完整的浏览器，就无法测量整个应用程序或网页的实际端到端响应时间。 真正的基于浏览器的性能测试允许您验证最终用户感知的 站点 功能和速度，正如我们上面讨论的，这才是真正重要的地方。
典型的真实浏览器性能测试解决方案可收集图像、JavaScript、CSS 等的加载时间。 通常，它们提供瀑布式图表，这些瀑布图可可视化这些组件的加载时间。
真正的基于浏览器的浏览器的占用空间略高。 由于无头浏览器模拟不能提供 100% 的逼真响应时间，因此可以公平地说，真正的基于浏览器的模拟应该是测试的首选方法。
测试脚本的实现和维护非常简单，因为用户操作直接反映，并且可视化重播使调试变得简单。 在下面的示例脚本中，浏览器打开一个 URL，插入用户的密码，然后单击登录按钮。
//sample real browser-based script
transaction TMain
begin
BrowserStart(BROWSER_MODE_DEFAULT, 800, 600);
导航到登录站点
浏览器纳维盖特（”https：//demo.com/测试网站/登录表单.html”）;
设置安全站点的身份验证
浏览器集文本（”//INPUT=@name=’用户'”，”用户1″）;
浏览器设置密码（”//输入@name\”\”，”密码1″）;
登录
浏览器点击（”//INPUT=@value=”登录”，BUTTON_Left）;
结束 Tmain;
毕竟，真正的浏览器模拟对于逼真的端到端负载测试非常有用。 但是，不要使用它进行压力测试，因为负载注入服务器上的占用空间太高。
不同类型的负载和性能测试
组件速度测试
近年来，软件开发方法已朝着敏捷方向发展。 短版本冲刺（sprint）至关重要。 开发人员和测试工程师可自动执行质量保证和性能检查。 通常，它们在协议级别实现基于服务的性能测试（ 有时是 API 测试），或者模拟基于浏览器的真实性能检查，以将端到端响应时间与商定的性能边界进行比较。
组件速度测试的目标：
- 验证和重复输入/输出行为。
- 自动接口和端到端性能检查。
- 将响应时间与约定的阈值进行比较。
负载测试
负载测试理想的设置，当涉及到验证非功能性要求。 原因之一是响应时间可以在可重现的条件下进行验证。 另一个标准是，这些测试允许验证响应时间阈值。 在负载测试方案中，实际响应时间测量至关重要。 因此，测试工程师使用无头或真正的基于浏览器的用户模拟进行负载测试设置。
负载测试的目标：
- 可重复负载模拟。
- 验证响应时间阈值。
- 识别类似生产负载条件下的瓶颈。
- 创建逼真的端到端测试场景。
压力测试
如果必须证明 应用程序在峰值负载条件下的可靠性，请运行压力测试以确定系统的断点。
压力测试的目标：
- 在交通高峰期证明可扩展性和稳定性。
- 观察系统如何失败并重新联机。
- 可重复性并不重要。
比较
显然，有很好的理由和情况 的协议，无头，和真正的浏览器为基础的用户模拟。 下面的矩阵提供了关于何时选择适当的测试方法的一些指导。
| 标准 | HTTP | 无头浏览器 | 真实浏览器 |
| 用户模拟 | （1） 无客户端渲染 | （2） 模拟某些客户端元素 | （3） 真实用户模拟 |
| 脚本实现和自定义 | （1） 网站复杂时困难 | （2） 构建健壮脚本所需的开发人员技能 | （3）简单的脚本，易于定制 |
| 脚本重播 | （1） 需要低级别分析 | （2） 取决于用过的引擎是视觉重播可能 | （3） 你看你得到什么 |
| 脚本可维护性 | （1） 需要编程技能 | （2） 未呈现部分中的错误很难解决 | （3） 容易，因为在重播过程中看到失败 |
| 多浏览器支持 | （1） 某些工具模拟 Web 浏览器，但这是无法比较的 | （2） 是，但某些元素经常缺失 | （2） 部分支持其他版本和不同的浏览器 |
| 负载喷射机的占地面积 | （3） 低，每台服务器最多 800 个会话 | （2） 中等，每台服务器最多 8 个会话 | （1） 高，每台服务器最多 6 个会话 |
| 推荐用于 DevOps | （2） 取决于实际测试方案 | （1） 否，通常为复杂脚本 | （3） 是，易于使用和现实的数字 |
| 推荐用于负载测试 | （1） 否，客户端处理被跳过 | （2） 是，优于 HTTP 模拟 | （3） 是，真实用户模拟 |
| 推荐用于压力测试 | （3） 是，因为负载发生器机器的开销较低 | （2） 否，负载发生器机器的开销过高 | （1） 否，负载发生器机器的最高开销 |
| 成本 | （3） 低 | （2） 中等 | （1） 高 |
| 总分 | 17 | 19 | 24 |
希望本文关于负载模拟和性能测试类型，为您提供了一些有关性能测试的更多见解。 如果您对运行负载和压力测试或 一般的 LoadView 解决方案有任何疑问， 请联系我们的团队 或注册与我们的性能工程师一起 进行演示 。