基于真实浏览器的负载测试或浏览器级别的用户测试

Question

我目前正在使用多个负载测试工具，例如Jmeter，LoadRunner和Gatling。 除LoadRunner提供的TrueClient协议外，所有上述工具都可以在协议级别的用户负载测试中使用。现在已经进行了诸如真实浏览器测试之类的测试，这在诸如LoadNinja和Flood等资源消耗工具上绝对是很高的。IO正是在这个新颖的概念上开展工作。

在这方面我几乎没有疑问

1. 基于浏览器的真实负载测试完全适合的情况是什么？
2. 在基于协议的负载测试中无法提供哪些真正的浏览器测试？

我知道，我们可以使用Jmeter模仿浏览器行为进行负载测试，但是真正的浏览器测试有什么不同？

Answer 1

  

....这个新颖的概念.....

您正在这里显示年龄。全面的客户端测试是1996年的最新技术，在公司大规模转为基于协议的测试之前，因为它在资源方面更加高效。自此以来，（Mercury，HP，Microfocus）LoadRunner，（Segue，Borland，Microfocus）Silk和（Rational，IBM）Robot一直保留使用完整GUI虚拟用户（使用功能自动化工具运行完整客户端）的能力。 TruClient是最近的一项功能，可以运行完整的客户端，但是根本不会将输出写入屏幕，因此您可以获得99％的收益和测量结果

有什么好处。好吧，从历史上看，两层的客户端服务器客户端很厚。大量的应用程序处理正在进行中。因此，将GUI虚拟用户和协议虚拟用户结合使用的数量很少，您就可以衡量客户端的成本/重量。到服务器的流可能需要两秒钟，但是在客户端进行转换并存在的情况下，可能还需要10秒钟。您现在知道了用户体验中的瓶颈所在。

好吧，欢迎来到未来的日子。 Web曾经非常薄，稍后将作为演示文稿使用，现在已经变得与传统的两层客户端服务器应用程序一样厚。我可能会更激烈地争论，因为现代浏览器解释JavaScript比过去几年的两层编译应用更多地是资源消耗。它只是普遍可用的，并且基于通用的客户端-服务器协议-HTTP。

现在网很厚，了解到达和显示之间的差异很有价值。您还可以在Chrome的“效果”标签中查看许多此类数据。我们在浏览器指标方面也拥有出色的w3c，可以深入了解本地代码执行的成本/权重。

将逻辑转移到客户端也导致了一个挑战，即试图重现JavaScript框架的逻辑和流程以来回生成协议级别的数据流。在这里，旧的客户端-服务器接口具有明显的优势，这些协议在数据表示方面具有高度的结构性。因此，即使使用复杂的胖客户端，也可以在协议级别轻松表示和修改数据流（以数据库为例，例如行，列...）。 HTML / HTTP是非常非结构化的。只要载体是HTTP，您的开发人员就可以发送和接收几乎所有内容，并且您可以将其转换为可在JavaScript中使用。

为使使用复杂的JavaScript框架创建脚本更容易，更省时，GUI虚拟用户重新流行起来。 Truclient现在不再需要运行一个驱动浏览器的功能齐全的测试工具，在每个OS实例中我们可以拥有1个浏览器和1个测试工具副本，而现在我们有了一个更有效地扩展的工具Truclient，其中每个OS实例可以运行多个。但是，无法避免底层浏览器实例的高资源成本。

Answer 2

让我尝试在下面回答您的问题：

基于浏览器的真实负载测试非常适合哪种情况？ 哪些真正的浏览器测试提供了在基于协议的负载测试中无法实现的功能？

一些公司进行基于浏览器的真实负载测试。但是，正如您正确地得出的结论，模拟这样的方案非常昂贵。金融科技公司通常会这样做，如果负载要少得多（例如100个用户），并且他们要测试的应用程序非常关键，并且此类应用程序无法使用标准api负载测试进行测试，因为这些应用程序大多数都是旧应用程序。

我知道，我们可以使用JMeter模仿浏览器行为进行负载测试，但是真正的浏览器测试有什么不同？

是的，真正的浏览器具有JavaScript。有时，如果前端（网站）的实现不佳，则无法使用服务级别负载测试来发现这些问题。如果您想查看开发人员或其他逻辑编写的JS对页面加载时间的影响程度，请进行加载测试。

重要的是要了解性能测试不仅限于API，还包括整个用户体验。

希望这会有所帮助。

Answer 3

您需要考虑两种测试类型：

1. 后端性能测试：模拟同时访问Web应用程序的X个真实用户。目标是确定relationship between increasing number of virtual users and response time/throughput（每秒请求数），识别saturation point，第一个bottleneck等。
2. 前端性能测试：基于协议的负载测试工具实际上并不呈现页面，因此即使来自服务器的响应很快出现，也可能是由于客户端中的错误引起的JavaScript渲染将花费大量时间，因此您可能需要使用真实的浏览器（1-2个实例）来收集browser performance metrics

表现良好的性能测试应同时检查这两种情况，最好使用基于协议的工具进行主负载，并同时使用真实的浏览器访问应用程序以执行客户端测量。