I have a project and need to test a large number of of users in Jmeter but the problem I am facing is how to login lots of users, it will be tedious for me to enter their data manually and the token.
Can we remove or bypass the session id/token? So I won't need to input it manually. Is there any simple way to login lacks of user so I can test the load and stress testing. Or is there any other open source tool in which I test this?
I think you should read the Apache JMeter User Manual first.
You work around to be like:
Try to record only one user login session using the Apache JMeter HTTP(S) Test Script Recorder.
Use CSV Dataset Config to pass all your login credentials in JMeter.
Add a Cookie manager in your test plan.
Use regular expression extractor or JSON path processor (Depending on your request type) if you need bypass any data in your subsequent request. Check this article.
You won't be able to simulate one lack users from your machine I guess.Actually, it depends on your hardware configuration. So check for the Distributed testing.
You have run your test in Non-GUI mode. You can use GUI mode for the only debugging purpose.
Do not add any listeners when you perform your load test since they consume more memory.
Try to tweak your JDK heap size accordingly.
Try to use updated JMeter version and JDK both.
It actually depends on your application design, for instance if usernames are matching some pattern like:
user1
user2
user3
etc.
you should be able to just add __threadNum() function as a postfix
If your users are present in a database table you can use JDBC Test Elements to read usernames from the database
When it comes to logging in, it is not about single request which performs login operation, your web application test must always represent real users using real browsers as close as possible, so the login flow should look like:
Open Login Page
Extract token using one of JMeter Post Processors
Perform login providing credentials and the token from the previous step
More information:
Building a Web Test Plan
Building an Advanced Web Test Plan
How To Login Into A Web Application with JMeter
Related
I recorded login and logoff requests using blazemeter. After the record nearly 10 request has been created by blazemeter, which some of them includes .../signalr/.../connectionToken labels.
when i run the test these labels return an error like and .
the test included 10 users. The users have different username and passwords. The other labels (another from these signalr labels) return true.
So, i wonder now if i can disable these pages and not include in the tests? or
any solution for this issue?
if i can disable these pages and not include in the tests
theoretically yes, you can ask around whether SignalR is in scope for performance testing and if not you could disable those, however I believe well-behaved JMeter test should act exactly like a real browser so if the real browser sends these requests to .../signalr/.../connectionToken - JMeter should also send them
or any solution for this issue
I don't think you can record and successfully replay anything in Web 2.0 times, the majority of web applications heavily use dynamic tokens for various reasons (saving client state, security, tracking, etc.). When you record the request you get a hard-coded value which can expire or invalidate by other means, you need to identify all the dynamic values like this SignalR token and perform correlation: the process of dynamic values extraction from the previous responses using suitable JMeter Post-Processors and re-using them in next requests in form of JMeter Variables or Functions
If you record the same user scenario second time and compare two resulting test plans all the request parameters which change will require correlation. There is also an alternative recording option which is capable of exporting recorded requests in "SmartJMX" mode with automatic detection and correlation of dynamic parameters, see How to Cut Your JMeter Scripting Time by 80% for more details.
I could somehow run JMeter test for a user but running HTTP requests a few time such like (multiple users). The problem is that authentication only supports one session and I don't think it's ok to create 50 users in LDAP to be able to test. I tried to use 'Parallel Controller' but after executing the first request the others have the status 'Socket closed'.
I don't think it's ok to create 50 users in LDAP to be able to test
I think this is what you should be really doing.
Parallel Controller is a kind of workaround to bypass JMeter Threads Model limitation when it comes to implementing specific test scenarios like simulating AJAX requests because it assumes several requests executing in parallel triggered by a single thread (virtual user)
In the majority of cases user does sequential actions like open login page -> login -> navigate somewhere -> type something -> etc.
Ideally each JMeter thread (virtual user) must represent a real user with unique credentials so I would strongly recommend either creating as many users as you need to simulate in LDAP, if you're not allowed to have test users in LDAP on permanent basis you can even create them from JMeter like:
setUp Thread Group - create users
normal Thread Group with your main test actions
tearDown Thread Group - delete users
See How to Load Test LDAP with Apache JMeter article to learn more about different types of LDAP requests you can send from JMeter
I want to test how many users can concurrently login to the application. For that, can I create one user name and password and increase the thread to 100? or should I create 100 username and passwords and load it somehow?
Treat each JMeter thread (virtual user) as the real user using a real browser, it means:
Different credentials (can be provided via CSV Data Set Config)
Properly simulating browser network footprint including (but not limited to)
Sending and receiving headers (and cookies as special header sub-type)
Downloading embedded resources (images, scripts, styles, fonts, sounds)
Representing browser cache
Simulating AJAX requests
Mimicking real user "think time" as real users don't hammer application non-stop, they need some time to "think" between operations so consider adding appropriate Timers
Login itself won't tell you full story, you need to produce realistic workload, i.e. after logging in user should start doing something which he's normally doing
Usually concurrent users = different users, because it should be based on real case scenario
During a load test you try to emulate real-world conditions
If you want to have concurrent users in your application you should use different users because most servers won't allow same user to use your application with multiple sessions, also your application wants to (test) support multiple users so you need to load test the common scenario first.
If your application allows user to use your application with multiple sessions
, then add a second load test which test it also
I have a django application to be tested using Jmeter. Here is the Workflow
Admin user logs in , gets back access_token
Creates a user, using access_token ,unique mobile and email
Created User resets its password using OTP and a new password
Created user logs into the application.
I am using Reg Ex. extractor for accessing access_token and OTP
I am able to perform this with 5 threads, but as I increase the threads, it fails. Let me know what am I missing. Below is the screen shot Of My Jmeter.
It is not clear what exactly fails. Whole JMeter test? Some specific sampler? Your application? How many users do you add, is it 6 or 600? You need to be more specific and include at least essential failure details.
In the meantime I would suggest the following troubleshooting options:
Add HTTP Cookie Manager to your Test Plan. Given you use > 1 user you need to maintain a separate session for each login.
You need to use a separate admin account for each thread. If you have only one admin account - create users in loop using Loop Controller as your test needs to be realistic.
Run your test in command-line non-GUI mode
Disable all the listeners during test run as they consume a lot of resources (especially View Results Tree one) therefore your test may simply fail due to lack of RAM, see Greedy Listeners - Memory Leeches of Performance Testing for detailed explanation.
I am automating functionality of API using JMeter. I just passed input parameters using JSON and asserted with expected result like 'Registered successfully'. My doubt is Whether I need to check the values saved in DB. If yes how can I do it in Jmeter.
JMeter provides JDBC Request Sampler which allows executing arbitrary SQL queries. You need to
Download relevant JDBC driver for your database management system and put it somewhere in JMeter Classpath (normally lib folder of your JMeter installation). JMeter restart will be required to pick the library up
Add JDBC Connection Configuration test element and specify database URL, credentials and other parameters if needed
Using JDBC Request sampler execute SQL query to validate that database contains the expected value(s)
See The Real Secret to Building a Database Test Plan With JMeter article for comprehensive instructions and configuration examples.
You could use JDBC Sampler & configurations for DB validation. However, I would suggest you to make use of other APIs (if any) to verify if they are present in the system/DB. some get request might bring the registered info.
I do a lot of API testing. sometimes we run these automated tests in higher environments like staging / PROD as part of sanity test after prod push. If you think that you might do something similar in the future, then you would not have prod DB config details - your test will be limited to run only in the lower environments & would not work in PROD. So, try to avoid DB validation.
Once you have successfully executed the API, add JDBC sampler after that, write query to count the number of rows in the db. If this count is growing which means the API is successfully inserting the data in the DB.
Once you have the count, write a beanshell script to print the count and compare it with older count and based on the comparison raise an assertion. This way you can be sure that the data is being inserted.
I will also recommend not to use this approach or any additional load when you are running your actual tests as the numbers you will get or system monitoring data you will collect will be with additional query which in turn will not be real life scenario or your actual test plan.
The best practices for API testing involve checking the result of the API call against an SQL query result.
Use the above details for setting your db connection.
I second with Vins. Using database validation to assert the reaponse from API limits the test capabilities and can not be scaled to higher environments where you have limited or no access.
Also you can not reuse the functional tests to run load tests as the number of users increases the more data gets inserted into database and slows down the test execution as more data pump in.
Also might be case that some select queries gets struck on as data set is more or due to network bandwidth or less memory alloxated to Jmeter
You might also face out of memory errors in java as it keeps trying to garbage collection to accomodate the large data set
Recommended apporach is to use front end validations if available and wherever applicable or make use of other APIs query and validate the data.