SoapUI工具测试webservice

flyfly310

昨天安装了soapui一个可以对webservice作哦功能和性能测试的东东，感觉比较好用
可以直接很方便的创建测试用例和进行测试，现在在网站上截下个介绍，希望对大家有所帮助
http://www.soapui.org/gettingstarted/sample-project.html

soapUI Sample Project

We know that getting started with a new application always is a challenge. In order to make it easier for you, soapUI comes shipping with a sample soapUI Project file. This soapUI Projects illustrates some of the basic concepts of soapUI and can be used as a soapUI starting point; try out the project, run the included MockService and the included tests in order familiarize yourself with the soapUI interface, and then move on to the Getting Started tutorial.

Here are the main concepts that are illustrated in the soapUI Project.
Web Service Mocking

Web Service Mocking is way to fake the functionality of a Web Service in soapUI; to create a Mock Up. But why do you need such functionality?

Web Service Mocking is very useful in projects where implementation of the Web Service has not started or is not finished for use yet or where you for some other reasons can't access the Web Services live.

In other words, Web Service Mocking makes it possible for you to start creating test for a Web Service the same time you start to develop the same Web Service. This means, when the real Web Service is ready for testing; you can already have the tests done. This can be extremely powerful and will make it possible to work according to Test Driven or Agile Methodologies.

In soapUI you can create a MockService simply by choosing to add a Web Service Request to a MockService in order for the MockService to listen to it. Or you can even right click the Interface Icon and choose "Generate MockService", which will generate a MockService containing each defined response in the Interface.

You can then choose how to Respond to the Request and choose how to Dispatch (send out) different responses.

Now, let's take a look at how the Mock Service works. Open the MockService, called SampleServiceSoapBinding MockService, by double clicking on it.

Browse through the different Interfaces in the MockService; login, logout, search, and buy, and see what we do with different requests. As you see all the requests are dispatched using scripts. This is by far the most common way of dispatching, but early on in a project you might just want to create a set of responses and dispatch them in sequence or at random.

You can start the MockService by pressing the MockService Start button.

Web Service Inspection

Web Service Inspection a fancy way of saying looking at the Web Service. Good support for Web Service inspection can be very important early in the project when you want to find out how a Web Service.

Inspecting the Web Service can be done in two ways; inspecting the Web Service and making Web Service requests.
Inspect the WSDL

You can inspect a WSDL by Double Clicking Interface Icon. You then get the Interface Viewer, a very useful tool for seeing what the WSDL contains and how it is structured.

This is a structured way of looking at your WSDL. Just browsing the XML of the WSDL is very cluttered and a WSDL often is to complicated too look at in its entirety and therefore it is seldom done, resulting in lower WSDL understanding. In other words, since WSDL's are so complicated people don't read it, and remember, the WSDL is the specification (contract actually, bet let's not get into that...) and how well you use it depends on how well you understand it. This is a serious problem early on in projects, the people in the project don't understand the Contract. The soapUI Interface Viewer is a great tool for solving this problem.

Now let's Inspect the Web Service. Inspect the Sample Project WSDL by double clicking the SampleServiceSoapBinding Interface Icon. Use the Interface Viewer to familiarize yourself with the WSDL, the move on to Web Service Requests.
Make Service Requests

Expand the login Interface and double click the login request. Login by using the username Login and the password Login123. You should now have gotten the response containing a sessionID 9575658833177431

Go ahead, try it!

No response? don't forget to start the MockService. We also need to copy the sessionID and use it to logout.
Functional Tests
Test Structure

Let's move on and look at how tests work in soapUI. We have created three different TestSuites all containing different TestCases. A TestCase is made up of several steps, called TestSteps. The structure of a soapUI project is like this;

    * Project
    * Interface
    * TestSuites
          o TestCases
                + TestSteps
                + LoadTests
    * MockServices

As you can see there is also something called LoadTests, we can gather what they are, but we'll go into detail more what they actually do and how they actually work later.
Functional Tests in detail

Now let's examine a Functional Test in a TestCase. Expand the TestSuite Sample Simple TestSuite and then double click the TestCase Simple Login and Logout w. Properties Steps. As you can see the case consists of 5 TestSteps.

You can also click the Description tab in order to see the in test documentation.

The step consists of three different types of TestSteps; One PropertyStep, Two Test Requests and Two PropertyTransfer Steps. This is what they do:

    * PropertySteps: Stores Properties for later use. In our case it's the Username and Password required to login.
    * Test Requests: The actual requests to the server. In this case login and logout.
    * PropertyTransfers: A step used for moving properties between different steps. This might be from a Property Step to a request like the step Property Transfer: Move Username and Password does, or to move properties from a Test Request to another, like the step Property Transfer: Move sessionID does.

Functional Tests continued

Double Click on each step and examine how they work. Double Click the TestSteps and you'll get the TestStep editor. You can for example see that the step Property Transfer: Move Username and Password moves does two transfers in two Properties.

    * First it takes does the TransferUser Transfer. It takes the Property Username from the step Properties: Username and Password and moves it to the step Test Request: login.
    * Then it takes does the TransferPass Transfer. It takes the Property Password from the said step Properties: Username and Password and also moves it to the step Test Request: login.

Assertions

An important feature in Test is the assertions in Test Requests. Open the Test Step Test Request: logout.

In the TestStep we have four assertions, all asserting different things; That the response is a SOAP response, that it complies with the schema, that is isn't a SOAP fault and something called an XPATH match. The XPath Match validates that a certain element has the value expected.

The Test Run

Now that we have examined the TestCase, let's run it! Press the Play Button and the Test will run and the Test Case progress bar should be full and green.

Does it turn red after only a step?

Don't forget to start the MockService.

Or... did you run the TestStep earlier?

Look at the response, maybe the response is that you already have a session?

We logged in earlier and aren't allowed to log in again, let's just go to the MockService, stop it and restart it, clearing any server side sessions. Now, rerun the test.
Load Tests

Something very useful in soapUI is the ability to quickly create LoadTests. Why is this useful? The earlier you are able to run load tests, the earlier you can discover any performance issues. In soapUI you create a LoadTest simply by choosing a functional test, right clicking it and saying New LoadTest. Done!

This makes soapUI LoadTest extra good since the immediately enable you to load test the functionality not that the Web Service can respond quickly to the same Request over and over again. LoadTests are byproducts of the Functional Tests.

Now, let's examine a Load Test!

Go to the TestSuite Sample expanded TestSuite and the TestCase Search and Buy TestCase. There you will find for LoadTests, one for each LoadTest strategy. Choose the Simple Strategy LoadTest. The simple strategy is a basic strategy with a random delay.

The first figure to configure is the Test Delay, this sets the number of milliseconds our base delay will be (1000 is one second). The second figure is the random variable which sets how the delay should be changed at random, the value 0.5 means it should be half, that is between 500 and 1000 milliseconds.

What would the value 0 mean? That's right no random delay at all, just 1000 milliseconds all the time.

Now, let's run it!

As you see the numbers of the test are continuously updated. You can see figures like the response times throughput per second (tps) assertions errors and more. You can also press the graph button and see a graph of the test run.

Read more about the Interface here and the different strategies here.

You can also do LoadTest Assertions. One of the more important is the Max Errors Step. This is used for allowing the maximum number of errors allowed in a test run.

This will lead us to the final example, discovering an error in our MockService.
An error in our MockService

Go to the TestSuite Sample TestSuite fails if we don't get faults and the TestCase TestCase: Searching after Logging out LoadTests. There you will find a load test called LoadTest with Multiple Tests (will fail). Open it and run it. After a time this test will fail

Why?

Because multiple users are simultaneously logging in with the same username, which is not allowed by the MockService

Go ahead, try it!

Continuation

Now you can continue running the tests and look at different ways of doing tests.

Enjoy!