曝光臺 注意防騙 網(wǎng)曝天貓店富美金盛家居專營店坑蒙拐騙欺詐消費者

1.5.6 TEST CASE DEVELOPMENT
Development of Scenarios is an iterative process during the conceptual design process, and this is equally true of Test Cases during the validation process. As explained in Part C and Chapter 2 of Part D, the initial Design Concept can lead to large number of potential directions for development (depending on the complexity of the changes required to the actual situation), each described by a potential Scenario.
In moving towards more detailed and accurate evaluations and assessments, only the Scenarios / Test Cases meeting the performance criteria will be kept and further developed. Thus, as the refinement of Scenarios / Test Cases increases, the number of Scenarios/Test
T
e
r
m
i
n
a
l
A
i
r
s
p
a
c
e
D
e
s
i
g
n
G
u
i
d
e
l
i
n
e
s
-
P
a
r
t
D

Cases reduces – and ultimately, this leads to the solution which is developed for implementation.
The design/simulation team should ensure the consistency of Scenarios/Test Cases throughout the process. Continuity can be assured by use of Test Cases which have been validated by one simulation method as a basis for the development of new Scenario / Test Case for the following assessment phase (using, perhaps, a different simulation method). This continuity also reduces the probability of errors – and divergence from design objectives. Furthermore, duplication of effort is avoided; this ensures that both cost and duration do not become excessive.
1.5.7 COMPARING TEST AND BASE CASES
In order to be able to make robust comparisons between Base and Test Cases and/or between Test Cases, these cases should bear sufficient resemblance to each other. If too many changes are incorporated (e.g. changes are made to several parameters of either the Airspace Organisation or Traffic Sample) it becomes difficult to evaluate the impact of each modification and may even make comparison impossible or, worse, produce misleading conclusions.
Therefore, the basic rule for making comparisons can be expressed as follows
“CHANGE ONE PARAMETER AT A TIME”
In view of the number of parameters attached to each of the two components of a Test Case, it is evident that 10 or more Test Cases could be created i.e. for 10 or more Traffic Samples run through the same Airspace Organisation in order to determine the effect of changing one Traffic Sample parameter. This stresses the importance using a naming convention to identify Base and Test Cases.
Thus, for example, in order to compare different airspace organisations, the same traffic sample should be used on different Airspace Organisations. This is shown in the Table below using as a starting point the Pseudo Reference Scenario coded PR 01-RT.
Base/Test Case Ident.  Airspace Organisation  Traffic Samples (Coded Identification)  What is being compared? . 
PR 01-RT  PR (Pseudo-Reference)  01-RT (100% traffic)  01-1T (120% traffic)  01-2T (150% traffic)  Assess Org PR against traffic increase 
A 01-RT  A  01-RT (100% traffic)  01-1T (120% traffic)  01-2T (150% traffic)  Assess Org A against traffic increase 
B 01-RT  B  01-RT (100% traffic)  01-1T (120% traffic)  01-2T (150% traffic)  Assess Org B against traffic increase 
Compare Org PR with A and B, and compare Org B with C  Compare Org PR with A and B, and compare Org B with C  Compare Org PR with A and B, and compare Org B with C  What is being compared? . 

Table 1 - 3: Detailed view of Sample Scenario Comparison
In the Table above, note that the difference between traffic samples is based (across) on a traffic increase (a single parameter, the amount of traffic in the Traffic Sample, has changed). In contrast, the downward comparison refers to a changing Airspace Organisation using the same Traffic Sample.
　
中國航空網(wǎng) www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：EUROCONTROL MANUAL FOR AIRSPACE PLANNING 2(89)