le3.1 software testing - freie universität · ©ian sommerville 2000 software engineering, 6th...
TRANSCRIPT
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1
Chapter 20
Software Testing
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 2
Defect testing
l The goal of defect testing is to discover defects in programs
l A successful defect test is a test which causes a program to behave in an anomalous way
l Tests show the presence not the absence of defects
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 3
l Test data Inputs which have been devised to test the system
l Test cases Inputs to test the system and the predicted outputs from these inputs if the system operates according to its specification
Test data and test cases
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 4
The defect testing process
Design testcases
Prepare testdata
Run programwith test data
Compare resultsto test cases
Testcases
Testdata
Testresults
Testreports
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 5
Black-box testing
Ie
Input test data
OeOutput test results
System
Inputs causinganomalousbehaviour
Outputs which revealthe presence ofdefects
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 6
Black-box testing
l An approach to testing where the program is considered as a ‘black-box’
l The program test cases are based on the system specification
l Test planning can begin early in the software process
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 7
Equivalence partitioning
System
Outputs
Invalid inpu ts Valid inpu ts
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 8
Equivalence partitioning
l Input data and output results often fall into different classes where all members of a class are related
l Each of these classes is an equivalence partition where the program behaves in an equivalent way for each class member
l Test cases should be chosen from each partition
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 9
Equivalence partitioning
Between 10000 and 99999Less than 10000 More than 99999
999910000 50000
10000099999
Input values
Between 4 and 10Less than 4 More than 10
34 7
1110
Number of input values
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 10
Search routine specification
procedure Search (Key : in ELEM; T: in ELEM_ARRAY;Found : out BOOLEAN; L: out ELEM_INDEX) ;
Pre-condition-- the array has at least one elementT’FIRST <= T’LAST
Post-condition-- the element is found and is referenced by L( Found and T (L) = Key)
or-- the element is not in the array( not Found andnot (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 11
l Inputs which conform to the pre-conditionsl Inputs where a pre-condition does not holdl Inputs where the key element is a member of
the arrayl Inputs where the key element is not a member
of the array
Search routine - input partitions
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 12
Testing guidelines (sequences)
l Test software with sequences which have only a single value
l Use sequences of different sizes in different tests
l Derive tests so that the first, middle and last elements of the sequence are accessed
l Test with sequences of zero length
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 13
Search routine - input partitions
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 14
White-box testing
Componentcode
Testoutputs
Test data
DerivesTests
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 15
l Usually called structural testingl Derivation of test cases according to program
structure. Knowledge of the program is used to identify additional test cases
l Objective is to exercise all program statements (not all path combinations)
White-box testing
Binary search (Java)
class BinSearch {
// This is an encapsulation of a binary search function that takes an array of// ordered objects and a key and returns an object with 2 attributes namely// index - the value of the array index// found - a boolean indicating whether or not the key is in the array// An object is returned because it is not possible in Java to pass basic types by// reference to a function and so return two values// the key is -1 if the element is not found
public static void search ( int key, int [] elemArray, Result r ){
int bottom = 0 ;int top = elemArray.length - 1 ;int mid ;r.found = false ; r.index = -1 ;while ( bottom <= top ){
mid = (top + bottom) / 2 ;if (elemArray [mid] == key){
r.index = mid ;r.found = true ;return ;
} // if partelse{
if (elemArray [mid] < key)bottom = mid + 1 ;
elsetop = mid - 1 ;
}} //while loop
} // search} //BinSearch
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 17
l Pre-conditions satisfied, key element in arrayl Pre-conditions satisfied, key element not in
arrayl Pre-conditions unsatisfied, key element in arrayl Pre-conditions unsatisfied, key element not in arrayl Input array has a single value
Binary search - equiv. partitions
l Input array has an even number of valuesl Input array has an odd number of valuesl Key is in/near middle of array
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 18
Binary search - test cases
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 19
Testing phases
Componenttesting
Integrationtesting
Software developer Independent testing team
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 20
Testing phases
l Component testing • Testing of individual program components• Usually the responsibility of the component developer (except
sometimes for critical systems)• Tests are derived from the developer’s experience
l Integration testing• Testing of groups of components integrated to create a system
or sub-system• The responsibility of an independent testing team• Tests are based on a system specification
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 21
Interface testingTestcases
BA
C
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 22
l Takes place when modules or sub-systems are integrated to create larger systems
l Objectives are to detect faults due to interface errors or invalid assumptions about interfaces
l Particularly important for object-oriented development as objects are defined by their interfaces
Interface testing
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 23
Interface testing guidelines
l Design tests so that parameters to a called procedure are at the extreme ends of their ranges
l Always test pointer parameters with null pointers
l Design tests which cause the component to faill Identify scenarios from use-cases and
supplement these with interaction diagrams that show the objects involved in the scenario
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 24
Weather station object interface
l Test cases are needed for all operations
l Use a state model to identify state transitions for testing
l Examples of testing sequences
• Shutdown → Waiting → Shutdown
• Waiting → Calibrating → Testing →Transmitting → Waiting
• Waiting → Collecting → Waiting →Summarising → Transmitting → Waiting
identifier
reportWeather ()calibrate (instruments)test ()startup (instruments)shutdown (instruments)
WeatherStation
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 25
Key points
l Test parts of a system which are commonly used rather than those which are rarely executed
l Equivalence partitions are sets of test cases where the program should behave in an equivalent way
l Black-box testing is based on the system specificationl Structural testing identifies test cases which cause all
paths through the program to be executedl Test interfaces in a sequence of operations confirming to
(anti-) use cases.