在过去，我使用微软Web应用程序压力测试工具和Pylot对Web应用程序进行压力测试。我写了一个简单的主页、登录脚本和站点演练(在一个电子商务网站中添加一些商品到购物车和结帐)。
只要让少数开发人员在主页上使劲敲一下，就几乎总能找到一个主要问题。更多的可伸缩性问题将在第二阶段浮出水面，甚至更多——在发布之后。
我使用的工具的URL是Microsoft Homer(又名Microsoft Web Application Stress Tool)和Pylot。
这些工具生成的报告对我来说没有多大意义，我花了很多时间试图弄清楚站点能够支持什么样的并发负载。这总是值得的，因为最愚蠢的错误和瓶颈总是会出现(例如，web服务器配置错误)。
你做了什么，你使用了什么工具，你的方法有什么成功?对我来说，最有趣的部分是提出某种有意义的公式，用于从压力测试应用程序报告的数字中计算应用程序可以支持的并发用户数。
当前回答
我玩JMeter。一个认为它不能不测试的是ASP。净Webforms。视图状态破坏了我的测试。我不知道为什么，但是有一些工具不能正确处理视图状态。我目前的项目是ASP。NET MVC和JMeter都能很好地与之配合。
其他回答
这里提到了很多好的工具。我想知道工具是否可以回答这个问题:“如何对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企业版(具有强大专业支持的商业版)。
弗兰克
我试过WebLoad，它是一个很好用的工具。它带有一个测试脚本IDE，允许您记录用户在网站上的操作。当它在web服务器上执行压力测试时，它还会绘制一个图表。试试吧，我强烈推荐。
You asked this question almost a year ago and I don't know if you still are looking for another way of benchmarking your website. However since this question is still not marked as solved I would like to suggest the free webservice LoadImpact (btw. not affiliated). Just got this link via twitter and would like to share this find. They create a reasonable good overview and for a few bucks more you get the "full impact mode". This probably sounds strange, but good luck pushing and braking your service :)
ab, siege, tsung, httperf，践踏，Pylot，请求日志分析器，perftools
对于基于web的服务，请查看loader.io。
简介:
加载程序。IO是一个免费的负载测试服务，允许你用数千个并发连接来测试你的web应用程序/api。
它们也有一个API。
