coverage
[email protected]
TESTING : our job
1. Test every requirement listed in the DSS.
2. Get 100% TCA (cover all if-then branches).
3. Sign off all FPTEST SCRs.
this is about #2.
COVERAGE
Run TCA on the section using the baseline PTH.
$! tca -x b.xil -p b.ptl -c b.cul -r b.tcr -"BATS" -t 3
$ tca -x b.xil -p b.ptl -c b.cul -r b.tcr -"BATS" -t 3 --"ignore=A,I,G,H"
COVERAGE
InspectFN - Inspects File Names - Looks at working config directory
and reports on source and output files per specified sub
functional area. So if your .exc report is older than any
sources, like an .ADA driver, a flag is raised.
InspectSCR - Inspects SCRs - Looks at the user-supplied SCR with ACM
Report ONE_SCR, gets the elements off of it, and then
searches all the .ins files in the working config containing
the SCR, for accepted and inspected generations.
InspectSCT - Rolls up all the .tce files in the working config and
builds a report.
COVERAGE
if we do not exercise one or more lines of code
in our testing (for any reason) that there is a systems/software analysis
that needs to be done to verify that the unexercised code does what it is
supposed to do and that there is no possibility of a safety issue with the
code. We need to get these analyses going as soon as possible, so that the
systems/software people here in Phoenix can do them on a non-panic basis.
From a certification standpoint, either the test coverage or the analysis is
acceptable, but one or the other must be done.
COVERAGE
TCA_SRC logical to point to multiple directories
$ setup_tca_src == "@EBWR1:[bennettp]setup_tca_src.com"
COVERAGE
Running TCA on the w-node is probably more efficient. You then do not
have to worry about whether you have the proper source files in
Bangalore. The original source files can always be accessed from the
w-node.
TCE
the TCE files contain TCA hole excuses.
we have standard excuses that can be found in the test ACM dir
in the file fpd.tch.
in addition, the is one more: {missing_testcases}
these are not excuses or analysis, these are admissions of error
and need to get fixed.
search the TCE files for {missing_testcases} and you will
see them all. this is not good.
please spend some time.
it shouldn't take much to fix them, as most holes are obvious.
if it is NOT obvious, skip it.
COVERAGE
1. connect w node.
2. $gtce xxxxxxx.tcr
3. edit xxxxxxx.tce with appropriate elements in fpd.tch.
(use "<" & ">" brackets)
4. $gtce xxxxxxx.tce b737test:fpd.tch
After instruction 4, you will have the elements provided in 3, expanded
with the description for the element.
COVERAGE
In order to run TCA from the VAX, you probably only need to know a few
things:
1) VAX login must execute department common startup
2) need to define tca_src on the VAX
3) tca command line on the VAX uses -"BTA" rather than -BTA
I assume that all of you already have a login which calls the department
common startup. If you are able to execute tca on the VAX, you are
calling the department startup. Just type TCA. If you get a help
screen, you're O.K. If not, you may need to include 1 or both of the
following commands in your login.com:
$ @ebs12:[737cds_disp.fp_profile]startup_common_profile.com
$ @ebvr3:[fpinteg.com]ite90_login
Defining tca_src is just a little more involved. Fortunately, Tim Inman
created a command procedure which allows us to define tca_src very
easily. A copy of Tim's command procedure can be executed from
ebs2:[fpdtest.tools]define_tca.com. You can execute this command
procedure and define tca to point to the software for the desired load.
COVERAGE
TCE: use the gtce routine on the w node.
just type gtce to learn to use it, but it's simple.
use gtce the first time on a tcr file to create a tce,
edit it, adding the in b7376test:fpd.tch,
then use gtce a second time on the tce with b7376test:fpd.tch
to create the final tce.
the first time is only to create a tcr file named TCE:
gtce file.tcr produces file.tce
i will use the TCE files from -800 to guide me in
creating the TCE files for -600.
i will open up 2 windows, one with the -800 TCE and the
other with the -600 TCE. the TCE files look exactly like
the TCR files, except we add comments only to TCE files.
if you have ever examined TCR files, you will know that it
lists lines of code that were not recorded as
covered. when i see a section listed in the -600 TCE,
i will check to see if the -800 has a corresponding
section listed, with an appropriate "excuse"
in the format of: followed by a description.
this description is added by the second running of gtce.
so i only need to add the same into the -600 TCE.
once you do it a few times, you start to understand
what excuse goes where and when. Then you are
ready to handle cases where -600 is unique from -800.
then, i am reading for the second running of gtce.
gtce file.tce b7376test:fpd.tch produces the final file.tce
GTCE -ver 1.01 PS5540-00353, description:
GTCE must be run at least twice. Syntax for first time is:
GTCE <.tcr file>
where:
<.tcr file> is the name of the TCA Report file name.
The purpose of this initial run is to create a .tce file.
Any subsequent runs of GTCE will be on the .tce file. This
method (of 'multiple' gtce runs) ensures that the .tce file
contains ALL of the structural holes in the .tce file, at least
after the first run, and, this method provides the user a way to
modify the .tce file, without changing the original .tcr file.
Following is the syntax for subsequent GTCE runs:
GTCE <.tce file> <.tch file(s)> [<-flags>]
<.thl file >
where:
<.tce file> is the name of the TCA structural coverage
exception report.
<.tch file(s)> is the name of the file(s) containing at least
some of the structural coverage hole analysis.
<.thl file is a file of .tch file names.
The format for .tch is as follows:
Analysis of the structural hole. Blank lines require at lease
one space, " ", as end of analysis are 2 blank lines.
[<-flags>] is the user-selected flag:
-o
back
