Popular Posts

Sunday, November 28, 2010

QA testing in agile world - Attitude matters most!

Few short tips about a viable approach for testing in agile world. May be valid for most organizations.

  • Understand your development team first. Study each engineer and adjust your way of acting (communication, management etc..) according to the team you are working on
  • Do not act as a quality police. Everyone is responsible for quality. It is your task to guide the others NOT finding faults and complain
  • Be as flexible as you can in all situations
  • Be quick on everything - learn, design, implement, configure, deploy quickly and test fast
  • Be innovative
  • Identify highly risked features first and start hunting bugs

  • CREATE A VALUE as a tester for your organization and BUILD the CONFIDENCE among the team!

Thursday, November 25, 2010

Invoking secure web services using SOAPUI - part1

SOAPUI is a very useful free tool which can be used in SOA testing. Service invocation using SOAPUI is straight forward and you can find a lot of references by surfing web. However, there are limited information about invoking services with various QOS (Quality of Service) features such as WS-Security, WS-Addressing etc.
This post takes you through the simplest QOS scenario, a web service is secured with UserName token policy and how SOAPUI is used to invoke such a service.

I will use the default HelloService hosted in WSO2 WSAS in this demonstration but the service invocation approach is similar with any service provider.

1. Download and install SOAPUI-3.6.1 or later (free version)
2. Download and install WSO2 WSAS-3.*

Step 1

First, we need to secure a web service hosted in WSAS. We will configure HelloService so that only the users in admin group will be allowed to invoke the service. In order to do that, start WSO2 WSAS and log in to management console. Then, select HelloService from Deployed Services page.
You will be directed to the service dashboard of HelloService as follows.

Click on Security link and Select "Enable Security" option. Then select, UserNameToken security scenario.

In the next screen, select admin user group and click on finish to apply the security policy for HelloService.

Step 2
We have configured server side security policy. If you look at the WSDL of HelloService (http://localhost:9763/services/HelloService?wsdl), you will notice that UserNameToken security policy is added to the service.
Now, we need to configure SOAPUI project to talk to HelloService with the required user credentials.

First, start SOAPUI and create a new project. Specify https://localhost:9443/services/HelloService?wsdl as the initial WSDL. Keep the other default settings.
You will see the following project structure.

Replace ? with an input value in the request editor and run the test. You will encounter a SOAPFault, Missing wsse:Security header in request, since we did not send security headers with the request.
Lets configure client side security now. In the Request Properties pane of SOAPUI project, you will find the following properties.

WSS-Password Type
WSS TimeToLive

Specify the following values for the above properties.

Username = admin
Password = admin
WSS-Password Type = PasswordText
WSS TimeToLive = 2000

Run the test. Have a look at the raw request view. You will see security header is added to the request.
Thats all! We will look at more advanced scenarios such as signing and encrypting messages with SOAPUI in future posts.

Saturday, November 13, 2010

Java bench - Simple and lightweight service load testing tool

At WSO2, we use various types of tools and programmatic approaches to load, stress and performance test SOA middleware products. Out of them, one particular tool is part of almost all engineers workspaces. It is Java bench (or java-ab).
Java bench is the java clone of the popular ApacheBench load generator customized for better HTTP1.1 support.

Java bench is a very simple and easy to use utility. One of the greatest advantages of using it for performance testing is, its lesser overhead on load generation machines. Most of the load generators consist of rich UIs and reporting utilities hence the load generator it self consumes considerable amount of CPU and memory when you run performance testing in single server. It is always not practical to run load generators in separate machines. Sometimes we need to run load/performance tests against a server running on a local machine in order to provide quick feedback about the product under test or reproduce perf/memory issues. In these situations, Java-bench is the ideal solution.

Lets see how we can run a basic performance test using java bench.

Linux or windows OS
jdk1.5 or higher

Step 1
Download Java bench from here and extract the downloaded zip file.

Step 2
Go to the root of the extracted directory and run 'java -jar benchmark.jar' to see the available options.

usage: HttpBenchmark [options] [http://]hostname[:port]/path
-v Set verbosity level - 4 and above prints response
content, 3 and above prints information on headers, 2 and above prints
response codes (404, 200, etc.), 1 and above prints warnings and info.
Add arbitrary header line, eg. 'Accept-Encoding:
gzip' inserted after all normal header lines. (repeatable)
-n Number of requests to perform for the benchmarking
session. The default is to just perform a single request which usually
leads to non-representative benchmarking results.
-T Content-type header to use for POST data.
-c Concurrency while performing the benchmarking
session. The default is to just use a single thread/client.
-h Display usage information.
-i Do HEAD requests instead of GET.
-k Enable the HTTP KeepAlive feature, i.e., perform
multiple requests within one HTTP session. Default is no KeepAlive
-p File containing data to POST.

Step 3

We will run a load test against one of the publicly available web services. I use a simple web service hosted in xmethods which generates a list of prime numbers that are less than a specified max value.
First you need to invoke this service using SOAPUI or some other client and capture the SOAP request message. Then save it as a xml in your file system.

Sample request:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://microsoft.com/webservices/">
<web:max>56 </web:max>

Step 4

Now, we can use java bench to send series of requests to the above web service as follows.

java -jar benchmark.jar -p SoapRequest.xml -n 100 -c 10 -k -H "SOAPAction: http://microsoft.com/webservices/GetPrimeNumbers" -T "text/xml; charset=UTF-8" http://www50.brinkster.com/vbfacileinpt/np.asmx

As you can see, we specify the soap request xml with -p parameter. -c specifies the no.of concurrent threads/clients used in the test. -n is used to specify the no.of requests transmitted per a keep-alive connection. In our example, each client carries 100 requests therefore 1000 total requests will be sent to the service. -k enables HTTP keep-alive so that multiple requests share the same HTTP session. -H is used to specify the HTTP headers. In our example, SOAPAction HTTP header is appended to the message. You can find the relevant SOAPAction from the WSDL of the service. -T is used to specify the Content-Type header of the request. The last parameter is the endpoint of target service.

After the test is completed, you will see the result as shown below.

Server Software: Microsoft-IIS/6.0
Server Hostname: www50.brinkster.com
Server Port: 80

Document Path: http://www50.brinkster.com/vbfacileinpt/np.asmx
Document Length: 429 bytes

Concurrency Level: 10
Time taken for tests: 59.378401 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 756000 bytes
Requests per second: 16.84 [#/sec] (mean)
Time per request: 593.784 [ms] (mean)
Time per request: 59.378 [ms] (mean, across all concurrent requests)
Transfer rate: 7.22 [Kbytes/sec] received
5.51 kb/s sent
12.73 kb/s total

Simple. Isn't it? We will look in to more interesting tests with java-bench in future posts.