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. Often some parts of the security infrastructure have to be disabled to allow testing to occur. I find that Testing application security is one of the most technically challenging aspects of performance testing. This requires more performance test compute to process - so often a combination of both types are used together. This is essentially "headerless browsers" of varying types.
This also allows for as-close-to-possible real user response times. * Browser Based - where you need the complex logic present in SPAs and Javascript to accurately create test traffic. Generally, this is focused on capacity and server response times.
* Protocol Testing - where you use servers to generate lots of HTTP/S traffic that is correctly structured to simulate user traffic. I work in performance testing, and in the web space you essentially have two different main approaches:
0 kommentar(er)
