Suppose, current test case has request element as shown below which is using project level property
<requestElement>
<color>${#Project#COLOR}</color>
</requestElement>
If the targeted application accepts any string, then it is easy to transform the above as below
<requestElement>
<color>${=java.util.UUID.randomUUID().toString()}</color>
</requestElement>
Now, both regular and load test should not have any issue to send the dynamic & unique value each time.
Similarly, you may use random integer or timestamp etc.,
Hope this help.
Dear nmrao,
That is one suggestion, but I guess it would not work for me.
I am looking for non-random (specific) values to make the calls.
One workaround i thought of is to have 2 sets of files;
a - single test
b - load test
Also have the file name and location as project property.
And a startup script to setup either single or load test in the project proeprty.
Then run the required script; and followup with the actual tests.
Based on what file is chosen, the appropriate data set will be fed into the data source loop.
Unless, there is a better way that someone can suggest...
Bhuvan.
Hi Bhuvan,
Is it that you want more control over the id that is generated? One simple way is to make yourself a custom id generator. This might be overkill, but I did an example like this:
http://rupertanderson.com/blog/1-how-to-develop-add-and-use-a-custom-groovy-library-in-soapui/
Sorry, if this is not in the direction of what you want.
It's just that in response to nmraos suggestion, you said you wanted a non random approach.
A datasource is of course another option as you first said.
Regards,
Rupert
Hi Bhuvan,
Is it that you want more control over the id that is generated? One simple way is to make yourself a custom id generator. This might be overkill, but I did an example like this:
http://rupertanderson.com/blog/1-how-to-develop-add-and-use-a-custom-groovy-library-in-soapui/
Sorry, if this is not in the direction of what you want.
It's just that in response to Rao's suggestion, you said you wanted a non random approach.
A datasource is of course another option as you first said.
Regards,
Rupert
Couple of pointers:
Please make information available with the specifics, so that others do not have to image while looking at the post.
Sorry for leaving lots unsaid.
Lets say its a test system; input being components under test.
the backend that tests, is proper system , i.e not simulated, hence the need to use exact input.
the input is a string - like a product code (all numbers).
a simple test would be to send in a code that will sent back a known successful result.
a load test, i would like to get a mix of results, hence would like to pass in a set of product codes,
which could generate different types of results; thus exercising a broader coverage in the backend, than just hammering one area.
Hope this makes sense...
Bhuvan.
