Tag Info

As for tutorials on SoapUI, sadly the majority of them are sub-par at best and out of date. If you want to learn SoapUI the best option is likely to jump in feet first and hit the ground running.
My background is primarily API testing, with a specialty with SoapUI and Groovy, so I will try and give some hints and pointers to get you started.
SoapUI's core ...

Instead of using SQL scripts, I would recommend using something like dbUnit for importing your test data. dbUnit will generate database dumps in XML format (this will also allow you database-independent test data).
The advantage is that you can write (build) scripts that will
import the dbUnit datasets,
run the database update SQL scripts on them (if you ...

Personally I would write a test data generator that generates unique test data and pushes into the database via a direct api call as part of the setup for each test. That way you can run multiple tests in parallel and can scale up your automated test execution.
From my experience, if you are using SoapUI, you probably should be calling the applications ...

Actually, I can see two questions in your post.
Is it better to test SOAP Web services backed by EJB using Java or C#?
Actually, Web service stack of technologies was designed to support interaction between application written in different technologies, so it does not matter how the Web service was implemented. I.e., Web service implemented in Java can by ...

I accomplished a similar thing by running the SoapUI tests within the Maven Build
http://www.soapui.org/test-automation/maven/maven-2-x.html
one of the outputs is "junitReport : Turns on creation of JUnit-reports, (true/false)" which will then let you use any of of the million JUnit graphing tools.
Hope that helps in finding your solution

You are on the right path with the "clean sheet" approach.
It would be best if every test runs on empty database and it fills in data in the database as a part of its own fixture. But if you find yourself using a lot of the same kind of the data for a bunch of tests, then a XML import file would be best.
Your testsuite should clear the database before each ...

As far as I'm aware data export and reporting you're looking for is available in Pro version of SoapUI. I would recommend developing your tests using SoapUI and using Apache JMeter for load testing as it's capable of sending SOAP requests, performing assertions and correlation and has powerful and flexibly configurable reporting system.
References:
...

In this situation, we are using the approach exposed by Bruce McLeod.
We use a data generator to produce 4 datasets from the same configuration defined by the test case:
the input data for the test (run manually or with qtp) to fill gui forms for example,
the data inserted before test with soapui in the application to create the customers on which the ...

Runscope provides a Web UI for creating tests. There is no code to write for standard assertions. You can write more complex assertions using Javascript.
It is a cloud based service, which allows tests to be run from data centers around the world, which is useful when testing response times. You can also use our local agent to test APIs that are behind ...

A lot of devs I know use PostMan, a Chrome app. I have written my own tool using .Net that allows me to use pre-formatted requests with a given type reflected from a .dll file. A REST client is like a browser. It makes a request and does something with the response (like printing out the JSON response).

welcome to SQA. One thing that it looks like you are not taking into account is the network speed of the device you are testing on. If you are running load runner on a network that has high internet connection speeds, or more probably is on the same network as the service you're testing, then you will get almost no additional time due to network latency, ...

SoapUI supports something called "properties" which are essentially the variables you asked for. After setting a property, whether manually or by a Groovy script, properties can be included in your individual test steps. SoapUI will expand a properties reference to whatever the property's value is. Property references look like this: ${property_name}.
...

Got an answer from the SoapUI forum
"depends where "do the variables belong" - you choose a scope eg. custId (i believe it is sth like customerID) in TestCase scope, if you need the custId visible in all teststeps
Lets have the example on TestCase scope - you go to Custom Properties tab in soapui (left bottom corner), create there a property (variable) ...

This option is only available in the PRO version of SOAP UI. The license costs around 300 dollars a year. You can have the data in an excel sheet and map the columns in the request; Loop it so that the test runs until all the rows in excel sheet are read and executed. You can export the response to a CSV or excel sheet.
You might also find this useful: ...