Learn effective techniques and best practices for RESTful API testing using JMeter

Cloud-based applications typically involve several components that interact through APIs, using XML or http://www.aliyun.com/zixun/aggregation/33906.html ">javascript Object" Notation (JSON) format for exchanging data. The technology described in this article uses the Apache JMeter (a GUI-based open source test application) to perform functional, performance, and reliability testing of cloud-enabled applications that use the RESTful Web APIs and JSON.

Learn about the capabilities of JMeter as the RESTful API Test tool and its relevance to testing cloud-based applications. Because Multi-Tenant cloud is an important cloud feature, this article will introduce techniques for integrating data separation and data retrieval programmatically to ensure data integrity. This article shows how to write a valid JMeter test script (also known as a test plan or JMX file) that helps maintain, reuse, and modularize. You also learned how to use configuration and property files to ensure that you can run the same script in multiple environments.

The authors assume that you are familiar with the JMeter user interface and have extensive experience in using JMeter.

Where to set properties to implement optimal scripting reuse

Because cloud-enabled applications can often be replicated and deployed easily and quickly, they can be tested in a variety of environments. If you need to test and run automation scripts in multiple environments, it is advantageous to use a separate property file in JMeter to define data (including logon credentials) for connection resources, such as application servers and databases.

Define JMETER properties and variables in the three files in the Jmeter_home/bin directory. When you start JMeter, it loads the files in the following order:

jmeter.properties An optional user-defined property file System.properties

When JMeter is running, if you want to add any new attributes or change existing properties, you must first turn off JMeter and then restart it for the change to take effect.

The Jmeter.properties file stores properties related to the JMeter application itself. Only attributes that are specific to the JMeter program are retained in this file or are specific to the framework. Create a separate file (the filename you choose) to use to store the test environment-specific properties and variables, which are global properties and variables for all scripts associated with the application being tested-for example, the Administrator's username/password. In the Jmeter.properties file, uncomment the User.properties setting and set the User.properties value to the name of the file you created. The example in Listing 1 sets the value to Myuser.properties:

Listing 1. Specify a user property file in the Jmeter.properties file

# Should JMeter automatically load additional JMeter properties?# File name to look for (comment to disable) User.properties=myuser.properties

The sample user properties file in Listing 2 shows the format used to define variables in the user's properties file. (in this definition, spaces are not allowed anywhere on the left side of the equal sign; property values can contain spaces if necessary).

Listing 2. Sample User Properties File

#----------------------------------------------------------------# FVT API Test Environnement parameters#------------ ----------------------------------------------------# #---Login credentialsuser_login=admin@in.ibm.comuser_ password=password##---creator serverapp_server=localhostapp_port=80app_context=ctxprotocol=http##--- Database Server${db_name}db_host=localhostdb_port=50000db_name=dbnamedb_user=dbadmindb_password=dbpassword

The third property file system.properties of the JMeter should be retained so that it must be available to all system-defined attributes that all scripts define. For example, if all your scripts use a particular database server, you can specify the related properties in the System.propterties file.

The JMeter User tabbed Variables Control Panel (shown in Figure 1) shows how the JMeter script reads the properties defined in the user's properties file.

Figure 1. How the JMeter script reads configuration data defined in the user's properties file

The format of each item in the Value column of the Control Panel is:

${__property (variable_name,variable_name)}

For example, the User_login variable from the user's property file is read as the ${__property (User_login, User_login)} function in the script. The first user_login in parentheses is the name of the variable defined in the property file (and is listed in the Control Panel's name column). If a variable is not defined in the property file, the second instance is the default value or the fallback value.

When you define a variable in a property file and when it is defined as a variable in the JMeter script, there are no strict rules. But there are two guidelines that can help you achieve consistency in multiple JMeter scripts and reduce unnecessary duplicate variable definitions:

If you use the same values consistently in several scripts, you can define the data in either the user properties file or the System.properties file. Examples of this include system variables (for example, database name and server name), and variable execution scope (for example, log level). If some scripts use a value that may change in each script, you can define it as a script variable or define it in an external data file, such as a comma-separated value (CSV) file.