SlideShare a Scribd company logo
4
Most read
14
Most read
15
Most read
Software Engineering Principles
Ajit K Nayak, Ph.D.
ajitnayak@soauniversity.ac.in
Software Testing
Acknowledgements
• Slides of Prof. Rajib Mall, IIT, KGP
Unit Testing
• Black-Box Testing
– Two main approaches to design black box test
cases:
– Equivalence class partitioning
– Boundary value analysis
• White-Box Texting
– Designing white-box test cases:
– requires knowledge about the internal structure of
software.
– white-box testing is also called structural testing.
Equivalence Partitioning
• The input domain data is divided into different equivalence
data classes.
– used to reduce the total number of test cases to a finite set of
testable test cases, still covering maximum requirements.
• Example: an input box accepting numbers from 1 to 1000 then
there is no use in writing thousand test cases for all 1000 valid
input numbers plus other test cases for invalid data.
• test cases can be divided into three sets of input data called as
classes.
– 1) One input data class with all valid inputs. Pick a single value
from range 1 to 1000 as a valid test case. If you select other
values between 1 and 1000 then result is going to be same. So
one test case for valid input data should be sufficient.
– 2) Input data class with all values below lower limit. I.e. any
value below 1, as a invalid input data test case.
– 3) Input data with any value greater than 1000 to represent
third invalid input class.
Boundary Value Analysis
• Complements equivalence partitioning (typically
combined)
• In practice, more errors found at boundaries of
equivalence classes than within the classes
• Divide input domain into equivalence classes
• Also divide output domain into equivalence classes
• Need to determine inputs to cover each output
equivalence class
• Again one test case per equivalence class
White-box testing : Statement coverage
• Design test cases so that every statement in a
program is executed at least once.
• Statement coverage criterion
– An error in a program can not be discovered unless
the part of the program containing the error is
executed.
– Observing that a statement behaves properly for
one input value does not guarantee that it will
behave correctly for all input values.
Example: Euclid's GCD Algorithm
int f1(int x, int y){
1 while (x != y){
2 if (x>y) then
3 x=x-y;
4 else
5 y=y-x;
5 }
6 return x;
}
• By choosing the
test set
• {(x=3,y=3),
• (x=4,y=3),
• (x=3,y=4)}
• all statements are
executed at least
once.
White-box testing : Branch Coverage
• Test cases are designed such that:
– different branch conditions given true and false
values in turn.
• Branch testing guarantees statement coverage:
– A stronger testing compared to the statement
coverage-based testing.
– i.e. Test cases are a superset of a weaker testing:
• discovers at least as many errors as a weaker testing
• contains at least as many significant test cases as a
weaker test.
Example: Euclid's GCD Algorithm
int f1(int x, int y){
1 while (x != y){
2 if (x>y) then
3 x=x-y;
4 else
5 y=y-x;
5 }
6 return x;
}
• Test cases for
branch coverage
can be:
• {(x=3,y=3),
• (x=3,y=2),
• (x=4,y=3),
• (x=3,y=4)}
White-box Testing: Condition Coverage
• Test cases are designed such that:
– each component of a composite conditional
expression
– given both true and false values.
• Consider the conditional expression
– ((c1.and.c2).or.c3):
– Each of c1, c2, and c3 are exercised at least
once, i.e. given true and false values.
• It require 2n (the number of component conditions)
test cases.
– practical only if n is small
White-box testing : Path Coverage
• Design test cases such that:
– all linearly independent paths in the program are
executed at least once.
• Defined in terms of control flow graph (CFG) of a
program.
• A control flow graph (CFG) describes:
– the sequence in which different instructions of a
program get executed.
– the way control flows through the program.
Drawing a CFG - I
• Number all the statements of a program.
– Numbered statements represent nodes of the
control flow graph.
• An edge from one node to another node exists:
– if execution of the statement representing the first
node can result in transfer of control to the other
node.
• Sequence:
– 1 a=5;
– 2 b=a*b-1;
1
2
Drawing a CFG - II
• Selection:
1. if(a>b) then
2. c=3;
3. else
4. c=5;
5. c=c*c;
• Iteration:
• 1 while(a>b){
• 2 b=b*a;
• 3 b=b-1;}
• 4 c=b+d;
1
2 3
4
1
2
3
4
Example
int f1(int x, int y){
1 while (x != y){
2 if (x>y) then
3 x=x-y;
4 else
5 y=y-x;
5 }
6 return x;
}
1
2
3 4
5
6
Path
• A path through a program:
– a node and edge sequence from the starting node
to a terminal node of the control flow graph.
• There may be several terminal nodes for program.
• Any path through the program:
• introducing at least one new node that is not included
in any other independent paths.
• McCabe's cyclomatic metric is an upper bound:
– for the number of linearly independent paths of a
program
• Provides a practical way of determining the maximum
number of linearly independent paths in a program.
Cyclomatic Complexity - I
• Given a control flow graph G, cyclomatic complexity
V(G) = E-N+2
– N is the number of nodes in G
– E is the number of edges in G
• Cyclomatic complexity = 7-6+2 = 3. 1
2
3 4
5
6
• Another way of computing
cyclomatic complexity:
• determine number of bounded
areas in the graph
• V(G) = Total number of bounded
areas + 1
• Example: the number of bounded
areas is 2.
• Cyclomatic complexity = 2+1=3.
Cyclomatic Complexity - II
• The cyclomatic complexity of a program provides a
lower bound on the number of test cases to be
designed
– to guarantee coverage of all linearly independent
paths.
– does not make it any easier to derive the test cases,
– only gives an indication of the minimum number of
test cases required.
Path Testing
• Draw control flow graph.
• Determine V(G).
• Determine the set of linearly
independent paths.
• Prepare test cases:
• to force execution along each
path.
• Number of independent paths: 3
• 1,6 test case (x=1, y=1)
• 1,2,3,5,1,6 test case(x=1, y=2)
• 1,2,4,5,1,6 test case(x=2, y=1)
1
2
3 4
5
6
Cyclomatic Complexity - III
• Relationship exists between
– McCabe's metric & the number of errors existing in
the code,
– the time required to find and correct the errors.
• also indicates the psychological complexity of a
program.
• i.e. difficulty level of understanding the program.
• Therefore, limit cyclomatic complexity of modules to
some reasonable value. (10 or so)
Automated Testing Tools
• Mercury Interactive
• Quick Test Professional: Regression testing
• WinRunner: UI testing
• IBM Rational
• Rational Robot
• Functional Tester
• Borland
• Silk Test
• Compuware
• QA Run
• AutomatedQA
• TestComplete
Thank You

More Related Content

PPTX
Loop optimization
PPTX
Deterministic context free grammars &non-deterministic
PPTX
8 queens problem using back tracking
PPTX
Shortest job first Scheduling (SJF)
PPTX
Graph coloring problem(DAA).pptx
PPTX
Applications Of Computer Graphics
PDF
Introduction To Autumata Theory
Loop optimization
Deterministic context free grammars &non-deterministic
8 queens problem using back tracking
Shortest job first Scheduling (SJF)
Graph coloring problem(DAA).pptx
Applications Of Computer Graphics
Introduction To Autumata Theory

What's hot (20)

PPT
Finite automata
PPTX
Bootstrapping in Compiler
PPTX
Finite automata-for-lexical-analysis
PPTX
unit-4-dynamic programming
PPTX
Syntax Analysis in Compiler Design
PPTX
Graph coloring using backtracking
PPSX
Fuzzy expert system
PPTX
Context free grammar
PDF
UNIT-V.pdf daa unit material 5 th unit ppt
PDF
Daa notes 1
PPT
Fuzzy logic ppt
PDF
State Space Search in ai
PPTX
All pair shortest path
PPTX
Top down and botttom up Parsing
PPTX
Greedy algorithms
PPTX
Context free grammar
PDF
Closure properties of context free grammar
PPTX
Assembly Language
PPTX
Lecture 06 production system
PPTX
Performance analysis and randamized agoritham
Finite automata
Bootstrapping in Compiler
Finite automata-for-lexical-analysis
unit-4-dynamic programming
Syntax Analysis in Compiler Design
Graph coloring using backtracking
Fuzzy expert system
Context free grammar
UNIT-V.pdf daa unit material 5 th unit ppt
Daa notes 1
Fuzzy logic ppt
State Space Search in ai
All pair shortest path
Top down and botttom up Parsing
Greedy algorithms
Context free grammar
Closure properties of context free grammar
Assembly Language
Lecture 06 production system
Performance analysis and randamized agoritham
Ad

Viewers also liked (20)

PDF
Software Engineering : OOAD using UML
PDF
Software Engineering :Behavioral Modelling - II State diagram
PDF
Software Engineering :Behavioral Modelling - I Sequence diagram
PDF
Software Engineering :UML class diagrams
PDF
Software Engineering : Requirement Analysis & Specification
PDF
How to Present Data in PowerPoint
PPT
Regression analysis
PPT
Multiple regression presentation
ODP
Multiple linear regression
PPT
Regression analysis ppt
PPT
Uml Omg Fundamental Certification 1
PDF
Computer Networks Module II
PDF
Introduction to database-Normalisation
PDF
Introduction to database-ER Model
PDF
Software Engineering : Process Models
PDF
Computer Fundamentals & Intro to C Programming module i
PPTX
I BELIEVE I CAN FLY ( version française)
PPT
Uml Omg Fundamental Certification 5
PPTX
I BELIEVE I CAN FLY
PPTX
The badguy summary
Software Engineering : OOAD using UML
Software Engineering :Behavioral Modelling - II State diagram
Software Engineering :Behavioral Modelling - I Sequence diagram
Software Engineering :UML class diagrams
Software Engineering : Requirement Analysis & Specification
How to Present Data in PowerPoint
Regression analysis
Multiple regression presentation
Multiple linear regression
Regression analysis ppt
Uml Omg Fundamental Certification 1
Computer Networks Module II
Introduction to database-Normalisation
Introduction to database-ER Model
Software Engineering : Process Models
Computer Fundamentals & Intro to C Programming module i
I BELIEVE I CAN FLY ( version française)
Uml Omg Fundamental Certification 5
I BELIEVE I CAN FLY
The badguy summary
Ad

Similar to Software Engineering : Software testing (20)

PPT
11 whiteboxtesting
PPT
2. Lect 27 to 28 White box s/w testing.ppt
PPT
Seii unit6 software-testing-techniques
PPT
Chapter 14 software testing techniques
PPT
Newsoftware testing-techniques-141114004511-conversion-gate01
PPT
white box testing.ppt
PPT
CS8494 SOFTWARE ENGINEERING Unit-4
PPT
1414_lecturueueueueuueueeueueueuusuee_7.ppt
PPT
testing(2).pptjjsieieo2i33kejjskskosowwiwk
PPT
New software testing-techniques
PPSX
White Box testing by Pankaj Thakur, NITTTR Chandigarh
PPS
Testing techniques
PPT
Testing foundations
PPT
SOFTWARE ENGINEERING unit4-2 CLASS notes in pptx 2nd year
PPTX
Software engineering module 4 notes for btech and mca
PPT
software quality Assurance-lecture26.ppt
PPT
Test Techniques
PPT
Software Testing Techniques
PPT
Software Testing Tecniques
PPT
Qat09 presentations dxw07u
11 whiteboxtesting
2. Lect 27 to 28 White box s/w testing.ppt
Seii unit6 software-testing-techniques
Chapter 14 software testing techniques
Newsoftware testing-techniques-141114004511-conversion-gate01
white box testing.ppt
CS8494 SOFTWARE ENGINEERING Unit-4
1414_lecturueueueueuueueeueueueuusuee_7.ppt
testing(2).pptjjsieieo2i33kejjskskosowwiwk
New software testing-techniques
White Box testing by Pankaj Thakur, NITTTR Chandigarh
Testing techniques
Testing foundations
SOFTWARE ENGINEERING unit4-2 CLASS notes in pptx 2nd year
Software engineering module 4 notes for btech and mca
software quality Assurance-lecture26.ppt
Test Techniques
Software Testing Techniques
Software Testing Tecniques
Qat09 presentations dxw07u

More from Ajit Nayak (18)

PDF
Software Engineering an Introduction
PDF
Database Programming using SQL
PDF
Ns2: Introduction - Part I
PDF
Ns2: OTCL - PArt II
PDF
NS2: AWK and GNUplot - PArt III
PDF
Socket programming using C
PDF
Object Oriented Analysis Design using UML
PDF
Parallel programming using MPI
PDF
Operating Systems Part III-Memory Management
PDF
Operating Systems Part I-Basics
PDF
Operating Systems Part II-Process Scheduling, Synchronisation & Deadlock
PDF
Introduction to database-Transaction Concurrency and Recovery
PDF
Introduction to database-Formal Query language and Relational calculus
PDF
Computer Networks Module III
PDF
Computer Networks Module I
PDF
Object Oriented Programming using C++ Part III
PDF
Object Oriented Programming using C++ Part I
PDF
Object Oriented Programming using C++ Part II
Software Engineering an Introduction
Database Programming using SQL
Ns2: Introduction - Part I
Ns2: OTCL - PArt II
NS2: AWK and GNUplot - PArt III
Socket programming using C
Object Oriented Analysis Design using UML
Parallel programming using MPI
Operating Systems Part III-Memory Management
Operating Systems Part I-Basics
Operating Systems Part II-Process Scheduling, Synchronisation & Deadlock
Introduction to database-Transaction Concurrency and Recovery
Introduction to database-Formal Query language and Relational calculus
Computer Networks Module III
Computer Networks Module I
Object Oriented Programming using C++ Part III
Object Oriented Programming using C++ Part I
Object Oriented Programming using C++ Part II

Recently uploaded (20)

PDF
Operating System & Kernel Study Guide-1 - converted.pdf
PDF
PPT on Performance Review to get promotions
PDF
Digital Logic Computer Design lecture notes
PDF
Evaluating the Democratization of the Turkish Armed Forces from a Normative P...
PPTX
Engineering Ethics, Safety and Environment [Autosaved] (1).pptx
PPTX
web development for engineering and engineering
DOCX
573137875-Attendance-Management-System-original
PPTX
Internet of Things (IOT) - A guide to understanding
PDF
Structs to JSON How Go Powers REST APIs.pdf
PDF
Well-logging-methods_new................
PPTX
Recipes for Real Time Voice AI WebRTC, SLMs and Open Source Software.pptx
PPTX
UNIT-1 - COAL BASED THERMAL POWER PLANTS
PPTX
CYBER-CRIMES AND SECURITY A guide to understanding
PDF
keyrequirementskkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
PPTX
Infosys Presentation by1.Riyan Bagwan 2.Samadhan Naiknavare 3.Gaurav Shinde 4...
PDF
composite construction of structures.pdf
PPTX
FINAL REVIEW FOR COPD DIANOSIS FOR PULMONARY DISEASE.pptx
PDF
BMEC211 - INTRODUCTION TO MECHATRONICS-1.pdf
PPTX
MCN 401 KTU-2019-PPE KITS-MODULE 2.pptx
PDF
Mitigating Risks through Effective Management for Enhancing Organizational Pe...
Operating System & Kernel Study Guide-1 - converted.pdf
PPT on Performance Review to get promotions
Digital Logic Computer Design lecture notes
Evaluating the Democratization of the Turkish Armed Forces from a Normative P...
Engineering Ethics, Safety and Environment [Autosaved] (1).pptx
web development for engineering and engineering
573137875-Attendance-Management-System-original
Internet of Things (IOT) - A guide to understanding
Structs to JSON How Go Powers REST APIs.pdf
Well-logging-methods_new................
Recipes for Real Time Voice AI WebRTC, SLMs and Open Source Software.pptx
UNIT-1 - COAL BASED THERMAL POWER PLANTS
CYBER-CRIMES AND SECURITY A guide to understanding
keyrequirementskkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
Infosys Presentation by1.Riyan Bagwan 2.Samadhan Naiknavare 3.Gaurav Shinde 4...
composite construction of structures.pdf
FINAL REVIEW FOR COPD DIANOSIS FOR PULMONARY DISEASE.pptx
BMEC211 - INTRODUCTION TO MECHATRONICS-1.pdf
MCN 401 KTU-2019-PPE KITS-MODULE 2.pptx
Mitigating Risks through Effective Management for Enhancing Organizational Pe...

Software Engineering : Software testing

  • 1. Software Engineering Principles Ajit K Nayak, Ph.D. ajitnayak@soauniversity.ac.in Software Testing
  • 2. Acknowledgements • Slides of Prof. Rajib Mall, IIT, KGP
  • 3. Unit Testing • Black-Box Testing – Two main approaches to design black box test cases: – Equivalence class partitioning – Boundary value analysis • White-Box Texting – Designing white-box test cases: – requires knowledge about the internal structure of software. – white-box testing is also called structural testing.
  • 4. Equivalence Partitioning • The input domain data is divided into different equivalence data classes. – used to reduce the total number of test cases to a finite set of testable test cases, still covering maximum requirements. • Example: an input box accepting numbers from 1 to 1000 then there is no use in writing thousand test cases for all 1000 valid input numbers plus other test cases for invalid data. • test cases can be divided into three sets of input data called as classes. – 1) One input data class with all valid inputs. Pick a single value from range 1 to 1000 as a valid test case. If you select other values between 1 and 1000 then result is going to be same. So one test case for valid input data should be sufficient. – 2) Input data class with all values below lower limit. I.e. any value below 1, as a invalid input data test case. – 3) Input data with any value greater than 1000 to represent third invalid input class.
  • 5. Boundary Value Analysis • Complements equivalence partitioning (typically combined) • In practice, more errors found at boundaries of equivalence classes than within the classes • Divide input domain into equivalence classes • Also divide output domain into equivalence classes • Need to determine inputs to cover each output equivalence class • Again one test case per equivalence class
  • 6. White-box testing : Statement coverage • Design test cases so that every statement in a program is executed at least once. • Statement coverage criterion – An error in a program can not be discovered unless the part of the program containing the error is executed. – Observing that a statement behaves properly for one input value does not guarantee that it will behave correctly for all input values.
  • 7. Example: Euclid's GCD Algorithm int f1(int x, int y){ 1 while (x != y){ 2 if (x>y) then 3 x=x-y; 4 else 5 y=y-x; 5 } 6 return x; } • By choosing the test set • {(x=3,y=3), • (x=4,y=3), • (x=3,y=4)} • all statements are executed at least once.
  • 8. White-box testing : Branch Coverage • Test cases are designed such that: – different branch conditions given true and false values in turn. • Branch testing guarantees statement coverage: – A stronger testing compared to the statement coverage-based testing. – i.e. Test cases are a superset of a weaker testing: • discovers at least as many errors as a weaker testing • contains at least as many significant test cases as a weaker test.
  • 9. Example: Euclid's GCD Algorithm int f1(int x, int y){ 1 while (x != y){ 2 if (x>y) then 3 x=x-y; 4 else 5 y=y-x; 5 } 6 return x; } • Test cases for branch coverage can be: • {(x=3,y=3), • (x=3,y=2), • (x=4,y=3), • (x=3,y=4)}
  • 10. White-box Testing: Condition Coverage • Test cases are designed such that: – each component of a composite conditional expression – given both true and false values. • Consider the conditional expression – ((c1.and.c2).or.c3): – Each of c1, c2, and c3 are exercised at least once, i.e. given true and false values. • It require 2n (the number of component conditions) test cases. – practical only if n is small
  • 11. White-box testing : Path Coverage • Design test cases such that: – all linearly independent paths in the program are executed at least once. • Defined in terms of control flow graph (CFG) of a program. • A control flow graph (CFG) describes: – the sequence in which different instructions of a program get executed. – the way control flows through the program.
  • 12. Drawing a CFG - I • Number all the statements of a program. – Numbered statements represent nodes of the control flow graph. • An edge from one node to another node exists: – if execution of the statement representing the first node can result in transfer of control to the other node. • Sequence: – 1 a=5; – 2 b=a*b-1; 1 2
  • 13. Drawing a CFG - II • Selection: 1. if(a>b) then 2. c=3; 3. else 4. c=5; 5. c=c*c; • Iteration: • 1 while(a>b){ • 2 b=b*a; • 3 b=b-1;} • 4 c=b+d; 1 2 3 4 1 2 3 4
  • 14. Example int f1(int x, int y){ 1 while (x != y){ 2 if (x>y) then 3 x=x-y; 4 else 5 y=y-x; 5 } 6 return x; } 1 2 3 4 5 6
  • 15. Path • A path through a program: – a node and edge sequence from the starting node to a terminal node of the control flow graph. • There may be several terminal nodes for program. • Any path through the program: • introducing at least one new node that is not included in any other independent paths. • McCabe's cyclomatic metric is an upper bound: – for the number of linearly independent paths of a program • Provides a practical way of determining the maximum number of linearly independent paths in a program.
  • 16. Cyclomatic Complexity - I • Given a control flow graph G, cyclomatic complexity V(G) = E-N+2 – N is the number of nodes in G – E is the number of edges in G • Cyclomatic complexity = 7-6+2 = 3. 1 2 3 4 5 6 • Another way of computing cyclomatic complexity: • determine number of bounded areas in the graph • V(G) = Total number of bounded areas + 1 • Example: the number of bounded areas is 2. • Cyclomatic complexity = 2+1=3.
  • 17. Cyclomatic Complexity - II • The cyclomatic complexity of a program provides a lower bound on the number of test cases to be designed – to guarantee coverage of all linearly independent paths. – does not make it any easier to derive the test cases, – only gives an indication of the minimum number of test cases required.
  • 18. Path Testing • Draw control flow graph. • Determine V(G). • Determine the set of linearly independent paths. • Prepare test cases: • to force execution along each path. • Number of independent paths: 3 • 1,6 test case (x=1, y=1) • 1,2,3,5,1,6 test case(x=1, y=2) • 1,2,4,5,1,6 test case(x=2, y=1) 1 2 3 4 5 6
  • 19. Cyclomatic Complexity - III • Relationship exists between – McCabe's metric & the number of errors existing in the code, – the time required to find and correct the errors. • also indicates the psychological complexity of a program. • i.e. difficulty level of understanding the program. • Therefore, limit cyclomatic complexity of modules to some reasonable value. (10 or so)
  • 20. Automated Testing Tools • Mercury Interactive • Quick Test Professional: Regression testing • WinRunner: UI testing • IBM Rational • Rational Robot • Functional Tester • Borland • Silk Test • Compuware • QA Run • AutomatedQA • TestComplete