dws advice
[email protected]
DWS ADVICE
Don't write tests at random:
Look at the test anchor you want to test,
and find the associated code anchor from the trace matrix.
Check the code to see if all the variables
are implemented before starting the test.
if a section is not fully implemented, skip it.
1. design a complete multiple condition table (MCT)
2. manually generate the test from the MCT
3. put the test in ACM
4. have a test design inspection (TDI)
5. fix the test as per TDI comments
6. run the test
7. fix the test until everything is running properly.
8. put the test and results in ACM
9. have a test execution inspection (TEI)
10. fix the test as per TEI comments
11. put the final test and results in ACM.
Test Development Inspection (TDI) main points:
1. make sure the requirements are being tested.
2. make sure that the trace matrix is accurate.
Test Execution Inspection (TEI) main points:
1. make sure the test outputs are the same as those
designed in the multiple condition table (MCT).
2. identify how to fill in the missing coverage.
We use a Peer-Review Inspection Process.
We invite SQA to every Inspection.
The Inspection Checklist is in FPDPROC:TEST_CHECKLIST_DWS.TXT
Many times there are CODE/DOCS disagreements.
Many times, the DOCS are WRONG and the CODE is RIGHT!
By inspecting the code as you write your test, you can
locate these disagreements early, and ask about them.
This will save time when the DOCS are wrong
DON'T CHANGE THE TEST RESULTS TO AGREE WITH UNEXPECTED ACTUAL RESULTS!!!!
FOLLOW THE MCT AS DESIGNED!!!
IF THERE IS A FAILURE, REPORT IT.
we are testing code. expect failures.
NP build advice:
Many times, the NP_Build is late.
Many times, it doesn't work.
But it shouldn't hold you up.
You don't have to wait for the NP_Build to be available
to look at the code.
If you need to look at the code, look at the REAL Build.
The NP_Build is NOT the REAL Build.
The REAL Build is a PARTITION BUILD.
The NP Build is a NON_PARTITION BUILD.
It's the SAME CODE.
do a integ md90 and then a show logical on m90*
and you can see all the builds out there.
you can check the code there.
you can check the code in MD90src.
it's all there.
you don't need to wait for an NP build to check the code.
SAMPLE DWS SESSION:
on vax
putdws test.tdf
goto sun
rlogin cds32
dap1p test.tdf (look for correlation errors)
dws
mv ~/*.ssi .
goto dws
disp
disp777
cd /sun/CDS/bennettp
dws
select..select SUT..np_driver.abs
select..SUT run mode..load and run
select ssli
file..open script../sun/CDS/INTEG/efis_prim_check.ssi
goto vax
getdws test.res
tgs/rpt test.res -> test.rpt
fixing the BD CT
>in1_adc_dpkg_.ada
> 52 Baro_Correction_Ins_HG :
> 53 array(IO_Common_Array_Tpkg.Capt_FO_Type) of
> 54 In_ADC_Tpkg.Baro_Correction_Ins_HG_Type;
>in_adc_tpkg_.ada
> 16 type Baro_Correction_Ins_HG_Type is record
> 17 Pad_30_32 : Portable_Types_Pkg.Unsigned_3;
> 18 Tens : Portable_Types_Pkg.Unsigned_32 range 0..7;
> 19 Ones : Portable_Types_Pkg.Unsigned_32 range 0..9;
> 20 Tenths : Portable_Types_Pkg.Unsigned_32 range 0..9;
> 21 Hundredths : Portable_Types_Pkg.Unsigned_32 range 0..9;
> 22 Thousandths : Portable_Types_Pkg.Unsigned_32 range 0..9;
> 23 Pad_5_10 : Portable_Types_Pkg.Unsigned_6;
> 24 Stat : Disp_Common_Tpkg.Status_Type;
> 25 end record;
> 26 for Baro_Correction_Ins_HG_Type use record
> 27 Pad_30_32 at 0 range 0..2;
> 28 Tens at 0 range 3..5;
> 29 Ones at 0 range 6..9;
> 30 Tenths at 0 range 10..13;
> 31 Hundredths at 0 range 14..17;
> 32 Thousandths at 0 range 18..21;
> 33 Pad_5_10 at 0 range 22..27;
> 34 Stat at 0 range 28..31;
> 35 end record;
> In the sut.sym he gives IN1_ADC_DPKG_BARO_CORRECTION_INS_HG
> to refer the variable..this variable is of record type and
> i need to set the individual members of the record.
I've written the bd and ct for the variable and it works fine.
You may be interested in knowing how
I split the variable into five parts
BARO_CORRECTION_INS_HG_CAPT_001.E
BARO_CORRECTION_INS_HG_CAPT_01.E
BARO_CORRECTION_INS_HG_CAPT_0.E
BARO_CORRECTION_INS_HG_CAPT_1.E
BARO_CORRECTION_INS_HG_CAPT_10.E
Then i wrote the CT for each variable
BARO_CORRECTION_INS_HG_CAPT_001.E 1 DWS_VAR.IN1_ADC_DPKG_BARO_CORRECTION_INS_HG.CAPT_DATA_001
BARO_CORRECTION_INS_HG_CAPT_01.E 1 DWS_VAR.IN1_ADC_DPKG_BARO_CORRECTION_INS_HG.CAPT_DATA_01
BARO_CORRECTION_INS_HG_CAPT_0.E 1 DWS_VAR.IN1_ADC_DPKG_BARO_CORRECTION_INS_HG.CAPT_DATA_0
BARO_CORRECTION_INS_HG_CAPT_1.E 1 DWS_VAR.IN1_ADC_DPKG_BARO_CORRECTION_INS_HG.CAPT_DATA_1
BARO_CORRECTION_INS_HG_CAPT_10.E 1 DWS_VAR.IN1_ADC_DPKG_BARO_CORRECTION_INS_HG.CAPT_DATA_10
then i wrote the BD as
------------------------------------------
-- ADA Variable Name: IN1_ADC_DPKG_BARO_CORRECTION_INS_HG
-- Variable Type:
------------------------------------------
define packet IN1_ADC_DPKG_BARO_CORRECTION_INS_HG bus DWS_VAR freq 20 size 2 is begin
CAPT_DATA_001 0:10..0:13 BCD max 9;
CAPT_DATA_01 0:14..0:17 BCD max 9;
CAPT_DATA_0 0:18..0:21 BCD max 9;
CAPT_DATA_1 0:22..0:25 BCD max 9;
CAPT_DATA_10 0:26..0:28 BCD max 7;
end; -- end define IN1_ADC_DPKG_BARO_CORRECTION_INS_HG
What I do in the TDF is , suppose i want to set 12.34
then i set 1 to the tens part , 2 to the one's part
3 to the tenths part and 4 to the hundreths part.
It's working fine
Chethan
BNR vs. BCD
BNR is straight binary. BCD is binary coded decimal.
In BNR, you have a value of the least significant bit. The number
represented by the BNR number is the value of the LSB times
the number of total bits. For example:
LSB = 1, BNR = 1010, represented number = 1 * 10 = 10
LSB = 0.5, BNR = 1010, represented number = 0.5 * 10 = 5
LSB = 0.25, BNR = 1010, represented number = 0.25 * 10 = 2.5
In BCD, the hex represents decimal digits. For example:
BCD = 0010 0101 0010, represented number = 252
BCD = 1001 1000 0111, represented number = 987
You should note that there are ILLEGAL representations
using BCD numbers. The only LEGAL representations
are 0..9. A Hex A..F is illegal. The software must be
written to filter out illegal BCD digits.
coding a BCD number as "BCD MAX 9" would seem to limit
the possible inputs for the BCD digit between 0 and 9. I would
have to check this on the DWS, but it would appear that
you would not be able to test hex values A..F using the above
BCD definition. This applies to 4-bit BCD number. (For the 3-bit
number which is limited to "BCD MAX 7", you couldn't test
8 or 9.) In general, this wouldn't be a problem, since the
BCD is a code for a decimal number, and the values
"A".."F" are not valid numbers. However, our testing is
supposed to not only test "expected" values, such as
0..9, but also "unexpected" values, such as "A" and "F". The
displays code must properly handle the case where a
BCD digit is not legal, and we in the land of test are
supposed to verify that the displays code does properly
handle unexpected values. Since we
are SUPPOSED to be doing boundary value testing, it would
be necessary for the testers to try to enter HEX values
A and F, in addition to 0..9. If they ARE testing A and F, then
"BCD MAX 9" might be OK. But my feelings would be that
"BCD MAX 9" would not allow the tester to test "A". There
is a possibility that the testers in Bangalore are not doing
appropriate boundary value testing. I would check into this
further. It is really quite important, in my opinion, that we
test "out of range" values for the BCD digits.
BNR MAX #10# might be OK for 4 bits
BCD MAX 15 might work also.
DWS ADVICE
The tool "dws_split" is run on the DWS to gather xinfo data, and in
some cases to obtain .res files in batch mode. This tool was created due
to some problems which occur using "dws" on the venix system. On the 777
program, we noticed that the dws would "hang" after running a number of
files in batch mode. We traced this problem down to a possible stack
problem with venix. After running a number of files in batch mode, it
seemed that a stack pointer possibly overran the legal stack area. The
DWS would then hang.
Since this problem included a third party (the makers of the Venix
operating system), rather than pushing for a Venix change to solve the
problem, we on 777 opted to create a workaround - dws_split (author:
Craig Gibson). Using default settings, the tool dws_split splits up the
batch command into groups of 8 files - that is, 8 .ssi files will execute
in batch, then the dws program will terminate. The tool dws_split will
then start dws up again and run the second batch of 8 .ssi files,
repeating this process until all .ssi files are executed in batch. The
starting and stopping of the dws program seemed to reset the stack
pointer (or whatever it was that caused the dws to halt), thus providing
a workaround to our problem.
Unfortunately, in some cases, dws_split still did not provide a
solution to the dws halt problem. To solve this problem, an optional
"number" was added to dws_split to allow the user to specify the number
of files to run at a time. There are times when some of the .ssi files
are very large, thus requiring the split to occur on less than 8 files at
a time.
One last comment: the tool dws_split should also allow for the
creation of .res and .xin files at the same time using the optional
qualifier "-r". Since most of the graphics testing must create .res
files interactively, we do not have a lot of experience with using this
option. The -r option should work. If not, we should consult with Craig
Gibson to see if we must modify dws_split further.
The dws_split command line is as follows:
dws_split [optional split# - default = 8]
[optional -r]
(all the above should be on 1 line)
file of .ssi filenames: This is a text file containing the names of all the
.ssi files to run in batch
sut: The name of the .abs file against which to run dws_split. Please
note that a .pth file of the same name must also be present.
split #: The number of files to execute every time a dws window is brought
up by the dws_split tool. The default is 8 files/window. The
optional number should be decreased if the dws continues to halt
with the default of 8.
-r: Indicates to the dws_split tool that .res files will be created. If
this option is not used, the dws_tool will disable the creation of
.res files.
DWS ADVICE
There are two ways of generating .xin files and .rpt files at the same
time on the DWS. One way could be used for tests which require user
interaction. The other way could be used for tests which can run in batch.
1) If user interaction is needed:
a) Load SUT using "STUCCOS LOAD"
b) Start SUT execution using "RUN 050"
c) Execute tests to obtain .res
d) Create .xin by doing "STUCCOS DATA SAVE"
2) If no user interaction is necessary:
a) dws_split -r
The -r causes dws_split to generate .res files also.
back
