[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference cookie::mru

Title:MRU Internal Bug Reports
Moderator:COOKIE::STMARTIN
Created:Wed Sep 20 1995
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:346
Total number of notes:1175

335.0. "V1.2 Coverage Testing Report." by NABETH::alan (Dr. File System's Home for Wayward Inodes.) Thu May 01 1997 20:37

	I've been doing coverage testing for about over a week now
	on the V1.2 API to ensure as much of it as possible has
	been executed.  The results aren't final since I'm still
	finding bits that should be executeable, but at the moment
	I'm up to over 5524 of 5589 (98.84%) lines among the three
	API files.

	All of mrd_message.c has been executed and large parts of
	it verified that it is returning the correct results.

	Four of 943 lines of the UNIX interface module haven't
	been executed.  Two of this are a check in the event
	that a strcpy will return NULL.  I have my doubts that
	strcpy could return NULL, if passed a reasonable pointer,
	but the V4.0B manual doesn't describe it this way.  The
	remaining two lines are checks that the ASC/ASCQ codes
	are actually available from Request Sense.  I could
	probably change the code to get rid of these.

	Most of the unexecuted code is in the common code.  As
	of early this afternoon, I had 4014 of 4075 (98.50%) lines
	executed. This is a slight regression from V1.1 that had
	37 lines of 2492 (98.52%) executed.  Close examination
	of the common code has revealed some places that can be
	cleaned up, which may improve the result a little.
T.RTitleUserPersonal
Name		DateLines
335.1API Total: 99.32%NABETH::alanDr. File System's Home for Wayward Inodes.Mon May 05 1997 19:5571
	The API Coverage testing results are:

API

    mrd_clc_scsi.c  939 lines of   943 (99.58%)
    mrd_common.c   4028 lines of  4062 (99.16%)
    mrd_message.c   571 lines of   571 (100.00%)

    Combined       5538 lines of  5576 (99.32%)


Profile listing generated Thu May  1 20:20:41 1997 with:
   prof -pixie -testcoverage coverage coverage.Addrs Sums 

----------------------------------------------------------------------------
*  -t[estcoverage] using basic-block counts;                               *
*  sorted alphabetically by procedure name;                                *
*  the compiler emitted code for these lines, but the code was unexecuted  *
----------------------------------------------------------------------------

mrd_assign_channel (mrd_clc_scsi.c), line(s): 2
215-216(2)	strcat(3) returned NULL.

mrd_request_sense (mrd_clc_scsi.c), line(s): 2
685		Sense Length too short for ASCQ.
690		Sense Length too short for ASC.

mrd_check_barcode (mrd_common.c), line(s): 1
493		PVOLTAG not set in RES data.

mrd_find_cartridge (mrd_common.c), line(s): 4
3515		mrd_show(3mrd) failed for Slot; mrd_return.		(1)
3590		mrd_show(3mrd) failed for Drive; mrd_return.		(1)
3665		mrd_show(3mrd) failed for Transport; mrd_return.	(1)
3740		mrd_show(3mrd) failed for Port; mrd_return.		(1)

mrd_home (mrd_common.c), line(s): 2
3219		Element status not MRD_STATUS_SUCCESS.
3227		Read Element Status data not valid.

mrd_initialize (mrd_common.c), line(s): 3
2873-2875(3)	Command failure.

mrd_scsi_decode (mrd_common.c), line(s): 1
3908		Entry point?						(2)

mrd_show (mrd_common.c), line(s): 6
2664-2666(3)	Descriptor size == 0.					(3)
2677-2679(3)	No elements.

mrd_startup (mrd_common.c), line(s): 17
2063-2069(7)	Test Unit Ready failed and Request Sense.
2228-2230(3)	Read Element Status failed in port check.
2302-2306(6)	Read Element Status failed in descriptor size check.
2324		Descriptor size still <= 0.

Footnotes:

1.  The Pixie results claim that the mrd_return line for these
    error cases is unexecuted.  This is odd, but I'm not going
    to try and tweek the code to "fix" it.

2.  This is really odd.  It claims that the function declaration is
    not be executed.  But being just one line and the rest of the
    routine seeming to behave correctly, I'm also not going to worry
    about it.

3.  I have a recollection that the insane TZ857 we have rolled away
    in corner would cause this problem.  I am planning to put that
    changer somewhere, because it is sometimes useful to test with
    insane devices.