Functional Testing Approach

• Identify Features
• Implement Test Design
• Plan and Design Test
• Configure Test Environment
• Execute Test Cases
• Analyze Report and Retest

Identified Features:

Identify all the features to be tested using Jmeter. Here, we will create a Test Plan(with any website) in order to demonstrate how we can configure the Test Plan to include functional testing capabilities. The modified Test Plan will include these scenarios:

1. Navigate to Home page

2. Navigate to About Us page

3. Navigate to Careers page

4. Navigate to Resource Center page

5. Navigate to Contact page 

and etc.....

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.

Implement Test Design:

Identify the pattern to be verified in the response from server and design test cases  accordingly. Here, using HTTP Proxy Server to Record Page Requests:

We will need to include the HTTP Proxy Server element in the WorkBench. Some configuration will be required, as shown in the following snapshot:

Configuring the Proxy Server:

Simulating these scenarios will require JMeter to make requests for accessing the home pages, About us page, Competency page, etc.

Selecting Add Assertion will be especially useful as we add specific patterns of the page that we want to evaluate as a later part of this exercise. The Capture HTTP Headers option is selected to capture the Header information as we begin recording. However, to make the recording neater, we will keep this option unchecked.

In addition, since we do not require images in our testing, in the URL Pattern to Exclude section, add these patterns: .*.jpg, .*.js, .*.png, .*.gif', .*.ico, .*.css, otherwise these image files, which are not necessary for our testing, will be recorded causing unnecessary clutter in our recording.

Add thread groups as child of Test Plan as displaying in fig below.

Now change the name of each thread group as according to requirements as like showing in figure given below.

Let the Recording Begin...

Let us proceed with the recording following the test cases in the previous table as our guide. As you record each page, select the specific tags or page elements the correctness of which you want to validate and add them to the Patterns to Test section in the Response Assertion element of each sampler. This may take most of your recording time, since as you record, you need to decide carefully which page element(s) would be the most effective measure of correctness. There are plenty of developer tools available to help you in this possibly tedious task.

The Assertion Results listener is used with the Response Assertion elements, to summarize the success or failure of a page in meeting the validation criteria defined in each Response Assertion.

Execute Test Cases:

Once the assertions are properly completed, we are expecting that running our Test Plan would pass all the assertions. Passed assertions will not show any error in Assertion Results | Listener installed within the same scope. As for all Listeners, results as captured by the Listeners can be saved and reproduced at a later time. Following is a sample explaining what passed Assertions would reveal as the Test is executed.

On the other hand, a failed Assertion would show an error message in the same Listener as the following snapshot illustrates.

                                      

Since a page error or Page not found error is a real risk in web applications, a failure may originate from such an error, and not just because of a failed Assertion. We can view more information about the sampler that contains the failed Assertion to investigate the origins of a failure. A View Results Tree Listener records the details of requests and logs all errors (indicated by the red warning sign and red fonts).

Summary:By execution find out the results and report all the defects if any. After resolving those defects retest new build with the same scripts.

This will provide visual means for us to understand the capabilities of JMeter tools that support functional testing, as we directly wrote and implemented a JMeter script. We have demonstrated building a Test Plan to contain functional validations (or assertions) by incorporating various essential JMeter components, particularly the 'Response Assertion' element and 'Assertion Result' Listener. By using the 'User Defined Variable' Configuration element, we have also parametrized several values in order to give our Test Plan better flexibility. In addition, we have observed the result of these assertions as we performed a 'live' run of the application under test. An HTTP Request sampler may require to be modified, if there are any changes to the parameter(s) that the sampler sends with each request.

If you have any type of concern contact me or reply....