加载缓慢或无响应的网页会对财务收入产生影响，因为一旦问题得到解决，沮丧的用户很可能不会返回。 因此，性能测试已成为开发链的基本部分，需求仍在增长。
性能测试平台提供广泛的负载模拟方法，如 HTTP/S、无头和基于实际的浏览器。 在这篇文章中，我们将概述每个方面的主要方面，然后是一个比较矩阵，您可以使用该矩阵来选择适当的模拟方法。
基于 HTTP 的负载模拟
在我们数字时代的早期，基于HTTP的测试非常流行。 随着丰富的网络客户端技术的兴起，这种方法已变得越来越过时。 典型的基于 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 即可运行得更快。 许多测试自动化和性能测试平台都使用无头浏览器，因为它们允许进行真实的用户模拟。
一些提供商已经构建了自己的无头浏览器引擎，但遇到维护陷阱，因为他们必须跟上新的浏览器版本。 在这种情况下，强烈建议使用任何免费提供的无头浏览器套件，因为有一个广泛的社区，工作在改进。
客户端渲染的模拟不是免费的。 典型的负载注入服务器可以模拟多达 8 个同时无头浏览器会话。
测试脚本实现和自定义不是太难。 如果您具有基本的开发人员技能，您将能够创建简单的脚本。 并非所有无头浏览器都提供视觉重播功能，如果没有视觉重放，脚本调试和错误分析可能会变得非常棘手。
在下面的示例脚本中，将执行一个简单的后请求。 您需要 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 应用程序充满了 JavaScript、闪存、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）至关重要。 开发人员和测试工程师可自动执行质量保证和性能检查。 通常，它们在协议级别上实现基于服务的性能测试，或者模拟基于浏览器的实际性能检查，以将端到端响应时间与商定的性能边界进行比较。
目标
- 重复
- 自动接口和端到端性能检查
- 将响应时间与商定阈值进行比较
负载测试
负载测试理想的设置，当涉及到验证非功能性要求。 原因之一是响应时间可以在可重现的条件下进行验证。 另一个标准是，这些测试允许验证响应时间阈值。 在负载测试方案中，实际响应时间测量至关重要。 因此，测试工程师使用无头或真正的基于浏览器的用户模拟进行负载测试设置。
目标
- 可重复负载模拟
- 验证响应时间阈值
- 识别生产样负载条件下的瓶颈
- 创建真实的端到端测试方案
压力测试
如果必须证明应用程序在峰值负载条件下的可靠性，请运行压力测试以确定系统的临界点。
目标
- 证明可扩展性和稳定性
- 模拟峰值负载条件
- 可重复性并不重要
比较
显然，有充分的理由进行协议、无头或真正的基于浏览器的用户模拟。 以下矩阵提供了一些指导，以选择适当的方法。
| 标准 | 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 |