Software Testing Copyright, 1999 © Jerzy R. Nawrocki Personal Software Process Lecture.

Slides:



Advertisements
Similar presentations
2017/3/25 Test Case Upgrade from “Test Case-Training Material v1.4.ppt” of Testing basics Authors: NganVK Version: 1.4 Last Update: Dec-2005.
Advertisements

SOFTWARE ENGINEERING & IT 0301 Semester V
Effort and Schedule Estimation Copyright, 1999 © Jerzy R. Nawrocki Personal Software.
Software Testing Techniques
Chapter 14 Software Testing Techniques - Testing fundamentals - White-box testing - Black-box testing - Object-oriented testing methods (Source: Pressman,
Software Testing Technique. Introduction Software Testing is the process of executing a program or system with the intent of finding errors. It involves.
Unit-V testing strategies and tactics.
Chapter 14 Testing Tactics
Software Reviews Copyright, 1999 © Jerzy R. Nawrocki Personal Software Process Lecture.
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
Procedures for CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Software Quality Assurance (SQA). Recap SQA goal, attributes and metrics SQA plan Formal Technical Review (FTR) Statistical SQA – Six Sigma – Identifying.
November 2005J. B. Wordsworth: J5DAMQVT1 Design and Method Quality, Verification, and Testing.
Creator: ACSession No: 13 Slide No: 1Reviewer: SS CSE300Advanced Software EngineeringFebruary 2006 Testing - Techniques CSE300 Advanced Software Engineering.
1 Static Testing: defect prevention SIM objectives Able to list various type of structured group examinations (manual checking) Able to statically.
Detailed Design Kenneth M. Anderson Lecture 21
Software engineering for real-time systems
Illinois Institute of Technology
Testing an individual module
Chapter 18 Testing Conventional Applications
1 Software Testing Techniques CIS 375 Bruce R. Maxim UM-Dearborn.
Chapter 13 & 14 Software Testing Strategies and Techniques
Slide 6.1 CHAPTER 6 TESTING. Slide 6.2 Overview l Quality issues l Nonexecution-based testing l Execution-based testing l What should be tested? l Testing.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Lecture 11 Testing and Debugging SFDV Principles of Information Systems.
1 Software testing. 2 Testing Objectives Testing is a process of executing a program with the intent of finding an error. A good test case is in that.
Software Reviews & testing Software Reviews & testing An Overview.
Software Testing Testing types Testing strategy Testing principles.
Software Testing The process of operating a system or component under specified conditions, observing and recording the results, and making an evaluation.
Agenda Introduction Overview of White-box testing Basis path testing
INTRUDUCTION TO SOFTWARE TESTING TECHNIQUES BY PRADEEP I.
ReviewsReviews Copyright, 2002 © Jerzy R. Nawrocki Quality Management Auxiliary.
Software Engineering Lecture 14: Testing Techniques and Strategies.
Software Development Problem Analysis and Specification Design Implementation (Coding) Testing, Execution and Debugging Maintenance.
CSC 480 Software Engineering Testing - I. Plan project Integrate & test system Analyze requirements Design Maintain Test units Implement Software Engineering.
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
Software Engineering Saeed Akhtar The University of Lahore.
Theory and Practice of Software Testing
SOFTWARE TESTING. Introduction Software Testing is the process of executing a program or system with the intent of finding errors. It involves any activity.
Software Quality Assurance and Testing Fazal Rehman Shamil.
 Software Testing Software Testing  Characteristics of Testable Software Characteristics of Testable Software  A Testing Life Cycle A Testing Life.
Dynamic Testing.
Software Engineering Testing. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright.
Software Testing Techniques Presented By Dr. Shazzad Hosain.
CS223: Software Engineering Lecture 21: Unit Testing Metric.
SOFTWARE TESTING SOFTWARE TESTING Presented By, C.Jackulin Sugirtha-10mx15 R.Jeyaramar-10mx17K.Kanagalakshmi-10mx20J.A.Linda-10mx25P.B.Vahedha-10mx53.
SOFTWARE TESTING. SOFTWARE Software is not the collection of programs but also all associated documentation and configuration data which is need to make.
SOFTWARE TESTING LECTURE 9. OBSERVATIONS ABOUT TESTING “ Testing is the process of executing a program with the intention of finding errors. ” – Myers.
Verification vs. Validation Verification: "Are we building the product right?" The software should conform to its specification.The software should conform.
1 Software Testing. 2 What is Software Testing ? Testing is a verification and validation activity that is performed by executing program code.
Testing Integral part of the software development process.
CX Introduction to Web Programming Testing.
Requirements Engineering Lecture 7
Group mambers: Maira Naseer (BCS ).
Software Testing.
Requirements Engineering Lecture 2
Software Testing Techniques
Software Engineering (CSI 321)
Software Testing An Introduction.
Chapter 13 & 14 Software Testing Strategies and Techniques
UNIT-IV ECS-602 Software engineering PART-I
Software testing strategies 2
Software Testing (Lecture 11-a)
Chapter 14 Software Testing Techniques
Verification and Validation Unit Testing
Chapter 10 – Software Testing
Software Testing “If you can’t test it, you can’t design it”
Software Testing.
By: Lecturer Raoof Talal
Chapter 13 & 14 Software Testing Strategies and Techniques 1 Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
Presentation transcript:

Software Testing Copyright, 1999 © Jerzy R. Nawrocki Personal Software Process Lecture 14

J. Nawrocki, PSP, Lecture 14 { n+=NF; } { n+=NF; } END { print n; } From the previous lecture.. InspectionInspection (very formal) (very formal) Walk-throughWalk-through (a presentation) (a presentation) Personal reviewPersonal review (DIY) (DIY)

J. Nawrocki, PSP, Lecture 14 From the previous lecture.. DesignDesignCodeCodeUnittestUnittest I1I1 I2I2 I3I3 Net savings (hours/KLOC): I 1 : 94 I 2 : 51 I 3 : -20 Fagan inspections

J. Nawrocki, PSP, Lecture 14 From the previous lecture.. 1. Overview (whole team) 2. Preparation (individual) 3. Inspection (whole team) 4. Rework 5. Follow-up Designer Implem. Moderator Tester Review session Fagan inspections

J. Nawrocki, PSP, Lecture 14 From the previous lecture.. Are all constants defined? If a queue is being manipulated, can the execution be interrupted; If so, is queue protected by a locking structure? Are registers being restored on exits? Are all increment counts properly initialised (0 or 1)? Are absolutes shown where there should be symbolics? Are all blocks shown in design necessary? Checklist for design inspection Ex Wr Missing

J. Nawrocki, PSP, Lecture 14 From the previous lecture.. PR/M/Min L3: the prologue in the REMARKS section needs expansion. section needs expansion. LO/W/Maj L172: NAME-CHECK is performed one time too few. time too few. DE/W/Min L175: the design should allow for the occurrence of a period in a last occurrence of a period in a last name. name. Error list

J. Nawrocki, PSP, Lecture 14 From the previous lecture.. CC: Code comments CU: CB usage DE: Design error IC: Interconnect calls LO: Logic MN: Maintainability OT: Other PE: Performance PR: Prolog Major Minor Major Minor M W E M W E M W E M W E Date Code inspection report Mod/Mac: Total

J. Nawrocki, PSP, Lecture 14 From the previous lecture.. Questions posed by the author of the design - to encourage a thorough reviewQuestions posed by the author of the design - to encourage a thorough review Several brief reviews focusing on a part of a work product (part of a design document)Several brief reviews focusing on a part of a work product (part of a design document) A sequence of small inspectionsA sequence of small inspections One-person reviews and multi-person inspectionsOne-person reviews and multi-person inspections Indigenous and seeded defectsIndigenous and seeded defects Active design reviews Phased inspections

J. Nawrocki, PSP, Lecture 14 Introduction Software testing is a critical element of SQA and represents the ultimate review of specification, design, and coding. -- Roger Pressman97

J. Nawrocki, PSP, Lecture 14 Testing objectives Testing = executing a program to find an error Quality of a test case: probability of finding an as-yet undiscovered error. A successful test uncovers an as-yet undiscovered error. -- Glen Myers79

J. Nawrocki, PSP, Lecture 14 Dijkstras saying Testing cannot show the absence of defects, it can only show that software errors are present. -- E.W. Dijkstra

J. Nawrocki, PSP, Lecture 14 Testing effort Testing: ~ 30% - 40% of total effort Testing mission-critical systems: 70% - 80% of the total effort (!) -- Roger Pressman97

J. Nawrocki, PSP, Lecture 14 Testing principles All tests should be traceable to customer requirementsAll tests should be traceable to customer requirements Tests should be planned long before testing beginsTests should be planned long before testing begins The Pareto principle applies to software testingThe Pareto principle applies to software testing Testing should begin in-the-small and progress toward in-the-largeTesting should begin in-the-small and progress toward in-the-large Exhaustive testing is not possibleExhaustive testing is not possible Some testing should be conducted by an independent third partySome testing should be conducted by an independent third party

J. Nawrocki, PSP, Lecture 14 A good test.... has a high probability of finding an error.. is not redundant.. should be best of breed.. should be neither too simple nor too complex

J. Nawrocki, PSP, Lecture 14 White-box testing Flow chartFlow chart The number of independent paths (cyclomatic complexity - McCabe76):The number of independent paths (cyclomatic complexity - McCabe76): V(G) = P + 1 V(G) = P + 1 P: the number of predicate nodes P: the number of predicate nodes Construct a basis set of independent pathsConstruct a basis set of independent paths Prepare test cases: each path in the basis set must be takenPrepare test cases: each path in the basis set must be taken

J. Nawrocki, PSP, Lecture 14 White-box testing void PrintGraph(int n){ int r, c; int r, c; for(r=0; r<n; r++){ for(r=0; r<n; r++){ printf("\n%d:", r); printf("\n%d:", r); for(c=0; c<n; c++) for(c=0; c<n; c++) if(Connected(r, c)) if(Connected(r, c)) printf(" %d", c); } printf("\n"); printf("\n"); } 0: : 0 2: 0 3:

J. Nawrocki, PSP, Lecture 14 White-box testing void PrintGraph(int n){ int r, c; int r, c; for(r=0; r<n; r++){ for(r=0; r<n; r++){ printf("\n%d:", r); printf("\n%d:", r); for(c=0; c<n; c++) for(c=0; c<n; c++) if(Connected(r, c)) if(Connected(r, c)) printf(" %d", c); printf(" %d", c); } printf("\n"); printf("\n"); } r=0; if r>=n goto.. printf(, r); c=0; if c>=n goto.. if not Connected goto.. printf(, c) c++; r++; printf(\n);

J. Nawrocki, PSP, Lecture 14 White-box testing void PrintGraph(int n){ int r, c; int r, c; for(r=0; r<n; r++){ for(r=0; r<n; r++){ printf("\n%d:", r); printf("\n%d:", r); for(c=0; c<n; c++) for(c=0; c<n; c++) if(Connected(r, c)) if(Connected(r, c)) printf(" %d", c); printf(" %d", c); } printf("\n"); printf("\n"); } r=0; if r>=n goto.. printf(, r); c=0; if c>=n goto.. if not Connected goto.. printf(, c) c++; r++; printf(\n); V(G) = = 4

J. Nawrocki, PSP, Lecture 14 White-box testing r=0; if r>=n goto.. printf(, r); c=0; if c>=n goto.. if !Connected goto.. printf(, c) c++; r++; printf(\n); A A G G B B C C D D E E F F A - G

J. Nawrocki, PSP, Lecture 14 White-box testing r=0; if r>=n goto.. printf(, r); c=0; if c>=n goto.. if !Connected goto.. printf(, c) c++; r++; printf(\n); A A G G B B C C D D E E F F A - G A - B - F - A - G

J. Nawrocki, PSP, Lecture 14 White-box testing r=0; if r>=n goto.. printf(, r); c=0; if c>=n goto.. if !Connected goto.. printf(, c) c++; r++; printf(\n); A A G G B B C C D D E E F F A - G A - B - F - A - G A - B - C - E - B - F - A - G

J. Nawrocki, PSP, Lecture 14 White-box testing r=0; if r>=n goto.. printf(, r); c=0; if c>=n goto.. if !Connected goto.. printf(, c) c++; r++; printf(\n); A A G G B B C C D D E E F F A - G A - B - F - A - G A - B - C - E - B - F - A - G A - B - C - D - E - B - F - A - G

J. Nawrocki, PSP, Lecture 14 White-box testing r=0; if r>=n goto.. printf(, r); c=0; if c>=n goto.. if !Connected goto.. printf(, c) c++; r++; printf(\n); A A G G B B C C D D E E F F A - G n = 0

J. Nawrocki, PSP, Lecture 14 White-box testing r=0; if r>=n goto.. printf(, r); c=0; if c>=n goto.. if !Connected goto.. printf(, c) c++; r++; printf(\n); A A G G B B C C D D E E F F A - B - F - A - G 0 = n ???

J. Nawrocki, PSP, Lecture 14 White-box testing r=0; if r>=n goto.. printf(, r); c=0; if c>=n goto.. if !Connected goto.. printf(, c) c++; r++; printf(\n); A A G G B B C C D D E E F F A - B - F - A - G 0 1 n = 2 A-B-C-E-B-C-D-E-B-F-A-..-A-G A test case for:

J. Nawrocki, PSP, Lecture 14 Black-box testing Targets: incorrect or missing functionsincorrect or missing functions interface errorsinterface errors errors in data structureserrors in data structures performance errorsperformance errors initialisation and termination errorsinitialisation and termination errors

J. Nawrocki, PSP, Lecture 14 Black-box testing Requirements-based: use scenariosuse scenarios Based on formal specification: boundary value analysisboundary value analysis

J. Nawrocki, PSP, Lecture 14 Black-box testing 01 n = 2 n = 0 n = n = 2 n = void PrintGraph( int n )

J. Nawrocki, PSP, Lecture 14 Black-box testing r=0; if r>=n goto.. printf(, r); c=0; if c>=n goto.. if !Connected goto.. printf(, c) c++; r++; printf(\n); A A G G B B C C D D E E F F 01 n = 2 n = 0 n = n = 2 n = McCabes completeness

J. Nawrocki, PSP, Lecture 14 Test report template Tester: Date: Program: Test symbol: Test objective: Test conditions: Input Expected output Actual output

J. Nawrocki, PSP, Lecture 14 Test report template Tester: J. Nawrocki Date: Program: GraphCol Test symbol: N2Full Test objective: To check the program for a graph consisting of 2 connected nodes. Test conditions: Use the program N2Full. Input Expected output 0: 1 1: 0 Actual output 0: 1 1: 0

J. Nawrocki, PSP, Lecture 14 Comparison testing Multiple implementationsMultiple implementations Sometimes interface filters can be helpful (two modules are implementing not the same but similar systems)Sometimes interface filters can be helpful (two modules are implementing not the same but similar systems)

J. Nawrocki, PSP, Lecture 14 Software testing strategies Verification vs. ValidationVerification vs. Validation The V modelThe V model Predicting the failure intensity (logarithmic Poisson execution time model):Predicting the failure intensity (logarithmic Poisson execution time model): f(t) = (1/p)ln(l 0 pt + 1) f(t) = (1/p)ln(l 0 pt + 1) f(t) - cumulative number of failures that are expected to occur after time t f(t) - cumulative number of failures that are expected to occur after time t

J. Nawrocki, PSP, Lecture 14 Summary Testing is a destructive activity. Testing cannot show the absence of defects. Testing > 30% of total effort. All tests should be traceable to customer requirements. White-box testing. Black-box testing.

J. Nawrocki, PSP, Lecture 14 Further readings W.S. Humphrey, A Discipline for Software Engineering, Addison-Wesley, Reading, Engineering, Addison-Wesley, Reading, R.S. Pressman, Software Engineering. A Practitioners Approach, McGraw-Hill, A Practitioners Approach, McGraw-Hill, New York, New York, R.A. DeMillo et al., Software Testing and Evaluation, Benjamin/Cummings, Evaluation, Benjamin/Cummings, Menlo Park, Menlo Park, 1987.

J. Nawrocki, PSP, Lecture 14 Quality assessment 1. What is your general impression ? (1 - 6) 2. Was it too slow or too fast ? 3. Did you learn something important to you ? 4. What to improve and how ?