Criteria |
Comparison |
Architectural Validation |
Top-down testing is
better suited than bottom-up testing for early detection of system
architecture errors and high-level design errors. Early detection
reduces the cost of fixing the errors. |
System Demonstration |
A top-down approach to
testing allows the organization to quickly gain confidence in a
skeletal system that can then be used for demonstration purposes. A
bottom-up approach uses drivers at the highest system levels which
would likely be more cumbersome to demonstrate. |
Test Implementation |
Top-down testing will
generally place more of a burden on the development team since
meaningful stub behavior will be required for the system to be tested.
Stubs can become quite complex in order to provide the necessary
behavioral characteristics. Reusable components, on the other hand,
provide stable behavior and therefore developers do not need to be
quite as creative when creating the drivers that drive those low-level
components. |
Test Observation |
Top-down and bottom-up
testing are about equal on this criteria. High-level components
aren’t necessarily meant to generate observable output and
must be made to do so using an artificial environment. Likewise,
low-level components may need an artificial environment in order to
probe their internal behavior. |
Sub-System |
Test Description |
Command Processing
System Testing |
Tests for errors in
integration and functioning of system sub-components.
Assures proper operation of Input Monitoring and
Processing, Clock, Timer, Auto Cook, and Auto Defrost functions. |
Cooking Control System
Testing |
Tests for errors in
integration and functioning of cooking control function and oven
control function. |
Output Processing System |
Tests for errors in
integration of timer display, clock display, and beeper signaling. |
No part of this work should be produced or used without the permission of the authors: Michael Turner and Dr. Sharon A White.