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