Forum Discussion

AnandPasayat's avatar
AnandPasayat
Occasional Contributor
14 years ago

Request/Response logging option in LOADUI

Hi,

I'm performing load test using soapui runner component in LoadUI.Could any one suggest, do we have any option in loadui (tablelog component) to check the soap request & response details, after successful execution of the test case using soapui runner componet?
or we need to check in the "SoapUI log" field in SoapUI module?

The above information is required to ensure that the LoadUI is injecting the soap requests (through Soapui runner component) to the intended SUT(System Under Test) & the respective response has been sent by SUT.

Waiting for your response, It's Urgent.

Thank You.

Regards,
Anand

4 Replies

  • AndyHughes's avatar
    AndyHughes
    Regular Contributor
    14 years ago
    Yes you can do this by setting up test case properties in SoapUI for the request and response and then using a property transfer to populate them. A table log (attached to the bottom of the stats component can then be used to output these test case properties so you can see the request and response of each individual call.
  • Elvorin's avatar
    Elvorin
    Contributor
    14 years ago
    AndyHughes wrote:
    Yes you can do this by setting up test case properties in SoapUI for the request and response and then using a property transfer to populate them. A table log (attached to the bottom of the stats component can then be used to output these test case properties so you can see the request and response of each individual call.


    Yeah, that's the only crude way of debugging any test case setup issue I've found so far. But make sure you delete those property transfer steps before your 'official' load test. Otherwise the performance numbers will be skewed (as property transfer step takes few milliseconds itself). Or else, configure your graph components to just show the SOAP call step's response time.

    I really wish LoadUI had some easier way of logging request/response. May be even by modifying soapui-log4j.xml file (provided some class of SoapUI has debug statement for request/response).
  • AndyHughes's avatar
    AndyHughes
    Regular Contributor
    14 years ago
    Yeah I get your point, and you do have to just get the timings from the specific test step you want when drawing graphs, but to be honest the property transfer part is negligible in terms of time when compared to the request (most of the time it's nothing).

    Also, I keep it in there so I can see what actually happens if and when it fails in a load test.

    Also another point to note which I didn't say before is that you will also have to have an assertion which looks for a 'failure' in order that should it happen, it's recorded as such. For example I use a 'Contains' assertion with the text 'fault'. Generally I find any SOAP request which goes wrong has the word 'fault' somewhere in the response.
  • Elvorin's avatar
    Elvorin
    Contributor
    14 years ago
    AndyHughes wrote:
    Yeah I get your point, and you do have to just get the timings from the specific test step you want when drawing graphs, but to be honest the property transfer part is negligible in terms of time when compared to the request (most of the time it's nothing).


    Not always true. Some of my service operations responds in 4ms (best time scenario). Having a 2ms property transfer will skew it a lot.

    I really wish LoadUI had option to generate report just on soap call response time. Right now, I can configure graphs to show just that and get aggregated raw data from it. But summary still shows for the entire test case.

    AndyHughes wrote:

    Also, I keep it in there so I can see what actually happens if and when it fails in a load test.

    Also another point to note which I didn't say before is that you will also have to have an assertion which looks for a 'failure' in order that should it happen, it's recorded as such. For example I use a 'Contains' assertion with the text 'fault'. Generally I find any SOAP request which goes wrong has the word 'fault' somewhere in the response.


    I generally keep 2 assertions - SOAP response and Not a SOAP Fault.