R. Clayton (rclayton@monmouth.edu)
Wed, 29 Mar 2000 12:14:00 -0500 (EST)
I'm not sure what a good structural test would be. Would it entail just
looking at the diagram in the SDD and making sure the modules in the code are
split up as they should be?
Structural, or white box, tests, are conducted with a knowledge of the
structure - that is, code - of the unit under test. This is in distinction to
functional, or black box, tests, which are conducted with a knowledge of only
the expected input-output behaviors of the unit under test.
To do a structural test, you first pick a unit to test; I recommend one of the
smaller procedures or methods in your code. A procedure or method is
recommended because they're the smallest, self-contained units in your code. A
small procedure or method is recommended because it cuts down on the work you
have to do to design and run the test (but pick a unit with some meat to it;
don't test a trivial, one-line unit).
Once you've got the unit, figure one or two types of faults to test for. It
would be nice, but not necessary, if the faults being tested for are related to
the unit being tested. For example, if the unit to test is a procedure that
strips white space from the start of a line, you might test to make sure all
types of white space is stripped, or you might test to ensure that a line
containing only white space is handled properly.
Once you've got the fault types determined, set the test data criteria. The
criteria to use is up to you, but you should try to avoid picking trivial
criteria for the unit being tested; for example, don't use the all-paths
criteria on a procedure with straight-line code, use one of the data criteria
(on the other hand, exceptions form paths through, and the all-paths criteria
can be difficult to meet in straight-line code that throws exceptions). It
would be nice, but not necessary, if the test criteria related to the fault
types; for example, if you want to force buffer overflows, it would probably be
better to use data-flow criteria rather than control-flow criteria.
With criteria available, you can generate the test sets, list the expected
faults, describe the testing procedure, and, if possible, run the tests,
recording the results. If you generate a lot of test data, you should write a
summary of the results; otherwise, just make sure they're neatly organized and
presented.
This archive was generated by hypermail 2.0b3 on Thu Mar 30 2000 - 20:50:05 EST