Artem Nagornyi's SDET recipes

This is a simple shell script that replaces "Number of Threads" parameter in the original script, accepting it from the command line. touch ./run_jmeter.sh chmod +x ./run_jmeter.sh And finally insert the code below into the file using your favorite editor.

This is how we can execute a JavaScript function on a web page with Watir test automation framework .

Testing applications built with Seam Java framework is possible with JMeter like any other web applications, though there are some nuances to take into account. One of them is ViewState parameter. This parameter is dynamic and it means that we cannot just leave it hardcoded in our JMeter script because it will be broken the next time you try to execute it. Why this happens? Let's dig a little deeper. Black-box testing doesn't require us to know how Seam framework works, right? Okay, in this case we only need to know how it affects our tests. As testers we need to make sure that ViewState parameter in the POST request has the same value as returned by a previous GET request. For example you have two subsequent requests: GET http://x.x.x.x:8080/some_page.seam POST http://x.x.x.x:8080/some_page.seam The first request opens a page and the second one performs an action on the page (for instance - expands some tab, tree, etc). If you analyze the response data with a list

How to handle server-side authorization with JMeter? Well, this is probably one of the most popular questions amid the novices implementing JMeter tests. It is very straightforward to pass credentials in the POST request if this type of authorization is implemented on application side. But what if we have authorization configured on Apache web server? It is showing us a pop-up demanding user and password every time we try to access the application. However it is very easy to handle, you just need to use JMeter HTTP Authorization Manager . You can do this in two steps: Add authorization manager to your thread group: Add -> Config Element -> HTTP Authorization Manager. Set application URL, username and password fields.

How to measure the peak (maximum) number of parallel users supported by your web application? It seems to be a trivial task for JMeter, however it is not so simple. The main problem is that JMeter doesn't have a built-in feature to identify how Response Time changes with amount of parallel threads. But what if we need to measure this metric in scope of performance testing? There is a nice Response Times vs Threads plugin for JMeter. However this plugin works only with the version of JMeter starting from 2.4 and it is hard to integrate it with Continuous Integration servers. And what if we have the bunch of scripts already implemented for the older 2.3.4 version or just looking for alternative solution that is easier to integrate with our Continuous Integration server? Chronos plugin for Maven would be a good match. Integration of Maven and Chronos with JMeter had been already described in this post This what I suggest to change in your JMeter script: In "Thread group&q

There are several different approaches to integrate JMeter and Maven. We needed to use one of them to integrate our JMeter test automation suite with our continuous integration server. There are two plugins available: JMeter Maven Plugin Chronos Maven Plugin I decided to use Chronos Maven plugin. It requires explicit installation of JMeter. I've successfully configured pom.xml for running our test automation suite and reporting of the test results. You need to perform the following steps: 1. Install Apache Maven 2. Create pom.xml file and put it in a directory of your choice 3. Set your local JMeter installation directory path in jmeter.home in pom.xml file 4. Set the path to your JMeter script in pom.xml 5. Set assertions in pom.xml file if required (I didn't need this, so they are not present in the example below) 6. Create a JMeter project and copy it to test subdirectory of the directory where you stored pom.xml file. Your directory structure should

It is more challenging to implement automated tests for websites using dynamic AJAX requests which load data or elements on the fly. With Watir test automation framework there are several different approaches. We can insert some fixed sleeps before the checkpoints. However this is a bad solution in many cases because quite often we don't know the exact time it takes, also fixed sleeps can make our tests very slow, especially when we have a large test automation suite. This is my solution for Watir test automation framework. It retries any operation with the element until success. If it fails for the first time, it retries again in 3 seconds, repeating 5 times until success. We can configure the maximum number of retries and the interval between each retry. Implementation of the method in Ruby Usage examples