在过去,我使用微软Web应用程序压力测试工具和Pylot对Web应用程序进行压力测试。我写了一个简单的主页、登录脚本和站点演练(在一个电子商务网站中添加一些商品到购物车和结帐)。

只要让少数开发人员在主页上使劲敲一下,就几乎总能找到一个主要问题。更多的可伸缩性问题将在第二阶段浮出水面,甚至更多——在发布之后。

我使用的工具的URL是Microsoft Homer(又名Microsoft Web Application Stress Tool)和Pylot。

这些工具生成的报告对我来说没有多大意义,我花了很多时间试图弄清楚站点能够支持什么样的并发负载。这总是值得的,因为最愚蠢的错误和瓶颈总是会出现(例如,web服务器配置错误)。

你做了什么,你使用了什么工具,你的方法有什么成功?对我来说,最有趣的部分是提出某种有意义的公式,用于从压力测试应用程序报告的数字中计算应用程序可以支持的并发用户数。


当前回答

尝试ZebraTester,它比jMeter更容易使用。我已经使用jMeter很长一段时间了,但是负载测试的总设置时间总是一个问题。虽然ZebraTester不是开源的,但我在过去六个月节省的时间弥补了它。他们还有一个SaaS门户,可以使用他们的负载生成器快速运行测试。

其他回答

看看LoadBooster(https://www.loadbooster.com)。它利用无头脚本浏览器PhantomJS/CasperJs来测试网站。Phantomjs将解析和渲染每个页面,执行客户端脚本。无头浏览器方法更容易编写测试场景,以支持复杂的AJAX重载Web 2.0应用程序、浏览器导航、鼠标单击和对浏览器的击键,或者等待DOM中存在元素。LoadBooster也支持硒HTML脚本。

免责声明:我为LoadBooster工作。

我发现IBM Page Detailer也是一个有趣的工具。

这里提到了很多好的工具。我想知道工具是否可以回答这个问题:“如何对web应用程序进行压力测试?”这些工具并没有真正提供一种方法来强调Web应用程序。以下是我所知道的:

压力测试显示了Web应用程序如何在响应不断增加的用户数量时失败。压力测试显示Web应用程序在失败时如何运行。今天大多数Web应用程序——尤其是社交/移动Web应用程序——都是服务的集成。例如,当Facebook在2011年5月中断服务时,你无法登录Pepsi.com的Web应用程序。该应用程序并没有完全失败,只是用户无法使用它的大部分正常功能。

性能测试显示Web应用程序保持响应时间的能力,与有多少用户同时使用应用程序无关。例如,一个应用程序每秒处理10个事务,同时有10个并发用户,应该每秒处理20个事务,同时有20个用户。如果应用程序每秒处理的事务少于20个,那么响应时间就会变长,应用程序无法实现线性可伸缩性。

同样,在上面的例子中,每秒事务数应该仅仅是测试用例/工作流的成功操作。故障通常发生在较短的时间跨度内,这将使TPS测量过于乐观。失败对于压力和性能测试非常重要,因为它们也会在应用程序上产生负载。

我在TestMaker用户指南http://www.pushtotest.com/pushtotest-testmaker-6-methodology上写了PushToTest方法。TestMaker有两种版本:开源(GPL)社区版和TestMaker企业版(具有强大专业支持的商业版)。

弗兰克

我用过openSTA。

这允许与网站的会话被记录,然后通过相对简单的脚本语言回放。

您可以轻松地测试web服务并编写自己的脚本。

它允许您以任何您想要的方式将脚本放在一个测试中,并配置迭代的数量、每次迭代中的用户数量、引入每个新用户的递增时间以及每次迭代之间的延迟。将来还可以安排测试。

它是开源的,免费的。

它生成了许多报告,这些报告可以保存到电子表格中。然后,我们使用数据透视表来方便地分析和绘制结果。

此外,还有一个很棒的开源纯python分布式和可伸缩的locust框架,它使用了greenlets。它很擅长模拟大量同时使用的用户。