-------------------
CEN 4072/6070 Software Testing & Verification ------------------Exam 1 -- Spring 2010 – Solution Notes
1. a. is, b. is, c. is not, d. is, e. is not, f. is, g. is
2. d
3. d
4. b
5. a
6. c
7. d
8. a. The members of both teams were taught the Fagan inspection method, but
the course they attended included little about how to use metrics to improve
the process.
Both teams had some success with code inspections but felt that they weren’t
getting the ROI they should – especially with non-code documents
(requirements, etc.).
One team gradually stopped using inspections, while the other set about
trying to improve the process in various ways, such as adjusting the
inspection speed according to the potential for defects, having inspectors
report their preparation time and the number of defects they found at the
start of each inspection meeting, etc. All the changes resulted in more
successful non-code inspections.
b. The lessons learned by the experiences of these two project teams were:
(1) the importance of taking the initiative to adjust the inspection process,
(2) that training by itself is not enough to ensure success, and that
(3) an unsuccessful experience makes it difficult for teams to try inspections
again.
9. a. 3X4=12
b.
TEST CASE TEMPLATES
CAUSES
1
2
3
4
5
6
7
(6)
T
T
T
T
T
T
F
(7)
T
T
T
F
F
F
T
(8)
F
T
F
F
T
F
T
(9)
T
F
F
T
F
F
F
T
T
T
T
T
T
T
EFFECT
(26)
c. Test cases 1, 2, 3, and 6 would be eliminated.
2
The specified functions were: fmod, which returns the floating-point
10.
remainder of the division of x by y, and sort, which sorts, merges, or
sequence checks text files.
fmod is a relatively simple function that can easily be modeled by a
small number (the solution notes identified 5) of mutually exclusive
effects combining the specified behaviors of fmod and matherr. A
major advantage of this approach is that it easily allows for the
coverage of all combinations of such behaviors by associating test
cases with each feasible combination of connected Causes in the
Cause-Effect graph. This could be accomplished using a relatively
small number of cases for fmod.
In contrast, sort has a relatively complex interface with a large
number of mostly independent parameters and arguments. Attempting
to identify mutually exclusive Effects for this function would require
identifying an extremely large number of behavioral combinations,
where many of the behaviors would almost certainly be independent of
one another. Thus, attempting to identify mutually exclusive Effects for
sort would probably not be appropriate.
11. c
12. P, N, Q, A, L, J, M, F, C, O, G, I
13. a.
1. input(X,Y)
while (Y>0) do
2.
Y := Y-X
end_while
3. if (X<0) then
4.
X := -X
end_if
5. output(X,Y)
1
Y 0
input(X,Y))
Y> 0
2
Y := Y-X
Y> 0
Y 0
3
X≥ 0
X< 0
4
5
X := -X
output(X,Y)
b. In addition to (1,5): (1,2) (1,4) (1,<3,4>) (1,<3,5>) (4,5)
c. In addition to (1,5): (1,2) (1,<1,2>) (1,<1,3>) (2,2) (2,5) (2,<2,2>)
(2,<2,3>)
d. <1,3,5> <1,2,3,5> <1,2,2,3,5>
e. Y>0 & Y-X>0 & Y-2X <=0 & X<0
f. none
3
14. a. is not, b. is, c. is not, d. is, e. is not, f. is
15. An “implicit part of the specification for pow()” included the mathematical
definition of exponentiation. By seeking out the definition in a standard math
dictionary, it was discovered that x**y really MEANS different functions
depending on what region (point, line, etc.) in the x,y plane the input reflects.
These functional differences were then modeled as separate non-error Effects in
our test case design model. (Note that the pow MAN page explicitly referenced
matherr.)
16. Encapsulation (of methods and state): It can be problematic when the effects
of operations being tested are private and therefore “hidden” from the tester.
Special instrumentation may be required to interpret the effects of methods
that result in hidden state changes, or to access methods that are themselves
private.
State dependent behavior of methods: The behavior of methods depends on
both their parameters or “inputs” and the underlying state of the object. Thus,
testing techniques which assume stateless program behavior should be
avoided.
Inheritance: Inheritance is an abstraction mechanism that allows object classes
to be specialized or extended from one or more other object classes. When
attributes and methods are inherited from ancestor classes, determining which
methods need to be re-tested can be problematic.
Polymorphism and Dynamic Binding: When variable types and method bindings
can change dynamically, testers must utilize techniques to determine which
combinations of types and bindings to test.