TNC Examples
TNC Examples
Examples
Three examples will be used throughout in Chapters 5 through 9 to illustrate the various unit
testing methods: the triangle problem (a venerable example in testing circles); a logically complex
function, NextDate; and an example that typifies MIS applications, known here as the commis-
sion problem. Taken together, these examples raise most of the issues that testing craftspersons
will encounter at the unit level. The discussion of higher levels of testing in Chapters 11 through
17 uses four other examples: a simplified version of an automated teller machine (ATM), known
here as the simple ATM system (SATM); the currency converter, an event-driven application typi-
cal of graphical user interface (GUI) applications; and the windshield wiper control device from
the Saturn™ automobile. The last example, a garage door controller, illustrates some of the issues
of “systems of systems.”
For the purposes of code-based testing, pseudocode implementations of the three unit-level
examples are given in this chapter. System-level descriptions of the SATM system, the currency
converter, the Saturn windshield wiper system, and the garage door controller are given in
Chapters 11 through 17. These applications are modeled with finite-state machines, variations
of event-driven petri nets, selected StateCharts, and with the Universal Modeling Language
(UML).
15
© 2010 Taylor & Francis Group, LLC
16 ◾ Software Testing
Comment ‘ <text>
Selection If <condition>
Then <then clause>
Else <else clause>
EndIf
Posttest repetition Do
<loop body>
Until <condition>
The output of the program is the type of triangle determined by the three sides: Equilateral,
Isosceles, Scalene, or NotATriangle. If an input value fails any of conditions c1, c2, or c3, the pro-
gram notes this with an output message, for example, “Value of b is not in the range of permitted
values.” If values of a, b, and c satisfy conditions c4, c5, and c6, one of four mutually exclusive
outputs is given:
2.2.2 Discussion
Perhaps one of the reasons for the longevity of this example is that it contains clear but complex
logic. It also typifies some of the incomplete definitions that impair communication among cus-
tomers, developers, and testers. The first specification presumes the developers know some details
about triangles, particularly the triangle inequality: the sum of any pair of sides must be strictly
greater than the third side. The upper limit of 200 is both arbitrary and convenient; it will be used
when we develop boundary value test cases in Chapter 5.
Input a, b, c
Match = 0
1. a = b? Y 2. Match = Match + 1
3. a = c? Y 4. Match = Match + 2
5. b = c? Y 6. Match = Match + 3
7. Match = 0? Y
N
8. a + b ≤ c?
N 13. Match = 1? Y
N
Y
N N
Y
Y N Y
18. Match = 3? Y 19. b + c ≤ a? N 10. b + c ≤ a?
N Y
N Y N
Start
Input a, b, c
c1 = 1≤ a ≤ 200
c1? F a invalid
F
T
c2 = 1≤ b ≤ 200
c2? F b invalid
c3 = 1≤ c ≤ 200
Output a, b, c
Triangle
inequalities N Not a triangle
all OK?
a = b AND b = c? Y Equilateral
Output(“Side A is”,a)
Output(“Side B is”,b)
Output(“Side C is”,c)
match = 0
If a = b ‘(1)
Then match = match + 1 ‘(2)
EndIf
If a = c ‘(3)
Then match = match + 2 ‘(4)
EndIf
If b = c ‘(5)
Then match = match + 3 ‘(6)
EndIf
If match = 0 ‘(7)
Then If (a + b)≤ c ‘(8)
Then Output(“NotATriangle”) ‘(12.1)
Else If (b + c) ≤ a ‘(9)
Then Output(“NotATriangle”) ‘(12.2)
Else If (a + c) ≤ b ‘(10)
Then Output(“NotATriangle”) ‘(12.3)
Else Output (“Scalene”) ‘(11)
EndIf
EndIf
EndIf
Else If match = 1 ‘(13)
Then If (a + c) ≤ b ‘(14)
Then Output(“NotATriangle”) ‘(12.4)
Else Output (“Isosceles”) ‘(15.1)
EndIf
Else If match=2 ‘(16)
Then If (a + c) ≤ b
Then Output(“NotATriangle”) (12.5)
Else Output (“Isosceles”) ‘(15.2)
EndIf
Else If match = 3 ‘(18)
Then If (b + c) ≤ a ‘(19)
Then Output(“NotATriangle”) ‘(12.6)
Else Output (“Isosceles”) ‘(15.3)
EndIf
Else Output (“Equilateral”) ‘(20)
EndIf
EndIf
EndIf
EndIf
‘
End Triangle1
2.2.4 Structured Implementations
Program triangle2 ‘Structured programming version of simpler specification
Third version
Program triangle3’
Dim a, b, c As Integer
Dim c1, c2, c3, IsATriangle As Boolean
‘Step 1: Get Input
Do
Output(“Enter 3 integers which are sides of a triangle”)
Input(a, b, c)
c1 = (1 ≤ a) AND (a ≤ 300)
c2 = (1 ≤ b) AND (b ≤ 300)
c3 = (1 ≤ c) AND (c ≤ 300)
If NOT(c1)
Then Output(“Value of a is not in the range of permitted values”)
EndIf
If NOT(c2)
Then Output(“Value of b is not in the range of permitted values”)
EndIf
If NOT(c3)
ThenOutput(“Value of c is not in the range of permitted values”)
EndIf
Until c1 AND c2 AND c3
Output(“Side A is”,a)
Output(“Side B is”,b)
Output(“Side C is”,c)
‘Step 2: Is A Triangle?
If (a < b + c) AND (b < a + c) AND (c < a + b)
Then IsATriangle = True
Else IsATriangle = False
EndIf
‘Step 3: Determine Triangle Type
If IsATriangle
Then If (a = b) AND (b = c)
Then Output (“Equilateral”)
Else If (a ≠ b) AND (a ≠ c) AND (b ≠ c)
Then Output (“Scalene”)
Else Output (“Isosceles”)
EndIf
EndIf
Else Output(“Not a Triangle”)
EndIf
End triangle3
c1. 1 ≤ month ≤ 12
c2. 1 ≤ day ≤ 31
c3. 1812 ≤ year ≤ 2012
As we did with the triangle program, we can make our problem statement more specific. This
entails defining responses for invalid values of the input values for the day, month, and year. We
can also define responses for invalid combinations of inputs, such as June 31 of any year. If any
of conditions c1, c2, or c3 fails, NextDate produces an output indicating the corresponding vari-
able has an out-of-range value—for example, “Value of month not in the range 1...12.” Because
numerous invalid day–month–year combinations exist, NextDate collapses these into one mes-
sage: “Invalid Input Date.”
2.3.2 Discussion
Two sources of complexity exist in the NextDate function: the complexity of the input domain
discussed previously, and the rule that determines when a year is a leap year. A year is 365.2422
days long; therefore, leap years are used for the “extra day” problem. If we declared a leap year
every fourth year, a slight error would occur. The Gregorian calendar (after Pope Gregory) resolves
this by adjusting leap years on century years. Thus, a year is a leap year if it is divisible by 4, unless
it is a century year. Century years are leap years only if they are multiples of 400 (Inglis, 1961);
thus, 1992, 1996, and 2000 are leap years, while the year 1900 is not a leap year. The NextDate
function also illustrates a sidelight of software testing. Many times, we find examples of Zipf’s law,
which states that 80% of the activity occurs in 20% of the space. Notice how much of the source
code is devoted to leap year considerations. In the second implementation, notice how much code
is devoted to input value validation.
2.3.3 Implementations
tomorrowMonth = 3
Else ‘not a leap year
Output(“Cannot have Feb.”, day)
EndIf
EndIf
EndIf
EndIf
EndCase
Output (“Tomorrow’s date is”, tomorrowMonth, tomorrowDay, tomorrowYear)
End NextDate
Case month Of
Case 1: month Is 1,3,5,7,8, Or 10: ‘31 day months (except Dec.)
If day < 31
Then tomorrowDay = day + 1
Else
tomorrowDay = 1
tomorrowMonth = month + 1
EndIf
Case 2: month Is 4,6,9, Or 11 ‘30 day months
If day < 30
Then tomorrowDay = day + 1
Else
If day = 30
Then tomorrowDay = 1
tomorrowMonth = month + 1
Else Output(“Invalid Input Date”)
EndIf
EndIf
Case 3: month Is 12: ‘December
If day < 31
Then tomorrowDay = day + 1
Else
tomorrowDay = 1
tomorrowMonth = 1
If year = 2012
Then Output (“Invalid Input Date”)
Else tomorrow.year = year + 1
EndIf
EndIf
Case 4: month is 2: ‘February
If day < 28
Then tomorrowDay = day + 1
Else
If day = 28
Then
If (year is a leap year)
Then tomorrowDay = 29 ‘leap day
Else ‘not a leap year
tomorrowDay = 1
tomorrowMonth = 3
EndIf
Else
If day = 29
Then
If (year is a leap year)
Then tomorrowDay = 1
tomorrowMonth = 3
Else
If day > 29
Then Output(“Invalid Input Date”)
EndIf
EndIf
EndIf
EndIf
EndIf
EndCase
Output (“Tomorrow’s date is”, tomorrowMonth, tomorrowDay, tomorrowYear)
‘
End NextDate2
2.4.1 Problem Statement
A rifle salesperson in the former Arizona Territory sold rifle locks, stocks, and barrels made by a
gunsmith in Missouri. Locks cost $45, stocks cost $30, and barrels cost $25. The salesperson had to
sell at least one lock, one stock, and one barrel (but not necessarily one complete rifle) per month,
and production limits were such that the most the salesperson could sell in a month was 70 locks,
80 stocks, and 90 barrels. After each town visit, the salesperson sent a telegram to the Missouri
gunsmith with the number of locks, stocks, and barrels sold in that town. At the end of a month,
the salesperson sent a very short telegram showing –1 lock sold. The gunsmith then knew the sales
for the month were complete and computed the salesperson’s commission as follows: 10% on sales
up to (and including) $1000, 15% on the next $800, and 20% on any sales in excess of $1800.
2.4.2 Discussion
This example is somewhat contrived to make the arithmetic quickly visible to the reader. It might be
more realistic to consider some other additive function of several variables, such as various calculations
found in filling out a US 1040 income tax form. (We will stay with rifles.) This problem separates into
three distinct pieces: the input data portion, in which we could deal with input data validation (as we
did for the triangle and NextDate programs), the sales calculation, and the commission calculation
portion. This time, we will omit the input data validation portion. We will replicate the telegram
convention with a sentinel-controlled while loop that is typical of MIS data gathering applications.
2.4.3 Implementation
Welcome to
4 5 6 Enter
7 8 9 Clear
0 Cancel