debug
[email protected]
===========================
TEST FAILURES:
---------------------------
Test failures may be the result of DSS/code mismatches.
First, make sure the DSS you are using matches the load you
run on. Second, make sure the code you inspect matches the DSS
you are using and the load you run on.
Go over your test carefully, comparing it with the DSS, looking
for flaws in the test. If you are unclear about wording, ask somebody.
There's alot of experienced engineers sitting all around you.
When you are satisfied that you've made no mistake, take a look
at the code. As testers, we must be able to clearly show where
the problem lies. It's not always easy. Do alot of code searches
for variable names, and kind of get a feel for where in the code
you are testing. Look for something obvious.
"All my testcases are failing" is not likely to gather much
support from your fellow engineers.
They will assume you don't know how to test correctly.
They will delay, and hedge, and ignore you, hoping you will
eventually get your act together.
Nobody wants to do your work for you.
However, if you can discover through searching that a certain
variable is not getting set, you have a strong argument.
Send your Lead a Good Email. A Good Email includes the
TESTID and location, lists the exact DSS and section,
and a little description of the problem with supporting code.
Be as detailed as is necessary. Assume the reader
has no familiarity with that section. Every time your Lead has
to ask "what do you mean?" is a wasted day!
3 additional questions means 3 additional days!
Think about it. It's unnecessary. Be specific.
If it's a Real Problem, the Lead in Phoenix writes an SCR.
You can use this SCR to Excuse your Test Failures. Leave the
Test Failures in the Test, list them in an EXC file, and you
are finished with the Initial Development of that Test.
The HISO Initial Development Inspection of the Test will check
to make sure that fixing the SCR should Pass the Failing Testcases.
Everything is put in ACM, and it's on to the next Test.
Hopefully, the SCR will get fixed in time for SCR Rework Phase,
and you can rerun the Test, running on a new Load containing
the Fix to the problem you discovered.
Once it's all running, request the removal of the EXC from ACM.
A Typo in the DSS should not affect the design of your Test.
A Typo is not a Real Problem. It's a cut-n-paste mistake.
It doesn't confuse you, and you have no problem testing the section.
If you find a Typo in the DSS, report it to the Lead. He will
pass it on to the DOCS people. It will get fixed.
There may or may not be an SCR written.
SAMPLE DEBUG SESSION:
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
check to make sure it is running(29050 processsor status)
in the command window:
dws_var.drv_dpkg_format_1.data := pfd_capt;
dws_var.drv_dpkg_format_1.data := efis_pri_capt;
this is just a check to make sure you have control.
open a sun window:
cd /usr/dws
grep sut.sym (for the variables you need to view)
in the dws window: debug..select and modify
paste in the variable names and modify the values
this doesn't work well for records,arrays
use the command window for more complicated variables like format_1
set up the initial conditions:
By looking at the code you can see which variables you need to change.
Many times status variables have been checked long before, and
you may not even have to set them up.
I suggest setting up and observing the most critical variables first,
then gradually widening the scope if the expected behavior does not appear.
change the variable that will trigger a screen response.
observe the changes on the display
try another.
DEBUG
The problem you are having is due to the function
"set_OPC_PFD_ND_FORMAT". The function is setting the OPC variable, but
it never executes the required "run_powerup_initialize" function after
setting the variable. Please remeber that all OPC's are read by our
software only on powerup (there may be some exceptions that are read at
other times). Every function which sets an OPC must also execute
"run_powerup_initialize" after the OPC is set.
DEBUG
The driver is not perfect.
(Duh!) There are cases when, because of the way the driver is set up,
software will be called twice in a single 50 msec frame. This
happened to us when we set:
drv_dpkg_non_graphics_periodic = true
drv_dpkg_common_globs = true
Because common_globs = true, the package graph1_app_mgr_20hz is
called, which in turn calls pfd_masi_pkg.process_20hz. Because
non_graphics_periodic is true, the driver calls
pfd_masi_pkg.process_20hz. Thus, we call the routine twice in a
single frame.
For most of our tests, the above scenario will not affect your tests.
However, if you are doing something which involves filtering, calling
the routine twice in a frame confuses the filter software. Since the
filter is designed to read one sample per 50 msec frame, our issuing 2
calls to the routine makes the filter think it has just sampled twice.
The virtual sample rate is thus 40hz rather than 20hz.
DEBUG
In order for these
conditions to be registered by the summary, they have to have a proper
format. I suggest that you play with tgs -rpt a little to try to
determine a proper format for these output lines.
DEBUG
".t" variables:
> First of all, lets say that I implemented the code by
> simply substituting the logic in place of wherever the .t is used?
> That is perfectly acceptable because that is the exact purpose of
> a .t. The .t variables are used to help simplify the DSS and
> usually is used to get rid of duplicated logic.
> The fact that I actually implemented the .t at all was completely
> an implementation issue and should be ignored by any tests.
>
> If you look at section 4.2.2.3 of the Flat Panel Displays
> Detailed System Specification/Software Requirements Document
> Standards you will see that a .t variable is "not observable"
> to test. Therefore, I don't see why you need to test that
> if - then statement as a separate entity.
DEBUG
elaboration:
we ELABORATE declarations and EXECUTE statements.
before you actually EXECUTE any lines of code(statements),
the code is first ELABORATED (that is: comes into existance).
so before even one line of code is EXECUTED,
the data declarations(the variables) are ELABORATED.
so, when we have:
a variable that is assigned to an initial value
in the declaration,
we have a case where:
the variable is initialized at ELABORATION
(before even the first line of code is called).
it's not easy to test, obviously, because you can't
set the variable to B,
step, and
check to see if it is now initialized to A,
because:
before you get a chance to set the variable to B,
the code has already been ELABORATED, and initialized,
and it only does it once!
so you can set it to B, but you can step all day
and it won't re-init to A.
we don't bother to test these cases.
we cover them with a .ANA analysis file, which contains
a simple explanation of the problem, why it can't be tested,
and your engineering analysis of why you believe this code
runs correctly.
circumstantial proof is helpful.
back
