Applies to ReadyAPI 3.0, last modified on November 19, 2019

To create and run tests with ReadyAPI, you need to have general understanding of web service technologies and testing principles. These topics are large, and they are out of the ReadyAPI documentation scope. We compiled a high-level overview to help you get started with ReadyAPI faster.

Terms

  • Web services are client/server applications in which clients and servers exchange data over the Web through the HTTP protocol or some other protocol based on HTTP. Examples of such applications include navigation software, online bank clients, weather monitoring systems, and so on.

  • The URLs, to which clients send requests, contain information on the tested server (host), the port number to be used for communication, and the requested server resource, for example, a page or file path:

    Web service load testing with ReadyAPI: Endpoint
  • Requests that clients send to servers have the following structure:

    • The start line that specifies the HTTP method (like GET, POST, or DELETE), the target URL and the protocol version.

    • Headers that pass additional info like expected format of response data, or the size and format of request data.

    • (Optionally) Request body. Some request types do not use it.

    Web service load testing with ReadyAPI: Request data

    Responses have a similar structure:

    • The start line with the response code and message. Some frequently-used codes are 200 OK (success) and 404 Not Found (failure, the requested resource was not found).

    • Headers that describe the response data format and contain additional values like cookies, server info, and so on.

    • Response body, for instance, an array with requested data, an image, a file, and so on.

    Web service load testing with ReadyAPI: Response data
  • Frequently-used formats for request and response bodies are JSON and XML.

  • The command a client sends to the server for execution is called an action, method or operation depending on the service architectural style (SOAP or REST, see below).

  • The two popular architectural styles for web services are SOAP and REST:

    • SOAP services use the SOAP protocol that is built over HTTP. These services use HTTP requests of the POST type and pass data in the XML format in request and response bodies. All the requests go to the same URL and the operation to be executed is specified by special request headers or XML elements in the request body.

      SOAP services use WSDL definitions that strictly describe operations supported by the service, their parameter types and data formats.

    • REST services work over HTTP. The operation to be executed is set by a combination of the HTTP method and the requested resource name. For example, a RESTful service of an online pet store can have a /pets resource. The POST http://petstore.io/pets request can add information on a pet to the database, and the GET http://petstore.io/pets request can retrieve information on available pets.

      There are several formats of REST service definitions: OpenAPI (Swagger), WADL, and some other. However, some developers do not provide any definition for their RESTful services at all.

How You Can Test a Web Service

  • To ensure that a web service functions properly, you create and run functional tests on it.

    These tests send requests to the server and verify its responses.

    In ReadyAPI, you create functional tests in SoapUI. Despite the name – SoapUI – you can create tests for both SOAP and REST services there. You can easily simulate requests and customize their parameters in special editors:

    Web service testing with ReadyAPI: Request editor

    Click the image to enlarge it.

    To validate response data and response codes, you add assertions to test requests:

    Web service testing with ReadyAPI: Assertions panel

    Click the image to enlarge it.

    The easiest way to determine if the server is working correctly or not is to check the response code. 200 OK typically means the server processed a request successfully.

  • In real life, a client typically sends a series of requests to the server. For instance, for an online shop, the first request can be used for signing in, and subsequent requests – for buying some products.

    In SoapUI, you simulate this real-life behavior by organizing requests and other test steps into test cases:

    Web service testing with ReadyAPI: Test cases, test suites and requests

    Multiple test cases that work together are grouped into test suites, which, in their turn, belong to test projects (see the image above).

Let’s now create a test project and add an automated functional test to it.

Prev     Next

See Also

Creating Your First Functional Test

Highlight search results