RESTful API test using JMeter

Where to set the attributes for optimal script reuse

Since cloud-enabled applications can usually be copied and deployed easily and quickly, they can be tested in a variety of environments. If you need to test and run automated scripts in multiple environments, you can use a separate properties file in JMeter to define data (including login credentials) for connection resources (such as application servers and databases), which is very beneficial.

Define JMeter attributes and variables in three files under the JMETER_HOME/bin directory. When starting JMeter, it loads these files in the following order:

1. jmeter.properties
2. An optional user-defined properties file
3. system.properties

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

The jmeter.properties file stores properties related to the JMeter application itself. Only the attributes specific to the JMeter program or the attributes specific to the framework are retained in this file. Create a separate file (the file name is chosen by you) and use this file to store test environment-specific attributes and variables, which are global attributes and variables for all scripts associated with the application under test—for example, The username/password of the administrator. In the jmeter.properties file, uncomment the user.properties settings and set the value of user.properties to the name of the created file. The example in Listing 1 sets the value to myuser.properties:

Listing 1. Specify a user properties 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 example user properties file in Listing 2 shows the The format used to define variables in the user properties file. (In this definition, no spaces are allowed anywhere on the left side of the equal sign; when necessary, the attribute value can contain spaces).

Listing 2. Example user properties file

#----------------------- -----------------------------------------
# FVT API Test Environment parameters
#-------------------------------------------- --------------------
#
# --- Login Credentials
[email protected]
USER_PASSWORD=password 
#
# --- Application Server
APP_SERVER=localhost
APP_PORT=80
APP_CONTEXT=ctx
PROTOCOL=http
#
# --- Database Server${DB_NAME}
DB_HOST=localhost
DB_PORT=50000
DB_NAME=dbname
DB_USER=dbadmin
DB_PASSWORD=dbpassword

The third property file system.properties of JMeter should be retained so that system-wide properties that must be defined for all scripts can use it. For example, if all your scripts use a specific database server, you can specify the relevant properties in the system.propterties file.

JMeter’s User Defined Variables control panel (shown in Figure 1) shows how the JMeter script reads the attributes defined in the user properties file.

Figure 1. How the JMeter script reads the configuration data defined in the user 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 properties file is Read as the ${__property(USER_LOGIN, USER_LOGIN)} function in the script. The first USER_LOGIN in the brackets is the name of the variable defined in the properties file (and is listed in the Name column of the control panel). If the variable is not defined in the properties file, then the second instance is the default value or fallback value.

When to define a variable in the properties file and when to define it 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 the same value is used consistently in several scripts, then The data can be defined in the user properties file or the system.properties file. Examples of this include system variables (for example, database name and server name), and execution-scope variables (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, for example, a comma separated value (CSV) file .

Use JSON template files for payload separation

Many cloud APIs require JSON payloads as input. JSON defines a set of structured elements, which can be nested in other elements. Each element defines one or more name/value pairs. Functional testing involves repeatedly providing data in a specified format. For example, in a typical REST API call, the JSON payload is passed in the body of the REST HTTP request and usually contains hard-coded data. Hard-coded data is often repeated in multiple tests and scattered throughout the script.

A common problem with this method is that if the JSON structure (or data) changes (perhaps because of changes in API parameters), then you must enter the JMeter test, find the body of the HTTP request, and modify it JSON structure (and data) to meet new requirements. If there are thousands of HTTP requests in multiple JMeter test cases that use this JSON structure, then many repeated edits must be performed.

A better way is to create a JSON structure template and define the replacement string for the data destination. The JSON template does not contain any hard-coded data values, but defines reference variables that are loaded with the actual data when the script is running. Then, the template is read into a variable in the JMeter script and replaced in the HTTP request body.

Listing 3 shows the traditional way of defining a JSON payload:

Listing 3. Static JSON definition in the JMeter test plan

 {
 "Customer":{
 "CustomerType":"DIRECT",
 "CustomerNumber":"1234567890",
 "Organization":{
 "OrgName" :"IBM",
 "Phone":"999-999-9999",
 "AddressSet":[

 {
 "AddressLine1":"Tech Park One",
 "AddressLine2":"",
 "AddressType":"MAILING",
 "City":"Pune",
 "Country":"India", 
 "State":"Maharashtra",
 "StateCode":"MH",
 "PostalCode":"411006"
 }
 ],
 "Contact":{
 "FamilyName":"Gilra",
 "GivenName":"Shalini",
 "EmailAddress":"[emailprotected]",
 "NamePrefix ":"Miss",
 "LanguagePreference":"EN_US",
 "WorkPhone":"999-99 99"
 }
 }
 }
}

Listing 4 shows the dynamic way of defining JSON in a template:

Listing 4. Dynamic JSON definition in external JSON template file

{ 
 "Customer":{ 
 "CustomerType":"${__eval(${STR_CUSTOMERTYPE })}", 
 "CustomerNumber":"${__eval(${STR_CUSTOMERNUMBER})}", 
 "Organization":{ 
 "OrgName":"${__eval(${ STR_ORGNAME})}", 
 "Phone":"${__eval(${STR_PHONE})}", 
 "AddressSet":[ 
 {
 "AddressLine1":" ${__eval(${STR_ADDRESSLINE1})}", 
 "AddressLine2":"${__eval(${STR_ADDRESSLINE2})}", 
 "AddressType":"${__eval(${STR_ADDRESSTYPE} )}", 
 "City":"${__eval(${STR_CITY})}", 
 "Country":"${__eval(${STR_COUNTRY})}", 
 "State":"${__eval(${STR_STATE})}", 
 "StateCode":"${__eval(${STR_STATECODE})}", 
 "PostalCode":"${__eval (${STR_POSTALCODE})}", 
 } 
 ], 
 "Contact":{ 
 "FamilyName":"${__eval(${STR_FAMILYNAME})}", 
 "GivenName":"${__eval( ${STR_GIVENNAME})}", 
 "EmailAddress":"${__eval(${STR_EMAILADDRESS})}", 
 "NamePrefix":"${__eval(${STR_NAMEPREFIX})}", 
 "LanguagePreference":"${__eval(${STR_LANGUAGEPREFERENCE})}", 
 "WorkPhone":"${__eval(${STR_WORKPHONE})}", 
} 
} 
} 
}

The JSON entity in Listing 3 only contains hard-coded data. In contrast, the template in Listing 4 only contains the name of the reference variable, so any JMeter test plan can use the template. The actual data is stored separately in the CSV data file, which we will discuss in the next section.

Please note that the JSON in Listing 4 calls the JMeter __eval() function for each defined substitution variable. This added step makes it possible to calculate variables when executing JMeter scripts at runtime.

Figure 2 and Figure 3 show how to specify the JSON entity template file in the JMeter test script. Figure 2 shows the HTTP Request control panel:

Figure 2. The content of a template file used in the test

In the example in Figure 2, the CUSTOMER_JSON variable represents the entire JSON Customer element. This variable is enclosed in the _eval() function and displayed as the body of the HTTP request (under the heading Send Parameters With the Request on the Parameters tab). Then, in Figure 2, the request body is ${_eval(${CUSTOMER_JSON})}.

Define the CUSTOMER_JSON variable in the User Parameters control panel, as shown in Figure 3:

Figure 3. Read the JSON template file in the JMeter script

In Figure 3, the CUSTOMER_JSON variable is set to FileToString(), and the path to the JSON template file is used as a parameter. All the contents of the JSON entity template file are read into the CUSTOMER_JSON variable. Therefore, the content of the JSON entity template file is calculated at runtime, and all the substitution strings defined are translated into the data defined by them. (The next section will explain how substitution variables are related to actual data).

Because JMeter’s JSON entity template files are external to JMeter test scripts, you can store them in a separate directory, such as JMETER_HOME/tests/jsontemplates. When you access a JSON entity template in the JMeter test plan, you can specify the name relative to the JMeter BIN directory, for example:

../tests/jsontemplates/customer_template.json

You can also store the template in a place other than the JMETER_HOME directory, in which case you must provide an absolute path.

Data abstraction using the CSV Data Set Config element

Although separating the test data from the JMeter test plan initially looks like Extra work was performed, but the separation results in a more concise test are also easier to manage. When you need to modify the test, you can quickly realize some benefits. Some data may still be located locally and exist in each test plan, but most of the test data is abstracted into external files — in properties files (as we discussed earlier) or a CSV data configuration file. The resulting test suite is easier to maintain, and in most cases, you can modify any data value without editing the JMeter test plan.

JMeter uses CSV files to store comma-separated data rows. The CSV Data Set Config function of the JMeter framework provides a way to dynamically read the test data of the CSV file at runtime. Another benefit of storing test data as CSV is that you can store multiple rows of data representing multiple data objects/variables, or multiple iterations of loop processing. JMeter 2.3.4 and later versions also support providing a CSV title as the first line of the file. Then, use the delimited string name of the title to store the defined data value. Normally, each subsequent row of data represents an iteration of the loop. In this sense, the script is mainly “data-driven”, and testers can modify the data in the CSV file without any changes to the JMX script.

Testers can also share data across multiple test threads and store test data in multiple CSV files. For example, if a test logs in with a set of user credentials, and then creates an order for that user, you can create two CSV files: one to save the user’s credentials and the other to save the order information. Sometimes, it may be necessary to create multiple JMX scripts to access the CSV file. In this case, you must place the CSV file in a location that can be accessed by multiple scripts.

Iteration data defined in a CSV file is usually associated with variable names. You can define these variable names in the title, separated by commas, and they match the number of data values ​​one-to-one. As JMeter processes each line of the file, it will assign the appropriate data value to the variable name associated with that location. Listing 5 shows the contents of a sample CSV file:

List 5. Sample CSV file (customer.csv)

"STR_TESTCASE","STR_CUSTOMERTYPE", "STR_CUSTOMERNUMBER","STR_ORGNAME","STR_PHONE",
"STR_ADDRESSLINE1","STR_ADDRESSLINE2","STR_ADDRESSTYPE","STR_CITY","STR_COUNTRY",
"STR_STATE","STR_STATECODE","STR_POSTCODEAL ","STR_FAMILYNAME","STR_GIVENNAME",
"STR_EMAILADDRESS","STR_NAMEPREFIX","STR_LANGUAGEPREFERENCE","STR_WORKPHONE", 

"Testcase1","DIRECT","1234567890", "IBM","999-999-9999","Tech Park One","","MAILING",
"Pune","India","Maharashtra","MH","411006"," Gilra","Shalini","[email protected]","Miss",
"EN_US","999-9999", 

"Testcase2","DIRECT","1234567891 ","IBM","999-999-9999","Tech Park One","","MAILING",
"Pune","India","Maharashtra","MH","411006" ,"Prakash","Prem","[email protected]",
"Mr","EN_US","999-9999", 

"Testcase3","DIRECT", "1234567892","IBM","999-999-9999","550, Kings Street","","MAILING",
"Littleton","United States","MA","MA" ,"1460- 1250","Tuohy","Tom","[email protected]","Mr",
"EN_US","999-9999",

When JMeter processes the CSV file in Listing 5, for the first iteration, Pune will be assigned to the STR_CITY variable, India will be assigned to the STR_COUNTRY variable, and so on. Then, do the same for the next two rows/iterations, but use the values ​​specified on those rows. When the script runs, the specified variables are loaded and contain their values ​​until they are overwritten or the script ends. To avoid inadvertently overwriting variables, please name the variables carefully. In addition, when you are debugging a JMeter script, it is important to know where the variable originated, because the script itself does not define that location. It is helpful to use a consistent variable name naming convention in the CSV file.

Figure 4 shows how to specify a CSV file in the CSV Data Set Config control panel:

Figure 4. Specify and read a CSV file in JMeter< /p>

In Figure 4, the Filename field is set to the relative path of the CSV file to be read. The “Allow quoted data?” value is set to true because the data value in the CSV file is enclosed in quotation marks. The “Recycle on EOF?” option is set to false and the “Stop thread on EOF?” option is set to true, which will cause the thread to stop when it reaches the end of file (EOF).

Use While Controllers to implement loops

After separating the test data into separate CSV Data Set Config files, it can be easier Use the data set to iterate through a set of similar but independent operations. JMeter provides loop constructors such as While Controller to help iterate. By organizing the test operations in the loop constructor, you can perform all the data-driven tests you need in a JMeter test plan.

This method is useful for cloud testing because it addresses the need for testing to access APIs from multiple access roles or different data sets (positive, negative, boundary values, etc.). Using loops, all test arrangements of an API test target can be placed in a test plan, which makes writing test cases at least 20 times faster.

Figure 5 shows how to use the While Controller control panel to tell JMeter to loop through all the CSV file data:

Figure 5. Loop through all the data in the CSV file

In Figure 5, the Condition (function or variable) field is set to the jexl() function. This function compares the variables from the CSV data file with EOF. When there are no other data rows in the CSV file, it tells JMeter to exit the loop. The condition can be any variable or function whose final result is false.

Use BeanShell to write scripts

By using the BeanShell scripting language, you can perform Java programming in JMeter scripts. For example, the BeanShell script is useful in situations where the script must manipulate variables captured with JMeter’s Regular Expression Extractor. The BeanShell script executes the program passed to it and returns the result at runtime.

In some cloud applications, the response data (possibly in JSON format) returned from an API command is used as the request data for another API command, with some modifications. Using unknown dynamic data can be tricky and difficult unless you can use programming in scripts. With the BeanShell script, you can manipulate the JSON payload or read the attribute values ​​of the JSON payload at runtime by using the JSONObject class library. In order to use JSONObject in JMeter scripts, you can include java json.jar in JMeter’s classpath by copying the JAR to the JMETER_HOME/lib folder.

You can define and use BeanShell scripts in a variety of ways for different purposes. Using BeanShell PreProcessor or PostProcessor, you can apply a piece of code in the JMeter BeanShell Sampler before or after the sampler is executed. With BeanShell Assertion, you can perform conditional tests, such as whether a JMeter variable saves an expected value.

The general steps to define and use a BeanShell script are:

1. In JMeter, create a BeanShell Listener, a BeanShell PreProcessor, a BeanShell PostProcessor, or a BeanShell Sampler.
2. Use vars.get(“variable”) in the BeanShell script to get variables.
3. Use the Java programming language to process BeanShell scripts.
4. In the BeanShell script, use vars.put(“variable”) to put the processed variable back into the specified JMeter variable (this can be an existing variable or a new variable).

The sample BeanShell script in Listing 6 modifies the GivenName and WorkPhone values ​​of the third level of JSON nested in Listing 3:

Listing 6. Using the BeanShell script to modify two JSON values

custPayload = vars.get("testResp");
org.json.JSONObject custJSON = new org.json.JSONObject(custPayload) ;

if (custJSON.has("Customer") && custJSON.get("Customer")!= null) {
 org.json.JSONObject contactJSON = custJSON.getJSONObject("Customer ").getJSONObject(
 "Organization").getJSONObject("Contact");
 contactJSON.put("GivenName", "Shalini");
 contactJSON.put("MobilePhone", "9923406159");
}
vars.put("updatedCustPayload", custJSON.toString());

Now, requests can use ${updatedCustPayload} in API UPDATE commands variable.

You can use BeanShell scripts to manipulate JMeter variables or JSON data in many other ways — such as performing arithmetic operations, extracting the value of a variable, or substituting the value of a specific variable for the value of another variable. In general, BeanShell can be used to perform tasks that JMeter does not directly support.

Using Module Controller to modularize reusable fragments

A complex test plan includes many variables and functions, which is very common . Usually, these fragments are used more than once or twice in other test plans. In this case, these fragments can be split into several sub-modules that can be reused in other places to reduce maintenance workload. Then, if a reusable feature needs to be modified in the future, you only need to modify it somewhere.

JMeter Module Controller is a mechanism that can replace test plan fragments in the current test plan at runtime. Fragments can be in any thread group or on WorkBench. Any fragment used by the Module Controller must have a unique name because that name is used to find the target controller when reloading a test plan.

The example in Figure 6 shows where the Module Controller is placed and the module called in the script:

Figure 6. The placement of the Module Controller and what it points to Module

In the test plan shown in Figure 6, Register Customer is defined as a separate module and is placed in the WorkBench section. The Module Controller (Module Controller-Register Customer) is placed after the Login User routine and before the Logout, pointing to the Register Customer module. When running the script, the Module Controller replaces the Register Customer module in the test plan at the location of the Module Controller.

Figure 7 shows how to define a Module Controller in the script:

Figure 7. Module Controller points to a simple controller defined in WorkBench

In Figure 7, select the Register Customer module from the drop-down list in the Module To Run field, which lists all available modules.

When reusable components are reused in the same script (JMX file), Module Controller can be used. If you will use reusable fragments in other scripts, you can move the fragments to a separate JMX file and call it using the Include Controller, which will be described in detail in the next section.

Use Include Controller to include reusable JMeter files

JMeter’s Include Controller provides a placeholder for one of the JMX files (Parent script) can call another JMeter script (child script). By splitting the script into smaller scripts or modules/routines, and using these subroutines to build a test suite, modularization can be achieved in the scripts to enhance comprehensibility and reusability. Use Include Controller to separate reusable code snippets or prerequisites (such as Login User and Register User) to help better manage and maintain scripts.

To use Include Controller, you first need to create a child JMX file that contains a reusable routine (such as Login Admin User). Figure 8 shows a sample child script, which can be included in the parent script through Include Controller:

Figure 8. Child JMX file (LoginUser.jmx)

< p> The sub-script in Figure 8 defines a test plan, which contains a sample program and a Login User HTTP request. In the HTTP request, the variables used in the protocol, server name, and other settings are defined in the parent script.

The next step is to add an Include Controller where you want to call the child script in the parent script, and point the Include Controller to the path of the child JMX file. Figure 9 shows an Include Controller defined in the parent script:

Figure 9. Adding an Include Controller to the parent JMX file

In the Include Controller control panel shown in Figure 9 , The Filename field stores the relative path of the child JMX file (Login_User.jmx in this example).

The child JMX file can access any variables defined in the parent JMX file accessible in the Include Controller, and the parent JMX file can use the variables defined in the child JMX file.

Use regular expressions

When JSON is the request payload of a REST operation, the response is either in JSON format or in characters String representation. After completing the operation, the response string, error code, and error message string must be extracted to verify that the feature works as expected. You can use JMeter’s regular expression feature to extract response data from variables.

Figure 10 shows how to create a simple regular expression extractor in JMeter’s Regular Expression Extractor control panel:

Figure 10. Simple regular expression Extractor

In Figure 10, Reference Name (User in this case) stores the value extracted using regular expression syntax. In the Regular Expression field, you provide the syntax for the regular expression to run against the response (in Figure 11, the syntax is \”LoginName\”:\”(.*?)\”) to extract specific data. Examples of common regular expression syntax for JSON response data include:

• \s*(.+)\s* used to extract the entire response string
• \”LoginName\ “:\”(.*?)\” Used to extract “LoginName”:”[email protected]”
• \”CustomerId\”:(\d+) Used to extract “CustomerId”:2000006< /li>

In the Template field of Figure 10, $1$ represents the grouping of reference variables. The Default Value field is used to provide a default value for debugging if the regular expression does not match. According to practice, only declare default values ​​when adding and testing regular expression patterns during the scripting phase.

Extend the JMeter script to perform performance testing

Ideally, performance testing of any application includes two scenarios: The spike in the number of users and the increase in system load. If the existing functional test scenario covers basic REST functions, it is easy to extend and update it to test the performance of REST services hosted on the cloud infrastructure. You can modify the number of requests that should be sent to each server to load test the application. You can control the number of requests by configuring the rise period using the appropriate loop iteration.

For example, suppose you have a test plan to execute and verify a simple set of REST principles based on the following algorithm:

1. Execute an HTTP POST method to create a customer object .
2. Execute an HTTP GET method to verify the creation of the client object.
3. Execute an HTTP PUT method to verify the modification of the client object.
4. Execute an HTTP DELETE method to verify that the client object has been deleted.

You can adjust a simple functional test plan (originally designed for RESTful API functional test scenarios) into a performance test script targeting servers deployed in a cloud environment.

1. Navigate to the Thread Group control panel of the test plan, as shown in Figure 11:

   Figure 11. Figure 11. Example of performance simulation settings

   

2. Enter ${Thread} in the Number of Threads (users) field. The value of the Thread variable (which will be configured in step 5) sets the number of available threads to reflect how many virtual users are accessing the server.
3. Enter ${RampUp} in the Ramp-Up Period (in seconds) field. The value of the RampUp variable (which will be configured in step 5) determines the speed of distributing requests (this is based on the number of threads defined in step 1). For example, if there are 10 threads and the acceleration rise time is 100 seconds, then each thread starts 10 seconds after the previous thread starts, and there is a total time of 100 seconds to speed up the test.
4. Enter ${Loop} in the Loop Count field. The value of the Loop variable (which will be configured in step 5) determines the number of times the test plan is executed.
5. Navigate to the User Defined Variables control panel and define Thread, RampUp, and Loop as global variables, as shown in Figure 12. Assign appropriate variable values ​​to each load to be simulated.

   Figure 12. Performance test simulation variables

   

   In Figure 12, the Loop value is set to 5, the RampUp value is set to 50, and the Loop value is set to 2.

Figure 13 shows the result of executing JMeter on one of the node servers deployed in the cloud application based on the variable values ​​configured in Figure 12:

Figure 13. Performance test results

Figure 13 shows the heaviness of concurrent requests sent to the server Load to simulate performance test conditions.

Extend the JMeter script to perform reliability testing

Reliability testing is performed by continuously running a Group scripts are a way to ensure the stability of the overall system. The results of the reliability test should be viewed together with the results of the stress test, functional test, and network feature test.

Like performance testing, you can convert a test plan that executes and validates a set of simple REST principles into a set of appropriate reliability test scripts to determine the performance of any product or feature running on the cloud instance stability.

An important aspect of reliability testing is to determine whether a failure occurs during the course of running a script for multiple days. Check the Forever checkbox of the Thread Group control panel, as shown in Figure 14, so that the thread can run until the test fails or the script is forcibly stopped:

Figure 14. JMeter script可靠性设置

在配置了可靠性测试设置后，运行测试几天，通过JMeter 结果图或通过JMeter 提供的推断选项连续监测结果。

结束语

本文向您介绍了使用 JMeter 来有效地测试基于云的应用程序的方法。文章并没有进行详尽的讨论，我们鼓励您尝试使用其他技术来改进 JMeter 中的自动化任务实现。 JMeter Wiki是继续您的探索的一个好地方。

本文转自:  清明-心若淡定  https://www.cnblogs.com/saryli/p/5944875.html