SOFTWARE TESTING AND QUALITY

ASSURANCE LAB
ETCS - 453

Submitted To: Submitted By:

Dr. Naresh Kumar Name: Aditya Gupta
Serial No: 37
Enrollment No: 35115002717
Class: CSE-II (B)

Maharaja Surajmal Institute of Technology,

C-4 Janakpuri, New Delhi-110058
 Experiment 1

AIM: Test the program of Quadratic Equation using Boundary Value Analysis

Theory:

A quadratic Equation ax2+bx+c=0 with input as three positive integers a,b,c having values ranging from
interval [1,100].
Boundary Value Analysis:

It is a software testing technique in which tests are designed to include representatives of boundary
values in a range.
It is used to identify errors at boundaries rather than finding those exist in center of input domain

We consider the values as 1(Minimum), 2 just above Minimum), 50 Nominal, 99(just above Maximum),
100(Maximum).

TEST CASE ID a b c EXPECTED

OUTPUT
1 50 50 1 Real Roots
2 50 50 2 Real Roots
3 50 50 50 Imaginary Roots
4 50 50 99 Imaginary Roots
5 50 50 100 Imaginary Roots
6 50 1 50 Imaginary Roots
7 50 2 50 Imaginary Roots
8 50 99 50 Imaginary Roots
9 50 100 50 Equal Roots
10 1 50 50 Not a quadratic
equation
11 2 50 50 Real Roots
12 99 50 50 Imaginary Roots
13 100 50 50 Imaginary Roots
Source Code:

#include <bits/stdc++.h>
#define MIN 0
#define MAX 100 using
namespace std;
void test(int a, int b, int c, int testcaseid) {
string output;
if(a == 0) {
output = "Not a Quadratic Equation\n";
} else {
int d = b*b - 4*a*c;
if(d < 0) {
output = "Imaginary Roots\n";
} else if(d == 0) {
output = "Real and Equal Roots\n";
} else {
output = "Real and Distinct Roots\n";
}
}
cout<<" "<<testcaseid<<"\t\t"<<a<<"\t"<<b<<"\t"<<c<<"\t"<<output;
}

int main() {
int min, max,testcaseid= 0;

cout<<"Enter range\n";
cin>>min>>max;
if(min < MIN || max > MAX) {
printf("Invalid range\n");
return 0;
}

int nominal = (min + max)/2;

int values[] = {min, min+1, nominal, max-1, max};

cout<<"TestCase\ta\tb\tc\tOutput\n";

// fix variable b,c to nominal value and change values of a for(int

i=0;i<5;i++) {
testcaseid++;
test(values[i],nominal, nominal,testcaseid);
}

//fix variable a,c to nominal value and change values of b for(int

i=0;i<5;i++) {
// skip the case where all three values of a,b,c are same
// since it was already included once in above loop if(values[i]
!= nominal){
testcaseid++;
test(nominal, values[i], nominal,testcaseid);
}

}
 // fix variable a,b to nominal values and change values of c
for(int i=0;i<5;i++) {
if(values[i] != nominal)
{
testcaseid++;
test(nominal, nominal, values[i],testcaseid);
}

return 0;
}

Output:
 Experiment 2

Aim:

To determine the type of triangle.Input is a triple +ve integers, Values may be between x,y,z Program

output may be scalene, isosceles,equilateral not a triangle. Perform BVA

Theory :

It accepts three integers a,b,c. These are taken as sides of triangle Outputs of triangle may be equilateral

,scalene ,isosceles. We will generate 6n + 1 cases.

Testcase id Side a Side b Side c Output

1 50 50 1 Isosceles
2 50 50 2 Isosceles
3 50 50 50 Equilateral
4 50 50 99 Isosceles
5 50 50 100 Not a triangle
6 50 1 50 Isosceles
7 50 2 50 Isosceles
8 50 99 50 Isosceles
9 50 100 50 Not a triangle
10 1 50 50 Isosceles
11 2 50 50 Isosceles
12 99 50 50 Isosceles
13 100 50 50 Isosceles
 Source Code –
#include<iostream.h>

#include<conio.h>

void main()

int a,b,c;

clrscr();

cout<<"Enter The Value Of a,b,c \n";//side's of triangle

cin>>a>>b>>c;

if(a==b && b==c && c==a)

cout<<"The Triangle is Equilateral\n";

else if(a==b || b==c || c==a)

cout<<"The Triangle is Isosceles\n";

else

cout<<"The Triangle is Scalene\n";

}
getch();

}
Output:
 Experiment 3

Aim :

Perform Robust case testing on Quadratic Equation.

Theory :

Robustness testing is any quality assurance methodology focused on testing the robustness of
software. It has also been used to describe the process of verifying the correctness of test cases in
a test process.

It is a extention of boundary value analysis. Here , we went to go outside the legitimate boundary
of input domain.

There are four additional test cases which are outside the legitimate input domain.

Hence, total test cases are 6n+1.

Test Case Id Side a Side b Side c Roots

1 -1 50 50 Invalid input
2 0 50 50 Not quadratic eqn
3 1 50 50 Real Roots
4 50 50 50 Imaginary Roots
5 99 50 50 Imaginary Roots
6 100 50 50 Imaginary Roots
7 101 50 50 Invalid input
8 50 -1 50 Invalid input
9 50 0 50 Imaginary Roots
10 50 1 50 Imaginary Roots
11 50 99 50 Imaginary Roots
12 50 100 50 Equal Roots
13 50 101 50 Invalid input
14 50 50 -1 Invalid input
15 50 50 0 Real Roots
16 50 50 1 Real Roots
17 50 50 99 Imaginary Roots
18 50 50 100 Imaginary Roots
19 50 50 101 Invalid input
Source Code –

#include <iostream.h>

#include <math.h>

#include <conio.h>

void main() {

float a, b, c, x1, x2, discriminant, realPart, imaginaryPart;

clrscr();

cout << "Enter coefficients a, b and c: ";

cin >> a >> b >> c;

discriminant = b*b - 4*a*c;

if (discriminant > 0) {

x1 = (-b + sqrt(discriminant)) / (2*a);

x2 = (-b - sqrt(discriminant)) / (2*a);

cout << "Roots are real and different." << endl;

cout << "x1 = " << x1 << endl;

cout << "x2 = " << x2 << endl;

else if (discriminant == 0) {

cout << "Roots are real and same." << endl;

x1 = (-b + sqrt(discriminant)) / (2*a);

cout << "x1 = x2 =" << x1 << endl;

}
 else {

realPart = -b/(2*a);

imaginaryPart =sqrt(-discriminant)/(2*a);

cout << "Roots are complex and different." << endl;

cout << "x1 = " << realPart << "+" << imaginaryPart << "i" << endl;

cout << "x2 = " << realPart << "-" << imaginaryPart << "i" << endl;

getch();

}
 Experiment 4

AIM: Perform Robust case Testing on Triangle problem.

Test Case ID Side a Side b Side c Output

1 50 50 0 Invalid input
2 50 50 1 Isosceles
3 50 50 2 Isosceles
4 50 50 50 Equilateral
5 50 50 99 Isosceles
6 50 50 100 Not a triangle
7 50 50 101 Invalid input
8 50 0 50 Invalid input
9 50 1 50 Isosceles
10 50 2 50 Isosceles
11 50 99 50 Isosceles
12 50 100 50 Not a triangle
13 50 101 50 Invalid input
14 0 50 50 Invalid input
15 1 50 50 Isosceles
16 2 50 50 Isosceles
17 99 50 50 Isosceles
18 100 50 50 Not a triangle
19 101 50 50 Invalid input
SOURCE CODE:

#include<conio.h>

#include<iostream.h>

void main()

clrscr();

int a,b,c;

cout<<"enter the value of a:\n";

cin>>a;

cout<<"enter the value of b:\n";

cin>>b;

cout<<"enter the value of c:\n";

cin>>c;

if(a<1||b<1||c<1||a>100||b>100||c>100)

cout<<"not a triangle!\n";

else

if((a==b)&&(b==c)&&(c==a))

cout<<"the triangle is equilateral\n";

if((a==b)&&(b!=c))

cout<<"the triangle is isosceles\n";

if((a!=b)&&(b!=c)&&(c!=a))
cout<<"the triangle is scalene\n";

getch();

OUTPUT:
 Experiment 5

Aim: Write a program for a triangle problem using weak Robust Equivalence class Testing.

Theory

 Identify equivalence classes of valid and invalid values.

 Test cases have all valid values except one valid value.
 Defects faults due to calculations with valid values of a single variable.
 Defects faults due to invalid values of a single variable.
 It is ok for Regression Testing.

Considering the invalid values for a, b and c yields the following:

Test Case ID side ‘a’ side ‘b’ side ‘c’ Expected Output
WR1 1 50 50 Invalid value of a
WR2 50 -1 50 Invalid value of b
WR3 50 50 -1 Invalid value of c
WR4 201 50 50 Out of Range
value of a
WR5 50 201 50 Out of Range
value of b
WR6 50 50 201 Out of Range
value of c
WR7 5 100 5 Isosceles
WR8 100 5 200 Scalene
WR9 50 50 5 Equilateral
Source Code

#include<iostream.h>

#include<conio.h>

void main(){

clrscr();

int a, b, c;

cout<<"Enter the value of a:"<<endl;

cin>>a;

cout<<"Enter the value of b:"<<endl;

cin>>b;

cout<<"Enter the value of c:"<<endl;

cin>>c;

if(a<1||b<1||c<1||a>100||b>100||c>100){

cout<<"Not a triangle"<<endl;

}else{

if((a==b)&&(b==c)&&(a==c))

cout<<"The triangle is equilateral"<<endl;

if(((a==b)&&(b!=c)) || ((a==c)&&(b!=c)) || ((c==b)&&(a!=c)))

cout<<"The triangle is isoceles"<<endl;

if((a!=b)&&(b!=c)&&(c!=a))

cout<<"The triangle is scalene"<<endl;

getch();

}
Output:
 Experiment 6

AIM : Test the program of previous date using Strong Robust Equivalence Class Testing
THEORY: ‘Previous Date’ is a function consisting of three variables like : month(mm), date(dd),
year(yyyy). It returns the date of next day as output. It reads current date as input date.

The conditions are

C1 : 1<=month<=12

C2 : 1<=day<=31

C3 : 1900<=year<=2020

Thus based on valid values, the equivalence classes are :-

M1 = {month : 1<=month<=12}

D1 = {day : 1<=day<=31}

Y1 = {year : 1900<=year<=2020}

And the invalid equivalence classes are :

M2 = {month : month<1}

M3 = {month : month>12}

D2 = {day : day<1}

D3 = {day : day>31}

Y2 = {year : year<1900}

Y3 = {year : year>2020}

Test Case ID Month Day Year Expected Output

SR1 -1 15 1912 Invalid value of month
SR2 6 -1 1912 Invalid value of day
SR3 6 15 1809 Invalid value of year
SR4 -1 -1 1900 Invalid value of month
Invalid value of day
SR5 6 -1 1811 Invalid value of day
Invalid Value of year
SR6 -1 15 1811 Invalid value of month
Invalid value of year
SR7 -1 -1 1811 Invalid value of month
Invalid value of day
Invalid value of year
SR8 2 4 2016 Valid values of month, day & year
Source Code

#include<stdio.h>

#include<Conio.h>

void main()

int d,d1,m,m1,y,y1,flag=0;

clrscr();

printf("\nProgram to find previous date :\n(Date should be entered in the format 'dd mm
yyyy')\n(yyyy should be between 1900-2020)\nEnter the date:");

scanf("%d %d %d", &d,&m,&y);

d1=d;

m1=m;

y1=y;

if(d<1||d>31)

printf("Invalid date class value");

if(m<1||m>12)

printf("\nInvalid month class value");

if(y<1900||y>2020)

printf("\nInvalid year class value");

if((d>=1 && d<=31) && (m>=1 && m<=12) && (y>=1900 && y<=2020))

flag=1;

if(m==5||m==7||m==10||m==12)

if(d==1)

d1=30;
m1=m-1;

else

d1=d-1;

printf("\nValid values of month, day & year");

else

if(m==1||m==2||m==4||m==6||m==8||m==9||m==11)

if(m==2)

if(d==29)

{
if((y%4==0 && y%100!=0)||y%400==0)

flag=1;

else

printf("Invalid value of day");

flag=0;

}}

if(d==30||d==31)

printf("\nInvalid value of day");

flag=0;

}}
if(m==4||m==6||m==9||m==11)
{

if(d==31)

printf("\nInvalid value of day");

flag=0;

}}

if(d==1)

d1=31;

if(m==1)

m1=12;

y1=y-1;

else

m1=m-1;

}}

else

d1=d-1;}

if(flag==1)

printf("Valid values of month,day & year");

else
if(m==3)

if(d==1)

if((y%4==0 && y%100!=0)||y%400==0)

d1=29;

m1=m-1;

else

d1=28;

m1=m-1;

else

d1=d-1;

printf("\nValid values of month, day and year");

}}

if(flag==1)

printf("\nThe entered date is :%d%d%d",d,m,y);

printf("\nThe previous date is : %d%d%d",d1,m1,y1);

getch();

}
OUTPUT:
 Experiment 7
AIM
Test the program of triangle using Decision Table Testing.

THEORY
A Decision Table Testing is a good way to deal with different combination of inputs which produce
different results. It is also called Cause-Effect Table. It provides a systematic way of stating complex
business rules, which is useful for developers as well as for testers. Decision tables can be used in test
design as they help testers to explore the effects of combinations of different inputs.
A decision table is basically an outstanding technique used in both testing and requirements
management. It is a structured exercise to prepare requirements when dealing with complex business
rules.

ADVANTAGES
1. Any complex business flow can be easily converted into the test scenarios
& test cases using this technique.
2. It provide complete coverage of test cases which help to reduce the rework on writing
test scenarios & test cases.
3. These tables guarantee that we consider every possible combination of condition
values. This is known as its “completeness property”.
4. Simple to understand and everyone can use this method to design the test scenarios
and test cases.

C1: x < y+z? O T T T T T T T T T T

C2: y < y+z? F T T T T T T T T T
C3: z < x+y? F T T T T T T T T
C4: x = y? T T T T F F F F
C5: y = z? T T F F T T F F
C6: x = z? T F T F T F T F
O1: Not a T T T
triangle
O2: Scalene T
O3: Isosceles T T T
O4: T
Equilateral
O5: T T T
Impossible
Test Cases:
Inputs:
C1: Side x is less than sum of sides of y & z. C2:
Side y is less than sum of sides of x & z. C3: Side z
is less than sum of sides of x & y. C4: x < y
C5: x < z
C6: y < z
Outputs:
O1: Not a triangle O2:
Scalene triangle O3:
Isosceles triangle
O4: Equilateral triangle
O5: Impossible stage

Test Case Side ‘a’ Side ‘b’ Side ‘c’ Output

1 50 50 0 Invalid Input
2 50 50 1 Isosceles
3 50 50 50 Equilateral
4 50 100 1 Scalene
5 50 99 50 Isosceles
6 50 50 50 Isosceles
7 50 100 50 Not a triangle
Source Code:
#include<conio.h>
#inclde<iostream.h>
void main(){ clrscr();
int a,b,c;
cout<<”enter the value of a:\n”;
cin>>a;
cout<<”enter the value of b:\n”;
cin>>b;
cout<<”enter the value of c:\n”; cin>>c;
if(a<1||b<1||c<1||a>100||b>100||c>100){
cout<<”not a triangle\n”;
}
else{ if((a==b)&&(b==c)&&(c==a))
cout<<”the triangle is equilateral\n”;

if((a==b)&&(b!=c))
cout<<”the triangle is isosceles\n”;
if((a!=b)&&(b!=c)&&(c!=a))
cout<<”the triangle is scalene\n”;
}
getch();
}
Output:
 Experiment 8

AIM : Test the program of greatest among two numbers with DD path testing.

Theory

A DD path or decision to decision path is a path of execution between two decisions.

Properties

 Every node on aflow graph of aprogram belongs to one DD path

 It is used to find independent path for testing.
 Every statement has been extended atleast once.

Note:-For designing a DD path a flow graph is made first and then combning all sequential steps
into one step.

The program of finding the largest number among the two numbers consist of 11 lines.
STEP 1: GENERATING FLOW GRAPH

1-> 2->3->4->5->6->7->8
|
12<-11<-10<-9->13->14->15
|
17
|
18
|
19

1-8 SEQUENTIAL STEPS

9 DECISION STEP

STEP 2: GENERATING DD PATH

A
|
B
/ \
C D
\ /
E
|
F
No of Edges :- 6

No of Edges:- 6
SOURCE CODE-

#include<stdio.h.

#include<conio.h>

Void main()

Clrscr();

int a ,b ,big ;

printf(“Enter two number : ”);

scanf(“%d%d”,&a,&b);

if(a>b)

big =a;

else

big=b;

Printf(“”Biggest of two number is %d”,big);

getch();

}
Next step is to find out independent path using cyclometric complexity :

There are many methods:-

1. e – n + 2p

=6–6+2

=2

2. No of Regions = 2

So no of independent paths are 2

1. ABCEF
2. ABDEF

Test Cases:

ID a b Output

1. 4 3 A is greater

2. 3 4 B is greater

OUTPUT :

Enter two number :

43
Biggest of two number is 4
 Experiment 9

Aim:
Create test plan document for any program

Theory:
Test plan reflects our entire project testing schedule and approach. Here, we are going to
create a test plan for Triangle problem tested though boundary value analysis.

1. Introduction
A program has been written for a Triangle problem to check whether the triangle
formed is scalene, isosceles or equilateral. To test this program, we are using
boundary value analysis.

2. Objectives
This test plan will define the strategy that is being used to the test the program
reliability, efficiency etc.

3. Scope
A Triangle problem is being tested to determine whether the triangle formed is
scalene, equilateral or isosceles. Different test cases will be generated that
corresponds to both valid and invalid inputs and outputs.

4. Testing Strategy
Boundary value analysis approach has been used to test the program BVA is a black
box testing in which we are not considering the internal structure. This type of
strategy does not require much knowledge as only boundary values are considered.
This type of strategy will generate 4n+1 test cases.

5. Hardware Requirements
Computers and modems

6. Feature to be tested
As BVA has been used, so there will be total 4n+1 test cases consisting of both valid
and invalid cases. Mainly there will be three features that will be focused -
Whether the triangle is isosceles, scalene or equilateral

7. Features not to be tested

It is not necessary to test all possible combinations. Only main features will be tested.

8. Pre – conditions
Let us say, the 3 sides of a triangle are x,y,z
Then, x<y+z
y<x+z
z< x+y
9. Roles/Responsibilities
Different roles and responsibilities are performed by different persons. First
verification is done by developers and validation is done by customers.

10. Risks
If the number of variable increase then no. of test cases will definitely increase. Then
it will become impossible to test all possible combinations.
 Experiment 10
Aim: Study of any testing tool (Rational Robot).

Theory: Rational Robot is a complete set of components for automating the testing of
Microsoft Windows client/server and Internet applications.

Rational Robot is an automated functional regression testing tool.

Components of Rational Robot

1. Rational Administrator: Create and manage rational projects to store your testing
information.
2. Rational Test Manager: Review and analyze test results.
3. Object properties, text, grid and image comparators: View and analyze the
results of verification point playback.
4. Rational site check: Manage Internet and intranet web sites.

How Does Rational Robot Works?

Rational Robot lets all members of your development and testing teams implement a
complete and effective testing methodology. Robot replaces the repetitive, often error-prone
process of manual testing with the software tools to automate your testing effort.

With Robot’s automated functional testing, you save time and ensure that your testing process
produces predictable and accurate results. With Robot, you can start recording tests in as few as
two mouse clicks. After recording, Robot plays back the tests in a fraction of the time it would
take to repeat the steps manually.

Robot’s object-Oriented Recording technology lets you generate scripts quickly & simply by
running and using the application-under-test. Object-Oriented Recording identifies objects by
their internal object names, not by screen coordinates.

Analyzing The Results In The Log Viewer And Comparators

The Rational Log Viewer lets you view logs that are created when you play back scripts in
Robot. Reviewing the playback results in the Log Viewer reveals whether each script and its
components passed or failed.

To analyze each failure and then remedy it, you can use one of the Log Viewer’s four
Comparators Grid, Object Properties, Text, and Image. Each Comparator graphically displays
the ‘before and after’ results
of playback. If there is no failure on playback, only a baseline file displaying the recorded data
or image is displayed. If a failure occurs on playback, an actual file is displayed next to the
baseline file.

Tracking Applications With Rational Testfactory

 Automatically create and maintain a detailed map of the application-under-test.

 Automatically generate scripts that provide extensive product coverage and
scripts that encounter defects, without recording.
 Track executed and unexecuted source code, and report detailed findings.
 Shorten the product testing cycle by minimizing the time invested in writing navigation code.
 Automate distributed functional testing with Test Accelerator—an application that
drives and manages the execution of scripts on remote machines.
 Experiment 11

Aim: Study of QA complete tool.

Theory: QA complete tool is a test management tool that allows you to take a strategic approach to
testing by prioritizing key test functions, accounting for risk, planning for coverage and controlling
test execution.
Key features:

Text Case Management

The ability to organize, plan and analyze the testing efforts across the lifecycle is critical to success.
QA complete delivers better test case management by employing reusable test libraries to quickly
create new test scenarios.

Test automation tool integration

QA complete support many automated testing tools integration with these tools allows to review the
history of any automated test on any machine history of any automated test on any machine.

Bidirectional traceability

It ensures ‘adequate’ test coverage for each software requirement, this means that design
specifications are approximating verified .

Requirement management

QA complete heeds to manage requirements. It lets us define requirements for each release and trace
the release for which each requirement is scheduled.

Test automation

 QA complete supports many automated tools to-\review and compare automated test sum
histories across machines
 Coordinated manual and automated testing effort
 To make better informed release decisions
 Launch test directly form automated tool
 Share results across the ram using dashboard

Defect management

QA complete allows you to track states and resolutions process of defects and issues for each release
instead of spending time entering data, QA complete automatically generates a defect identifiers on
fatted test cases, so testers can invert their time in running test.
Reports Standard

Reports
Organized by modules they can be exported to several different formats. Many of these crystals
based reports are right.

Summary report

Great for identification of distribution data.

 EXPERIMENT NO- 12

AIM: Study of open source testing tool open STA

THEORY:

OpenSTA supplies versatile Test development software that enables you to create and run Tests
tailor-made for the environment you are assessing. The contents and structure of a Test will
depend on the type of test you are conducting, the nature of the system you are targeting and the
aims of your performance test.

OpenSTA supports the creation of HTTP/S load Tests that include Scripts which supply the load
element, and may also include Collectors which are used to record additional performance data.
You can also use OpenSTA to develop Collector-only used Tests for monitoring production
environments.
It is possible to use the same Test in both these scenarios.

OpenSTA -Open System Testing Architecture

OpenSTA (Open System Testing Architecture) is a distributed software architecture for

developing, executing and analyzing the results of Tests.

A Test may include Scripts or Collectors or both. Scripts define the operations performed by
Virtual Users. Collectors define sets of SNMP, NT Performance data or other data to be retrieved
during all or part of a Test-run. They can provide useful information about system activity and
the Results can be analyzed alongside those from other OpenSTA Modules.

The OpenSTA Architecture provides generic facilities that may be used by other OpenSTA
Modules. This chapter describes this architecture and its components.

Overview of HTTP/S Testing

OpenSTA is a distributed testing architecture that enables you to create and run
performance Tests to evaluate Web Application Environments (WAEs) and production systems.
It can be employed at all stages of WAE development as well as being used to continuously
monitor system performance once a WAE goes live.
Use it to develop load Tests that include an HTTP/S load element, known as Scripts, to help
assess the performance of WAEs during development, and to create Collector-only Tests that
monitor and record performance data from live WAEs within a production environment.
Performance tesing using HTTPs /Load

1. Create scripts ( script models)

2. Model Scripts if required
3. Create data collections collectors
4. Create tests
5. Define tasks group settings
6. Run attest
7. Monitor a test run
8. Display test results

Creating Scripts

It involves deciding how you expect clients to use the WaE under test then recording browser
sessions which incorporate this behavior to produce scripts

Modelling scripts

Modeling Scripts enables you to develop realistic Tests and improve the quality of the Test
results produced.
There are extensive modeling options available within Script Modeler that can help you to
develop realistic performance Tests. When you are familiar with the structure of Scripts and in
particular the SCL code they are written in, you will be well equipped to model them. SCL is a
simple scripting language that gives you control over the Scripts you create. It enables you to
model Scripts to accurately simulate the Web activity and to generate the load levels you need
against target WAEs when a Test is run.

Creating collectors

It involves deciding which host computers or other devices to collect performances data form
and the type of data to collect during a test run.

Creating tests

It involves creating the scripts and collectors you want to include in them then select the scripts
and collectors you need from the repository window and add them one at atime to test.

Running and Monitoring Tests

Running a test enables you to initiate real and user web activity and accurately simulate the test
conditions you want in order to generate the level of load required against target WAE’s

Displaying Results

Running a test then displaying the results enables you to analyze and assesses whether WAE’s
will be able to meet the processing demands that will be placed on them.
What Are Scripts?

Scripts form the content of an HTTP /S performance test using HTTP /S load.
All scripts are stored in the repository from where they can be included by reference into
multiple tests.

Script Modeller Interface

Script Modeller supplies versatile script creation and modeling functionality use the menu bar
and right click menu options to create and model scripts.

The Script Modeller Interface consists of 4 primary areas

1. Toolbars and Function Bars

2. Script Pane
3. Query Results Pane
4. Output Pane