Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 10: esting and Inspecting to Ensure High Quality www.oseng.com
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 10: Testing and Inspecting to Ensure High Quality
10.1 Basic definitions A failure is an unacceptable behaviour exhibited by a system The frequency of failures measures the reliability -An important design objective is to achieve a very low failure rate and hence high reliability -a failure can result from a violation of an explicit or implicit requirement a defect is a flaw in any aspect of the system that contributes, or may potentially contribute, to the occurrence of one or more failures lt might take several defects to cause a particular failure An error is a slip-up or inappropriate decision by a software developer that leads to the introduction of a defect www.oseng.cor C Lethbridge/Laganiere 2001 Chapter 10: Testing and Inspecting for High Quality 2
© Lethbridge/Laganière 2001 Chapter 10: Testing and Inspecting for High Quality 2 10.1 Basic definitions • A failure is an unacceptable behaviour exhibited by a system —The frequency of failures measures the reliability —An important design objective is to achieve a very low failure rate and hence high reliability. —A failure can result from a violation of an explicit or implicit requirement • A defect is a flaw in any aspect of the system that contributes, or may potentially contribute, to the occurrence of one or more failures —It might take several defects to cause a particular failure • An error is a slip-up or inappropriate decision by a software developer that leads to the introduction of a defect
10.2 Effective and Efficient Testing To test effectively, you must use a strategy that uncovers as many defects as possible. To test efficiently, you must find the largest possible number of defects using the fewest possible tests Testing is like detective work The tester must try to understand how programmers and designers think so as to better find defects -The tester must not leave anything uncovered and must be suspicious of everything - lt does not pay to take an excessive amount of time tester has to be efficient www.oseng.com C Lethbridge/Laganiere 2001 Chapter 10: Testing and Inspecting for High Quality
© Lethbridge/Laganière 2001 Chapter 10: Testing and Inspecting for High Quality 3 10.2 Effective and Efficient Testing To test ef ectively, you must use a strategy that uncovers as many defects as possible. To test ef iciently, you must find the largest possible number of defects using the fewest possible tests • Testing is like detective work: —The tester must try to understand how programmers and designers think, so as to better find defects. —The tester must not leave anything uncovered, and must be suspicious of everything. —It does not pay to take an excessive amount of time; tester has to be ef icient
Black-box testing Testers provide the system with inputs and observe the outputs They can see none of The source code The internal data any of the design documentation describing the system's internals www.oseng.com C Lethbridge/Laganiere 2001 Chapter 10: Testing and Inspecting for High Quality
© Lethbridge/Laganière 2001 Chapter 10: Testing and Inspecting for High Quality 4 Black-box testing Testers provide the system with inputs and observe the outputs • They can see none of: —The source code —The internal data —Any of the design documentation describing the system’s internals
Glass-box testing Also called‘ white-box’or‘ structural? testing Testers have access to the system design They can Examine the design documents -View the code -Observe at run time the steps taken by algorithms and their internal data Individual programmers often informally employ glass box testing to verify their own code www.oseng.com C Lethbridge/Laganiere 2001 Chapter 10: Testing and Inspecting for High Quality 5
© Lethbridge/Laganière 2001 Chapter 10: Testing and Inspecting for High Quality 5 Glass-box testing Also called ‘white-box’ or ‘structural’ testing Testers have access to the system design • They can —Examine the design documents —View the code —Observe at run time the steps taken by algorithms and their internal data • Individual programmers often informally employ glass- box testing to verify their own code
Equivalence classes It is inappropriate to test by brute force, using every possible input value -Takes a huge amount of time Is impractical -Is pointless You should divide the possible inputs into groups which you believe will be treated similarly by all algorithms -Such groups are called equivalence classes a tester needs only to run one test per equivalence class The tester has to understand the required input appreciate how the software may have been designed www.oseng.com C Lethbridge/Laganiere 2001 Chapter 10: Testing and Inspecting for High Quality 6
© Lethbridge/Laganière 2001 Chapter 10: Testing and Inspecting for High Quality 6 Equivalence classes • It is inappropriate to test by brute force, using every possible input value —Takes a huge amount of time —Is impractical —Is pointless! • You should divide the possible inputs into groups which you believe will be treated similarly by all algorithms. —Such groups are called equivalence classes. —A tester needs only to run one test per equivalence class —The tester has to - understand the required input, - appreciate how the software may have been designed
Examples of equivalence classes Valid input is a month number (1-12 -Equivalence classes are: [-o00[1.12],[13.00 Valid input is one of ten strings representing a type of fuel Equivalence classes are 10 classes, one for each string A class representing all other strings www.oseng.com C Lethbridge/Laganiere 2001 Chapter 10: Testing and Inspecting for High Quality
© Lethbridge/Laganière 2001 Chapter 10: Testing and Inspecting for High Quality 7 Examples of equivalence classes • Valid input is a month number (1-12) —Equivalence classes are: [-∞..0], [1..12], [13.. ∞] • Valid input is one of ten strings representing a type of fuel —Equivalence classes are - 10 classes, one for each string - A class representing all other strings
Combinations of equivalence classes Combinatorial explosion means that you cannot realistically test every possible system-wide equivalence class If there are 4 inputs with 5 possible values there are 54(i.e625)possible system-wide equivalence classes You should first make sure that at least one test is run with every equivalence class of every individual input You should also test all combinations where an input is likely to affect the interpretation of another You should test a few other random combinations of equivalence classes www.oseng.com C Lethbridge/Laganiere 2001 Chapter 10: Testing and Inspecting for High Quality 8
© Lethbridge/Laganière 2001 Chapter 10: Testing and Inspecting for High Quality 8 Combinations of equivalence classes • Combinatorial explosion means that you cannot realistically test every possible system-wide equivalence class. —If there are 4 inputs with 5 possible values there are 5 4 (i.e.625) possible system-wide equivalence classes. • You should first make sure that at least one test is run with every equivalence class of every individual input. • You should also test all combinations where an input is likely to af ect the interpretation of another. • You should test a few other random combinations of equivalence classes
EXample equivalence class combinations One valid input is either Metric'or ' US/Imperial equivalence classes are Metric, US/Imperial, Other Another valid input is maxumum speed 1 to 750 km/h or I to 500 mph validity depends on whether metric or uS/imperial Equivalence classes are -∞.0],[1.500,[501.750],[751.∝ Some test combinations Metric, 1.500 valid US/Imperial, [501..750] Inva Metric,[501.750 va Metric,[501.750 valid www.oseng.com C Lethbridge/Laganiere 2001 Chapter 10: Testing and Inspecting for High Quality
© Lethbridge/Laganière 2001 Chapter 10: Testing and Inspecting for High Quality 9 Example equivalence class combinations • One valid input is either ‘Metric’ or ‘US/Imperial’ —Equivalence classes are: - Metric, US/Imperial, Other • Another valid input is maxumum speed: 1 to 750 km/h or 1 to 500 mph —Validity depends on whether metric or US/imperial —Equivalence classes are: - [-∞..0], [1..500], [501..750], [751.. ∞] • Some test combinations - Metric, [1..500] valid - US/Imperial, [501..750] invalid - Metric, [501..750] valid - Metric, [501..750] valid
Testing at boundaries of equivalence classes More errors in software occur at the boundaries of equivalence classes The idea of equivalence class testing should be expanded to specifically test values at the extremes of each equivalence class e. g The number 0 often causes problems E. g. If the valid input is a month number(1-12) Test equivalence classes as before Test 0, 1, 12 and 13 as well as very large positive and negative values www.oseng.com C Lethbridge/Laganiere 2001 Chapter 10: Testing and Inspecting for High Quality
© Lethbridge/Laganière 2001 Chapter 10: Testing and Inspecting for High Quality 10 Testing at boundaries of equivalence classes • More errors in software occur at the boundaries of equivalence classes • The idea of equivalence class testing should be expanded to specifically test values at the extremes of each equivalence class —E.g. The number 0 often causes problems • E.g.: If the valid input is a month number (1-12) —Test equivalence classes as before —Test 0, 1, 12 and 13 as well as very large positive and negative values