0% found this document useful (0 votes)
85 views5 pages

Lecture 3 (Note)

Uploaded by

swomth7
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
85 views5 pages

Lecture 3 (Note)

Uploaded by

swomth7
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

Lecture – 3

Software Testing
Black-Box Testing
1. Equivalence Class Partitioning

Q1. For a software that computes the square root of an input integer that can assume values in
the range of 0 and 5000. Determine the equivalence classes and the black box test suite.
Answer: There are three equivalence classes—
• The set of negative integers,
• the set of integers in the range of 0 and 5000, and
• the set of integers larger than 5000.
test suite : {–5, 500, 6000}
Test Case ID Test case Description Test Data Expected Result
TC1 Check input integer value -5 System should not accept
TC2 Check input integer value 500 System should accept
TC3 Check input integer value 6000 System should not accept

Q2. Design the equivalence class test cases for a program that reads two integer pairs (m1, c1)
and (m2, c2) defining two straight lines of the form y = mx + c. The program computes the
intersection point of the two straight lines and displays the point of intersection.
Answer: The equivalence classes are the following:
• Parallel lines (m1 = m2, c1  c2)
• Intersecting lines (m1  m2)
• Coincident lines (m1 = m2, c1 = c2)
test suite : {(2,2)(2,5),(5,5)(7,7), (10,10) (10,10)}
Test Case ID Test case Description Test Data Expected Result
TC1 Check input integer value for (2,2) (2,5) System should not accept
Parallel lines (m1 = m2, c1  c2)
TC2 Check input integer value for (5,5)(7,7) System should accept
Intersection lines (m1  m2 )
TC3 Check input integer value for (10,10) System should not accept
coincident lines (m1 = m2, c1 = c2) (10,10)
Q3. Design equivalence class partitioning test suite for a function that reads a character string
of size less than five characters and displays whether it is a palindrome.
Answer: The equivalence classes are palindromes, non-palindromes, and invalid inputs.
test suite: {abc, aba, abcdef}
Test Case ID Test case Description Test Data Expected Result
TC1 Check input character string ( size abc System should display
< 5 ) palindromes “Non-Palindromes”
TC2 Check input character string ( size aba System should display
< 5 ) non palindromes “Palindromes”
TC3 Check input character string ( size abcdef System should not accept
> 5 ) Invalid
2. Boundary Value Analysis
Q1. For a function that computes the square root of the integer values in the range of 0 and 5000,
determine the boundary value test suite.
Answer: The boundary value based test suite is: {0, -1, 5000, 5001}.
Test Case Test case Description Test Expected Result
ID Data
TC1 Check input integer boundary value = 0 0 System should accept
TC2 Check input integer boundary value < 0 -1 System should not accept
TC3 Check input integer boundary value = 5000 System should accept
5000
TC4 Check input integer boundary value > 5001 System should not accept
5000
Q2. Design boundary value test suite for the function that reads a character string of size less
than five characters.
Boundary Value Test Suite = {“”, “a”, “abcd”, “abcde”, “abcdef”}

Test Case ID Test case Description Test Data Expected Result


TC1 String size is 0 “” System should accept
TC2 String size is 1 “a” System should accept
TC3 String size is 4 “abcd” System should accept
TC4 String size is 5 “abcde” System should not accept
TC4 String size is 6 “abcdef” System should not accept

White-Box Testing
1. Control Flow Graph (CFG)

Q. Consider the following C function calculate the GCD


int computeGCD(x, y) {
1 int x, y;
2 while (x != y){
3 if (x>y) then
4 x=x-y;
5 else y=y-x;
6 }
7 return x;
}

(i) Draw the Control Flow Graph for GCD function.


(ii) Show the GCD function is test by statement coverage testing with the given
test suite.
Test suite : {(x=3, y=3), (x=4, y=3), (x=3, y=4)}
(or)
Show the GCD function is test by branch coverage testing with the given test
suite.
Test suite: {(x=3, y=3), (x=4, y=3), (x=3, y=4)}
(iii) Determine the McCabe’s Cyclomatic complexity of the GCD function.
(iv) Show the GCD function is test by Data Flow-Based testing.
Answer –

(i)
1

false
2
true

3
true false

4 5

Figure – Control Flow Graph for GCD

(ii) Statement coverage testing

Test Test case Description Test Expected Statement Statement


Case ID Data Result Covered Missed
TC1 while (x != y) => false x=3, y=3 x=3 1, 2, 7 3, 4, 5, 6
if (x > y) => false
TC2 while (x != y) => true x=4, y=3 x=1 1, 2, 3, 4, 5
if (x > y) => true 6, 7
TC3 while (x != y) => true x=3, y=4 x=1 1, 2, 3, 5, 4
if (x > y) => false 6, 7

Branch coverage testing

Test Test case Description Test Expected Edge Edge


Case ID Data Result Covered Missed
TC1 while (x != y) => false x=3, y=3 x=3 1-2, 2-7 2-3, 3-4, 3-
if (x > y) => false 5, 4-6, 5-6,
6-7
TC2 while (x != y) => true x=4, y=3 x=1 1-2, 2-3, 3-4, 3-5, 5-6
if (x > y) => true 4-6, 6-7
TC3 while (x != y) => true x=3, y=4 x=1 1-2, 2-3, 3-5, 4-5, 4-6
if (x > y) => false 5-6, 6-7

(iii) Method 1 – V (G) = E – N + 2


E = number of edges
N = number of nodes
E = 9, N = 7
V (G) = 9 – 7 + 2 = 4
Method 2 – V (G) = Total number of non-overlapping bounded areas +1
Total number of non-overlapping bounded areas = 3
V (G) = 3 + 1 = 4

Method 3 – V (G) = Total number of decision and loop statements (N) + 1


Total number of decision and loop statements (N) = 2
V (G) = 2 + 1 = 3

(iv) Variable Defined at node Used at node


x 1 2, 3, 4, 5, 7
y 1 2, 3, 4, 5

Types of Testing
No Testing Definition
1 Unit Testing This testing focus on each component individually,
ensuring that it individual functions properly as a unit,
referred to as testing in the small.
2 Black-Box Testing In this testing, test cases are designed from an
examination of the input/output values only and no
knowledge of design or code is required. It is also
known as functional testing.
3 White-Box Testing In this testing, designing test case requires a thorough
knowledge of the internal structure of a program. It is
also known as structural testing.
4 Multiple Condition In this testing, tests cases are designed to make each
Coverage Testing component of a composite conditional
5 Fault-based Testing In this testing, a program is first tested by using an
initial test suite designed by using various white box
testing strategies. After the initial testing is complete,
this testing can be taken up. This testing is to make a
few arbitrary changes to a program at a time.
6 Mutation Testing In this testing, a program is first tested by using an
initial test suite designed by using various white box
testing strategies. After the initial testing is complete,
this testing can be taken up. This testing is to make a
few arbitrary changes to a program at a time.
7 Regression Testing This testing is taken up after each change to the
system or after each bug fix to ensure that no new bug
has been introduced due to the change or the bug fix.
8 Integration Testing This testing is conduct to check whether the different
modules of a program interface with each other
properly and to detect the errors at the module
interfaces (call parameters) in parameter passing,
when one module invokes the functionality of another
module.
9 Big-Bang Approach to In this testing, all the modules making up a system are
Integration Testing integrated in a single step. Debugging errors reported
during this integration testing are very expensive to
fix.
10 Bottom-up Approach In this testing, first the modules for each subsystem
to Integration Testing are integrated separately and independently. The
primary purpose of this testing is to test whether the
interfaces among various modules making up the
subsystem work satisfactorily. In a pure these testing
no stubs are required, and only test-drivers are
required.
11 Top-down Approach This testing starts with root module in the structure
to Integration Testing chart and one or two subordinate modules of the root
module. This testing requires the use of program stubs
(called Dummy code) to simulate the effect of lower-
level routines.
12 System Testing In this testing, test case are designed to validate a fully
developed system to assure that it meet its
requirements. Theses test cases are therefore designed
solely based on the SRS document.
13 Alpha Testing This testing refers to the system testing carried out by
the test team within the developing organization.
14 Beta Testing This testing is the system testing performed by a select
group of friendly customers.
15 Acceptance Testing This testing is the system testing performed by the
customer to determine whether to accept the delivery
of the system.
16 Performance Testing This testing is the important type of system testing.
This testing is carried out to check whether the system
meets the nonfunctional requirements identified in the
SRS document.
17 Stress Testing This testing is also known as endurance testing. In this
testing, test cases are designed to impose a range of
abnormal and even illegal input conditions.
18 Volume Testing This testing check whether the data structures have
been designed to successfully handle extraordinary
situations.
19 Configuration Testing This testing is used to test system behavior in various
hardware and software configurations specified in the
requirements.
20 Compatibility Testing This testing is required when the system interfaces
with external systems (e.g., databases, servers, etc.).
This testing aim to check whether the interfaces with
the external systems are performing as required.
21 Documentation This testing checked whether the required user
Testing manual, maintenance manuals, and technical manuals
exist and are consistent.
22 Usability Testing This testing concerns checking the user interface to
see if it meets all user requirements concerning the
user interface. During this testing, the display screens,
messages, report formats, and other aspects relating to
the user interface requirements are tested.
23 Smoke Testing This testing is performed before a fully integrated
system is accepted for system testing. This testing is
done to check whether at least the main functionalities
of the software are working properly.
24 Portability Testing This testing means to test the ability of the software
product and its components for its effectiveness on
one platform to other irrespective of the environment.
25 Path Coverage Testing This testing strategy calls for traversing each linearly
independent path through a program at least one.

You might also like