April 1,200291.3913 R McFadyen1 A Traditional Software Development Process Unit test Integration...
-
date post
18-Dec-2015 -
Category
Documents
-
view
213 -
download
0
Transcript of April 1,200291.3913 R McFadyen1 A Traditional Software Development Process Unit test Integration...
April 1,2002 91.3913 R McFadyen 1
A Traditional Software Development Process
Unit test
Integration test
System test
Detailed design
Architectural design
Analysis
Requirements analysis
Business modeling process
Business results
April 1,2002 91.3913 R McFadyen 2
Black Team
Peopleware: Productive Projects and Teams
by Tom Demarco and Timothy Lister
Ch 19: The Black Team
•"legendary" Black Team at IBM in 60’s
•a particularly effective testing team
•the best testers at the company
•testers delighted in finding new ways to break software
•programmers dreaded having their software go through Black Team testing
•promoted themselves by dressing all in black
•the spirit of the Black Team has survived
April 1,2002 91.3913 R McFadyen 3
Testing
Unit testing •Equivalence classes•Boundary classes•Black-box testing•White-box testing
Integration testing
System testing
Object-oriented testing
April 1,2002 91.3913 R McFadyen 4
Black-box Testing
• A blackbox test is one that focuses on the input/output behaviour of a component without considering its implementation
• The system being tested is a black box, whose behaviour is determined by studying its inputs and outputs
• aka functional testing since it is concerned with functionality and not implementation
• Equivalence testing
• Boundary testing
April 1,2002 91.3913 R McFadyen 5
Equivalence testing
• A technique to minimize the number of test cases• An equivalence class is a set of tests with common characteristics• A test case is selected for each class• We use our domain knowledge to generate equivalence classes• example: suppose a method returns the number of days in a
month, given the month and year.– When we consider months, we could arrive at 3 equivalence
classes:• months with 31 days• months with 30 days• months with 28 or 29 days
– When we consider years, we have two equivalence classes: leap years and non-leap years
– Combining, we have 6 equivalence classes
April 1,2002 91.3913 R McFadyen 6
Six equivalence classes
Equivalence classInput values
month year
31 day month, non-leap year 7 1901
31 day month, leap year 7 1904
30 day month, non-leap year 6 1901
30 day month, leap year 6 1904
28/29 day month, non-leap year 2 1901
28/29 day month, leap year 2 1904
April 1,2002 91.3913 R McFadyen 7
Boundary testing
•We focus on the boundary conditions of equivalence classes
•Rather than selecting any element in an equivalence class, boundary testing requires that elements be selected from the “edges”
Example
•In general, years that are multiples of 4 are leap years; years that are multiples of 100 are not leap years, unless they are multiples of 400.
•2000 is a leap year, but 1900 is not
•For Year, 2000 and 1900 are good boundary cases
•0 and 13 would be good boundary cases for month
April 1,2002 91.3913 R McFadyen 8
Ten equivalence classes
Equivalence classInput values
month year31 day month, non-leap year 7 1901
31 day month, leap year 7 1904
30 day month, non-leap year 6 1901
30 day month, leap year 6 1904
28/29 day month, non-leap year 2 1901
28/29 day month, leap year 2 1904
Leap year divisible by 400 2 2000
Non-leap year divisible by 100 2 1900
Non-positive invalid month 0 1904
positive invalid month 13 1904
April 1,2002 91.3913 R McFadyen 9
Whitebox testing
Boundary and Equivalence testing: if you know the algorithm, you will be able to generate more test classes.
Path testing: A whitebox testing technique based on flow of control
•Construct a flow graph for Cyclomatic Complexity
•The minimum number of tests necessary to cover all edges is the number of independent paths through the flow graph
•Design test cases such that each transition is traversed at least once - examine each condition and select an input for the true branch and another for the false branch
April 1,2002 91.3913 R McFadyen 10
public class MonthOutOfBounds extends Exception {…};public class YearOutOfBounds extends Exception {…};
class MyGregorianCalendar {public static boolean isLeapYear(int year) {boolean leap;if (year%4) {
leap = true;} else {
leap = false;}return leap;
}
public static int getNumDaysInMonth(int month, int year)...
A (faulty) Java implementation of getNumDaysInMonth()
See next slide
What’s wrong here?
April 1,2002 91.3913 R McFadyen 11
public static int getNumDaysInMonth(int month, int year) throws MonthOutOfBounds, YearOutOfBounds {
int numDays;if (year < 1) {
throw new YearOutOfBounds(year);}if (month==1 || month==3 || month==5 || month==7 || month==10 || month==12) {
numDays = 32;} else if (month==4 || month==6 || month==9 || month==11) {
numDays = 30;} else if (month == 2) {
if (isLeapYear(year)) {numDays = 29;
} else {
numDays = 28;}
} else {
throw new MonthOutOfBounds(month);}
return numDays;}
...}
What’s wrong here?
April 1,2002 91.3913 R McFadyen 12
Flow graph - as a UML activity diagram
year out of bounds
month out of bounds
n = 32
n = 30
n = 28
n = 29
[year < 1]
[month in {1,3,5,7,10,12}]
[month in {4,6,9,11}]
[month=2][leap year]
April 1,2002 91.3913 R McFadyen 13
UML activity diagram (flow graph)
year out of bounds
month out of bounds
n = 32
n = 30
n = 28
n = 29
[year < 1]
[month in {1,3,5,7,10,12}]
[month in {4,6,9,11}]
[month=2][leap year]
1
2
3
4
5 6
We can walk through the flow graph and generate 6 tests to ensure each transition is traversed
April 1,2002 91.3913 R McFadyen 14
UML activity diagram (flow graph)
year out of bounds
month out of bounds
n = 32
n = 30
n = 28
n = 29
[year < 1]
[month in {1,3,5,7,10,12}]
[month in {4,6,9,11}]
[month=2][leap year]
1
2
3
4
5 6
We can walk through the flow graph and generate 6 tests to ensure each transition is traversed
Year=0; month=7
Year=1999; month=7
Year=1999; month=6
Year=2000; month=2
Year=1999; month=2
Year=2000; month=0
April 1,2002 91.3913 R McFadyen 15
What is the flow graph for isLeapYear()?
What tests can we generate from it?
isLeapYear()
Which tests, of all the tests we’ve outlined, will actually help us find the problems with these two methods?
April 1,2002 91.3913 R McFadyen 16
Another White-box Testing Example
FindMean(float Mean, FILE ScoreFile) …
What is the flow graph for FindMean?
What is the CC?
What tests can we generate from the CC … to know all paths have been executed?
April 1,2002 91.3913 R McFadyen 17
/*Read in and sum the scores*/
Another White-box Testing Example
FindMean(float Mean, FILE ScoreFile)
{ SumOfScores = 0.0; NumberOfScores = 0; Mean = 0;
Read(ScoreFile, Score);
while (! EOF(ScoreFile) {
if ( Score > 0.0 ) {
SumOfScores = SumOfScores + Score;
NumberOfScores++;
}
Read(ScoreFile, Score);
}
/* Compute the mean and print the result */
if (NumberOfScores > 0 ) {
Mean = SumOfScores/NumberOfScores;
printf("The mean score is %f \n", Mean);
} else
printf("No scores found in file\n");
}
April 1,2002 91.3913 R McFadyen 18
Prepare for Flow Graph
FindMean (FILE ScoreFile){ float SumOfScores = 0.0;
int NumberOfScores = 0; float Mean=0.0; float Score;Read(ScoreFile, Score);while (! EOF(ScoreFile) {
if (Score > 0.0 ) {SumOfScores = SumOfScores + Score;NumberOfScores++;}
Read(ScoreFile, Score);}/* Compute the mean and print the result */if (NumberOfScores > 0) {
Mean = SumOfScores / NumberOfScores;printf(“ The mean score is %f\n”, Mean);
} elseprintf (“No scores found in file\n”);
}
1
2
3
4
5
7
6
89
April 1,2002 91.3913 R McFadyen 19
Constructing the Logic Flow Diagram
4
3
2
1
5
6
7 8
9
CC = 11-9+2 = 4
1, 2, 6, 8, 9
1, 2, 6, 7, 9 is not possible
1, 2, 3, 4, 5, 2, 6, 7, 9
1, 2, 3, 4, 5, 2, 6, 8, 9 is not possible
1, 2, 3, 5, 2, 6, 8, 9
1, 2, 3, 5, 2, 6, 7, 9 is not possible
ok
ok
ok
Note: If node 4 is included then node 7 must be included
These 3 tests cover all paths! We didn’t need 4!
April 1,2002 91.3913 R McFadyen 20
Testing
Testing tools can count the number of times instructions are executed. This is examined for completeness – that all paths have been executed.
How would knowledge of the algorithm (the code) affect your choices of equivalence classes and boundary classes?
• Suppose you are testing a search method. What equivalence and boundary classes would you decide on?
• Suppose you know the search is a binary search and not a simple selection search … this should affect your classes
April 1,2002 91.3913 R McFadyen 21
Class model for a testing system?
is caused by
* *
Test case
Failure FaultError
Test suite
is caused by
*
*
CorrectionComponent
Test stub
Test driver
exercises is revised by
finds repairs
*
* *
*
* * 1…n
*
*
April 1,2002 91.3913 R McFadyen 22
Testing
Example:
Suppose we have a search module to test. We know:
– the list, elt, must have at least one element
– if the element, key, is found, found will be true and elt[L] = key
– if the key is not found, found will be false
How do we structure, or organize, our test cases?
April 1,2002 91.3913 R McFadyen 23
Black-box Testing
Example (continued):• How do we structure, or organize, our test cases?
• We have two types of searches: successful and unsuccessful. So, we can partition our search test cases into two classifications: found and not found
• When it comes to lists of elements, we know that lists of length 1, are special cases or boundary points. So, we should have 2 partitions of lists: length 1, and length of more than one.
• When an element is searched for, it can be found in boundary positions. So, we can should have 3 partitions: found at the start, found at the end, and then we should include where it is found in the middle.
April 1,2002 91.3913 R McFadyen 24
Black-box Testing
Found Not Found
List of 1 element List of 1 element
Example (continued):•combining the partitions
List of >1 element
In 1st position
In last position
In middle position
List of >1 element
1 2
3
4
5
6
April 1,2002 91.3913 R McFadyen 25
Black-box Testing
55
44
Example (continued):•sample tests for the 6 partitions
55 33 88 44
22 33 6 77 88 44
33 66 77 88 22
22 55 88 66 77
1
2
3
4
5
6
55 true, 1
55 false, ?
55 true, 1
44 true, 6
77 true, 3
99 false, ?
Outputs Found, L
Inputs List Key
April 1,2002 91.3913 R McFadyen 26
White-box Testing
•Tests are derived from knowledge of the software’s construction
•aka structural, glass-box, or clear-box testing
•Tester analyzes the code, the algorithm, to derive test data
April 1,2002 91.3913 R McFadyen 27
White-box Testing
Example:
suppose we are examining an algorithm that searches an ordered list for a specific value in Key.
•On examination we see it’s a binary search and we see that it really treats the List as having 3 sections:
elements < midmid-point
elements > mid
April 1,2002 91.3913 R McFadyen 28
White-box Testing
•:We can use this knowledge to further refine our partitioning - we need to test for where the Key we are looking for is at the boundary points for these partitions.
elements < midmid-point
elements > mid
We’ll add two more tests
April 1,2002 91.3913 R McFadyen 29
White-box Testing
Example:
55
44
55 66 77 88 99
22 33 44 50 56 61 76
22 33 44 50 56 61 76
22 33 44 50 56 61 76
1
2
3
4
5
6
55 true, 1
55 false, ?
55 true, 1
50 true, 4
76 true, 7
44 true, 3
Outputs Found, L
Inputs List Key
22 33 44 50 56 61 767 56 true, 522 55 88 66 778 99 false, ?
April 1,2002 91.3913 R McFadyen 30
Integration Testing
Combine components into a systemTypical strategy is bottom-up or top-down• Top-down
– related to top-down development– development starts with high-level components and
works down. – Incomplete modules are stubs with the interface, but
little or no functionality.– As top level is programmed and tested, the sub-
components are implemented and tested, …• Bottom-up
– ... (requires more test drivers)• Big-bang … difficult to pinpoint errors
April 1,2002 91.3913 R McFadyen 31
Object-Oriented Integration Testing
Class testing• more than one method/operation• statechart diagrams
• transitions … events that can cause a change in state must be tested
Subclasses•Subclasses should be tested for inherited operations•Overridden operations must be tested
Integration testing (top? bottom?)•Collaboration testing
•Test objects for support of system events and Use Cases •Test significant object collaborations•Note on page 311: suggests implementation from least-coupled to most-coupled