top - download
⟦ff9a82b9d⟧ Wang Wps File
Length: 15377 (0x3c11)
Types: Wang Wps File
Notes: CPS/TSP/001
Names: »0341A «
Derivation
└─⟦1304ed705⟧ Bits:30006073 8" Wang WCS floppy, CR 0030A
└─ ⟦this⟧ »0341A «
WangText
…02…CPS/TSP/001
…02…KNN/810521…02……02…#
SOFTWARE
TEST PLAN
…02…Issue
1…02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL ......................................
4
1.1 PURPOSE AND SCOPE ..........................
4
1.2 PROJECT REFERENCES .........................
5
1.3 TERMS.......................................
5
2 UNIT TEST REQUIREMENTS .......................
6
2.1 UNIT DEFINITION ............................
6
2.2 TESTING APPROACH ...........................
7
2.3 TEST SPECIFICATION .........................
8
2.3.1 Capability Testing .....................
8
2.3.2 Structural Testing .....................
8
2.4 TEST PROCEDURES ............................
10
2.4.1 Facilities Required ....................
10
2.4.2 Set-up Conditions ......................
10
2.4.3 Sequence of Events .....................
10
2.5 TEST BED ...................................
11
3 TEST MANAGEMENT ..............................
12
3.1 UNIT DEVELOPMENT ...........................
12
3.2 UNIT TEST SCHEDULE .........................
15
3.3 ORGANIZATIONAL RESPONSIBILITIES ............
17
1 G̲E̲N̲E̲R̲A̲L̲
1.1 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲
The purpose of this plan is to establish the level
of thoroughness by which the unit testing shall be
conducted.
Furthermore, the plan contains a description of how
the project will conduct and monitor unit testing.
Unit testing is the first step in a series of tests.
The types of testing which shall be distinguished
are:
1) U̲n̲i̲t̲ ̲t̲e̲s̲t̲i̲n̲g̲: Tests a piece of software against
the specifications imposed on it in the design
phase. This usually means testing against detailed
design.
2) I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲t̲e̲s̲t̲i̲n̲g̲: Tests whether a unit tested
piece of software interfaces properly with other
units and whether these units function properly
together within a higher level of integration.
This is mainly a verification of the consistency
of detail design with architectural design.
3) Q̲u̲a̲l̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲t̲e̲s̲t̲i̲n̲g̲: Systematically tests a
completely integrated piece of software and its
parts against the functional performance and interface
specifications on which the design was based.
This amounts to testing the design against the
requirements specifications.
CAMPS software integration will be described in a separate
plan CPS/TSP/002.
Qualification tests of CAMPS developed software are
described in the CAMPS Acceptance Plan (CPS/PLN/012),
that describes the following software tests:
- in-plant software test.
- software functional test.
- software operational test.
This plan only describes verification by means of testing.
Other verification methods are described in the CAMPS
system development plan, CPS/PLAN/002, chapter 5.
1.2 P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
- CAMPS Program Implementation Plan
CPS/100/PIP/0001
- System Development Plan
CPS/PLN/002
- CAMPS Acceptance Plan
CPS/PLN/012
- CAMPS Software Integration Plan
CPS/TSP/002
1.3 T̲E̲R̲M̲S̲
C̲A̲M̲P̲S̲ ̲s̲o̲f̲t̲w̲a̲r̲e̲ ̲p̲a̲c̲k̲a̲g̲e̲s̲ make up to first level break-down
of the application software and system software subsystems.
A u̲n̲i̲t̲ is any piece of software, which has relatively
few interfaces to other pieces of software. Software
packages are normally made up of 5-10 units.
A m̲o̲d̲u̲l̲e̲/̲r̲o̲u̲t̲i̲n̲e̲ is the smallest compilable piece of
software
2 U̲N̲I̲T̲ ̲T̲E̲S̲T̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
2.1 U̲n̲i̲t̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
A unit is any i̲n̲d̲e̲p̲e̲n̲d̲e̲n̲t̲ piece of software.
A software system may be divided into packages, modules,
routines, and elementary processes, or any other division
using different designation at the various levels.
The word unit is used to designate any piece of software
regardless of its size or its level in a hierarchy.
For the purpose of testing, an independent unit is
any piece of software which has relatively few interfaces
to other pieces such that those few interfaces may
be easily simulated and monitored for each such unit
a Unit Development Folder exists.
Whenever the development of a software system leads
to the definition of such a unit and this unit is given
some kind of independence in the further development,
a Unit Development Folder (UDF) shall be established,
(the system itself is the first unit to be identified).
2.2 T̲E̲S̲T̲ ̲A̲P̲P̲R̲O̲A̲C̲H̲
Units shall during unit testing be exhaustively tested
as independent entities. This will reduce the testing
required during integration of units to testing of
interfaces.
As indicated above, units can exist at different levels
in the software hierarchy. Units at one level can
therefore contain units at lower levels.
During unit testing of a higher level unit, lower level
units shall not be included in the unit test at the
higher level. Instead stubs simulating the functions
of the lower level units shall be inserted.
During integration of units, the stubs are replaced
with the actual lower level units which have been carefully
tested at their own level.
Integration shall start with the higher level of unit(s).
By successively joining verified units at the lower
level, level by level, integration continues until
the lowest level of units has been integrated.
2.3 T̲E̲S̲T̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
Software units shall be tested by test cases.
The total set of test cases developed for Unit Testing
shall demonstrate:
1) that the software unit meets its functional, performance,
timing, sizing and interface specifications.
2) that all code was sufficiently exercised to establish
confidence in its reliability in normal, marginal,
and abnormal operational environments.
Consequently, one subset of the test space must be
designed against the requirements whereas the other
subset must be designed against the implemented software
independent of the specifications on which its design
was based.
2.3.1 C̲a̲p̲a̲b̲i̲l̲i̲t̲y̲ ̲T̲e̲s̲t̲
All units shall be associated with a clear specification
of the functional, performance, timing, sizing and
interface requirements.
A cross reference between requirements and test cases
shall be established to make sure that all requirements
are tested.
2.3.2 S̲t̲r̲u̲c̲t̲u̲r̲a̲l̲ ̲T̲e̲s̲t̲i̲n̲g̲
In testing against the implemented code three aspects
shall be distinguished:
- Correctness of the control paths executed under
given input conditions as well as executability
of all code.
- Correctness of data access and determination of
access addresses.
- Correctness of the calculations performed on that
path.
a) A path shall be defined by an entry point, an exit
or abortion point and a set of loop counts and
selection exits from which the exact sequence of
actually executed instructions can be reconstructed.
To as large an extent as practicable, independent
substructures shall be derived and test cases developed
to test the paths within each of these substructures
independently of the others. Independence should,
if possible, be construed to mean operation on
different subsets of data space.
b) The test cases shall at least exercise every alternative
of a selection, demonstrate proper termination
of variable count loops for several loop counts,
demonstrate proper data access for several destinations,
and exercise every compound statement in all of
its modes.
This effectivity of the test cases shall be proven
by appropriate monitoring and tracing tools.
c) Errors in the calculations performed on a given
path are of two kinds.
1) Errors which appear on every execution of the
path (unconditional errors e.g. wrong or missing
statement, wrong address etc.).
2) Errors depending upon the value of the variables
processed (conditional errors e.g. overflow,
insufficient precision of results etc.)
The first class is completely discovered through
the all branches/all modes requirement.
The probability of detecting errors of the second class
shall be made sufficiently high by supplying a test
space which exercises critical sequences with at least
three different sets of off nominal inputs (e.g. marginal,
extreme, singular, boundary value, wrong type or format,
out of bounds, null, missing or other data and control
parameters which are unusual with respect to singularities
of the function or limits of the computer).
2.4 T̲e̲s̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
For each of the test cases, specified according to
section 2.3, a procedure shall be established.
The procedures shall specify:
- facilities required
- set-up conditions
- sequence of event
- acceptance criteria
2.4.1 F̲a̲c̲i̲l̲i̲t̲i̲e̲s̲ ̲R̲e̲q̲u̲i̲r̲e̲d̲
A section in the test procedures shall contain the
minimum facilities required to run the test case in
the test facility.
2.4.2 S̲e̲t̲-̲U̲p̲ ̲C̲o̲n̲d̲i̲t̲i̲o̲n̲s̲
The test set-up conditions shall describe all external
environmental conditions that have a bearing on the
test.
2.4.3 S̲e̲q̲u̲e̲n̲c̲e̲ ̲o̲f̲ ̲E̲v̲e̲n̲t̲s̲
The test sequence of events must be updated to show
all actions required to run the test in the test facility,
and expected results for that test facility.
2.5 T̲E̲S̲T̲ ̲B̲E̲D̲
In connection with the development of a software unit
a complete test bed shall be developed and utilized
in unit testing.
The Test Bed shall be released with the unit and be
available in the future as a basis for tests after
modifications and to be integrated in the integration
test bed as appropriate.
The Test Bed shall consist of:
a) Test Driver
- If the unit under test is not a selfstanding
program, the test driver shall contain the
necessary control structure to invoke the functions
of the test item.
- If the test item does not access its input
data directly, the test driver shall contain
means for accessing proper input data and convey
them to the unit.
- If the test item does not produce direct output
the test driver shall contain means for accepting
output from the unit and store them in a test
output file.
b) Test Data
A Test Data file shall contain all the necessary
data to exercise the test.
c) Test Output File
An output file shall be available for retaining
the results of a test run. The latest test results
shall always be kept on a copy in order to compare
it with the result of a new run.
d) Stubs
One or more stubs as necessary to simulate the
functions of other units with which the unit under
test normally interfaces.
The simulation may be primitive but shall be sufficient
to support the ongoing test.
3 T̲E̲S̲T̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲
This chapter contains a description of how the project
will conduct and monitor unit testing to ensure compliance
with the test requirements outlined in 3.1.
3.1 U̲n̲i̲t̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲F̲o̲l̲d̲e̲r̲
The following section describes the Unit Development
folder (UDF) which is a means of imposing the management
philosophy and a development methodology on the software
development during the detailed design coding and unit
test phases.
The UDF is simply stated a specific form of development
notebook which has proven useful and effective in collecting
and organizing software products as they are produced.
The UDF begins with the definition of requirements
to be implemented within the unit, from which is derived
a detailed design description and unit development
test plan(s) describing the development testing activity.
To this is added the unit code, a list of test cases
and procedures, and finally, test results demonstrating
that the coded unit meets the requirements and is free
of errors and anomalies. During the process, the design
description may be revised to make it reflect the coded
unit. Thus, as the unit evolves from its initial check-out
state to a completely tested segment of code, the UDF
progresses from a "code-to" specification to an "as-built"
specification. Changes from code-to to as-built documentation
will be under CR configuration management. By the time
the unit is ready for integration with other units,
the product specification for the unit is complete,
including design description.
Copies of the documentation contained in the UDF's
will be delivered to the purchaser as part of the as-built
documentation.
The figure overleaf illustrates the role of the UDF
in the total software development process.
For detailed information related to the UDF please
refer UDF standard SD/STD/006 or CPS/STD/001.
figure 3.1…01…the UDF in the development process
3.2 U̲N̲I̲T̲ ̲T̲E̲S̲T̲ ̲S̲C̲H̲E̲D̲U̲L̲E̲
This section presents all activities which apply to
all unit development especially emphasizing the unit
test activities.
In parallel with detailed design, test cases exhaustively
testing the unit, shall be developed.
Test cases shall together with the detailed design
be reviewed during the detailed design review.
During the coding phase, test procedures and test beds
shall be developed.
Inspection of test procedures, may be established prior
to unit testing.
After successful unit testing, test results shall be
reviewed in order to ensure thoroughness of the testing.
Overleaf, is presented a schedule for the sequence
of activities and events which apply to all unit testing.
The relative distribution of effort allocated to design,
coding and test is 1/3, 1/6 and 1/2 respectively.
The estimated effort allocated to design, coding and
test per lK source code is..........
The reviews scheduled for a UDF is one to two weeks.
Specific unit test schedules will be established when
units have been allocated and when the integration
plan has defined the sequence of integrating units.
This is planned to occur late in the preliminary design
phase.
Figure 3.2-1
Unit development and test schedule
3.3 O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲ ̲R̲E̲S̲P̲O̲N̲S̲I̲B̲I̲L̲I̲T̲I̲E̲S̲
This section describes the responsibilities related
to unit testing.
For each major software package, a work package manager
(WPM) will be allocated. The WPM is responsible for
the management of all units contained in the packages,
as well as test and integration of these.
The WPM shall ensure that the test cases and procedures
defined for each unit comply with the test requirements
defined. Furthermore, he shall approve the test results
before the unit is released for integration.
Test cases and procedures shall be developed by the
individual implementing the unit.
Christian Rovsing A/S Quality Assurance may any time
initiate audits and inspections to ensure that testing
is performed according to the plans and standards applicable
to unit testing.