WEBTESTING
Web tests help us to test the web application in a manner which imitates the user environment. We can thus record a set of http requests that the user browses through, along with the think times. Think time is the time taken by the user to navigate from one web page to the other. Thus, including the think time helps us capture a more realistic situation in which the application will be used.
Web tests can be used to record and test different parts of your application code. Different web tests can be created for this purpose. These web tests can then be included in a Load test and the application can thus be tested for load.
Different versions of various web tests are tested for
-- Specific conditions: to ensure the application responds appropriately. This test includes the alternate, exception and direct path functionality testing.
-- To perform a task or a series of tasks correctly every time. This tests direct path functionality testing.
Recorded web tests: A set of http requests can be recorded and tested. Once you have recorded a test, you have various options for configuring, altering, or making comments on specific tests or requests.
Data Driven web tests: Data binding allows a database to provide parameters to the test at various steps instead of having to change multiple tests of the same type by hand. Data binding can be used for individual data-driven web tests or for load testing. For data-driven web tests the test will cycle through a table in the database and run the test once for each row in the table. Each column can supply a value to various parts of the web test.
CREATING A SIMPLE WEBTEST
In this sample web test, a set of HTTP requests is recorded. We then bind a data source to a form parameter.
After the test is run, we change the edit web test setting to run the test for each row in the database.
Step 1: Record a simple web test and run. The following shows the recorded web test.
Figure 1:
This sample test makes a simple search for the job, when the user inputs a job ID. The above snap snot shows the input parameter jobId - 3.The result is thus a search made and the details of the job.
This is a simple web test which checks for the validity of the jobId in the database, and hence the search functionality.
Figure 2:
Step 2: Run the web test. Above figure shows the results of the web test. Check the “edit run settings” as shown in the figure above. And ensure that by default, fixed run count is set to one. For data source binding we will change the run settings to run the web test for every row of the database.
Step 3: Using the data source to bind the input value from the database. Click the add source button and connect to the server as shown. Test the connection and say ok. We now get a list of tables from the Database to which we have connected. Select the tables which you would wish to include in your database.
Figure 3:
Step 4: To bind the Database field to the form parameter. Click the form field which we wish to bind to database. Go to its properties->bind it to the field from the database in the “value” attribute of the properties. Refer the figure below.
Figure 4:
Access methods for Data Source binding:
Sequential: For a load test, this method reads through every row in the table from top to bottom and continues to loop for the duration of the load test.
Random: For a load test, this method reads through every row in the table in a random order and continues to loop for the duration of the load test.
Unique: For a load test, this method reads through every row in the table from top to bottom and runs the test once for each row.
Edit the run Settings from the test output window, and configure the web test to be run for every row from Database.
Notice that the Form post parameter has “{{TalentMart1.viewJobDetailsAll.Job Id}}” for the Form Parameter which takes job Id. Run the web test. This test will pass, picking a job ID from Database in a sequential /Random/Unique manner, as selected for the data source.
Figure 5:
Step 5: Extracting values. In this sample, extracting the value of the form field is shown.
Extraction rules are used to extract parts of either the header or the body of a request .For example we might want to exact a parameter from one web page and validate it in the next webpage as will be sown in our example. There are several prebuilt extraction rules the situations you will run in to. These extraction rules are described as below.
Built in Extraction Rules:
Extract Attribute Value: Extracts the value of a given HTML attribute.
Extract Form Field: Extracts the value of a given form field.
Extract HTTP Header: Extracts the value of a given header.
Extract Regular Expression: Extracts any text that matches the given regular expression.
Extract Text: Extracts any text based on a beginning and ending set of criteria. Regular expressions can be used for this extraction rule also.
Extract Hidden Fields: Extracts all hidden fields from a response.
As in our example, we will extract the job Id picked up from the database, and validate the value.
So, we add the Extract form Field as an extraction rule to the next web request which generated the job ID. See snapshot below.
Form field name is given same as that generated by the previous request. “Ctl00$ContentPlaceHolder1$txtJobId” The context parameter is the name given to the extracted value. Here, I have given “jobId”.
Figure 6:
When the test is run, after extraction rule applied, the web test will pass the extraction of job Id value (as shown) . Thus, we have successfully extracted the value input in the web page.
Figure 7:
Step 6: Validation Rule. In this sample we are validating the extracted value job Id to be existing in the database.
Validation rules are used to validate the extracted values. There are several prebuilt validation rules the situations you will run in to. We can also set the level of validation to be done. These validation rules are described as below.
Built in validation Rules:
Form Field: Verifies that a field exists on the form and what the value in that field is to be.
Find Text: Verifies that certain text appears somewhere in the response page.
Maximum Request Time: Verifies that a request finishes in a given amount of time
Required Attribute Value: Verifies that a specified HTML tag exists in the response and contains an attribute with a given value
Required Tag: Verifies that a specified HTML tag exists in the response
As in our example, we will validate the extracted job Id to be existing in the Database.
So, we add the Form Field as a validation rule to the next web request which generated the job ID. See snapshot below.
Figure 8:
The validation Rule is configured with the following.
Setting the validation level on a rule to ‘‘low’’ means that it will always be run. In this case, low means that it is a low-level, or fundamental, verification; low does not refer to the priority of the verification. Setting the level to ‘‘high’’ means that it will only be run if the load test has been set to a validation level of ‘‘high.’’
Setting the load test level to Will run only the rules with a setting of
Low Low
Medium Low, Medium
High Low, Medium, High
The Expected value should be present in the database column of job Id. Thus we bind it to the database (as shown) .
The form parameter is the parameter which needs to be validated. In our case it is the jobId context parameter.
Figure 9:
When the test is run, after validation rule applied, the web test will pass the extraction of job Id value, and also the validation of the extracted value (As shown) . Thus, we have successfully extracted and validated the value input in the web page.
