Right now we are using Loadui for load testing, when ever i do a load test for soap web service for 10 min, the request to the server is same for 10 min, the total count like
Ex: 22000 count is the same request
I want to configure the load test like in real time, like data driven testing. each user has unique data every time they hit the endpoint.
This feature is available in Loadui NG ? , if available how to do it.
It is possible to use datasources in SoapUI tests. Additionally it will be possible to use shared datasource option in load test. It will allow each virtual user to use its own record.
Not long ago I evaluated loadui. And my purpose was similar to yours, I wanted to data drive the load test. But maybe LoadUI isn't built for this purpose. After playing around for a while and evaluating whether it was worth the expense of LoadUI, I decided that I could achieve what I wanted using regular SoapUI NG. I discovered that in reality there were two ways to attack load testing.
1. How much load can this thing take before it falls over. (The sexy impressive management statistic and what LoadUI is great for. This can be used to benchmark the system using various requests and monitoring these results release to release may provide insight into system performance. But the impressive stat isn't really useful in its own right. After all, nobody cares if the system can handle 20zillion req/sec if the requirement is only to handle 20/sec)
2. How does it behave in regular day to day load and can I ramp that up slightly to discover how much head room I have to predict system performance in the future using a representative data set. ie, maybe data that actually occurred on a particular day.
I think a combination of these two would be a sensible approach to load testing in my opinion, but I opted for option 2 as a really good way of evaluating the software without going to the expense of LoadUI. I used SoapUI NG and 'replayed' a days worth of data through our system. Now, whenever we have a new release I can run this same test and compare the system performance to last time. I believe that SoapUI is totally capable of doing this is any real world scenario. What LoadUI give you is the ability to vary the load in different ways, ramp it up and down etc, draw graphs, produce reports, but essentially there is no reason why SoapUI can't do the actual service calls
This has always been possible and has always been a reason why customers went with LoadUI NG.
You can data drive your testcases with a DataSource test step (http://readyapi.smartbear.com/soapui/intro/data), then you can set that DataSource teststep to share data between threads (https://www.soapui.org/load-testing/tutorials/datadriven-loadtesting.html)
Yeh sorry I didn't mean to mislead. It is of course possible in LoadUI, I was just highlighting really that in the vast majority of sensible use cases, SoapUI NG is perfectly adequate for data driven testing.
My point being that if you are load testing a service then is the data that important? (If you have a specific test case for this then fine) but generally, when load testing a service you are creating load and so the data isn't important, if the data is important then my assumption was that you are in a real world scenario in which case SoapUI using data driven functionality is more than capable.
(But I stand to be corrected on the above, just my view).
We paid for Load UI NG Pro and have the free version SOAP UI. I have a use case where I need to load test an API that activates cards from the database but in order to do that I need to feed in a list of unique card numbers. Is this possible with our current setup or do we need to get SOAP UI Pro to make this possible?
Hi vondie,
you'll need a SoapUI NG Pro license to setup a DataSource step that will be used in LoadUI.
As you don't have SoapUI NG Pro license, I'd suggest contact your account manager (you can ask through support - https://support.smartbear.com/message/?prod=ReadyAPI), to see if there's a way SmartBear can accommodate.
Thanks,
Mike Giller
API Sales Engineering Manager
That's disappointing but thanks for the information!
