I work in performance testing, and in the web space you essentially have two different main approaches: * Protocol Testing - where you use servers to generate

I work in performance testing, and in the web space you essentially have two different main approaches: * Protocol Testing - where you use servers to generate lots of HTTP/S traffic that is correctly structured to simulate user traffic. Generally, this is focused on capacity and server response times. * Browser Based - where you need the complex logic present in SPAs and Javascript to accurately create test traffic. This also allows for as-close-to-possible real user response times. This is essentially "headerless browsers" of varying types. This requires more performance test compute to process - so often a combination of both types are used together. I find that Testing application security is one of the most technically challenging aspects of performance testing. Often some parts of the security infrastructure have to be disabled to allow testing to occur. For example, Rate Limiting by source IP, any form of Captcha, 3rd party (OpenId etc) services have to be disabled - which increases the risk to application availability because sometimes there are components that haven't been tested exactly the way they will work for actual users. Luckily most the 3rd party services we use are already significantly tested by their vendors - but it is something that I worry about.