我目前正在开发多种负载测试工具，例如 Jmeter、LoadRunner 和 Gatling。 除 LoadRunner 提供的 TrueClient 协议外，上述所有工具都适用于协议级别的用户负载测试。现在像真正的浏览器测试这样的东西已经到位，资源消耗工具（如 LoadNinja 和 Flood.IO）工作在这个新颖的概念上。
在这方面我有几个疑问
我知道，我们可以使用 Jmeter 来模拟浏览器行为进行负载测试，但与真正的浏览器测试有什么不同吗？
【问题讨论】：
标签： browser jmeter performance-testing simulation loadrunner
您需要考虑两种类型的测试：
良好的性能测试应该检查这两种情况，最好使用基于协议的工具进行主要负载，同时使用真实浏览器访问应用程序以执行客户端测量。
【讨论】：
....这个新颖的概念.....
你在这里有点暴露你的年龄。完整的客户端测试在 1996 年是最先进的，在公司大量转向基于协议的测试之前，因为它在资源方面更有效。从那时起，（Mercury、HP、Microfocus）LoadRunner、（Segue、Borland、Microfocus）Silk 和（Rational、IBM）Robot 保留了使用完整 GUI 虚拟用户（使用功能自动化工具运行完整客户端）的能力。 TruClient 是最近添加的，它运行完整的客户端，但根本不会将输出写入屏幕，因此您可以获得 99% 的好处和测量结果
有什么好处。好吧，从历史上看，两层客户端服务器客户端很厚。大量的申请处理正在进行中。因此，将少量的 GUI 虚拟用户与协议虚拟用户相结合，可以让您衡量客户端的成本/重量。流向服务器可能需要 2 秒，但使用转换并呈现在客户端可能需要额外的 10 秒。您现在知道用户体验的瓶颈在哪里了。
好吧，欢迎来到未来的过去。 曾经超薄的网络就像后来的演示文稿一样，已经变得和经典的两层客户端服务器应用程序一样厚。我可能会认为解释 JavaScript 的现代浏览器比过去几年的两层编译应用程序更消耗资源。它是普遍可用的，并且基于通用的客户端-服务器协议 - HTTP。
现在网络很厚，了解到达和展示之间的差异是很有价值的。您还可以在 Chrome 的性能选项卡中观察到大部分此类数据。我们在浏览器指标方面也有出色的 w3c，可以深入了解本地代码执行的成本/权重。
将逻辑转移到客户端也导致了尝试重现 JavaScript 框架的逻辑和流程以来回生成协议级数据流的挑战。这是旧的客户端-服务器接口具有明显优势的地方，协议在数据表示方面是高度结构化的。因此，即使使用复杂的胖客户端，在协议级别表示和修改数据流也变得很容易（以数据库为例，行、列......）。 HTML/HTTP 非常非结构化。只要载体是 HTTP，您的开发人员几乎可以发送和接收任何内容，并且您可以将其转换为在 JavaScript 中使用。
为了使用复杂的 JavaScript 框架更轻松、更省时地创建脚本，GUI 虚拟用户重新流行起来。与其运行驱动浏览器的全功能测试工具（每个操作系统实例可以有 1 个浏览器和 1 个测试工具副本），我们现在拥有更有效地扩展的东西，Truclient，每个操作系统实例可以运行多个.但是，无法避免底层浏览器实例的高资源成本。
【讨论】：
让我试着在下面回答你的问题：
真正的基于浏览器的负载测试非常适合的场景是什么？ 在基于协议的负载测试中不可能提供哪些真正的浏览器测试？
一些公司进行真正的基于浏览器的负载测试。但是，正如您正确得出的结论，模拟此类场景的成本非常高。如果负载非常少（例如 100 个用户）并且他们想要测试的应用程序非常关键，并且此类应用程序无法使用标准 api 负载测试进行测试，因为这些应用程序大多是遗留应用程序，金融科技公司大多会这样做。
我知道，我们可以使用 JMeter 来模拟浏览器行为进行负载测试，但与真正的浏览器测试有什么不同吗？
是的，真正的浏览器有 JavaScript。有时，如果前端（网站）的实施很差，您无法使用服务级别负载测试来发现这些问题。如果您想了解开发人员编写的 JS 或其他逻辑对页面加载时间的影响程度，加载测试是有意义的。
重要的是要了解，性能测试不仅限于 API，还包括整个用户体验。
希望这会有所帮助。
【讨论】：