Forum Discussion

wizzim's avatar
wizzim
New Contributor
12 years ago

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:

  • 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

  • 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.
  • Hi Cheerios,

    Thank you very much for your feedback! Many of your requests are actually already in the queue to be added to LoadUI in future releases.

    Anyway, I have asked the LoadUI team and Product Owner to have a look at your post. It is always helpful to see how our customers interact with our software and have feedback on how we can make it better.

    Hopefully, at least some of these feature requests will be materialized very soon!

    Stay tuned!

    Best regards,

    Renato
    SmartBear Software
  • wizzim's avatar
    wizzim
    New Contributor
    Hello Renato,

    Thanks for your answer

    Additionnaly, there is a bug I forgot to mention:

    Let's say you have a Fixed Rate Generator with a burst size of e.g. 2.
    You wire this generator to a Round-Robin Splitter with 2 outputs.

    When running the project, you'll see the the Splitter is giving the 2 bursts randomly, for instance one time everything to output1, sometimes 1 for output1 and 1 for output2, ...
    This is counterintuitive: each output should receive each time 1 from the burst.

    Regards
    w.