Subject Name: Software Engineering

Unit No:6 Unit Name: Software Testing and

Maintenance

Faculty Name : Ms. Dhanashri A. Bhosale

Index

Lecture 34 –Basic Concept and Terminology 3

Lecture 35– White Box Testing 11

Lecture 36 – Black Box Testing 16

2
Unit No:6 Unit Name: Software Testing

Lecture No: 34
Basic Concept and
Terminology
Typical Project Blues…

4 Software Testing
Introduction

Software Testing is the process used to identify the correctness,

completeness and quality of developed computer software.

It is the process of executing a program/application under positive and

negative conditions by manual or automated means. It checks for the :-
 Specification

 Functionality

 Performance

5 Software Testing
Need of Testing

 Uncover as many as errors (or bugs) as possible in a given product.

 Demonstrate a given software product matching its requirement
specifications.
 Validate the quality of a software testing using the minimum cost and efforts.
 Generate high quality test cases, perform effective tests, and issue correct
and helpful problem reports.

6 Software Testing
Software Tester

7 Software Testing
 Error, Bug, Fault & Failure

 Error : It is a human action that produces the incorrect result that produces a

fault.

 Bug : The presence of error at the time of execution of the software.

 Fault : State of software caused by an error.

 Failure : Deviation of the software from its expected result. It is an event.

8 Software Testing
Testing Methodologies

Black box testing

 No knowledge of internal program design or code required.
 Tests are based on requirements and functionality.

White box testing

 Knowledge of the internal program design and code required.
 Tests are based on coverage of code statements, branches, paths,
conditions.

9 Software Testing
Steps in Testing

Testing of software is actually a series of 4

steps.

1. The first step individually tests each unit

of the software, ensuring that it
functions properly as a unit. Hence, the
name unit testing.

2. Next, components must be assembled

or integrated to form the complete
software package. Integration testing
addresses these issues.

10 Software Testing
Steps in Testing

3. After the software has been integrated

(constructed), a set of high-order tests

are conducted.. Validation testing

provides final assurance that software

meets all functional, behavioral, and

performance requirements.

11 Software Testing
Steps in Testing

4. The last high-order testing step falls

outside the boundary of software
engineering and into the broader context
of computer system engineering.

Software, once validated, must be

combined with other system elements
(e.g., hardware, people, databases).
System testing verifies that all elements
mesh properly and that overall system
function/performance is achieved.

12 Software Testing
Verification and Validation

The program being developed must be checked to ensure

that it meets its specification and delivers the functionality
expected by the people paying for the software.

 Verification
• Are you building the product right?
• Software must conform to its specification

 Validation
• Are you building the right product?
• Software should do what the user really requires

13 Software Testing
Verification and Validation Goals

• Establish confidence that the software system is ‘fit for its intended purpose’.
• Level of required confidence depends upon
System purpose

User expectations
Marketing environment

• Deciding how much effort should be spent on the V & V process.

14 Software Testing
 Static and Dynamic Verification and Validation

Static
verification

Requirements High-level Formal Detailed

specification Program
specification design design

Dynamic
Prototype
validation

Software Inspection(Static)
Analyse and check the requirements document, design diagrams and the program
source code.
You can use inspections at all stages of the process.

15 Software Testing
 Static and Dynamic Verification and Validation

Static
verification

Requirements High-level Formal Detailed

specification Program
specification design design

Dynamic
Prototype
validation

Software Testing(Dynamic)-
• Involves running an implementation of the software with test data.
• You examine the outputs of the software and its operational behavior to check that it
is performing as required.

16 Software Testing
Type of Testing

• Unit Testing

• Integration Testing

• Validation Testing

• System Testing

17 Software Testing
 Unit Testing

• Objectives: The primary goal of unit testing is to take the smallest module of testable

software, and running it in isolation by using prepared test cases and comparing with

the actual result to test the interfaces between modules.

• When  After modules are coded

• Who  Developer/programmer

• Methods  White Box testing techniques

18 Software Testing
What are Stubs, Drivers ?

• A stub is a computer program which is used as a substitute for the body of a

software module or a dummy module which simulates the function of a
module called by a given module under test.
• Driver a module which transmits test cases in the form of input arguments to
the given module under test and either prints or interprets the results produced
by it.

19 Software Testing
Integration Testing

• Objectives
To technically verify proper interfacing between modules, and within
sub-systems that satisfy functional requirement.
• When  After modules are unit tested
• Who  Developers/Programmer
• Methods  White Box techniques
Black Box techniques

20 Software Testing
 Types Of Integration Testing

» Top-Down Integration testing

» Bottom-Up Integration testing

21 Software Testing
Top Down Integration Testing

Stub
Stub A

stub
Stub
B

B Stub
Stub
C

Stub

22 Software Testing
Bottom Up Integration testing

Test Test Test

Drivers Drivers Drivers

Level N Level N Level N

Test Test
Drivers Drivers

Level N-1 Level N-1

23 Software Testing
Regression Testing

• Objectives

o It is used to checks faults, defects propagated to other modules by changes

made to existing program.

o This testing is used to reduce the side effects of changes.

o Testing is done by re-executing the previous versions of the application.

• Who

Programmers or independent testers

24 Software Testing
Validation Testing

• Objectives: To verify that the system meets the user requirements. It is the

system testing performed by the customer him/herself after the product

delivery to determine whether to accept or reject the delivered product.

• When  After System Testing

• Who  Users / End Users

• Methods  Black Box techniques

25 Software Testing
Black Box Testing

• In the black-box testing approach, test cases are designed using only the

functional specification of the software, i.e. without any knowledge of the

internal structure of the software.

• It explains the process of giving the input to the system and checking the

output, without considering how the system generates the output. It is also

known as Behavioral Testing.

• It attempts to find error in the external behavior of the code.

26 Software Testing
Alpha Testing

• It is a testing in which the version of complete software is tested by the

customer under the supervision of developer.

• This testing is performed at the developer's site in a control environment

under the guidance of a developer.

27 Software Testing
Beta Testing

• It is a testing in which software is tested by a customer without the developer

being present.

• This testing is performing at the customer's site.

• Customer records the problems and reports it to the developer then the

developer makes appropriate modifications.

28 Software Testing
System Testing

• Objectives: The goal of system testing is not to find out faults but to

demonstrate performance.

• What  The system testing is actually a series of different tests , primary

purpose of which is to fully exercise the system. All work to verify that all system

elements have been properly integrated and perform allocated functions.

• When  After Validation Testing

• Who  Development Team

29 Software Testing
Unit No:6 Unit Name: Software Testing

Lecture No: 35
White Box Testing – Path
Testing
 What is it?

• Testing the internal structure of the software

• Understand the code and the code will set you
free.
• White-box testing is testing that takes into account
the internal mechanism of a system or component
• It’s also known as Structural testing, clear box
testing and glass box testing

31 Software Testing
White Box Testing

Test data

Tests Derives

Component Test
code outputs

32 Software Testing
Techniques

• Statement coverage
• Loop testing
• Path testing
• Branch testing

33 Software Testing
 Statement Coverage

• 100% method coverage: All void foo (int a, b, c, d, e)

{
methods in all classes are if (a == 0)
called. {
return;
• 100% statement coverage: }
All statements in a method int x = 0;
if ((a==b) OR ((c==d) AND bug(a) ))
are executed. {
x =1;
}
e = 1/x;
}

34 Software Testing
 Path testing

• Make sure all the paths are covered.

• Determine the paths

• Construct a logic flow chart

35 Software Testing
Path testing: Determine Paths

FindMean (FILE ScoreFile)

{ float SumOfScores = 0.0;
int NumberOfScores = 0;
1
float Mean=0.0; float Score;
Read(ScoreFile, Score);
2 while (! EOF(ScoreFile) {
3 if (Score > 0.0 ) {
SumOfScores = SumOfScores + Score;
4
NumberOfScores++;
}
5
Read(ScoreFile, Score); 6
}
/* Compute the mean and print the result */
7 if (NumberOfScores > 0) {
Mean = SumOfScores / NumberOfScores;
printf(“ The mean score is %f\n”, Mean); 8
} else
printf (“No scores found in file\n”); 9
36 }
Software Testing
Path testing: Logic flow diagram

Start

F
2
T
3
T F
4 5

7
T F
8 9

Exit

37 Software Testing
Control Graph Component

• A control flow graph (or simply, flow graph) is a directed graph which
represents the control structure of a program or module. A control flow graph
(V, E) has V number of nodes/vertices and E number of edges in it. A control
graph can also have :
•
Junction Node – a node with more than one arrow entering it.
• Decision Node – a node with more then one arrow leaving it.
• Region – area bounded by edges and nodes (area outside the graph is also
counted as a region.).

38 Software Testing
Components

39 Software Testing
Notations for constructing flow graph : Sequence Statements

40 Software Testing
Notations for constructing flow graph : If Else

41 Software Testing
Notations for constructing flow graph : Do While / while

42 Software Testing
Notations for constructing flow graph : Switch - Case

43 Software Testing
 Cyclomatic Complexity

• The cyclomatic complexity V(G) is said to be a measure of the logical complexity of a

program. It can be calculated using three different formulae :

1. Formula based on edges and nodes :

V(G) = e - n + 2*P

e is number of edges,
n is number of vertices,
P is number of connected components.

For example, consider first graph given above,

Example : e = 4, n = 4 and p = 1

So, Cyclomatic complexity V(G) = 4 - 4 + 2 * 1 = 2

44 Software Testing
 Cyclomatic Complexity

2. Formula based on Decision Nodes

V(G) = d + P

where,
d is number of decision nodes,
P is number of connected nodes.
For example, consider first graph given above,

where, d = 1 and p = 1 So, Cyclomatic Complexity V(G) = 1 + 1 = 2

45 Software Testing
 Cyclomatic Complexity

3. Formula based on Regions :

V(G) = number of regions in the graph

Cyclomatic complexity V(G) = 1 (for Region 1) + 1 (for Region 2) = 2

46 Software Testing
Cyclomatic Complexity

1. Formula based on edges and

nodes :
V(G) = e - n + 2*P
e is number of edges,
n is number of vertices,
P is number of connected components.
For example, consider first graph given
above,
Example : e = 8, n = 7 and p = 1
8–7+2*1=3

47 Software Testing
Cyclomatic Complexity

2. Based on Decision Nodes

V(G) = d + P

where,
d is number of decision nodes,
P is number of connected nodes.

where, d = 2 and p = 1

So, Cyclomatic Complexity

V(G) = 2 + 1 = 2

48 Software Testing
Cyclomatic Complexity

3. Formula based on Regions :

V(G) = number of regions in the

graph

Cyclomatic complexity V(G) = 1

(for Region 1) + 1 (for Region 2) + 1
(for Region 3) = 3

49 Software Testing
 Loop testing

• Test the ‘for’ and ‘while’ loops in the code.

• Look for exceptions of infinite loop.

• Cause execution of loop to be skipped.

• Loop to be executed exactly once.

• Loop to be executed more than once

50 Software Testing
 Branch testing

• Also known as Conditional Testing

• Make sure that each possible outcome from a condition is tested at least once.

if (i=true)

printf (“I am true”)

else
printf (“I am false”)

Possible Testcases are

1. i=true;

2. i=false

51 Software Testing
Unit No: Unit Name: Software Testing

Lecture No:36
Black Box Testing – BVA
Integration
Black-Box Testing

• Black Box Testing is testing technique having no knowledge of the internal

functionality/structure of the system
• Synonyms for Black-Box are Behavioral, Functional, Opaque-Box, Closed-Box
etc.

53 Software Testing
Black Box Testing contd…

• Black-box Testing focuses on testing the function of the program or application

against its specification
• Determines whether combinations of inputs and operations produce expected
results
• When black box testing is applied to software engineering, the tester would only
know the "legal" inputs and what the expected outputs should be, but not how
the program actually arrives at those outputs

54 Software Testing
Focus of Black-Box Testing

• In this technique, we do not use the code to determine a test suite; rather,

knowing the problem that we're trying to solve, we come up with four types of

test data:

• Easy-to-compute data

• Typical data

• Boundary / extreme data

• Bogus data

55 Software Testing
 Black-Box Testing Techniques

• Equivalence Partitioning

• Boundary Value Analysis

• Error Guessing

• Cause-Effect Graphing

56 Software Testing
Equivalence Partitioning

• An equivalence class is a subset of data that is representative of a larger class

• Equivalence partitioning is a technique for testing equivalence classes rather

than undertaking exhaustive testing of each value of the larger class

• For example, a program which edits credit limits within a given range
($10,000 - $15,000) would have three equivalence classes
– < $10,000 (invalid)

– Between $10,000 and $15,000 (valid)

– > $15,000 (invalid)

57 Software Testing
 Boundary Analysis

• This technique consists of developing test cases and data that focus on the input and

output boundaries of a given function

• In the same credit limit example, boundary analysis would test.

– Low boundary -/+ one ($9,999 and $10,001)

– On the boundary ($10,000 and $15,000)

– Upper boundary -/+ one ($14,999 and $15,001)

58 Software Testing
Error Guessing

• Test cases can be developed based upon the intuition and experience of the
tester
• For example, where one of the inputs is the date, a tester may try February 29,
2001

59 Software Testing
Advantages of Black-Box Testing

• More effective on larger units of code than glass box testing

• Tester needs no knowledge of implementation, including specific
programming languages
• Tester and programmer are independent of each other
• Tests are done from a user's point of view
• Will help to expose any ambiguities or inconsistencies in the specifications
• Test cases can be designed as soon as the specifications are complete

62 Software Testing
Disadvantages of Black-Box Testing

• Only a small number of possible inputs can actually be tested, to test every

possible input stream would take nearly forever

• Without clear and concise specifications, test cases are hard to design

• There may be unnecessary repetition of test inputs if the tester is not informed

of test cases the programmer has already tried

63 Software Testing
Unit No:6 Unit Name: Software Testing

Lecture No:
Validation and System Testing
Validation

• A method of checking data as it is entered, to reduce the number of errors.

• A Validation Rule is what the data is tested against. If the data fails to meet the criteria an
error message will appear.

65 Software Testing
Validation Types

• Presence check – has the data been entered

• Range check – is the data within a certain range of letters or numbers? E.g. 1-99
• Format check – does the data follow a correct pattern e.g. DOB 18/02/1981
• Length check – Has the correct number of characters been entered?
• List/Lookup check – Is the data within the list of acceptable values?
• Cross Field check – Checks two fields are entered correctly e.g. if a particular phone is
available on only one network it will be rejected if a different network is selected
• Check digit – Make sure longer numbers are entered correctly e.g. barcode (last digit
checks via complex calculation that the previous digits are correct)

66
Validation Continued

• Validation reduces data entry errors but can not remove

them completely

• Example:
– 18/02/1991 might be entered instead of 18/02/1981
– The above meets the validation rule (format) but is obviously wrong
which might mean that the system rejects the customers application
(e.g. would be to young to get a phone contract)

• To avoid this we use verification

67 Software Testing
System Testing

• Entire system is tested as per the

requirements.
• System testing falls within the scope
of black box testing.
• System testing is performed on the
entire system in the context of a
Functional Requirements and/or a
System Requirement Specification
(SRS).

68 Software Testing
1. Recovery Testing

 Forces the software to fail in different conditions and verifies that recovery is properly
performed.
 Many computer system recover from faults and resume processing within a prespecified
time.
 If recovery requires human intervention, the Mean Time to Repair (MTTR) is evaluated to
determine whether it is within acceptable limits.

69 Software Testing
2. Security Testing

 Attempts to verify that protection mechanisms built into a

system.
 Any computer based system can manages sensitive
information or causes actions that can improperly harm
individuals is a target for illegal penetration.
 Ex: Hackers
 Legal Penetration : authorized system designer
 Illegal Penetration : Hacker

70 Software Testing
 3. Stress Testing

• Also known as “Endurance (patience) Testing”.

• Evaluate system performance when it is stressed for short
period of time.
• Check the program with abnormal situations.
Stress testing situations:
• Generate 10 interrupt per second
• Increase the input rate
• Request maximum resource

71 Software Testing
4. Performance Testing

• Check whether the system meets the non functional

requirements identified in the SRS.
• Considered as “ Black Box testing”
• Test the Run Time Performance of software
• Also coupled with stress testing.
• Required both hardware and software instrumentation to do
this testing.

72 Software Testing
Thank You