PRESIDENCY UNIVERISTY, BENGALURU

School of Information Sciences

Bachelor of Computer Applications

Software Testing
(CSA 2010)
IV Semester 2024-25
 MODULE-2

Black Box Testing

• Understanding Functional Testing Without Knowing Internal Code
What is Black Box Testing?
• Black box testing is a software testing method where testers examine
external functionality without knowing the internal structure.
• Focuses on input and output rather than internal coding.
• Testers create test cases based on user requirements.
 Example of Black Box Testing
E-commerce website checkout process
• Adding items to the cart and proceeding to payment.
• Checking if error messages appear when incorrect payment details
are entered.
• Ensuring smooth and intuitive user experience.
Black Box vs. White Box Testing
Black Box Testing White Box Testing
No need-to-know internal Requires knowledge of system structure and
code. coding.

Focuses on user Focuses on internal system flaws like security

experience. issues.

Tests external Tests internal code logic and execution.

functionality.
 Benefits of Black Box Testing
• No Coding Knowledge Required: Anyone can perform it.
• User-Centric: Based on real-world user scenarios.
• Cost & Time Effective: Quick and easy to execute.
• Fewer False Positives: More accurate results.
• Protects Intellectual Property: Internal code remains confidential.
 Black Box Testing Techniques
• Equivalence Partitioning
• Boundary Value Analysis
• Decision Table Testing
• State Transition Testing
• Exploratory Testing
• Error Guessing
 Equivalence Partitioning
• Divides input data into partitions where each class produces similar
results.
• Example: OTP verification (6-digit valid, shorter/longer invalid).
Boundary Value Analysis (BVA)
• Focuses on input values at the boundaries.
• Example:
 Decision Table Testing
• Uses a structured table to represent inputs and outputs.
• Example: Membership discount (Gold & purchases over $100 = 20%
discount).
 State Transition Testing
• Tests system behavior when transitioning between states.
• Example: Shopping cart workflow (Add to cart → Checkout → Payment →
Confirmation).
 Exploratory Testing
• No predefined test cases, testers explore the application dynamically.
• Example: Navigating an e-commerce site, adding products, and testing
various functions.

Error Guessing
• Based on tester intuition and experience.
• Example:
Bank deposit limits ($5000-$7000) – testing values below and above.
 White Box Testing
• A software testing method that examines the internal structure, logic, and
code of an application.
• Requires programming knowledge to design test cases.
• Helps in identifying security vulnerabilities, logic errors, and inefficiencies.
 Importance of Code Coverage
• Measures how much of the application's code is tested.
• Ensures that unit tests validate the core functionalities.
• Includes techniques like Statement Coverage, Branch Coverage, Path
Coverage, Decision Coverage, Condition Coverage, and Multiple Condition
Coverage.
 Statement Coverage
• Ensures that every statement in the code is executed at least once.
• Helps find dead code and unexecuted statements.

• If the test case does not execute printf(“Sum = %d”, sum);, then statement
coverage is incomplete.
 Branch Coverage
• Ensures each possible branch of a control structure (IF-ELSE, loops, switches) is executed.
• Covers both True and False conditions.

• Test cases should include:

✅ x = 15 (True branch)
✅ x = 5 (False branch)
 Path Coverage
• Ensures that all possible execution paths are tested.
• More thorough than branch coverage.
• Essential for complex applications with multiple paths.

• Possible paths:
✅ (x > 0, y > 0)
✅ (x > 0, y <= 0)
✅ (x <= 0)
 Decision Coverage
• Ensures that all possible outcomes of control flow statements are tested.
• Covers decision points in IF, SWITCH, WHILE, FOR statements.

• Test Cases:
✅ A = True, B = True
✅ A = True, B = False
✅ A = False, B = True
✅ A = False, B = False
 Condition Coverage
• Ensures each condition in a decision is tested separately.
• Unlike decision coverage, it examines individual Boolean conditions.

• Test cases must check both conditions separately:

✅ X > 5, Y < 10
✅ X ≤ 5, Y < 10
✅ X > 5, Y ≥ 10
✅ X ≤ 5, Y ≥ 10
 Multiple Condition Coverage
• Tests all possible combinations of conditions.
• Uses 2ⁿ test cases, where n = number of conditions.

• Test cases must check both conditions separately:

✅ A = True, B = True
✅ A = True, B = False
✅ A = False, B = True
✅ A = False, B = False
Module-2: Test Case Development and Execution

Test Cases: Identification of Test case Scenarios

Test Case Template
Writing Test cases for Problems
Test Case Execution
Examples for Lab Exercises.
 BOUNDARY VALUE ANALYSIS (BVA)
TESTING

• Boundary value testing is focused on the values at boundaries. This

technique determines whether a certain range of values are
acceptable by the system or not.
• It is very useful in reducing the number of test cases. It is most
suitable for the systems where an input is within certain ranges.
• Boundary value analysis (BVA) is based on testing the boundary values
of valid and invalid partitions.
• The Behavior at the edge of each equivalence partition is more likely
to be incorrect than the behavior within the partition, so boundaries
are an area where testing is likely to yield defects.
• The basic assumption of boundary value analysis is, the test cases that
are created using boundary values are most likely to cause an error.

• There is 18 and 30 are the boundary values that's why tester pays more
attention to these values, but this doesn't mean that the middle values
like 19, 20, 21….27,28, 29 are ignored. Test cases are developed for each
and every value of the range.
Boundary Value Testing
• Any program can be considered to be a function in the
sense that prog. I/p form its domain & prog. o/p form
its range.
• Input domain testing is the best known functional
testing technique.
Boundary Value Analysis
• When function F is implemented as a pogram, the input
variables x1 & x2 will have some boundaries
F(x1, x2), a ≤ x1 ≤ b, c ≤ x2 ≤ d
[a,b] [c,d] are ranges of x1 & x2.
•Input space(domain) of our function F is shown above.
•Any point within the shaded rectangle is a legitimate input to
the
function F.
•Boundary value analysis focuses on the boundary of the input
space to identify test cases.
Cont.,
• Errors tend to occur near the extreme values of an input
variable
• e.g. loop conditions (< instead of ≤), counters
• Basic idea: use input variable values at their minimum (min), just
above the minimum (min+), a nominal value (nom), just below
their maximum (max-), and at their maximum (max).
• Testing tool (T) generates such Test Cases for Properly specified
program. min, min+, max-, max.
Cont.,
• The boundary value analysis test cases are obtained by
holding the values of all but one variable at their nominal
values, and letting that variable assume its extreme
values <x ,x >
1nom 2min
<x1nom, x2min+>
<x1nom, x2nom>
<x1nom, x2max->
<x1nom, x2max>
<x1min, x2nom>
<x1min+, x2nom>
<x1nom, x2nom>
<x1max-, x2nom>
<x1max, x2nom>
1) Example on Boundary Value Analysis Test Case Design Technique:

Assume, we have to test a field which accepts Age 18 – 56

• Test case 4: Enter the value 55 (56-1) = Valid
• Test case 5: Enter the value 56 = Valid
• Test case 6: Enter the value 57 (56+1) =Invalid
Example 2:
Assume we have to test a text field (Name) which accepts the length between 6-12 characters.
EXAMPLE 3 Design boundary value test cases for a Pizza delivery app.
Pizza values 1 to 10 is considered valid. A ORDER SUCCESS message is shown.
While value 11 to 99 are considered invalid for order and an ERROR message will appear, "Only
10 Pizza can be ordered"

• Minimum boundary value is 1

• Maximum boundary value is 10
• Valid Inputs: 1,2,9,10
• Invalid Inputs: 0 ,11
• Test case 1: Entered value on App 0 (min-1) = Invalid ERROR
• Test case 2: Entered value on App 1 (min) = Valid ORDER SUCCESS
• Test case 3: Entered value on App 2 (min+1) = Valid ORDER SUCCESS
• Test case 4: Entered value on App 9 (max-1) = Valid ORDER SUCCESS
• Test case 5: Entered value on App 10 (max) = Valid ORDER SUCCESS
• Test case 6: Entered value on App 11 (max+1) = Invalid ERROR
 EQUIVALENCE PARTITIONING
TESTING METHOD
• Equivalence Partitioning Method is also known as Equivalence class
partitioning (ECP). It is a software testing technique or
black-box testing that divides input domain into classes of data, and
with the help of these classes of data, test cases can be derived.
• An ideal test case identifies class of error that might require many
arbitrary test cases to be executed before general error is observed.
• In equivalence portioning, equivalence classes are evaluated for given
input conditions. Whenever any input is given, then type of input
condition is checked, then for this input conditions, Equivalence class
represents or describes set of valid or invalid states.
Contents

Equivalence class.
Weak normal equivalence class testing.
Strong normal equivalence class testing.
Weak Robust equivalence class testing.
Strong Robust equivalence class testing.
Equivalence class Testing

– amount <= 1800

– 1800 < amount < 15000
– amount >= 15000
Equivalence class Testing
• When Function F is implemented as a program, the
input variables x1,x2 will have boundaries
Weak Normal Equivalence class
Testing
• Assumes the ‘single fault’ or “independence of input
variables.”
• e.g. If there are 2 input variables, these input variables are
independent of each other.

• Partition the test cases of each input variable separately into

one of the different equivalent classes.

• Choose the test case from each of the equivalence classes for
each input variable independently of the other input variable
• Using 1 variable from each equivalence class(interval) in a test
case.
 Weak Normal Equivalence class test
cases

X2

x1
a b c d
Strong Normal Equivalence testing
• Multi Fault assumption.
• We need Test cases from each element of the Cartesian product
of the equivalence classes.
• The Cartesian product guarantees that we have a notion of
completeness in two senses
• We cover all the equivalence classes,
• We have 1 of each possible combination of inputs.
 Strong Normal Equivalence class test
cases

X2

x1
a b c d
Weak Robust Equivalence class
Testing
• Up to now we have only considered partitioning the
valid input space.

• “Weak robust” is similar to “weak normal” equivalence

test except that the invalid input variables are now
considered.
• The robust part comes from consideration of invalid
values, & the weak part refers to the single fault
assumption.
Strong Robust Equivalence Testing
• Robust part comes from consideration of invalid values,
• Strong part refers to the multiple fault assumption.
• We obtain test cases from each element of the
Cartesian product of all the equivalence classes
 Strong robust Equivalence class test
cases

X2

x1
a b c d
Equivalence class Test Cases for Triangle problem
Example-1:
Let us consider an example of any college admission process.
There is college that gives admissions to students based upon
their percentage.
• Consider percentage field that will accept percentage only between 50 to 90 %,
more and even less than not be accepted, and application will redirect user to
error page.
• If percentage entered by user is less than 50 %or more than 90 %, that
equivalence partitioning method will show an invalid percentage
• If percentage entered is between 50 to 90 %, then equivalence partitioning
method will show valid percentage.
Example 2:
Let us consider an example of an online shopping site. In this site, each of
products has specific product ID and product name. We can search for product
either by using name of product or by product ID. Here, we consider search field
that accepts only valid product ID or product name.
Decision Table
• A Decision Table is a tabular representation of inputs versus rules/cases/test
conditions. It is a very effective tool used for both complex software testing
and requirements management.
• Decision table helps to check all possible combinations of conditions for
testing and testers can also identify missed conditions easily. The conditions
are indicated as True(T) and False(F) values.
What is Decision Table Testing?
• Decision table testing is a software testing technique used to test system
behavior for different input combinations.
• This is a systematic approach where the different input combinations and
their corresponding system behavior (Output) are captured in a tabular
form.
• That is why it is also called as a Cause-Effect table where Cause and effects
are captured for better test coverage.
Example 2: How to make Decision Table for Upload Screen
Now consider a dialogue box which will ask the user to upload photo with certain conditions like –
LAB EXERCISES
Exp 1: 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 a triangle and determine if
the three values represent an equilateral triangle, isosceles triangle,
scalene triangle, or they do not form a triangle at all. Assume that the
upper limit for the size of any side is 10. Derive test cases for your
program based on boundary-value analysis, execute the test cases and
discuss the results.

AIM To derive test cases using Boundary Value Analysis

Technique
PROGRAM TO TEST Triangle Problem
TECHNIQUE USED Boundary Value Analysis
TYPE OF TESTING Black Box Testing
TC Id Test Case Input Data Expected Output Actual Status
Description A b C Output

1 Enter nominal for a& 5 5 1 Isosceles

b, min for c
2 Enter nominal for a& 5 5 2 Isosceles
b, min+ for c
3 Enter nominal for a& 5 5 5 Equilateral
b, nominal for c
4 Enter nominal for a& 5 5 9 Isosceles
b, max- for c
5 Enter nominal for a& 5 5 10 Not a Triangle
b, max for c
6 Enter nominal for a& 5 1 5 Isosceles
c, min for b
7 Enter nominal for a& 5 2 5 Isosceles
c, min+ for b
8 Enter nominal for a& 5 9 5 Isosceles
c, max- for b
9 Enter nominal for a& 5 10 5 Not a Triangle
c, max for b
10 Enter nominal for b& 1 5 5 Isosceles
c, min for a
11 Enter nominal for b& 2 5 5 Isosceles
c, min+ for a
12 Enter nominal for b& 9 5 5 Isosceles
c, max- for a
13 Enter nominal for b & 10 5 5 Not a Triangle
c, max for a
 TEST REPORT
No of Test Cases Executed:
No of Defects Raised:
No of Test Cases Passed:
No of Test Cases Failed:
Exp 2: 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 a triangle and determine if the three values represent an
equilateral triangle, isosceles triangle, scalene triangle, or they do not form a
triangle at all. Assume that the upper limit for the size of any side is 10. Derive
test cases for your program based on equivalence class partitioning, execute the
test cases and discuss the results.

AIM To derive test cases using Equivalence Class Partitioning

Technique
PROGRAM TO TEST Triangle Problem
TECHNIQUE USED Equivalence Class Partitioning
TYPE OF TESTING Black Box Testing
 Weak Normal and Weak Robust Test case for Triangle Problem
TC Id Test Case Input Data Expected Output Actual Output Status
Description
a b c

1 WN1 5 5 5 Equilateral
2 WN2 2 2 3 Isosceles
3 WN3 3 4 5 Scalene
4 WN4 4 1 2 Not a Triangle
5 WR1 -1 5 5 Value of a is not in the range of
permitted values

6 WR2 5 -1 5 Value of b is not in the range of

permitted values

7 WR3 5 5 -1 Value of c is not in the range of

permitted values

8 WR4 11 5 5 Value of a is not in the range of

permitted values

9 WR5 5 11 5 Value of b is not in the range of

permitted values

10 WR6 5 5 11 Value of c is not in the range of

permitted values
 Strong Robust Test case for Triangle Problem
TC Test Case Input Data Expected Output Actual Status
Id Description a b c
Output

1 SR1 -1 5 5 Value of a is not in the

range of permitted values

2 SR 2 5 -1 5 Value of b is not in the

range of permitted values

3 SR3 5 5 -1 Value of c is not in the range

of permitted values

4 SR4 -1 -1 5 Value of a, b is not in the

range of permitted values

5 SR5 5 -1 -1 Value of b, c is not in the

range of permitted values

6 SR6 -1 5 -1 Value of a, c is not in the

range of permitted values

7 SR7 -1 -1 -1 Value of a, b, c is not in the

range of permitted values
 TEST REPORT
No of Test Cases Executed:
No of Defects Raised:
No of Test Cases Passed:
No of Test Cases Failed:
Exp 3: 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 a 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

AIM To derive test cases using Decision Table Technique

PROGRAM TO TEST Triangle Problem

TECHNIQUE USED Decision Table
TYPE OF TESTING Black Box Testing
 DECISION TABLE FOR TRIANGLE PROBLEM
Condition Entries (Rules)

Conditions
R1 R2 R3 R4 R5 R6 R7 R8 R9 R 10 R 11

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

C3: c<a+b? -- -- F T T T T T T T T

C4: a=b? -- -- -- F T T T F F F T

C5: a=c? -- -- -- T F T F T F F T

C6: b=c? -- -- -- T T F F F T F T
Actions Action Entries

a1: Not a Triangle X X X

a2: Scalene X

a3: Isosceles X X X

a4: Equilateral X

a5: Impossible X X X
 Decision table Test Cases for Triangle problem
Expected Output
TC ID Test Case Description a B c Actual Output Status

1 Testing for Rule 1 4 1 2 Not a Triangle

2 Testing for Rule 2 1 4 2 Not a Triangle

3 Testing for Rule 3 1 2 4 Not a Triangle

4 Testing for Rule 11 5 5 5 Equilateral

5 Testing for Rule 7 2 2 3 Isosceles

6 Testing for Rule 8 2 3 2 Isosceles

7 Testing for Rule 9 3 2 2 Isosceles

8 Testing for Rule 10 3 4 5 Scalene

 TEST REPORT
No of Test Cases Executed:
No of Defects Raised:
No of Test Cases Passed:
No of Test Cases Failed:
EXP 4: Design, develop, code and run the program in any suitable language to
solve the commission problem. Analyze it from the perspective of boundary
value testing, derive different test cases, execute these test cases and discuss
the test results.

AIM To derive test cases using Boundary Value Analysis

Technique

PROGRAM TO TEST Commission Problem

TECHNIQUE USED Boundary Value Analysis
TYPE OF TESTING Black Box Testing
 Input Data
Locks Stocks Barrels Expected
TC Id Test Case Description Sales Actual Output (sales, commission) Status
L S B Output(commission)

1 Enter nominal for L, S 35 40 1 2800 420

and min for B

2 Enter nominal for L, S 35 40 2 2825 425

and min + for B

3 Enter nominal for L, S 35 40 45 3900 640

and nominal for B

4 Enter nominal for L, S 35 40 89 5000 860

and max- for B

5 Enter nominal for L, S 35 40 90 5025 865

and max for B

6 Enter nominal for L, B 35 1 45 2730 406

and min for S

7 Enter nominal for L, B 35 2 45 2760 412

and min+ for S

8 Enter nominal for L, B 35 79 45 5070 874

and max- for S
9 Enter nominal for L, B and 35 80 45 5100 880
max for S

10 Enter nominal for B, S and 1 40 45 2370 334

min for L

11 Enter nominal for B, S and 2 40 45 2415 343

min+ for L

12 Enter nominal for B, S and 69 40 45 5430 946

max- for L

13 Enter nominal for B, S and 70 40 45 5475 955

max for L
 TEST REPORT
No of Test Cases Executed:
No of Defects Raised:
No of Test Cases Passed:
No of Test Cases Failed:
Exp 5:Design, develop, code and run the program in any suitable language to
solve the commission problem. Analyze it from the perspective of equivalence
class testing, derive different test cases, execute these test cases and discuss the
test results.

AIM To derive test cases using Decision Table Technique

PROGRAM TO TEST Commission Problem

TECHNIQUE USED Equivalence Class Partitioning
TYPE OF TESTING Black Box Testing
EQUIVALENCE CLASS PARTITIONING TEST CASES FOR COMMISSION PROBLEM

TC Id Test Case Input Data Sales Expected Actual Status

Description Locks Stocks Barrels Output(Commission) Output

1 WN 10 10 10 $100 10
2 WR2 -2 40 45 Values of locks Values of locks not in the
not in the range range 1...70
1...70

3 WR3 71 40 45 Values of locks Values of locks not in the

not in the range range 1...70
1...70

4 WR4 35 -1 45 Values of stocks Values of stocks not in the

not in the range range 1...80
1...80

5 WR5 35 81 45 Values of stocks Values of stocks not in the

not in the range range 1...80
1...80

6 WR6 35 40 -1 Values of barrels Values of barrels not in

not in the range the range 1...90
1...90

7 WR8 35 40 91 Values of barrels Values of barrels not in

not in the range the range 1...90
1...90
TC Id Test Case Input Data Sales Expected Actual Status
Description Locks Stocks Barrels Output(Commission) Output

1 SR1 -2 40 45 Values of locks not Values of locks not in

in the range 1...70 the range 1...70

2 SR2 35 -1 45 Values of stocks Values of stocks not in

not in the range the range 1...80
1...80
3 SR3 35 40 -2 Values of barrels Values of barrels not in
not in the range the range 1...90
1...90
4 SR4 -2 -1 45 Values of locks not Values of locks not in
in the range 1...70 the range 1...70
Values of stocks Values of stocks not in
not in the range the range 1...80
1...80
5 SR5 -2 40 -1 Values of locks not Values of locks not in
in the range 1...70 the range 1...70
Values of barrels Values of barrels not in
not in the range the range 1...90
1...90
6 SR6 35 -1 -1 Values of stocks Values of stocks not in
not in the range the range 1...80
1...80 Values of barrels not in
Values of barrels the range 1...90
not in the range
1...90
7 SR7 -2 -1 -1 Values of locks not Values of locks not in
in the range 1...70 the range 1...70
Values of stocks Values of stocks not in
not in the range the range 1...80
1...80 Values of barrels not in
Values of barrels the range 1...90
not in the range
1...90
 TEST REPORT
No of Test Cases Executed:
No of Defects Raised:
No of Test Cases Passed:
No of Test Cases Failed:
Exp 6:Design, develop, code and run the program in any suitable language to
solve the commission problem. Analyze it from the perspective of Decision
table testing, derive different test cases, execute these test cases and discuss the
test results.

AIM To derive test cases using Decision Table Technique

PROGRAM TO TEST Commission Problem

TECHNIQUE USED Decision Table
TYPE OF TESTING Black Box Testing
Decision Table for Commission Problem
Conditions Condition Entries (Rules)

C1: 1≤locks≤70? F T T T T T

C2: 1≤stocks≤80? -- F T T T T

C3: 1≤barrels≤90? -- -- F T T T

C4: sales>1800? -- -- -- T F F

C5: sales>1000? -- -- -- -- T F

C6: sales≤1000? -- -- -- -- -- T
Actions Action Entries

a1: com1 = 0.10*Sales X

a2: com2 = com1+0.15*(sales-1000) X

a3: com3 = com2+0.20*(sales-1800) X

a4: Invalid Locks input X

a4: Invalid Stocks input X

a4: Invalid Barrels input X

Decision Table Test Cases

TC Test Case Expected Output Actual

Locks Stocks Barrels Status
ID Description Output

Enter Invalid for

Value of locks not in
1 locks and valid for -2 40 45
the range 1..70
stocks and barrels

Enter Invalid for

Value of locks not in
2 locks and valid for 90 40 45
the range 1..70
stocks and barrels

Enter Invalid for

Value of stocks not in
3 stocks and valid for 35 -3 45
the range 1..80
locks and barrels

Enter Invalid for

Value of stocks not in
4 stocks and valid for 35 100 45
the range 1..80
locks and barrels
Decision Table Test Cases

Enter Invalid for

Value of barrels not in
5 barrels and valid for 35 40 -10
the range 1..80
locks and stocks

Enter Invalid for

Value of barrels not in
6 barrels and valid for 35 40 150
the range 1..80
locks and stocks

Enter inputs where

7 5 5 5 Sales:500 a1:50
sales <1000

Enter inputs where

8 15 15 15 Sales:1500 a2: 175
sales >1000

Enter inputs where

9 25 25 25 Sales:2500 a3: 360
sales >1800
EXERCISE-5
NextDate Problem using Boundary Value Analysis

Problem Definition:
• "Next Date" is a function consisting of three variables like: month, date and year. It returns the date
of next day as output. It reads current date as input date.

The constraints are

• C1: 1 ≤ month ≤ 12
C2: 1 ≤ day ≤ 31
C3: 1812 ≤ year ≤ 2020.
• If any one condition out of C1, C2 or C3 fails, then this function produces an output "value of month
not in the range 1...12".
• Since many combinations of dates can exist, hence we can simply display one message for this
function: "Invalid Input Date".
• A very common and popular problem occurs if the year is a leap year. We have taken into
consideration that there are 31 days in a month. But what happens if a month has 30 days or even 29
or 28 days?
• A year is called as a leap year if it is divisible by 4.
#include<stdio.h>
#include<ctype.h>
int check(int day,int month)
{
if((month==4||month==6||month==9 ||month==11) && day==31)
return 1;
else
return 0;
}
int isleap(int year)
{
if (year % 400 == 0 || (year % 100 != 0 && year % 4 == 0))
return 1;
else
return 0;
}
int main()
{
int day, month, year, tomm_day, tomm_month, tomm_year;
char flag;
do
{
flag='y';
printf("\n Enter the today's date in the form of dd mm yyyy \n");
scanf("%d%d%d",&day,&month,&year);
tomm_month=month;
tomm_year= year;
if(day<1 || day>31)
{
printf("value of day, not in the range 1...31\n");
flag='n';
}
if(month<1 || month>12)
{
printf("value of month, not in the range 1....12\n");
flag='n'; }
else if(check (day,month))
{
printf("value of day, not in the range day<=30");
flag='n';
}
if(year<=1812 || year>2020)
{
printf("value of year, not in the range 1812.......2020\n");
flag='n';
}
if(month==2)
{
if(isleap(year) && day>29)
{
printf("invalid date input for leap year");
flag='n';
}
else if(!(isleap(year))&& day>28)
{
printf("invalid date input for not a leap year");
flag='n';
}
}
}
}
while(flag=='n');
switch (month)
{
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:if(day<31)
tomm_day=day+1;
else
{
tomm_day=1;
tomm_month=month+1;
}
break;
case 4:
case 6:
case 9:
case 11: if(day<30)
tomm_day=day+1;
else
{
tomm_day=1;
tomm_month=month+1;
}
break;
case 12: if(day<31)
tomm_day=day+1;
else
{
tomm_day=1;
tomm_month=1;
if(year==2020)
{
printf("the next day is out of boundary value of year\n");
return 0;
}
else
tomm_year=year+1;
}
break;
case 2:
if(day<28)
tomm_day= day+1;
else if(isleap(year) && day==28)
tomm_day=day+1;
else if(day==28 || day==29)
{
tomm_day=1;
tomm_month=3;
}
break;
}
printf("next day is : %d %d %d",tomm_day, tomm_month, tomm_year);
return 0;
}
BOUNDARY VALUE TESTING
The constraints are
C1: 1 ≤ month ≤ 12
C2: 1 ≤ day ≤ 31
C3: 1900 ≤ year ≤ 2024

The Next Date program takes date as input and checks it for validity. If it is valid, it returns the next date as its
output.

Here we have three inputs for the program, hence n = 3.

Since BVA yields (4n + 1) test cases according to single fault assumption theory,

hence we can say that the total number of test cases will be (4*3+1)=12+1=13.
The boundary value test cases are

C1: 1 ≤ month ≤ 12
C2: 1 ≤ day ≤ 31
C3: 1900 ≤ year ≤ 2024
STRONG NORMAL EQUIVALENCE TEST CLASS
Decision Table for Nextdate problem
DECISION TABLE TEST CASES
LAB EXERCISES ON
WHITE BOX TESTING
 Introduction to White box testing
• It is a testing method in which the internal structure/design/implementation
of the program is being tested.
• Also known as Clear Box Testing, Open Box Testing, Glass Box Testing,
Transparent Box Testing, Code-Based Testing or Structural Testing)
• The tester chooses inputs to exercise paths through the code and determines
the appropriate outputs.

The key principles that assist you in executing white box tests successfully are:
Statement Coverage – ensure every single line of code is tested.
Branch Coverage – ensure every branch (e.g. true or false) is tested.
Path Coverage – ensure all possible paths are tested.
 Advantages of White Box
Testing:

• Forces test developer to reason carefully about

implementation.
• Reveals errors in "hidden" code.
• Spots the Dead Code or other issues with respect to best
programming practices.
 Disadvantages of White Box Testing:

• Expensive as one has to spend both time and money

to perform white box testing.
• Every possibility that few lines of code are missed
accidentally.
• In-depth knowledge about the programming
language is necessary to perform white box testing.
 Levels applicable to:

• White Box Testing method is applicable to the following

levels of software testing:
• Unit Testing: For testing paths within a unit.
• Integration Testing: For testing paths between units.
• System Testing: For testing paths between subsystems.
 Static Testing

• Static testing is a software testing method that involves

examination of the program's code and its associated
documentation but does not require the program be executed.
• Static Testing, a software testing technique in which the software
is tested without executing the code. It has two parts as listed
below:
• Review - Typically used to find and eliminate errors or
ambiguities in documents such as requirements, design, test
cases, etc.
• Static analysis - The code written by developers are analyzed
(usually by tools) for structural defects that may lead to
defects.
• Static Testing is defined as a software testing
technique by which we can check the defects in
software without actually executing it. Its counter-
part is Dynamic Testing which checks an application
when the code is run
• The two main types of static testing techniques are
• Manual examinations: Manual examinations include
analysis of code done manually, also known as
REVIEWS.
• Automated analysis using tools: Automated analysis
are basically static analysis which is done using tools.
Static Testing by
humans

There are multiples ways to achieve Static

testing by humans. Few of them are as
follows:
• Desk checking of the code
• Code walkthrough
• Code Review
• Code Inspection
 Desk checking of the code

• Desk checking is an informal manual test that programmers can use

to verify coding and algorithm logic before a program launch. This
enables them to spot errors that might prevent a program from
working as it should.
• Desk checking is a similar process to proof reading; in this exercise,
the programmer runs through lines of code to identify errors and to
check logic.
• Typically, the programmer will print out the code and go through it
in a pencil and paper exercise. This usually involves creating a table
with columns containing line numbers, variables, conditions, and
inputs and outputs, depending on the checks he is making.
 Code walkthrough
• Code Walkthrough is a form of peer review in which a programmer
leads the review process and the other team members ask questions
and spot possible errors against development standards and other
issues.
• The meeting is usually led by the author of the document under review
and attended by other members of the team.
• The main purpose of walkthrough is to enable learning about the
content of the document under review to help team members gain an
understanding of the content of the document and also to find defects.
 Code Review

• Code review (sometimes referred to as peer review) is a

software quality assurance activity in which one or several
humans check a program mainly by viewing and reading parts
of its source code, and they do so after implementation or as
an interruption of implementation.

• Code review is systematic examination (often as peer review)

of computer source code. It is intended to find and fix mistakes
overlooked in the initial development phase, improving both
the overall quality of software and the developers' skills.
 Code Inspection

• Code Inspection is the most formal type of review, which is a

kind of static testing to avoid the defect multiplication at a
later stage. The main purpose of code inspection is to find
defects and it can also spot any process improvement if any.
• The inspection process is the most formal type of review
based on rules and checklists and makes use of entry and
exit criteria.
• It usually involves peer examination of the code and each
one has a defined set of roles.
• After the meeting, a formal follow-up process is used to
ensure that corrective action is completed in a timely
manner.
 Static Testing by Tools

• Static analysis tools are generally used by developers as part of the

development and component testing process.
• The key aspect is that the code (or other artefact) is not executed or
run but the tool itself is executed, and the source code we are
interested in is the input data to the tool.
• Other than software code, static analysis can also be carried out on
things like, static analysis of requirements or static analysis of websites
(for example, to assess for proper use of accessibility tags or the
following of HTML standards).
• Static analysis tools for code can help the developers to understand the
structure of the code, and can also be used to enforce coding standards.
Features or characteristics of static analysis tools are:
• To calculate metrics such as cyclomatic complexity or nesting levels
(which can help to identify where more testing may be needed due to
increased risk).
• To enforce coding standards.
• To analyze structures and dependencies.
• Help in code understanding.
• To identify anomalies or defects in the code.
Exp 7: Design, develop, code and run the program in any suitable
language to implement the binary search algorithm. Determine the basis
paths and using them derive different test cases, execute these test cases
and discuss the test results.

AIM To derive test cases using Basis paths testing

PROGRAM TO TEST Binary Search

TECHNIQUE USED Basis paths testing

TYPE OF TESTING White Box Testing

What is Path Testing?

Path testing is a structural testing method that involves using the

source code of a program in order to find every possible executable
path. It helps to determine all faults lying within a piece of code. This
method is designed to execute all or selected path through a computer
program.
Basis Path Testing

Basis path testing is a form of Structural testing (White Box testing). The method devised by
McCabe to carry out basis path testing has four steps. These are:
1. Draw the program graph.
2. Calculate the cyclomatic complexity.
3. Select a basis set of paths.
4. Generate test cases for each of these paths
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.
Lab Exercise Complete Binary Search program

int binsrc(int x[],int low, int high, int key)

{
int mid; 1
while(low<=high) 2
{
mid=(low+high)/2;
if(x[mid]==key) 3
return mid; 8
if(x[mid]<key) 4
low=mid+1; 5
else
high=mid-1; 6
} 7
return -1; 8
} 9
int main()
{
int a[20],key,i,n,succ;
printf("Enter the n value");
scanf("%d",&n);
if(n>0)
{
printf("enter the elements in ascending order\n");
for(i=0;i<n;i++)
scanf("%d",&a[i]);
printf("enter the key element to be searched\n");
scanf("%d",&key);
succ=binsrc(a,0,n-1,key);
if(succ>=0)
printf("Element found in position = %d\n",succ+1);
else
printf("Element not found \n");
}
else
printf("Number of element should be greater than zero\n");
return 0;
}
#include<stdio.h>
int binsrc(int x[],int low, int high, int key)
{
int mid; 1
while(low<=high) 2
{
mid=(low+high)/2;
if(x[mid]==key) 3
return mid; 8
if(x[mid]<key) 4
low=mid+1; 5
else
high=mid-1; 6
} 7
return -1; 8
} 9

PROGRAM GRAPH
BASIS PATHS
DERIVING TEST CASES USING BASIS PATH TESTING
The last step is to devise test cases for the basis paths.
TEST CASES

Expected Output
Actual
TC ID PATHS array elements key Status
Output

Element found
1 1-2-3-8-9 {10.20.30.40.50} 30
in position = 3

Element found
2 1-2-3-4-5-7-2 {10.20.30.40.50} 20
in position = 2

Element found
3 1-2-3-4-6-7-2 {10.20.30.40.50} 40
in position = 4

4 1-2-8-9 NA NA NA NA NA
Exp 8: Design, develop, code and run the program in any suitable
language to implement an absolute letter grading procedure, making
suitable assumptions. Determine the basis paths and using them derive
different test cases, execute these test cases and discuss the test results.

AIM WRITE CODE AND TEST CASES, EXECUTE TEST CASES

PROGRAM TO TEST Letter grading procedure

TECHNIQUE USED Basis paths testing

TYPE OF TESTING White Box Testing

#include<stdio.h>
main()
{
int per;
printf("Enter percentage\n");
scanf("%d",&per);
if((per<35)&&(per>=1))
printf("fail");
else if((per<=40)&&(per>=35))
printf("Grade C");
else if((per<=50)&&(per>40))
printf("Grade C+");
else if((per<=60)&&(per>50))
printf("Grade B");
else if((per<=70)&&(per>60))
printf("Grade B+");
else if((per<=80)&&(per>70))
printf("Grade A");
else if((per<=100)&&(per>80))
printf("Grade A+");
else
printf("Invalid input\n");
}
Calculate the cyclomatic complexity.

V(G)= E – N + 2 * P = 26-20+2*1 = 8
Basis Paths:
P1 to P8
BASIS PATHS TEST CASES
TCID Basis Path Input Data Actual O/P Expected O/p Status
P1 1-2-3-4-5-20 30 Fail Fail Pass
P2
P3
P4
P5
P6
P7
P8
Exercise: 9 Design, develop, code and run the program in any
suitable language to implement a PRIME NUMBER CHECKING
procedure, making suitable assumptions.

Determine the basis paths and using them derive different test
cases, execute these test cases and discuss the test results.
#include <stdio.h>
int main() {
int n, i, flag = 0;
printf("Enter a positive integer: ");
scanf("%d", &n);
// 0 and 1 are not prime numbers
// change flag to 1 for non-prime number
if (n == 0 || n == 1)
flag = 1;
for (i = 2; i <= n / 2; ++i) {
// if n is divisible by i, then n is not prime
// change flag to 1 for non-prime number
if (n % i == 0) {
flag = 1;
break; } }
// flag is 0 for prime numbers
if (flag == 0)
printf("%d is a prime number.", n);
else
printf("%d is not a prime number.", n);
return 0; }
Control Flow Graph
Calculate the cyclomatic complexity by using the following formula −

• V(G) = e - n + 2*p
In the control flow diagram above,
where e = 10, n = 8, and p =1
As a result, V(G) = 10 - 8 + 2 * 1 = 4 Cyclomatic Complexity
BASIS PATHS
• A – B – F – G – H is the first path.

• A – B – F – H is the second path.

• A - B - C - E - B - F - G - H is the third path

• A - B - C - D - F - H is the fourth path.

BASIS PATH TEST CASES