我一直在开发一个在前端大量使用 AJAX 和动态 JavaScript 的网站，现在是开始压力测试的时候了。 但是，如何正确地对需要在前端单击多个链接的内容进行压力测试呢？ 我能够轻松、快速、重复地访问该网站的每个页面的一种方法是将 Google Mini 指向它。 但这不会单击链接，然后导航模态窗口之类的东西。
编辑 - 我应该指出该网站是用 PHP5 完成的，并且使用的 JavaScript 库是 jQuery。 不确定这是否会产生任何影响，但觉得了解一下可能会有用。
I have been working on a site that makes some pretty big use of AJAX and dynamic JavaScript on the front end and it's time to start stress testing. But how do you properly stress test something that requires clicking several links on the front-end? One way I was able to easily hit every page of the site quickly and repeatedly was to point a Google Mini at it. But that's not going to click links and then navigate Modal windows and things like that.
Edit - I should point out that the site is done in PHP5 and the JavaScript library used is jQuery. Not sure if this would make any difference but felt it might be useful to know.
发布评论
评论（5）
我在某种程度上不同意内森和弗雷迪的观点。 他们是正确的，“AJAX 测试”在发出 HTTP 请求方面实际上没有什么不同。 但事情没那么简单。 请参阅我在 Ajaxian.com 上的文章，了解为什么 Ajax 负载测试很难。
JMeter、Pylot 和 The Grinder 都是生成 HTTP 请求的好工具（我个人推荐 Pylot）。 但从本质上讲，它们并不充当浏览器并处理 JavaScript，这意味着它们所做的只是重播在记录时间看到的流量。 如果这些 AJAX 请求是该会话所特有的，则它们可能不适合/不适合大量重播。
事实是，随着更多逻辑被推送到浏览器中，使用传统负载测试工具正确模拟流量变得更加困难（如果不是不可能）。
在我的文章中，我给出了一个简单的示例，说明当您想要查询 1000 个不同的搜索词（负载测试期间的一个重要目标）时，测试 Google 主页等内容会变得多么困难。 要使用 JMeter/Pylot/Grinder 来完成此操作，您实际上最终会使用该工具的本机语言重新编写部分 AJAX 代码（在您的情况下使用 jQuery）。
如果您的目标是测量用户感知的响应时间（这可以说是一天结束时最重要的事情），那么事情会变得更加复杂。 对于使用 Comet/“反向 Ajax”（一种长时间保持打开套接字的技术）的非常复杂的应用程序，传统的加载工具根本不起作用。
我的公司 BrowserMob 提供使用 Firefox 浏览器的 负载测试服务，由 Selenium，驱动数百或数千个真实浏览器，允许您测量和计时浏览器中看到的视觉元素的性能。 我们还支持传统的虚拟用户（盲目 HTTP 流量）和模拟浏览器（通过 HtmlUnit）。
话虽如此，通常将 BrowserMob 等服务与传统负载测试相结合是正确的方法。 也就是说，真实的浏览器非常适合全保真负载测试，但它们永远不会像“虚拟用户”那样经济，因为它们需要 10-100 倍的 RAM 和 CPU。 请参阅我最近的博客文章，了解是否 模拟或不模拟虚拟用户。
希望有帮助！
I disagree with Nathan and Freddy to some degree. They are correct that "AJAX testing" is really no different in that HTTP requests are made. But it's not that simple. See my article on Ajaxian.com on Why Load Testing Ajax is Hard.
JMeter, Pylot, and The Grinder are all great tools for generating HTTP requests (I personally recommend Pylot). But at their core, they don't act as a browser and process JavaScript, meaning all they do is replay the traffic they saw at record time. If those AJAX requests were unique to that session, they may not be suitable/correct to replay in large volumes.
The fact is that as more logic is pushed down in to the browser, it becomes much more difficult (if not impossible) to properly simulate the traffic using traditional load testing tools.
In my article, I give a simple example of how difficult it becomes to test something like Google's home page when you want to query 1000's of different search terms (an important goal during load testing). To do it with JMeter/Pylot/Grinder you effectively end up re-writing parts of the AJAX code (in your case w/ jQuery) over again in the native language of the tool.
It gets even more complex if your goal is to measure the response time as perceived by the user (which is arguably the most important thing at the end of the day). For really complex applications that use Comet/"Reverse Ajax" (a technique that keeps open sockets for long periods of time), traditional load tools don't work at all.
My company, BrowserMob, provides a load testing service that uses Firefox browsers, powered by Selenium, to drive hundreds or thousands of real browsers, allowing you to measure and time the performance of visual elements as seen in the browser. We also support traditional virtual users (blind HTTP traffic) and a simulated browser (via HtmlUnit).
All that said, usually a mix of a service like BrowserMob plus traditional load testing is the right approach. That is, real browsers are great for a full-fidelity load test, but they will never be as economical as "virtual users", since they require 10-100X more RAM and CPU. See my recent blog post on whether to simulate or not to simulate virtual users.
Hope that helps!
您可以使用类似 openSTA。
这允许记录与网站的会话，然后通过相对简单的脚本语言进行回放。
您还可以轻松测试 Web 服务并编写自己的脚本。
它允许您以任何您想要的方式将脚本放在测试中，并配置迭代次数、每次迭代中的用户数量、引入每个新用户的启动时间以及每次迭代之间的延迟。 测试也可以安排在未来。
它是开源且免费的。
它会生成许多可以保存到电子表格中的报告。 然后，我们使用数据透视表轻松分析结果并绘制图表。
You could use something like openSTA.
This allows a session with a web site to be recorded and then played back via a relatively simple script language.
You can also easily test web services and write your own scripts.
It allows you to put scripts together in a test in any way you want and configure the number of iterations, the number of users in each iteration, the ramp up time to introduce each new user and the delay between each iteration. Tests can also be scheduled in the future.
It's open source and free.
It produces a number of reports which can be saved to a spreadsheet. We then use a pivot table to easily analyse and graph the results.
JMeter 在这方面非常出色。 您可以记录您的会话并根据您的喜好进行调整。
所谓的“ajax 负载测试”是该站点上反复出现的主题，并且经常被混淆。 所以让我们说清楚：对普通网页进行负载测试和使用 ajax 进行负载测试之间实际上没有区别。 这一切都归结为离散的请求； 它们只是碰巧不是整页刷新。
需要记住的一件事是，处理请求的服务器的负载测试（负载测试）与正在更新的 UI 组件的屏幕性能（JavaScript 的执行情况）之间存在明显差异。
简单的负载测试示例：
JMeter is great at this. You may record your sessions and tweak them to your liking.
So-called 'ajax load testing' is a recurring subject on this site, and is often confused. So let's get it straight: There is really no difference between load testing a normal web page and load testing with ajax. It all boils down to discrete requests; they just happen to not be full page refreshes.
One thing to keep in mind is there is a distinct difference between load testing the server processing the requests (a load test) and the performance on screen of the UI components being updated (how well your javascript performs.)
Simple load test example:
有可以支持 AJAX 的负载测试工具。 例如，WebLoad
http://www.radview.com/solutions/ajax-负载测试.aspx
There are load testing tools that can support AJAX. For example, WebLoad
http://www.radview.com/solutions/ajax-load-testing.aspx
你真正想要的是压力测试服务器处理ajax请求的能力。 使用加载工具在“记录”测试时查看请求，然后进行适当的调整。 我只使用过 vs 测试版，所以我无法向您推荐低成本的版本。
What you really want is to stress test is the server's ability to handle the ajax requests. Use a load tool that looks at the requests while "recording" the test, and then tune as appropriate. I have only used the vs test edition one, so I can't point you to a low cost one.