Mastering SOAP API testing. Testing Web Services Download a Web Service for Testing

API usage and dependence on web services have increased in recent years. Here is a list of 12 web service testing tools that will help you tremendously.

Over the past few years, the popularity and use of web services or APIs has increased. A web service or API is a set of procedures or software components that help an application interact with or execute a process / transaction by forming a connection between another application or server. Basically there are two types of web services: REST and SOAP for transferring data and information over the Internet protocol.

Because these web services are available on the Internet and spread over different networks, they are vulnerable to viruses and security threats that affect the processes based on them. Hence, testing web services or APIs becomes necessary to ensure correct operation and correct response to requests. Software testing is a promising area in the IT field, you can get the necessary knowledge at

There are several commercial and free testing tools on the market to test their connectivity, response, and performance. These testing tools automate testing for a specific scenario such as functional testing, load testing, performance testing, and more.

Here are 12 great web services testing tools to consider for your API or web service testing requirements:

SoapUI

SoapUI is an open source cross-platform testing tool. It can automate functional, regression, conformance, and load tests for both SOAP and REST services. It is easy to use and supports leading technologies and standards for modeling and stimulating the behavior of web services.

Key features:

• Provides reports for print, export, and HTML at the Project, TestSuite, TestCase, or LoadTest level.
• Interoperability with Hudson, Bamboo, Maven, ANT and JUnit.
• Allows you to develop your own set of functions in the form of SoapUI plugins.
• Records, monitors and displays all data.
• Supports WS-Security and SSL decryption.

TestingWhiz

TestingWhiz is a “codeless” test automation tool that is compatible with API / web services. It allows functional, interoperability and load testing, and work with REST and SOAP web services through a WSDL interface over HTTP and FTP.

Key features:

• Supports string comparison to validate API response.
• Helps in finding API defects with integrated bug tracking tools such as JIRA, Mantis, and Fogbugz.
• Creates visual logs and test reports via email.
• Provides continuous integration with Jenkins, Bamboo & Hudson.
• Supports testing based on data and keywords.

SOAPSonar

SOAPSonar provides end-to-end web service testing for HTML, XML, SOAP, REST, and JSON. It provides functional testing, performance testing, interoperability testing and security testing using OASIS and W3C standards.

Key features:

• Supports testing for XSD mutation vulnerabilities.
• Provides comprehensive analysis of WSDL and Schema.
• Performs load testing with simulated behavior and multiple concurrent loading processes.
• Provides reports in XML, DOC, XLS, PDF, RTF and RPT formats.
• Interacts with the HP Quality Center.

SOAtest

SOAtest is a tool for testing and validating APIs and API driven applications. It provides robust function block support, integration, security, simulation, and load testing with technologies such as REST, JSON, MQ, JMS, TIBCO, HTTP, and XML.

Key features:

• Provides End-to-End Testing
• Supports 120+ protocols / message types.
• Comes with an easy to use interface.
• Helps to create complex, extensible and reusable tests without coding.
• Supports continuous integration testing

TestMaker

TestMaker is an open source tool for testing and monitoring the performance of web services and SOA applications using PushtoTest. It works in Jython (Python written in Java). TestMaker can repurpose Selenium tests, SoapUI tests, Sahi tests, or any tests written in Groovy, Java, Python, PHP, Ruby and Perl into functional, load tests.

Key features:

• Uses command line prompt to test functionality, load and performance.
• Intuitive look and feel with standard multi-window IDE.
• Provides a control panel for running tests and displaying results in real time.
• Allows access to all Java libraries and Jython language classes.

Postman

Postman is another API / web services testing tool that has powerful HTTP client support. It has an easy-to-use query builder that lets you write test cases and manage response data and response times for efficient testing and API test case management.

Key features:

• Allows you to organize your API into functions called Postman assemblies.
• Facilitates collaboration and sharing of API data and controls.
• Allows writing logic tests to the Postman Interface.

vRest

VRest is a tool dedicated to testing, testing REST APIS and web services. It also supports testing web, mobile and desktop applications that interact with third party APIs or HTTP services.

Key features:

• Has mock server functionality to create mock APIs in minutes.
• There is a Chrome extension for recording and playing test cases.
• Supports integration with Jenkins for server uptime and Jira for bug tracking.
• Facilitates management of permissions.
• Allows you to export and import test cases and reports from external tools such as Postman Collections, Swagger 2.

HttpMaster

HttpMaster is another exclusive tool for testing REST web services. This helps testers test REST API behavior and validate output in formats such as XML, JSON, and HTML. With its generic HTTP tool, HttpMaster also helps the developer model client activity and API application response behavior.

Key features:

• Has an easy-to-use and elegant user interface that does not require advanced technical skills.
• Uses HTTP methods like GET, POST, DELETE, etc.
• Provides various types and expressions for validation to facilitate testing.
• Uses the command line interface to create and run a test.
• Allows you to store all information - API calls and project data in one place.

Runscope

Runscope is a simple tool for testing and monitoring API performance. Runscope also supports API testing and mobile app backend testing.

Key features:

• Allows you to create tests with dynamic data even for complex cases.
• Displays metrics and analytics to identify problems.
• Works with tools like HipChat, Webhooks, Slack, and PagerDuty for API failure notification.
• Allows you to reuse and run tests in multiple locations.
• Facilitates centralized test management to improve collaboration.

Rapise

Rapise is a robust automation tool with powerful and extensible features. It is based on an open and flexible architecture for fast functional testing of REST / SOAP web services. Rapise also provides support for testing web applications embedded in Java, .NET, Ajax, Silverlight, and Flash.

Key features:

• Uses standard HTTP methods such as POST, GET, PUT and DELETE.
• Lets you store prototyped requests for a specific web service.
• Contains a built-in REST definition constructor and object library.
• Has powerful reporting capabilities.
• Supports cross-browser testing and parallel execution.

WebInject

WebInject is a free tool for automated functional, acceptance and regression testing of web services. It is a command line tool and is based on Perl, making it easy to run tests as you do not need to waste time on the command line. Also, it doesn't have an IDE which means tests are written outside of the WebInject UI. It can run on platforms with a Perl interpreter.

Key features:

• Provides real-time display of results.
• Controls the response time of the system.
• Supports various uses - both a full-fledged test platform and a stand-alone tester.
• Creates reports in HTML and XML formats.
• Allows integration with another system as a plug-in for external monitoring.

Storm

Finally, Storm is another open source tool from CodePlex for testing web services written in Java or .NET. It currently only supports SOAP web service.

Key features:

• Allows you to test multiple web services from a single user interface.
• Helps to edit raw SOAP requests.
• Allows you to refer to web service methods that contain complex data types.
• Supports testing WCF applications.

Of course, the list doesn't end here, as there are so many tools out there for testing web services.

Sign up right now or order a call with a free consultation!

Using the Web Services Validation Tool for WSDL and SOAP

Apparently, with the advent of new technologies and standards such as XML and HTTP, Web services have secured a place in the pantheon of Internet innovation. But how did this innovation come about?

The basic concept of Web services can be traced back to the mid-1960s in the United States. In the transport industry, for example, in the railway and shipping companies, a new concept for the exchange of electronic data between computers was introduced, which further developed into EDI (Electronic Data Interchange) technology. I first heard about EDI from a business school professor in 1980.

In 1996, the US National Institute of Standards and Technology announced a standard for EDI in the Federal Information Processing Standards Publications (FIPS PUB 161-2). According to the published specification, EDI is a standard for the exchange of strictly formatted messages between computers. The processing of received messages is carried out only by the computer, and these messages are usually not intended for human interpretation. This is exactly what Web services do, except that XML, the Internet, and the World Wide Web did not exist in the mid-1960s.

For those who are not very familiar with Web services, I'll briefly go over the definitions and basic components of Web services.

What are Web Services

A Web service is a software system designed to support machine-to-machine communications between computing resources over a network and uses Simple Object Access Protocol (SOAP) messages as defined by the World Wide Web Consortium.

The Simple Object Access Protocol (SOAP) is a simple, extensible protocol over which structured and typed messages are exchanged in a decentralized, distributed network environment. SOAP messages are written in the Extensible Markup Language (XML) format, a simple and flexible text format derived from the Standard Generalized Markup Language (SGML), which was developed by the International Organization for Standardization (ISO 8879: 1986).

Web Services Description Language (WSDL) is an XML-based language that describes the interface of Web services.

What happens when you exchange faulty SOAP messages? What would happen if the erroneous SOAP message was processed without warning and even used to generate information for decision making?

In practice, it is impossible to tell whether the data in the SOAP message is correct or not. However, you can test a SOAP message for correctness by looking at its interface definition or WSDL.

In real life, debugging problems in SOAP messages is not easy. If there is any error in the SOAP message, an HTTP response code of 500 is received from the Web services server. Web services servers do not provide details about which part of the SOAP message has a problem. You might run into an even worse situation where correct SOAP responses are received from the web services server without any error messages, and neither you nor your web service servers can understand the problems in your SOAP requests and responses. For example, suppose you wanted to query the current stock price of Company B, but you sent a SOAP message with misspelled tags to the Web services server. The web services server can ignore the incorrect tags and provide a default value in the SOAP response message, such as the stock price of Company A. If this goes unnoticed, the consequences can be catastrophic.

These types of problems can be prevented proactively by using the Web Services Validation Tool for WSDL and SOAP. It allows you to validate the correctness of SOAP messages using the Web Service Definition Language (WSDL) before deploying applications that use the Web service. The program parses the syntax and correctness of your SOAP messages with WSDL and indicates problems with detailed error reporting and line numbers. As a result, you no longer receive annoying HTTP 500 messages. Are your SOAP messages encrypted? No problems. The program will decrypt them and check the correctness of the decrypted SOAP messages for you.

This program was created to help IBM Web Services support personnel resolve Web services-related issues on IBM® WebSphere Application Server reported by customers around the world. The program is designed to check the correctness of SOAP messages. If the SOAP message is digitally signed, the program will verify that as well. With the Web Services Validation Tool for WSDL and SOAP, you can even send SOAP messages to Web service servers and receive SOAP response messages. The program was created in order to eliminate problems during industrial operation by using it in the early stages of development, as well as in order to reduce the time for solving problems arising during operation.

We will create a very simple Web service. First, we'll create a simple Java ™ application. After verifying that the Java application is working, we will use IBM Rational® Application Developer for WebSphere® Software to generate a Web service. Then we'll make some changes to the generated web service. Finally, we use the Web Services Validation Tool for WSDL and SOAP to create, validate, send, and receive SOAP messages.

You can create a simple Web service using the IBM Rational Application Developer for WebSphere Software. Web services can be created in two ways:

1. Top-down development development in which Java classes that implement Web services are generated from WSDL.
2. Bottom-up development, in which a Web service is generated from a Java bean or an enterprise Java bean.

In the following example, we will implement a Web service using a bottom-up development approach. First, we will create a simple Java application. We will then generate a Java bean Web service from a Java application using the IBM Rational Application Developer for WebSphere Software.

Creating a Java Application

First, we will create a Java application that issues a greeting. If no name is specified, the application will return the text "Hello, buddy!" If a name is specified, the application will return the text "Hello," followed by that name. Below is the code for the DemoWebService Java application included in the demo package. The hello () method returns a string depending on the name.

Listing 1. DemoWebService.java

Testing a Java Application

It is very important to test your Java application before creating a Web service from it. To run the application, you can write a class with a main () method. You can also use the Universal Test Client functionality provided by IBM Rational Application Developer v7 for quick testing without writing test code. You just need to select Universal Test Client from the Java class context menu to launch the Test Client.

1. In Universal Test Client, expand Objects\u003e DemoWebService.
2. Choose method hello.
3. Enter a string or your name in the field Value and press the button Invoke.

You can also run the test with the null parameter and see what happens. If null is passed to hello (), the string "Hello, buddy!" Is returned as expected.

Creating a web service

So far, everything is working well. Let's start generating a Web service from a Java class using the bottom-up Web services development method.

1. Select the DemoWebService Java application and create a new Web service from IBM Rational Application Developer.

1. Since we have created a Java class, choose Bottom up Java bean Web service in the Web service type list. Please select Start client and press the button Finish... If we had an EJB class, we could also write an EJB (Java Enterprise bean) to generate the Web service.

If everything went well, you will see the generated DemoWebServiceDelegate.java in Java Resources next to DemoWebService.java.

When looking at DemoWebServiceDelegate.java, you can find the Java Web service annotation @ javax.jws.WebService, which specifies targetNamespace, serviceName, and portName in the DemoWebServiceDelegate class. An instance of DemoWebService is created, and another hello () method is created from the hello () method of the DemoWebService. If you would like to learn more about Java Web services annotations, see Java Specification Request (JSR) 181. Web services metadata for the Java platform.

Listing 2. DemoWebServiceDelegate.java

Creating WSDL

In the client program project, you may also find that the DemoWebServiceService.wsdl and DemoWebServiceService_schema1.xsd files have been generated. DemoWebServiceService.wsdl contains Web Service Definition Language information describing network services for a previously created Java application. DemoWebServiceService_schema1.xsd contains an XML schema that describes the structure of the data types used in SOAP messages.

When you look at the DemoWebServiceService.wsdl file, you can see that it has a set of definitions elements at the root. There are 6 elements in a definition element:

• types (types);
• message (message);
• portType (port type);
• binding (binding);
• service (service);
• port (port).

Types defines the data types used in messaging. In DemoWebServiceService.wsdl, we import DemoWebServiceService_schema1.xsd instead of defining data types in the WSDL file.

Message defines the messages exchanged. We have 2 messages: "hello" and "helloResponse". The hello message has a part called "parameters". This part has a "tns: hello" element. The helloResponse message has a part called "parameters" which is similar to hello. This part has a "tns: helloResponse" element. The hello and helloResponse elements are defined in the DemoWebServiceService_schema1.xsd file. We'll cover them shortly.

Port Type - operations supported by endpoints. Each operation provides an input and output message. Our hello operation consists of an input "tns: hello" message and an output message "tns: helloResponse". These operations correspond to a request-response exchange. WSDL provides 4 different endpoint exchange primitives:

• one-way (one-way);
• request-response (request-response);
• solicit-response (request-response);
• notification

In a unidirectional exchange, the endpoint only receives the message. In a challenge-response exchange, the endpoint receives the message and sends the appropriate message. In a request-response exchange, an endpoint sends a message and receives a corresponding message. In a "notification" exchange, the endpoint only sends the message.

Binding defines the protocol details and message format specifications for operations and messages specified by the port type. For the style attribute, we use the value document. The style attribute provides 2 different message styles: rpc and document. Rpc-style messages contain parameters and return values. In the document style, messages contain documents. The transport attribute specifies the URI for the SOAP transport. The specified value http://schemas.xmlsoap.org/soap/http means that HTTP binding will be used in the SOAP specification. The URI for the SOAPAction HTTP header for the SOAP HTTP bind is specified in the soapAction attribute. Because the SOAP HTTP binding is used, the soapAction attribute is required. We use the empty string "" for the soapAction attribute. The soap: body element defines how the message parts are assembled within the body element of the SOAP message. The use attribute provides 2 different options: literal and encoded. We are using literal. This means that we have chosen to define a specific schema using either the type attribute or the element. When using the encoded variant, the type is abstract with encoding rules.

Service defines the set of used ports.

Port defines the endpoint of a communication by specifying the network address to bind.

network address to bind. In our case, the SOAP endpoint address is http: // localhost: 9081 / HelloWorldWSProject / DemoWebServiceService.

Listing 3. DemoWebServiceService.wsdl

Create schema

We are importing DemoWebServiceService_schema1.xsd from DemoWebServiceService.wsdl. Consider the DemoWebServiceService_schema1.xsd file. It is written in the XML Schema definition language to describe the structure and content constraints of XML documents. We have 2 elements: hello and helloResponse. Each element has a type. The hello type has an element "arg0" which is a string. The "arg0" element is optional because the value of the minOccurs attribute in its declaration is 0. If the minOccurs attribute is set to 1 or greater, the element must be specified. The same goes for the "return" element of type helloResponse.

Listing 4. DemoWebServiceService_schema1.xsd

Getting Started with the Web Services Validation Tool for WSDL and SOAP

So we've covered WSDL and schema. Let's start the web services server so that we can invoke the web service from the Web Services Validation Tool for WSDL and SOAP.

To run the Web Services Validation Tool for WSDL and SOAP, you need a Java 6 (or higher) runtime and XML digital encoding and decoding API that conform to the World Wide Web Consortium's "XML Encryption Syntax and processing" specifications (http: // www. w3.org/TR/xmlenc-core/).

IBM Java 6 provides an implementation of JSR 106: XML Digital Encryption APIs. If you have IBM Java 6 installed, then everything is ready to work and you do not need to install anything else.

If your Java 6 runtime, such as Sun Microsystems ™ Java 6, does not have XML Digital Encryption APIs, you need to install libraries that implement JSR 106 or the Apache ™ XML Security package version 1.4.3, which can be downloaded from http: / /santuario.apache.org/. Simply download the binary distribution, unzip it into a directory, and tell the toolkit where that directory is using the -vmargs and -DAXS command line options.

At the time of this writing, the Web Services Validation Tool for WSDL and SOAP supports JSR 106 and Apache XML Security version 1.4.3 for XML Digital Encryption and Decryption. If you want to verify digital signatures in SOAP messages, you need libraries that implement JSR 105: XML Digital Signature APIs. Fortunately, Java 6 VMs from Sun Microsystems and IBM provide implementations of JSR 105. This is why Java 6 was chosen as the minimum Java runtime environment requirement. If your Java 6 environment does not provide libraries that implement JSR 105, you need to find them.

The Web Services Validation Tool for WSDL and SOAP can be downloaded from here for free. Installation is very simple. Unzip the package to a directory and run wsvt.exe. If your default Java virtual machine is not a Java 6 environment that supports XML digital signatures and digital encryption and decryption, you must specify the Java 6 location with the -vm parameter, for example:

wsvt –vm c: \\ IBMjava6 \\ bin \\ java.exe

Again, if you have IBM Java 6, you don't need to install anything else. Everything you need is already included in IBM Java 6. When using Java 6 from Sun Microsystems, you need to tell the program the location of Apache XML Security to decrypt encrypted SOAP messages.

For example, the following command will run a program with Sun Java 6 and Apache XML Security library version 1.4.3 located in the C: \\ xml-security-1_4_3 \\ libs directory:

wsvt –vm c: \\ SUNjava6 \\ bin \\ java.exe –vmargs –DAXS \u003d C: \\ xml-security-1_4_3 \\ libs

The following is a list of Apache XML security library files actually used by the Web Services Validation Tool for WSDL and SOAP, although Apache XML security version 1.4.3 ships with 9 jars:
commons-logging.jar;
serializer.jar;
xalan.jar;
xmlsec-1.4.3.jar.

The MANIFEST.MF of the Web Services Validation Tool for WSDL and SOAP contains the following information:
Bundle-ActivationPolicy: lazy
Bundle-ClassPath: .,
external: $ AXS $ / commons-logging.jar,
external: $ AXS $ / serializer.jar,
external: $ AXS $ / xalan.jar,
external: $ AXS $ / xmlsec-1.4.3.jar

This is why you had to specify –vmargs –DAXS \u003d C: \\ xml-security-1_4_3 \\ libs for Sun Java 6 to decrypt encrypted SOAP messages.

I've spent quite some time troubleshooting class loading conflicts and incompatibilities among XML-related classes found in the Sun Java runtime, Apache XML Security, and some Eclipse plugins. Setting up the IBM Java runtime was straightforward because it ships with the JSR 106 implementation and does not require Apache XML Security.

Project creation

Now that you have set up and run the tool, you can create a new project. A project can contain a WSDL file, multiple schema files associated with a WSDL file, and SOAP messages in XML files. If there are multiple WSDL files in the project, only one of them is used, and the others are ignored when validating the XML SOAP message file. To use a different WSDL file, you must create a separate project. Each SOAP message must be contained in a file with the extension .xml, otherwise it will not be considered a SOAP message.

1. Right click and select New\u003e Project.

1. Please select Project at General.

1. Enter "Test Project" in the field Project name and press the button Finish.

Importing WSDL and Schema

We have created a "Test Project" project. Now you can import WSDL and XSD into it.

1. Select the project and then from the context menu select Import.

1. Please select File System at General.

1. Select the directory where WSDL and XSD are stored.
2. Select 2 files (DemoWebServiceService.wsdl and DemoWebServiceService_schema1.xsd) and click Finish.

WSDL and schema overview

We now have a project with WSDL and XSD. You can double-click the left mouse button on the WSDL to view the WSDL in Design and Source mode. In Design mode, you can render a Web service with inputs and outputs.

In Source mode, you can view and edit the WSDL in a text editor.

If XSD files cannot be opened in the XSD editor, you can open them in the XML editor by choosing Open With\u003e XML Editor in the context menu of this XSD file.

We have opened DemoWebServiceService_schema1.xsd in an XML editor.

Creating a SOAP message

So we have the WSDL and schema ready to validate the correctness of SOAP messages. Let's start testing the Web Services Validation Tool for WSDL and SOAP with a SOAP message. You must include the SOAP message in your project. The SOAP message must be contained in a .xml file to be validated.

1. Please select New\u003e XML to create a SOAP message in the project.

1. Please select Test Project for the parent folder of the new SOAP message. If the file is not already selected, enter "DemoSOAPMessage.xml" in the File name and press the button Finish.

The program automatically invokes the XML editor with the new XML file. There is nothing in it except a string with the version and xml encoding. It's good that we have at least something before starting to create a SOAP message from scratch. Do you know how to compose a SOAP message? Do not worry. In the next section, we'll walk you through the steps to create one.

To create a SOAP message, you can invoke the "hello" service using the "parameters" parameter with my name, "Jinwoo". You can of course use your own name. The namespace is http: // demo /. Be careful - it is written as http: // demo /, not http: // demo, this is essential.

Listing 5. HelloWorldSOAPmessage.xml

Do you see problems in this SOAP message? If so, don't worry. We'll deal with this later.

SOAP message transmission

Are you ready to send a message to the web services server?

1. Select SOAP message and select

1. In the Transmit SOAP Request and Receive SOAP Response window, you can fill in Service Address, SOAPAction and Content-Type... In this application, we do not need to specify a SOAPAction because we have used an empty string "" for the soapAction attribute in the binding section of the DemoWebServiceService.wsdl file.
2. Enter http: // localhost: 9081 / HelloWorldWSProject / DemoWebServiceService in the box Service Addressif the server is running on the local computer on port localhost: 9081. Otherwise, you must enter the real address at which the Web service is available.
3. Please select text / html for the field Content-Type.
4. Click the button OK to send the SOAP message to the server.

Receiving a SOAP message

If the server is up and running, you should receive a SOAP response. If you don't receive a response, check that the address and content type are correct.

Checking the validity of a SOAP message

Excellent! We have accepted a SOAP response. It is also saved in the project. But wait. Can you see something is wrong? We got "Hello, buddy!" instead of "Hello, Jinwoo!" Something went wrong? Have no idea?

Unfortunately, the web services server didn't let us know what was wrong. No warnings. It can be very dangerous when unpredictable SOAP responses are sent and the Web services server has no idea what is going wrong. Even recipients of SOAP responses may not notice the problems in the SOAP message in question.

The Web Services Validation Tool for WSDL and SOAP helps you determine what is going wrong.

Listing 6. Answer

1. Select the SOAP reply message and click Validate.

The Web Services Validation Tool for WSDL and SOAP found an error in the SOAP message.

Editing a SOAP message

1. The program complains about the value of "parameters". Change it to arg0 and save.

Listing 7. Modified SOAP message

1. Check the correctness of the modified SOAP response message. No more error messages appear.

1. We are now ready to send the modified reply message to the server. Select SOAP message and then select Transmit SOAP Request and Receive SOAP Response.

1. In the Transmit SOAP Request and Receive SOAP Response window, enter http: // localhost: 9081 / HelloWorldWSProject / DemoWebServiceService in the field Service Addressif the server is running on port localhost: 9081.
2. Please select text / html for the field Content-Type and press the button OK.

This time, as expected, the correct answer arrives.

Listing 8. SOAP response

Invalid namespace detection

What happens if you send a message with the wrong namespace?

1. Change the namespace to http: // demo2 / and save the post.

Listing 9. Changing the namespace

1. Then you can send the request to the server.

You will see an IOException: Server returned HTTP response code: 500 for URI: http: // localhost: 9081 / HelloWorldWSProject / DemoWebServiceService.

The web services server responded with IOException information, but not enough information to detect the error. Check the correctness of the message using the toolkit if you want more details to solve the problem.

The program says: "Invalid SOAP message: cvc-complex-type.2.4.a: Invalid content was found starting with element 'ns0: hello". One of "(" http: // demo / ": hello," http: // demo / ": helloResponse)" is expected ".

This message indicates that http: // demo / is expected. This is what we need to know, not the 500 HTTP response code.

Validating the correctness of encrypted SOAP messages

What if your SOAP messages are encrypted? No problem if you have keys and passwords. Just select the SOAP message and Validate just like it is done for any other regular SOAP message. If your SOAP message is encrypted, a prompt similar to the one shown in Figure 35 will appear on the screen.

At the time of this writing, 3 types of keystore are supported:

1. Java Key Store (JKS).
2. Java Cryptography Extension Key Store (JCEKS).
3. Personal Information Exchange Syntax Standard (Public Key Cryptography Standards # 12).

You need to provide information about your keystore: file name, file type and password. If the information is correct, you must select a key and password. You can also find information about your keystores and the list of keys and certificates in the keystore, such as keystore type, provider name, provider version, provider information, key type, creation date, certificate type, algorithm, and format.

If all the information is correct, the program will generate a decrypted SOAP message and check its correctness.

The following encryption algorithms are currently supported:

• Advanced Encryption Standard (AES) in Cipher Block Chaining (CBC) with an initialization vector (128/192/256 bits).
• Advanced Encryption Standard (AES) Key Encryption (128/192/256 bits).
• Triple Data Encryption Algorithm Modes of Operation (triple-DES) Key Encryption.
• Triple Data Encryption Algorithm Modes of Operation (triple-DES) Key Encryption in Cipher Block Chaining (CBC) mode.
• RSA Cryptography Specifications Version 1.5.
• RSA Optimal Asymmetric Encryption Padding (OAEP) is a method with a mask generation function.

Validating Digitally Signed SOAP Messages

What if your SOAP message is digitally signed? Just select SOAP message and then select SOAP Message Digital Signature Verification.

If the digital signature is correct, you will see the following screen:

Otherwise, the program will report an error in the signature. The following digital signature specifications and algorithms are currently supported:

• Secure Hash Algorithm 1 (SHA-1)
• Hash Message Authentication Code (HMAC)
• Digital Signature Algorithm (DSA)
• Public-Key Cryptography Standards (PKCS # 1)
• RSA Encryption Algorithm with Secure Hash Algorithm (SHA-1)
• Canonical XML Version 1.0 and 1.1
• XSL Transformations (XSLT) Version 1.0
• XML Path Language (XPath) Version 1.0
• Base64

Access to the US National Weather Bureau service using a SOAP message

The simple web service we created and tested works fine. Can this program be used in a "real" environment? You can try using a real U.S. National Weather Bureau Web service provided by the U.S. National Oceanic and Atmospheric Administration (NOAA).

1. Create a project.

1. Create the XML for the SOAP message.

The US National Weather Bureau provides many different Web services. You can try working with the NDFDgenByDay service, which provides weather forecasts for a point with a given latitude and longitude.

To access NDFDgenByDay, you need to provide the following information:

Table 1. NDFDgenByDay

In this example, we want to create a SOAP request to get a weekly forecast for a location with coordinates (LAT38.9, LON-77.01) starting from 2010-07-23 in a 24-hour format:

Listing 10. SOAP request

We didn't specify the namespace because the service worked without it. If you run into any problems with the namespace, set it up.

Select a message and Transmit SOAP Request and Receive SOAP Response For more information, see the Web Services Validation Tool for WSDL and SOAP.

Table 2. Request for information

The forecast data is now much easier to read.

If you find this tip uncomfortable, you can use your own HTML formatting method. Most Web services offer results in XML format, so you don't have to do this all the time.

Conclusion

We created, transformed, received, and validated SOAP messages using the Web Services Validation Tool for WSDL and SOAP. It can pinpoint problems that most Web services servers cannot even detect, which can have serious consequences in real life. Using this program during the development phase allows you to reduce the time to troubleshoot problems during operation.

SOAP (Simple Object Access Protocol) is a standardized protocol for transferring messages between client and server. It is usually used in conjunction with HTTP (S), but it can work with other application layer protocols (for example, SMTP and FTP).
SOAP testing from the point of view of testing techniques is not fundamentally different from working with other APIs, but it requires preliminary preparation (in terms of protocol theory) and special testing tools. In this article, I would like to formulate a small checklist of necessary knowledge and skills, which will be equally useful for both a SOAP tester (who often does not know "what to grasp" after setting a problem), and a manager who is forced to evaluate the knowledge of testers and develop plans for training.

Theoretical basis

The fact that SOAP is a protocol is very important for testing: you need to study the protocol itself, the "primary" standards and protocols on which it is based, and (as needed) existing extensions.

XML
XML is a markup language similar to HTML. Any message sent / received via SOAP is an XML document in which the data is conveniently structured and easy to read, for example:

Julia
Natasha
Reminder
Don't forget to write an article!

More details about XML can be found at w3schools or codenet (in Russian). Be sure to pay attention to the description of namespaces (a method of resolving conflicts when describing elements in XML) - their use is necessary in SOAP.

XSD
When working, it is always convenient to have a standardized description of possible XML documents and check them for correct filling. For this there is an XML Schema Definition (or XSD for short). The two main features of XSD for a tester are the description of data types and the imposition of restrictions on possible values. For example, the element from the previous example can be made optional and limited to 255 characters using XSD:

...







...

SOAP extensions
You may also come across various SOAP “extensions” in your work — standards like WS- *. One of the most common is WS-Security, which allows you to work with encryption and electronic signatures. Often, WS-Policy is used along with it, with which you can manage the rights to use your service.

Example using WS-Security:

Alice
6S3P2EWNP3lQf + 9VC3emNoT57oQ \u003d
YF6j8V / CAqi + 1nRsGLRbuZhi
2008-04-28T10: 02: 11Z

All of these extensions are quite complex constructs that are not used in every SOAP service; Their detailed study at the initial stage of mastering SOAP testing is unlikely to be relevant.

Tools

As you already understood, SOAP is a serious business, to work with it you need to know the theory and numerous standards. In practice, such complexity would lead to very significant labor costs (for example, it would be necessary to look at the diagram in a notebook every time and send requests with curl). Therefore, tools have been created to make it easier to work with SOAP.

XML / XSD Editors
A good tester starts testing at the stage of writing the documentation, so it is convenient to use special editors to check circuits. The two most famous are Oxygen (cross-platform) and Altova (Windows only); both of them are paid. These are very powerful programs that analysts actively use when describing services.

In my practice, three features of the editors turned out to be useful: XSD visualization, XML generation from XSD, and XML validation against XSD.

1. XSD visualization is needed for a visual representation of the diagram, allowing you to quickly isolate the required elements and attributes, as well as existing restrictions. For example, for a CheckTextRequest, the text element is required, and all three attributes are optional (with the options attribute set to zero by default).

Visualization is necessary when there are many types and constraints in the schema. If you just need it and don't want to pay for custom editors, then you can consider free alternatives (like JDeveloper).

2. XML generation based on XSD useful when you want to see a valid example of a message. I use it to quickly experiment with how to fill out a message and check the nuances of how constraints work.

3. After using the feature from point 2, it is useful to conduct xML validation against XSD - that is, check the message for correctness. Together, features 2 and 3 allow you to catch tricky defects in XSD even when the service itself is under development.

Testing tool - SoapUI

SOAP testing almost always means using SoapUI. You can read about the use of this tool in different sources (,), but the most effective way is to read the official documentation. I distinguish 8 conditional levels of SoapUI proficiency:

Level 1 - I can send requests
Learn to create a WSDL based project. SoapUI can generate all the necessary requests for you; you just have to check the correctness of their filling and press the "Send" button. Once you have developed the skills to create correct queries, you should master the art of forming incorrect queries that cause errors.

Level 2 - I can do Test Suites and Test Cases
Start doing mini-autotests. Test suites and test cases allow you to create API test scripts, prepare data for requests, and automatically check the received response against what is expected. At first, they can be used simply as collections of queries. For example, if you have a defect and want to quickly check it after fixing, you can select a separate test kit specifically for defect requests.

Level 3 - can write Assertions
After mastering the test cases, it will be useful for you to learn how to make them automatically checkable. After that, you will no longer need to look for information about the answer with your "eyes": if there is an automatic check, the cases will be marked green (if the check is passed) or red (if it is not passed). SoapUI provides a large set of possible assertions, but the most convenient and simple ones are Contains and Not Contains. With their help, you can check the presence of a specific text in the received response. These checks also support regular expression searches.

Level 4 - using XPath and / or XQuery in Assertions
For those who are a little familiar with UI with Selenium, XPath is a familiar thing. Roughly speaking, XPath allows you to search for elements in an XML document. XQuery is a similar technology that can use XPath internally; this language is much more powerful, it resembles SQL. Both of these languages \u200b\u200bcan be used in Assertions. Checks with their help are more targeted and stable, so your cases will be more trusted.

Level 5 - can write complex tests using special steps

Test cases can contain not only one request, but also several (for example, when you want to emulate a standard user scenario “create an entity” → “export an entity”). There can be other special steps between requests, for example:

• Properties and Property Transfer (help to reuse data and transfer it between requests);
• JDBC Request (used to get data from the database);
• Conditional Goto (allows you to make branches or loops in a test case);
• Run TestCase (helps to bring some typical queries into separate test cases and call them where needed).

Level 6 - using Groovy scripts

SoapUI allows you to write Groovy scripts in a variety of places. The simplest case is generating data within the query itself using $ (\u003d) inserts. I use inserts like this all the time:

• $ (\u003d new Date (). format ("yyyy-MM-dd'T'HH: mm: ss")) - to insert the current date and time in the required format;
• $ (\u003d java.util.UUID.randomUUID ()) - to insert a correctly formed random GUID.

Complete scripts can be used as steps in cases and checks. At some point, you will find that several special steps from the fifth level can be replaced with one script at once.

Level 7 - using MockServices
SoapUI based on WSDL can generate Mock objects. A mock is the simplest simulation of a service. Using mocks, you can start writing and debugging test cases even before the service is actually available for testing. They can also be used as stubs for temporarily unavailable services.

Level 8 - God SoapUI
You know the difference between the paid and free versions of SoapUI and use the SoapUI API in your code. You use plugins and run cases through the command line and / or CI. Your test cases are simple and easy to maintain. In general, you "ate the dog" on this instrument. I would be happy to talk to someone who has mastered SoapUI at this level. If you are, please write in the comments!

Testing with programming languages

I will give an example of how a request to the YandexSpeller API looks like, made using groovy-wslite:

import wslite.soap. *
def client \u003d new SOAPClient ("http://speller.yandex.net/services/spellservice?WSDL")
def response \u003d client.send (SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") (
body (
CheckTextRequest ("lang": "ru", "xmlns": "http://speller.yandex.net/services/spellservice") (
text ("thorn")
}
}
}
assert "error" \u003d\u003d response.CheckTextResponse.SpellResult.error.s.text ()
assert "1" \u003d\u003d [email protected]()

As far as I know, there are no high-level frameworks (like Rest-assured) for testing SOAP yet, but an interesting tool has recently appeared - karate. It can be used to describe SOAP and REST test cases as scripts like Cucumber / Gherkin. For many testers, turning to karate will be an ideal solution, because such scenarios in terms of the complexity of writing and maintaining cases will lie somewhere in the middle between using SoapUI and writing your own SOAP testing framework.

Conclusion

You probably won't ever want to test SOAP just for yourself (as you might with REST). It is a heavyweight protocol used in serious enterprise solutions. But its heaviness is at the same time a gift to the tester: all technologies used are standardized, there are high-quality tools for work. All that is required of the tester is the desire to learn and use them.

Let's put together that checklist of necessary skills for a tester. So, if you are just starting to test SOAP services, you need to know and be able to use:

• WSDL.
• SOAP.
• XML / XSD editors (at the XSD rendering level).
• SoapUI at level 1.

As you can see, the main focus is on the study of standards, in SoapUI it is quite simple to be able to execute queries. As you dive into SOAP testing, you will be faced with tasks that require more serious skills and knowledge, but you should not try to learn everything at once. Consistency in increasing the level of complexity of the tasks performed is much more important. By following this recommendation, one day you will realize that you have become a good specialist in this field!

Nowadays, it is rare for a modern application to do without an API. This is true both for a simple site and for highly loaded distributed systems. API testing is one of the main tasks in the quality assurance process. Unsurprisingly, the demand for testers who can test APIs is increasing day by day. In this course, you will gain an understanding of the methods, tools and approaches in API testing, acquire the necessary knowledge, which will undoubtedly have a favorable effect on your value as a testing specialist.

This course will be useful for students familiar with the basics of software testing who want to grow further and improve their skills.

Course program:

Lesson 1. Introductory. SOAP protocol

• Briefly about the lecturer;
• Course objectives;
• What are API, WS and why are they needed;
• The role of API testing in the quality assurance process;
• Review of WS testing tools;
• Methods used in testing WS;
• SOAP history;
• Terminology and main concepts (XML, XSD, Endpoint, WSDL).

Lesson 2: SOAP Protocol. REST architecture

• Terminology and main concepts (UDDI, XSLT, XPath, XQuery, HTTP methods, HTTP statuses);
• SOAP structure and main components;
• Scope of application;
• Features of work;
• Advantages and disadvantages;
• Features of REST architecture;
• Terminology and main concepts (WADL, RESTful, JSON, JSONPath);
• REST principles;
• Status code and main statuses;
• CRUD verbs;
• Advantages and disadvantages.

Lesson 3. Acquaintance with SoapUI. Working with a REST project

• Java installation;
• Installing SoapUI;
• Overview of the main interface elements;
• Connection of a training project;
• Review of project methods;
• Sending a request and analyzing the received response;
• Study of the available web services of the project;
• Testing plan preparation;
• Writing test cases;
• Elements “TestSuite”, “TestCase”, “TestSteps”.

Lesson 4. Working with a REST Project (XML)

• Block "Assertions";
• Running tests at different levels;
• Element “Properties”, basic features;
• Working with Properties;
• "Property Transfer" element;
• Working with Assertions.

Lesson 5. Working with a REST Project (JSON)

• Conditions and branches;
• Working with Assertions;
• TestRunner, features of work;
• Running TS, TC from the command line;
• Working with Test runner;
• Working with Groovy scripts.

Lesson 6. Working with Groovy Scripts

• Working with static and dynamic data;
• We generate test data;
• We get data from “Properties”;
• Data recording and transfer;
• Conditions and branches;
• Script Assertion.

Lesson 7. Additional features

• Connecting external libraries and custom classes;
• Mock services;
• Why do we need Mock services;
• An example of working with a Mock service;
• What about CI?
• Install Jenkins;
• Running a Jenkins project.