testing – Technix

What’s WSDL?

Web Service Definition Language in short WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure oriented information.

WSDL is a

XML document written to describe a web service.
It specifies the location of the web service and the operations or methods the web service exposes.

A WSDL document uses the following elements in the definition of network services (Web services)

Types – a container for data type definitions. This describes the data. The XML schema Language(Known as XSD also) is used for this purpose.
Message – an abstract, typed definition of the data being communicated. The contains the information needed to perform the operation.
Operation – an abstract description of an action supported by a service. This defines the actions and the way the message is encoded.
Port Type – an abstract set of operations supported by one or more endpoints.
Binding – a concrete protocol and data format specification for a particular port type. Defines the interface and the binding style.
Port – a Single endpoint defined as a combination of a binding and a network address. It defines the address or the connection point to a web service.
Service – a collection of related endpoints

Representation of concepts defined by WSDL 1.1 and WSDL 2.0 documents.

WSDL 1.2 has been renamed to WSDL 2.0, because of the major differences, like

Removed message constructs.
Operator overloading not supported.
PortTypes renamed to interfaces.
Ports renamed to interfaces.
Added further semantics to the description language.

<?xml version="1.0" encoding="UTF-8"?>
<description xmlns="http://www.w3.org/ns/wsdl" 
             xmlns:tns="http://www.tmsws.com/wsdl20sample" 
             xmlns:whttp="http://schemas.xmlsoap.org/wsdl/http/"
             xmlns:wsoap="http://schemas.xmlsoap.org/wsdl/soap/"
             targetNamespace="http://www.tmsws.com/wsdl20sample">

<!-- Abstract type -->
   <types>
      <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
                xmlns="http://www.tmsws.com/wsdl20sample"
                targetNamespace="http://www.example.com/wsdl20sample">

         <xs:element name="request"> ... </xs:element>
         <xs:element name="response"> ... </xs:element>
      </xs:schema>
   </types>

<!-- Abstract interfaces -->
   <interface name="Interface1">
      <fault name="Error1" element="tns:response"/>
      <operation name="Opp1" pattern="http://www.w3.org/ns/wsdl/in-out">
         <input messageLabel="In" element="tns:request"/>
         <output messageLabel="Out" element="tns:response"/>
      </operation>
   </interface>

<!-- Concrete Binding Over HTTP -->
   <binding name="HttpBinding" interface="tns:Interface1" 
            type="http://www.w3.org/ns/wsdl/http">
      <operation ref="tns:Get" whttp:method="GET"/>
   </binding>

<!-- Concrete Binding with SOAP-->
   <binding name="SoapBinding" interface="tns:Interface1" 
            type="http://www.w3.org/ns/wsdl/soap" 
            wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"
            wsoap:mepDefault="http://www.w3.org/2003/05/soap/mep/request-response">
      <operation ref="tns:Get" />
   </binding>

<!-- Web Service offering endpoints for both bindings-->
   <service name="Service1" interface="tns:Interface1">
      <endpoint name="HttpEndpoint" 
                binding="tns:HttpBinding" 
                address="http://www.example.com/rest/"/>
      <endpoint name="SoapEndpoint" 
                binding="tns:SoapBinding" 
                address="http://www.example.com/soap/"/>
   </service>
</description>

Example WSDL

Introduction to Jmeter

Thread Group

Thread group elements are the beginning points of any test plan.
All controllers and samplers must be under a thread group.
Other elements, e.g. Listeners, may be placed directly under the test plan, in which case they will apply to all the thread groups.
As the name implies, the thread group element controls the number of threads JMeter will use to execute your test. The controls for a thread group allow you to:
• Set the number of threads
• Set the ramp-up period
• Set the number of times to execute the test

Ramp-up period

The ramp-up period tells JMeter how long to take to “ramp-up” to the full number of threads chosen.
If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds.

How to define Ramp-Up Period???

Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen).
Start with Ramp-up = number of threads and adjust up or down as needed.
By default, the thread group is configured to loop once through its elementsSamplers:
Samplers perform the actual work of JMeter. Each sampler (except Test Action) generates one or more sample results. The sample results have various attributes (success/fail, elapsed time, data size etc) and can be viewed in the various listeners.

Version

Thread Group

Ramp-up period

How to define Ramp-Up Period???