Wednesday, August 25, 2010

Paros - Simplest way to secure your Web Application

Posted by: Hemanth Dande 
(Sr. SQA Engineer working at PlanetSoft, an Insurance Industry Company).
Contact Author: hemanth.dande@gmail.com


PAROS Configuration

Open Paros by clicking the shortcut key or by the below shown navigation


Navigate to Tools > Options and configure the settings as shown below

Configure the browser settings as shown below
Recording The session

Open the application, Navigate to each possible corners of the application in all possible
scenarios. Then it will be recorded as shown below.

Navigate to Analyse and click on Spider, below shown Spider pop up will display. Click on
Start
After completion of spider, navigate to Analyse and click on Scan or Scan All.
After completion, pop up will be displayed as shown below.
Click on OK in above pop up, Navigate to Reports and click on Last Scan Report. The it
displays the path of the report saved as shown in below screenshot
Click on OK, Report will display as shown below.

Thursday, August 12, 2010

Software Test Automation - Generations

Many of us might have come across buzzwords like Keyword-driven, Data-driven, Capture-Replay and these days Model-driven Automation methodologies. Let us try to understand these buzzwords in a more systematic manner through the generations of Software Test Automation.
To Err Is Human
Software developers are Humans and they make mistakes. But is that a good excuse. Definitely not. This lead to inception of Quality Assurance(QA). 

But QA Engineers are also humans. They do make mistakes. Also humans are not meant for repetitive tasks as they can get bored, tired or they can skip things. This is what exactly happens during testing of an application. Also due to lack of time few test cases will be skipped. This showed the purpose of automating execution of test cases. 
Software Test Automation is not a Substitute for Manual Testing
Areas like Regression testing, Sanity and Smoke testing are apt for Automation as they give a huge Return On
Investment (ROI).  Trying to automate test cases related to new features or features in development is not a good idea and it does more bad than good.

First Generation in Software Test Automation(Agreement)

At this stage every one agreed that Automation is required and started automating test cases.Scripting languages like Shell Scripting, Windows Scripting, Perl, Ruby, Python are used to automate tasks which will make testing easy and increasing reliability by reducing human errors. Also used rudimentary tools to record and replay test case execution.

Maintaining loose scripts became a major problem here. Also in record and play the flexibility part is missing. Example change of some steps in Test Case due to change in application is not possible and it needs re-recording of whole test case.

Second Generation in Software Test Automation(Framework)

To fight with the pain points in first generation, Frameworks have been evolved which binds loose scripts lying here and there and also provides utilities like reporting, logging along with Test runner. Also they decouple activities like reading configuration parameters and passing information from one test case to other. Also Object Oriented Principles (OOP) is strictly followed while writing scripts eliminate duplication of code and to reap fruits of OOP concepts. Also tools provided a feature to allow edit of recorded test cases.

Maintaining test cases using scripts became difficult as the Person should be Good at QA with deep understanding of Product as well as he should be good at Coding. This is the Generation which started demanding huge coding skill set from QA. But in reality percentage of Engineers who are good at both QA and Coding is very very less as there is an attitude difference in QA(Breaking) and Coding(Making). 

Third Generation in Software Test Automation(Approach)
 

Extreme Engineering is in place by this time. People realized that Test Design is more important that automation Technology. Keyword-Driven approach got introduced which facilitates one to separate Coding from Test Case logic. This helps a person who is expert in Coding to Code and QA with good Domain knowledge to write test cases. Along with this one can use Data-Driven Approach where data is separated  (not hard coded) from Test cases so that a test case can be executed across different test data sets. Also Integrated Development Environment(IDE) are developed to write test cases. More about keyword-driven approach will be discussed in my next Post.

But Software Test Automation is not just meant for execution of Test Cases as this alone will not guarantee the quality of an application.

Fourth Generation in Software Test Automation(Big Picture)

Capturing test cases from requirements is a huge task and should be done with perfection. Otherwise some of the test cases will not get captured and can result in defective product. In the process of Evolution Model -Based Testing came into existence. According to Wikipedia Model-based testing is the application of Model based design for designing and executing the necessary artifacts to perform software testing

Load Tests using JMeter

Create Test Plan in JMeter
JMeter Documentation is available here

Discussion on Different Load Testing Tools

Brain Dumps are available here
Setup of EC2 Clients
  1. Create a key-pair and copy it to your Linux Machine.
  2. Rename it as rsa-gsg-keypair(optional).
  3. Change Permissions using

    chmod 600 rsa-gsg-keypair
  4. Launch an EC2 instance from Amazon Console
  5. User guide for EC2 clients is available here
  6. Get the Public DNS Name of the instance.
  7. Now Log-in to the Instance using

    ssh -i id_rsa-gsg-keypair root@xxx.amazonaws.com
  8. If required change Client's Time Zone to GMT using

    unlink /etc/localtime
    ln -sf /usr/share/zoneinfo/GMT /etc/localtime
  9. Download JMeter using


    wget http://mirrors.axint.net/apache/jakarta/jmeter/binaries/jakarta-jmeter-2.4.tgz
  10. Install JMeter


    tar –xzf jakarta-jmeter-2.4.tgz
  11. Set path to JMeter


    export PATH=$PATH:/path_to_jmeter_bin_directory
  12. Download and install Java Runtime Environment (JRE)
  13. Get Load test Plan (jmx file of JMeter onto this client)
  14. Increase Open files limit using

    ulimit –n 8192
  15. Run Load test using

    jmeter.sh -n -t M2LoadTests.jmx -l sample.jtl -j sample.log
  16. Copying JMeter results (jtl files) on half hourly intervals make crontab entry as

    */30 * * * * /bin/cp /root/sample.jtl /root/Client-1-`/bin/date +"%Y-%m-%d-%H-%M"`.jtl
JMeter as a Service
Information on JMeter as a Service is available here

Home Work (Benchmarking)
  1. Host a simple "Hello world" HTML Page on the server on which you are going to perform Load tests
  2. Try to perform load tests by hitting "Hello World" Page using 2 clients. (500 Threads from each client)
  3. Increase number of threads by increasing no. of clients.
  4. Keep on plotting results in a graph.
  5. If it is a straight line then some thing is wrong with your setup like webserver setup (look at webserver conf file)
  6. If it is some kind of Curve shooting up then wait for a U-Turn in the curve.
  7. Get Numbers related to Latencies at this U-Turn and consider them as lowest Latencies with given setup.
  8. Get Numbers related to Throughput at this U-Turn and consider them as highest Throughput one can achieve with given setup.
  9. Also get average network latency for 100 pings using traceroute. This will be the minimum Network Latency.
Key parameters to be captured

  1. Processor Utilization


    dstat with -cp switch
  2. Memory utilization


    dstat with -m switch
  3. Disk utilization


    dstat with -d switch
  4. Network utilization


    dstat with -n switch

Points to Remember
  1. Servers should not be put behind Load Balancer
  2. Install dstat if required using


    emerge -av dstat if it is Gentoo



    yum if is RHEL
  3. Monitor Server side System Resources using


    dstat -cndymlp -N total -D total -l --output SystemMon.csv