Best approach for WS testing in soapUI
I have been assigned for automated testing of Web services to achieve the following in soapUI: Basically before the soap message is send everytime it should be replaced with another test data. For ...
Forum Discussion
Not (entirely) sure what you mean, but for data-driven testing you could try the following approach (unfortunately I do not have the time to prepare an example project):
1.1. Create a testcase with properties on testcase level
1.2. Add the soapRequest to the testcase. (To fill the properties for the request you can use references, syntax: ${#TestCase#propertyname )
1.3. Decide on a tactic for the validation, this can be either:
a: A teardownscript/teststep to export the response (to either the testcase property or a db)
b: Xpath and/or contains validations to assert the response, these assertions can also use the ${#TestCase#propertyname references for validation.
c: A groovy script for the validation and script the assertions based on the data entered on testcase lvl.
2.1 Create a second testcase which will provide the data, (either from a datasource step/database-query/data-generator/etc)
2.2 add the steps necessary to acquire the data
2.3 add a script/property-transfer step or use the teardownscript to return this data to testcase-properties
3.1 Now create the testcase that will combine the previous testcases to an actual testcase.
3.2 add the data teststep (2.1) to this testcase (run testCase testStep) and select (all) the properties as return values.
3.3 add the soapRequest testcase (1.1) to this testcase (run testCase teststep) and have the properties from this testStep refer to the data-testStep properties.
Et voila, you have a data driven testcase, depending on how you want to provide data and/or validate the request, you can alter the approach.
Tips & tricks:
1a. If you are creating this setup, use the runmode "primary TestCase" so you can easily "debug" your testcases
1b. If the testcase performs the way you want it to, use "parrallel" runmode so you can run it simultaneously and reuse your soapRequest testcase for other testcases.
2 If you'd do not like the setup with the additional testcases, you can add the soapRequest and the datasource directly to your primary testcase.
b. the disadvantage of this is that it's a bit less easy to reuse the functions of these teststeps for other testcases.
Good luck on your project, I only use the soapUI pro version, so I do not know if all the functions described above are available for the free version....
1.1. Create a testcase with properties on testcase level
1.2. Add the soapRequest to the testcase. (To fill the properties for the request you can use references, syntax: ${#TestCase#propertyname )
1.3. Decide on a tactic for the validation, this can be either:
a: A teardownscript/teststep to export the response (to either the testcase property or a db)
b: Xpath and/or contains validations to assert the response, these assertions can also use the ${#TestCase#propertyname references for validation.
c: A groovy script for the validation and script the assertions based on the data entered on testcase lvl.
2.1 Create a second testcase which will provide the data, (either from a datasource step/database-query/data-generator/etc)
2.2 add the steps necessary to acquire the data
2.3 add a script/property-transfer step or use the teardownscript to return this data to testcase-properties
3.1 Now create the testcase that will combine the previous testcases to an actual testcase.
3.2 add the data teststep (2.1) to this testcase (run testCase testStep) and select (all) the properties as return values.
3.3 add the soapRequest testcase (1.1) to this testcase (run testCase teststep) and have the properties from this testStep refer to the data-testStep properties.
Et voila, you have a data driven testcase, depending on how you want to provide data and/or validate the request, you can alter the approach.
Tips & tricks:
1a. If you are creating this setup, use the runmode "primary TestCase" so you can easily "debug" your testcases
1b. If the testcase performs the way you want it to, use "parrallel" runmode so you can run it simultaneously and reuse your soapRequest testcase for other testcases.
2 If you'd do not like the setup with the additional testcases, you can add the soapRequest and the datasource directly to your primary testcase.
b. the disadvantage of this is that it's a bit less easy to reuse the functions of these teststeps for other testcases.
Good luck on your project, I only use the soapUI pro version, so I do not know if all the functions described above are available for the free version....