Experiment 1:: AIM: Consider An Automated Banking Application. The User Can Dial The Bank From A Personal Computer
Experiment 1:: AIM: Consider An Automated Banking Application. The User Can Dial The Bank From A Personal Computer
Experiment 1:: AIM: Consider An Automated Banking Application. The User Can Dial The Bank From A Personal Computer
EXPERIMENT 1:
AIM: Consider an automated banking application. The user can dial the bank from a personal computer,
provide a six-digit password, and follow with a series of keyword commands that activate the banking
function. The software for the application accepts data in the following form:
TEST CASES:
Status
TestCase Expected (Pass/Fai
ID Test Step Description Test Data result Actual result l)
validation enter the 3 digit
of area area code if non-
code local and Blank if
TC01 local.
validation enter the 3 digit
of area area code if non-
code local and Blank if
TC02 local.
validation enter the 3 digit
of area area code if non-
code local and Blank if
TC03 local.
validation enter the 3 digit
of area area code if non-
code local and Blank if
TC04 local.
Validation enter a 3-digit
of Prefix number prefix. It
should not begin
TC05 with 0 (or) 1.
Validation enter a 3-digit
of Prefix number prefix.It
should not begin
TC06 with 0 (or) 1.
"Withdrawl".
EXPERIMENT-2
AIM: Consider an automated banking application. The user can dial the bank from a personal computer,
provide a six-digit password, and follow with a series of keyword commands that activate the banking
function. The software for the application accepts data in the following form:
Design the test cases to test the system using following Black Box testing technique:
DESCRIPTION:
Boundary value analysis is the process of testing between extreme ends or boundaries between
partitions' of the input values. So these extreme ends like min, min+, nom, max, max- values are called
boundary values and the testing is called "boundary testing".
The basic idea in boundary value testing is to select input variable values at their:
1. Minimum
3. A nominal value
5. Maximum
ROBUST BVA:
Robustness testing can be seen as an extension of Boundary Value Analysis. The idea behind
Robustness testing is to test for clean and dirty test cases. By clean I mean input variables that lie in the
legitimate input range. By dirty I mean using input variables that fall just outside this input domain. In
addition to the aforementioned 5 testing values (min, min+, nom, max-, max) we use two more values for
each variable (min-, max+), which are designed to fall just outside of the input range.
WORST BVA:
Boundary Value analysis uses the critical fault assumption and therefore only tests for a single
variable at a time assuming its extreme values. By disregarding this assumption we are able to test the
outcome if more than one variable were to assume its extreme value. In an electronic circuit this is called
Worst Case Analysis.
If the function under test were to be of the greatest importance we could use a method named
Robust Worst-Case testing which as the name suggests draws it attributes from Robust and Worst-Case
testing. Test cases are constructed by taking the Cartesian product of the 7-tuple set defined in the
Robustness testing chapter. Obviously this results in the largest set of test results we have seen so far and
requires the most effort to produce
TEST CASES:
TC01
TC02
TC03
TC04
TC05
Test Area
CaseID Code Prefix Suffix Password Command Expected output
TC01
TC02
TC03
TC04
TC05
Test Area
CaseID Code Prefix Suffix Password Command Expected output
TC01
TC02
TC03
TC04
TC05
EXPERIMENT-3
AIM: Consider an application that is required to validate a number according to the following simple
rules
A number can start with an optional sign.
If there is a decimal point, then there should be two digits after the decimal.
If there is a decimal point, then there should be two digits after the decimal.
Any number-whether or not it has a decimal point, should be terminated a blank. Generate test
cases to test valid and invalid numbers.
DESCRIPTION:
A decision table is an excellent tool to use in both testing and requirements management.
Essentially it is a structured exercise to formulate requirements when dealing with complex
business rules. Decision tables are used to model complicated logic.
In a decision table, conditions are usually expressed as true (T) or false (F). Each column in the
table corresponds to a rule in the business logic that describes the unique combination of circumstances
that will result in the actions.
Decision tables can be used in all situations where the outcome depends on the combinations of
different choices, and that is usually very often. In many systems there are tons of business rules where
decision tables add a lot of value.
2. Add Columns
4. Determine Actions
DECISION TABLE:
TEST CASES:
EXPERIMENT-4
AIM: Generate test cases using Black box testing technique to Calculate Standard Deduction on Taxable
Income. The standard deduction is higher for tax payers who are 65 or older or blind. Use the method given
below to calculate tax.
1. The first factor that determines the standard deduction is the filing status. The basic standard deduction
for the various filing status are:
Single $4,750
Married, filing a joint return $9,500
Married, filing a separate return $7,000
2. If a married couple is filing separate returns and one spouse is not taking standard Deduction, the other
spouse also is not eligible for standard deduction.
3. An additional $1,000 is allowed as standard deduction, if either the filer is 65 yrs or the spouse is 65 yrs
or older (the latter case applicable when the filing status is “Married” and filing “joint”).
4. An additional $1,000 is allowed as standard deduction, if either the filer is blind or the spouse is blind
(the latter case applicable when the filing status is
“married” and filing “joint”).
DESCRIPTION:
BLACK-BOX TESTING:
` Black-box testing is a method of software testing that examines the functionality of an application
without peering into its internal structures or working. This method of test can be applied to virtually every
level of software testing: unit, integration, system and acceptance. It typically comprises most if not all
higher level testing ,but can also dominate unit testing as well.
EQUIVALENCE CLASS:
Equivalence Partitioning also called as equivalence class partitioning. It is abbreviated as ECP. It is
a software testing technique that divides the input test data of the application under test into each partition
at least once of equivalent data from which test cases can be derived. An advantage of this approach is it
reduces the time required for performing testing of a software due to less number of test cases.
EQUIVALENCE CLASSES:
TEST CASES
SD1
SD2
SD3
SD4
SD5
SD6
SD7
SD8
SD9
SD10
EXPERIMENT-5
The control flow graph is a graphical representation of a program's control structure. It uses the
elements named process blocks, decisions, and junctions.
The flow graph is similar to the earlier flowchart, with which it is not to be confused.
The nodes are represented in the following way
Flow Graph Elements: A flow graph contains four different types of elements (1) Decisions (2)
Junctions (3) Case Statements.
1. Decisions:
A decision is a program point at which the control flow can diverge.
2. Case Statements:
A case statement is a multi-way branch or decisions.
Examples of case statement are a jump table in assembly language, and the
PASCAL case statement.
From the point of view of test design, there are no differences between Decisions
and Case Statements
3. Junctions:
A junction is a point in the program where the control flow can merge.
Examples of junctions are: the target of a jump or skip instruction in ALP, a label
that is a target of GOTO.
CYCLOMATIC COMPLEXITY:
Cyclomatic complexity is a source code complexity measurement that is being correlated to a
number of coding errors. It is calculated by developing a Control Flow Graph of the code that measures
the number of linearly-independent paths through a program module.
In other words, the cyclomatic complexity metric is based on the number of decisions in a
program. It is important to testers because it provides an indication of the amount of testing (including
reviews) necessary to practically avoid defects.
In other words, areas of code identified as more complex are candidates for reviews and
additional dynamic tests. While there are many ways to calculate cyclomatic complexity, the easiest way
is to sum the number of binary decision statements (e.g. if, while, for, etc.) and add 1 to it. A more formal
definition regarding the calculation rules is provided in the glossary.
INDEPENDENT PATHS:
The number of different paths from the stating node of the flow graph to the ending node of the
flow graph. A graph may have 1 or more independent paths.
A
1 2 3
4 B
5
R2 C R4
R1 D
6
7
E
8 F
9
G
R3 H
10
I I
11 12
B)CYCLOMETRIC COMPLEXITY:
V(G)=e-n+2P
V(G)=d+1
C)INDEPENDENT PATHS:
EXPERIMENT-6
AIM: source code of simple insertion sort implementation using arrays in ascending order in c
programming language
PROGRAM:
1. #include<stdio.h>
2. Int main()
3. {
4. IntI,j,s,temp,a[20];
5. Printf(“Enter total elements”);
6. Scanf(“%d”,&s);
7. Printf(“Enter %d elements”,s);
8. For(i=0;i<s;i++)
9. Scanf(“%d”,a[i]);
10. For(i=0;i<s;i++)
11. {
12. Temp=a[i];
13. J=i-1;
14. While((temp<a[j])&&(j>=0))
15. {
16. a[j+1]=a[j];
17. j=j-1;
18. }
19. a[j+1]=temp;
20. }
21. Printf(“after sorting”);
22. For(i=0;i<s;i++)
23. Printf(“%d”,a[i]);
24. return 0;
25. }
B) CYCLOMATIC COMPLEXITY:
a. V(g) = e-n+2p =
b. V(g) = d+1 =
c. No „of regions: v(g)=
C) INDEPENDENT PATHS :
D) TEST CASES :
TC01
TC02
TC03
TC04
EXPERIMENT-7
AIM: Consider a system having an FSM for a stack having the following states and Transitions.
STATES:
Design test case for this FSM using state table- based testing.
DESCRIPTION:
State Transition testing, a black box testing technique, in which outputs are triggered by changes
to the input conditions or changes to 'state' of the system. In other words, tests are designed to execute
valid and invalid state transitions.
Understand the various state and transition and mark each valid and invalid state
Defining a sequence of an event that leads to an allowed test ending state
Each one of those visited state and traversed transition should be noted down
Steps 2 and 3 should be repeated until all states have been visited and all transitions traversed
For test cases to have a good coverage, actual input values and the actual output values have to be
generated
ADVANTAGES:
Allows testers to familiarize with the software design and enables them to design tests effectively.
It also enables testers to cover the unplanned or invalid states.
STATE TABLE:
Full / T3
Empty / T11
TEST CASES:
TC01
TC02
TC03
TC04
TC05
TC06
TC07
TC08
TC09
TC10
TC11
TC12
TC13
TC14
TC15
TC16
TC17
TC18
TC19
TC20
TC21
TC22
TC23
EXPERIMENT-8
AIM :Given the following fragments of code, how many tests are required for 100% decision coverage ?
Give the test cases.
PROGRAM:
Branch coverage is also known as Decision coverage or all-edges coverage.It covers both the true
and false conditions unlikely the statement coverage.A branch is the outcome of a decision, so branch
coverage simply measures which decision outcomes have been tested. This sounds great because it takes
a more in-depth view of the source code than simple statement coverage.
This metric ignores branches within Boolean expressions which occur due to short-circuit
operators.
TC01
TC02
TC03
TC04
EXPERIMENT-9
AIM : To give the following code ., how much minimum number of test cases is required for full statement
and branch coverage ?
PROGRAM:
Read p
Read q
If p+q>100
If p>50
DESCRIPTION:
STATEMENT COVERAGE:
Statement coverage is a white box testing technique, which involves the execution of all the
statements at least once in the source code. It is a metric, which is used to calculate and measure the
number of statements in the source code which have been executed. Using this technique, we can check
what the source code is expected to do and what it should not. It can also be used to check the quality of the
code and the flow of different paths in the program. The main drawback of this technique is that we cannot
test the false condition in it.
Branch Coverage:
Branch coverage is also known as Decision coverage or all-edges coverage.It covers both the true
and false conditions unlikely the statement coverage.A branch is the outcome of a decision, so branch
coverage simply measures which decision outcomes have been tested. This sounds great because it takes a
more in-depth view of the source code than simple statement coverage.
This metric ignores branches within Boolean expressions which occur due to short-circuit
operators.
TC01
TC01
TC02
EXPERIMENT-10
AIM: Consider a program to input two numbers and print them in ascending order given below. Find all
du paths and identify those du-paths that are not feasible. Also find all dc paths and generate the test cases
for all paths (dc paths and non dc paths).
#include<stdio.h>
#include<conio.h>
1. void main ()
2. {
3 int a, b, t;
4. Clrscr ();
5. Printf (“Enter first number”);
6. scanf (“%d”,&a);
7. printf(“Enter second number”);
8. scanf(“%d”,&b);
9. if (a<b){
10. t=a;
11. a=b;
12. b=t;
13. }
14. printf (“%d %d”, a, b);
15 getch ();
}
DESCRIPTION:
DU-PATHS:-
In a path segment if the variable is defined earlier and the last link has a computational use of that
variable then that path is termed as a du path.
A sub-path in the flow is defined to go from a point where a variable is "defined", to a point where
it is "referenced", that is, where it is "used" - whatever kind of usage it is. Such a sub-path is called a
"definition-use pair" or "du-pair". The pair is made up of a "definition" of a variable and a "use" of the
variable.
DC-PATHS:-
• A path (i, n1, ..., nm, j) is called a definition-clear path with respect to x from node i to node j if it
contains no definitions of variable x in nodes (n1, ..., nm , j) .
• The family of data flow criteria requires that the test data execute definition-clear paths from each
node containing a definition of a variable to specified nodes containing c-use and edges
containing p-use of that variable.
1,2,3,4,5
7,8
11,12,13
14
15,16
1,2,3,4,5
6:Define
7,8
9:P-use
10:C-use
11:Define
12,13
14:P-use
15,16
DU-PATHS DC-PATHS
8:Define
9:P-use
10
11:C-use
12:Define
13
14:P-use
15,16
DU-PATHS DC-PATHS
1,2,3,4,5,6,7,8
10:Define
11
12:C-use
13
14
15,16
DU-PATHS DC-PATHS
1. 1.
EXPERIMENT-11
AIM: Consider the program and generate possible program slices for all variables. Design at least one test
case from every slice.
#include<stdio.h>
#include<conio.h>
3. void main ()
4. {
3 int a, b, t;
14. Clrscr ();
15. Printf (“Enter first number”);
16. scanf (“%d”,&a);
17. printf(“Enter second number”);
18. scanf(“%d”,&b);
19. if (a<b){
20. t=a;
21. a=b;
22. b=t;
23. }
14. printf (“%d %d”, a, b);
15 getch ();
}
DESCRIPTION:
One of the program analysis techniques is program slicing. The main applications of program
slicing include various software engineering activities such as program understanding, debugging, testing,
program maintenance, complexity measurement and so on. Program slicing is a feasible method to restrict
the focus of a task to specific sub-components of a program. It can also be used to extract the statements
of a program that are relevant to a given computation.
TEST CASES:-
Test Case id a b a b
T1 10 20 20 10
T2 20 10 20 10
T3 10 10 10 10
EXECUTION SLICE:-
The Set of statements executed under a Test Case is called as an Execution Slice of a program.
#include<stdio.h>
#include<conio.h>
1.void main ()
2.{
3.int a, b, t;
4.Clrscr ();
5.Printf (“Enter first number”);
6.scanf (“%d”,&a);
7.printf(“Enter second number”);
8.scanf(“%d”,&b);
9.if (a<b){
10.t=a;
11.a=b;
12. b=t;
13.}
14. printf (“%d %d”, a, b);
15 getch ();
}
In the above Program the IF statement(9) is changed to “if(a==b)” then only the test case T3 has
to be re-run.
Test Case id a B a b
T3
DYNAMIC SLICE:-
The set of statements executed under a test case and having an effect on program output is called
as Dynamic Slice of a program.
#include<stdio.h>
#include<conio.h>
1void main ()
2{
3.int a, b, t;
4.Clrscr ();
5.Printf (“Enter first number”);
6.scanf (“%d”,&a);
7.printf(“Enter second number”);
8.scanf(“%d”,&b);
9.if (a<b){
10.t=a;
11.a=b;
12. b=t;
13.}
14. printf (“%d %d”, a, b);
15 getch ();
}
In the above Program the IF statement(9) is changed to “if(a>b)” then only the test case T2 has to
be re-run.
Test Case id a B a b
T2
EXPERIMENT-12
AIM:Consider the code to arrange the nos. in ascending order. Generate the test cases for relational
coverage, loop coverage and path testing. Check the adequacy of the test cases through mutation testing
and also compute the mutation score for each.
PROGRAM:
1.i = 0;
2.n=4;
3.While (i<n-1)
4.do j = i + 1;
5.While (j<n)
6.do if A[i]<A[j]
7. Swap (A[i], A[j]);
8 end do;
9. i=i+1;
10.end do
DESCRIPTION:
PATH TESTING:
Path Testing is a structural testing method based on the source code or algorithm and NOT based
on the specifications. It can be applied at different levels of granularity.
PATH TESTING TECHNIQUES:
Control Flow Graph (CFG) - The Program is converted into Flow graphs by representing the
code into nodes, regions and edges.
Decision to Decision path (D-D) - The CFG can be broken into various Decision to Decision
paths and then collapsed into individual nodes.
Independent (basis) paths - Independent path is a path through a DD-path graph which cannot be
reproduced from other paths by other methods.
MUTATION TESTING:
Mutation testing is a structural testing technique, which uses the structure of the code to guide the
testing process. On a very high level, it is the process of rewriting the source code in small ways in order
to remove the redundancies in the source code.
These ambiguities might cause failures in the software if not fixed and can easily pass through
testing phase undetected.
1, 2
A
3
B
4
C
R1 R2
6
R3 R4
7
F 8
G
9
H
10
Cyclomatic Complexity:
1. Cyclomatic complexity = E - N + P
Where, E = number of edges in the flow graph.
N = number of nodes in the flow graph.
P = number of Procedures in the flow graph
V (G) = E - N + P
=
2. Cyclomatic complexity = number of regions in graph
V (G)=
3. Cyclomatic complexity = number of Decision nodes in the graph + 1
V (G) =
IndependentPaths:
The number of different paths from the starting node of the flow graph to reach the ending node of the
flow graph. A graph may have 1 or more independent paths.
TEST CASES:
TID
INPUT EXPECTED OUTPUT INPUTPATH
OUTPUT
TC01
TC02
TC03
ORIGINAL PROGRAM:
1.i = 0;
2.n=4;
3.While (i<n-1)
4.do j = i + 1;
5.While (j<n)
6.do if A[i]<A[j]
7. Swap (A[i], A[j]);
8 end do;
9. i=i+1;
10.end do
MUTATED PROGRAM:
1.i = 0;
2.n=4;
3.While (i<n+1) // M1
4.do j = i + 1;
5.While (j<n+1) // M2
6.do if A[i]>=A[j] // M3
7. Swap (A[i], A[j]);
8 end do;
9. i=i+1;
10.end do
KILLED MUTANT:
If the original program and mutant programs generate the same output, then that mutant is
killed by the test case. Hence the test case is good enough to detect the change between the
original and the mutant program.
LIVE MUTANT:
If the original program and mutant program generate different output, Mutant is kept alive.
In such cases, more effective test cases need to be created that kill all mutants.
TEST CASES:
TC01
TC02
TC03
MUTATION SCORE:
The mutation score is defined as the percentage of killed mutants with the total number of
mutants.
EXPERIMENT-13
AIM: Design and develop a program in a language of your choice to solve the triangle problem defined as
follows : Accept three integers which are supposed to be the three sides of triangle and determine if the
three values represent an equilateral triangle, isosceles triangle, scalene triangle, or they do not form a
triangle at all. Derive test cases for your program based on decision-table approach, execute the test cases
and discuss the results
PROGRAM:
#include<stdio.h>
int main()
{
int a,b,c;
char istriangle;
printf("enter 3 integers which are sides of triangle\n");
scanf("%d%d%d",&a,&b,&c);
printf("a=%d\t,b=%d\t,c=%d",a,b,c);
if( a<b+c && b<a+c && c<a+b ) // to check is it a triangle or not
istriangle='y';
else
istriangle ='n';
if (istriangle=='y')
if ((a==b) && (b==c))
printf("equilateral triangle\n");
else if ((a!=b) && (a!=c) && (b!=c))
printf("scalene triangle\n");
else
printf("isosceles triangle\n");
else
printf("Not a triangle\n");
return 0;
}
DESCRIPTION:
DECISION TABLE BASED TESTING:
A decision table is an excellent tool to use in both testing and requirements management.
Essentially it is a structured exercise to formulate requirements when dealing with complex business
rules. Decision tables are used to model complicated logic.
In a decision table, conditions are usually expressed as true (T) or false (F). Each column in the
table corresponds to a rule in the business logic that describes the unique combination of circumstances
that will result in the actions.
Decision tables can be used in all situations where the outcome depends on the combinations of
different choices, and that is usually very often. In many systems there are tons of business rules where
decision tables add a lot of value.
2. Add Columns
4. Determine Actions
DECESION TABLE:
RULES R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11
C1:a<b+c F T T T T T T T T T T
C2: b<a+c - F T T T T T T T T T
Condition C3: c<a+b - - F T T T T T T T T
Stub C4: a=b - - - T T T T F F F F
C5: a=c - - - T T F F T T F F
C6:b=c - - - T F T F T F T F
A1: Not a
Triangle
X X X
A2: Scalene X
Triangle
Action
A3: Isosceles X X X
Stub
Triangle
A4: Equilateral
Triangle
X
A5: Impossible X X X
TEST CASES:
Test Input
case Actual
ID Description a b C Expected Output Output Status
TC01
TC02
TC03
TC04
TC05
TC06
EXPERIMENT-14
DESCRIPTION:
Automation Automation is making a process automatic eliminating the need for human intervention. It is a
self-controlling or self-moving process. Automation Software offers automation wizards and commands of
its own in addition to providing a task recording and re-play capabilities. Using these programs you can
record an IT or business task.
Benefits of Automation
Fast
Reliable
Repeatable
Programmable
Reusable
INTRODUCTION TO SELENIUM
1. History of Selenium
• In 2004 invented by Jason R. Huggins and team.
• Original name is JavaScript Functional Tester [JSFT]
• Open source browser based integration test framework built originally by
Thoughtworks.
• 100% JavaScript and HTML
• Web testing tool
• That supports testing Web 2.0 applications
B. Toolbar: The toolbar contains buttons for controlling the execution of your test cases, including a
step feature for
C. Menu Bar:
· File Menu: The File menu allows you to create, open and save test case and test suite files.
· Edit Menu: The Edit menu allows copy, paste, delete, undo and select all operations for
editing the commands in your test case.
· Options Menu: The Options menu allows the changing of settings. You can set the timeout
value for certain commands, add user-defined user extensions to the base set of Selenium
commands, and specify the format (language) used when saving your test cases.
D. Help Menu:
The command set is often called selenese. Selenium commands come in three “flavors”:
Actions are commands that generally manipulate the state of the application.
· assert
· verify
· waitFor
Example: "assertText","verifyText" and "waitForText".
NOTE:
These are probably the most commonly used commands for building test.
click/clickAndWait - performs a click operation, and optionally waits for a new page to load.
verifyElementPresent -verifies an expected UI element, as defined by its HTML tag, is present on the
page.
verifyText - verifies expected text and it‟s corresponding HTML tag are present on the page.
waitForPageToLoad -pauses execution until an expected new page loads. Called automatically when
clickAndWait is used.
waitForElementPresent -pauses execution until an expected UI element, as defined by its HTML tag, is
present on the page.
During recording, Selenium-IDE will automatically insert commands into your test case based on your
actions.
a. Remember Base URL MODE - Using Base URL to Run Test Cases in Different Domains
Run a Test Case Click the Run button to run the currently displayed test case. Run a Test Suite Click the
Run All button to run all the test cases in the currently loaded test suite.
Stop and Start The Pause button can be used to stop the test case while it is running. The icon of this
button then changes to indicate the Resume button. To continue click Resume.
Stop in the Middle You can set a breakpoint in the test case to cause it to stop on a particular command.
This is useful for debugging your test case. To set a breakpoint, select a command, right-click, and from the
context menu select Toggle Breakpoint.
Start from the Middle You can tell the IDE to begin running from a specific command in the middle of
the test case. This also is used for debugging. To set a startpoint, select a command, right-click, and from
the context menu select Set/Clear Start Point.
Run Any Single Command Double-click any single command to run it by itself. This is useful when
writing a single command. It lets you immediately test a command you are constructing, when you are not
sure if it is correct. You can double-click it to see if it runs correctly. This is also available from the context
menu.
Test Suite:
A test suite is a collection of tests. Often one will run all the tests in a test suite as one continuous batch-
job. When using Selenium-IDE, test suites also can be defined using a simple HTML file. The syntax again
is simple. An HTML table defines a list of tests where each row defines the filesystem path to each test.
Using Firefox, first, download the IDE from the SeleniumHQ downloads page Firefox will protect
you from installing addons from unfamiliar locations, so you will need to click „Allow‟ to proceed with the
installation, as shown in the following screenshot.
Select Install Now. The Firefox Add-ons window pops up, first showing a progress bar, and when the
download is complete, displays the following.
Restart Firefox. After Firefox reboots you will find the Selenium-IDE listed under the Firefox Tools
menu.
When downloading from Firefox, you‟ll be presented with the following window.