Difference between revisions of "Building JMeter scripts with GXtest"

From GXtest Wiki
Jump to: navigation, search
(→‎Tips for performance projects)
 
(7 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
| Generando scripts JMeter con GXtest
 
| Generando scripts JMeter con GXtest
 
| Building JMeter scripts with GXtest
 
| Building JMeter scripts with GXtest
−
| Building JMeter scripts with GXtest
+
| GXtest の JMeter スクリプトの構築
 
}}
 
}}
  
 
== JMeter ==
 
== JMeter ==
−
[https://jmeter.apache.org/ JMeter] is an open source tool for performance testing and it is used for automating test cases, generating scripts that contain the http (or https) requests executed in each test case, and it allows modifications in order to perform some actions (such as introducing validations, conditions, parameterizations, etc.).
+
[https://jmeter.apache.org/ JMeter] is a free open source tool for performance (load / stress) testing and actually the most used tool in this area, enabling running http (or https) requests to the web server simulating a browser without actually using one. Using GXtest, you will able to build JMeter scripts with a simple click, and after that being able to adapt it in order to perform your own actions (such as introducing validations, conditions, parameterizations, etc.).
  
−
JMeter allows us to mount test scenarios where we can define the amount of active users, the number of iterations, the way in which users access the system and other options that let us represent the most realistic scenario. The figure below shows an example of a JMeter test plan.
+
JMeter allows to run test scenarios defining a large amount of active users, iterations, and simulating environments under certain loads to represent a realistic scenario. The figure below shows an example of a JMeter test plan.
  
 
[[image:JmeterExample.PNG|frame|center]]
 
[[image:JmeterExample.PNG|frame|center]]
  
−
Alike OpenSTA, a drawback of JMeter is the test case recording process. When recording the test cases we get a script with the http requests that were made, therefore, for someone that has no knowledge of the application, it will be really difficult to identify each step, or what each request does. Many times, in order to have a clearer script, we can introduce comments between each step during the recording, as well as timers that control the timing of each step. If on top of that, we want to add validations or parameterized variables, we can conclude that doing a script with JMeter is a tedious task and it may be annoying in those projects where the application’s code is being constantly changed, which means that the scripts have to be often re-generated.
+
JMeter test case generation process is achieved by running the test case in the browser and capturing HTTP requests that were made automatically using a Proxy. This enable people without JMeter experience to first create the test case (flow and data using datapools) in GXtest, and to provide this script to a performance expert who will be able to finish the JMeter script properly (specially adding regular expressions and adding some hardcoded parameters) .  
  
−
It is advisable for a performance project that JMeter measurements are complemented with GX monitoring tools, such as [http://wiki.gxtechnical.com/commwiki/servlet/hwiki?Application+Monitoring+and+Management%3A+using+a+JMX+or+WMI+monitor, JMX].
+
Without this process, it will be really difficult to identify steps and to identify what each request does in terms of functional /business rules. In order to have an understandable script it is possible to introduce comments between each step (during the recording), as well as timers to control each step.  
  
−
== Generando scripts de performance con GXtest ==
+
Creating JMeter scripts without GXtest is usually a tedious task that can be hard to accomplish, specially when the application’s code is being constantly changing, which means that the scripts have to be almost complete re-generated. Also, please note that if you plan to run test scripts using Ajax encryption (enabled by default in GeneXus) it would be almost impossible to make it without GXtest generation due to encryption.
  
−
GXtest can generate JMeter scripts from a previously recorded test case. This gives many advantages to the tester:
+
== Tips for performance projects ==
 +
By default it is very hard to make performance testing scripts in GeneXus since there are a lot of parameters that you will not control over HTTP request and HTTP responses. That said, it is almost a must to turn Ajax Security off to properly generate parametrized requests and avoiding STATUS CODE 403 - Not authorized results in GeneXus.
 +
http://wiki.genexus.com/commwiki/servlet/wiki?17384,Javascript+Debug+Mode+property,
  
−
*Recording the test cases with GXtest, which is done in a much more practical way and allows to add validations and more options which are mentioned in other articles.
 
−
*Automatization of the most tedious parts of the script, without the need of wasting time in executing repetitive tasks.
 
−
*In the event of a change in the application, the possibility of taking those changes to GXtest and then re-generate the scripts in an easy way, without the need of recording them again in GXtest.
 
−
*No need of introducing validations manually, timers or parametrizations. Normally, this turns into a considerably long task and usually presents problems. GXtest automatically introduces all these elements.
 
−
*Having the secondary requests (css, gif, jpg, js, etc.) in separate files, away from the primary ones. This allows to have a clearer script which makes analysing easier.
 
−
*The use of debugging flags that condition the secondary requests and log messages.
 
−
*Support of NTLM authentication.
 
−
*Automatical management of all redirects.
 
  
 +
Strongly consider to compliment test execution results with GeneXus monitoring tools, such as [http://wiki.genexus.com/commwiki/servlet/wiki?27299,Management+and+Performance+information+using+JMX+or+WMI,, JMX or WMI].
  
−
=== How does the script generator work? ===
+
 
 +
If you want to simulate real behavior using Ajax Encryption, we have included in [[GXtest_3.2-RC]] the ability to encrypt Ajax request in runtime as well as other common parametrizations like AJAX_KEY, AJAX_SECURITY_TOKEN, GX_WEBSOCKET_ID, and other variables.
 +
 
 +
== Generating JMeter scripts with GXtest ==
 +
 
 +
GXtest can generate JMeter scripts from a previously recorded test case. This gives many advantages to users, including:
 +
 
 +
* Recording test cases with GXtest, which can be done by a functional without performance automation experience. (after generation, a performance tester will need to work on top of that).
 +
*Automatic generation of the most tedious part of the script without wasting time running repetitive tasks.
 +
*No need of introducing top validations manually, timers or basic parametrizations. Normally, this turns into a considerably long task and usually presents problems. GXtest automatically introduces all these elements.
 +
*The use of debugging flags for think times and log messages.
 +
*Support of NTLM authentication.
 +
*Automatic management of redirection.
 +
 
 +
=== How does the script generator works? ===
  
 
The performance script is created by clicking the GXtest Designer button "Generate JMeter scripts".
 
The performance script is created by clicking the GXtest Designer button "Generate JMeter scripts".
Line 36: Line 45:
 
[[File:JmeterButton.PNG]]
 
[[File:JmeterButton.PNG]]
  
−
When sending the request to create an JMeter script, the test case will start executing as usual in the user’s screen. Nevertheless, there are many different actions happening internally: in the course of the test case execution, a xml file is created with all the GXtest commands that are being used in the test, while http requests are recorded into a saz extension file. This files are left inside a folder with the name of the test case, where the GXtest Designer is installed, normally in: ''Abstracta\GXtest Designer\Performance\ExecutionLog\''.
+
When sending the request to create an JMeter script, the test case will start executing as usual in the user’s screen. Nevertheless, there are many different actions happening internally: in the course of the test case execution, a xml file is created with all the GXtest commands that are being used in the test, while http requests are recorded into a .saz extension file. This files are left inside a folder with the name of the test case, where the GXtest Designer is installed, normally in: ''Abstracta\GXtest Designer\Performance\ExecutionLog\''.
  
−
The ''saz'' format belongs to the [http://www.fiddler2.com Fiddler] tool, which is a proxy that records http traffic between Internet and the PC, that then can be analyzed by introducing breakpoints, editing requests at protocol level, etc.
+
The ''saz'' format belongs to the [http://www.fiddler2.com Fiddler] tool, which is a proxy that records http traffic between Internet and the PC, that then can be analyzed by introducing breakpoints, editing requests at protocol level, etc. This file is very important to performance automators in order to compare original requests and understand how they should parametrize the rest of the script in Jmeter.  
  
 
With these two files (xml and saz), the JMeter test plan is generated using GXtest commands from the xml file and http(s) requests from the saz file. Once the execution is completed, the resulting script will have each GXtest command that was executed, associated with the http(s) requests that are involved in each of them, with their appropriate timers, and in the case they have been introduced, the corresponding validations. The resulting file is created in the folder ''Abstracta\GXtest Designer\JMeter''.
 
With these two files (xml and saz), the JMeter test plan is generated using GXtest commands from the xml file and http(s) requests from the saz file. Once the execution is completed, the resulting script will have each GXtest command that was executed, associated with the http(s) requests that are involved in each of them, with their appropriate timers, and in the case they have been introduced, the corresponding validations. The resulting file is created in the folder ''Abstracta\GXtest Designer\JMeter''.
  
−
In general, the resulting scripts are ready to be executed without doing any changes. Although, depending on the system, some modifications might be done to add conditions, variables, validations, etc., so the script will behave as real as possible.
+
The resulting scripts may be ready to be executed without changes, but usually modifications and parametrizations needs to be done by a JMeter expert, specially if the system is using Ajax Encryption. Usually, there is need to: add some conditions, parametrize new variables, add system validations, etc. in order to make a performance script as real as possible.
 +
 
 +
=== GXtest Features for building JMeter scripts ===
 +
 
 +
As told, GXtest generates the majority of the work by creating the Jmeter script automatically and it is almost a must to make performance testing in GeneXus.
 +
 
 +
Top features are:
 +
 
 +
* Script readability
 +
** The generated script is readable and modular.
 +
** Traceability between user actions (GXtest commands) and HTTP request
 +
** Global variable parametrization such as: webServer, port, webapp, threads, ramp up, etc.
 +
** Introduction of Thinktimes between each user action
 +
 
 +
* Follow redirect:
 +
** All requests that causes STATUS CODE 302 are discarded
 +
** JMeter follow-redirect steps to improve robustness
 +
** Deleted secondary requests. Using JMeter "Retrieve embedded resources" feature instead
 +
 
 +
* Error debugging
 +
** All request and responses are logged in JMeter's log to enable an easy debugging
 +
** DEBUG FLAG: enable to skip Think-times (faster execution running when building the script)
 +
 
 +
* Result analysis
 +
** User actions are grouped to better understand response times.
 +
 
 +
* Automatic Parameters
 +
** GX Variables and Test Data used by Datapools (when data used is bigger than 3 chars)
 +
** Ajax security variables (GX_AJAX_KEY, AJAX_SECURITY_TOKEN)
 +
** Common vars (GX_WEBSOCKET_ID)
 +
** Beanshell generation to automatically encrypt URL parameters in AJAX requests
 +
 
 +
* Good practices
 +
** Cookies are deleted before generation.
 +
** Usage of Cookie Manager in JMeter
 +
 
 +
=== Unsupported items===
 +
There are some items that would be nice to include in next versions of GXtest that are currently not being generated:
 +
* Uploading binaries
 +
* More Genexus variables
 +
* User / developers variables
  
  
Line 49: Line 98:
 
After the test case is executed from GXtest Designer, the JMeter test plan generated will be available in GXtest installation folder ''Abstracta\GXtest Designer\JMeter''.
 
After the test case is executed from GXtest Designer, the JMeter test plan generated will be available in GXtest installation folder ''Abstracta\GXtest Designer\JMeter''.
  
−
The generated file will have the jmx extension, and it can be open from the File -> Open JMeter's menu.
+
The generated file will have the .jmx extension, and it can be open from the File -> Open JMeter's menu.
  
  
Line 55: Line 104:
  
 
JMeter is a free tool and can be downloaded from its [https://jmeter.apache.org/ web site]
 
JMeter is a free tool and can be downloaded from its [https://jmeter.apache.org/ web site]
−
 
  
 
== Summary ==
 
== Summary ==
  
−
GXtest allows to create scripts to use in performance tests with the JMeter tool. When generating the scripts from GXtest, the tester saves loads of time from doing repetitive tasks, and it gives him the possibility to focus on other activities to reduce the amount of performance errors and therefore obtain a better quality product.
+
GeneXus hides all complexity to developers as well as GXtest allows to create Jmeter scripts make performance testing in GeneXus.  
 +
Generating scripts using the tool will save a lot of time and relieve headaches with handling GeneXus requests.
 +
 
 +
Also, if AJAX SECURITY is enabled, GXtest will be probably the only option to handle such complexity on scripts.

Latest revision as of 17:47, 25 November 2016

Spanish.gif
English.gif
Japan.gif

Contents

JMeter

JMeter is a free open source tool for performance (load / stress) testing and actually the most used tool in this area, enabling running http (or https) requests to the web server simulating a browser without actually using one. Using GXtest, you will able to build JMeter scripts with a simple click, and after that being able to adapt it in order to perform your own actions (such as introducing validations, conditions, parameterizations, etc.).

JMeter allows to run test scenarios defining a large amount of active users, iterations, and simulating environments under certain loads to represent a realistic scenario. The figure below shows an example of a JMeter test plan.

JmeterExample.PNG

JMeter test case generation process is achieved by running the test case in the browser and capturing HTTP requests that were made automatically using a Proxy. This enable people without JMeter experience to first create the test case (flow and data using datapools) in GXtest, and to provide this script to a performance expert who will be able to finish the JMeter script properly (specially adding regular expressions and adding some hardcoded parameters) .

Without this process, it will be really difficult to identify steps and to identify what each request does in terms of functional /business rules. In order to have an understandable script it is possible to introduce comments between each step (during the recording), as well as timers to control each step.

Creating JMeter scripts without GXtest is usually a tedious task that can be hard to accomplish, specially when the application’s code is being constantly changing, which means that the scripts have to be almost complete re-generated. Also, please note that if you plan to run test scripts using Ajax encryption (enabled by default in GeneXus) it would be almost impossible to make it without GXtest generation due to encryption.

Tips for performance projects

By default it is very hard to make performance testing scripts in GeneXus since there are a lot of parameters that you will not control over HTTP request and HTTP responses. That said, it is almost a must to turn Ajax Security off to properly generate parametrized requests and avoiding STATUS CODE 403 - Not authorized results in GeneXus. http://wiki.genexus.com/commwiki/servlet/wiki?17384,Javascript+Debug+Mode+property,


Strongly consider to compliment test execution results with GeneXus monitoring tools, such as JMX or WMI.


If you want to simulate real behavior using Ajax Encryption, we have included in GXtest_3.2-RC the ability to encrypt Ajax request in runtime as well as other common parametrizations like AJAX_KEY, AJAX_SECURITY_TOKEN, GX_WEBSOCKET_ID, and other variables.

Generating JMeter scripts with GXtest

GXtest can generate JMeter scripts from a previously recorded test case. This gives many advantages to users, including:

  • Recording test cases with GXtest, which can be done by a functional without performance automation experience. (after generation, a performance tester will need to work on top of that).
  • Automatic generation of the most tedious part of the script without wasting time running repetitive tasks.
  • No need of introducing top validations manually, timers or basic parametrizations. Normally, this turns into a considerably long task and usually presents problems. GXtest automatically introduces all these elements.
  • The use of debugging flags for think times and log messages.
  • Support of NTLM authentication.
  • Automatic management of redirection.

How does the script generator works?

The performance script is created by clicking the GXtest Designer button "Generate JMeter scripts".

JmeterButton.PNG

When sending the request to create an JMeter script, the test case will start executing as usual in the user’s screen. Nevertheless, there are many different actions happening internally: in the course of the test case execution, a xml file is created with all the GXtest commands that are being used in the test, while http requests are recorded into a .saz extension file. This files are left inside a folder with the name of the test case, where the GXtest Designer is installed, normally in: Abstracta\GXtest Designer\Performance\ExecutionLog\.

The saz format belongs to the Fiddler tool, which is a proxy that records http traffic between Internet and the PC, that then can be analyzed by introducing breakpoints, editing requests at protocol level, etc. This file is very important to performance automators in order to compare original requests and understand how they should parametrize the rest of the script in Jmeter.

With these two files (xml and saz), the JMeter test plan is generated using GXtest commands from the xml file and http(s) requests from the saz file. Once the execution is completed, the resulting script will have each GXtest command that was executed, associated with the http(s) requests that are involved in each of them, with their appropriate timers, and in the case they have been introduced, the corresponding validations. The resulting file is created in the folder Abstracta\GXtest Designer\JMeter.

The resulting scripts may be ready to be executed without changes, but usually modifications and parametrizations needs to be done by a JMeter expert, specially if the system is using Ajax Encryption. Usually, there is need to: add some conditions, parametrize new variables, add system validations, etc. in order to make a performance script as real as possible.

GXtest Features for building JMeter scripts

As told, GXtest generates the majority of the work by creating the Jmeter script automatically and it is almost a must to make performance testing in GeneXus.

Top features are:

  • Script readability
    • The generated script is readable and modular.
    • Traceability between user actions (GXtest commands) and HTTP request
    • Global variable parametrization such as: webServer, port, webapp, threads, ramp up, etc.
    • Introduction of Thinktimes between each user action
  • Follow redirect:
    • All requests that causes STATUS CODE 302 are discarded
    • JMeter follow-redirect steps to improve robustness
    • Deleted secondary requests. Using JMeter "Retrieve embedded resources" feature instead
  • Error debugging
    • All request and responses are logged in JMeter's log to enable an easy debugging
    • DEBUG FLAG: enable to skip Think-times (faster execution running when building the script)
  • Result analysis
    • User actions are grouped to better understand response times.
  • Automatic Parameters
    • GX Variables and Test Data used by Datapools (when data used is bigger than 3 chars)
    • Ajax security variables (GX_AJAX_KEY, AJAX_SECURITY_TOKEN)
    • Common vars (GX_WEBSOCKET_ID)
    • Beanshell generation to automatically encrypt URL parameters in AJAX requests
  • Good practices
    • Cookies are deleted before generation.
    • Usage of Cookie Manager in JMeter

Unsupported items

There are some items that would be nice to include in next versions of GXtest that are currently not being generated:

  • Uploading binaries
  • More Genexus variables
  • User / developers variables


How to import the generated file into JMeter?

After the test case is executed from GXtest Designer, the JMeter test plan generated will be available in GXtest installation folder Abstracta\GXtest Designer\JMeter.

The generated file will have the .jmx extension, and it can be open from the File -> Open JMeter's menu.


Installing JMeter

JMeter is a free tool and can be downloaded from its web site

Summary

GeneXus hides all complexity to developers as well as GXtest allows to create Jmeter scripts make performance testing in GeneXus. Generating scripts using the tool will save a lot of time and relieve headaches with handling GeneXus requests.

Also, if AJAX SECURITY is enabled, GXtest will be probably the only option to handle such complexity on scripts.

Retrieved from "http://gxtest.abstracta.com.uy/wiki/index.php?title=Building_JMeter_scripts_with_GXtest&oldid=4792"