top - download
⟦f32959ae6⟧ Wang Wps File
Length: 9965 (0x26ed)
Types: Wang Wps File
Notes: TEST PROCEDURE STANDARD
Names: »0216A «
Derivation
└─⟦26e1ab804⟧ Bits:30005814 8" Wang WCS floppy, CR 0001A
└─ ⟦this⟧ »0216A «
WangText
…00……00……00……00……86…1 …02… …02… …02…
…02…SD/STD/011
KFL/801020 #
TEST PROCEDURE STANDARD
SD
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 SCOPE AND PURPOSE ....................... 4
1.1 SCOPE ................................ 4
1.2 PURPOSE .............................. 4
2 APPLICABLE DOCUMENTS ..................... 4
3 TEST PROCEDURES .......................... 5
to 11
3.1 GENERAL .............................. 5
3.1.1 Contents of a Test Procedure ..... 5
3.1.1.1 Requirements Tested .......... 5
3.1.1.2 Configuration ................ 5
3.1.1.3 Special Set-Up ............... 5
3.1.1.4 Input ........................ 6
3.1.1.5 Intermediate Results ......... 6
3.1.1.6 Output ....................... 6
3.1.1.7 Cross Reference .............. 6
3.2 REQUIREMENTS TESTED .................. 6
3.2.1 Verbal Description ............... 6
3.2.2 Listing of Requirements .......... 7
3.3 CONFIGURATION ........................ 7
3.3.1 Standard Configuration ........... 7
3.3.2 Minimum Configuration ............ 7
3.3.3 Maximum Configuration ............ 8
3.4 SPECIAL SET-UP ....................... 8
3.4.1 Special Hardware Set-Up .......... 8
3.4.2 Other Special Set-Up ............. 8
3.5 INPUT ................................ 8
3.5.1 General .......................... 8
3.5.2 Data Input ....................... 9
3.5.3 Other Ordinary Input ............. 9
3.5.4 Extraordinary Input .............. 9
3.6 INTERNEDIATE RESULTS ................. 10
3.7 EXPECTED OUTPUT ...................... 10
3.7.1 Description of Expected Output ... 10
3.7.2 Recording of Output .............. 10
3.7.3 Identification of Output ......... 11
1̲ ̲ ̲S̲C̲O̲P̲E̲ ̲A̲N̲D̲ ̲P̲U̲R̲P̲O̲S̲E̲
1.1 S̲C̲O̲P̲E̲
This standard is applicable to all formal test procedures
necessary to verify the correct function of all parts
of a system and to ensure that all requirements have
been fulfilled.
1.2 P̲U̲R̲P̲O̲S̲E̲
The purpose of this standard is to ensure that all
test procedures are constructed in a homogenous way
in order to make them easily understandable and to
ensure proper test of any requirement.
2̲ ̲ ̲A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
TBD
3̲ ̲ ̲T̲E̲S̲T̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲
3.1 G̲E̲N̲E̲R̲A̲L̲
a) This section deals with the general contents and
logical sequence of a test procedure.
b) All of the items identified by the headings of
sections 3.1.1.1 through 3.1.1.6 shall be present
in a test procedure. and in the sequence used herein.
c) If one or more of the items are not applicable,
this shall be stated.
3.1.1 C̲o̲n̲t̲e̲n̲t̲s̲ ̲o̲f̲ ̲a̲ ̲T̲e̲s̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
3.1.1.1 R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲ ̲T̲e̲s̲t̲e̲d̲
The requirements tested in the test procedure must
be listed in an unambiguous way by references to the
System Requirements Specification.
3.1.1.2 C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
A description of the minimum and/or maximum hardware
and software configuration that must be available for
the test.
3.1.1.3 S̲p̲e̲c̲i̲a̲l̲ ̲S̲e̲t̲-̲U̲p̲
If a special set-up is necessary for the execution
of the test procedure this must be clearly stated.
3.1.1.4 I̲n̲p̲u̲t̲
The input to the test procedure must be described thouroughly
and in the sequence in which it should be input.
3.1.1.5 I̲n̲t̲e̲r̲m̲e̲d̲i̲a̲t̲e̲ ̲R̲e̲s̲u̲l̲t̲s̲
Intermediate results which should be checked during
the test must be clearly stated in conjunction with
the instants in which they should appear.
3.1.1.6 O̲u̲t̲p̲u̲t̲
A complete list of expected output must be included
in the test procedure stating both the output medium
and the instant in which the output is expected.
3.1.1.7 C̲r̲o̲s̲s̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲
A list of all requirements referring to the test procedures
in which they are tested is established in accordance
with TBD.
3.2 R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲ ̲T̲E̲S̲T̲E̲D̲
3.2.1 V̲e̲r̲b̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) The Requirements Tested section shall commence
with a brief verbal description of the specific
requirements, thus enlightening the purpose of
the test procedure.
b) General requirements which are tested or demonstrated
repeatedly in a great number of test procedures
(e.g. the output format of certain data) need not
be described in all test procedures in
which they are tested. Such requirements may be
described in a "dummy" test procedure referring
to representative tests.
3.2.2 L̲i̲s̲t̲i̲n̲g̲ ̲o̲f̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
a) All specific requirements tested in the procedure
shall be listed by reference to the Systems Requirements
Specification (SRS) by numbers.
b) This list shall be sequenced by the SRS requirements
numbers.
c) The step number of the test in which a requirement
is demonstrated shall be placed in the requirements
list adjacent to the requirement number (if applicable)
3.3 C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲
3.3.1 S̲t̲a̲n̲d̲a̲r̲d̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
a) If a test may be run in any configuration of a
system this shall be clearly stated.
b) If a test can be run in any configuration but for
some reason should be run in one or several special
environment(s), standard configuration must not
be stated. In such cases the special environment
shall be described either in the Configuration
section or in the Special Sut-Up section.
3.3.2 M̲i̲n̲i̲m̲u̲m̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
a) If a minimum configuration of the system (hardware
as well as software) is necessary for a successful
test run, this minimum must be clearly described.
b) The reason for the demand for a minimum configuration
must be stated if not obvious.
3.3.3 M̲a̲x̲i̲m̲u̲m̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
a) If a maximum configuration for some reason is demanded
(e.g. to demonstrate the ability to run a task
in a small system) this shall be clearly stated.
b) Only relevant limitations of the configuration
must be stated in this section.
3.4 S̲P̲E̲C̲I̲A̲L̲ ̲S̲E̲T̲-̲U̲P̲
3.4.1 S̲p̲e̲c̲i̲a̲l̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲ ̲S̲e̲t̲-̲U̲p̲
a) Any special hardware set-up demanded prior to the
start of the test shall be clearly stated.
b) Special hardware set-up may be simulated break-down
or malfunction.
c) Simulation of break-down or repair of hardware
during test is considered input and should be described
in the input section.
3.4.2 O̲t̲h̲e̲r̲ ̲S̲p̲e̲c̲i̲a̲l̲ ̲S̲e̲t̲-̲U̲p̲
a) Other special set-up demanded shall also be clearly
stated.
b) Other special set-up may be e.g. cold start, absence
of some databases, etc.
3.5 I̲N̲P̲U̲T̲
3.5.1 G̲e̲n̲e̲r̲a̲l̲
a) In this section the term "input" is used in a very
broad sense meaning any sort of action performed
by the test conductor.
b) Any input must be clearly and unambiguously described.
c) The input descriptions must be consecutively numbered
commencing with 1. Each separate action must be
considered a numbered step.
3.5.2 D̲a̲t̲a̲ ̲I̲n̲p̲u̲t̲
a) All data input must be described in details to
the extent necessary to obtain the expected output.
b) If some data cannot be determined in beforehand
(e.g. date, operator code), and these data have
influence on the expected output, this must be
considered when constructing the expected output.
c) It must be clearly stated which medium carries
the input. If several identical media are connected
to the system, it must be stated which medium to
use (e.g. not "a VDU terminal" but "VDU terminal
No. 3").
3.5.3 O̲t̲h̲e̲r̲ ̲O̲r̲d̲i̲n̲a̲r̲y̲ ̲I̲n̲p̲u̲t̲
a) Other ordinary input comprises actions normally
performed in the systems environment, e.g. pressing
a function key.
b) Also this sort of input shall be described unambiguously.
3.5.4 E̲x̲t̲r̲a̲o̲r̲d̲i̲n̲a̲r̲y̲ ̲I̲n̲p̲u̲t̲
a) Extraordinary input is actions not normally performed
during operation of the system. It might be the
swithching off of a VDU terminal to simulate a
break-down.
b) It is essential to describe exactly how such an
action shall be performed.
c) If such a action shall be performed simultaneously
with an ordinary action, and an assistant to the
test conductor is thus necessary, this must be
stated.
3.6 I̲N̲T̲E̲R̲M̲E̲D̲I̲A̲T̲E̲ ̲R̲E̲S̲U̲L̲T̲S̲
a) This section deals with intermediate results, i.e.
output which cannot be recorded. That comprises
e.g. "Bell rings for 10 seconds", "Alarm light
switched on".
b) Such intermediate results shall be listed in their
order of appearance and numbered by the number
of the input step performed immediately before
the result.
3.7 E̲X̲P̲E̲C̲T̲E̲D̲ ̲O̲U̲T̲P̲U̲T̲
3.7.1 D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲ ̲o̲f̲ ̲E̲x̲p̲e̲c̲t̲e̲d̲ ̲O̲u̲t̲p̲u̲t̲
a) Expected output shall be described exactly as it
is expected to appear.
b) This includes an indication of which output medium
is used for output.
c) If some output is dependent on input not determinable
in beforehand, (e.g. date, operator code), it shall
be stated which relation the output must have to
the input.
3.7.2 R̲e̲c̲o̲r̲d̲i̲n̲g̲ ̲o̲f̲ ̲O̲u̲t̲p̲u̲t̲
a) To facilitate a thorough scrutiny of the output
it should be logged or hard copies printed to an
extent which is reasonable, the importance of the
specific test taken into account.
b) Hardcopies and log prints shall be marked sufficiently
to identify them to the test run producing them.
3.7.3 I̲d̲e̲n̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲O̲u̲t̲p̲u̲t̲
a) The expected output shall be listed in the order
of appearance.
b) The expected output list shall be numbered in accordance
with the input list. Any output item shall bear
the number of the input step performed immediately
before the appearance of the output.