Forum Discussion

IMounsey-Smith's avatar
IMounsey-Smith
Occasional Contributor
14 years ago

LOADUI and SOAPUI - Only monitor selected step

Hey guys

I have set up a TestCase in SoapUI which contains 3 steps.

1. Properties
2. XML Generator (Groovy Script)
3. Request

The idea here is, the XML generator will generate a XML string that the Request will then send to the Soap service. The Generator can take anywhere from a few ms to X seconds to generate a string.

When I run the test case within SoapUI I can see how much time is spent on each step and so can confidently see the actual cost of the request (response time etc) as it doesnt include the time taken in the previous step (1 and 2).

In LoadUI, when I run the test case, the time taken seems to be including the time taken for all steps combined.

Is there a way to tell LoadUI to only monitor the time taken to execute the actual request, step 3, and not any of the other steps?

Its just happens that the time to generate the XML is in some cases taken 20 seconds to generate which seems to be affecting my results. All I want to monitor (as SoapUI is able to do) is my Request step response time.

3 Replies

  • Hello!

    There's many way to achieve this, bu this is probably the easiest:

    In the soapUI Runner's settings, change output level from TestCase only to one of the other options. You can now see the response times for individual TestSteps, e.g. in the Statistics Workbench.

    Another alternative would be to make two TestCases in soapUI, and use one soapUI Runner each for them, with the first Runner connected to the second. This gives you more flexibility in terms of loadUI flow control (i.e. you can put components in between the Runners, etc.). I won't go into detail on how to do this now though, but feel free to ask if this sounds as an interesting way.

    Regards

    Henrik
    SmartBear
  • IMounsey-Smith's avatar
    IMounsey-Smith
    Occasional Contributor
    Hey thanks for your reply.

    I ended up going down the 'easy' option way. Displays what I would like to see.

    The second option you give would be an interesting case to set up. I wonder how loadUI/soapUI would handle it, if you had many simultaneous users set up.

    I would imagine you would set up a testCase1 to generate the XML and store it into a datasink or a variable or some sort. Then another testCase2 that purely executes the request generated in testCase1 .

    The only issue I see here is with the generated XML testCase and how the result is handled. I foresee that if you had 2 users executing the same test cases, you could get them overwriting each others generated XML. Then again this depends on how and where the generated XML is stored or used.

    Interesting to see how it would work. Ill do some investigation and see if I can set it up.
  • IMounsey-Smith wrote:
    I would imagine you would set up a testCase1 to generate the XML and store it into a datasink or a variable or some sort. Then another testCase2 that purely executes the request generated in testCase1 .

    Yes, easiest is to save the XML to a TestCase Property and then enable Add TestCase Properties to Result Message in the soapUI Runner's settings. In loadUI 2.0 (first beta will be released in one week), this will be enabled by default (there will also be a completely new soapUI Runner).

    Then in the request TestCase, make sure that you have a TestCase Property with the same name. A soapUI Runner will automatically override a TestCase Property's value if an incoming message contains a property with the same name.

    IMounsey-Smith wrote:
    The only issue I see here is with the generated XML testCase and how the result is handled. I foresee that if you had 2 users executing the same test cases, you could get them overwriting each others generated XML. Then again this depends on how and where the generated XML is stored or used.

    That will not be an issue. LoadUI don't mix users/wire-messages with each other.

    However, as with any load testing scenario, you need to make sure that the handling of any common resources in the Script TestStep is thread-safe. E.g. if you use common variables like files, TestSuite Properties, Project Properties or context-variables (context.myVariable = aValue), you need to synchronize the access of these among users/threads. In the case of files, soapUI Pro handles this automatically with DataSources.

    Regards

    Henrik, SmartBear