Contributions
Re: Test Structure
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.13 years agoPlace ReadyAPI QuestionsReadyAPI Questions773Views0likes0CommentsRe: Test Structure
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.13 years agoPlace ReadyAPI QuestionsReadyAPI Questions773Views0likes0CommentsTest 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, Jonathan13 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.2KViews0likes3CommentsChunking database records across mock responses
Greetings, I'm new to SoapUI and was trying to figure out the proper way to accomplish a task I'm working on. I've got a database of several thousand records and I need to send them via soap back to the caller in chunks of 100 per transmission. I can write the SQL to do this, but I'm not sure what the right way to go about connecting that up to SoapUI. I've been able to get soapUI to produce a single response with all the data using a groovy script and a mocked service response. From reading through the website, I think what I ought to be doing is setting up a test suite with a datasource, datasource loop, property transfer, and mock response; but I'm not sure. Thanks in advance, Jonathan715Views0likes0Comments