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


1.7
date	92.11.11.11.02.58;	author marlow;	state Exp;
branches;
next	1.6;

1.6
date	92.11.11.08.34.52;	author lacey;	state Exp;
branches;
next	1.5;

1.5
date	92.11.11.08.18.44;	author lacey;	state Exp;
branches;
next	1.4;

1.4
date	92.11.11.08.07.15;	author lacey;	state Exp;
branches;
next	1.3;

1.3
date	92.11.10.19.42.25;	author gaubert;	state Exp;
branches;
next	1.2;

1.2
date	92.11.10.00.17.38;	author gaubert;	state Exp;
branches;
next	1.1;

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


desc
@@


1.7
log
@*** empty log message ***
@
text
@%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Describes the overall strategy for integration. Testing is divided
% into phases and builds that address specific functional and behavioral 
% characteristics of the software. 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Test Plan}

  Testing of the xplan software for PERT/Gantt Chart Generation from a
project task list will have all test phases check for interface
integrity, functional validity, information content, and performance
in a bottom up testing strategy starting with the main modules and
their supporting submodules and functions.  Internal and external
interfaces will be tested as each module, and cluster of modules is
incorporated into the system structure for xplan.  Tests will be
designed and performed to uncover functional and logical errors.
Tests will focus on discovering errors regarding local and global data
structures, and their usage.  Finally tests will be conducted to
determine a performance bound for xplan which will be specified when
the final product is delivered to the customer.
 
  The overall plan for testing xplan, is to focus on test procedures
for each of the main modules described in the detailed design
document\cite{detailed-design}.  Those main modules are the database, ASCII text file input,
Graphical User Interface (GUI), PERT/Gantt Chart critical path
calculations module, ASCII textfile output generator module, and \LaTeX\
file format output generator module.  For each of these modules, a
specific test procedure is described in detail, with emphasis on
testing the interface integrity, functional validity, information
content, and performance for each main module.  Also, details for
testing submodules and supporting function units will be described in
the test procedure for a main module.  In general, testing techniques
such as white box and black box testing will be applied to each main
module and submodule.  Furthermore, unit tests will be applied to each
functional unit to check interfaces, local data structures, boundary
conditions, independent paths, and error handling paths.  Also, other
test procedures described in the class and lectures will be applied to
modules if they are appropriate for testing certain functions and
qualities.  Driver programs and stubs will be generated as necessary
for testing specific modules and functions.  Furthermore, the group
will conduct a review process for each major module described in the
detailed design document when it is ready to be integrated into the
system level of xplan.  This review process will range from casual
conversation and peer group review to a formal code walk through for
critical modules such as critical path calculations, and graphical
display and output of PERT/Gantt charts.  The emphasis of the review
process will be in building quality into the xplan software, and
evaluating the results and implications of test procedures and data.
Basically, reviews are meant to be a second check on the testing
process.  If tests display errors such as logical, syntax, and design,
the xplan main modules and supporting submodules will be edited and
revised as necessary to achieve desired performance.  The desired
performance of xplan software is described in the requirements
specification and detailed design documents.

   Basically, our test plan has the two goals of achieving
verification and validation of the xplan software.  Verification
testing is done to insure that main modules, and supporting submodules
and function perform correctly as designed in the detailed design
document, and throughout the coding process of xplan.  Validation
testing will be performed once all main modules of xplan are fully
integrated and the system software functions correctly according to
our test goals.  Validation testing will be performed to insure that
xplan meets all of its design goals and requirements from the
customers perspective, as we described in the requirements document.
The ultimate system level test case data used to test xplan, will be
our groups PERT/Gantt chart data generated for this project from MS
Project which was included in our project plan document.  Basically,
we will check to see that our critical path for a project is
calculated correctly by comparing the results of xplan with the
results of MS Project.  Also, we will compare our graphical displays
of PERT/Gantt charts with those of MS Project.  We are using MS
Project as a competitive software test case, since MS Project is a
commercial software product very similar to the design goals of xplan.
Persons performing the final system level test will be all group
members of the xplan design team, before it is delivered to the
customer.



\subsection{Test phases and builds}

  The xplan software for PERT/Gantt chart generation from a project
task list will be tested and build in several phases.  However, it is
important to note that the test phases and builds will be done in
parallel whenever possible.  However, the first main module of the
detailed design document to be tested and built first is the database
module. That is because all other modules call on the database module
to supply them with PERT/Gantt chart task lists and task information.
Next, the database module will be integrated with the Graphical User
Interface (GUI) module.  After the two are tested together and are
shown to be working and interfacing correctly, the ASCII text file
input module will be integrated into the xplan software.  At that
point, the database, user commands and data input functions are known
to be fully functional after they finish integration testing.
Meanwhile, the test work and development for the PERT/Gantt chart
critical path calculations module, the \LaTeX\ file output format,
ASCII text file output format, and the graphical display of
PERT/Gantt charts to the canvases of the PERT and Gantt popup windows
of the GUI are done simultaneously.  By having four members on the
xplan design team, we are able to perform separate module testing and
building tasks in parallel.  Then, when a modules dependencies have
tested to our satisfaction, by fulfilling the criteria set for them in
the xplan requirements specification and detailed design documents, we
will perform integration testing of all aspects of xplan's system
software.

\subsection{Schedule}

  The current schedule for completing test phases and builds for the various modules
and system software for xplan is the following:
\begin{description}
\item [November 11, 1992] Testing Specifications document for xplan due.
\item [November 12, 1992] The database development and testing should be finished.
\item [November 17, 1992] Portions of the Graphical User Interface(GUI) what support entry
and retrieval of PERT/Gantt chart project task lists, and task information should be 
completed and tested.  The xplan input and output file subsystem should also be completed 
and tested. The GUI, file subsystem, and database modules should all be integrated and
tested.
\item [November 18, 1992] The first highlevel practice demo of xplan for the customer will
be performed for customer input and reaction to the xplan software development.
\item [November 21, 1992] The calculations subsystem should be completed and integrated
with the GUI.
\item [November 28, 1992] The \LaTeX\ generation module should be completed and integrated with
the GUI
\item [December 3, 1992] The official practice demo of the xplan system software will be 
performed, so customer input regarding the validation of requirements specifications can
be assessed.
\item [December 7, 1992] The official demonstration of xplan system software is due.  All 
last minute testing must definitely be finished and demonstrate xplan meets the customers
expectations as specified in the requirements specification document.

\item   [NOTE:] The hard deadlines are those stipulated by the customers who are Dr. Cheng, and
Jerry Gannod.  The soft deadlines are projected by the xplan design team for our own
benefit in scheduling the progress of xplan's development.

\end{description}

\subsection{System Overhead Software}

  Once all of the modules are fully integrated and tested to verify
their functionality and validate their requirements specifications,
the xplan system software can be tested.  The way that xplan system
software will be tested is by user interaction with the GUI by design
team members like the customer will use the product.  However, the MS
Project software will be used as a tool to compare the performance of
the xplan system software.  The PERT/Gantt chart data input to MS
Project for our project plan document will be entered as test data to
the final xplan system software for generating PERT/Gantt chart
information from a project task list.  We will compare the performance
of xplan to that of MS Project as a test procedure to help assess the
quality of xplan's performance.  The reason MS Project was chosen as a
competitive test comparison, is that MS Project is a commercial
product which is widely available, and MS Project is the only tool
available to us for calculating PERT/Gantt charts.

   Finally, no driver program will be written to test the fully
implemented xplan system software, because xplan was specifically
designed to be operated by interactive communication with a human user
in real time.

\subsection{Environment and Resources}
  The environment in which the testing will be done is a workstation
running the Unix operating system, along with X Windows and a
window manager. This is the same environment in which the
program should be executed in normal use. The initial startup of the program must come from a shell or
console window. When the user is ready to run the program it will be
done by the command line argument xplan filename.prj, where
filename.prj is the name of the file that contains the tasks from a
previous session of the program. If the user wants to start a new
session, he/she can type in the command xplan.

  The hardware resources for the testing procedures of the project will
involve a workstation such as the Sun SPARCstation I, II, IPC, IPX or NEXTstations. Other
resources include software and people. From the software stand point,
Open Windows or X Windows must be used to support the interface of
the project. Since most of the integration testing will be done from the
interface, Open Windows or X Windows is a must.

  The debugging tool {\tt dbx} will be used in the testing process of the
xplan software. When the program is being compiled, the -g option will
be used. This option will build a symbol table for the program that
includes the names of all of the source files used to build the
program at compilation time. The debugging tool will create a shell
where the user can set breakpoints, look at the values of the
variables, trace through different sections of code, and append to the
modules that are to be tested within the program. Unfortunately, the
{\tt dbx} debugger will not work with the output from  program generators
such as {\tt flex} and {\tt bison}\footnote{The man pages for the dbx debugger say that such tools confuse it.}.
@


1.6
log
@*** empty log message ***
@
text
@d23 1
a23 1
document.  Those main modules are the database, ASCII text file input,
d25 1
a25 1
calculations module, ASCII textfile output generator module, and LaTeX
d82 1
a82 1
  The xplan software for PERT/Gantt chart Generation from a project
d96 2
a97 2
critical path calculations module, and the LaTeX file output format,
and ASCII text file output format, and the graphical display of
d104 1
a104 1
will perform integration testing of all aspects of xplans system
d123 1
a123 1
\item [November 28, 1992] The LaTeX generation module should be completed and integrated with
d132 1
a132 1
\item   [NOTE:] The hard deadlines are those stipulated by the customers who are Dr.\ Cheng, and
d134 1
a134 1
benefit in scheduling the progress of xplans development.
d146 2
a147 2
the xplan system software.  The PERT/Gantt chart data inputed to MS
Project for our project plan document will be input as test data to
d152 3
a154 2
competitive test comparision, is that MS Project is a commercial
product which is widely available.
d163 1
a163 1
running the Unix operating system, along with X Windows and some
d167 1
a167 1
done by the command line argument xplan filename.prj , where
d173 1
a173 1
involve a workstation such as the Sun SPARSstation I, II, IPC, IPX or NEXT stations. Other
d187 2
a188 2
{\tt dbx} debugger will not work with the output from the program generators
of {\tt flex} and {\tt bison}\footnote{The man pages for the dbx debugger say that such tools confuse it.}.
@


1.5
log
@*** empty log message ***
@
text
@a106 2


d161 9
d171 6
a176 8
The environment to which the testing will be done will come from the
Open Windows environment. This will be the same environment in which
to run the program. The initial startup of the program must come from
a shell or console window. When the user is ready to run the program
it will be done by the command line argument xplan <filename>.task ,
where <filename>.task is the name of the file that contains the tasks
for a previous secession of the program. If the user wants to start a
new secession of the program, he/she can type in the command xplan.
d178 3
a180 16
The resources for the testing procedures of the project xplan will
involve a terminal such as the SPARC I, SPARC II, NEXT machines, SUN
3, SUN 4, or the SPARC station IPX's. This will be the resources
needed for hardware in in the testing phase of the project. Other
resources involve software and people. From the software stand point,
Open Windows or X Windows must be used to initialize the interface of
the project. Since most of the testing will be done from the
interface, Open windows or X Windows is a must. On machines that are
used either by the case center, the SPARC station IPX's, or the NEXT
machines, the user must set up the display with the xhost and setenv
commands.  This will set up the display such that the xplan interface
can be run.

The debugging tool, DBX, will be used in the testing process of the
xplan project. When the program is being compiled, the -g option will
be on. This option will build a symbol table for the program that
d186 2
a187 3
DBX debugger will not work with the output from the program generators
of Flex and Bison.

@


1.4
log
@*** empty log message ***
@
text
@d8 46
d55 22
a79 31








%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% You will need to test at the high-level module level, 
% and then test as you put together the different pieces
% of the system.
%
% A sample breakdown is as follows:
%
%	1. User interaction or top level user interface: 
%	(command selection, drawing creation, display 
%	representation, error processing and representation)
%
%	2. Data manipulation and analysis: (symbol creation, 
%	 computation of positions of graphical entities, 
%	 manipulation of input data -- transformation of data from
%	 parsing activities, and generation of new data based on
%	 input data.
%	
%	3. Display processing and generation:
%	(placement of graphical components onto drawing canvas, 
% 	generation of new GUI elements)
%
%	4. Database management (access, update, integrity, performance) 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
d82 24
a108 13







%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% A schedule for conducting the tests and the integration is discussed
% in the following subsection. Start and end dates for each phase are 
% established and dates when specific modules will be available are 
% established. 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
d111 22
d134 3
d138 1
d140 1
d142 14
d157 4
a161 67










%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% A brief description of overhad software (stubs and drivers) concentrates 
% on characteristics that might require special effort.
%
% Criteria for testing and corresponding tests:
%
% 	1. Interface integrity: internal and external interfaces are
%	tested as each module (or cluster) is incorporated into the
%	structure.
%
%	2. Functional validity: tests designed to uncover functional errors
%	are conducted.
%	3. Information content: tests designed to uncover errors associated 
%	with local or global data structures are conducted.
%	
%
%
% A brief description of overhad software (stubs and drivers) concentrates 
% on characteristics that might require special effort.
%
% Criteria for testing and corresponding tests:
%
% 	1. Interface integrity: internal and external interfaces are
%	tested as each module (or cluster) is incorporated into the
%	structure.
%
%	2. Functional validity: tests designed to uncover functional errors
%	are conducted.
%
%	3. Information content: tests designed to uncover errors associated 
%	with local or global data structures are conducted.
%
%	
% 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Overhead software}
















%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Test environment and resources are described. Unusual hardware 
% configurations, exotic simulators, special test tools might
% be discussed in this section. 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@


1.3
log
@This version includes the Evironment and R part of the testing spec
@
text
@d137 34
a170 1
\include{Env-Resources}
@


1.2
log
@Brian: I have incorperated the Environment and resources section of the testing spec.
@
text
@d137 1
a137 32
  The environment to which the testing will be done will come from the
Open Windows environment. This will be the same environment in which
to run the program. The initial startup of the program must come from
a shell or console window. When the user is ready to run the program
it will be done by the command line argument xplan <filename>.task ,
where <filename>.task is the name of the file that contains the tasks
for a previous secession of the program. If the user wants to start a
new secession of the program, he/she can type in the command xplan.

  The resources for the testing procedures of the project xplan will
involve a terminal such as the SPARC I, SPARC II, NEXT machines, SUN
3, SUN 4, or the SPARC station IPX's. This will be the resources
needed for hardware in in the testing phase of the project. Other
resources involve software and people. From the software stand point,
Open Windows or X Windows must be used to initialize the interface of
the project. Since most of the testing will be done from the
interface, Open windows or X Windows is a must. On machines that are
used either by the case center, the SPARC station IPX's, or the NEXT
machines, the user must set up the display with the xhost and setenv
commands.  This will set up the display such that the xplan interface
can be run.

  The debugging tool, DBX, will be used in the testing process of the
xplan project. When the program is being compiled, the -g option will
be on. This option will build a symbol table for the program that
includes the names of all of the source files used to build the
program at compilation time. The debugging tool will create a shell
where the user can set breakpoints, look at the values of the
variables, trace through different sections of code, and append to the
modules that are to be tested within the program. Unfortunately, the
DBX debugger will not work with the output from the program generators
of Flex and Bison.
@


1.1
log
@Initial revision
@
text
@d137 32
@
