OTP i.e. one-time password, Security Questions or Captcha are the security features which protect the application from non-human threats. The non-human threat that means try 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 an automated way 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?
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
Actually, there are three approaches to handle the security feature in 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 purpose only. In that case, you do not need to include the request/function which handles 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 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 purpose. Static Captcha or OTP means the application will generate the same value every time. In this approach, Captcha or OTP field is kept enable 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 write 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 the end 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 implement 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 approach which suits your test scenario. The second approach is always preferable and better than the other two.