在数字时代的早期，基于 HTTP 的测试非常流行。随着丰富的 Web 客户端技术的兴起，基于 HTTP 的仿真方法变得越来越过时。典型的基于 HTTP 的测试驱动程序执行服务请求并分析响应。现代 Web 2.0 应用程序由许多客户端脚本组成，这些脚本被完全忽略，并且在这种类型的测试执行中无法测量。在最坏的情况下，由于客户端生成的 ID 短缺，无法在协议级别模拟复杂的用例。

由于其请求和响应性质，负载喷射机上的开销非常低。典型的负载测试服务器可以同时模拟多达 800 个会话。复杂的基于协议的用例可能难以实现。性能工程师需要处理 Cookie、会话 I 和其他动态参数。根据要测试的系统类型，一些 Web 表单名称通常在部署新版本后更改，这将导致基于 HTTP 的脚本失败。

示例协议级脚本

交易 TMain

无功

hContext：数字;

开始

网页网址（”http：//lab3/st/”，”问候”）;

网页存储上下文（hContext）;

网页链接（”加入体验！” – 新访问者”）;

网页提交（”继续”，继续001，”主菜单”）;

网页链接（”产品”，”商店 – 产品”）;

网页链接（NULL，”商店 – 产品”，3）;

网页提交（”搜索”，搜索001，”-搜索”，0，NULL，hContext）;

结束TMain;

dclform

继续001：

“名称”：=”杰克”

“新名称按钮”：= “继续”;

搜索001：

“搜索”：= “启动”;

此处看到的示例脚本展示了这些脚本的技术性质。如果应用程序的技术属性发生更改，则必须重写整个脚本。

毕竟，协议级脚本非常适合连续集成环境中的组件级测试，并且由于其负载注入机器占用空间小而非常适合压力测试。

基于无头浏览器的负载模拟

随着 Web 2.0 技术的兴起，测试业务面临着严峻的挑战。由于脚本重播期间缺少客户端逻辑，无法再在协议级别测试或模拟丰富的浏览器应用程序。因此，引入了几个无头浏览器，如 HtmlUnit、PhantomJS 或 SlimerJS。它们通常构建在 WebKit 之上，WebKit 是 Chrome 和 Safari 背后的引擎。

无头浏览器类似于没有 GUI 的真实浏览器。许多测试自动化和性能测试平台都在使用无头浏览器来模拟流量。

无头浏览器有自己的陷阱;随着新的浏览器进入市场无头浏览器套件需要赶上所有性能和功能增强的真实浏览器。

客户端渲染的模拟不是免费的。典型的负载注入服务器可以模拟多达 10-12 个同时无头浏览器会话，而基于 HTTP 的会话数为 500 个。

测试脚本实现和自定义不是太难。如果你有基本的编码技能，你将能够创建简单的脚本。并非所有无头浏览器都提供可视重播功能，如果没有可视重播脚本调试或错误分析，可能会变得非常棘手。

示例幻影脚本
“使用严格”;
var 页 = 要求（”网页”）。

服务器 = “http://posttestserver.com/post.php?dump”，
数据 = “宇宙]膨胀和答案=42”;

page.open（服务器、”帖子”、数据、功能（状态）|

如果（状态！= “成功”） |

控制台.log（’无法发布！’）;

[ ] 否则，

控制台.log（页面.内容）;

}
幻影.退出（）;

});

在此处看到的示例脚本中，将执行一个简单的帖子请求。您需要 Java 编程技能来自定义此类测试脚本。

基于真实浏览器的负载模拟

Web2.0 应用程序充满了 JavaScript、闪存、Ajax 和 CSS。如果没有完整的浏览器，就无法测量整个网页的实际端到端响应时间。通过实际基于浏览器的性能测试，您可以验证最终用户认为的网站功能和速度。

典型的真实浏览器性能测试解决方案可收集图像、JavaScript、CSS 等加载时间。它们通常提供瀑布图，这些瀑布图可可视化这些组件的加载时间。

基于浏览器的实际浏览器的占用空间略高。考虑到无头浏览器模拟不能提供 100% 逼真的响应时间，可以公平地说，应该首选基于浏览器的真实模拟。在现实生活中，无头浏览器的性能仅比实际浏览器好 20%。因此，如果平均大小的单负载喷油器可以运行 10-12 个无头浏览器会话，则相同的负载喷射器可以运行 8-10 个实际浏览器会话。

测试脚本的实现和维护非常简单，因为用户操作直接反映，并且可视化重播使调试变得容易。在浏览器下面的示例脚本中打开 URL，插入用户和密码并单击登录按钮。

示例基于浏览器的实际脚本

交易 TMain

开始

浏览器启动（BROWSER_MODE_DEFAULT，800，600）;

导航到登录站点

浏览器导航（”http：//demo.com/测试网站/LoginForm.html”）;

设置安全站点的身份验证

浏览器集文本（”//输入[@name=用户”，”用户1″）;

浏览器设置密码（”//INPUT[@name=”pwd'”，”密码1″）;

浏览器点击（”//输入[@value[‘登录]，BUTTON_Left）;

结束TMain;

毕竟，真正的浏览器仿真对于现实的端到端负载测试很有用，但对于压力测试高用户量可能会非常昂贵，因为负载注入服务器上的占用空间太高。

Performance Test Types

Component Speed Tests

近年来，软件开发方法向敏捷方向发展。短版本冲刺（sprint）至关重要。开发人员和测试工程师自动进行质量保证和性能检查。通常，它们会在协议级别上实现基于服务的性能测试，或者模拟基于浏览器的实际性能检查，以将端到端响应时间与商定的性能边界进行比较。

目标

• 可重复性

• 自动接口和端到端性能检查

• 将响应时间与商定的阈值进行比较

Load Tests

出于多种原因，在验证非功能性需求时，负载测试是理想的测试方法。一个是响应时间可以在可重现的条件下验证。另一种是，这些测试允许验证响应时间阈值。在负载测试方案中，真实的响应时间测量至关重要。因此，测试工程师使用无头或基于实时浏览器的用户模拟来设置负载测试设置。

目标

• 可重现负载模拟

• 验证响应时间阈值

• 识别生产瓶颈，如负载条件

• 逼真的端到端测试方案

Stress Test

如果必须测试应用程序在峰值负载条件下的可靠性，请运行压力测试。在这种类型的测试中，您主要指定用户的最大数量以及应用程序上增加的提升和稳定状态加载的时间。目标是确定被测应用程序的临界点。

目标

• 可证明可扩展性和稳定性

• 模拟峰值负载条件

• 精确重现性并不重要

比较

显然，协议、无头或基于实际浏览器的用户模拟有很好的理由。下面的矩阵提供了一些选择适当方法的指导。

标准

HTTP

无头浏览器

真实浏览器

用户模拟

无

客户端呈现

模拟了某些客户端元素

真实用户模拟

脚本

实现和自定义

网站复杂时困难

构建健壮脚本所需的开发人员技能

简单的脚本，易于自定义

S

压接重播

需要低级分析

根据所使用的发动机，可以进行视觉重播

你看到你得到什么

脚本可维护性

所需的编程技能

未渲染部分中的错误难以解决

轻松，因为您在重播期间看到失败

多浏览器支持

某些工具模拟 Web 浏览器，但无法与

是的，但有些元素经常丢失

有些支持其他版本和不同的浏览器

负载喷射机上的F 欧印

低

，每个服务器最多 800 个会话

中

，

每个服务器最多10-12

个会话

高

，每个服务器最多 6 个会话

建议

用于

DevOps

取决于实际测试方案

否，通常复杂的脚本

是，易于使用和逼真的数字

推荐用于负载测试

否

，跳过客户端处理

是，优于 HTTP 模拟

是，逼真的用户模拟

推荐用于压力测试

是，因为负载发生器上的开销较低

否，负载发生器计算机上的开销过高

否，

负载发生器上最高开销

成本

低

高

推荐用于大容量、低成本测试 Web 服务器压力测试（如果可能）

不推荐

推荐用于真实复杂的应用仿真。

压力测试

目标

• 可证明可扩展性和稳定性

• 模拟峰值负载条件

• 精确重现性并不重要

比较

显然，协议、无头或基于实际浏览器的用户模拟有很好的理由。下面的矩阵提供了一些选择适当方法的指导。

标准	HTTP	无头浏览器	真实浏览器
用户模拟	无客户端呈现	模拟了某些客户端元素	真实用户模拟
脚本实现和自定义	网站复杂时困难	构建健壮脚本所需的开发人员技能	简单的脚本，易于自定义
脚本重播	需要低级分析	根据使用的引擎是可视重播是可能的	你看到你得到什么
脚本可维护性	所需的编程技能	未呈现部分中的错误难以解决	轻松，因为您在重播期间看到失败
多浏览器支持	某些工具模拟 Web 浏览器，但这不是可比的	是的，但有些元素经常丢失	有些支持其他版本和不同的浏览器
负载喷射机上的占地面积	低，每个服务器最多 800 个会话	中等，每个服务器最多 10-12 个会话	高，每个服务器最多 6 个会话
建议用于 DevOps	取决于实际测试方案	否，通常复杂的脚本	是，易于使用和逼真的数字
推荐用于负载测试	否，客户端处理被跳过	是，优于 HTTP 模拟	是，逼真的用户模拟
建议进行压力测试	是，因为负载发生器上的开销较低	否，负载发生器上的开销过高	否，负载发生器上最高开销
成本	低	高	高
	推荐用于大容量、低成本测试 Web 服务器压力测试（如果可能）	不推荐	推荐用于真实复杂的应用仿真。