wizzim
12 years agoNew Contributor
Suggestions for LoadUI
Hello all,
for my company, I had to develop load tests using SoapUI and LoadUI. The use case was the following: fire 15 different SOAP requests in parallel for a certain period of time, at a certain rate. No ramp, no variation, no randomness: pretty simple.
The queries were prepared by hand with SoapUI as 15 test cases (each query is different because the body is a big base64 payload).
Here are some suggestions I thought about during my work with LoadUI.
Usability:
Component:
SoapUI integration:
I know that a lot of my problems can be solved with custom components, but I was rushed by the schedule of the project and I didn't have time to dive into writing custom components, even if I know Groovy. I was expecting more from LoadUI "out-of-the-box".
Additionaly, I find the documentation of custom component to be scattered and missing a reference with all the API functions one can call in the component code.
The blog posts were interesting, but they are not a replacement for a complete reference.
Thank you for reading all my rant
Cheerios
w.
for my company, I had to develop load tests using SoapUI and LoadUI. The use case was the following: fire 15 different SOAP requests in parallel for a certain period of time, at a certain rate. No ramp, no variation, no randomness: pretty simple.
The queries were prepared by hand with SoapUI as 15 test cases (each query is different because the body is a big base64 payload).
Here are some suggestions I thought about during my work with LoadUI.
Usability:
- allow copy-pasting and cloning of component
- allow hiding the components toolbar
- ship a counter component, that just count how many "pulses" are sent on a wire (useful for debug)
- extend the size of the title in the jasperreport : often, my project titles are truncated because the default report displays only like, 8 chars.
- color-code the inputs of component
The current interface is pretty intuitive, but I have the feeling that the user is lacking some information about what the component expect as input. For instance if I wire together a generator and a VU Scenario, what happens? I know that VU Scenario should have only scheduler component wired to them, but maybe LoadUI should show it with a red input to the VU scenario, and a red output to the generator?
Component:
- ship a demux component that just sends an input to n outputs, no randomness, no specific distribution.
This would allow the user to have only one generator with n runner attached through this demux (current generator can only have one runner attached to it).
I cannot understand why the need of such a component never arose.
For instance for my project, I need to have 15 runners (see SoapUI runner limitation underneath). Therefore I also need 15 generators!
The following screenshot explains the chaos:
SoapUI integration:
- allow the user to configure SoapUI timeout in LoadUI
- allow the soapui runner to launch a testsuite, no just a testcase.
For my project, I had to create 15 testcases and 15 SoapUI runners to run them.
I would have prefered to:- be able to run a testsuite (and its testcases in parallel) with a SoapUI runner
or - be able to run the teststeps of a testcase in parallel
- be able to run a testsuite (and its testcases in parallel) with a SoapUI runner
- in soap runner, add an option to count the number of teststeps run, not just 1 request
If I a have a SoapUI testsuite with one testcase that contains 5 teststeps, and each of these steps fires a Soap request, then running the testcase should count in LoadUI as 5 requests, because 5 actual requests are fired. Currently, LoadUI always count that as "1".
I know that a lot of my problems can be solved with custom components, but I was rushed by the schedule of the project and I didn't have time to dive into writing custom components, even if I know Groovy. I was expecting more from LoadUI "out-of-the-box".
Additionaly, I find the documentation of custom component to be scattered and missing a reference with all the API functions one can call in the component code.
The blog posts were interesting, but they are not a replacement for a complete reference.
Thank you for reading all my rant

Cheerios
w.