在过去，我使用微软Web应用程序压力测试工具和Pylot对Web应用程序进行压力测试。我写了一个简单的主页、登录脚本和站点演练(在一个电子商务网站中添加一些商品到购物车和结帐)。
只要让少数开发人员在主页上使劲敲一下，就几乎总能找到一个主要问题。更多的可伸缩性问题将在第二阶段浮出水面，甚至更多——在发布之后。
我使用的工具的URL是Microsoft Homer(又名Microsoft Web Application Stress Tool)和Pylot。
这些工具生成的报告对我来说没有多大意义，我花了很多时间试图弄清楚站点能够支持什么样的并发负载。这总是值得的，因为最愚蠢的错误和瓶颈总是会出现(例如，web服务器配置错误)。
你做了什么，你使用了什么工具，你的方法有什么成功?对我来说，最有趣的部分是提出某种有意义的公式，用于从压力测试应用程序报告的数字中计算应用程序可以支持的并发用户数。
当前回答
我玩JMeter。一个认为它不能不测试的是ASP。净Webforms。视图状态破坏了我的测试。我不知道为什么，但是有一些工具不能正确处理视图状态。我目前的项目是ASP。NET MVC和JMeter都能很好地与之配合。
其他回答
我也投票给jMeter，我想在@PeterBernier的回答中添加一些引用。
负载测试回答的主要问题是有多少并发 我的web应用程序可以支持哪些用户?为了得到正确的答案， 负载测试应该代表真实的应用程序使用情况，接近于 可能的。
请记住，jMeter有许多构建块逻辑控制器，配置元素，预处理器，监听器，…这对你有帮助。
你可以模仿真实世界的情况与jMeter，例如，你可以:
Configure jMeter to act as real Browser by configuring (concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding , ajax support ,... ) Configure jMeter to generate user requests (by defining number of users per second, ramp-up time, scheduling ,...) Configure lots of client with jMeter on them, to do a distributed load test. Process response to find if the server is responding correctly during test. ( For example assert response to find a text in it)
请考虑:
It is easy to start a real web application test with jMeter in minutes. The jMeter has a very easy tool which record your test scenario ( know as HTTP(S) Test Script Recorder). jMeter has lots of plugins at http://jmeter-plugins.org. The jMeter UI is swing based and has made good changes in jMeter 3.2. On the other hand please consider that JMeter GUI should only be used for test and debugging. It is not good practice to use it in GUI mode for actual test. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui. Configure and test your scenario and run it on non-gui mode. The are lots of reporting showing tools in jMeter (Known as listeners) but there are not meant to be on during test. You must run your test and generate reports ( .jtl files). Then you must use these tools to analyze result. Please have a look at https://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formats or https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm.
https://www.blazemeter.com/jmeter提供了非常有用的信息，可以帮助您配置测试环境。
看看LoadBooster(https://www.loadbooster.com)。它利用无头脚本浏览器PhantomJS/CasperJs来测试网站。Phantomjs将解析和渲染每个页面，执行客户端脚本。无头浏览器方法更容易编写测试场景，以支持复杂的AJAX重载Web 2.0应用程序、浏览器导航、鼠标单击和对浏览器的击键，或者等待DOM中存在元素。LoadBooster也支持硒HTML脚本。
免责声明:我为LoadBooster工作。
我用过Grinder。它是开源的，非常容易使用，并且非常可配置。它是基于Java的，脚本使用Jython。我们在一个。net web应用程序上运行了它，所以不要认为它只是一个Java工具(从本质上讲，任何web压力工具都不应该与它所使用的平台绑定)。
We did some neat stuff with it... we were a web based telecom application, so one cool use I set up was to mimick dialing a number through our web application, then used an auto answer tool we had (which was basically a tutorial app from Microsoft to connect to their RTC LCS server... which is what Microsoft Office Communicator connects to on a local network... then modified to just pick up calls automatically). This then allowed us to use this instead of an expensive telephony tool called The Hammer (or something like that).
无论如何，我们还使用该工具来查看应用程序在高负载下的运行情况，它在查找瓶颈方面非常有效。该工具内置了报告，以显示请求花费的时间，但我们从未使用过它。日志还可以存储所有响应或自定义日志。
我强烈推荐这个工具，非常有用的价格…但是期望用它做一些自定义设置(它有一个内置的代理来记录脚本，但它可能需要自定义来捕获会话之类的东西……我知道我必须自定义它以利用每个线程的唯一会话)。
我们已经开发了一个流程，将负载和性能测量视为头等重要的问题——正如你所说，把它留到项目的最后往往会导致失望……
因此，在开发过程中，我们包括非常基本的多用户测试(使用selenium)，它检查基本的疯狂问题，如中断的会话管理、明显的并发问题和明显的资源争用问题。重要的项目在持续集成过程中包含了这一点，所以我们得到了非常定期的反馈。
对于没有极端性能要求的项目，我们在测试中包含基本性能测试;通常，我们使用BadBoy编写测试脚本，并将它们导入JMeter，替换登录细节和其他线程特定的东西。然后我们将这些数据提升到服务器每秒处理100个请求的水平;如果响应时间小于1秒，通常就足够了。我们出发，继续我们的生活。
For projects with extreme performance requirements, we still use BadBoy and JMeter, but put a lot of energy into understanding the bottlenecks on the servers on our test rig(web and database servers, usually). There's a good tool for analyzing Microsoft event logs which helps a lot with this. We typically find unexpected bottlenecks, which we optimize if possible; that gives us an application that is as fast as it can be on "1 web server, 1 database server". We then usually deploy to our target infrastructure, and use one of the "Jmeter in the cloud" services to re-run the tests at scale.
同样，PAL报告有助于分析测试期间发生了什么—您经常会在生产环境中看到非常不同的瓶颈。
关键是要确保不只是运行压力测试，还要收集了解应用程序性能所需的信息。
这是给JMeter的另一票。
JMeter是一个开源的负载测试工具，用Java编写。它能够测试许多不同的服务器类型(例如，web, web服务，数据库，基本上使用请求的任何东西)。
然而，一旦你开始面对复杂的测试，它确实有一个陡峭的学习曲线，但它是非常值得的。您可以非常快速地启动并运行，这取决于您想要进行哪种类型的压力测试，这可能没问题。
优点:
Open-Source/Free tool from the Apache project (helps with buy-in) Easy to get started with, and easy to use once you grasp the core concepts. (Ie, how to create a request, how to create an assertion, how to work with variables etc). Very scalable. I've run tests with 11 machines generating load on the server to the tune of almost a million hits/hour. It was much easier to setup than I was expecting. Has an active community and good resources to help you get up and running. Read the tutorials first and play with it for a while.
缺点:
The UI is written in Swing. (ugh!) JMeter works by parsing the response text returned by the server. So if you're looking to validate any sort of javascript behaviours, you're out of luck. Learning curve is steep for non-programmers. If you're familiar with regular expressions, you're already ahead of the game. There are large numbers of (insert expletive) idiots in the support forum asking stupid questions that could be easily solved if they'd give the documentation even a cursory glance. ('How do I use JMeter to stress-test my Windows GUI' shows up quite frequently). Reporting 'out of the box' leaves much to be desired, particularly for larger tests. In the test I mentioned above, I ended up having to write a quick console app to do some of the 'xml-logfile' to 'html' conversions. That was a few years ago though, so it's probable that this would no longer be required.
