My husband always says, “Plan the work, execute the plan.” That couldn’t be more true when you are deciding the best way to organize your project and is even more important if you plan on using dynamic sets of data.
I’ve seen test suites setup two main ways (or a combination):
1) Setup the real world scenario as a specific set of calls. For example, “Place an order”. You would include whatever flow is required for that to take place, from login to checkout. Behavioral driven testing.
2) Use DataSinks and loops on one call to iterate through a set of data. An example of this could be looping through an Excel spreadsheet.
Once you’ve worked out what variety of the above best suits your needs, you can start to build it out. Another thing to keep in mind is where you want or need your properties to live so they stay in scope. Properties in SoapUI can be at the test case, test suite, or project level. So, if you have a property at the test case level another test case within the test suite will not be able to access it.
My examples will be around Rest services with JSON using the second framework since the first is so unique depending on how your services are set up. My focus is on Rest because there’s less information out there about it, or that’s what I found Googling.