全部版块 我的主页
论坛 计量经济学与统计论坛 五区 计量经济学与统计软件 winbugs及其他软件专版
2191 3
2015-08-13

  • SoapUI Cookbook
  • By: Rupert Anderson

  • Publisher: Packt Publishing

  • Pub. Date: February 27, 2015

  • Web ISBN-13: 978-1-78439-871-2

  • Print ISBN-13: 978-1-78439-421-9

  • Pages in Print Edition: 328

  • Subscriber Rating: [0 Ratings]



二维码

扫码加我 拉你入群

请注明:姓名-公司-职位

以便审核进群资格,未注明则拒绝

全部回复
2015-8-13 10:45:39
What this book covers

Chapter 1, Testing and Developing Web Service Stubs With SoapUI, provides a view on how to support early application development. The main theme here is how SoapUI can be used to generate, develop, and test basic RESTful and SOAP web service stubs using Apache CXF. Discovering, updating, and refactoring tests are also covered here. Apart from the pro-only WSDL refactoring and REST discovery recipe, this chapter is fairly basic in terms of SoapUI testing concepts. Although some readers may prefer not to start with this chapter, for example, if they already have basic SoapUI skills or no interest in developing Java web service stubs.

Chapter 2, Data-driven Testing and Using External Datasources, introduces the theme of data-driven testing and Groovy scripting as a key enabler. This chapter also introduces the building blocks of SoapUI properties, simple database handling, file handling, and how to use open source libraries in Groovy TestSteps. This chapter is fairly fundamental going forward, especially if you do not already know these concepts.

Chapter 3, Developing and Deploying Dynamic REST and SOAP Mocks, builds directly on the Groovy scripting and database and property handling from the previous chapter to show how to develop dynamic mock services. We also see how to deploy the mocks as WAR files to potentially support early application development. Mock services will be used to support recipe samples across several chapters.

Chapter 4, Web Service Test Scenarios, uses the fundamentals of the first three chapters to demonstrate how SoapUI can be used to solve some more high-level, scenario-based REST and SOAP web service testing problems. This is probably the most balanced chapter in terms of general SoapUI testing, as the subsequent chapters are more specialized.

Chapter 5, Automation and Scripting, is all about how SoapUI tests and mocks can be run from scripts with a view to continuous integration. Examples include command-line, Maven, Java, JUnit, Groovy, and Gradle scripts. Scripting of security and load tests will be looked at in chapters 7 and 9 respectively.

Chapter 6, Reporting, looks at the reporting features that are available to the scripts of the previous chapter, custom reporting with Groovy, and how Jenkins or similar CI tools can run the scripts and publish test results as JUnit style reports. Pro version only coverage reporting is also explored.

Chapter 7, Testing Secured Web Services, is all about using SoapUI to test APIs that feature HTTP Basic, Digest and Form, transport layer security (TLS), client certificate, and WSS security. A core learning is the X.509 certificate creation and handling within SoapUI. The security-scanning functionality of SoapUI is also explored.

Chapter 8, Testing AWS and OAuth 2 Secured Cloud Services, mainly explores how OAuth 2 code and implicit grant flows work and how SoapUI supports them. Amazon AWS Access Key Authentication is also explained and demonstrated using Groovy. All examples use popular cloud service providers such as Dropbox, Google, Gmail, and AWS, and involve RESTful web services.

Chapter 9, Data-driven Load Testing With Custom Datasources, discusses how to understand and deal with datasource concurrency issues when running multithreaded data-driven load tests. Distributed datasources and scripting of load tests are also covered.

Chapter 10, Using Plugins, focuses on using, rather than developing, some of the example plugins that are currently available for SoapUI. The basics of how plugins work is also briefly covered, as well as how to provide them in scripts such as Gradle and Maven, where a SoapUI installation is not normally present. While this chapter is near the end, it's actually quite easy to do, even though the understanding of how plugins work might seem more advanced.

Chapter 11, Taking SoapUI Further, is mostly about using SoapUI from its source code and how to develop SoapUI extensions and plugins using Groovy and Gradle. Even though developing extensions is advanced and beyond many people's needs, the examples should be quite doable, especially if you've read the other chapters. Also, building SoapUI from scratch is not hard at all and can be very useful, even in some of the earlier chapters.


二维码

扫码加我 拉你入群

请注明:姓名-公司-职位

以便审核进群资格,未注明则拒绝

2015-8-13 10:47:16
Generating a WSDL-first web service using SoapUI tool integration

This recipe shows how to configure SoapUI (Apache CXF) tool integration to generate a runnable Java web service with an empty implementation using its WSDL. This could be useful if you need a quick menu-driven way to create a SOAP web service that can be implemented and deployed separately to SoapUI.



How to do it...

First, we need to configure SoapUI to be able to generate and build the invoice web service. Then, we can run it as a standard Java executable. Perform the following steps:

  • In SoapUI, go to Tools | Apache CXF, and when the Apache CXF Stubs window appears, click on the Tools button to bring up the SoapUI Preferences window. Here, browse to the location where you downloaded Apache CXF, select the bin directory, and then click on OK:
  • Next, we need to configure the generation options under the Basic tab. The main points are:
    • WSDL location: For example, <chapter1 samples>/soap/invoicev1/wsdl/invoice_v1.wsdl.
    • Output directory: This is where the generated source code will end up; for example; <chapter1 samples>/soap/invoicev1/src/main/java.
    • Package Structure: This is for the generated source code; for example, ws.invoice.v1.
    • Artifact Options: Only tick Server and Implementation. However, the client and Ant build file options are also available. We will be using SoapUI as our client and won't require Ant.
  • To automatically compile our generated service code, under the Advanced tab, do the following:
    • Tick Compile.
    • Supply a Class Folder value for the resulting Java class files, for example, <chapter1 samples>/soap/invoicev1/target/classes.
    • Tick Validate WSDL (optional) under the advanced tab to check the structure and get basic WS-I compliance checks on your WSDL. Note that the invoice_v1.wsdl should not produce any output with this option.
    • Leave all other fields and checkboxes unchanged.
  • Under the Custom Args tab, enter –wsdlLocation invoice_v1.wsdl in Tool Args. This tells the web service code where to look for the WSDL file at runtime. Setting the value like this means thatinvoice_v1.wsdl is expected to be the root of the classes directory. More on this in the next section.
  • Now, we are ready to click on Generate! If all goes well, you should see an output similar to the following:

    You should also see the following generated Java source files in your output folder, for example:

    复制代码


二维码

扫码加我 拉你入群

请注明:姓名-公司-职位

以便审核进群资格,未注明则拒绝

2015-8-13 10:49:35
Developing a SOAP web service test-first

SoapUI is often used to retrofit tests around web services that are already at least partially developed. To follow a test-first or test-driven development (TDD) approach requires that we first set up failing tests and then provide a service implementation in order to pass them. In this recipe, we'll see how SoapUI can be used to facilitate test-first development for the invoice web service generated in the previous recipe.

How to do it...

Firstly, we'll set up a couple of simple failing tests to assert what we expect back from the getInvoice operation and then provide basic implementation to pass them. Next, we'll update the invoice WSDL definition to provide an additional createInvoice operation, write new failing tests, and finally provide basic code to pass those. Perform the following steps:

  • To create the SoapUI project and generate the initial PortBinding, Test Suite, TestCase, and Test Request TestStep, right-click on your Workspace and select New SOAP Project. In the window, enter/select the following and click on OK:
    • Project Name: InvoiceService
    • Initial WSDL: chapter1 samples>/soap/invoicev1/wsdl/invoice_v1.wsdl
    • Leave Create Requests ticked and also tick Create TestSuite
  • In the Generate TestSuite window, select the following options and click on OK:
    • Leave Style as One TestCase for Each Operation
    • Change Request Content to Use existing Requests in Interface
  • Accept the suggested TestSuite name as InvoicePortBinding TestSuite in the pop up and click on OK. All expected SoapUI test artifacts should now be generated in your project.
  • Now, we can write a simple failing test to assert what we expect a successful getInvoice request to return. Under the first TestStep option, double-click on getInvoice and you should see the SOAP request:
    复制代码

  • Change the invoiceNo (?) value to something more memorable, for example, 12345.
  • Now, start the stub invoice service generated in the previous recipe and submit the request by clicking on the green arrow. You should see a stubbed response, like the one shown in the following code:
    复制代码

  • Next, let's create some SoapUI Assertions to specify the invoice property values we expect to see:
    • invoiceNo = 12345
    • company = Test Company
    • amount = 100.0



Since we're dealing with SOAP XML, let's add 3 XPath Assertions to check these values in the response. SoapUI Pro users will find this easy, thanks to the convenient XPath builder. Open source users can either be 'hardcore' and write them from scratch or just copy the details provided.

二维码

扫码加我 拉你入群

请注明:姓名-公司-职位

以便审核进群资格,未注明则拒绝

相关推荐
栏目导航
热门文章
推荐文章

说点什么

分享

扫码加好友,拉您进群
各岗位、行业、专业交流群