head	1.3;
access;
symbols;
locks; strict;
comment	@% @;


1.3
date	92.11.11.10.48.24;	author marlow;	state Exp;
branches;
next	1.2;

1.2
date	92.11.11.08.02.11;	author marlow;	state Exp;
branches;
next	1.1;

1.1
date	92.11.07.22.42.44;	author lacey;	state Exp;
branches;
next	;


desc
@@


1.3
log
@*** empty log message ***
@
text
@%
%  This section provides a high level overview of the system.
%  Discuss the scope of the testing. (Recall the guidelines for
%  for testing that you gave in the preliminary-design document.
%  It should summarize the specific functional, performance, and internal
%  design characteristics that are to be tested.
%  The testing effort is bounded, criteria for completion of each test phase
%  should be described, and schedule constraints are documented.
% 
\section{Scope of Testing}

  This document describes the testing of the specific functional, performance, and internal
design characteristics of the xplan PERT/Gantt Chart Generator software
project for CPS 470.  The goals of the xplan testing program are for 
verification testing at the major module unit level, and for validation
testing at the system level after the integration and integration testing of all the
xplan modules is complete.  The major modules to be tested are: Graphical User Interface
(GUI) and interfaces to xplan modules and functions for processing, Database module, 
Calculations module for determining the critical path for task dependencies of a PERT/Gantt
Chart, \LaTeX\ file format output generator module, ASCII text file format input module with
supporting flex and bison code, ASCII text file format output generator module,
Graphical display of PERT/Gantt charts drawn on the  X Windows Canvas for xplan's GUI.  
The hard dates for xplan testing are those dates that documents and code are due as
described by Dr. Cheng.  However, the group has set several internal dates
for major testing activities to be completed by.  These dates are described
in the xplan Test Schedule section of this document.

   The way that xplan's software test program will be performed is the
following bottom up strategy.  First, unit testing will focus verification effort 
on the smallest xplan software units which are functions and submodules for the  major modules
described in the detailed design document.  Furthermore, a variety of test methods are
available as described in Dr Cheng's CPS 470 lectures and the class text.  
The methods used to test specific functional modules will depend on the
complexity and performance of that module.  However, in general, white box testing
will be used to do bottom up testing of all supporting functional units called by module.
Attention will be focussed on issues such as interfaces, data structures, algorithms,
and logic as they relate to specific issues of a module and supporting 
functional units.  Once the small scale testing is complete for the components
of a module, then black box testing will be performed for the entire 
module to check that it functions correctly and produces correct output as described in
the detailed design document, and the requirements specification document.  
 
  Integration testing will be performed to  verify that all functions and components
of a major design module are called, and communicate correctly.
Basically, white box testing is done to check for logical errors at the
small scale functional unit level, and black box testing is to check for correct 
performance at the module level.   The ultimate goal of our testing process is
to build quality into the final xplan product by insuring that functions, components,
and modules work correctly before they are interfaced with others, and integrated into the
final system for the xplan software.  If testing activities reveal problems with
logic, syntax, or design, then modules and their supporting submodules and functional
units will be edited and revised as necessary.
 
  The final system will be extensively tested by the group members before
delivery the the customers.  Also, a formal code walk through review of all aspects
of xplans software will be conducted before delivery to the customer. Furthermore, 
practice demos will be performed with the customer to show that the functionality and
performance described in the xplan requirements specification document has been 
implemented.


@


1.2
log
@*** empty log message ***
@
text
@d14 1
a14 1
project for cps 470.  The goals of the xplan testing program are for 
d16 5
a20 6
testing at the system level after the integration of all the xplan modules
is complete, and integration testing has finished.  The major modules to be
tested are: Graphical User Interface (GUI) and interfaces to xplan modules
and functions for processing, Database module, Calculations module for 
determining the critical path for task dependencies of a PERT/Gantt Chart, 
LaTeX file format output generator module, ASCII text file format input module with
d29 1
a29 1
following bottom up strategy.  First, Unit testing will focus verification effort 
d32 1
a32 1
available as described in Dr Cheng's cps 470 lectures and the class text.  
d34 1
a34 1
complexity and performance of that module.  However, in general, White Box testing
d39 1
a39 1
of a module, then Black Box testing will be performed for the entire 
d60 2
@


1.1
log
@Initial revision
@
text
@d1 1
a1 1
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
d9 1
a9 1
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
d11 50
@
