| home / authoring / jmeter |
[next] |
|
|
|
Emily H. Halili
JMeter is found to be very useful and convenient in support of functional testing. Although JMeter is known more as a performance testing tool, functional testing elements can be integrated within the Test Plan, which was originally designed to support load testing. Many other load-testing tools provide little or none of this feature, restricting themselves to performance-testing purposes. Besides integrating functional-testing elements along with load-testing elements in the Test Plan, you can also create a Test Plan that runs these exclusively. In other words, aside from creating a Load Test Plan, JMeter also allows you to create a Functional Test Plan. This flexibility is certainly resource-efficient for the testing project.
This chapter will give a walkthrough on how to create a Test Plan as we incorporate and/or configure JMeter elements to support functional testing. This chapter assumes that you have successfully gone through Chapter 5, and created a Test Plan for a specific target web server. We will begin the chapter with a quick overview to prepare you with a few expectations about JMeter. Later, we will create a new Test Plan similar to the Test Plan in Chapter 5, only smaller. The Test Plan we will create and run at the end of this chapter will incorporate elements that support functional testing, exclusively.
In this regard, I need to highlight that JMeter does not have a built-in browser, unlike many functional-test tools. It tests on the protocol layer, not the client layer (i.e. JavaScripts, applets, etc.) and it does not render the page for viewing. Although, by default that embedded resources can be downloaded, rendering these in the Listener | View Results Tree may not yield a 100% browser-like rendering. In fact, it may not be able to render large HTML files at all. This makes it difficult to test the GUI of an application under testing.
However, to compensate for these shortcomings, JMeter allows the tester to create assertions based on the tags and text of the page as the HTML file is received by the client. With some knowledge of HTML tags, you can test and verify any elements as you would expect them in the browser.
Unlike for a load-testing Test Plan, it is unnecessary to select a specific workload time to perform a functional test. In fact, the application you want to test may even reside locally, with your own machine acting as the "localhost" server for your web application. For this chapter, we will limit ourselves to selected functional aspects of the page that we seek to verify or assert.
We will create a Test Plan in order to demonstrate how we can configure the Test Plan to include functional testing capabilities. The modified Test Plan will include these scenarios:
|
Following these scenarios, we will simulate various entries and form submission as a request to a page is made, while checking the correct page response to these user entries. We will add assertions to the samples following these scenarios to verify the 'correctness' of a requested page. In this manner, we can see if the pages responded correctly to invalid data. For example, we would like to check that the page responded with the correct warning message when a user enters an invalid password, or whether a request returns the correct page.
First of all, we will create a series of test cases following the various user actions in each scenario. The test cases may be designed as follows:
With the exception of the Configuration elements, Listeners, and Assertions, which we will add later, our Test Plan will take the form that you see in the following screenshot (See Figure 1).
As in recording requests in Chapter 5, you will need to include the HTTP Proxy Server element in the WorkBench. Some configuration will be required, as shown in the following snapshot (See Figure 2).
| home / authoring / jmeter |
[next] |
| ||||||||||||||||||||
URL:
Digg This
Add to del.icio.us
