Forum Discussion

twinkiman's avatar
twinkiman
Occasional Contributor
14 years ago

Test Structure

Greetings,

I'm trying to put together my first loadui test case and not having much luck.

I have a datasource which is an SQL query that shuffles one of the columns of a table (10,000+ records).
I also have a second datasource which grabs some additional data from a second table based off a key from the primary data source.
I have datasource loops on both datasources. After the first one, I have a SOAP request to my product (which is valid).

I can run this test fine as a functional test. However when I export it to LoadUI and execute, it thinks one invocation means it should step through every record thus firing thousands of requests and not one.

I may be structuring the test incorrectly by making one testcase span all records. I could limit the testcase to a single record, however this seems inefficient to have to reissue the datasource query once per invocation. What it seems like I want is to define a datasource for the loadUI test (querying once) then let each thread pull from that. I currently do have the primary datasource set as shared.

Thanks,
Jonathan
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    Icon for Alumni rankAlumni
    14 years ago
    Hi!

    The problem here is the nested loops. What you would need to do here is to recreate the loops in loadUI, disabling the loop TestSteps in soapUI. You probably want to refactor the two loops in soapUI into two separate TestCases and then use two soapUI Runners in loadUI. Data would be transferred between these two runners via the Add TestCase Properties setting. This might require some fiddling as it's not among the basic usercases for loadUI, but I'm sure it can be done.


    Regards

    Henrik
    SmartBear Software
  • twinkiman's avatar
    twinkiman
    Occasional Contributor
    14 years ago
    I'm not sure I understand what you mean by the nested loops being a problem. The basic structure is as follows:

    Property step
    Primary Datasource (All records in table)
    ... Groovy script to reset property in property step
    ... Secondary Datasource (lookup specific pieces of data elsewhere) [skips to secondary loop step on no records]
    ... ... Groovy script to append 1 value to property as a properly formatted xml string
    ... Loop 0..* on Secondary Datasource
    ... Issue Soap Request (involving data from the primary datasource and the appended property)
    Loop on Primary Datasource

    I'm not sure how I could separate the inner loop since it's datasource is dependent on the data obtained from the primary loop. Additionally since there are an unknown number of records returned from the secondary loop, I can't just flatten the datasources together into one larger query.
  • twinkiman's avatar
    twinkiman
    Occasional Contributor
    14 years ago
    For posterity sake, I believe I've found a solution and thought I'd share.

    I've taken the secondary datasource and secondary loop out of the equation and just made the groovy script getting run after the primary data source smarter. Now the single groovy script resets the initial property, fetches an random number of records from SQL, builds the output, and appends it to the property. This still left me with the problem where each invocation was trying to output every SQL record, so I also removed the primary datasource loop. The test now looks something like the following:

    Property step
    Primary Datasource (All records in table)
    ... Groovy script to reset property in property step, fetch data from SQL, package it up, and append it to the property step.
    ... Issue Soap Request (involving data from the primary datasource and the appended property)

    I'm trusting that with each invocation in LoadUI, the datasource is getting staying constant and just moving a cursor.