DataMuseum.dk

Presents historical artifacts from the history of:

CR80 Wang WCS documentation floppies

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about CR80 Wang WCS documentation floppies

Excavated with: AutoArchaeologist - Free & Open Source Software.


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.