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

⟦3aa251aab⟧ Wang Wps File

    Length: 5022 (0x139e)
    Types: Wang Wps File
    Notes: Spelunked
    Names: »~ORPHAN66.00«

Derivation

└─⟦1304ed705⟧ Bits:30006073 8" Wang WCS floppy, CR 0030A
    └─ ⟦this⟧ »~ORPHAN66.00« 

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 SPECIFICATON ......................... 
          8
       2.3.1 Capability Testing .....................
               8
       2.3.2 Structural Testing .....................
               8

     2.4 TEST PROCEDURES ............................
          10
       2.4.1 Facilities Required ....................
              0
       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 contins 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 speifications 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 propery
             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
             partsagainst 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/00.

         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̲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 irst 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̲u̲t̲i̲n̲e̲ is the smallest compilable piece of
         software…86…1         …02…   …02…   …02…   …02…                       
                            
                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 elementaryprocesses, 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
         ny 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 leadsto
         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 ofinterfaces.

         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