OTP i.e. one-time password, Security Questions or Captcha are the security features which protect the application from non-human threats and possibly a threat if you are able to capture them via JMeter/LoadRunner. The non-human threat means trying to access the application through an automated script. Here, one thing to be noted JMeter, LoadRunner, NeoLoad or any other performance testing tool scripts are also automated ways to simulate the real user behaviour and generate the load on the server.
Just think, if you are able to capture or handle the captcha of an application through JMeter or LoadRunner script then is that application secured?
Definitely NO
Hence one thing is confirmed that none of the developers builds such an unsecured application. So, how a performance tester can handle this security feature?
Approach to Handle Captcha/OTP in JMeter/LoadRunner
Actually, there are three approaches to handle the security feature in the performance test script.
- Disable the security feature: You can ask the developer to disable the security feature like Captcha or OTP of the application for testing purposes only. In that case, you do not need to include the request/function which handles the captcha or OTP. But such an approach bypasses the security code (logic) of the application. The reason is that this approach does not simulate the production behaviour of the application. Because in the production server, the application code generates a captcha or OTP and when the user enters the value of the related security field then the application logic compares the entered value with the generated value in the backend and confirms the identity of the user. Hence by disabling the security feature, you are bypassing the security logic of the application which is not a good idea.
- Use Static Value: This approach leads the developer to make the Captcha or OTP static while accessing the application for testing purposes. Static Captcha or OTP means the application will generate the same value every time. In this approach, Captcha or OTP field is kept enabled and a pre-defined value is passed as a security check in the request to allow the virtual user to access the application. The only disadvantage of this approach is if the developer disables the OTP generation code and writes a new comparison logic (UserEnteredValue == PreDefinedValue) then the Captcha or OTP generation logic will be again bypassed which may slightly deviate the result from the actual performance. Hence the developer needs to tweak the existing logic so that actual application performance can be measured along with the security feature.
- Embed Captcha/OTP generation code in script: The alternate approach is to embed the security logic in the test script which generates captcha and OTP at the server end. But make sure the logic at both ends should generate the same value for the same user/request. This approach simulates the real-world scenario but bit difficult to implement. Sometimes, security code generation logic does not compatible with the performance test script. If those are simple jar files then there is a possibility to implement this approach. Security code syncing is also one of the factors which may restrict to implementation of this approach.
If you get success to embed the code with the script then the performance of the test script may get impacted which may impact the transaction rate (TPS) during the load test execution.
The conclusion is you can not capture the security code of the web application through automated script whether its a captcha or an OTP. Hence go for any of the above-mentioned approaches which suits your test scenario. The second approach is always preferable and better than the other two.
You may be interested:
- Performance Testing Tutorial
- Performance Engineering Tutorial
- Micro Focus LoadRunner Tutorial
- NeoLoad Tutorial