CMSC 345 Fall 2000 Unit Testing. The testing process.

Slides:



Advertisements
Similar presentations
Defect testing Objectives
Advertisements

การทดสอบโปรแกรม กระบวนการในการทดสอบ
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
1 Software Engineering Lecture 11 Software Testing.
CMSC 345, Version 11/07 SD Vick from S. Mitchell Software Testing.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Software Engineering Software Testing.
Testing an individual module
Software Testing. “Software and Cathedrals are much the same: First we build them, then we pray!!!” -Sam Redwine, Jr.
Chapter 18 Testing Conventional Applications
- Testing programs to establish the presence of system defects -
Software Testing & Strategies
1 Software Testing Techniques CIS 375 Bruce R. Maxim UM-Dearborn.
Chapter 13 & 14 Software Testing Strategies and Techniques
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
Software Testing Verification and validation planning Software inspections Software Inspection vs. Testing Automated static analysis Cleanroom software.
Dr. Pedro Mejia Alvarez Software Testing Slide 1 Software Testing: Building Test Cases.
System/Software Testing
Testing phases. Test data Inputs which have been devised to test the system Test cases Inputs to test the system and the predicted outputs from these.
Chapter 12: Software Testing Omar Meqdadi SE 273 Lecture 12 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Prof. Mohamed Batouche Software Testing.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1 Defect testing l Testing programs to establish the presence of system defects.
CSC 480 Software Engineering Lecture 14 Oct 16, 2002.
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 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.
1 Software Defect Testing Testing programs to establish the presence of system defects.
Software Testing. 2 CMSC 345, Version 4/12 Topics The testing process  unit testing  integration and system testing  acceptance testing Test case planning.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
Black Box Testing Techniques Chapter 7. Black Box Testing Techniques Prepared by: Kris C. Calpotura, CoE, MSME, MIT  Introduction Introduction  Equivalence.
Unit Testing 101 Black Box v. White Box. Definition of V&V Verification - is the product correct Validation - is it the correct product.
Software Testing Yonsei University 2 nd Semester, 2014 Woo-Cheol Kim.
INTRUDUCTION TO SOFTWARE TESTING TECHNIQUES BY PRADEEP I.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1 Defect testing l Testing programs to establish the presence of system defects.
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
CS451 Lecture 10: Software Testing Yugi Lee STB #555 (816)
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.
Dynamic Testing.
HNDIT23082 Lecture 09:Software Testing. Validations and Verification Validation and verification ( V & V ) is the name given to the checking and analysis.
Chapter 12: Software Testing Omar Meqdadi SE 273 Lecture 12 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
SOFTWARE TESTING LECTURE 9. OBSERVATIONS ABOUT TESTING “ Testing is the process of executing a program with the intention of finding errors. ” – Myers.
ANOOP GANGWAR 5 TH SEM SOFTWARE TESTING MASTER OF COMPUTER APPLICATION-V Sem.
Software Testing. SE, Testing, Hans van Vliet, © Nasty question  Suppose you are being asked to lead the team to test the software that controls.
Defect testing Testing programs to establish the presence of system defects.
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.
Software Testing.
Software Testing.
Rekayasa Perangkat Lunak Part-13
Software Testing.
Software Engineering (CSI 321)
IS301 – Software Engineering V:
Chapter 13 & 14 Software Testing Strategies and Techniques
Structural testing, Path Testing
Types of Testing Visit to more Learning Resources.
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Software testing strategies 2
Software Testing (Lecture 11-a)
Lecture 09:Software Testing
Software testing.
Chapter 10 – Software Testing
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Software Testing “If you can’t test it, you can’t design it”
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Chapter 13 & 14 Software Testing Strategies and Techniques 1 Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
Presentation transcript:

CMSC 345 Fall 2000 Unit Testing

The testing process

Stages in the Testing Process Unit Test – individual components Module Test – module = collection of components such as an object class or loose collection of functions Sub-System Test – collection of integrated modules. Look for interface mismatch. System Test – integrated subsystems. Find errors from unanticipated interactions Acceptance Test – test with “real” data. Find errors and omissions in requirements

Test Planning Sets standards for testing process rather than describing product tests Expensive Begins when system requirements are formulated and should be developed in detail as software is designed.

The test plan The testing process Requirements traceability Tested items Testing schedule Test recording procedures Hardware and software requirements Constraints

The V-model of development

Unit Testing Usually the responsibility of the programmer Black box testing Specification based White box testing Program based Normally perform both

Black Box Testing Tests module against functional and non- functional specifications Specification used to derive test cases Do not look at module code (except to debug) Attempt to force behavior that doesn't match specification Problem – how to select inputs that have a high probability of causing error Experience, domain knowledge

Approaches to Blackbox Testing Equivalence partitioning Boundary value analysis Stress testing

Equivalence Partitioning Equivalence class is related set of valid or invalid values or states Divide input domain into equivalence classes Attempt to cover classes of errors One test case per equivalence class, to reduce total number of test cases needed

Range equivalence classes Assumes scalar 1. Arbitrary value below range 2. Arbitrary value within range 3. Arbitrary value above range

Example Program specification states that the system will accept between 4 and 10 inputs which are 5-digit integers. Partition system inputs and outputs into ‘equivalence sets’ If input is a 5-digit integer between and 99999, equivalence partitions are Choose test cases at the boundary of these sets 00000, 09999, 10000, 99999, 10001

Equivalence partitions

Set equivalence classes Member of set Non-member of set

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

Range equivalence classes 1. Value immediately below range 2. First value of range 3. Second value of range 4. Next to last value of range 5. Last value of range 6. Value immediately above range 7. Minimum and maximum values of range's basic type (optional)

Scalar set equivalence classes Member of set Values immediately above and below each member of set Minimum and maximum values of set element's basic type (optional)

Non-scalar set equivalence classes Member of set Null value (if not in set) Other non-member value(s) of correct type ("above" and "below" each set member, "minimum" and "maximum" of type, if such concepts are applicable) Value of incorrect type, structurally equivalent (if not detected by compiler) Value of incorrect type, not structurally equivalent (if not detected by compiler)

Stress Testing Large amounts of data Worst case operating conditions Combinations of events

White Box Testing Complementary to black-box Tester can analyze the code and use knowledge about the structure to derive test cases Knowledge of the algorithm can be used to identify equivalence classes Tests control and/or data flow paths through module

Adequacy Criteria 1. Execute all (reachable) statements 2. Execute all branches of logical decisions, including boundaries of loops 3. Execute all (feasible) control flow paths in combination 4. Execute all data flow paths (from each definition to all its uses) Usually applied only to individual subroutines rather than module as a whole May be combined with black box testing if tool available to track code coverage

Statement Coverage Requires each statement in program be executed at least once 85% easy, 100% hard Unreachable code Dead code Complex sequence Microsoft reports 80-90% code coverage

Path Testing A strategy whose objective is to exercise every independent executable path Starting point is the program flow graph Flow graph constructed by replacing program control statements with diagrams Used as a basis for computing the cyclomatic complexity Complexity = Number of edges - Number of nodes +1

Flow graph representations

Binary Search Paths 1, 2, 3, 4, 12, 13 1, 2,3, 5, 6, 11, 2, 12, 13 1, 2, 3, 5, 7, 8, 10, 11, 2, 12, 13 1, 2, 3, 5, 7, 9, 10, 11, 2, 12, 13 Test cases should be derived so that all of these paths are executed A dynamic program analyser may be used to check that paths have been executed

Test cases After determining the independent paths, design test cases for each path The minimum number of test cases is equal to the cyclomatic complexity. Problem – path testing cannot test all possible combinations of paths through a program. There are an infinite number of possible path combinations in programs with loops

Exercise 8.16 A safety-critical system fails and several lives are lost. When the cause of the failure is investigated, the inquiry commission determines that the test plan neglected to consider the case that caused the system failure. Who is responsible for the deaths: The testers for not noticing the missing case? The test planners for not writing a complete test plan? The managers for not having checked the test plan? The customer for not having done a thorough acceptance test?

Exercise 8.18 Sometimes customers hire an independent organization to do independent verification & validation. The V & V staff examines all aspects of development, including process and product to ensure the quality of the final product. If an independent V &V team is used and the stysem still experiences a catastrophic failure, who should be held responsible? the managers, the V &V team, the designers the coders or the testers