负载测试： HTTP vs 无头 vs 真实浏览器

负载模拟方法的主要方面（如 HTTP、无头和基于实际浏览器）的概述，然后是比较矩阵，以帮助您选择适当的仿真方法。

概述

网页加载缓慢或无响应会影响财务收入，因为受挫的用户即使问题解决也很可能不会再返回。因此，性能测试已成为开发链中不可或缺的一部分，并且需求仍在不断增长。

性能测试平台提供多种负载模拟方法，如基于 HTTP、无头浏览器和真实浏览器的方式。本文将概述这些方法的主要方面，并附上比较矩阵，帮助你选择合适的模拟方式。

基于 HTTP 的负载模拟

在数字时代的早期，基于 HTTP 的测试非常流行。随着富客户端技术的兴起，基于 HTTP 的模拟方式日益过时。典型的 HTTP 测试驱动程序执行服务请求并解析响应。而现代的 Web 2.0 应用包含大量客户端脚本，这些脚本在该类型的测试中完全被忽略，未被测量。在最坏的情况下，由于缺乏客户端生成的 ID，复杂的用例无法在协议层模拟。

由于其基于请求和响应的特性，负载注入机器的开销非常低。一个典型的负载测试服务器可以模拟多达 800 个并发会话。复杂的基于协议的用例实现起来可能非常困难。性能工程师需要处理 cookies、会话 ID 和其他动态参数。根据所测试系统的类型，某些网页表单名称在新版本发布后可能发生变化，从而导致基于 HTTP 的脚本失效。

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

随着 Web 2.0 技术的发展，测试行业面临巨大挑战。由于脚本回放过程中缺乏客户端逻辑，富浏览器应用无法在协议层进行测试或模拟。因此，HtmlUnit、PhantomJS 和 SlimerJS 等多个无头浏览器被引入。这些浏览器通常基于 WebKit 构建，WebKit 是 Chrome 和 Safari 的引擎。

无头浏览器类似于真实浏览器但没有图形界面。许多自动化测试和性能测试平台使用无头浏览器来模拟流量。

无头浏览器也存在一些问题；随着新浏览器进入市场，无头浏览器套件需要不断赶上真实浏览器的性能和功能更新。

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

测试脚本的实现与定制并不困难。如果你有基本的编程技能，就能编写简单脚本。并非所有无头浏览器都支持可视化回放功能，没有可视化回放的话，脚本调试或错误分析可能变得非常复杂。

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

Web 2.0 应用中充满了 JavaScript、Flash、Ajax 和 CSS。如果没有完整浏览器，无法测量整个网页的真实端到端响应时间。基于真实浏览器的性能测试可以验证用户实际感受到的网站功能和速度。

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

真实浏览器的资源占用稍高。考虑到无头浏览器模拟无法提供 100% 真实的响应时间，可以说应优先选择基于真实浏览器的模拟。在实际场景中，无头浏览器的性能仅比真实浏览器高 20%。因此，如果一个平均尺寸的负载注入器能运行 10–12 个无头浏览器会话，那么也能运行 8–10 个真实浏览器会话。

测试脚本的实现与维护非常简单，因为用户行为会直接反映，并且可视化回放使调试更加轻松。以下示例脚本中，浏览器打开一个 URL，输入用户名和密码，并点击登录按钮。

性能测试类型

组件速度测试

近年来，软件开发方法趋于敏捷化。短发布周期至关重要。开发人员和测试工程师会自动执行质量保障与性能检查。通常，他们会在协议层实施基于服务的性能测试，或模拟真实浏览器测试来比较端到端响应时间与约定的性能边界。

目标

+ 可重复性
+ 自动化接口与端到端性能检查
+ 将响应时间与约定阈值进行比较

负载测试

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

目标

+ 可重现的负载模拟
+ 验证响应时间阈值
+ 在类生产负载条件下识别瓶颈
+ 真实的端到端测试场景

压力测试

如果你需要测试应用程序在峰值负载下的可靠性，可以进行压力测试。在这种测试中，主要需要指定最大用户数，以及应用保持加载状态的斜升和稳定期时间。目标是找出应用的崩溃点。

目标

+ 验证可扩展性和稳定性
+ 模拟峰值负载条件
+ 精确的可重现性不是重点

对比

显然，协议级、无头浏览器或真实浏览器的用户模拟各有优劣。下方矩阵可帮助选择合适的方法。

标准	HTTP	无头浏览器	真实浏览器
用户模拟	无客户端渲染	模拟部分客户端元素	真实用户模拟
脚本实现与定制	网站复杂时较困难	需要开发者技能来构建健壮脚本	脚本简单，易于定制
脚本回放	需低层级分析	取决于使用的引擎，可支持可视化回放	所见即所得
脚本可维护性	需要编程技能	未渲染区域的错误难以解决	可视回放中可直接看到错误，易于维护
多浏览器支持	部分工具模拟浏览器，但无法媲美真实效果	支持，但常缺少部分元素	部分支持不同版本和浏览器
负载注入器的系统资源占用	低，每台服务器最多支持 800 个会话	中，每台服务器最多支持 10–12 个会话	高，每台服务器最多支持 6 个会话
推荐用于 DevOps	取决于具体测试场景	否，脚本常较复杂	是，易于使用，结果真实
推荐用于负载测试	否，跳过了客户端处理	是，比 HTTP 模拟更好	是，用户模拟更真实
推荐用于压力测试	是，负载生成器负担低	否，负载生成器开销大	否，负载生成器开销最大
成本	低	高	高
	推荐用于高并发、低成本的 Web 服务器压力测试（如适用）	不推荐	推荐用于复杂应用的真实模拟