Unit Testing Asynchronous BPEL Processes Using soapUI
Service-Oriented Architecture
Unit Testing Asynchronous BPEL Processes Using soapUI by Daniel Amadei February 2012 Thanks to its support for Mocking and WS-Addressing, soapUI can be used to test asynchronous BPEL processes. Downloads
SoapUI is a useful tool for testing your SOA applications. You may have already used it to test your synchronous services, or, even better, to automate those tests. But did you know that you can test asynchronous BPEL processes using soapUI? This is possible thanks to soapUI's support for Mocking and WS-Addressing. This article will show you how that is done. Understanding how BPEL processes are exposed and the role played by WS-Addressing BPEL processes are exposed, by default, as SOAP over HTTP web services. As such, these processes can be tested as easily by soapUI as any other web service. This is trivial when your BPEL processes are synchronous: soapUI will make a request, and can validate the received response. All this happens on the same HTTP connection. But what if you want to automate unit tests for your asynchronous processes?
SoapUI helps a lot in this (not so trivial) task. It is interesting to note that for an asynchronous process, the response is, in fact, sent as an invocation made from the called process back to its caller. This forces the caller to be able to receive a request for the callback. The caller has to provide the interface expected by the called process so that the response can be delivered. SoapUI has this capability and can act as a server to receive the callback. The key behind all this is WS-Addressing support by both tools: soapUI and Oracle SOA Suite. Understanding WS-Addressing Wikipedia defines WS-Addressing (Web Services Addressing) as: A specification of transport-neutral mechanisms that allow web services to communicate addressing information. It essentially consists of two parts: a structure for communicating a reference to a Web service endpoint, and a set of Message Addressing Properties which associate addressing information with a particular message. WS-Addressing plays a very important role in Oracle BPEL Process Manager's architecture for asynchronous processes. When an asynchronous BPEL process is invoked, you can specify the callback information using WS-Addressing headers. When BPEL has to make a callback to deliver the asynchronous response, it will inspect those headers and use the specified
value to send the response. When a BPEL process invokes another asynchronous process, it automatically sets the headers. Throughout the article you will see how soapUI, via WS-Addressing, is able to invoke a process and receive the asynchronous callback. Testing Scenario The application this article will use to simulate the asynchronous scenario is a very simple asynchronous BPEL process. It copies a received string and sends it as a callback response to the requester. This scenario uses the
soapUI to send the request, wait for the callback, and then look for a match between the sent and received values. The first step in the test is to create a new application in JDeveloper. This test uses the 11.1.1.5 versions of Oracle JDeveloper and Oracle SOA Suite for the sample, but it can also apply to any 11g version of those two products. Using JDeveloper, create a new SOA Application and name it OTNTestingAsyncBPEL, as shown in Figure 1.
Figure 1- Creating the application Within this application, create a new project (you should be redirected to the project creation in the next screen):
Name it AsyncBPELTesting.
Click next and select Composite With BPEL Process
Click Finish.
Figure 2 - Creating the SOA Project You will be prompted to create the BPEL Process. Name it AsyncBPELProcess and make sure its template is &Asynchronous BPEL Process& so that the process will be created with an asynchronous structure, as is mandatory for this
Figure 3 - Creating the BPEL Process Your BPEL process should be identical to the one in Figure 4. This is a typical async process in which the request is received in a one-way fashion. As determined by the architecture, the client does not get a instead, the client is later stimulated by the called process to receive the response via what is known as
a &callback,& but what is, in fact, a request sent to the caller by the called process.
Figure 4 - The created asynchronous BPEL process Our BPEL process will be very simple: the text received as input will be copied to the output. This received value will be used later to test (using soapUI) if the correct response to the specified request was received.
To implement this logic in the BPEL process:
Create an Assign step and name it copyRequestValueToResponse;
Edit the Assign and copy the value received by the process/input element (inside the payload of the inputVariable) to the processResponse/result element of the output variable, as shown in Figure 5. The outputVariable will be sent to the client when it is used by the callbackClient step.
Figure 5 - Copying the request data to the callback response The project can now be deployed, and a preliminary test can be run. For now, don't worry about the callback. Creating the Test Project in SOAP UI The first test will be created simply to start the process. In soapUI, create a new test project by pressing Ctrl+N. Enter http://localhost:7001/soa-infra/services/default/AsyncBPELProject/asyncbpelprocess_client_ep?WSDL as the URL for the WSDL, and name the project AsyncBPELProjectTest, as shown in Figure 6. The project will be created and two bindings will be available, one for the request and one for the callback.
Figure 6 - Creating the SOAP UI project Expand the AsyncBPELProcessBinding process and open the &Request 1& item. Change the content of the input tag to &First test...& as shown below.
&soapenv:Envelope
xmlns:soapenv=&http://schemas.xmlsoap.org/soap/envelope/&
xmlns:asy=&/OTNTestingAsyncBPEL/AsyncBPELProject/AsyncBPELProcess&&
&soapenv:Header/&
&soapenv:Body&
&asy:process&
&asy:input&First test...&/asy:input&
&/asy:process&
&/soapenv:Body&
&/soapenv:Envelope&
Submit the request. You should not receive any content as response. After clicking the http log tab in soapUI, the return code received should be 202. This return code means that the request was accepted as per the HTTP protocol semantics. The example below illustrates the logging that can be seen in soapUI:
Sun Nov 13 09:30:38 BRST 2011:DEBUG:&& &HTTP/1.1 202 Accepted[\r][\n]&
Sun Nov 13 09:30:38 BRST 2011:DEBUG:&& &Date: Sun, 13 Nov :38 GMT[\r][\n]&
Sun Nov 13 09:30:38 BRST 2011:DEBUG:&& &Content-Length: 0[\r][\n]&
Sun Nov 13 09:30:38 BRST 2011:DEBUG:&& &Content-Type: [\r][\n]&
Sun Nov 13 09:30:38 BRST 2011:DEBUG:&& &X-ORACLE-DMS-ECID:
1b7ede:5a1f5e8a:d49:-b[\r][\n]&
Sun Nov 13 09:30:38 BRST 2011:DEBUG:&& &X-Powered-By: Servlet/2.5 JSP/2.1[\r][\n]&
Sun Nov 13 09:30:38 BRST 2011:DEBUG:&& &[\r][\n]&
You can see what happened to the BPEL process by using Oracle Fusion Middleware (FMW) Control to inspect the created instance. Access FMW Control on your server at
http://&ip&:&port&/em of your SOA Server. For example, in a typical installation the default host and port would be: http://localhost:7001/em. Inside FMW Control, find the project AsyncBPELProject and click the Instances tab. Your instance will be displayed, as shown in Figure 7.
Figure 7 - Instance created in our first test Click the instance to display all of the steps it has performed, as shown in Figure 8.
Figure 8 - All steps performed by the instance By clicking the BPEL process instance, you should be able to see the BPEL flow in a new browser window. Expand the payload element inside the callbackClient step and you should see the value we sent inside the processResponse/result element, as shown in Figure 9.
Figure 9 - BPEL Flow Since we did not specify any callback information, the callback was ignored. Now let's look at how soapUI can help with testing the rest of this scenario by acting as a server capable of receiving the asynchronous callback. What happens when an asynchronous response has to be sent to the client? The asynchronous request / response pattern in a web service is not a traditional request-response. As already mentioned, what happens under the covers is that the client sends a one-way message to the server and the server sends a request back to the client when it has to respond something. The client has to be able to receive the request back from the server. All this is shown in Figure 10.
Figure 10 - Asynchronous request/response using WS-A
Let's continue to build the soapUI project to see the callback scenario in practice. Testing it! The first step is to create a Test Suite and add a Test Case to it.
Right click your soapUI project and select New Test Suite, keeping the default suggested name for the test suite.
Right click the Test Suite and select New Test Case, also keeping the suggested name.
Your project should resemble Figure 11.
Figure 11 - SOAP UI with a Test Suite and Test Case Now, do the following to add a Request to your test case:
Expand the AsyncBPELProcessBinding, process and drag Request 1 to the test steps pane.
Respond to all soapUI prompts. Confirm all of the questions in the soapUI prompts.
This is (almost) all for the request part of the test. We now have to add a way to receive the response:
Right click Test Case 1
Select Add Test Step, Mock Response.
Name the mock response as Mock processResponse. A new window asking you to configure the Mock Response is shown.
Change the interface to AsyncBPELProcessCallbackBinding, which is the one we have for the callback.
Keep the operation as processResponse&it's the only one available. (If your process supports multiple asynchronous responses&callbacks, in reality&you could select which operation soapUI should emulate in this step.)
Enter 9898 as the port. SoapUI will direct the server to start listening at this TCP/IP port. As Path, enter /AsyncBPELProcessCallbackBinding/processResponse, representing the URL path.
Figure 12 shows the final state of the configuration screen. Click OK.
Figure 12 - SOAP UI MockResponse configuration At this point you may be wondering, &How will the BPEL engine understand that it has to respond to soapUI at the port [9898] and path [/AsyncBPELProcessCallbackBinding/processResponse] we've just configured?& Thanks to standards compliance by both tools&Oracle SOA Suite and soapUI&this is easily
accomplished using WS-Addressing. To specify the WS-Addressing information and inform SOA Suite how to call soapUI back when it has a response to deliver, do the following:
Open the request process - Request 1;
Click the WS-A button and check the Enable / Disable WS-A Addressing
Change the Must understand drop-down to TRUE;
Check the Add default wsa:Action
In the Reply To: section, specify http://localhost:9898/AsyncBPELProcessCallbackBinding/processResponse. This
is the address and path we specified in the configuration of the soapUI
Select Randomly generate MessageId so that a message ID is randomly generated to correlate the request with the response.
The WS-Addressing configuration should be identical to Figure 13.
Figure 13 - WS-Addressing configuration Open the Test Case again and execute it. Both steps should pass without a problem. By opening the Mock processResponse test step, you should see the received response. This shows that Oracle BPEL Process Manager was able to receive the request and call soapUI back to deliver the response asynchronously. You can format the XML so it is
easier to be read, as shown in Figure 14.
Figure 14 - Response received! Clicking on the soapUI log tab will display the following messages, showing that soapUI started a server to receive the request (on port 9898 with path /AsyncBPELProcessCallbackBinding/processResponse) and mounted a WSDL interface:
Sun Nov 13 20:55:40 BRST 2011:INFO:Mounted WSDL for interface [AsyncBPELProcessCallbackBinding] at [/AsyncBPELProcessCallbackBinding/processResponse?WSDL]
Sun Nov 13 20:55:40 BRST 2011:INFO:Started mockService [Mock processResponse] on port [9898] at path [/AsyncBPELProcessCallbackBinding/processResponse]
Sun Nov 13 20:55:40 BRST 2011:INFO:Stopped MockService [Mock processResponse] on port [9898]
Adding intelligence to the test We were able to send a request and, asynchronously, receive back the response. However, how do we know that we received the correct response? We can use soapUI assertions for that. Go back to the Mock processResponse test step and click the Assertions Tab. Add the following assertions:
SOAP Request
WS-Addressing Request. Configure it as shown in Figure 15.
Figure 15 - Asserting that the callback
request is WS-Addressing compliant
Add an XPath Match assertion. This assertion allows us to validate the received request callback. In the XPath Expression section, click the Declare button to automatically declare all namespaces. Find the namespace...
/OTNTestingAsyncBPEL/AsyncBPELProject/AsyncBPELProcess
...and take note of its prefix. Next, enter the following (still in the XPath Expression section)...
//&prefix&:processResponse/&prefix&:result
...where &prefix& is the prefix for the declared namespace. For example, if the namespace is declared as the following:
declare namespace ns1='/OTNTestingAsyncBPEL/AsyncBPELProject/AsyncBPELProcess'
...you should specify //ns1:processResponse/ns1:result as the XPath string.
Now we can specify the value we expect inside the &result& element. The value should be the same as specified in the request: First test.... Your configuration should resemble Figure 16.
Figure 16 - XPath Match configuration To make it more fun, we can also add an assertion to the request. For example, we can
test if the HTTP code we received was 202 (accepted) & meaning the request was accepted by Oracle SOA Suite for further processing. To do so, add the assertion named Valid HTTP Status Codes and specify 202 as the valid code, as shown in Figure 17.
Figure 17 - Valid HTTP return codes Run the test. You should see both test steps of the test case marked as green, proving they passed all of the added assertions, as shown in Figure 18.
Figure 18 - It passed! Moving Forward The test illustrated above is useful. However, for real world usage, it will become quite tedious and error prone to use identical values for the request and the validated response. Wouldn't it be better to specify the value in a single place? Well, this is very easy to be accomplished in soapUI. The first step to achieve this is to create a property that can be read by all test steps. For that, open the test case and locate the Test Properties tab on the left inferior side of the window, as shown in Figure 19.
Figure 19 - Test Properties To add and use the property:
Click the plus-sign icon and name the property requestValue.
As a value, enter 123456.
On the request, change the contents of the &input& element to ${#TestCase#requestValue}. This is a special instruction to read a property that was specified at the Test Case level, named requestValue. The request SOAP message should resemble the following:
&soapenv:Envelope xmlns:soapenv=&http://schemas.xmlsoap.org/soap/envelope/&
xmlns:asy=&/OTNTestingAsyncBPEL/AsyncBPELProject/AsyncBPELProcess&&
&soapenv:Header/&
&soapenv:Body&
&asy:process&
&asy:input&${#TestCase#requestValue}&/asy:input&
&/asy:process&
&/soapenv:Body&
&/soapenv:Envelope&
Now, go back to the Mock processResponse test step, open the XPath Match assertion, and add ${#TestCase#requestValue} as the expected result, as shown in Figure 20.
Figure 20 - Assertion based
on the test case property
Now, run the test. It should complete successfully.
Go back to the FMW Control. You should see that the value specified for the property was sent, as shown in Figure 21.
Figure 21 - Property value sent correctly to the BPEL process Conclusion Test automation is an essential capability for any project. Thanks to WS-Addressing support in
Oracle SOA Suite and soapUI, you can take advantage of test automation to
synchronous and asynchronous processes.
Daniel Amadei is a principal consultant for Oracle Consulting in Brazil, specializing in SOA and integration technologies. In addition to his SOA experience, he has worked with Java technologies since 1999. Daniel's certifications include Oracle SOA Foundation Practitioner, Oracle SOA Architect Certified Expert, and Sun Certified Enterprise Architect (SCEA). &&
Oracle Cloud
Customers and Events
Email Subscriptions
Communities
Services and Store
Contact and Chat
US Sales: +1.800.633.0738[接口测试]接口测试之SoapUI学习汇总_接口测试-牛bb文章网
[接口测试]接口测试之SoapUI学习汇总 接口测试
所属栏目： &
接口测试之――SoapUI学习（1）WebService它是一种构建应用程序的普遍模型,可以在任何支持网络通信的操作系统中实施运行;它是一种新的web应用程序分支，是自包含、自描述、模块 化的应用，可以发布、定位、通过web调用。Web Service是一个应用组件,它逻辑性的为其他应用程序提供数据与服务.各应用程序通过网络协议和规定的一些标准数据格式（Http，XML，Soap)来访问Web Service,通过Web Service内部执行得到所需结果.Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他Web Service应用程序可以发现并调用它部署的服务。------------------在构建和使用Web Service时,主要用到以下几个关键的技术和规则:1.XML:描述数据的标准方法.2.SOAP:表示信息交换的协议.3.WSDL:Web服务描述语言.4.UDDI通用描述、发现与集成，它是一种独立于平台的，基于XML语言的用于在互联网上描述商务的协议。 FONT style="BACKGROUND-COLOR:rgb(0,255,0)"&http://www.niubb.net/zh_cn/index.aspx 这个网站中有不少免费的WebService可用------------------我个人觉得下面的这个理解起来更容易些，甚至我都觉得他有点想API，只是放到web中了而已-------------------------1，什么是 Web Service?Web Service 就是一个网络组件（一个可以通过网络访问的程序）。它有一个或多个端口（Port），这些端口用于接收客户端的请求，并返回响应请求和响应的 都是一种基于XML的消息。 不过这种消息遵循特定的格式（SOAP ）。 2，怎样调用 Web Service？可能这样说不太准确，应该是“怎样调用Web Service中定义的操作 ”每个Web Service 都有一个描述文件（WSDL ），它描述 一个 Web Service 的如下方面：（1）服务的端口（接收SOAP消息的端口）（2）服务提供的操作（3）操作的输入输出格式的定义（通过XMLSchema 定义输入输出格式）有了Web Service 的描述文件（WSDL ），我们就知道怎样调用这个Web Service 中定义的操作了。（1）通过服务提供的操作找到你想调用的操作（2）找到这个操作的输入格式的定义（XMLSchema ），按照这种输入格式构造一个SOAP消息（3）将这个SOAP消息发送到服务的指定端口（4）准备接收一个从Web Service服务器返回的 SOAP 响应吧 !3,Web Service服务器一个Web Service服务器，本质上和一个Web服务器是相同的。它主要做下面这些事：--& 监听网络端口（监听服务端口）--& 接收客户端请求（接收SOAP请求）--& 解析客户端请求（解析SOAP消息，将SOAP消息转换为数据对象）--& 调用业务逻辑 （调用Web Service实现类的特定操作，参数是由SOAP消息转换而来的数据对象）--& 生成响应 （将返回值转换为SOAP消息）--& 返回响应 （返回SOAP响应）=================================================================================XML什么是 XML?? XML 指可扩展标记语言（EXtensible Markup Language）? XML 是一种标记语言，很类似 HTML? XML 的设计宗旨是传输数据，而非显示数据? XML 标签没有被预定义。您需要自行定义标签。? XML 被设计为具有自我描述性。? XML 是 W3C 的推荐标准XML 与 HTML 的主要差异XML 不是 HTML 的替代。XML 和 HTML 为不同的目的而设计：XML 被设计为传输和存储数据，其焦点是数据的内容。HTML 被设计用来显示数据，其焦点是数据的外观。HTML 旨在显示信息，而 XML 旨在传输信息。没有任何行为的 XML。XML 是不作为的。也许这有点难以理解，但是 XML 不会做任何事情。XML 被设计用来结构化、存储以及传输信息。下面是 John 写给 George 的便签，存储为 XML：这个标签有标题以及留言。它也包含了发送者和接受者的信息。但是，这个 XML 文档仍然没有做任何事情。它仅仅是包装在 XML 标签中的纯粹的信息。我们需要编写软件或者程序，才能传送、接收和显示出这个文档。XML 仅仅是纯文本XML 没什么特别的。它仅仅是纯文本而已。有能力处理纯文本的软件都可以处理 XML。不过，能够读懂 XML 的应用程序可以有针对性地处理 XML 的标签。标签的功能性意义依赖于应用程序的特性。通过 XML 您可以发明自己的标签上例中的标签没有在任何 XML 标准中定义过（比如 &to& 和 &from&）。这些标签是由文档的创作者发明的。这是因为 XML 没有预定义的标签。在 HTML 中使用的标签（以及 HTML 的结构）是预定义的。HTML 文档只使用在 HTML 标准中定义过的标签（比如 &p& 、&h1& 等等）。XML 允许创作者定义自己的标签和自己的文档结构。XML 不是对 HTML 的替代XML 是对 HTML 的补充。XML 不是对 HTML 的替代，理解这一点很重要。在大多数 web 应用程序中，XML 用于传输数据，而 HTML 用于格式化并显示数据。XML 应用于 web 开发的许多方面，常用于简化数据的存储和共享。XML 把数据从 HTML 分离如果你需要在 HTML 文档中显示动态数据，那么每当数据改变时将花费大量的时间来编辑 HTML。通过 XML，数据能够存储在独立的 XML 文件中。这样你就可以专注于使用 HTML 进行布局和显示，并确保修改底层数据不再需要对 HTML 进行任何的改变。通过使用几行 JavaScript，你就可以读取一个外部 XML 文件，然后更新 HTML 中的数据内容。XML 简化数据共享在真实的世界中，计算机系统和数据使用不兼容的格式来存储数据。XML 数据以纯文本格式进行存储，因此提供了一种独立于软件和硬件的数据存储方法。这让创建不同应用程序可以共享的数据变得更加容易。XML 简化数据传输通过 XML，可以在不兼容的系统之间轻松地交换数据。对开发人员来说，其中一项最费时的挑战一直是在因特网上的不兼容系统之间交换数据。由于可以通过各种不兼容的应用程序来读取数据，以 XML 交换数据降低了这种复杂性。XML 简化平台的变更升级到新的系统（硬件或软件平台），总是非常费时的。必须转换大量的数据，不兼容的数据经常会丢失。XML 数据以文本格式存储。这使得 XML 在不损失数据的情况下，更容易扩展或升级到新的操作系统、新应用程序或新的浏览器。XML 使您的数据更有用由于 XML 独立于硬件、软件以及应用程序，XML 使您的数据更可用，也更有用。不同的应用程序都能够访问您的数据，不仅仅在 HTML 页中，也可以从 XML 数据源中进行访问。通过 XML，您的数据可供各种阅读设备使用（手持的计算机、语音设备、新闻阅读器等），还可以供盲人或其他残障人士使用。XML 用于创建新的 Internet 语言很多新的 Internet 语言是通过 XML 创建的：其中的例子包括：? XHTML - 最新的 HTML 版本? WSDL - 用于描述可用的 web service? WAP 和 WML - 用于手持设备的标记语言? RSS - 用于 RSS feed 的语言? RDF 和 OWL - 用于描述资源和本体? SMIL - 用于描述针针对 web 的多媒体假如开发人员都是理性的假如他们都是理性的，就让未来的应用程序使用 XML 来交换数据吧。未来也许会出现某种字处理软件、电子表格程序以及数据库，它们可以使用纯XML =================================================================================WSDL 什么是 WSDL?? WSDL 指网络服务描述语言? WSDL 使用 XML 编写? WSDL 是一种 XML 文档? WSDL 用于描述网络服务? WSDL 也可用于定位网络服务? WSDL 还不是 W3C 标准WSDL 可描述网络服务（Web Services）WSDL 指网络服务描述语言 (Web Services Description Language)。WSDL 是一种使用 XML 编写的文档。这种文档可描述某个 Web service。它可规定服务的位置，以及此服务提供的操作（或方法）。WSDL 文档仅仅是一个简单的 XML 文档。它包含一系列描述某个 web service 的定义。WSDL 文档结构WSDL 文档是利用这些主要的元素来描述某个 web service 的：一个 WSDL 文档的主要结构是类似这样的：PS：实际上以上的结构，可以用浏览器打开一个具体的webservice来看，比如以下查询手机归属地的wsdl格式的webservice.cn/webservices/EnglishChinese.asmx?wsdlWSDL 文档可包含其它的元素，比如 extension 元素，以及一个 service 元素，此元素可把若干个 web services 的定义组合在一个单一的 WSDL 文档中。WSDL 端口&portType& 元素是最重要的 WSDL 元素。 它可描述一个 web service、可被执行的操作，以及相关的消息。 可以把 &portType& 元素比作传统编程语言中的一个函数库（或一个模块、或一个类）。WSDL 消息&message& 元素定义一个操作的数据元素。 每个消息均由一个或多个部件组成。可以把这些部件比作传统编程语言中一个函数调用的参数。WSDL types&types& 元素定义 web service 使用的数据类型。 为了最大程度的平台中立性，WSDL 使用 XML Schema 语法来定义数据类型。WSDL Bindings&binding& 元素为每个端口定义消息格式和协议细节。WSDL 实例这是某个 WSDL 文档的简化的片段：在这个例子中，&portType& 元素把 "glossaryTerms" 定义为某个端口的名称，把 "getTerm" 定义为某个操作的名称。操作 "getTerm" 拥有一个名为 "getTermRequest" 的输入消息，以及一个名为"getTermResponse" 的输出消息。&message& 元素可定义每个消息的部件，以及相关联的数据类型。对比传统的编程，glossaryTerms 是一个函数库，而 "getTerm" 是带有输入参数 "getTermRequest" 和返回参数 getTermResponse 的一个函数。接口测试之――soapui学习（2）上一篇 / 下一篇
16:10:47 / 个人分类：接口测试查看( 124 ) / 评论( 0 ) / 评分( 0 / 0 )（该文转自流口水的小猪的博客，因为分享不过来所以就copy了）学习自 /blog/284387通过这一节的学习，更真切的感觉到了什么是webservice，我们怎样自己写一个简单的webservice，这样，对我们后面利用soapUI测试webservice有帮助。如果你都不知道你测试的东西是什么，就直接测试，那似乎有点盲目。???? 开发webservice工作准备 开发简单的webservice 利用tomcat+axis2发布webservice 调用（测试）webservice=========开发WebService的环境准备==========使用axis2----------------axis2 是新一代的web service开发工具，它会让你的web service开发变得轻松，快捷。下面让我们以一个实际的例子来体验一下。首先，工欲善其事，必先利其器。就让我们先做好一些必备的准备工作吧。1.下载axis2 的2进制的包和war,现在的最新版本是1.4.1 发布时间是地址分别是：http://apache./ws/axis2/1_4_1/axis2-1.4.1-bin.zip http://apache./ws/axis2/1_4_1/axis2-1.4.1-war.zip2.把下载后的war放入tomcat的webapps目录里，然后启动tomcat，这样war包就会自动解压为目录axis2在浏览器中输入http://localhost:7890/axis2/ ，如果一切正常你会看到下面的画面 （这个东西，我以前就弄过，所以基本很快就搞定了）3，就开始准备一下axis2的eclispe的插件了。axis2的eclispe插件分为2个，一个是帮助我们生成aar文件的，另一个是帮我们用wsdl文件生成stub代码的。下载地址是http://www.niubb.netdyn/mirrors/mirrors.cgi/ws/axis2/tools/1_4_1/axis2-eclipse-service-archiver-wizard.ziphttp://www.niubb.netdyn/mirrors/mirrors.cgi/ws/axis2/tools/1_4_1/axis2-eclipse-codegen-wizard.zip下载完2个压缩文件后，可以直接把解压后的文件拷贝到plugins目录中，也可以在links目录中写文件路径的方式来安装插件，安装完插件后，打开 eclipse，在package explorer 中点击右键---&选择new----&other 如果安装正确你会看到（这个地方只有有点要说明：就是加压后的文件不能直接放，注意到解压后目录是 \axis2-eclipse-service-archiver-wizard\Axis2_Service_Archiver_1.3.0,我们要放的是Axis2_Service_Archiver_1.3.0这个文件夹，而不是上一层文件夹，刚开始我直接解决，拖过去的，原来拖的是 axis2-eclipse-service-archiver-wizard，重启eclipse怎么也找不到插件，找了很久的原因才发现）这样我们的准备工作就好了哦。=========开发一个简单的WebService========== 开发、发布自己的webservice1. 首先自己写一个java类代码如下：这里特别注意，刚开始，编辑好后要保存，eclipse会自动的编辑成.class 文件，需要把存放.class文件的目录记住，我这里是C:\Documents and Settings\Administrator\workspace\junit_study\ 这个后面发布的时候用的到。（原文中没有详细说明这个）在eclispe 的package Explorer 中点击右键，在菜单中选择新建---&other...-----&Axis2 Service Archiver点击next之后进入了选择 wsdl文件，这里我们选择skip wsdl点击next之后，进入的是选择jar文件的页面，这里我们没有外部的jar，所以点击next直接跳过这个页面。点击next之后，进入的是选择xml页面，这里我们选择的是自动生成xml，也就是勾选 Generate the service xml automatically这一项5.点击next之后，进入的是生成xml文件的页面，在service name 里填写这个服务所起的名字，这里我起名为MyWebserver,然后在class name 中填写要发布的类，这里一定要写全路径，写好后就可以点击load 按钮，如果一切ok的话，你会看到如下画面点击next 后，进入的是输出artiver文件的页面，先要在output File location 中选择要输出的路径，在output File Name中输入artiver文件的名称。我起的名字是my_service (这里输入的filename只是一个文件名而已，无其他什么意义)=========发布WebService==========这样，在我的桌面上就生成了一个my_service.aar文件，将其放入到\Tomcat 6.0\webapps\axis2\WEB-INF\services中，打开http://localhost:7890/axis2/services/listServices点击上面的HelloWorld连接，就打开了如下的页面原来如此，这下我就知道soapUI可以上场了。=========测试WebService==========-------PS：原文中的三其实就是说的用java来调用我们刚才发布的webservice，我只是用了soapUI来调用了而已。接口测试之――soapui学习（3）上一篇 / 下一篇
16:18:01 / 个人分类：接口测试查看( 123 ) / 评论( 0 ) / 评分( 0 / 0 )（该文转自流口水的小猪的博客，因为分享不过来所以就copy了）已经学习总结了两次的soapui的学习，但还没真正进入主题的学习，都是在打围。现在要正式来看看soapUI了。===========有关SoapUI==============首先，有关soapUI的官方网站似乎有两个http://www.niubb.net & http://www.niubb.net我经常都被搞糊涂，两个上面都可以下载soapui，不过只有前者有soapui的教程。据我所知，soapui有windows和linux版本。我学习的主要是windows版本。且虽然能够在网站上申请trial license，但可能还是不及soapui pro的功能全。并且很显然，还有loadUI就是用来测试webservice的性能的吧。有关soapUI / soapUI pro /loadUI 的比较，请参考http://www.niubb.net 网站的 About soapUI ? Product Comparison 。这样有具体的比较，但我们如果不是专业的测试webservice，或者说我们是客串测试webservice，soapui够用了吧。===========有关SoapUI的安装省略，按提示的图形界面安装即可=====================创建project，添加WSDL============project的soapUI测试webservice的测试基础，在创建project之后你才能干其他事情：功能测试，性能测试等等工作。创建project 和WSDL 比较简单，右键--》【New soapUI Project】--& 输入project name/WSDL--》【ok】直接贴图好了：当然这里的WSDL也可以暂时不输入，只写一个project name，后面在创建好了project右键添加也行。现在可以直接运行刚才的导入的webservice的request了接口测试之――soapui学习（4）上一篇 / 下一篇
16:19:06 / 个人分类：接口测试查看( 97 ) / 评论( 1 ) / 评分( 5 / 0 )注：（该文转自流口水的小猪的博客，因为分享不过来所以就copy了）当创建好project并且导入了WSDL后，我们就可以开始创建测试用例以便开展测试了。SoapUI有多种方法添加测试用例，且可以通过Groovy或者javaScript脚本来增强脚本的功能。下面我们要做的事是：1 为WSDL创建一个test case2. 为test case加上一点断言assertion3. 运用test case为WSDL创建test case1.1 展开Webservice，右键选择“Add to request ”或者在request页面选择添加testcase1.2. 在后续弹出的创建TestSuit对话框中，输入TestSuit的名称1.3.确定后要求输入TestCase对话框1.4.接着为这个测试用例添加request，这才是测试用例的核心1.5.确定后就能看到如下的界面这时我们可以看到TestSuite--》TestCase--》Request的组织结构另外就是点击不同的结构目录，右框中会根据点击的不同显示页面有所不同。 到了这一步，我们就可以打开TestCase中的Request，输入参数，进行测试了。到了上面，显然我们的测试用例不太可能这么简单，需要添加一些检查点（就是soapUI的assertion）。下面我们就添加assertion=============================添加Assertion2.1 双击Request，打开request页面，点击“Adds an assertion”2.2 在弹出的选择Assertion中选择断言的类型我们添加一个Contain类型的断言（或者叫检查点）2.3 在接着的Contains断言的具体属性中，输入要检查的内容，例如我们后面要查询London的天气，这里我们输入London，并勾选上忽略大小写确定后，你会发现你assertion是Failed这里要说明的是1. 失败是正常的，因为我们之前运行过这个用例，在添加assertion后它会立即在上一次执行的结果中执行一次assertion2. 我们只添加了一个assertion，为什么有两个呢。因为SOAP Response是测试用例默认自带的assetion==========================执行用例3.1. 点击执行，我们可以看到测试用例执行是成功的还要注意，测试的结果，可以以多种方式显示：XML / Raw / Outline / Overview 其实我们再仔细看request也是有几种显示形式的xml/ Raw /Outline /Form ，只是一般我们用form形式的而已3.2. 那么我们修改一下查询条件为seattle，测试用例还能成功吗？----------------------PS:需要说明的是，我们在测试网上提供的免费的webservice的时候，有时候webservice暂停了服务，这时我们测试是永远也不能成功的，那么我们如何判断webservice的服务已经暂停了呢，我们只需要在浏览器中打开webservice的WSDL地址，如果能显示xml文件，就说明服务是好的。当然这是一般的判断条件，并不绝对。接口测试之――soapui学习（5）上一篇 / 下一篇
16:20:34 / 个人分类：接口测试查看( 66 ) / 评论( 0 ) / 评分( 0 / 0 )注：（该文转自流口水的小猪的博客，因为分享不过来所以就copy了）通过（4）的学习，我们知道了soapUI提供的多种类型的assertion，那么我们来看看常用的assertion首先看看assertion的管理我们常用的? Contains - checks for the existence of aspecified string (see below)? Not Contains - checks for the non-existence ofa specified string (see below)? Reponse SLA - check the response time againsta specified value (see below)? XPath Match - compares the result of an XPathexpression to an expected value （估计用的不多）? XQuery match - compares the result on an XQueryexpression to an expected value (估计用的不多)? Script. - runs an arbitrary script. that canbe used to validate the received message asdesired其中的contains/Not Contains 基本差不多，添加的界面如下其中一是要注意可以忽略大小写二是可以用正则表达式，这个东东还是可以去实践实践的，学习地址在http://www.niubb.netjavase/7.b12/java/util/regex/Pattern.html接口测试之――soapui学习（6）上一篇 / 下一篇
16:21:40 / 个人分类：接口测试查看( 104 ) / 评论( 1 ) / 评分( 3 / 0 )注：（该文转自流口水的小猪的博客，因为分享不过来所以就copy了）soapUI教程很体贴，为我们做了一个webservice的实例，并且利用soapUI的webservice模拟功能（MockService）为我们学习soapUI提供了方便。下面就总结一下这个自带的webservice以及其他内容。 所有学习来自于http://www.niubb.netGetting-Started/web-service-sample-project.html 只是其他对相应的request没有做太多的说明，我进行学习进行一些补充说明。=======soapui自带的webservice实例======我们用的东东是 ..\soapUI-Pro-3.6.1\Tutorials 文件夹下的sample-soapui-pro-project.xml-----------1. 打开project （import preject）。在Project上右键选择“Import Project”2. 再弹出的选择框中浏览选择sample-soapui-pro-project.xml3. 完成后的显示结果4. 展开SoapBinding从这里我们可以看到这个服务有5个Request，login/logou/search/buy/return, 在右方可以看到有request的form格式，也就是这个request需要的参数。分别点击后能看到不同request的不同参数。上面没有介绍return请求，是我没看懂这个return是干什么的，自带的测试用例中也没有怎么用这个return。在学习中利用这个服务时，可以分别点击以上的请求自己试试看。在执行前，一定要运行MockService=============MockService=========================================================soapUI的MockService功能事实上，我到现在也没搞明白MockService到底是在模拟什么，根据我看的，应该是模拟的服务的response，并且这个服务的WSDL文件已经创建好了的。不明白如果WSDL都已经好了，那不是是webservice好了吗？先不管了，学习如何创建再说吧，以后再体会。 还是以soapUI学习（2）中创建的webservice为例来创建MockService吧1. 创建project，使用wsdl:http://localhost:7890/axis2/services/HelloWorld?wsdl2. 创建MockService选择一个soap右键选择Generate MockService创建好后就如下3. 编写MockService的Response，也就是修改Response （其实说白了，做模拟就是模拟返回值，输入的参数我们当然是知道的）将？改为一个模拟的返回值，例如我们这里改为“Bill says it is good”4. 创建一个Request 名称为：MockRequest ,并且关闭tomcat（为了看出是MockService在起作用，而不是原来真实的webservice起作用），启动MockService后执行MockRequest因为这里没有用到name这个参数做任何的事情，所以无论在name参数中输入什么，都返回“Bill says it's good”有关MockService的功能，官方网站上讲的很多，这里只是了解一下而已，我想除非是真正大量测试Webservice，否则对soapUI基础功能有所了解就能应付一般的webservice测试需要了吧。接口测试之――soapui学习（7）上一篇 / 下一篇
16:23:23 / 个人分类：接口测试查看( 70 ) / 评论( 0 ) / 评分( 0 / 0 )注：（该文转自流口水的小猪的博客，因为分享不过来所以就copy了）??? soapUI的属性概念 Transfer property ---直接传递到具体操作 Transer Property ---通过变量存放--------------------------------------------------------------------====================soapUI的属性概念====================经过学习，我们知道，soapUI的每个层次都可以创建属性Property这些属性，可以用来传递参数，例如可以在testsuite中创建两个属性：username/password，用来进行登录1. 首先我们创建一个测试用例，添加登录request2. 在testsuite层次上创建两个属性username=Login / password=Login1233.打开request，在form形式下点击输入框后面的“Get Data”按钮选择创建的属性参数。分别设置username/password4. 接着会弹出初始值对话框，注意这里输入的值要和创建属性时的值一致，不然输入的值就把原来属性值覆盖了另外，注意我这里是使用的soapUI自带的Sample Project ，并且要使用MockService的Endpoint：5.设置好后就可以运行啦。按上面的操作应该可以运行成功的。如果登录失败，提示“Already Logged In”，那么只要把MockService重启一下就可以了。其实有关soapUI的Property的应用，在自带的sample project中应用的比较充分，值得学习==================================================================上面还没说到正题呢，我们要说的是Property transfer。我们要进行login---》logout，其中login产生了sessionid，并且使用这个sessionid进行logout。首先看看Property transfer的主要页面，就是从Source传向Target。根据soure到target的两种方式，我们进行两种说明。两种方式分别是：一种是直接将soure获得的值传到下一个具体的步骤；另一种是将soure中获得的值存在一个变量中，以后直接引用，这个的好处是可以使用多次。====================将soure获得的值传到下一个具体的步骤====================1. 首先创建测试用例，添加3个步骤：login --》PropertyTransfer --》logout2. 双击PropertyTransfer，打开编辑页面添加PropertyTansfer，名称：SessionIDSource中选择：Test Request:login Property:Response 点击Xpath图标设置Xpath（在sessionid的数字上点击一下，就会出现下面的Xpath）Target中选择：Test Request:logout Property:Request 点击Xpath图标设置Xpath 设置好后的页面情况3. 试着运行一下这个测试用例，运行后切换到PropertyTransfer页面能看到transfer log，从这里我们能看到传输的值对不对，如果不是login产生的sessionid，那就说明不对，就要检查原因了。====================将soure中获得的值存在一个变量中====================1. 同样的，我们创建一个测试用例，login --》PropertyTransfer --》logout2. 不同的是，我们在Testcase的层次上新建一个属性login_session,值随便输入一个即可。这个login_session就用来做变量存储从login response中获得的session3.打开PorpertyTransfer的编辑页面新建session_id ， source: Test Request:login Property:Response, 选择Xpth，选中Response中的sessionidtarget：TestCase_luyx2 Property:login_session4. 接着，打开logout，为logout的session选择参数，选择后的结果是“${#TestCase#login_session}”5. 一下OK，运行，切换到PropertyTransfer，同样有log显示这就完成了将soure中获得的值存在一个变量中，在后面多次使用的实验了，虽然我们这样只用了一次而已，但也能看到用多次只是在相应要使用的地方参数化就行了。我们快速地在原来的测试用例上添加一个步骤search，参数化sessionid，给searchestring一个固定的值，运行也是可以的哦接口测试之――soapui学习（8）上一篇 / 下一篇
16:24:40 / 个人分类：接口测试查看( 97 ) / 评论( 0 ) / 评分( 0 / 0 )注：（该文转自流口水的小猪的博客，因为分享不过来所以就copy了）以soapUI自带的sample project为例，学习利用DataSource进行login --》search（循环）--》logoutDataSource 的类型有：Data Connection/ Grid / File/ XML /groovy /excel/directory/JDBC为了让DataSource能循环起来，还要和DataSource Loop结合，下面分布学习Grid / File /excel /Data Connection1. 创建testcase，添加基础的step：login/ search/ logout并且在search中对2. 新增step：DataSource并且新增一个Property:search_string, 选择类型：Grid 新增参数：Item 1 / Item 2 /Item 3 / Item 4在新参数后，可以运行DataSource中的绿色运行按钮，可以测试一下datasource是否可用（下面有data log查看）3. 新增step:DataSource Loop, 在DataSourceLoop配置对话框中选择datasource step,选择target step4. 在search request中配置相关session id / searchstringsession id的参数设置，就是选择login response产生的session （之前的学习中有介绍过）searchstring的参数设置类似，这里我们选择在DataSource中添加的search_string5. 以上设置好后，就能运行测试用例了，通过TestCase log /Http Log 我们能看出测试用例确实利用了我们添加的参数在循环测试上面学习了DataSource中最简单的Grid类型，下面接着学习File /Excel / Dataconnection 其实我们只有简单改变一下步骤2中DataSource的配置，根据类型的不同进行相应的设置就可以了File类型---------------------------准备格式如下的文件（参数必须一行一行写，我尝试用，隔开不起作用）在配置项中选择相应的文件，运行测试一下，一般没什么问题Excel类型----------------------------准备excel文件，注意保存为2003格式，2007格式似乎不能读取配置一下DataConnection类型 （我现在的是mysql连接）---------------------------首先在mysql数据库中准备数据配置data connection 正确填写各项，并利用Test connection测试连接是否成功注意的是，在配置之前，检查 soapUI 安装目录下的 \jre\lib\ext 中是否有mysql jdbc的driver，如果没有必须下载放进行，否则不能连接成功我从CSDN中下载的mysql-connector-java.jar配置好连接后，有相应的sql 查询语句配置页面，也可以自己写，我这些的是: select *执行一下，看看能不能查询出结果 （data log 中显示出来了，但具体的值没显示出来，不知道为何，但确实可用）接口测试之――soapui学习其他（9）上一篇 / 下一篇
16:25:54 / 个人分类：接口测试查看( 73 ) / 评论( 0 ) / 评分( 0 / 0 )小结一下：因为是突然接到项目要进行接口的测试的要求，难免有些仓促，之前也没有用过这个工具，也没有提供资料，在网上收罗了很久发现了此文。对使用这个工具的新手来说的确是比较不错的文档，其实官网也有资料，但是都是英文的，要去慢慢的理解消化，英语水平有限，时间又来不及了，有现成的从零开始的文档，还是非常高兴的。软件的下载地址可以在官网下，http://sourceforge.net/projects/soapui/有免费版本，也有收费的版本，收费的可以试用7天。收费的主要是还有一些附加的功能，如对此接口的性能测试，安全性测试等。要想破解的可以自己去CSND找一下,个人也是尊重知识产权的，但公司角度要节约经费，我也没有办法。主要是中国的大环境不太好，没有重视对知识产权的保护，导致我们没有创新，即使有了也会很快被山寨，正牌反而失去了市场。可谓是一直在模仿，从未去超越，所有时至今日中国成了廉价，劣质，山寨的代名词，对知识产权的尊重才是我们科技强国的出路。扯远了。。。。这个工具的其他扩展功能还有带继续研究。欢迎您转载分享：
更多精彩：