August 31, 1997

Prepared for: Prepared by:

![](media/image1.emf){width="0.8965277777777778in"
height="1.1395833333333334in"}![](media/image2.emf){width="1.2in"
height="0.9993055555555556in"}

Federal Highway Administration The Johns Hopkins University

Applied Physics Laboratory

**DRAFT**

**Commercial Vehicle Information Exchange Window (CVIEW)**

Master Test Plan

1\. Purpose

2\. Reference Documents

3\. Definitions

4\. Scope

5\. Features to be Tested

6\. Features Not to be Tested

7\. Approach

7.1 Program Phases

7.2 General Approach

7.3 Unit Testing

7.4 Integration Testing

7.5 System Testing

7.6 Acceptance Testing

8\. Item Pass/Fail Criteria

9\. Test Suspension and Resumption Criteria

10\. Environmental Requirements

11\. Responsibilities

12\. Deliverables, Milestones & Schedules

13\. Problem Reporting and Corrective Action

14\. Tools, Techniques, and Methodologies

15\. Approvals

Appendix A - Acceptance Test

Appendix B - System Test

B-1. Functionality Test

B-2. System Performance and Stress Test Plan

2.1 Introduction

2.2 Scope

2.3 Subscription Fulfillment Test

2.4 Subscription Download Test

2.5 Client Database Update

2.6 Query Processing

Appendix C - Integration Test

Appendix D - Unit Test (ADM)

Appendix E - Unit Test (SLP)

Appendix F - Unit Test (IMH)

Appendix G - Unit Test (IOT)

Appendix H - Unit Test (OMH)

Appendix I - Unit Test (SDB)

Appendix J - Unit Test (SDM)

**DRAFT**

**Commercial Vehicle Information Exchange Window (CVIEW)**

**Master Test Plan**

# Purpose

The purpose of this plan is to establish a formal set of guidelines and
activities to be adhered to and performed by JHU/APL and the developer
to ensure that the CVIEW System has been tested successfully and is
fully compliant with the CVIEW System requirements.

The initial release of this document, submitted in draft form, provides
a general framework for establishing the testing environment and
provides general guidelines for performing unit, integration, system,
and acceptance testing of the CVIEW System. Several draft versions of
this document will be issued, following review and comment by the
developer, as details regarding the software design evolve.

# Reference Documents

Software Development and Documentation, Military Standard, MIL-STD-498,
5 December 1994, AMSC NO. N7069.

IEEE Standard for Software Quality Assurance Plans, ANSI/IEEE Std
730-1984, June 14, 1984

POR-5804, Trident II Data processing Plan, Vol. 1, Johns Hopkins
University/Applied Physics Laboratory, January 1991

# Definitions

The information presented below represents a definition of terms used
throughout this document.

-   Approval. Written notification by an authorized representative of
    the acquirer that a developer\'s plans, design, or other aspects of
    the project appear to be sound and can be used as the basis for
    further work. Such approval does not shift responsibility from the
    developer to meet contractual requirements.

-   Computer program. A combination of computer instructions and data
    definitions that enable computer hardware to perform computational
    or control functions.

-   Computer Software Configuration Item (CSCI). An aggregation of
    software that satisfies an end use function and is designated for
    separate configuration management by the acquirer. CSCIs are
    selected based on tradeoffs among software function, size, host or
    target computers, developer, support concept, plans for reuse,
    criticality, interface considerations, need to be separately
    documented and controlled, and other factors.

-   Developer. An organization that develops software products
    (\"develops\" may include new development, modification, reuse,
    reengineering, maintenance, or any other activity that results in
    software products.

```{=html}
<!-- -->
```
-   Pass/Fail Criteria. Decision rules used to determine whether a
    software item or a software feature passes or fails a test.

-   Software development file (SDF). A repository for material pertinent
    to the development of a particular body of software. Contents
    typically include (either directly or by reference) considerations,
    rationale, and constraints related to requirements analysis, design,
    and implementation; developer-internal test information; and
    schedule and status information.

-   Software Feature. A distinguishing characteristic of a software
    item, e.g., performance, portability, functionality.

-   Software Item. Source code, object code, job control code, control
    data, or a collection of these items.

-   Software test environment. The facilities, hardware, software,
    firmware, procedures, and documentation needed to perform
    qualification, and possibly other, testing of software. Elements may
    include but are not limited to simulators, code analyzers, test case
    generators, and path analyzers, and may also include elements used
    in the software engineering environment.

-   Software unit. An element in the design of a CSCI; for example, a
    major subdivision of a CSCI, a component of that subdivision, a
    class, object, module, function, routine, or database. Software
    units may occur at different levels of a hierarchy and may consist
    of other software units. Software units in the design may or may not
    have a one-to-one relationship with the code and data entities
    (routines, procedures, databases, data files, etc.) that implement
    them or with the computer files containing those entities.

-   Test item. A software item which is an object of testing.

-   Test Log. A chronological record of relevant details about the
    execution of the tests.

-   Test Summary Report. A document or set of documents summarizing
    testing activities and results.

    Testing. The process of analyzing a software item to detect the
    differences between existing and required conditions, i.e., bugs,
    and to evaluate the features of the software item.

# Scope

This test plan covers general guidelines for performing unit,
integration, system, and acceptance testing of the CVIEW System. These
guidelines will be expanded to include specific test design, case, and
procedure specifications as details regarding the software design
evolve. Testing will ultimately cover operator and user procedures, as
well as programs and processing control. In addition to comprehensively
testing multi-process functionality including multi-threading,
inter-process communications and multi-processor utilization, external
interfaces, security, recovery and performance will also be evaluated.

# Features to be Tested

The CVIEW System, as specified in the CVIEW Physical Architecture
Document, is partitioned into eight CSCIs. These are:

-   Input Message Handler

-   Administrative Manager

-   Subscriber Processor

-   External Request Processor

-   Safety Data Manager

-   Output Message Handler

-   OPCON Manager

-   Input Output Translator

The features of each CSCI will be fully defined and documented in the
CVIEW Physical Architecture Document. In subsequent versions of the
Master Test Plan, the specific features of each CSCI and their
inter-relationships will be explicitly identified for testing purposes.

# Features Not to be Tested

Features of the CVIEW System which are not to be tested initially are
TBD.

# Approach

## Program Phases

The CVIEW Project will be conducted in multiple phases. New system
capabilities will be added with each phase and tested accordingly. The
CVIEW Phase Chart, which outlines planned phases, timelines and
capabilities is, for planning purposes, presented below.

![](media/image3.emf)

## General Approach

Software development and testing shall be a collaborative effort between
the JHU/APL and the developer. A graphical depiction of the development
and test approach is shown in Figure 1.

![](media/image4.emf)

During the development and test cycle, JHU/APL shall be responsible for
developing and maintaining an interim version of the CVIEW System at its
facility. This system is henceforth referred to as the Interim CVIEW
System and shall be used for software prototype development and testing.
Prototype software shall be developed by JHU/APL, in accordance with the
specifications of the CVIEW Logical and Physical Architecture, and
supplied to the developer.

The developer shall be responsible for developing and maintaining a
development version of the production CVIEW System, henceforth referred
to as the CVIEW System. The developer shall review and modify, where
applicable, prototype software supplied by JHU/APL and incorporate it
into the CVIEW System. The developer shall provide JHU/APL with builds
(releases) of the production software, at the CSCI level or above, to be
installed on the Interim CVIEW System, replacing prototype code, for
testing in accordance with the Master Test Plan. Concurrent testing
shall also be conducted at the developer's facility. Software
deficiencies, detected during testing, shall be corrected by the
developer and the corrected code re-installed on the Interim CVIEW
System for further testing. This iterative cycle shall continue until
all detected deficiencies have been eliminated.

APL and the developer will use the system documentation to prepare all
test design, case, and procedure specifications to support unit,
integration, system, and acceptance testing. This approach will verify
the accuracy and comprehensives of the information in the documentation
in those areas covered by the tests.

## Unit Testing

Unit testing means ensuring that all aspects of each software unit's
detailed design are comprehensively tested.

### Preparing for unit testing

The developer shall establish test cases (in terms of inputs, expected
results, and evaluation criteria), test procedures, and test data for
testing the software corresponding to each software unit. The test cases
shall cover all aspects of the unit\'s detailed design. The developer
shall record this information in the appropriate software development
files (SDFs).

### Performing unit testing. 

The developer shall test the software corresponding to each software
unit. The testing shall be in accordance with the unit test cases and
procedures.

### Revision and retesting. 

The developer shall make all necessary revisions to the software,
perform all necessary retesting, and update the software development
files (SDFs) and other software products as needed, based on the results
of unit testing.

### Analyzing and recording unit test results

The developer shall analyze the results of unit testing and shall record
the test and analysis results in appropriate software development files
(SDFs).

## Integration Testing

The developer shall perform integration testing in accordance with the
following requirements.

Note 1: Integration testing means integrating the software corresponding
to two or more software units, testing the resulting software to ensure
that it works together as intended, and continuing this process until
all software in each CSCI is integrated and tested.

Note 2: If a CSCI is developed in multiple builds, integration testing
of that CSCI will not be completed until the final build. Integration
testing in each build should be interpreted to mean integrating software
developed in the current build with other software developed in that and
previous builds, and testing the results.

### Preparing for integration testing

The developer shall establish test cases (in terms of inputs, expected
results, and evaluation criteria), test procedures, and test data for
conducting integration testing. The test cases shall cover all aspects
of the CSCI architectural design. This information shall be recorded by
the developer in the appropriate software development files (SDFs).

### Performing integration testing

The developer shall perform integration testing. The testing shall be in
accordance with the integration test cases and procedures. JHU/APL shall
also perform independent functional tests of each CSCI.

### Revision and retesting. 

The developer shall make all necessary revisions to the software,
perform all necessary retesting, in conjunction with JHU/APL, and update
the software development files (SDFs) and other software products as
needed, based on the results of integration testing.

### Analyzing and recording integration test results. 

The developer shall analyze the results of integration testing. Testing
and analysis results shall be recorded in the Integration Test Results
Document by the developer and be reviewed and approved by JHU/APL.

## System Testing

The developer shall participate in System testing activities in
accordance with the following requirements. Two types of system tests
shall be conducted: functionality testing and performance testing.

### Definition of System Testing

System testing insures that the individual CSCIs work together as they
are intended to. It involves testing two or more CSCIs together, and
ultimately the entire system as a whole. Two types of system testing
shall be conducted: functional testing and performance testing. Stress
testing is included as a part of performance testing.

#### Functional Testing

Functional system testing means integrating CSCIs with interfacing
CSCIs, testing the resulting groupings to determine whether they work
together as intended, and continuing this process until all CSCIs in the
system are integrated and tested.

If a system or CSCI is developed in multiple builds, system testing may
not be complete until the final build. System testing in each build
should be interpreted to mean integrating the current build of each CSCI
with the current build of the other and testing the results to ensure
that the system requirements (other than performance requirements) to be
implemented in that build have been met.

#### Performance and Stress Testing

Performance testing exercises the system as a whole to ensure that it
will meet it's performance and capacity requirements. Stress testing
ensures that extreme operating conditions, such as functioning at or
beyond the intended capacity limits, do not cause system failure or loss
of data. Since performance is influenced by the total system
configuration, all system components, including hardware, are exercised.

Performance testing a full system at full capacity can be highly
resource intensive. To mitigate resource drain, statistical techniques
may be employed to predict system performance from a smaller number of
tests or a set of tests requiring a reduced set of system resources. Use
of these techniques promotes resource utilization efficiency while
ensuring adequate testing of performance requirements.

### Preparing for system testing 

The developer and JHU/APL shall participate in developing and recording
test cases (in terms of inputs, expected results, and evaluation
criteria), test procedures, and test data for conducting system testing.
The test cases shall cover all aspects of the system-wide and system
architectural design. The developer shall record software-related
information in appropriate software development files (SDFs).

### Performing system testing. 

The developer and JHU/APL shall participate in system testing. The
testing shall be in accordance with the system test cases and
procedures.

### Revision and retesting. 

The developer shall make necessary revisions to the software,
participate in all necessary retesting, in conjunction with JHU/APL, and
update the appropriate software development files (SDFs) and other
software products as needed, based on the results of system testing. In
the case of performance and capacity testing, hardware configurations
may also have to be modified.

### Analyzing and recording system test results. 

JHU/APL shall be responsible for analyzing the results of system
testing. JHU/APL shall document analysis and test results in the System
Test Results Document.

## Acceptance Testing

The developer shall participate in system acceptance testing in
accordance with the following requirements.

Note: Acceptance testing is performed to demonstrate to the Federal
Highway Administration Office of Motor Carriers (FHWA/OMC) that all
system requirements have been met.

### Preparing for system acceptance testing. 

The developer and JHU/APL shall participate in devel­oping and recording
the test preparations, test cases, test procedures and test data to be
used for acceptance testing and the traceability between the test cases
and the system requirements.

### Performing acceptance testing

The developer and JHU/APL shall participate in acceptance testing. This
participation shall be in accordance with the acceptance test cases and
procedures.

### Independence in acceptance testing

The person(s) responsible for performing acceptance testing shall not be
the persons who performed detailed design or implementation of software
in the system. This does not preclude persons who performed detailed
design or implementation of software in the system from contributing to
the process, for example, by contributing test cases that rely on
knowledge of the system\'s internal implementation

### Revision and retesting

The developer shall make necessary revisions to the software, provide
JHU/APL advance notice of retesting, participate in all necessary
retesting, in conjunction with JHU/APL, and update the software
development files (SDFs) and other software products as needed, based on
the results of acceptance testing.

### Analyzing and recording acceptance test results 

JHU/APL shall be responsible for analyzing and recording the results of
acceptance testing. The results shall be documented in the Acceptance
Test Results Document.

# Item Pass/Fail Criteria

Requirements for determining item pass/fail criteria are TBD.

# Test Suspension and Resumption Criteria

Requirements for determining test suspension and resumption criteria are
TBD.

# Environmental Requirements

The developer shall establish, control, and maintain a software test
environment to perform unit, integration, system and acceptance testing
of software. The developer shall ensure that each element of the
environment performs its intended functions.

# Responsibilities

Specific testing responsibilities assigned to JHU/APL and the developer
for unit, integration, functional CSCI, system, and acceptance testing
are summarized in the table below.

  ------------------------------ ----------------- ---------- -------------- ----------
  **Test Type**                  **Participant**              **Facility**   

                                 APL               SAIC       APL            SAIC

  Unit Test                                        x                         x

  Integration Test                                 x                         x

  CSCI Functional Test           x                            x              

  System Test                    x                 x                         x

  Acceptance Test                x                 x                         x
  ------------------------------ ----------------- ---------- -------------- ----------

# Deliverables, Milestones & Schedules

> JHU/APL has responsibility for the following software **testing**
> deliverables and milestones:

**Phase 1 Testing Deliverables**:

Aug 1997 Master Test Plan

Jun 1998 Master Test Plan (Unit and Integration Test Results revised for
other systems and capabilities)

Sep 1998 Master Test Plan (System Test Results revised for other systems
and capabilities)

# Problem Reporting and Corrective Action

Problem reporting and corrective action issues were addressed in the
SAFER Quality Assurance Plan (QAP). The SAFER QAP shall also apply to
the CVIEW software development effort.

# Tools, Techniques, and Methodologies

Issues related to tools, techniques, and methodologies were addressed in
the SAFER Quality Assurance Plan. The SAFER QAP shall also apply to the
CVIEW software development effort.

# Approvals

Approval for the satisfactory completion of unit testing is the
responsibility of the developer with the concurrence of JHU/APL.
Approval for the satisfactory completion of integration, system, and
acceptance testing must be obtained from JHU/APL and FHWA/OMC prior to
the release of the CVIEW System for production processing.

**Appendix A - Acceptance Test**

**CVIEW System**

**Acceptance Test Plans and Test Reports**

**The CVIEW Acceptance Test Plans are**

**to be supplied (TBS)**

**Appendix B - System Test**

**CVIEW System Test Plans and Reports**

# Functionality Test

The following sections define the functionality tests conducted on the
CVIEW system as a whole and report on the results of performing each
test.

**System Functionality Test Plan**

[System ID:]{.underline} Carrier Snapshot

[SYS ID:]{.underline} SYS-CS-001

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH, SDM, OMH

[System Function:]{.underline}

1.  Detect, accept and process a single mailbox request for a carrier
    snapshot using a USDOT# as input in pseudo-EDI format;

2.  Send the snapshot to a given single requester's mailbox.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot request from the input mailbox

-   IMH must recognize it as a carrier snapshot request

-   IMH must parse the EDI format request to obtain the DOT number

-   IMH must fill in the request structure with the DOT number

-   IMH must call the appropriate SDM routine to continue processing

-   SDM must receive the packet header, request header, and request
    properly filled in with data types and the desired DOT number.

-   SDM must call OMH with the packet_header, request header, and send
    request properly filled in.

-   OMH must receive the proper carrier snapshot request from
    SDM_retrieve_safety_data.

-   OMH must query the database and retrieve a carrier snapshot.

-   OMH must send the snapshot to the requester's mailbox in text form.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

An input file in EDI format was sent to IMH via the Eudora mail package:

ST\*285\*000010010

BGN\*28\*54321\*951117\*0800\*GM

NM1\*41\*1\*ECKEL\*JOHN\*MORRIS\*\*\*57\*CSI

NX1\*MC

N9\*2I\*1

LM\*FH

LQ\*T07\*Q106

LM\*FH

LQ\*T10\*Q1

LM\*FH

LQ\*T10\*Q200

REF\*MCI\*0000004

[Expected Outcome:]{.underline}

The carrier snapshot for DOT number 4 should be received in text form in
the requester's mailbox.

[Test Procedure Steps:]{.underline}

Set up the message in EudoraLite. Send it to the IMH input mailbox.

Read the snapshot for the desired DOT number from the requester's
mailbox. Use the SQLPlus utility to view the carrier snapshot in the
database and verify that it is the same data received in the mail
message.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Carrier Snapshot

[SYS ID:]{.underline} SYS-CS-001

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The desired snapshot, for DOT number 4, was received in the
    requester's mailbox, and was read using the EudoraLite mail package.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Carrier Snapshot

[SYS ID:]{.underline} SYS-CS-002

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH, SDM, OMH

[System Function:]{.underline}

1.  Detect, accept and process five mailbox requests for carrier
    snapshot using USDOT numbers as input in pseudo-EDI format;

2.  Send results to a single requester's mailbox.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot request from the input mailbox

-   IMH must recognize it as a carrier snapshot request

-   IMH must parse the EDI format request to obtain the DOT number

-   IMH must fill in the request structure with the DOT number

-   IMH must call the appropriate SDM routine to continue processing

-   IMH must loop through the above sequence of steps four more times
    provided that five snapshot requests are successively queued in the
    input mailbox with no other intervening messages.

For each of five successive carrier snapshot requests:

-   SDM must receive the packet header, request header, and request
    properly filled in with data types and the desired DOT number.

-   SDM must call OMH with the packet_header, request header, and send
    request properly filled in.

-   SDM must perform the above steps five times for five successive
    valid carrier snapshot requests forwarded to it by IMH.

For each of five successive requests:

-   OMH must receive the proper carrier snapshot request from
    SDM_retrieve_safety_data.

-   OMH must query the database and retrieve a carrier snapshot,
    provided that the DOT number is a valid one.

-   OMH must send the snapshot to the requester's mailbox in text form.

-   OMH must loop through the above steps four additional times provided
    that a total of five carrier snapshots are queued in the input
    mailbox and sent by IMH to OMH.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

Five mail messages, with valid carrier snapshot requests.

[Expected Outcome:]{.underline}

The carrier snapshot for the five DOT numbers should be received in text
form in the requester's mailbox.

[Test Procedure Steps:]{.underline}

Start IMH process.

Set up the messages in Eudora. Send them to the IMH input mailbox.

Read the snapshots for the desired DOT numbers from the requester's
mailbox and verify their accuracy.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Carrier Snapshot

[SYS ID:]{.underline} SYS-CS-002

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

The five requested snapshot were received in the requester's mailbox and
were read using EudoraLite.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Carrier Snapshot

[SYS ID:]{.underline} SYS-CS-003

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH, SDM, OMH

[System Function:]{.underline}

1.  Detect, accept and process five mailbox requests for a carrier
    snapshot using USDOT numbers as input in pseudo-EDI format when five
    requests are already queued in the input mailbox;

2.  Send results to requester's mailbox.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot request from the input mailbox

-   IMH must recognize it as a carrier snapshot request

-   IMH must parse the EDI format request to obtain the DOT number

-   IMH must fill in the request structure with the DOT number

-   IMH must call the appropriate SDM routine to continue processing

-   IMH must loop through the above sequence of steps a total of ten
    times when the first five requests are already queued in the input
    mailbox before IMH is started, and then five additional requests are
    sent immediately after IMH processing begins.

-   SDM must receive the packet header, request header, and request
    properly filled in with data types and the desired DOT number.

-   SDM must call OMH with the packet_header, request header, and send
    request properly filled in.

-   SDM must perform the above steps five times for five successive
    valid carrier snapshot requests forwarded to it by IMH.

-   OMH must receive the proper carrier snapshot request from
    SDM_retrieve_safety_data.

-   OMH must query the database and retrieve a carrier snapshot,
    provided that the DOT number is a valid one.

-   OMH must send the snapshot to the requester's mailbox in text form.

-   OMH must loop through the above steps four additional times provided
    that a total of five carrier snapshots are queued in the input
    mailbox and sent by IMH to OMH.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

Ten mail messages, with valid carrier snapshot requests.

[Expected Outcome:]{.underline}

The ten requested carrier snapshots should be received in the
requester's mailbox.

[Test Procedure Steps:]{.underline}

Set up the ten messages in EudoraLite. Without starting IMH, send the
first five to the IMH input mailbox.

Start the IMH process.

Immediately, use EudoraLite to send the next five messages to the IMH
input mailbox.

Read the ten snapshots from the requester's mailbox. Verify that the
information in the text snapshot sent to the mailbox matches the
information in the database.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Carrier Snapshot

[SYS ID:]{.underline} SYS-CS-003

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The ten snapshots were received in the requester's mailbox for the
    ten desired USDOT numbers.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Carrier Snapshot

[SYS ID:]{.underline} SYS-CS-004

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH. SDM, OMH

[System Function:]{.underline}

1.  Detect, accept and process a carrier snapshot request using a single
    digit USDOT #.

2.  Detect, accept and process a carrier snapshot request using a seven
    digit USDOT #.

3.  Detect, accept and process a carrier snapshot request using a USDOT
    \# not contained in the database.

4.  Detect, accept and process a carrier snapshot request using an
    erroneous USDOT \# containing alphabetic characters.

5.  Send results to the requester's mailbox.

[Requirement to be validated:]{.underline}

-   IMH must read the snapshot request from the input mailbox

-   IMH must recognize it as a carrier snapshot request

-   IMH must parse the EDI format request to obtain the DOT number

-   IMH must fill in the request structure with the DOT number

-   IMH must call the appropriate SDM routine to continue processing

-   SDM must receive the packet header, request header, and request with
    the fields filled in properly for each test request. It must forward
    the correct packet header, request header, and request to OMH for
    further processing.

-   OMH must receive the proper carrier snapshot request from
    SDM_retrieve_safety_data.

-   OMH must query the database and retrieve a carrier snapshot,
    provided that the DOT number is a valid one.

-   OMH must send the snapshot to the requester's mailbox in text form.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

Mail messages, with carrier snapshot requests using a single digit
USDOT#, a seven digit USDOT#, a USDOT# not contained in the database,
and an erroneous USDOT# containing alphabetic characters.

[Expected Outcome:]{.underline}

Carrier snapshots will be successfully retrieved for the single digit
and seven digit USDOT numbers and will be received in the requester's
mailbox. For the USDOT number not contained in the database, and the
erroneous one containing alphabetic characters, the database retrieval
will fail, and a failure message will be received in the requester's
mailbox.

[Test Procedure Steps:]{.underline}

Set up the messages in Eudora. Send them to the IMH input mailbox.

Read the four replies from the requester's mailbox. Verify that carrier
snapshots were received for the two valid USDOT numbers and that failure
messages were received for the two invalid ones.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Carrier Snapshot

[SYS ID:]{.underline} SYS-CS-004

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The single digit USDOT# test case succeeded. The correct carrier
    snapshot was received in the requester's mailbox.

-   The seven digit USDOT# test case succeeded. The correct carrier
    snapshot was received in the requester's mailbox.

-   The USDOT# that did not exist in the database resulted in a failure
    message.

-   The USDOT# containing alphabetic characters resulted in a failure
    message.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Carrier Snapshot

[SYS ID:]{.underline} SYS-CS-005

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH, SDM, OMH

[System Function:]{.underline}

1.  Process a carrier snapshot request that is pure nonsense (that does
    not begin with 'R', 'C', or 'S').

2.  Process a carrier snapshot request containing 'R' followed by
    nonsense.

3.  Process a carrier snapshot request containing 'C' followed by
    nonsense.

4.  Process a carrier snapshot request containing 'S' followed by
    nonsense.

[Requirement to be validated:]{.underline}

-   The system must process erroneous incoming requests by rejecting
    them without crashing, and by informing the requester of an error if
    appropriate.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

Mail messages, with carrier snapshot requests containing pure nonsense,
'R' followed by nonsense, 'S' followed by nonsense, and 'C' followed by
nonsense.

[Expected Outcome:]{.underline}

The system will not query the database for a pure nonsense, since it is
not a request at all. An invalid file type message should print to the
screen, but no mail message will be generated.

The system will attempt to update the database with a 'C' followed by
nonsense carrier snapshot update request. Since the update will fail,
subscribers will not receive carrier snapshots.

'R' or 'S' followed by nonsense will cause retrieval failure messages to
be sent to the requester's mailbox..

[Test Procedure Steps:]{.underline}

Set up the messages in Eudora. Send them to the IMH input mailbox.

View output screen for possible error messages.

Check requester's mailbox for retrieval failure messages.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Carrier Snapshot

[SYS ID:]{.underline} SYS-CS-005

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   For the pure nonsense request, a message was printed to the console
    that it was not a valid message type and the system did not process
    it further.

-   For the 'C' plus nonsense message, an attempt was made to update the
    database. It failed. Failure messages were sent to subscribers. This
    was a bug that was subsequently corrected, because nothing should
    have been sent to the subscriber list.

-   For the 'R' and 'S' plus nonsense messages, the retrievals failed
    and failure messages were sent to the requester's mailbox.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Carrier Snapshot

[SYS ID:]{.underline} SYS CS-006

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH, SDM, OMH

[System Function:]{.underline}

1.  Send, accept, and process a single mailbox request for a carrier
    snapshot using a USDOT# as input in Aspen format (D=USDOT#).

2.  Send results to requester's mailbox.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot request from the input mailbox

-   IMH must recognize it as a carrier snapshot request in Aspen format

-   IMH must parse the Aspen (D=#) format request to obtain the DOT
    number

-   IMH must fill in the request structure with the DOT number

-   IMH must call the appropriate SDM routine to continue processing

-   SDM must receive the packet header, request header, and request
    properly filled in with data types and the desired DOT number.

-   SDM calls OMH with the packet header, request header, and send
    request properly filled in.

-   OMH must receive the proper carrier snapshot request from
    SDM_retrieve_safety_data.

-   OMH must query the database and retrieve the snapshot, provided that
    the DOT number is valid.

-   OMH must send the snapshot to the requester's mailbox in text form.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

Mail message containing the following two lines:

RCS

D=4

[Expected Outcome:]{.underline}

The carrier snapshot for DOT number 4 should be received in text form in
the requester's mailbox.

[Test Procedure Steps:]{.underline}

Set up the message in Eudora. Send it to the IMH input mailbox.

Read carrier snapshot for the USDOT number in the requester's mailbox.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Carrier Snapshot

[SYS ID:]{.underline} SYS CS-006

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The correct carrier snapshot was received in the requester's
    mailbox.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Carrier Snapshot

[SYS ID:]{.underline} SYS CS-009

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH, SDM, OMH

[System Function:]{.underline}

1.  Send, accept, and process mailbox requests for a carrier snapshot
    using USDOT numbers as inputs at various rates to determine system
    responsiveness.

2.  Determine saturation point- first point at which mailbox is filling
    faster than it is emptying.

3.  Before doing this, determine the minimum Sleep statement that will
    prevent POP3 error messages.

4.  Send results to requesters' mailboxes.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot request from the input mailbox

-   IMH must fill in the request structure with the DOT number

-   IMH must call the appropriate SDM routine to continue processing

-   IMH must perform the above steps repeatedly under any reasonable
    level of system load.

-   Spurious POP3 error messages should not be printed to the output
    screen.

-   SDM must receive the packet header, request header, and request
    properly filled in with data types and the desired DOT number.

-   SDM must call OMH with the packet header, request header, and send
    request properly filled in.

-   OMH must receive the proper carrier snapshot request from
    SDM_retrieve_safety_data.

-   OMH must query the database and retrieve a carrier snapshot,
    provided that the DOT number is a valid one.

-   OMH must send the snapshot to the requester's mailbox in text form.

-   Rapidly processing a large number of requests in sequence will not
    cause a crash or processing overload for OMH.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

For this test, multiple requesters must be used to stress the system.
One requester cannot send messages fast enough with EudoraLite, even if
they are set up in advance.

During the test, no other processing should be done on the system.

To further stress the system, one hundred requests were queued in the
input mailbox before the IMH process was started. Then three requester's
each sent one hundred additional requests at the same time. (Some of the
three hundred requests were submitted twice).

[Input Data:]{.underline}

Three hundred mail messages containing carrier snapshot requests in EDI
format.

[Expected Outcome:]{.underline}

Large numbers of requests will not crash or confuse the system. The
system will be able to handle three to four hundred snapshot requests
within a period of five to seven minutes.

[Test Procedure Steps:]{.underline}

Set up three hundred different carrier snapshot request messages in
EudoraLite.

Send one hundred requests to the IMH input mailbox.

Start processing.

Each requester will immediately send the assigned test messages to the
IMH input mailbox.

Wait a few minutes for IMH to finish all retrievals.

Each requester will read the responses sent by the system to his/her
mailbox and verify that a snapshot was received corresponding to each
request submitted.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Carrier Snapshot

[SYS ID:]{.underline} SYS CS-009

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   A Sleep statement of 225 milliseconds prevented POP3 error messages.
    200 milliseconds did not prevent all error messages, but did prevent
    most, so 225 ms seems to be a good threshold.

-   Carrier snapshots were rapidly received for the one hundred requests
    queued up before processing began. Two of the requesters rapidly
    received carrier snapshots for all requests submitted. The third
    requester was not using a proper Eudora account to send requests and
    receive responses. Some of his requests succeeded, but most failed.
    However, the problem seemed to be within the Eudora setup, not
    within IMH. IMH did not crash, and perfectly processed all other
    requests.

-   A saturation point was not reached with three people testing.
    Further testing must be done with a larger number of requesters.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Carrier Update

[SYS ID:]{.underline} SYS CU-001

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH, SDM, OMH

[System Function:]{.underline}

1.  Send, accept and process a single mailbox request for carrier
    snapshot add operation.

2.  Use an empty subscriber list (no subscribers).

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot add request from the input mailbox

-   IMH must recognize it as a carrier snapshot add request

-   IMH must call the appropriate SDM routine to continue processing and
    provide it with the correct data types and the database update
    record itself.

-   SDM_update_data must receive a packet header, data header, and
    update data filled in with accurate information so that it can
    update the database.

-   Since there are no subscribers, messages should not be sent.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

One database update request, with valid data, and a USDOT number not yet
existing in the database.

[Expected Outcome:]{.underline}

The database will be updated with the correct carrier snapshot record.
Since there are no subscribers, no snapshot messages will be sent to
mailboxes.

[Test Procedure Steps:]{.underline}

Send the update message to the IMH input mailbox.

Step through processing in debugger to verify that no attempt is made to
mail snapshots to nonexistent subscribers.

After the system processes the message, use SQLPlus to verify that the
record was written to the database.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Carrier Update

[SYS ID:]{.underline} SYS-CU-001

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The carrier snapshot was correctly written to the database.

-   No mail messages were sent to nonexistent subscribers..

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Carrier Update

[SYS ID:]{.underline} SYS-CU-002

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH, SDM, OMH

[System Function:]{.underline}

1.  Send, accept and process a single mailbox request for carrier
    snapshot add operation.

2.  Use a subscriber list containing one and only one valid subscriber.

3.  Send copy of updated carrier snapshot to the one subscriber.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot add request from the input mailbox

-   IMH must recognize it as a carrier snapshot add request

-   IMH must call the appropriate SDM routine to continue processing and
    provide it with the correct data types and the database update
    record itself.

-   SDM_update_data must receive a packet header, data header, and
    update data filled in with accurate information so that it can
    update the database.

-   SDM must call SLP to forward a snapshot update to the one
    subscriber.

-   OMH will forward a mail message containing a copy of the newly added
    snapshot to the one subscriber.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

One database update request, with valid data, and a USDOT number not yet
existing in the database.

[Expected Outcome:]{.underline}

The carrier snapshot will be successfully added to the database. The one
subscriber will receive a copy of the snapshot.

[Test Procedure Steps:]{.underline}

Set up the subscription table in the database to contain just one
subscriber.

Mail the update message to the IMH input mailbox.

When the system finishes processing the message, use SQLPlus to verify
that the carrier snapshot was added to the database.

Verify that a copy of the carrier snapshot was sent to the subscriber's
mailbox.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Carrier Update

[SYS ID:]{.underline} SYS-CU-002

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The carrier snapshot was written to the database.

-   A copy of the snapshot was sent to the one subscriber's mailbox.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Carrier Update

[SYS ID:]{.underline} SYS-CU-003

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH, SDM, OMH

[System Function:]{.underline}

1.  Send, accept and process a single mailbox request for carrier
    snapshot add operation.

2.  Use a subscriber list containing at least three subscribers, one of
    which is invalid.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot add request from the input mailbox

-   IMH must recognize it as a carrier snapshot add request

-   IMH must call the appropriate SDM routine to continue processing and
    provide it with the correct data types and the database update
    record itself.

-   SDM_update_data must receive a packet header, data header, and
    update data filled in with accurate information so that it can
    update the database.

-   SDM must call SL_fulfill_subscription to forward a snapshot update
    to the subscribers.

-   OMH will forward a mail message containing a copy of the newly added
    snapshot to the valid subscribers.

-   Having an invalid subscriber on the list will not cause a crash or
    processing problems.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

One database update request, with valid data, and a USDOT number not yet
existing in the database.

[Expected Outcome:]{.underline}

The carrier snapshot will be successfully added to the database. The
valid subscribers will receive copies of the snapshot in their
mailboxes. A snapshot message will be sent to the invalid user and the
mail system will deal with it as an invalid address.

[Test Procedure Steps:]{.underline}

Send carrier snapshot update message to the IMH input mailbox.

After the system finishes processing the message, use SQLPlus to view
the new snapshot record in the database.

Verify that the two valid subscribers receive copies of the snapshot in
their mailboxes.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Carrier Update

[SYS ID:]{.underline} SYS-CU-003

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, data header, and update data were
    properly filled in and passed to SDM_update_safety_data.

-   The carrier snapshot was added to the database.

-   The two valid subscribers received copies of the snapshot in their
    mailboxes.

-   The invalid subscriber case caused a problem due to a bug in MBX,
    which is being corrected.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Carrier Update

[SYS ID:]{.underline} SYS-CU-006

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH, SDM, OMH

[System Function:]{.underline}

1.  Send, accept and process five separate mailbox requests for carrier
    snapshot add operations.

2.  Use a subscriber list containing at least three subscribers, one of
    which is invalid.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot add request from the input mailbox

-   IMH must recognize it as a carrier snapshot add request

-   IMH must call the appropriate SDM routine to continue processing and
    provide it with the correct data types and the database update
    record itself.

-   IMH must be able to perform the above steps five successive times.

-   SDM_update_data must receive a packet header, data header, and
    update data filled in with accurate information so that it can
    update the database.

-   SDM must call SL_fulfill_subscription to forward a snapshot update
    to the subscribers.

-   SDM must perform the above steps five times successively.

-   OMH must forward copies of the newly added snapshots to the valid
    subscribers' mailboxes.

-   Having an invalid subscriber on the list will not cause a crash or
    processing problems.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and send results to the requester's mailbox.

[Input Data:]{.underline}

Five database update requests, with valid data, and USDOT numbers not
yet existing in the database.

[Expected Outcome:]{.underline}

The five carrier snapshots will be written to the database.

The two valid subscribers will receive copies of the five snapshots in
their mailboxes.

The invalid subscriber will not cause processing problems. The mail
system will simply handle it like any other invalid address.

[Test Procedure Steps:]{.underline}

Send five valid carrier snapshot update requests to the IMH input
mailbox.

Verify that the subscription list in the database contains three
subscribers, two of which are valid and one of which is invalid.

When processing is completed, verify, using SQLPlus, that the five
snapshots were added to the database.

Verify that both valid subscribers received copies of the five snapshots
in their mailboxes.

Verify that the invalid subscriber did not cause processing problems.

**System Functionality Test Report**

[System ID:]{.underline} Carrier Update

[SYS ID:]{.underline} SYS-CU-006

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The five carrier snapshots were correctly added to the database.

-   Copies of the five snapshots were received in the two valid
    subscribers' mailboxes.

-   The invalid subscriber case caused a problem due to a bug in MBX,
    which is being corrected.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Carrier Update

[SYS ID:]{.underline} SYS-CU-007

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH, SDM, OMH

[System Function:]{.underline}

1.  Send, accept and process five separate mailbox requests for carrier
    snapshot add operations when five add requests are already in the
    queue when IMH processing starts.

2.  Use a subscriber list containing at least three subscribers, one of
    which is invalid.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot add request from the input mailbox

-   IMH must recognize it as a carrier snapshot add request

-   IMH must call the appropriate SDM routine to continue processing and
    provide it with the correct data types and the database update
    record itself.

-   IMH must be able to process five queued requests immediately upon
    being initialized, and then perform the above steps five successive
    times for additional update records.

-   SDM_update_data must receive a packet header, data header, and
    update data filled in with accurate information so that it can
    update the database.

-   SDM must call SL_fulfill_subscription to forward a snapshot update
    to the subscribers.

-   SDM must perform the above steps ten times successively.

-   OMH will forward mail messages containing copies of the newly added
    snapshots to the valid subscribers.

-   Having an invalid subscriber on the list will not cause a crash or
    processing problems.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

Ten database update requests, with valid data, and USDOT numbers not yet
existing in the database.

[Expected Outcome:]{.underline}

The ten carrier snapshots will be written to the database.

The two valid subscribers will receive copies of the ten snapshots in
their mailboxes.

The invalid subscriber will not cause processing problems. The mail
system will simply handle it like any other invalid address.

[Test Procedure Steps:]{.underline}

Send ten valid carrier snapshot update requests to the IMH input
mailbox.

Verify that the subscription list in the database contains three
subscribers, two of which are valid and one of which is invalid.

When processing is completed, verify, using SQLPlus, that the ten
snapshots were added to the database.

Verify that both valid subscribers received copies of the five snapshots
in their mailboxes.

Verify that the invalid subscriber did not cause processing problems.

[Analysis Procedures:]{.underline}

**System Functionality Test Report**

[System ID:]{.underline} Carrier Update

[SYS ID:]{.underline} SYS-CU-007

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The ten carrier snapshots were correctly added to the database.

-   Copies of the ten snapshots were received in the two valid
    subscribers' mailboxes.

-   The invalid subscriber case caused a problem due to a bug in MBX,
    which is being corrected.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Accounting

[SYS ID:]{.underline} SYS-AC-001

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} ADM/ACT, IMH, SDM

[System Function:]{.underline}

1.  Send, accept, and process a single request to create an organization
    record in the database.

2.  The message should identify an organization not yet contained in the
    database.

3.  The message should add one or more initial users to the database as
    part of the organization.

[Requirement to be validated:]{.underline}

-   IMH_read_account_request must correctly parse the create
    organization message received in the input mailbox, and copy each
    piece of information contained in the message into the appropriate
    structures for further processing.

-   ADM_ACCT_create_org_account must verify that the requester has the
    privileges to create the organization record.

-   ADM_ACCT_create_org_account must create the organization record with
    a unique identification label.

-   ADM_ACCT_create_user_account must add any users identified in the
    create organization message to the database as a part of that
    organization.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

A valid request to create one organization with two initial users was
used as input.

[Expected Outcome:]{.underline}

The organization record and two user records will be correctly written
to the database.

[Test Procedure Steps:]{.underline}

Set up the message in EudoraLite. Send it to the IMH input mailbox.

When processing is completed, use the SQLPlus utility to view the
organization record and the two user records in the database.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Accounting

[SYS ID:]{.underline} SYS-AC-001

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The organization record was written to the database and filled in
    with the proper information.

-   The two user records were written to the database and were filled in
    properly.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Accounting

[SYS ID:]{.underline} SYS-AC-002

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} ADM/ACT, IMH, SDM

[System Function:]{.underline}

1.  Send, accept, and process a request to add one or more users to the
    database as part of an existing organization.

2.  Verify that the users were correctly entered into the database.

[Requirement to be validated:]{.underline}

-   IMH_read_account_request must correctly parse the create user
    message received in the input mailbox, and copy each piece of
    information contained in the message into the appropriate structures
    for further processing.

-   ADM_ACCT_create_user must verify that the user's organization
    already exists in the database.

-   ADM_ACCT_create_user must verify that the requester is valid and is
    associated with the organization.

-   ADM_ACCT_update_user_account must verify that the requester has the
    privileges to add the user record to the database.

-   ADM_ACCT_create_user must verify that the user does not already
    exist in the database as part of that organization.

-   ADM_ACCT_create_user must correctly add the user to the database.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

The input was a valid create user message containing data for two new
users for a previously existing organization. The message contained a
valid requester id for that organization.

[Expected Outcome:]{.underline}

Records for the two new users will be correctly written to the database.

[Test Procedure Steps:]{.underline}

Set up the message in EudoraLite. Send it to the IMH input mailbox.

When processing is completed, use SQLPlus to verify that the new user
records were correctly entered in the database.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Accounting

[SYS ID:]{.underline} SYS-AC-002

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Records for the two new users were correctly added to the database.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Accounting

[SYS ID:]{.underline} SYS-AC-003

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} ADM/ACT, IMH, SDM

[System Function:]{.underline}

1.  Send, accept, and process a request to update an organization
    already existing in the database

2.  The message will contain a valid requester id and the requester will
    have the necessary privileges.

[Requirement to be validated:]{.underline}

-   IMH_read_account_request must correctly parse the update
    organization message received in the input mailbox, and copy each
    piece of information contained in the message into the appropriate
    structures for further processing.

-   ADM_ACCT_update_org_account must verify that the organization
    already exists in the database.

-   ADM_ACCT_update_org_account must verify that the requester is valid
    and is associated with the organization.

-   ADM_ACCT_update_user_account must verify that the requester has the
    privileges to update the organization record.

-   ADM_ACCT_update_org_account must correctly make the requested
    modifications to the organization record.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

Input was a message containing an existing organization, a valid
requester id, and a request to modify the telephone number and part of
the mailing address.

[Expected Outcome:]{.underline}

The telephone number and mailing address will be updated for that
organization.

[Test Procedure Steps:]{.underline}

Set up the message in EudoraLite. Send it to the IMH input mailbox.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Accounting

[SYS ID:]{.underline} SYS-AC-003

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The organization record was modified as requested in the database.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Accounting

[SYS ID:]{.underline} SYS-AC-004

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} ADM/ACT, IMH, SDM

[System Function:]{.underline}

1.  Send, accept, and process a message containing a request to update
    user information.

2.  The input message should contain a valid organization, requester,
    and user.

[Requirement to be validated:]{.underline}

-   IMH_read_account_request must correctly parse the update
    organization message received in the input mailbox, and copy each
    piece of information contained in the message into the appropriate
    structures for further processing.

-   ADM_ACCT_update_user_account must verify that the user's
    organization already exists in the database.

-   ADM_ACCT_update_user_account must verify that the requester is valid
    and is associated with the organization.

-   ADM_ACCT_update_user_account must verify that the requester has the
    privileges to update the user record.

-   ADM_ACCT_update_user_account must verify that the user already
    exists in the database.

-   ADM_ACCT_update_user_account must make the requested modifications
    to the user record.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and send results to the requester's mailbox.

[Input Data:]{.underline}

The input was a message requesting that the telephone number, extension,
and city be changed for one user, and that the country be changed for
another user.

[Expected Outcome:]{.underline}

All requested changes will be made to the two users records in the
database.

[Test Procedure Steps:]{.underline}

Use SQLPlus to view the records for the two users. Verify that the
information in their fields is different from the information in the
update user request.

Set up the message in EudoraLite. Send it to the IMH input mailbox.

When processing is completed, use the SQLPlus utility to verify that the
records for the two users have changed appropriately.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Accounting

[SYS ID:]{.underline} SYS-AC-004

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The requested changes were made to the two user records.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Accounting

[SYS ID:]{.underline} SYS-AC-005

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} ADM/ACT, IMH, SDM

[System Function:]{.underline}

1.  Send, accept, and process a request to delete a user.

2.  The request message will contain a user id existing in the database,
    and a valid requester.

3.  The request message will contain the correct organization id for the
    user.

[Requirement to be validated:]{.underline}

-   IMH_read_account_request must correctly parse the delete user
    message received in the input mailbox, and copy each piece of
    information contained in the message into the appropriate structures
    for further processing.

-   ADM_ACCT_delete_user_account must verify that the requester has the
    privileges to delete the user record.

-   ADM_ACCT_delete_user_account must verify that the requester is not
    deleting his own record.

-   ADM_ACCT_delete_user_account must remove the users identified from
    the database.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

Input consisted of a delete user request that specified one valid user
in a valid organization. The requester was also valid, and had the
privileges to delete users.

[Expected Outcome:]{.underline}

The user will be deleted.

[Test Procedure Steps:]{.underline}

Using the SQLPlus utility, verify that the user exists in the database.

Set up the message in EudoraLite. Send it to the IMH input mailbox.

Using the SQLPlus utility, verify that the user no longer exists in the
database.

[Analysis Procedures:]{.underline}

**System Functionality Test Report**

[System ID:]{.underline} Accounting

[SYS ID:]{.underline} SYS-AC-005

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The correct user was deleted from the database.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Accounting

[SYS ID:]{.underline} SYS-AC-006

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} ADM/ACT, IMH, SDM

[System Function:]{.underline}

1.  Send, accept, and process a request to delete an organization.

2.  The message will contain an organization identifier existing in the
    database, and will have a valid requester with the privileges to
    delete an organization.

[Requirement to be validated:]{.underline}

-   IMH_read_account_request must correctly parse the create
    organization message received in the input mailbox, and copy each
    piece of information contained in the message into the appropriate
    structures for further processing.

-   ADM_ACCT_delete_org_account must verify that the requester has the
    privileges to delete the organization record.

-   ADM_ACCT_delete_org_account must verify the organization exists in
    the database.

-   ADM_ACCT_delete_org_account must delete the organization.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

Input was a message containing a valid organization identifier and a
valid requester.

[Expected Outcome:]{.underline}

The organization record will be deleted from the database.

[Test Procedure Steps:]{.underline}

Using SQLPlus, verify that the organization exists in the database.

Set up the message in EudoraLite. Send it to the IMH input mailbox.

Using SQLPlus, verify that the organization no longer exists in the
database.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Accounting

[SYS ID:]{.underline} SYS-AC-006

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The requested organization was deleted from the database.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Subscription List

[SYS ID:]{.underline} SYS-SL-001

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SLP, IMH, SDM

[System Function:]{.underline}

1.  Send, accept, and process a single request to create a subscription
    record in the database.

2.  The subscription request message should be for a subscriber not yet
    included in the database.

3.  At least two USDOT numbers should be entered in the parameter list.

[Requirement to be validated:]{.underline}

-   IMH_read_subscription_request must correctly parse the create
    subscription message received in the input mailbox, and copy each
    piece of information contained in the message into the appropriate
    structures for further processing.

-   SLP_create must check whether the subscription already exists in the
    database.

-   SLP_create must create the subscription using the sender's
    identifier as the user id.

-   SLP_create must correctly add the USDOT numbers to the subscriber
    parameter table in the database.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

A valid request to add a subscriber was used as input. Two USDOT numbers
were placed in the parameter list.

[Expected Outcome:]{.underline}

The subscriber will be added to the database.

[Test Procedure Steps:]{.underline}

Set up the message in EudoraLite. Send it to the IMH input mailbox.

When processing is completed, use the SQLPlus utility to view the
subscription record.

[Analysis Procedures:]{.underline}

**System Functionality Test Report**

[System ID:]{.underline} Subscription List

[SYS ID:]{.underline} SYS-SL-001

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The subscriber was correctly entered in the database subscription
    table.

-   The subscriber's selected USDOT numbers were correctly entered into
    the subscriber parameter list.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Subscription List

[SYS ID:]{.underline} SYS-SL-002

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SLP, IMH, SDM, OMH

[System Function:]{.underline}

1.  Send, accept, and process a single request to add a carrier snapshot
    to the database.

2.  The subscription table in the database should contain at least one
    valid subscriber who will receive a copy of the snapshot.

[Requirement to be validated:]{.underline}

-   IMH_read_subscription_request must correctly parse the create
    subscription message received in the input mailbox, and copy each
    piece of information contained in the message into the appropriate
    structures for further processing.

-   SLP_monitor must read the subscription table.

-   SLP_monitor must call SDM to extract the new snapshot from the
    database and send copies to all subscribers.

-   SLP_create must check whether the subscription already exists in the
    database.

-   SLP_create must create the subscription using the sender's
    identifier as the user id.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

A valid request to add a carrier snapshot was used as input.

[Expected Outcome:]{.underline}

The carrier snapshot will be added to the database.

All valid subscribers in the subscription table of the database will
receive copies of the carrier snapshot.

[Test Procedure Steps:]{.underline}

Set up the message in EudoraLite. Send it to the IMH input mailbox.

When processing is completed, use the SQLPlus utility to view the new
carrier snapshot record in the database.

Read each subscribers mailbox to verify that a copy of the carrier
snapshot was received.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Subscription List

[SYS ID:]{.underline} SYS-SL-002

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
10/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The carrier snapshot was added to the database.

-   Each subscriber received a copy of the carrier snapshot.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**System Functionality Test Plan**

[System ID:]{.underline} Subscription List

[SYS ID:]{.underline} SYS-SL-003

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SLP, IMH, SDM, OMH

[System Function:]{.underline}

1.  Send, accept, and process a single request retrieve a carrier
    snapshot and add the USDOT number to the requester's parameter list.

2.  The message should contain a valid USDOT number contained in the
    database.

3.  The requester should already be listed as a subscriber in the
    subscription table, and should have one or more USDOT numbers
    already set up in the subscriber parameters table. The requested
    USDOT number should not yet be in the subscriber parameters table,
    however.

4.  The user_seq value used in the message must match that in the
    subscription record.

[Requirement to be validated:]{.underline}

-   IMH_read_subscription_request must correctly parse the create
    subscription message received in the input mailbox, and copy each
    piece of information contained in the message into the appropriate
    structures for further processing.

-   IMH_translate_message must recognize the input message as a request
    to retrieve the snapshot and append the USDOT number to the
    subscriber's parameter list.

-   SLP_create must check whether the subscription already exists in the
    database.

-   SLP_create must call SLP_append to append the requested USDOT number
    to the subscriber's parameter list.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The SDB
library of SQL statements embedded in C code was used to retrieve the
snapshot from the Oracle v.7.2 database. The SQLPlus utility was used to
view the database and verify results. The MBX library, based on the
Distinct mail protocol software, was used to extract the message from
the mailbox for processing and to forward results to the requester's
mailbox.

[Input Data:]{.underline}

A valid request to retrieve a carrier snapshot and add the USDOT number
to the subscriber's parameter list was used. The format was as follows:

R

A=111

PTest1

where PTest1 is the user_seq value.

[Expected Outcome:]{.underline}

A copy of the carrier snapshot will be sent to the requester's mailbox.

The USDOT number will be added to the requester's parameter list.

[Test Procedure Steps:]{.underline}

Set up the message in EudoraLite. Send it to the IMH input mailbox.

When processing is completed, use the SQLPlus utility to view the
subscriber parameters table and verify that the requested USDOT number
has been added.

Read the requester's mailbox to verify that a copy of the carrier
snapshot was received.

[Analysis Procedures:]{.underline}

-   

**System Functionality Test Report**

[System ID:]{.underline} Subscription List

[SYS ID:]{.underline} SYS-SL-003

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
11/5//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The USDOT number was added to the requester's subscriber parameter
    list in the database.

-   The requester received a copy of the carrier snapshot.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

# System Performance and Stress Test Plan

## Introduction

This section describes the performance tests carried out on the CVIEW
system to determine its readiness for supporting roadside data exchange
operations. The performance attributes of the CVIEW system may be
divided into four areas: online query, subscription fulfillment,
subscription download and client database update. Each of these areas
will be characterized.

The purpose of system performance and stress testing is to identify and
mitigate performance factors that might prevent successful operation of
the CVIEW system. A variety of techniques, including measurement
techniques and the use of analytical and queueing models, have been used
to support this type of testing. Performance testing is used to identify
and characterize fundamental performance factors while analytical and
queuing models are used to extend these empirical results to support
predictive estimates when temporal and system testing resources are
limited.

## Scope

The CVIEW System's performance will be characterized in two separate
functional areas. The CVIEW system is required to perform two distinct
functions, first database updates and distribution of data to
subscribers based on them, and second, responding to queries from
clients.

The process of updating and distributing data from the CVIEW database
can be analyzed into three steps for the purpose of performance testing.
The first is subscription fulfillment, the second, subscription
download, and the third is client database update.

-   Subscription fulfillment is the process of updating the CVIEW
    database with data obtained from external sources, e.g., SAFER, and
    posting data changes to users' mail boxes in accordance with their
    subscriptions. The performance test of this process is described in
    section 2.3, *Subscription Fulfillment.*

-   Subscription download is the process of transferring the updated
    data from a user's mail box to the user's client machine. It is
    exclusive of the process of updating the client's database with the
    transferred data. The performance test of this process is described
    in section 2.4, *Subscription Download*.

-   Client database update is the process of using the transferred
    update data to alter the client's local database and thus make the
    information available to the user. The performance test of this
    process is described in section 2.5, *Client Database Update*.

In addition to the processes described above, the CVIEW system will be
able to accept requests for specific carrier, vehicle, and driver
snapshots and return them to the requesting client. The performance
test, as it relates to carrier snapshot processing, is described in
section 2.6, *Query Processing*.

## Subscription Fulfillment Test

To Be Supplied (TBS)

## Subscription Download Test

### Subscription Size Characterization; Download Response Time Test

The size of the subscription data to be downloaded and the speed of the
network on which it is transferred will be the two primary factors
governing download response time. In this section, the size of the
subscription data and the response time resulting from its transference
over a 28.8K (kilo-bits per second) connection are estimated. This
transfer rate was selected as a representative dial-up connection.

#### Method

A subscription file is generated from an update file in several steps:

-   The update snapshots for carriers that fit the user's subscription
    are selected. Our tests assumed that users will be interested in all
    carriers.

-   A selected snapshot is checked against its current state in the
    CVIEW database to determine what changes have occurred. Only if the
    snapshot has changed significantly is it selected for the user's
    subscription. The selection algorithm used is described below.

-   The selected snapshots are written out to disk in the transfer
    format. Only the information required by the user, called his view,
    is stored on disk. ASPEN users will receive data based on the ISS
    view.

-   The file containing the snapshots is compressed and stored in the
    user's mailbox.

To predict the results of the first two steps, the selection algorithm
was run against several MCMIS update files. This was used, along with
statistics from past MCMIS updates to predict the number of records that
would typically be sent to a user.

To predict the results of the last two steps, various numbers of
snapshots were selected from the CVIEW database, written to disk in
"application file format" and compressed. The resulting file size was
measured and the results were used to predict the size of a transfer
file given the number of records to be sent.

To predict the transfer time, the number of bits for a particular
expected file size was calculated based on the assumption of 10 bits per
byte (to account for communication overhead).

#### Data and Analysis

The expected size of a weekly MCMIS update was estimated based on 42
weeks of MCMIS updates occurring between 4/30/96 and 3/9/97. The average
number of records per update was 39,709 and the standard deviation was
19,387. Figure 3 illustrates the expected probability density for a
MCMIS update record count.

![](media/image5.emf)

The expected size of an ISS update to be sent to a MCSAP site was
estimated as a function of the size of the MCMIS update.

Records were chosen for an ISS update if any of the following changes
occurred:

-   The update moves the record into a new category, either INSPECT,
    OPTIONAL or PASS

-   The update **increases** the ISS score by 10 or more points.

-   Any change to the NAME, DBA NAME, or the address fields, including
    ADDRESS, CITY, STATE, ZIP and ZIP+4.

ISS updates from four weekly MCMIS files were chosen using the selection
criteria listed above. These were used to derive an ISS update record
count formula based on the size of a MCMIS update. Figure 4 illustrates
the results.

![](media/image6.emf)

Using the mean and standard deviation for MCMIS updates and the
correlation function characterized in Figure 4, the expected record
counts for ISS updates was estimated and is shown in Figure 5. The
average update is estimated to be approximately 3,300 records/week,
while the 90^th^ percentile is approximately 4,400 records/week.

![](media/image7.emf)

The size of a ISS update record may vary as a result of varying field
lengths contained within the record. As such, the length of an ISS
update file will vary in size. In addition, the application of
compression techniques will introduce additional file size variability.
To estimate the size of an ISS update file, random samples of ISS update
records were assembled, formatted in the ISS view and compressed. Based
on the linear relationship illustrated in Figure 6, ISS update file
sizes were estimated.

![](media/image8.emf)

#### Results

Based on the results of analysis from section 2.4.1.2, response time
estimates for the download of an ISS update from CVIEW to a user, e.g.,
an ASPEN system, were made. The assumptions were:

-   The connection between CVIEW and the receiving system is established
    via a 28.8 K dial-up line.

-   Communication overhead is estimated at about 2 bits per byte, for a
    total of 10 bits per byte.

-   MIME encoding (for SMTP transmission of binary data) adds about 1/3
    to the file size.

-   The 28.8 K communications link between the receiving system and
    CVIEW is the limiting performance factor. This assumption is
    verified in section 2.4.2, *Server Performance and Response Time.*

Figure 7 shows the expected download time for weekly ISS update files
given the assumptions and results stated above.

![](media/image9.emf)

### Server Performance and Response Time Test

The purpose of this test is to ensure that the CVIEW server is correctly
configured to provide the speed and capacity required to support
subscription download operations to no fewer than 200 MCSAP sites.
**Test results are TBS**.

#### Dependent Variables

The following performance indicators will be measured and analyzed under
permutations of the independent variables listed in the next section
during subscription download processing.

#####  Response Time

The time taken to download a subscription from the server to the client
machine and store it on the client's disk system exclusive of the time
required to make a network connection or update the client's database.

It is expected (and an objective of this test is to confirm) that for
dial up users on a 28.8 K modem, the network download time will be the
bottleneck, not the CVIEW server. Response time should therefore remain
flat over a wide range of users when connected over dial-up telephone
lines. For network connections, the bottleneck will more likely be the
CVIEW server and thus response times should be more variable.

##### RAID Disk Utilization

The [transaction rate]{.underline}, [transaction queue
depth]{.underline}, and [data transfer rate]{.underline} will be
measured or predicted.

##### CPU Utilization

The [percent of non-idle CPU time]{.underline} will be measured or
predicted.

##### Memory Utilization

The [memory utilization]{.underline} by relevant processes and the
[system page fault rate]{.underline} will be measured or predicted.

#### Independent Variables

The following loading and configuration factors will be used in various
permutations to determine their affect on the dependent variables. Not
all possible experiments will be run; the test design, described below,
specifies which experiments will be conducted. From these experiments an
analytic model will be used to predict the outcome of those experiments
not run. The results of the analytic model will form the basis for a
queuing model which will be used to simulate actual operations under
various conditions.

##### Simultaneous Clients and Clients Per Workstation

Simultaneous clients refers to the number of clients simultaneously
connected to CVIEW downloading subscription data. Performance under 1,
2, 4, 6, 10, 20 and 50 clients should be measured or reasonably
predicted by the analytic model. Up to 10 clients, each on a separate
workstation, can be reasonably measured. Test involving larger numbers
of clients may have to utilize several clients per workstation or be
derived entirely analytically.

##### Subscription File Size

Subscription files of 3,000 and 4,250 ISS records will be used. The
3,000 is the mean number of records and 4,250 is the 90^th^ percentile.
Measurements will be made with the 90^th^ percentile case first. Results
of that test will dictate whether or not it is worth while executing the
mean case.

##### Connectivity Characteristics

Two connectivity cases using LAN connectivity at a 56K bandwidth and
dial up connectivity using a 28.8K bandwidth will be considered. The LAN
connection will essentially remove the network as a bottleneck, while
the 28.8 dial up case will represent the extreme in which the network is
the bottleneck. Most testing will be done over the LAN; a few dial-up
cases will be used to substantiate the analytic model. Intermediate
cases will be estimated from the analytic model. At least one stress
test utilizing the 800 number dial up will be conducted.

##### Mail Server Configuration: NT Mail Verses Microsoft Exchange

The mail server software will be a significant factor in the performance
of the system during subscription download. Primary testing will be
performed using CVIEW's existing NT Mail system. Test cases will also be
executed using Microsoft Exchange to determine if it provides improved
performance or reliability.

###### NT Mail Thread Count

The NT Mail server allows the maximum number of threads it will support
to be configured. Tests involving variable numbers of concurrent clients
will be executed to determine the optimal NT Mail thread count.

##### Number of Mail Messages

Testing will be done primarily with only one mail message in the
client's mail box. Given that users download their subscriptions
regularly this is the most realistic case. Tests will be run with a
greater numbers per mail box to determine the affect they have on
performance.

## Client Database Update

Results TBS

### ASPEN and CVIEW API

Results TBS

### SAFER and CVIEW Visual User Environment (SafeVUE)

Results TBS

## Query Processing

Results TBS

**Appendix C - Integration Test**

**CVIEW System**

**Integration Test Plans and Test Reports**

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} IMH-CS-001

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH

[Integration Function:]{.underline}

1.  Detect, accept and process a single mailbox request for a carrier
    snapshot using a USDOT# as input in pseudo-EDI format;

2.  Send results to SDM.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot request from the input mailbox

-   IMH must recognize it as a carrier snapshot request

-   IMH must parse the EDI format request to obtain the DOT number

-   IMH must fill in the request structure with the DOT number

-   IMH must call the appropriate SDM routine to continue processing

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the request. The MBX_Read
routine was used to extract a message from the mailbox.

[Input Data:]{.underline}

An input file in EDI format was sent to IMH via the Eudora mail package:

ST\*285\*000010010

BGN\*28\*54321\*951117\*0800\*GM

NM1\*41\*1\*ECKEL\*JOHN\*MORRIS\*\*\*57\*CSI

NX1\*MC

N9\*2I\*1

LM\*FH

LQ\*T07\*Q106

LM\*FH

LQ\*T10\*Q1

LM\*FH

LQ\*T10\*Q200

REF\*MCI\*0000004

[Expected Outcome:]{.underline}

IMH will call SDM_retrieve_safety_data with the packet header request
type correctly filled with SAF_TRANS_DATA_REQUEST. The request structure
will contain the correct DOT number in the query criteria.

The carrier snapshot for DOT number 4 should be received in text form in
the requester's mailbox.

[Test Procedure Steps:]{.underline}

Set up the message in Eudora. Send it to the IMH input mailbox.

Check packet header, request header, and request passed to
SDM_retrieve_safety_data to verify that data types and DOT number are
set correctly.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} IMH-CS-001

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, request header, and request were
    properly filled in and passed to SDM_retrieve_safety_data for the
    request.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} SDM-CS-001

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SDM

[Integration Function:]{.underline}

1.  Detect, accept and process a single carrier snapshot request using a
    USDOT# as input

2.  Send results to OMH.

[Requirement to be validated:]{.underline}

-   SDM receives the packet header, request header, and request properly
    filled in with data types and the desired DOT number.

-   SDM calls OMH with the packet_header, request header, and send
    request properly filled in.

[Test Tools, Drivers, or Special Conditions:]{.underline}

None.

[Input Data:]{.underline}

Packet header, request header, and request are received as input.

[Expected Outcome:]{.underline}

OMH is called with data structures properly filled in, and is equipped
with the information needed to query the database and send results back
to the requester.

[Test Procedure Steps:]{.underline}

After a valid carrier snapshot request is sent via Eudora to IMH, verify
that SDM_retrieve_safety_data receives the request with the correct
return address, data type and DOT number.

Verify that OMH_send_safety_data is called with data structures filled
in with the correct return address, data type and DOT number.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} SDM-CS-001

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   SDM_retrieve_safety_data received all information necessary to
    complete the retrieval.

-   OMH_send_safety_data was given all information necessary to complete
    the retrieval.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} OMH-CS-001

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} OMH

[Integration Function:]{.underline}

1.  Detect, accept and process a single carrier snapshot request using a
    USDOT# as input

2.  Send results to a single requester's mailbox.

[Requirement to be validated:]{.underline}

-   OMH must receive the proper carrier snapshot request from
    SDM_retrieve_safety_data.

-   OMH must query the database and retrieve a carrier snapshot,
    provided that the DOT number is a valid one.

-   OMH must send the snapshot to the requester's mailbox in text form.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The MBX_Send routine was used to send the snapshot back to the
requester's mailbox.

SDB_get_view was called to retrieve the snapshot from the database.

[Input Data:]{.underline}

The packet header, request header, and send request are received by OMH
as inputs.

[Expected Outcome:]{.underline}

OMH will successfully query the database, retrieve the requested
snapshot, and send it to the requester's mailbox.

[Test Procedure Steps:]{.underline}

Verify that OMH_send_safety_data receives the packet header, request
header, and send request properly filled in.

Verify that OMH_output_query_database successfully calls SDB to retrieve
the snapshot.

Verify that OMH_output_message_generator successfully calls MBX_Send to
forward the snapshot to the requester.

Read the snapshot for the desired DOT number from the requester's
mailbox.

[Analysis Procedures:]{.underline}

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} OMH-CS-001

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The desired snapshot, for DOT number 4, was received in the
    requester's mailbox, and was read using the EudoraLite mail package.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Date:\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} IMH-CS-002

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH

[Integration Function:]{.underline}

1.  Detect, accept and process five mailbox requests for carrier
    snapshot using USDOT numbers as input in pseudo-EDI format;

2.  Send results to SDM.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot request from the input mailbox

-   IMH must recognize it as a carrier snapshot request

-   IMH must parse the EDI format request to obtain the DOT number

-   IMH must fill in the request structure with the DOT number

-   IMH must call the appropriate SDM routine to continue processing

-   IMH must loop through the above sequence of steps four more times
    provided that five snapshot requests are successively queued in the
    input mailbox with no other intervening messages.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the requests to the input
mailbox. The MBX_Read routine was used to extract messages from the
mailbox.

[Input Data:]{.underline}

Five mail messages, with valid carrier snapshot requests.

[Expected Outcome:]{.underline}

IMH will call SDM_retrieve_safety_data five successive times with the
packet header request type correctly filled with SAF_TRANS_DATA_REQUEST.
The request structure will contain the correct DOT number in the query
criteria.

The carrier snapshot for the five DOT numbers should be received in text
form in the requester's mailbox.

[Test Procedure Steps:]{.underline}

Start IMH process.

Set up the messages in Eudora. Send them to the IMH input mailbox.

Check packet header, request header, and request passed to
SDM_retrieve_safety_data to verify that data types and DOT number are
set correctly for each of the five messages.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} IMH-CS-002

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, request header, and request were
    properly filled in and passed to SDM_retrieve_safety_data for each
    of the five messages.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} SDM-CS-002

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SDM

[Integration Function:]{.underline}

1.  Detect, accept and process five carrier snapshot requests using
    USDOT numbers as input;

2.  Send results to OMH.

[Requirement to be validated:]{.underline}

For each of five successive carrier snapshot requests:

-   SDM receives the packet header, request header, and request properly
    filled in with data types and the desired DOT number.

-   SDM calls OMH with the packet_header, request header, and send
    request properly filled in.

-   SDM performs the above steps five times for five successive valid
    carrier snapshot requests forwarded to it by IMH.

[Test Tools, Drivers, or Special Conditions:]{.underline}

None

[Input Data:]{.underline}

Packet header, request header, and request are received as input.

[Expected Outcome:]{.underline}

OMH is called with data structures properly filled in, and is equipped
with the information needed to query the database and send results back
to the requester.

[Test Procedure Steps:]{.underline}

For each of the five carrier snapshot requests forwarded from IMH to
SDM:

Verify that SDM_retrieve_safety_data receives the request with the
correct return address, data type and DOT number.

Verify that OMH_send_safety_data is called with data structures filled
in with the correct return address, data type and DOT number.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} SDM-CS-002

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

For each of the five requests:

-   SDM_retrieve_safety_data received all information necessary to
    complete the retrieval.

-   OMH_send_safety_data was given all information necessary to complete
    the retrieval.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Date:\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} OMH-CS-002

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} OMH

[Integration Function:]{.underline}

1.  Detect, accept and process five carrier snapshot requests using
    USDOT numbers as input

2.  Send results to a single requester's mailbox.

[Requirement to be validated:]{.underline}

For each of five successive requests:

-   OMH must receive the proper carrier snapshot request from
    SDM_retrieve_safety_data.

-   OMH must query the database and retrieve a carrier snapshot,
    provided that the DOT number is a valid one.

-   OMH must send the snapshot to the requester's mailbox in text form.

-   OMH must loop through the above steps four additional times provided
    that a total of five carrier snapshots are queued in the input
    mailbox and sent by IMH to OMH.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The MBX_Send routine was used to send the snapshot back to the
requester's mailbox.

SDB_get_view was called to retrieve the snapshot from the database.

[Input Data:]{.underline}

Five successive sets of packet header, request header, and send request
are received by OMH as inputs.

[Expected Outcome:]{.underline}

OMH will successfully query the database, retrieve the requested
snapshot, and send it to the requester's mailbox for each of the five
requests.

[Test Procedure Steps:]{.underline}

For each of the five requests:

Verify that OMH_send_safety_data receives the packet header, request
header, and send request properly filled in.

Verify that OMH_output_query_database successfully calls SDB to retrieve
the snapshot.

Verify that OMH_output_message_generator successfully calls MBX_Send to
forward the snapshot to the requester.

Read the snapshot for the desired DOT number from the requester's
mailbox.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} OMH-CS-002

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The five desired snapshots were received in the requester's mailbox,
    and were read using the EudoraLite mail package.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Date:\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} IMH-CS-003

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH

[Integration Function:]{.underline}

1.  Detect, accept and process five mailbox requests for a carrier
    snapshot using USDOT numbers as input in pseudo-EDI format when five
    requests are already queued in the input mailbox;

2.  Send results to SDM.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot request from the input mailbox

-   IMH must recognize it as a carrier snapshot request

-   IMH must parse the EDI format request to obtain the DOT number

-   IMH must fill in the request structure with the DOT number

-   IMH must call the appropriate SDM routine to continue processing

-   IMH must loop through the above sequence of steps a total of ten
    times when the first five requests are already queued in the input
    mailbox before IMH is started, and then five additional requests are
    sent immediately after IMH processing begins.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the requests to the input
mailbox. The MBX_Read routine was used to extract a message from the
mailbox.

[Input Data:]{.underline}

Ten mail messages, with valid carrier snapshot requests.

[Expected Outcome:]{.underline}

IMH will call SDM_retrieve_safety_data ten successive times with the
packet header request type correctly filled with SAF_TRANS_DATA_REQUEST.
The request structure will contain the correct DOT number in the query
criteria.

The carrier snapshot for the ten DOT numbers should be received in text
form in the requester's mailbox.

[Test Procedure Steps:]{.underline}

Set up the ten messages in Eudora. Without starting IMH, send the first
five to the IMH input mailbox.

Start the IMH process.

Immediately, use Eudora to send the next five messages to the IMH input
mailbox.

For each message, check packet header, request header, and request
passed to SDM_retrieve_safety_data to verify that data types and DOT
number are set correctly.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} IMH-CS-003

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, request header, and request were
    properly filled in and passed to SDM_retrieve_safety_data for all
    ten messages.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} SDM-CS-003

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SDM

[Integration Function:]{.underline}

1.  Detect, accept and process five carrier snapshot requests using
    USDOT#'s as input when five messages are already queued in the
    mailbox before the IMH process is started;

2.  Send results to OMH.

[Requirement to be validated:]{.underline}

If IMH processing is started with five carrier snapshot requests already
queued in the mailbox, and then five additional requests are immediately
sent, SDM will do the following for each:

-   SDM receives the packet header, request header, and request properly
    filled in with data types and the desired DOT number.

-   SDM calls OMH with the packet_header, request header, and send
    request properly filled in.

-   SDM performs the above steps five times for five successive valid
    carrier snapshot requests forwarded to it by IMH.

[Test Tools, Drivers, or Special Conditions:]{.underline}

None

[Input Data:]{.underline}

Packet header, request header, and request are received as input for
each of the ten requests.

[Expected Outcome:]{.underline}

OMH is called with data structures properly filled in, and is equipped
with the information needed to query the database and send results back
to the requester for the ten DOT numbers.

[Test Procedure Steps:]{.underline}

For each of the ten carrier snapshot requests forwarded from IMH to SDM:

Verify that SDM_retrieve_safety_data receives the request with the
correct return address, data type and DOT number.

Verify that OMH_send_safety_data is called with data structures filled
in with the correct return address, data type and DOT number.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} SDM-CS-003

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

For each of the ten requests:

-   SDM_retrieve_safety_data received all information necessary to
    complete the retrieval.

-   OMH_send_safety_data was given all information necessary to complete
    the retrieval.

-   Ten correct snapshots were received by the requester.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Date:\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} OMH-CS-003

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} OMH

[Integration Function:]{.underline}

1.  Detect, accept and process five carrier snapshot requests using
    USDOT numbers as input when five requests are already queued in the
    mailbox before IMH process is started.

2.  Send results to a single requester's mailbox.

[Requirement to be validated:]{.underline}

For each of the ten requests:

-   OMH must receive the proper carrier snapshot request from
    SDM_retrieve_safety_data.

-   OMH must query the database and retrieve a carrier snapshot,
    provided that the DOT number is a valid one.

-   OMH must send the snapshot to the requester's mailbox in text form.

-   OMH must loop through the above steps four additional times provided
    that a total of five carrier snapshots are queued in the input
    mailbox and sent by IMH to OMH.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The MBX_Send routine was used to send the snapshot back to the
requester's mailbox.

SDB_get_view was called to retrieve the snapshot from the database.

[Input Data:]{.underline}

Ten successive sets of packet header, request header, and send request
are received by OMH as inputs.

[Expected Outcome:]{.underline}

OMH will successfully query the database, retrieve the requested
snapshot, and send it to the requester's mailbox for each of the ten
requests.

[Test Procedure Steps:]{.underline}

For each of the ten requests:

Verify that OMH_send_safety_data receives the packet header, request
header, and send request properly filled in.

Verify that OMH_output_query_database successfully calls SDB to retrieve
the snapshot.

Verify that OMH_output_message_generator successfully calls MBX_Send to
forward the snapshot to the requester.

Read the snapshot for the desired DOT number from the requester's
mailbox.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} OMH-CS-003

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The ten desired snapshots were received in the requester's mailbox,
    and were read using the EudoraLite mail package.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Date:\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} IMH-CS-004

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH

[Integration Function:]{.underline}

1.  Detect, accept and process a carrier snapshot request using a single
    digit USDOT #.

2.  Detect, accept and process a carrier snapshot request using a seven
    digit USDOT #.

3.  Detect, accept and process a carrier snapshot request using a USDOT
    \# not contained in the database.

4.  Detect, accept and process a carrier snapshot request using an
    erroneous USDOT \# containing alphabetic characters.

5.  Send results to SDM.

[Requirement to be validated:]{.underline}

-   IMH must read the snapshot request from the input mailbox

-   IMH must recognize it as a carrier snapshot request

-   IMH must parse the EDI format request to obtain the DOT number

-   IMH must fill in the request structure with the DOT number

-   IMH must call the appropriate SDM routine to continue processing

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the requests to the input
mailbox. The MBX_Read routine was used to extract a message from the
mailbox.

[Input Data:]{.underline}

Mail messages, with carrier snapshot requests using a single digit
USDOT#, a seven digit USDOT#, a USDOT# not contained in the database,
and an erroneous USDOT# containing alphabetic characters.

[Expected Outcome:]{.underline}

IMH will call SDM_retrieve_safety_data ten successive times with the
packet header request type correctly filled with SAF_TRANS_DATA_REQUEST.
The request structure will contain the correct DOT number in the query
criteria.

The carrier snapshot for the ten DOT numbers should be received in text
form in the requester's mailbox.

[Test Procedure Steps:]{.underline}

Set up the messages in Eudora. Send them to the IMH input mailbox.

For each message, check packet header, request header, and request
passed to SDM_retrieve_safety_data to verify that data types and DOT
numbers are set correctly. (For the DOT number containing alphabetic
characters, it obviously cannot be set correctly but will probably have
been converted to a zero).

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} IMH-CS-004

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The single digit USDOT# test case succeeded.

-   The seven digit USDOT# test case succeeded.

-   The USDOT# that did not exist in the database resulted in a failure
    message.

-   The USDOT# containing alphabetic characters resulted in a failure
    message.

-   For all test cases, the request forwarded to SDM had the structures
    filled in correctly, with the exception of the USDOT \# containing
    alphabetic characters. For that one, the ascii to long integer
    conversion failed, returned a zero, placed zero in the structure as
    the carrier id, and resulted in retrieval failure, as would be
    expected. IMH did not crash.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} SDM-CS-004

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SDM

[Integration Function:]{.underline}

1.  Detect, accept and process a carrier snapshot request using a single
    digit USDOT #.

2.  Detect, accept and process a carrier snapshot request using a seven
    digit USDOT #.

3.  Detect, accept and process a carrier snapshot request using a USDOT
    \# not contained in the database.

4.  Detect, accept and process a carrier snapshot request using an
    erroneous USDOT \# containing alphabetic characters.

5.  Send results to OMH.

[Requirement to be validated:]{.underline}

-   SDM must receive the packet header, request header, and request with
    the fields filled in properly for each test request. It must forward
    the correct packet header, request header, and request to OMH for
    further processing.

[Test Tools, Drivers, or Special Conditions:]{.underline}

None.

[Input Data:]{.underline}

Packet headers, request headers, and requests filled in correctly, with
carrier snapshot requests single digit USDOT#, a seven digit USDOT#, a
USDOT# not contained in the database, and an erroneous USDOT# containing
alphabetic characters.

[Expected Outcome:]{.underline}

For each request, SDM will call OMH_send_safety_data with the data type
and USDOT# set correctly. (In case of the erroneous USDOT# with
alphabetic carriers, conversion to zero will be considered a desirable
result).

[Test Procedure Steps:]{.underline}

For each message, check packet header, request header, and request
received by SDM_retrieve_safety_data have data types and DOT numbers set
correctly. (For the DOT number containing alphabetic characters, it
obviously cannot be set correctly but will probably have been converted
to a zero). Similarly, verify that packet header, request header, and
request have the correct settings when passed to OMH_send_safety_data
for each message.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} SDM-CS-004

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The single digit USDOT# test case succeeded.

-   The seven digit USDOT# test case succeeded.

-   The USDOT# that did not exist in the database resulted in a failure
    message.

-   The USDOT# containing alphabetic characters resulted in a failure
    message.

-   For all test cases, the request received by SDM had the structures
    filled in correctly, with the exception of the USDOT \# containing
    alphabetic characters. For that one, the ascii to long integer
    conversion failed, returned a zero, placed zero in the structure as
    the carrier id.

-   For all test cases, the packet header, request header, and send
    request forwarded to OMH had the data types and USDOT numbers set
    correctly, or to zero in the case of the alphabetic DOT number.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} OMH-CS-004

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} OMH

[Integration Function:]{.underline}

1.  Detect, accept and process a carrier snapshot request using a single
    digit USDOT #.

2.  Detect, accept and process a carrier snapshot request using a seven
    digit USDOT #.

3.  Detect, accept and process a carrier snapshot request using a USDOT
    \# not contained in the database.

4.  Detect, accept and process a carrier snapshot request using an
    erroneous USDOT \# containing alphabetic characters.

5.  Send results to the requester's mailbox.

[Requirement to be validated:]{.underline}

-   OMH must receive the proper carrier snapshot request from
    SDM_retrieve_safety_data.

-   OMH must query the database and retrieve a carrier snapshot,
    provided that the DOT number is a valid one.

-   OMH must send the snapshot to the requester's mailbox in text form.

[Test Tools, Drivers, or Special Conditions:]{.underline}

None.

[Input Data:]{.underline}

Packet headers, request headers, and send requests filled in correctly,
with carrier snapshot requests single digit USDOT#, a seven digit
USDOT#, a USDOT# not contained in the database, and an erroneous USDOT#
containing alphabetic characters.

[Expected Outcome:]{.underline}

For each test message, OMH will successfully query the database,
retrieve the requested snapshot, and send it to the requester's mailbox.

[Test Procedure Steps:]{.underline}

For each test message:

Verify that OMH_send_safety_data receives the packet header, request
header, and send request properly filled in.

Verify that OMH_output_query_database successfully calls SDB to retrieve
the snapshot.

Verify that OMH_output_message_generater successfully calls MBX_Send to
forward the snapshot to the requester.

Read the snapshot for the desired DOT number from the requester's
mailbox.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} OMH-CS-004

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The single digit USDOT# test case succeeded.

-   The seven digit USDOT# test case succeeded.

-   The USDOT# that did not exist in the database resulted in a failure
    message.

-   The USDOT# containing alphabetic characters resulted in a failure
    message.

-   For all test cases, the request received by SDM had the structures
    filled in correctly, with the exception of the USDOT \# containing
    alphabetic characters. For that one, the ascii to long integer
    conversion failed, returned a zero, placed zero in the structure as
    the carrier id.

-   For all test cases, the packet header, request header, and send
    request received by OMH had the data types and USDOT numbers set
    correctly, or to zero in the case of the alphabetic DOT number.

-   For the single digit and seven digit USDOT numbers, the snapshot
    retrieval succeeded and the snapshots were sent to the requester's
    mailbox and read from it. For the non-existing USDOT# and the one
    containing alphabetic characters (which was converted to zero, a
    non-existing USDOT#), the database queries failed, and a failure
    message was sent to the requester's mailbox.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} IMH-CS-005

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH

[Integration Function:]{.underline}

1.  Process a carrier snapshot request that is pure nonsense (that does
    not begin with 'R', 'C', or 'S').

2.  Process a carrier snapshot request containing 'R' followed by
    nonsense.

3.  Process a carrier snapshot request containing 'C' followed by
    nonsense.

4.  Process a carrier snapshot request containing 'S' followed by
    nonsense.

[Requirement to be validated:]{.underline}

-   IMH must process erroneous incoming requests by rejecting them
    without crashing, and by informing the requester of an error if
    appropriate.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the requests to the input
mailbox. The MBX_Read routine was used to extract a message from the
mailbox.

[Input Data:]{.underline}

Mail messages, with carrier snapshot requests containing pure nonsense,
'R' followed by nonsense, 'S' followed by nonsense, and 'C' followed by
nonsense.

[Expected Outcome:]{.underline}

IMH will not forward the pure nonsense request to SDM, since it is not a
request at all.

IMH will forward 'C' followed by nonsense to SDM as a carrier snapshot
update request although it does not contain a valid record for updating
the database.

IMH will not forward 'R' or 'S' followed by nonsense requests to SDM.

[Test Procedure Steps:]{.underline}

Set up the messages in Eudora. Send them to the IMH input mailbox.

View output screen for possible error messages.

Check request structures forwarded to SDM_retrieve_safety_data for the
'R' and 'S' plus nonsense requests.

Check structures forwarded to SDM_update_safety_data for the 'C' plus
nonsense request.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} IMH-CS-005

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   For the pure nonsense request, IMH printed a message to the console
    that it was not a valid message type and did not process it further.

-   For the 'C' plus nonsense message, IMH accepted it as a snapshot
    update request and forwarded it to SDM.

-   For the 'R' plus nonsense message, IMH accepted it as a snapshot
    retrieval request, but did not extract a valid USDOT# from the
    message. It forwarded a request for USDOT# zero to SDM.

-   The 'S' plus nonsense message caused IMH to crash while trying to
    parse the EDI segments to obtain a USDOT#. (This problem was
    corrected later by improving error handling in the EDI parse
    routines. After correction, a request for USDOT# was forwarded to
    SDM, but IMH no longer crashed.)

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} SDM-CS-005

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SDM

[Integration Function:]{.underline}

1.  Process a carrier snapshot request that is pure nonsense (that does
    not begin with 'R', 'C', or 'S').

2.  Process a carrier snapshot request containing 'R' followed by
    nonsense.

3.  Process a carrier snapshot request containing 'C' followed by
    nonsense.

4.  Process a carrier snapshot request containing 'S' followed by
    nonsense.

5.  Forward results, if any, to OMH for further processing.

[Requirement to be validated:]{.underline}

-   SDM must process erroneous incoming requests without crashing.

[Test Tools, Drivers, or Special Conditions:]{.underline}

None.

[Input Data:]{.underline}

Input for 'R' or 'S' plus nonsense was the carrier snapshot request
structure. Input for 'C' plus nonsense was the carrier snapshot update
structure.

[Expected Outcome:]{.underline}

The pure nonsense message will never reach SDM.

'C' plus nonsense will result in a failure by SDB when trying to update
the database with a totally invalid record.

'R' and 'S' plus nonsense with result in SDM trying to retrieve USDOT# =
0, which does not exist. An error message will be forwarded to OMH.

[Test Procedure Steps:]{.underline}

Set up the messages in Eudora. Send them to the IMH input mailbox.

View output screen for possible error messages.

Check request structures forwarded to SDM_retrieve_safety_data for the
'R' and 'S' plus nonsense requests.

Check structures forwarded to SDM_update_safety_data for the 'C' plus
nonsense request.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} SDM-CS-005

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   For the pure nonsense request, SDM was not called by IMH.

-   For the 'C' plus nonsense message, SDB attempted to update the
    database and failed.

-   For the 'R' and 'S' plus nonsense message, SDM received structures
    containing zero for the USDOT#. SDB then failed to retrieve a
    snapshot. OMH was called to output an error message.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Date:\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} OMH-CS-005

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} OMH

[Integration Function:]{.underline}

1.  Process a carrier snapshot request that is pure nonsense (that does
    not begin with 'R', 'C', or 'S').

2.  Process a carrier snapshot request containing 'R' followed by
    nonsense.

3.  Process a carrier snapshot request containing 'C' followed by
    nonsense.

4.  Process a carrier snapshot request containing 'S' followed by
    nonsense.

5.  Forward results, if any, to requester's mailbox.

[Requirement to be validated:]{.underline}

-   OMH must process erroneous incoming requests without crashing.

[Test Tools, Drivers, or Special Conditions:]{.underline}

EudoraLite mail package and MBX_Send routine were used to return results
to the requester.

[Input Data:]{.underline}

Input for 'R' or 'S' plus nonsense was the carrier snapshot send request
structure. OMH received no input for pure nonsense or 'C' plus nonsense.

[Expected Outcome:]{.underline}

The pure nonsense message will never reach OMH.

'C' plus nonsense will result in a failure by SDB when trying to update
the database with a totally invalid record and will not require any
processing by OMH.

'R' and 'S' plus nonsense with result in OMH forwarding a snapshot
retrieval failure message to the requester's mailbox.

[Test Procedure Steps:]{.underline}

Check request structures forwarded to OMH by SDM_retrieve_safety_data
for the 'R' and 'S' plus nonsense requests.

Check output screen and requester's mailbox for error messages.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} OMH-CS-005

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   For the pure nonsense request, OMH was not reached.

-   For the 'C' plus nonsense message, SDB attempted to update the
    database and failed. No action was required of OMH

-   For the 'R' and 'S' plus nonsense message, SDM received structures
    containing zero for the USDOT#. SDB then failed to retrieve a
    snapshot. OMH output snapshot retrieval failure messages to the
    requester's mailbox.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} IMH-CS-006

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH

[Integration Function:]{.underline}

1.  Send, accept, and process a single mailbox request for a carrier
    snapshot using a USDOT# as input in Aspen format (D=USDOT#).

2.  Send results to SDM.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot request from the input mailbox

-   IMH must recognize it as a carrier snapshot request in Aspen format

-   IMH must parse the Aspen (D=#) format request to obtain the DOT
    number

-   IMH must fill in the request structure with the DOT number

-   IMH must call the appropriate SDM routine to continue processing

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the requests to the input
mailbox. The MBX_Read routine was used to extract a message from the
mailbox.

[Input Data:]{.underline}

Mail message containing the following two lines:

RCS

D=4

[Expected Outcome:]{.underline}

IMH will call SDM_retrieve_safety_data with the packet header request
type correctly filled with SAF_TRANS_DATA_REQUEST. The request structure
will contain the correct DOT number in the query criteria.

The carrier snapshot for DOT number 4 should be received in text form in
the requester's mailbox.

[Test Procedure Steps:]{.underline}

Set up the message in Eudora. Send it to the IMH input mailbox.

Check packet header, request header, and request passed to
SDM_retrieve_safety_data to verify that data types and DOT number are
set correctly.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} IMH-CS-006

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, request header, and request were
    properly filled in and passed to SDM_retrieve_safety_data.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} SDM-CS-006

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SDM

[Integration Function:]{.underline}

1.  Detect, accept and process a single carrier snapshot request using
    USDOT numbers as input in Aspen format (D=USDOT#);

2.  Send results to OMH.

[Requirement to be validated:]{.underline}

-   SDM receives the packet header, request header, and request properly
    filled in with data types and the desired DOT number.

-   SDM calls OMH with the packet header, request header, and send
    request properly filled in.

[Test Tools, Drivers, or Special Conditions:]{.underline}

None

[Input Data:]{.underline}

Packet header, request header, and request are received as input.

[Expected Outcome:]{.underline}

OMH is called with data structures properly filled in, and is equipped
with the information needed to query the database and send results back
to the requester.

[Test Procedure Steps:]{.underline}

Verify that SDM_retrieve_safety_data receives the request with the
correct return address, data type and DOT number.

Verify that OMH_send_safety_data is called with data structures filled
in with the correct return address, data type and DOT number.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} SDM-CS-006

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   SDM_retrieve_safety_data received all information necessary to
    complete the retrieval.

-   OMH_send_safety_data was given all information necessary to complete
    the retrieval.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Date:\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} OMH-CS-006

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} OMH

[Integration Function:]{.underline}

1.  Detect, accept and process a single carrier snapshot request using
    USDOT numbers as input in Aspen format (D=USDOT#).

2.  Send results to a single requester's mailbox.

[Requirement to be validated:]{.underline}

-   OMH must receive the proper carrier snapshot request from
    SDM_retrieve_safety_data.

-   OMH must query the database and retrieve a carrier snapshot,
    provided that the DOT number is a valid one.

-   OMH must send the snapshot to the requester's mailbox in text form.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The MBX_Send routine was used to send the snapshot back to the
requester's mailbox.

SDB_get_view was called to retrieve the snapshot from the database.

[Input Data:]{.underline}

Packet header, request header, and send request are received by OMH as
inputs.

[Expected Outcome:]{.underline}

OMH will successfully query the database, retrieve the requested
snapshot, and send it to the requester's mailbox for the request.

[Test Procedure Steps:]{.underline}

Verify that OMH_send_safety_data receives the packet header, request
header, and send request properly filled in.

Verify that OMH_output_query_database successfully calls SDB to retrieve
the snapshot.

Verify that OMH_output_message_generator successfully calls MBX_Send to
forward the snapshot to the requester.

Read the snapshot for the desired DOT number from the requester's
mailbox.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} OMH-CS-006

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The desired snapshot was received in the requester's mailbox, and
    was read using the EudoraLite mail package.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Date:\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} IMH-CS-009

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH

[Integration Function:]{.underline}

1.  Send, accept, and process mailbox requests for a carrier snapshot
    using USDOT numbers as inputs at various rates to determine system
    responsiveness.

2.  Determine saturation point- first point at which mailbox is filling
    faster than it is emptying.

3.  Before doing this, determine the minimum Sleep statement that will
    prevent POP3 error messages.

4.  Send results to SDM.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot request from the input mailbox

-   IMH must fill in the request structure with the DOT number

-   IMH must call the appropriate SDM routine to continue processing

-   IMH must perform the above steps repeatedly under any reasonable
    level of system load.

-   Spurious POP3 error messages should not be printed to the output
    screen.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the requests to the input
mailbox. The MBX_Read routine was used to extract a message from the
mailbox.

For this test, multiple requesters must be used to stress the system.
One requester cannot send messages fast enough with EudoraLite, even if
they are set up in advance.

During the test, no other processing should be done on the system.

To further stress the system, one hundred requests were queued in the
input mailbox before the IMH process was started. Then three requester's
each sent one hundred additional requests at the same time. (Some of the
three hundred requests were submitted twice).

[Input Data:]{.underline}

Three hundred mail messages containing carrier snapshot requests in EDI
format.

[Expected Outcome:]{.underline}

Large numbers of requests will not crash or confuse IMH. IMH will be
able to handle three to four hundred snapshot requests within a period
of five to seven minutes.

[Test Procedure Steps:]{.underline}

Each requester will read the responses sent by OMH to his/her mailbox
and verify that a snapshot was received corresponding to each request
submitted. Set up three hundred different carrier snapshot request
messages in Eudora.

Send one hundred to the IMH input mailbox.

Start IMH processing.

Each requester will immediately send the assigned test messages to the
IMH input mailbox.

Wait a few minutes for IMH to finish all retrievals.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} IMH-CS-009

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   A Sleep statement of 225 milliseconds prevented POP3 error messages.
    200 milliseconds did not prevent all error messages, but did prevent
    most, so 225 ms seems to be a good threshold.

-   Carrier snapshots were rapidly received for the one hundred requests
    queued up before IMH processing began. Two of the requesters rapidly
    received carrier snapshots for all requests submitted. The third
    requester was not using a proper Eudora account to send requests and
    receive responses. Some of his requests succeeded, but most failed.
    However, the problem seemed to be within the Eudora setup, not
    within IMH. IMH did not crash, and perfectly processed all other
    requests.

-   A saturation point was not reached with three people testing.
    Further testing must be done with a larger number of requesters.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} SDM-CS-009

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SDM

[Integration Function:]{.underline}

1.  Send, accept, and process mailbox requests for a carrier snapshot
    using USDOT numbers as inputs at various rates to determine system
    responsiveness.

2.  Determine saturation point- first point at which mailbox is filling
    faster than it is emptying.

3.  Before doing this, determine the minimum Sleep statement that will
    prevent POP3 error messages.

4.  Send results to OMH.

[Requirement to be validated:]{.underline}

-   SDM receives the packet header, request header, and request properly
    filled in with data types and the desired DOT number.

-   SDM calls OMH with the packet header, request header, and send
    request properly filled in.

[Test Tools, Drivers, or Special Conditions:]{.underline}

None

[Input Data:]{.underline}

Packet header, request header, and request are received as input for
each request.

[Expected Outcome:]{.underline}

SDM receives requests properly filled in with the USDOT numbers.

OMH is called with data structures properly filled in, and is equipped
with the information needed to query the database and send results back
to the requester.

Large number of requests will be processed sequentially and result in no
confusion or overload.

[Test Procedure Steps:]{.underline}

Set up three hundred different carrier snapshot request messages in
Eudora.

Send one hundred to the IMH input mailbox.

Start IMH processing.

Each requester will immediately send the assigned test messages to the
IMH input mailbox.

Wait a few minutes for IMH to finish all retrievals.

Verify that SDM_retrieve_safety_data receives the request with the
correct return address, data type and DOT number.

Verify that OMH_send_safety_data is called with data structures filled
in with the correct return address, data type and DOT number.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} SDM-CS-009

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Carrier snapshots were rapidly received for the one hundred requests
    queued up before processing began. Two of the requesters rapidly
    received carrier snapshots for all requests submitted. The third
    requester was not using a proper Eudora account to send requests and
    receive responses. Some of his requests succeeded, but most failed.
    However, the problem seemed to be within the Eudora setup, not
    within SDM. SDM did not crash, and perfectly processed all other
    requests.

-   SDM_retrieve_safety_data received all information necessary to
    complete the retrievals.

-   OMH_send_safety_data was given all information necessary to complete
    the retrievals.

-   

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Date:\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} OMH-CS-009

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} OMH

[Integration Function:]{.underline}

1.  Send, accept, and process mailbox requests for a carrier snapshot
    using USDOT numbers as inputs at various rates to determine system
    responsiveness.

2.  Determine saturation point- first point at which mailbox is filling
    faster than it is emptying.

3.  Before doing this, determine the minimum Sleep statement that will
    prevent POP3 error messages.

4.  Send results to requesters' mailboxes.

[Requirement to be validated:]{.underline}

-   OMH must receive the proper carrier snapshot request from
    SDM_retrieve_safety_data.

-   OMH must query the database and retrieve a carrier snapshot,
    provided that the DOT number is a valid one.

-   OMH must send the snapshot to the requester's mailbox in text form.

-   Rapidly processing a large number of requests in sequence will not
    cause a crash or processing overload for OMH.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The MBX_Send routine was used to send the snapshot back to the
requester's mailbox.

SDB_get_view was called to retrieve the snapshot from the database.

[Input Data:]{.underline}

Packet header, request header, and send request are received by OMH as
inputs for each request.

[Expected Outcome:]{.underline}

OMH will successfully query the database, retrieve the requested
snapshot, and send it to the requester's mailbox for the request even
though hundreds of snapshot requests are received in a few minutes.

[Test Procedure Steps:]{.underline}

Set up three hundred different carrier snapshot request messages in
Eudora.

Send one hundred to the IMH input mailbox.

Start IMH processing.

Each requester will immediately send the assigned test messages to the
IMH input mailbox.

Wait a few minutes for IMH to finish all retrievals.

Verify that OMH_send_safety_data receives the packet header, request
header, and send request properly filled in.

Verify that OMH_output_query_database successfully calls SDB to retrieve
the snapshot.

Verify that OMH_output_message_generator successfully calls MBX_Send to
forward the snapshot to the requester.

Read the snapshot for the desired DOT number from the requester's
mailbox.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Snapshot

[ITP ID:]{.underline} OMH-CS-009

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Carrier snapshots were rapidly received for the one hundred requests
    queued up before processing began. Two of the requesters rapidly
    received carrier snapshots for all requests submitted. The third
    requester was not using a proper Eudora account to send requests and
    receive responses. Some of his requests succeeded, but most failed.
    However, the problem seemed to be within the Eudora setup, not
    within OMH. OMH did not crash, and perfectly processed all other
    requests.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} IMH-CU-001

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH

[Integration Function:]{.underline}

1.  Send, accept and process a single mailbox request for carrier
    snapshot add operation.

2.  Use an empty subscriber list (no subscribers).

3.  Send results to SDM.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot add request from the input mailbox

-   IMH must recognize it as a carrier snapshot add request

-   IMH must call the appropriate SDM routine to continue processing and
    provide it with the correct data types and the database update
    record itself.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the requests to the input
mailbox. The MBX_Read routine was used to extract messages from the
mailbox.

[Input Data:]{.underline}

One database update request, with valid data, and a USDOT# not yet
existing in the database.

[Expected Outcome:]{.underline}

IMH will call SDM_update_safety_data with the correct packet header,
data header, and update data.

[Test Procedure Steps:]{.underline}

Check packet header, data header, and update data passed to
SDM_update_safety_data to verify that data structures are correctly
filled in for the update request.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} IMH-CU-001

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, data header, and update data were
    properly filled in and passed to SDM_update_safety_data.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} SDM-CU-001

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SDM

[Integration Function:]{.underline}

1.  Send, accept and process a single mailbox request for carrier
    snapshot add operation.

2.  Use an empty subscriber list (no subscribers).

3.  Send results to OMH if appropriate.

[Requirement to be validated:]{.underline}

-   SDM_update_data must receive a packet header, data header, and
    update data filled in with accurate information so that it can
    update the database.

[Test Tools, Drivers, or Special Conditions:]{.underline}

None.

[Input Data:]{.underline}

One database update request, with valid data, and a USDOT# not yet
existing in the database.

Subscription list file (existing, but empty).

[Expected Outcome:]{.underline}

IMH will call SDM_update_safety_data with the correct packet header,
data header, and update data.

[Test Procedure Steps:]{.underline}

Check packet header, data header, and update data passed to
SDM_update_safety_data to verify that data structures are correctly
filled in for the update request.

Verify that no attempt is made by SL_fulfill_subscription to send
updates to users, since the subscription list is empty in this test.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} SDM-CU-001

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, data header, and update data were
    properly filled in and passed to SDM_update_safety_data.

-   SL_fulfill_subscription correctly found that the subscription list
    was empty, and did not try to send updates to any mailboxes.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} OMH-CU-001

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} OMH

[Integration Function:]{.underline}

1.  Send, accept and process a single mailbox request for carrier
    snapshot add operation.

2.  Use an empty subscriber list (no subscribers).

3.  Do not attempt to send updates to any subscribers.

[Requirement to be validated:]{.underline}

-   Since there are no subscribers who need to receive updates, OMH
    should not be reached in this test.

[Test Tools, Drivers, or Special Conditions:]{.underline}

None.

[Input Data:]{.underline}

No input should be received by OMH.

[Expected Outcome:]{.underline}

OMH will never be called and will do nothing in this test case.

[Test Procedure Steps:]{.underline}

Verify that within SL_fulfill_subscription, since the subscription list
is empty, SDM_retrieve_safety_data is never called.

Check output screen for possible error messages.

Check mailboxes for erroneous attempts to send updates to users.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} OMH-CU-001

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   OMH was never called, and did nothing.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} IMH-CU-002

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH

[Integration Function:]{.underline}

1.  Send, accept and process a single mailbox request for carrier
    snapshot add operation.

2.  Use a subscriber list containing one and only one valid subscriber.

3.  Send results to SDM.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot add request from the input mailbox

-   IMH must recognize it as a carrier snapshot add request

-   IMH must call the appropriate SDM routine to continue processing and
    provide it with the correct data types and the database update
    record itself.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the requests to the input
mailbox. The MBX_Read routine was used to extract messages from the
mailbox.

[Input Data:]{.underline}

One database update request, with valid data, and a USDOT# not yet
existing in the database.

[Expected Outcome:]{.underline}

IMH will call SDM_update_safety_data with the correct packet header,
data header, and update data.

[Test Procedure Steps:]{.underline}

Check packet header, data header, and update data passed to
SDM_update_safety_data to verify that data structures are correctly
filled in for the update request.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} IMH-CU-002

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, data header, and update data were
    properly filled in and passed to SDM_update_safety_data.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} SDM-CU-002

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SDM

[Integration Function:]{.underline}

1.  Send, accept and process a single mailbox request for carrier
    snapshot add operation.

2.  Use a subscriber list containing one and only one valid subscriber.

3.  Send results to OMH to forward to the subscriber.

[Requirement to be validated:]{.underline}

-   SDM_update_data must receive a packet header, data header, and
    update data filled in with accurate information so that it can
    update the database.

-   SDM must call SL_fulfill_subscription to forward a snapshot update
    to the one subscriber.

[Test Tools, Drivers, or Special Conditions:]{.underline}

Use SQLPlus to view the newly added record and verify that it was
written to the database properly.

[Input Data:]{.underline}

One database update request, with valid data, and a USDOT# not yet
existing in the database.

Subscription list file containing the mail address for one subscriber.

[Expected Outcome:]{.underline}

SDM_update_safety_data will receive the correct packet header, data
header, and update data.

SL_fulfill_subscription will call SDM_retrieve_safety_data to obtain the
updated snapshot and request OMH to forward it to the subscriber.

[Test Procedure Steps:]{.underline}

Check packet header, data header, and update data passed to
SDM_update_safety_data to verify that data structures are correctly
filled in for the update request.

Verify that SL_fulfill_subscription and SDM_retrieve_safety_data perform
all processing necessary to enable OMH to forward a copy of the updated
snapshot to the one subscriber.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} SDM-CU-002

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, data header, and update data were
    properly filled in and passed to SDM_update_safety_data.
    SDM_update_safety_data successfully added the record to the
    database.

-   SL_fulfill_subscription correctly read the subscription list, and
    called SDM_retrieve_safety_data to retrieve the updated snapshot and
    forward information to OMH.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} OMH-CU-002

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} OMH

[Integration Function:]{.underline}

1.  Send, accept and process a single mailbox request for carrier
    snapshot add operation.

2.  Use a subscriber list containing one and only one subscriber.

3.  Send a copy of the updated snapshot to the one subscriber.

[Requirement to be validated:]{.underline}

-   OMH will forward a mail message containing a copy of the newly added
    snapshot to the one subscriber.

[Test Tools, Drivers, or Special Conditions:]{.underline}

MBX_Send routine is used to forward the message to the subscriber's
mailbox. EudoraLite mail package is used to read the message and verify
that an updated carrier snapshot was received by the subscriber.

[Input Data:]{.underline}

A valid packet header, request header, and send request will be the
input to OMH.

[Expected Outcome:]{.underline}

OMH will query the database, obtain a copy of the newly added record,
and send it to the subscriber.

[Test Procedure Steps:]{.underline}

Verify that OMH_query_database successfully retrieves the new record.

Verify that OMH_output_message_generator forwards the new snapshot to
the subscriber.

Read message in subscriber's mailbox. Verify that the correct snapshot
was sent.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} OMH-CU-002

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The new carrier snapshot was sent to the subscriber's mailbox.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} IMH-CU-003

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH

[Integration Function:]{.underline}

1.  Send, accept and process a single mailbox request for carrier
    snapshot add operation.

2.  Use a subscriber list containing at least three subscribers, one of
    which is invalid.

3.  Send results to SDM.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot add request from the input mailbox

-   IMH must recognize it as a carrier snapshot add request

-   IMH must call the appropriate SDM routine to continue processing and
    provide it with the correct data types and the database update
    record itself.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the requests to the input
mailbox. The MBX_Read routine was used to extract messages from the
mailbox.

[Input Data:]{.underline}

One database update request, with valid data, and a USDOT# not yet
existing in the database.

[Expected Outcome:]{.underline}

IMH will call SDM_update_safety_data with the correct packet header,
data header, and update data.

[Test Procedure Steps:]{.underline}

Check packet header, data header, and update data passed to
SDM_update_safety_data to verify that data structures are correctly
filled in for the update request.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} IMH-CU-003

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, data header, and update data were
    properly filled in and passed to SDM_update_safety_data.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} SDM-CU-003

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SDM

[Integration Function:]{.underline}

1.  Send, accept and process a single mailbox request for carrier
    snapshot add operation.

2.  Use a subscriber list containing at least three subscribers, one of
    which is invalid.

3.  Send results to OMH to forward to the subscribers.

[Requirement to be validated:]{.underline}

-   SDM_update_data must receive a packet header, data header, and
    update data filled in with accurate information so that it can
    update the database.

-   SDM must call SL_fulfill_subscription to forward a snapshot update
    to the subscribers.

[Test Tools, Drivers, or Special Conditions:]{.underline}

Use SQLPlus to view the newly added record and verify that it was
written to the database properly.

[Input Data:]{.underline}

One database update request, with valid data, and a USDOT# not yet
existing in the database.

Subscription list file containing the mail address for three or more
subscribers, one of which is invalid.

[Expected Outcome:]{.underline}

SDM_update_safety_data will receive the correct packet header, data
header, and update data.

SL_fulfill_subscription will call SDM_retrieve_safety_data to obtain the
updated snapshot and request OMH to forward it to the subscribers.

[Test Procedure Steps:]{.underline}

Check packet header, data header, and update data passed to
SDM_update_safety_data to verify that data structures are correctly
filled in for the update request.

Verify that SL_fulfill_subscription and SDM_retrieve_safety_data perform
all processing necessary to enable OMH to forward a copy of the updated
snapshot to the subscribers.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} SDM-CU-003

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, data header, and update data were
    properly filled in and passed to SDM_update_safety_data.
    SDM_update_safety_data successfully added the record to the
    database.

-   SL_fulfill_subscription correctly read the subscription list, and
    called SDM_retrieve_safety_data to retrieve the updated snapshot and
    forward information to OMH.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} OMH-CU-003

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} OMH

[Integration Function:]{.underline}

1.  Send, accept and process a single mailbox request for carrier
    snapshot add operation.

2.  Use a subscriber list containing at least three subscribers, one of
    which is invalid.

3.  Send a copy of the updated snapshot to the subscribers.

[Requirement to be validated:]{.underline}

-   OMH will forward a mail message containing a copy of the newly added
    snapshot to the valid subscribers.

-   Having an invalid subscriber on the list will not cause a crash or
    processing problems.

[Test Tools, Drivers, or Special Conditions:]{.underline}

MBX_Send routine is used to forward the message to the subscriber's
mailbox. EudoraLite mail package is used to read the message and verify
that an updated carrier snapshot was received by the subscriber.

[Input Data:]{.underline}

A valid packet header, request header, and send request will be the
input to OMH.

[Expected Outcome:]{.underline}

OMH will query the database, obtain a copy of the newly added record,
and send it to the subscribers.

[Test Procedure Steps:]{.underline}

Verify that OMH_query_database successfully retrieves the new record.

Verify that OMH_output_message_generator forwards the new snapshot to
the subscribers.

Read message in each subscriber's mailbox. Verify that the correct
snapshot was sent.

Check output screen for error messages concerning invalid subscriber.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} OMH-CU-003

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The new carrier snapshot was sent to each valid subscriber's
    mailbox.

-   An error message concerning "Unknown user" was printed on the output
    screen. The invalid subscriber caused no processing problems.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} IMH-CU-006

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH

[Integration Function:]{.underline}

1.  Send, accept and process five separate mailbox requests for carrier
    snapshot add operations.

2.  Use a subscriber list containing at least three subscribers, one of
    which is invalid.

3.  Send results to SDM.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot add request from the input mailbox

-   IMH must recognize it as a carrier snapshot add request

-   IMH must call the appropriate SDM routine to continue processing and
    provide it with the correct data types and the database update
    record itself.

-   IMH must be able to perform the above steps five successive times.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the requests to the input
mailbox. The MBX_Read routine was used to extract messages from the
mailbox.

[Input Data:]{.underline}

Five database update requests, with valid data, and USDOT#'s not yet
existing in the database.

[Expected Outcome:]{.underline}

IMH will call SDM_update_safety_data with the correct packet header,
data header, and update data for each update request.

[Test Procedure Steps:]{.underline}

Check packet header, data header, and update data passed to
SDM_update_safety_data to verify that data structures are correctly
filled in for each update request.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} IMH-CU-006

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, data header, and update data were
    properly filled in and passed to SDM_update_safety_data for each of
    the five requests.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} SDM-CU-006

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SDM

[Integration Function:]{.underline}

1.  Send, accept and process five separate mailbox requests for carrier
    snapshot add operations.

2.  Use a subscriber list containing at least three subscribers, one of
    which is invalid.

3.  Send results to OMH to forward to the subscribers.

[Requirement to be validated:]{.underline}

-   SDM_update_data must receive a packet header, data header, and
    update data filled in with accurate information so that it can
    update the database.

-   SDM must call SL_fulfill_subscription to forward a snapshot update
    to the subscribers.

-   SDM must perform the above steps five times successively.

[Test Tools, Drivers, or Special Conditions:]{.underline}

Use SQLPlus to view the newly added records and verify that they were
written to the database properly.

[Input Data:]{.underline}

Five database update requests, with valid data, and USDOT#'s not yet
existing in the database.

Subscription list file containing the mail address for three or more
subscribers, one of which is invalid.

[Expected Outcome:]{.underline}

SDM_update_safety_data will receive the correct packet header, data
header, and update data for each request.

SL_fulfill_subscription will call SDM_retrieve_safety_data to obtain the
updated snapshot and request OMH to forward it to the subscribers for
each request.

[Test Procedure Steps:]{.underline}

Check packet header, data header, and update data passed to
SDM_update_safety_data to verify that data structures are correctly
filled in for the update requests.

Verify that SL_fulfill_subscription and SDM_retrieve_safety_data perform
all processing necessary to enable OMH to forward a copy of each of the
five updated snapshots to the subscribers.

[Analysis Procedures:]{.underline}

**Integration Test Report**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} SDM-CU-006

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, data header, and update data were
    properly filled in and passed to SDM_update_safety_data.
    SDM_update_safety_data successfully added the five records to the
    database.

-   SL_fulfill_subscription correctly read the subscription list, and
    called SDM_retrieve_safety_data to retrieve the updated snapshots
    and forward information to OMH.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} OMH-CU-006

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} OMH

[Integration Function:]{.underline}

1.  Send, accept and process five separate mailbox requests for carrier
    snapshot add operations.

2.  Use a subscriber list containing at least three subscribers, one of
    which is invalid.

3.  Send a copy of the updated snapshots to the subscribers.

[Requirement to be validated:]{.underline}

-   OMH will forward mail messages containing copies of the newly added
    snapshots to the valid subscribers.

-   Having an invalid subscriber on the list will not cause a crash or
    processing problems.

[Test Tools, Drivers, or Special Conditions:]{.underline}

MBX_Send routine is used to forward the messages to each subscriber's
mailbox. EudoraLite mail package is used to read the messages and verify
that updated carrier snapshots was received by the subscribers.

[Input Data:]{.underline}

A valid packet header, request header, and send request will be the
input to OMH for each of five requests.

[Expected Outcome:]{.underline}

OMH will query the database, obtain copies of the newly added records,
and send it to the subscribers.

[Test Procedure Steps:]{.underline}

Verify that OMH_query_database successfully retrieves the new records.

Verify that OMH_output_message_generator forwards the new snapshots to
the subscribers.

Read messages in each subscriber's mailbox. Verify that the correct
snapshots were sent.

Check output screen for error messages concerning invalid subscriber.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} OMH-CU-006

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The five new carrier snapshots were sent to each valid subscriber's
    mailbox.

-   An error message concerning "Unknown user" was printed on the output
    screen. The invalid subscriber caused no processing problems.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} IMH-CU-007

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} IMH

[Integration Function:]{.underline}

1.  Send, accept and process five separate mailbox requests for carrier
    snapshot add operations when five add requests are already in the
    queue when IMH processing starts.

2.  Use a subscriber list containing at least three subscribers, one of
    which is invalid.

3.  Send results to SDM.

[Requirement to be validated:]{.underline}

-   IMH must read a snapshot add request from the input mailbox

-   IMH must recognize it as a carrier snapshot add request

-   IMH must call the appropriate SDM routine to continue processing and
    provide it with the correct data types and the database update
    record itself.

-   IMH must be able to process five queued requests immediately upon
    being initialized, and then perform the above steps five successive
    times for additional update records.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The EudoraLite mail package was used to send the requests to the input
mailbox. The MBX_Read routine was used to extract messages from the
mailbox.

[Input Data:]{.underline}

Ten database update requests, with valid data, and USDOT#'s not yet
existing in the database.

[Expected Outcome:]{.underline}

IMH will call SDM_update_safety_data with the correct packet header,
data header, and update data for each update request.

[Test Procedure Steps:]{.underline}

Check packet header, data header, and update data passed to
SDM_update_safety_data to verify that data structures are correctly
filled in for each update request.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} IMH-CU-007

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, data header, and update data were
    properly filled in and passed to SDM_update_safety_data for each of
    the ten requests.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} SDM-CU-007

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} SDM

[Integration Function:]{.underline}

1.  Send, accept and process five separate mailbox requests for carrier
    snapshot add operations when five requests are already in the queue
    when IMH process is started..

2.  Use a subscriber list containing at least three subscribers, one of
    which is invalid.

3.  Send results to OMH to forward to the subscribers.

[Requirement to be validated:]{.underline}

-   SDM_update_data must receive a packet header, data header, and
    update data filled in with accurate information so that it can
    update the database.

-   SDM must call SL_fulfill_subscription to forward a snapshot update
    to the subscribers.

-   SDM must perform the above steps ten times successively.

[Test Tools, Drivers, or Special Conditions:]{.underline}

Use SQLPlus to view the newly added records and verify that they were
written to the database properly.

[Input Data:]{.underline}

Ten database update requests, with valid data, and USDOT#'s not yet
existing in the database.

Subscription list file containing the mail address for three or more
subscribers, one of which is invalid.

[Expected Outcome:]{.underline}

SDM_update_safety_data will receive the correct packet header, data
header, and update data for each request.

SL_fulfill_subscription will call SDM_retrieve_safety_data to obtain the
updated snapshot and request OMH to forward it to the subscribers for
each request.

[Test Procedure Steps:]{.underline}

Check packet header, data header, and update data passed to
SDM_update_safety_data to verify that data structures are correctly
filled in for the update requests.

Verify that SL_fulfill_subscription and SDM_retrieve_safety_data perform
all processing necessary to enable OMH to forward a copy of each of the
ten updated snapshots to the subscribers.

[Analysis Procedures:]{.underline}

-   

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} SDM-CU-007

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   Data structures for packet header, data header, and update data were
    properly filled in and passed to SDM_update_safety_data.
    SDM_update_safety_data successfully added the ten records to the
    database.

-   SL_fulfill_subscription correctly read the subscription list, and
    called SDM_retrieve_safety_data to retrieve the updated snapshots
    and forward information to OMH.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Integration Test Plan**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} OMH-CU-007

[Version Control ID:]{.underline} APL V01-B02

[Affected CSCI:]{.underline} OMH

[Integration Function:]{.underline}

1.  Send, accept and process five separate mailbox requests for carrier
    snapshot add operations when five add request messages are already
    in the queue when IMH processing is started.

2.  Use a subscriber list containing at least three subscribers, one of
    which is invalid.

3.  Send a copy of the updated snapshots to the subscribers.

[Requirement to be validated:]{.underline}

-   OMH will forward mail messages containing copies of the newly added
    snapshots to the valid subscribers.

-   Having an invalid subscriber on the list will not cause a crash or
    processing problems.

[Test Tools, Drivers, or Special Conditions:]{.underline}

MBX_Send routine is used to forward the messages to each subscriber's
mailbox. EudoraLite mail package is used to read the messages and verify
that updated carrier snapshots was received by the subscribers.

[Input Data:]{.underline}

A valid packet header, request header, and send request will be the
input to OMH for each of ten requests.

[Expected Outcome:]{.underline}

OMH will query the database, obtain copies of the newly added records,
and send it to the subscribers.

[Test Procedure Steps:]{.underline}

Verify that OMH_query_database successfully retrieves the new records.

Verify that OMH_output_message_generator forwards the new snapshots to
the subscribers.

Read messages in each subscriber's mailbox. Verify that the correct
snapshots were sent.

Check output screen for error messages concerning invalid subscriber.

[Analysis Procedures:]{.underline}

-   

**Integration Test Report**

[Integration ID:]{.underline} Carrier Update

[ITP ID:]{.underline} OMH-CU-007

[Version Control ID:]{.underline} APL V01-B02 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
7/1//96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

Actual Results:

-   The ten new carrier snapshots were sent to each valid subscriber's
    mailbox.

-   An error message concerning "Unknown user" was printed on the output
    screen. The invalid subscriber caused no processing problems.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Appendix D - Unit Test (ADM)**

**Administrative Manager**

**Unit Test Plans and Test Reports**

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_create_org_account

[UTP ID:]{.underline} ACCT_CRE_ORG1

[Version Control ID:]{.underline} SAIC V01-B03-01

[Unit Function:]{.underline}

It creates an organizational account, and multiple user accounts if the
request is valid.

This function may insert an entry into ORG_ACCOUNT table, an entry into
BANK table, and entries into USER table.

[Requirement to be validated:]{.underline}

-   3.2.1.1

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \$/SAFER/SAIC SAFER/V01-B03-01 - SAIC Initial
effort/ADM/Unit tests/UT drivers (June, 97)/ADM_ACCT_Org_Create_dvr1.c

[Input Data:]{.underline}

Key input data:

Requester_user: John Smith with Create Org privilege

Org name = "Science Applications International Corporation"

Org Shortname = "SAIC"

Bank name = "First Virginia"

Bank branch = "McLean"

Two Users:

User1 = John Smith with Org Create Privilege

User2 = Joe M. Doe

[Expected Outcome:]{.underline}

An entry keyed "SAIC_x" is added to Org_Account table.

An entry keyed "First Virginia" + "McLean" is added to Bank table.

Two entries keyed "smithjx" and "doejmx" are added to User_Account
table.

Users "smithjx" and "smithjx_sub" are added to user database for the NT
domain

Users "doejmx" and "smithjx_sub" are added to user database for the NT
domain

The NT users shall belong to "SAFER Group" and have dial-in capabillity

[Test Procedure Steps:]{.underline}

-   Create separate director for testing

-   Get all account manager module from \$/SAFER/SAIC SAFER/V01-B03-01 -
    SAIC Initial effort/ADM in to this director

-   Create a new project in MS VC++ 5.0 compiler

-   Create the test driver that

1.  Populates information in the unit test plan into the
    ADM_ACCT_org_info_t

2.  Calls ADM_ACCT_create_org_account(..)

-   Build the executable

-   Run the executable

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_create_org_account

[UTP ID:]{.underline} ACCT_CRE_ORG1

[Version Control ID:]{.underline} SAIC V01-B03-01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} SSD [Test Date:]{.underline} August 29,
1997

[Purpose of Test:]{.underline}

Test on successful creation of organizational accounts and user
accounts.

[Actual Results:]{.underline}

Failed.

Organization is created but the user is not created. The debug mode
stopped after calling ACCT_ADM_add_NT_users() which is under
modification to support wider variety of user groups.

To-Do

Debug ACC_ADM_add_NT_users()

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_create_org_account

[UTP ID:]{.underline} ACCT_CRE_ORG1

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

It creates an organizational account, and multiple user accounts if the
request is valid.

This function may insert an entry into ORG_ACCOUNT table, an entry into
BANK table, and entries into USER table.

[Requirement to be validated:]{.underline}

-   3.2.1.1

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_Org_Create_dvr1.c

[Input Data:]{.underline}

Key input data:

Requester_user_id = "jsmith"

Org name = "Science Applications International Corporation"

Org Shortname = "SAIC"

Bank name = "First Virginia"

Bank branch = "McLean"

Two Users:

User1 = "jsmith" with super user privileges

User2 = "jdoe"

[Expected Outcome:]{.underline}

An entry keyed "SAIC_x" is added to Org_Account table.

An entry keyed "First Virginia" + "McLean" is added to Bank table.

Two entries keyed "jsmith" and "jdoe" are added to User_Account table.

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_create_org_account

[UTP ID:]{.underline} ACCT_CRE_ORG1

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

Test on successful creation of organizational accounts and user
accounts.

[Actual Results:]{.underline}

-   An organizational account keyed "SAIC_1" is inserted into
    Org_Account table.

-   A bank keyed "First Virginia" + "McLean" is inserted into Bank
    table.

-   Two users keyed "SAIC_1" + "jsmith" and "SAIC_1" + "jdoe" are
    inserted into User_Account table.

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_create_org_account

[UTP ID:]{.underline} ACCT_CRE_ORG2

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

It creates an organizational account, and multiple user accounts if the
request is valid.

This function may insert an entry into ORG_ACCOUNT table, an entry into
BANK table, and entries into USER table.

[Requirement to be validated:]{.underline}

-   3.2.1.1

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Special Conditions:

> An organization with name "Science Applications International
> Corporation" and no suborg name exists in the database.

Test Drivers:

\\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_Org_Create_dvr2.c

[Input Data:]{.underline}

Key input data:

1\. Requester_user_id = "jsmith"

Org name = "Science Applications International Corporation"

Org Shortname = "SAIC"

Two Users:

User1 = "jsmith" with super user privileges

User2 = "jdoe"

[Expected Outcome:]{.underline}

Appropriate error messages displayed (on the screen). No account will be
created. No further processing on the request.

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_create_org_account

[UTP ID:]{.underline} ACCT_CRE_ORG2

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

Test on unsuccessful creation of organizational accounts and user
accounts.

[Actual Results:]{.underline}

-   Error message "Org exists, please provide a different suborg name to
    create a new account." displayed on the screen.

-   No entries are added to any of the database tables.

-   Program terminated.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_create_org_account

[UTP ID:]{.underline} ACCT_CRE_ORG3

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

It creates an organizational account, and multiple user accounts if the
request is valid.

This function may insert an entry into ORG_ACCOUNT table, an entry into
BANK table, and entries into USER table.

[Requirement to be validated:]{.underline}

-   3.2.1.1

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Special Conditions:

> An organization with name "Science Applications International
> Corporation" and no suborg name exists in the database.

Test Drivers:

\\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_Org_Create_dvr3.c

[Input Data:]{.underline}

Key input data:

1\. Requester_user_id = "ssmith"

Org name = "Science Applications International Corporation"

Suborg name = "SAFER Program"

Org Shortname = "SAIC"

Two Users:

User1 = "jsmith" with super user privileges

User2 = "jdoe"

[Expected Outcome:]{.underline}

Appropriate error messages displayed. No account will be created. No
further processing on the request.

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_create_org_account

[UTP ID:]{.underline} ACCT_CRE_ORG3

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

Test on unsuccessful creation of organizational accounts and user
accounts.

[Actual Results:]{.underline}

-   Error message "Requester id is not in the user list to be created."
    displayed on the screen.

-   No changes to any of the database tables.

-   Program terminated.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_create_org_account

[UTP ID:]{.underline} ACCT_CRE_ORG4

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

It creates an organizational account, and multiple user accounts if the
request is valid.

This function may insert an entry into ORG_ACCOUNT table, an entry into
BANK table, and entries into USER table.

[Requirement to be validated:]{.underline}

-   3.2.1.1

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Special Conditions:

> An organization with name "Science Applications International
> Corporation" and no suborg name exists in the database.

Test Drivers:

\\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_Org_Create_dvr4.c

[Input Data:]{.underline}

Key input data:

1\. Requester_user_id = "jsmith"

Org name = "Science Applications International Corporation"

Suborg name = "SAFER Program"

Org Shortname = "SAIC"

Two Users:

User1 = "jsmith" without org-create privilege

User2 = "jdoe"

[Expected Outcome:]{.underline}

Appropriate error messages displayed. No account will be created. No
further processing on the request.

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_create_org_account

[UTP ID:]{.underline} ACCT_CRE_ORG4

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

Test on unsuccessful creation of organizational accounts and user
accounts.

[Actual Results:]{.underline}

-   Error message "The requester does not have the privilege to create
    an org account." displayed on the screen.

-   No change to any of the database tables.

-   Program terminated.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_create_org_account

[UTP ID:]{.underline} ACCT_CRE_ORG5

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

It creates an organizational account, and multiple user accounts if the
request is valid.

This function may insert an entry into ORG_ACCOUNT table, an entry into
BANK table, and entries into USER table.

[Requirement to be validated:]{.underline}

-   3.2.1.1

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Special Conditions:

> An organization with account_id "SAIC_1", name "Science Applications
> International Corporation" and suborg name "UNKNOWN" exists in the
> database.

Test Drivers:

\\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_Org_Create_dvr5.c

[Input Data:]{.underline}

Key input data:

1\. Requester_user_id = "jsmith"

Org name = "Science Applications International Corporation"

Suborg name = "SAFER Program"

Org Shortname = "SAIC"

> Bank name = "First Virginia"
>
> Bank branch = "McLean"

Three Users:

User1 = "jsmith" with super user privileges

User2 = "jsmith"

User3 = "jdoe"

[Expected Outcome:]{.underline}

An entry keyed "SAIC_2" added to Org_Account table.

No new entry added to Bank table since the bank already exists.

The first user is added to User_Account table.

Error message on the second user creation since the user exists.

The third user is added to User_Account table.

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_create_org_account

[UTP ID:]{.underline} ACCT_CRE_ORG5

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

It tests on successful generation of an organizational account id and
creations of an organizational account and user accounts. It also tests
on continuing creation of next user when error happens on a user.

[Actual Results:]{.underline}

-   Organizational account keyed "SAIC_2" created.

-   User account "jsmith" created.

-   Error creating user "jsmith". Error message "User id jsmith has been
    taken, failed to create an account for smith." displayed.

-   User account "jdoe" created.

-   No new bank created. The bank part of the org references an existing
    entry in BANK table.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_create_user_account

[UTP ID:]{.underline} ACCT_CRE_USER1

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

It creates one or more user accounts if the request is valid.

This function may insert entries into USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_User_Create_dvr1.c

Special Conditions:

Org account SAIC_1 exists with one user "jsmith" who has create_user
privilege.

[Input Data:]{.underline}

Key input data:

Requester_user_id = "jsmith"

Account_id = "SAIC_1"

Two Users:

User1 = "jjones"

User2 = "jdoe"

[Expected Outcome:]{.underline}

Two entries keyed "jjones" and "jdoe" of SAIC_1 are added to
User_Account table.

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_create_user_account

[UTP ID:]{.underline} ACCT_CRE_USER1

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

Test on successful creation of user accounts.

[Actual Results:]{.underline}

-   Two users keyed "SAIC_1" + "jjones" and "SAIC_1" + "jdoe" are
    inserted into User_Account table.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_create_user_account

[UTP ID:]{.underline} ACCT_CRE_USER2

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

It creates one or more user accounts if the request is valid.

This function may insert entries into USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_User_Create_dvr2.c

Special Conditions:

Org account SAIC_1 exists with three users "jjones", "jdoe", and
"jsmith".

User "jsmith" has create_user privilege.

[Input Data:]{.underline}

Key input data:

Requester_user_id = "jsmith"

Account_id = "SAIC_1"

User1 to create "jdoe"

User2 to create "mjohnson"

User3 with last name Jones to created (user id is not provided)

[Expected Outcome:]{.underline}

Error message displayed while creating user "jdoe"

Successful creation of user "mjohnson"

Error message displayed while creating user with last name Jones

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_create_user_account

[UTP ID:]{.underline} ACCT_CRE_USER2

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

Test on unsuccessful creation of a user account since the user to create
already exists.

Test on continuing creation of the next user even if error detected on
the current one.

[Actual Results:]{.underline}

-   Error creating user jdoe. Error message "User id jdoe has been
    taken, failed to create an account for Doe." displayed on the
    screen.

-   User mjohnson created.

-   Error creating an account for Jones. Error message "User_id is not
    provided, can't create user Jones." displayed on the screen.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_create_user_account

[UTP ID:]{.underline} ACCT_CRE_USER3

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

It creates one or more user accounts if the request is valid.

This function may insert entries into USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_User_Create_dvr3.c

Special Conditions:

Org account SAIC_1 exists with three users "jjones", "jdoe", and
"jsmith".

User "jsmith" has create_user privilege.

User "jdoe" does not have create_user privilege.

[Input Data:]{.underline}

Key input data:

Requester_user_id = "jdoe"

Account_id = "SAIC_1"

User to create "mjoe"

[Expected Outcome:]{.underline}

Error message displayed while creating user "mdoe"

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_create_user_account

[UTP ID:]{.underline} ACCT_CRE_USER2

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

Test on unsuccessful creation of a user account due to insufficient
privileges.

[Actual Results:]{.underline}

-   Error creating user mode. Error message "The requester does not have
    the privilege to create a user account." displayed on the screen..

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_create_user_account

[UTP ID:]{.underline} ACCT_CRE_USER3

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

It creates one or more user accounts if the request is valid.

This function may insert entries into USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_User_Create_dvr3.c

Special Conditions:

Org account SAIC_1 exists with three users "jjones", "jdoe", and
"jsmith".

User "jsmith" has create_user privilege.

User "jdoe" does not have create_user privilege.

[Input Data:]{.underline}

Key input data:

Requester_user_id = "jdoe"

Account_id = "SAIC_1"

User to create "mjoe"

[Expected Outcome:]{.underline}

Error message displayed while creating user "mdoe"

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_create_user_account

[UTP ID:]{.underline} ACCT_CRE_USER3

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

Test on unsuccessful creation of a user account due to insufficient
privileges.

[Actual Results:]{.underline}

-   Error creating user mode. Error message "The requester does not have
    the privilege to create a user account." displayed on the screen..

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_delete_org_account

[UTP ID:]{.underline} ACCT_DEL_ORG1

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function deletes an organizational account and all its user
accounts.

It may delete an entry in ORG_ACCOUNT table, an entry in BANK table and
entries in USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.1

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_Org_Delete_dvr1.c

Special Conditions:

-   Org "SAIC_1" exists with two users "jsmith" and 'jdoe"

-   User "jdoe" does NOT have delete-org privilege

[Input Data:]{.underline}

Requesting_user_id = "jdoe"

Org to delete is "SAIC_1"

[Expected Outcome:]{.underline}

Error message displayed on the screen.

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_delete_org_account

[UTP ID:]{.underline} ACCT_DEL_ORG1

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline} 8/7/96

[Purpose of Test:]{.underline}

Test on unsuccessful deletion of an org account due to insufficient
privileges.

[Actual Results:]{.underline}

-   Error message "The requester does not have the privilege to delete
    an org account." displayed on the screen.

-   Org account SAIC_1 still exists.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_delete_org_account

[UTP ID:]{.underline} ACCT_DEL_ORG2

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function deletes an organizational account and all its user
accounts.

It may delete an entry in ORG_ACCOUNT table, an entry in BANK table and
entries in USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.1

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_Org_Delete_dvr2.c

Special Conditions:

-   Org "SAIC_1" exists with two users "jsmith" and 'jdoe"

-   Org "SAIC_2" exists with one user "jjones".

[Input Data:]{.underline}

Requesting_user_id = "jsmith"

Org to delete is "SAIC_2"

[Expected Outcome:]{.underline}

Error message displayed on the screen.

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_delete_org_account

[UTP ID:]{.underline} ACCT_DEL_ORG2

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline} 8/7/96

[Purpose of Test:]{.underline}

Test on unsuccessful deletion of an org account since the requester is
not associated with the org.

[Actual Results:]{.underline}

-   Error message "Requester is not associated with the org." displayed
    on the screen.

-   Org account SAIC_2 still exists.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_delete_org_account

[UTP ID:]{.underline} ACCT_DEL_ORG3

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function deletes an organizational account and all its user
accounts.

It may delete an entry in ORG_ACCOUNT table, an entry in BANK table and
entries in USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.1

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_Org_Delete_dvr3.c

Special Conditions:

-   Org "SAIC_1" exists with two users "jsmith" and 'jdoe"

-   User "jsmith" has delete-org privilege

-   Org "SAIC_2" exists with 3 users "jsmith", "jdoe" and "jjones"

[Input Data:]{.underline}

Requesting_user_id = "jsmith"

Org to delete is "SAIC_1"

[Expected Outcome:]{.underline}

Org account SAIC_1 is deleted.

Users "jsmith" and "jdoe" associated with "SAIC_1" are deleted.

Users "jsmith" and "jdoe" associated with "SAIC_2" still exist.

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_delete_org_account

[UTP ID:]{.underline} ACCT_DEL_ORG3

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline} 8/7/96

[Purpose of Test:]{.underline}

Test on successful deletion of an org account and its user accounts.

[Actual Results:]{.underline}

-   Org account SAIC_1 does not exists anymore.

-   User accounts "jsmith", "jdoe" with account_id "SAIC_1" do not exist
    anymore.

-   User accounts "jsmith", "jdoe" with account_id "SAIC_2" still exist.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_delete_user_account

[UTP ID:]{.underline} ACCT_DEL_USER1

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function removes an user account associated with an org from the
database.

It deletes an entry in USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_User_Delete_dvr1.c

Special Conditions:

-   Org "SAIC_2" exists with three users "jsmith", "jjones" and 'jdoe"

-   User "jdoe" does NOT have delete-user privilege

[Input Data:]{.underline}

Requesting_user_id = "jdoe"

User to delete is "jjones"

[Expected Outcome:]{.underline}

Error message displayed on the screen.

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_delete_user_account

[UTP ID:]{.underline} ACCT_DEL_USER1

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline} 8/7/96

[Purpose of Test:]{.underline}

Test on unsuccessful deletion of an user account due to insufficient
privileges.

[Actual Results:]{.underline}

-   Error message "The requester does not have the privilege to delete a
    user account." displayed on the screen.

-   User account "jjones" associated with "SAIC_2" still exists.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_delete_user_account

[UTP ID:]{.underline} ACCT_DEL_USER2

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function removes an user account associated with an org from the
database.

It deletes an entry in USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_User_Delete_dvr2.c

Special Conditions:

-   Org "SAIC_2" exists with three users "jsmith", "jjones" and 'jdoe"

-   Org "SAIC_1" exists with one user "pjones"

[Input Data:]{.underline}

Requesting_user_id = "pjones"

User to delete = "jjones"

[Expected Outcome:]{.underline}

Error message displayed on the screen.

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_delete_user_account

[UTP ID:]{.underline} ACCT_DEL_USER2

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline} 8/7/96

[Purpose of Test:]{.underline}

Test on unsuccessful deletion of an user account since the requester is
not associated with the org the user is in.

[Actual Results:]{.underline}

-   Error message "Requester is not associated with the org." displayed
    on the screen.

-   User account "jjones" with org account SAIC_2 still exists.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_delete_user_account

[UTP ID:]{.underline} ACCT_DEL_USER3

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function removes an user account associated with an org from the
database.

It deletes an entry in USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_User_Delete_dvr3.c

Special Conditions:

-   Org "SAIC_2" exists with three users "jsmith", "jjones" and 'jdoe"

-   User "jsmith" has delete-user privilege

[Input Data:]{.underline}

Requesting_user_id = "jsmith"

Account_id = "SAIC_2"

Users to delete are "jjones", "mdoe", "jdoe" and "jsmith"

[Expected Outcome:]{.underline}

Successful deletion of user "jjones"

Error message diaplayed on the screen while deleting user "mdoe"

Successful deletion of user "jdoe"

Error message displayed on the screen while deleting user "jsmith"

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_delete_user_account

[UTP ID:]{.underline} ACCT_DEL_USER3

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline} 8/7/96

[Purpose of Test:]{.underline}

Test on successful deletion of two user accounts and unsuccessful
deletion of the last user of the org.

Test on detecting errors when deleting a user that is not associated
with the org.

Test on continuing deleting next user when error happens.

[Actual Results:]{.underline}

-   User "jjones" with SAIC_2 deleted

-   Error deleting user "mdoe". Error message "SDB error in deleting
    user."

-   User "jdoe" with SAIC_2 deleted

-   User "jsmith" with SAIC_2 was not deleted. Error message "The user
    is the last user. Cannot delete." displayed on the screen.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_delete_user_account

[UTP ID:]{.underline} ACCT_DEL_USER3A

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function removes an user account associated with an org from the
database.

It deletes an entry in USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_User_Delete_dvr3.c

Special Conditions:

-   Org "SAIC_2" exists with three users "jsmith", "jjones" and 'jdoe"

-   User "jsmith" has delete-user privilege

[Input Data:]{.underline}

Requesting_user_id = "jsmith"

Account_id = "SAIC_2"

Users to delete are "jjones", "mdoe", "jdoe" and "jsmith"

[Expected Outcome:]{.underline}

Successful deletion of user "jjones"

Error message diaplayed on the screen while deleting user "mdoe"

Successful deletion of user "jdoe"

Error message displayed on the screen while deleting user "jsmith"

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_delete_user_account

[UTP ID:]{.underline} ACCT_DEL_USER3A

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 2

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline}
8/12/96

[Purpose of Test:]{.underline}

Rerun previous test because of code changes. Currently, the requester
can not delete himself which automatically meets the requirement of not
to delete the last user.

[Actual Results:]{.underline}

-   User "jjones" with SAIC_2 deleted

-   Error deleting user "mdoe". Error message "SDB error in deleting
    user."

-   User "jdoe" with SAIC_2 deleted

-   User "jsmith" with SAIC_2 was not deleted. Error message "Can not
    delete self." displayed on the screen.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_update_org_account

[UTP ID:]{.underline} ACCT_UPD_ORG1

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function updates fields of an organizational accounts as well as
fields of the user accounts associated with the organizational account.

It may update an entry in ORG_ACCOUNT table, an entry in BANK table and
entries in USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.1

-   3.2.2.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_Org_Update_dvr1.c

Special Conditions:

-   Org "SAIC_1" exists with two users "jsmith" and 'jdoe"

-   User "jsmith" exists with update-org privilege

[Input Data:]{.underline}

Requesting_user_id = "jsmith"

change org phone# to 7035554444

change bank contact_name to "Mary Jones"

change user "jdoe" account status to inactive

[Expected Outcome:]{.underline}

Org SAIC_1's phone# changed to 7035554444

Org SAIC_1's bank contact person name changed to Mary Jones

User jdoe's account status changed to inactive

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_update_org_account

[UTP ID:]{.underline} ACCT_UPD_ORG1

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline} 8/5/96

[Purpose of Test:]{.underline}

Test on successful updating of a field in Org_Account table, a field in
Bank_Account table and a field in User_Account table with one org-update
request. Also tests on update of a field of character string type as
well as update of a field of character type.

[Actual Results:]{.underline}

-   Org SAIC_1's phone has been changed to 7035554444

-   Contact_name of the bank with which SAIC_1 is associated has been
    changed to Mary Jones

-   User jdoe's acct_status has been changed to 'I'

-   Successful update messages displayed on the screen

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_update_org_account

[UTP ID:]{.underline} ACCT_UPD_ORG2_1

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function updates fields of an organizational accounts as well as
fields of the user accounts associated with the organizational account.

It may update an entry in ORG_ACCOUNT table, an entry in BANK table and
entries in USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.1

-   3.2.2.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_Org_Update_dvr2.c

Special Conditions:

-   Org "SAIC_1" exists with two users "jsmith" and 'jdoe"

-   User "jsmith" exists with update-org privilege

-   SAIC_1 banks with "First Virginia", "McLean" branch and no other
    orgs are associated that branch.

[Input Data:]{.underline}

Requesting_user_id = "jsmith"

Change org SAIC_1's bank_branch to "FALLS CHURCH"

Change or g SAIC_1's bank_account_id to "1234567890"

[Expected Outcome:]{.underline}

Org SAIC_1 is associated with a new bank branch (a new entry in bank
table)

Bank "First Virginia" + "McLean" is removed from Bank table

Bank_account_id of SAIC_1 in Org_Account table is changed to
"1234567890"

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_update_org_account

[UTP ID:]{.underline} ACCT_UPD_ORG2_1

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline} 8/6/96

[Purpose of Test:]{.underline}

Test on changes of an org's bank to see if a new bank is created, and if
the un-referenced old bank is deleted.

[Actual Results:]{.underline}

-   a new bank entry whose bank_branch = "FALLS CHURCH" gets created

-   bank_account_id of SAIC_1 is updated to "1234567890"

-   old bank entry whose bank_branch = "McLean" is NOT removed. BUG!

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

[Unit ID:]{.underline} ADM_ACCT_update_org_account

[UTP ID:]{.underline} ACCT_UPD_ORG2_2

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function updates fields of an organizational accounts as well as
fields of the user accounts associated with the organizational account.

It may update an entry in ORG_ACCOUNT table, an entry in BANK table and
entries in USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.1

-   3.2.2.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_Org_Update_dvr2.c

Special Conditions:

-   Org "SAIC_1" exists with two users "jsmith" and 'jdoe"

-   User "jsmith" exists with update-org privilege

-   SAIC_1 banks with "First Virginia", "McLean" branch and no other
    orgs are associated that branch.

[Input Data:]{.underline}

Requesting_user_id = "jsmith"

Change org SAIC_1's bank_branch to "FALLS CHURCH"

Change or g SAIC_1's bank_account_id to "1234567890"

[Expected Outcome:]{.underline}

Org SAIC_1 is associated with a new bank branch (a new entry in bank
table)

Bank "First Virginia" + "McLean" is removed from Bank table

Bank_account_id of SAIC_1 in Org_Account table is changed to
"1234567890"

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_update_org_account

[UTP ID:]{.underline} ACCT_UPD_ORG2_2

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 2

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline} 8/6/96

[Purpose of Test:]{.underline}

Test on changes of an org's bank to see if a new bank is created, and if
the un-referenced old bank is deleted.

Bug was found at previous test and was fixed. Rerun the test.

[Actual Results:]{.underline}

-   a new bank entry whose bank_branch = "FALLS CHURCH" gets created

-   bank_account_id of SAIC_1 is updated to "1234567890"

old bank entry whose bank_branch = "McLean" is removed.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_update_org_account

[UTP ID:]{.underline} ACCT_UPD_ORG3

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function updates fields of an organizational accounts as well as
fields of the user accounts associated with the organizational account.

It may update an entry in ORG_ACCOUNT table, an entry in BANK table and
entries in USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_Org_Update_dvr3.c

Special Conditions:

-   Org "SAIC_1" exists with two users "jsmith" and 'jdoe"

-   SAIC_1's phone = "7035554444"

-   User "jdoe" does NOT have update-org privilege.

[Input Data:]{.underline}

Requesting_user_id = "jdoe"

change org phone# to 7034445555

[Expected Outcome:]{.underline}

No change is made. Error message displayed on the screen.

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_update_org_account

[UTP ID:]{.underline} ACCT_UPD_ORG3

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline} 8/6/96

[Purpose of Test:]{.underline}

Test on unsuccessful update on org field due to insufficient privileges.

[Actual Results:]{.underline}

-   Error message "The requester does not have the privilege to update
    an org account." displayed on the screen.

-   SAIC_1's phone remains "7035554444".

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_update_org_account

[UTP ID:]{.underline} ACCT_UPD_ORG3

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function updates fields of an organizational accounts as well as
fields of the user accounts associated with the organizational account.

It may update an entry in ORG_ACCOUNT table, an entry in BANK table and
entries in USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_Org_Update_dvr3.c

Special Conditions:

-   Org "SAIC_1" exists with two users "jsmith" and 'jdoe"

-   SAIC_1's phone = "7035554444"

-   User "jdoe" does NOT have update-org privilege.

[Input Data:]{.underline}

Requesting_user_id = "jdoe"

change org phone# to 7034445555

[Expected Outcome:]{.underline}

No change is made. Error message displayed on the screen.

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_update_org_account

[UTP ID:]{.underline} ACCT_UPD_ORG3

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline} 8/6/96

[Purpose of Test:]{.underline}

Test on unsuccessful update on org field due to insufficient privileges.

[Actual Results:]{.underline}

-   Error message "The requester does not have the privilege to update
    an org account." displayed on the screen.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_update_user_account

[UTP ID:]{.underline} ACCT_UPD_USER1

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function updates fields of user accounts. A user can update only a
subset field of its own account unless the user has update-user
privilege.

It may update entries in USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.2.1

-   3.2.3.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_User_Update_dvr1.c

Special Conditions:

-   Org "SAIC_2" exists with two users "jsmith" and 'jdoe"

-   User "jsmith" exists with update-user privilege

-   User "jdoe" does not have update-user privilege

[Input Data:]{.underline}

Requesting_user_id = "jdoe"

1\. Change his phone# to 7035554444

2\. Give himself create-org privileges

3\. Change user "jsmith" phone number to 7035554444

[Expected Outcome:]{.underline}

jdoe's phone# changed to 7035554444

Error changing create-org privileges, error message displayed

Error changing jsmith's phone#, error message displayed

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_update_user_account

[UTP ID:]{.underline} ACCT_UPD_USER1

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline} 8/7/96

[Purpose of Test:]{.underline}

Test on successful updating of a updatable field of the requester
himself.

Test on unsuccessful updating of a field that requires special
privileges.

Test on unsuccessful updating other user's info due to insufficient
privileges.

[Actual Results:]{.underline}

-   User jdoe's phone has been changed to 7035554444

-   Error message "User jdoe does not have the privilege to update the
    field." displayed on the screen when jdoe trying to change his
    create-org-priv.

-   Error message "Do not have privilege to update user jsmith."
    displayed on screen when user jdoe trying to update jsmith's phone
    number.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} ADM_ACCT_update_user_account

[UTP ID:]{.underline} ACCT_UPD_USER2

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function updates fields of user accounts. A user can update only a
subset field of its own account unless the user has update-user
privilege.

It may update entries in USER_ACCOUNT table.

[Requirement to be validated:]{.underline}

-   3.2.2.1

-   3.2.3.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: \\\\PSAFER2\\SAFER\\SAIC
SAFER\\PingSAFER\\V01-B03-01\\ADM\|ACCT\\Unit_Test\\Drivers\\ADM_ACCT_User_Update_dvr2.c

Special Conditions:

-   Org "SAIC_2" exists with two users "jsmith" and 'jdoe"

-   User "jsmith" exists with update-user privilege

[Input Data:]{.underline}

Requesting_user_id = "jsmith"

1\. Change his own phone# to 7035554444

2\. Change user "sdoe" phone number to 7035554444

3\. Give user jdoe create-org privileges

[Expected Outcome:]{.underline}

jsmith's phone# changed to 7035554444

Error changing user sdoe's phone number, error message displayed

jdoe has create-org privilege

[Test Procedure Steps:]{.underline}

-   

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} ADM_ACCT_update_user_account

[UTP ID:]{.underline} ACCT_UPD_USER2

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Ping Liang [Test Date:]{.underline} 8/7/96

[Purpose of Test:]{.underline}

Test on successful updating of a updatable field of the requester
himself.

Test on unsuccessful updating of non-exist user.

Test on successful updating other user's info with update-user
privileges.

[Actual Results:]{.underline}

-   User jsmith's phone has been changed to 7035554444

-   Error message "User sdoe does not exist, update failed." displayed
    on the screen when jsmith trying to update user sdoe

-   User jdoe now has create-org privilege

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Appendix E - Unit Test (SLP)**

**Subscription List Processor**

**Unit Test Plans and Test Reports**

**Unit Test Plan**

Date: 8/27/97

[Unit ID:]{.underline} slp_append_query

[UTP ID:]{.underline} SLP_APPEND_QUERY01

[Version Control ID:]{.underline} 142dev version 2

[Unit Function:]{.underline}

This function appends a query to an existing subscription. Before
appending, this function first verifies that the query is not already
part of the subscription. If it is a duplicate, no action is taken.

[Requirement to be validated:]{.underline}

-   ?

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the test function slp_create, and
using the microsoft developer studio to halt execution at the call to
slp_append_query, modifying the input parameters, and then stepping over
the function an examining the database table for changes. The table
"subscriber_parms" must NOT have a row containing the input data prior
to this test.

[Input Data:]{.underline}

new_subscription.query_parms\[0\].parm_number = SAFER_DOT_PARAM

new_subscription_query_parms\[0\].parm_value = 654123

new_subscription_query_parms\[1\].parm_value\[0\] = '\\0';

[Expected Outcome:]{.underline}

A new entry in the database table "subscriber_parms"

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp_append_query at the first call to
    slp_append_query.

-   Select "Test-\>Go" from MS Developer menu.

-   When trap occurs, modify input parameters to match input data above.

-   Use SqlPlus to examine database table "subscriber_parms" and make
    sure matching query **does not** exist.

-   Step over slp_append_query and examine database.

[Analysis Procedures:]{.underline}

-   If database table "subscriber_parms" has correct new entry, AND
    slp_append_query() returns SLP_OK, then function has executed
    successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_append_query

[UTP ID:]{.underline} SLP_APPEND_QUERY01

[Version Control ID:]{.underline} 142dev version 2: [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

To test successful execution of slp_append_query for the NEW query case.

[Actual Results:]{.underline}

function placed new query into subscriber_parms table

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/27/97

[Unit ID:]{.underline} slp_append_query

[UTP ID:]{.underline} SLP_APPEND_QUERY02

[Version Control ID:]{.underline} 142dev version 2

[Unit Function:]{.underline}

This function appends a query to an existing subscription. Before
appending, this function first verifies that the query is not already
part of the subscription. If it is a duplicate, no action is taken.

[Requirement to be validated:]{.underline}

-   ?

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the test function
test_slp_append_query, and using the microsoft developer studio to halt
execution at the call to slp_append_query, modifying the input
parameters, and then stepping over the function an examining the
database table for changes. The table "subscriber_parms" must NOT have a
row containing the input data.

[Input Data:]{.underline}

new_subscription.query_parms\[0\].parm_number = SAFER_DOT_PARAM

new_subscription_query_parms\[0\].parm_value = 654123

new_subscription_query_parms\[1\].parm_value\[0\] = '\\0';

[Expected Outcome:]{.underline}

No change to database table "subscriber_parms"

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp_append_query at the first call to
    slp_append_query.

-   Select "Test-\>Go" from MS Developer menu.

-   When trap occurs, modify input parameters to match input data above.

-   Use SqlPlus to examine database table "subscriber_parms" and make
    sure matching query **does** exist.

-   Step over slp_append_query and examine database.

[Analysis Procedures:]{.underline}

-   If database table "subscriber_parms" has not been affected, AND
    slp_append_query() returns SLP_OK then function has executed
    successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_append_query

[UTP ID:]{.underline} SLP_APPEND_QUERY02

[Version Control ID:]{.underline} 142dev version 2 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

To test successful execution of slp_append_query for the ALREADY EXISTS
query case.

[Actual Results:]{.underline}

function did not place new query into subscriber_parms table

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/27/97

[Unit ID:]{.underline} slp_append_query

[UTP ID:]{.underline} SLP_APPEND_QUERY03

[Version Control ID:]{.underline} 142dev version 2

[Unit Function:]{.underline}

This function appends a query to an existing subscription. Before
appending, this function first verifies that the query is not already
part of the subscription. If it is a duplicate, no action is taken.

[Requirement to be validated:]{.underline}

-   ?

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the test function
test_slp_append_query, and using the microsoft developer studio to halt
execution at the call to slp_append_query, modifying the input
parameters, and then stepping over the function an examining the
database table for changes.

[Input Data:]{.underline}

new_subscription.subscription_id = 0

[Expected Outcome:]{.underline}

No change to database table "subscriber_parms" , and SLP_ERROR will be
returned

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp_append_query at the first call to
    slp_append_query.

-   Select "Test-\>Go" from MS Developer menu.

-   When trap occurs, modify input parameters to match input data above.

-   Step over slp_append_query and examine database.

[Analysis Procedures:]{.underline}

If database table "subscriber_parms" has not changed AND
slp_append_query() returns SLP_ERROR then function has executed
successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_append_query

[UTP ID:]{.underline} SLP_APPEND_QUERY03

[Version Control ID:]{.underline} 142dev version 2 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

To test successful execution of slp_append_query for non-existent
subscription case.

[Actual Results:]{.underline}

function returned SLP_ERROR without making any database changes.

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/27/97

[Unit ID:]{.underline} base_to_the_power

[UTP ID:]{.underline} BASE_TO_THE_POWER01

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp

[Unit Function:]{.underline}

This function returns the value of x to the y.

[Requirement to be validated:]{.underline}

-   ?

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the function with a random set of
values including exception cases such as exponents of 0, 1, and \< 0.

[Input Data:]{.underline}

base = 2, power = 0

base = 3, power = 1

base = 4, power = 8

base = -4, power = 3

base = 5, power = -4

[Expected Outcome:]{.underline}

1

3

65536

-64

0

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp at the first call to base_to_the_power.

-   Select "Test-\>Go" from MS Developer menu.

-   When trap occurs, modify input parameters to match input data above.

-   Step over base_to_the_power and examine result.

[Analysis Procedures:]{.underline}

-   If results match the "expected outcome" above, then function
    executed successfully

**Unit Test Report**

[Unit ID:]{.underline} base_to_the_power

[UTP ID:]{.underline} BASE_TO_THE_POWER01

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp
[Test Seq Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

To test successful execution of base_to_the_power.

[Actual Results:]{.underline}

Function failed for the power \< 0 case

\_\_\_\_\_ PASS \_\_[X]{.underline}\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/20/97

[Unit ID:]{.underline} calculate_event_mask

[UTP ID:]{.underline} CALCULATE_EVENT_MASK01

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp

[Unit Function:]{.underline}

This function calculates a subscribers complete set of event mask words
given a list of events

[Requirement to be validated:]{.underline}

-   ?

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the test functions
slp_build_subscription_req and test_slp_create, and using the microsoft
developer studio to halt execution at the call to calculate_event_mask
and stepping through the function to verify correctness. The function
slp_build_subscription_req should first be modified to add appropriate
events to the request.

[Input Data:]{.underline}

sub_req.elements\[0\].event_name = SLP_EVENT_NULL; // 0

sub_req.elements\[0\].event_type = SLP_SIMPLE;

sub_req.elements\[1\].event_name = SLP_CS_EV_QUANTITY_POWER_UNITS; // 30

sub_req.elements\[1\].event_type = SLP_SIMPLE;

sub_req.elements\[2\].event_name = SLP_CS_EV_ISS_SCORE; // 241

sub_req.elements\[2\].event_type = SLP_SIMPLE;

sub_req.elements\[3\].event_name = SLP_CS_EV_MAIL_ZIP_PLUS; // 27

sub_req.elements\[3\].event_type = SLP_SIMPLE;

sub_req.elements\[4\].event_name = SLP_CS_EV_WORK_INDIAN; // 55

sub_req.elements\[4\].event_type = SLP_SIMPLE;

sub_req.elements\[5\].event_name = SLP_CS_EV_WORK_OTHER; // 56

sub_req.elements\[5\].event_type = SLP_SIMPLE;

sub_req.elements\[6\].event_name = SLP_CS_EV_HAZMATS_10; // 123

sub_req.elements\[6\].event_type = SLP_SIMPLE;

sub_req.elements\[7\].event_name =
SLP_CS_EV_VIOLATION_MEDICAL_CERTIFICATE; // 156

sub_req.elements\[7\].event_type = SLP_SIMPLE;

sub_req.elements\[8\].event_name = SLP_CS_EV_OOS_REPORT_NUMBER; // 224

sub_req.elements\[8\].event_type = SLP_SIMPLE;

sub_req.elements\[9\].event_name = SLP_CS_EV_OOS_DATETIME; // 225

sub_req.elements\[9\].event_type = SLP_SIMPLE;

[Expected Outcome:]{.underline}

The event mask words should be returned as follows:

mask mask

[Word \# Event values range Event values Bit flags HEX value Decimal
Value]{.underline}

0 1-28 0,27 1, 28 80000010 2147483664

1 29-56 30, 55 3,28 80000041 2147483713

2 57-84 56 1 00000012 18

3 85-112 none none 00000003 3

4 113-140 124 12 00008004 32772

5 141-168 157 17 00100005 1048581

6 169-196 none none 00000006 6

7 197-224 none none 00000007 7

8 225-252 225,242,226 1,2,18 00200038 2097208

9 253-280 none none 00000009 9

Example calculation:

Word #0:

Events 0 and 27 fall within the first mask word. The bit positions refer
to the bit position starting from the 5^th^ bit from the right in a 32
bit binary word. The right most four bits are used to represent the
index of the word number ( 0 for word 0 , 1 for word 1, etc. ).

So event 0 would be the first bit in the set of usable ( left most 28 )
bits. Word one with just event 0 would be : 0x00000010 ( event ) +
0x00000000 ( word index) = 0x00000010. When you also include event 28 it
is: 0x800000000 ( event 28 ) + 0x00000010 ( event 0 ) + 0x00000000 (
word index ) = 80000010. The decimal representation is 2147483664.

[Test Procedure Steps:]{.underline}

-   Set breakpoint in slp_create at the first call to
    calculate_event_mask.

-   Select "Test-\>Go" from MS Developer menu.

-   When trap occurs, step over calculate_event_mask

-   Verify that returned mask words match expected results.

[Analysis Procedures:]{.underline}

-   If returned mask word values match expected results then function
    has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} calculate_event_mask

[UTP ID:]{.underline} CALCULATE_EVENT_MASK01

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp
[Test Seq Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/20/97

[Purpose of Test:]{.underline}

To test successful execution of calculate_event_mask.

[Actual Results:]{.underline}

[Mask Word Decimal Value]{.underline}

0 2147483664

1 2147483713

2 18

3 3

4 32772

5 1048581

6 6

7 7

8 2097208

9 9

\_\_[X]{.underline}\_\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/27/97

[Unit ID:]{.underline} clear_mask

[UTP ID:]{.underline} CLEAR_MASK01

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp

[Unit Function:]{.underline}

This function sets all events in all mask words to TRUE

[Requirement to be validated:]{.underline}

-   ?

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling it with a pointer to a
SLP_event_mask_t struct and verifying that all event bits are set to
false and that the word number is represented by the 4 lowest order bits
in the struct pointed to after execution.

[Input Data:]{.underline}

event mask memory location

[Expected Outcome:]{.underline}

event mask

word# value

0 0

1 1

2 2

3 3

4 4

5 5

6 6

7 7

8 8

9 9

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp at the first call to fill_mask.

-   Select "Test-\>Go" from MS Developer menu.

-   When trap occurs, modify input parameters to match input data above.

-   Step over base_to_the_power and examine result.

[Analysis Procedures:]{.underline}

-   If results match the "expected outcome" above, then function
    executed successfully

**Unit Test Report**

[Unit ID:]{.underline} clear_mask

[UTP ID:]{.underline} CLEAR_MASK01

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp
[Test Seq Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

To test successful execution of clear_mask.

[Actual Results:]{.underline}

word# value

0 0

1 1

2 2

3 3

4 4

5 5

6 6

7 7

8 8

9 9

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/25/97

[Unit ID:]{.underline} slp_create

[UTP ID:]{.underline} SLP_CREATE01

[Version Control ID:]{.underline} 142dev version

[Unit Function:]{.underline}

This function is responsible for receiving subscription requests,
validating those requests, and modifying the database according to the
request. Possible actions are: Adding a new subscription to the
database, updating an existing subscription in the database, sending a
status report describing a subscription in the database, sending
baseline info to the user, and appending a query item to an existing
subscription in the database.

[Requirement to be validated:]{.underline}

-   3.1.4.1 - Create new subscription - No baseline info

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling test_slp_create, modifying the
input parameters, and using the microsoft developer studio to halt
execution at the call to slp_create, and then step through the function
to verify correctness.

[Input Data:]{.underline}

packet_header.type = SAF_TRANS_UPDATE

packet_header.process_id = 0;

packet_header.reply_address = "SAICCurt"

packet_header.sender_org = "SAIC"

packet_header.sender_account = "SAICCurt"

request_header.type = SAF_DATA_NULL

request_header.req_overnite_flag = 0

update_data .data.subscription_req.process_time_type = SLP_IMMEDIATELY

update_data .data.subscription_req.output_type = SLP_VIEW

update_data .data.subscription_req.query_number = SAFER_QUERY_DOT

update_data .data.subscription_req.user_seq = "TESTSEQ"

update_data .data.subscription_req.event_status_flag = FALSE;

update_data .data.subscription_req.baseline_data_flag = FALSE;

update_data.data.subscription_req.append_flag = FALSE;

update_data .data.subscription_req.query_parms\[0\].parm_number =
SAFER_DOT_PARAM;

update_data .data.subscription_req.query_parms\[0\].parm_value = 220

update_data .data.subscription_req.elements\[0\].event_type = SLP_SIMPLE

update_data .data.subscription_req.elements\[0\].event_name = 1

update_data .data.subscription_req.view_name = 1

update_data .data.type = SAF_DATA_NULL

[Expected Outcome:]{.underline}

slp_create will make the following calls - (#) = number of calls:
sdb_check_for_subscription(2),sdb_get_org_subscription_id(1),
insert_parm(1), calculate_event_mask(1), calculate_range_mask(1),
sdb_get_available_sub_id(1), sdb_insert_new_subscription(1),
sdb_add_user_to_subscription(1), sdb_insert_parms(1), sdb_commit(1), and
free_parms(1).

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp_create at first call to slp_create

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, step into slp_create

-   Step over all function calls until function hits a return statement

[Analysis Procedures:]{.underline}

-   If slp_create calls all functions listed in expected outcome, AND
    returns SLP_OK, then it has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_create

[UTP ID:]{.underline} SLP_CREATE01

[Version Control ID:]{.underline} 142dev version [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/25/97

[Purpose of Test:]{.underline}

To test successful execution of slp_create for the "create new
subscription" case ( no baseline info).

[Actual Results:]{.underline}

-   2 calls made to sdb_check_for_subscription

-   1 call made to sdb_get_org_subscription_id

-   1 call made to insert_parm

-   1 call made to calculate_event_mask

-   1 call made to calculate_range_mask

-   1 call made to sdb_get_available_sub_id

-   1 call made to sdb_insert_new_subscription

-   1 call made to sdb_add_user_to_subscription

-   1 call made to sdb_insert_parms

-   1 call made to sdb_commit

-   1 call made to free_parms

-   function returned SLP_OK

\_\_[X]{.underline}\_\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/25/97

[Unit ID:]{.underline} slp_create

[UTP ID:]{.underline} SLP_CREATE02

[Version Control ID:]{.underline} 142dev version

[Unit Function:]{.underline}

This function is responsible for receiving subscription requests,
validating those requests, and modifying the database according to the
request. Possible actions are: Adding a new subscription to the
database, updating an existing subscription in the database, sending a
status report describing a subscription in the database, and appending a
query item to an existing subscription in the database. In the case of
"create new subscription", slp_create will decide whether or not to send
baseline info to the user.

[Requirement to be validated:]{.underline}

-   3.1.4.1 - 3.1.4.1 - UPDATE existing subscription - No baseline info

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling test_slp_create, modifying the
input parameters, and using the microsoft developer studio to halt
execution at the call to slp_create, and then step through the function
to verify correctness.

[Input Data:]{.underline}

packet_header.type = SAF_TRANS_UPDATE

packet_header.process_id = 0;

packet_header.reply_address = "SAICCurt"

packet_header.sender_org = "SAIC"

packet_header.sender_account = "SAICCurt"

request_header.type = SAF_DATA_NULL

request_header.req_overnite_flag = 0

update_data .data.subscription_req.process_time_type = SLP_IMMEDIATELY

update_data .data.subscription_req.output_type = SLP_VIEW

update_data .data.subscription_req.query_number = SAFER_QUERY_DOT

update_data .data.subscription_req.user_seq = "TESTSEQ"

update_data .data.subscription_req.event_status_flag = FALSE

update_data .data.subscription_req.baseline_data_flag = FALSE

update_data .data.subscription_req.append_flag=FALSE

update_data .data.subscription_req.query_parms\[0\].parm_number =
SAFER_DOT_PARAM

update_data .data.subscription_req.query_parms\[0\].parm_value = 220

update_data .data.subscription_req.elements\[0\].event_type = SLP_SIMPLE

update_data .data.subscription_req.elements\[0\].event_name = 1

update_data .data.subscription_req.view_name = 1

update_data .data.type = SAF_DATA_NULL

[Expected Outcome:]{.underline}

slp_create will make the following calls - (#) = number of calls:
sdb_check_for_subscription(1), insert_parm(1), calculate_event_mask(1),
calculate_range_mask(1), sdb_delete_parms(1),

sdb_update_subscription(1), sdb_insert_parms(1), sdb_commit(1), and
free_parms(1).

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp_create at first call to slp_create

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, step into slp_create

-   Step over all function calls until function hits a return statement

[Analysis Procedures:]{.underline}

-   If slp_create calls all functions listed in expected outcome, AND
    returns SLP_OK, then it has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_create

[UTP ID:]{.underline} SLP_CREATE02

[Version Control ID:]{.underline} 142dev version [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/25/97

[Purpose of Test:]{.underline}

To test successful execution of slp_create for the "update existing
subscription" case ( no baseline info).

[Actual Results:]{.underline}

-   1 call made to sdb_check_for_subscription

-   1 call made to insert_parm

-   1 call made to calculate_event_mask

-   1 call made to calculate_range_mask

-   1 call made to sdb_delete_parms

-   1 call made to sdb_update_subscription

-   1 call made to sdb_insert_parms

-   1 call made to sdb_commit

-   1 call made to free_parms

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/25/97

[Unit ID:]{.underline} slp_create

[UTP ID:]{.underline} SLP_CREATE03

[Version Control ID:]{.underline} 142dev version

[Unit Function:]{.underline}

This function is responsible for receiving subscription requests,
validating those requests, and modifying the database according to the
request. Possible actions are: Adding a new subscription to the
database, updating an existing subscription in the database, sending a
status report describing a subscription in the database, and appending a
query item to an existing subscription in the database. In the case of
"create new subscription", slp_create will decide whether or not to send
baseline info to the user.

[Requirement to be validated:]{.underline}

-   3.1.4.1 - Send status report

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling test_slp_create, modifying the
input parameters, and using the microsoft developer studio to halt
execution at the call to slp_create, and then step through the function
to verify correctness.

[Input Data:]{.underline}

update_data .data.packet_header.type = SAF_TRANS_UPDATE

update_data .data.packet_header.process_id = 0;

update_data .data.packet_header.reply_address = "SAICCurt"

update_data .data.packet_header.sender_org = "SAIC"

update_data .data.packet_header.sender_account = "SAICCurt"

update_data .data.request_header.type = SAF_DATA_NULL

update_data .data.request_header.req_overnite_flag = 0

update_data .data.subscription_req.process_time_type = SLP_IMMEDIATELY

update_data .data.subscription_req.output_type = SLP_VIEW

update_data .data.subscription_req.query_number = SAFER_QUERY_DOT

update_data .data.subscription_req.user_seq = "TESTSEQ"

**update_data .data.subscription_req.event_status_flag = TRUE**;

update_data .data.subscription_req.baseline_data_flag = FALSE;

update_data .data.subscription_req.query_parms\[0\].parm_number =
SAFER_DOT_PARAM;

update_data .data.subscription_req.query_parms\[0\].parm_value = 220

update_data .data.subscription_req.elements\[0\].event_type = SLP_SIMPLE

update_data .data.subscription_req.elements\[0\].event_name = 1

update_data .data.subscription_req.view_name = 1

update_data .data.type = SAF_DATA_NULL

[Expected Outcome:]{.underline}

slp_create will make the following calls - (#) = number of calls:
sdb_check_for_subscription(1), slp_status(1)

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp_create at first call to slp_create

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, step into slp_create

-   Step over all function calls until function hits a return statement

[Analysis Procedures:]{.underline}

-   If slp_create calls all functions listed in expected outcome, AND
    returns SLP_OK, then it has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_create

[UTP ID:]{.underline} SLP_CREATE03

[Version Control ID:]{.underline} 142dev version [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/25/97

[Purpose of Test:]{.underline}

To test successful execution of slp_create for the "Send status report"
case

[Actual Results:]{.underline}

-   1 call made to sdb_check_for_subscription

-   1 call made to slp_status

-   Returned SLP_OK

\_\_[X]{.underline}\_\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/25/97

[Unit ID:]{.underline} slp_create

[UTP ID:]{.underline} SLP_CREATE04

[Version Control ID:]{.underline} 142dev version

[Unit Function:]{.underline}

This function is responsible for receiving subscription requests,
validating those requests, and modifying the database according to the
request. Possible actions are: Adding a new subscription to the
database, updating an existing subscription in the database, sending a
status report describing a subscription in the database, and appending a
query item to an existing subscription in the database. In the case of
"create new subscription", slp_create will decide whether or not to send
baseline info to the user.

[Requirement to be validated:]{.underline}

-   3.1.4.1 - Send baseline info

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling test_slp_create, modifying the
input parameters, and using the microsoft developer studio to halt
execution at the call to slp_create, and then step through the function
to verify correctness.

[Input Data:]{.underline}

update_data .data.packet_header.type = SAF_TRANS_UPDATE

update_data .data.packet_header.process_id = 0;

update_data .data.packet_header.reply_address = "SAICCurt"

update_data .data.packet_header.sender_org = "SAIC"

update_data .data.packet_header.sender_account = "SAICCurt"

update_data .data.request_header.type = SAF_DATA_NULL

update_data .data.request_header.req_overnite_flag = 0

update_data .data.subscription_req.process_time_type = SLP_IMMEDIATELY

update_data .data.subscription_req.output_type = SLP_VIEW

update_data .data.subscription_req.query_number = SAFER_QUERY_DOT

update_data .data.subscription_req.user_seq = "TESTSEQ"

update_data .data.subscription_req.event_status_flag = FALSE

**update_data .data.subscription_req.baseline_data_flag = TRUE**

update_data .data.subscription_req.query_parms\[0\].parm_number =
SAFER_DOT_PARAM;

update_data .data.subscription_req.query_parms\[0\].parm_value = 220

update_data .data.subscription_req.elements\[0\].event_type = SLP_SIMPLE

update_data .data.subscription_req.elements\[0\].event_name = 1

update_data .data.subscription_req.view_name = 1

update_data .data.type = SAF_DATA_NULL

[Expected Outcome:]{.underline}

slp_create will make the following calls - (#) = number of calls:
sdb_check_for_subscription(1), insert_parm(1), calculate_event_mask(1),
calculate_range_mask(1), sdb_delete_parms(1),

sdb_update_subscription(1), sdb_insert_parms(1), sdb_commit(1),
slp_formreq(1) and free_parms(1).

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp_create at first call to slp_create

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, step into slp_create

-   Step over all function calls until funtion hits a return statement

[Analysis Procedures:]{.underline}

-   If slp_create calls all functions listed in expected outcome, AND
    returns SLP_OK, then it has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_create

[UTP ID:]{.underline} SLP_CREATE04

[Version Control ID:]{.underline} 142dev version [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/25/97

[Purpose of Test:]{.underline}

To test successful execution of slp_create for the "send baseline info"
case.

[Actual Results:]{.underline}

-   1 call made to sdb_check_for_subscription

-   1 call made to insert_parm

-   1 call made to calculate_event_mask

-   1 call made to calculate_range_mask

-   1 call made to sdb_delete_parms

-   1 call made to sdb_update_subscription

-   1 call made to sdb_insert_parms

-   1 call made to sdb_commit

-   1 call made to slp_formreq

-   1 call made to free_parms

-   Returned SLP_OK

\_\_\_X\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 6/10/97

[Unit ID:]{.underline} slp_create

[UTP ID:]{.underline} SLP_CREATE05

[Version Control ID:]{.underline} 142dev version

[Unit Function:]{.underline}

This function is responsible for receiving subscription requests,
validating those requests, and modifying the database according to the
request. Possible actions are: Adding a new subscription to the
database, updating an existing subscription in the database, sending a
status report describing a subscription in the database, and appending a
query item to an existing subscription in the database. In the case of
"create new subscription", slp_create will decide whether or not to send
baseline info to the user.

[Requirement to be validated:]{.underline}

-   3.1.4.1 - Append query to existing subscription

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling test_slp_create, modifying the
input parameters, and using the microsoft developer studio to halt
execution at the call to slp_create, and then step through the function
to verify correctness.

[Input Data:]{.underline}

update_data .data.packet_header.type = SAF_TRANS_UPDATE

update_data .data.packet_header.process_id = 0;

update_data .data.packet_header.reply_address = "SAICCurt"

update_data .data.packet_header.sender_org = "SAIC"

update_data .data.packet_header.sender_account = "SAICCurt"

update_data .data.request_header.type = SAF_DATA_NULL

update_data .data.request_header.req_overnite_flag = 0

update_data .data.subscription_req.process_time_type = SLP_IMMEDIATELY

update_data .data.subscription_req.output_type = SLP_VIEW

update_data .data.subscription_req.query_number = SAFER_QUERY_DOT

update_data .data.subscription_req.user_seq = "TESTSEQ"

update_data .data.subscription_req.event_status_flag = FALSE

update_data .data.subscription_req.baseline_data_flag = FALSE;

**update_data.data.subscription_req.append_flag = TRUE**

update_data .data.subscription_req.query_parms\[0\].parm_number =
SAFER_DOT_PARAM;

**update_data .data.subscription_req.query_parms\[0\].parm_value =
654123**

update_data .data.subscription_req.elements\[0\].event_type = SLP_SIMPLE

update_data .data.subscription_req.elements\[0\].event_name = 1

update_data .data.subscription_req.view_name = 1

update_data .data.type = SAF_DATA_NULL

[Expected Outcome:]{.underline}

slp_create will make the following calls - (#) = number of calls:
sdb_check_for_subscription(1), insert_parm(1), slp_append_query(1)

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp_create at first call to slp_create

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, step into slp_create

-   Step over all function calls until funtion hits a return statement

[Analysis Procedures:]{.underline}

If slp_create calls all functions listed in expected outcome, AND
returns SLP_OK, then it has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_create

[UTP ID:]{.underline} SLP_CREATE05

[Version Control ID:]{.underline} 142dev version [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/25/97

[Purpose of Test:]{.underline}

To test successful execution of slp_create for the "append query to
existing subscription" case.

[Actual Results:]{.underline}

-   1 call made to sdb_check_for_subscription

-   1 call made to insert_parm

-   1 call made to slp_append_query

-   Continued through function and performed an update - Should have
    returned

\_\_\_\_\_ PASS \_\_[X]{.underline}\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/27/97

[Unit ID:]{.underline} fill_mask

[UTP ID:]{.underline} FILL_MASK01

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp

[Unit Function:]{.underline}

This function sets all events in all mask words to TRUE

[Requirement to be validated:]{.underline}

-   ?

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the function with a pointer to a
SLP_event_mask_t struct and verifying that all event bits are set to
true in the struct pointed to after execution.

[Input Data:]{.underline}

event mask

word \# value

0 0

1 1

2 2

3 3

4 4

5 5

6 6

7 7

8 8

9 9

[Expected Outcome:]{.underline}

event mask

word# value

0 4294967280

1 4294967281

2 4294967282

3 4294967283

4 4294967284

5 4294967285

6 4294967286

7 4294967287

8 4294967288

9 4294967289

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp at the first call to fill_mask.

-   Select "Test-\>Go" from MS Developer menu.

-   When trap occurs, modify input parameters to match input data above.

-   Step over base_to_the_power and examine result.

[Analysis Procedures:]{.underline}

-   If results match the "expected outcome" above, then function
    executed successfully

**Unit Test Report**

[Unit ID:]{.underline} fill_mask

[UTP ID:]{.underline} FILL_MASK01

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp
[Test Seq Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

To test successful execution of fill_mask.

[Actual Results:]{.underline}

word# value

0 4294967280

1 4294967281

2 4294967282

3 4294967283

4 4294967284

5 4294967285

6 4294967286

7 4294967287

8 4294967288

9 4294967289

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} sdb_get_available_sub_id

[UTP ID:]{.underline} SDB_GET_AVAILABLE_SUB_ID01

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function reads through the subscription table in the database and
returns the highest existing sub_id + 1

[Requirement to be validated:]{.underline}

-   3.1.4.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

none

[Expected Outcome:]{.underline}

The next available subscription_id

[Test Procedure Steps:]{.underline}

-   Query the database for the highest sub_id ( select subscription_id
    from subscription)

-   Call function and check answer against a manual sql query

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} sdb_get_available_sub_id

[UTP ID:]{.underline} SDB_GET_AVAILABLE_SUB_ID01

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/6/96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

[Actual Results:]{.underline}

-   Manual query showed 6 to be the highest sub_id

-   function returned 7 (ok)

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/27/97

[Unit ID:]{.underline} get_local_time

[UTP ID:]{.underline} GET_LOCAL_TIME01

[Version Control ID:]{.underline} 142dev version 2: slp_date_utils.cpp

[Unit Function:]{.underline}

This function reads the system time and date and returns it in the form
of an integer of the format YYYYMMDDHH

[Requirement to be validated:]{.underline}

-   ?

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the test function get_local_time,
and using the microsoft developer studio to step over the function and
examining the return value.

[Input Data:]{.underline}

none

[Expected Outcome:]{.underline}

the system time and date should be returned as an integer in the form
YYYYMMDDHH

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp at the first call to get_local_time.

-   Select "Test-\>Go" from MS Developer menu.

-   Step over get_local_time and examine return value.

[Analysis Procedures:]{.underline}

-   If return value matches the system time and date and is an integer
    in the form YYYYMMDDHH then the function has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} get_local_time

[UTP ID:]{.underline} GET_LOCAL_TIME01

[Version Control ID:]{.underline} 142dev version 2: slp_date_utils.cpp
[Test Seq Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

To test successful execution of get_local_time.

[Actual Results:]{.underline}

function returned the correct system time and date as an integer in the
format YYYYMMDDHH

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} sdb_get_subscription

[UTP ID:]{.underline} SDB_GET_SUBSCRIPTION

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function selects a subscription record from the database given an
integer value. It then puts that subscription record into a C data
structure and returns that structure.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

An integer value

[Expected Outcome:]{.underline}

A C data structure for a subscription with id =input found in the
database

[Test Procedure Steps:]{.underline}

-   Call function with existing subscription id

-   Call function with negative subscription id

-   Call function with 0 subscription id

-   Call function with non-existent positive subscription id

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} sdb_get_subscription

[UTP ID:]{.underline} SDB_GET_SUBSCRIPTION

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/5/96

[Purpose of Test:]{.underline}

The verify that the function executes as expected given valid and
invalid input.

[Actual Results:]{.underline}

-   Returned correct subscription

-   Returned subscription with id = 0 (correct action)

-   Returned subscription with id = 0 (correct action)

-   Returned subscription with id = 0 (correct action)

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} sdb_get_sub_id_list

[UTP ID:]{.underline} SDB_GET_SUB_ID_LIST01

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function reads all subscription ids found in the subscription table
and returns a linked list of those ids.

[Requirement to be validated:]{.underline}

-   3.1.4.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

none

[Expected Outcome:]{.underline}

Correct list of subscription ids

[Test Procedure Steps:]{.underline}

-   Use sqlplus to select list of subscription ids (select
    subscription_id from subscription)

-   Compare sql list to the list created and returned by
    sdb_get_sub_id_list

[Analysis Procedures:]{.underline}

**Unit Test Report**

[Unit ID:]{.underline} sdb_get_sub_id_list

[UTP ID:]{.underline} SDB_GET_SUB_ID_LIST01

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton T[est Date:]{.underline}
8/5/96

[Purpose of Test:]{.underline}

To verify that the list of ids returned matches the list produced by a
sql select command

[Actual Results:]{.underline}

-   function returns the correct list

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} sdb_insert_new_subscription

[UTP ID:]{.underline} SDB_INSERT_NEW_SUBSCRIPTION01

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function adds a new subscription to the subscription database table
and returns SLP_OK upon success.

[Requirement to be validated:]{.underline}

-   3.1.4.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

a new subscription ( C data structure )

[Expected Outcome:]{.underline}

an enumerated value indicating success or failure

[Test Procedure Steps:]{.underline}

-   Call function with a subscription

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} sdb_insert_new_subscription

[UTP ID:]{.underline} SDB_INSERT_NEW_SUBSCRIPTION01

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/6/96

[Purpose of Test:]{.underline}

To verify that the function executes as planned

[Actual Results:]{.underline}

The function inserted the subscription as planned.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/28/97

[Unit ID:]{.underline} insert_parm

[UTP ID:]{.underline} INSERT_PARM01

[Version Control ID:]{.underline} 142dev version 2:
slp_linked_list_utils.cpp

[Unit Function:]{.underline}

This function creates and adds nodes to a linked list of
SLP_parm_no_value_pair_t t

[Requirement to be validated:]{.underline}

-   ? - CASE: NULL list pointer to begin with

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the function with a pointer to a
SLP_linked_query_parms_list_t struct, and a SLP_parm_no_value_pair_t
struct and verifying that a list is created or added to correctly.

[Input Data:]{.underline}

query_parm.parm_number = SAFER_DOT_PARAM

query_parm.parm_value = "654123"

parms_list_ptr = NULL;

[Expected Outcome:]{.underline}

\*parms_list_ptr =

parms_list = query_parm.parm_number = SAFER_DOT_PARAM

query_parm.parm_value = "654123"

next = NULL

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp at the first call to insert_parm

-   Select "Test-\>Go" from MS Developer menu.

-   When trap occurs, modify input parameters to match input data above.

-   Step over insert_parm and examine result.

[Analysis Procedures:]{.underline}

-   If results match the "expected outcome" above, then function
    executed successfully

**Unit Test Report**

[Unit ID:]{.underline} insert_parm

[UTP ID:]{.underline} INSERT_PARM01

[Version Control ID:]{.underline} 142dev version 2:
slp_linked_list_utils.cpp [Test Seq Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/28/97

[Purpose of Test:]{.underline}

To test successful execution of insert_parm.

[Actual Results:]{.underline}

parms_list_ptr = parm_number : SAFER_DOT_PARAM

parm_value: "654321"

next 0

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/28/97

[Unit ID:]{.underline} insert_parm

[UTP ID:]{.underline} INSERT_PARM02

[Version Control ID:]{.underline} 142dev version 2:
slp_linked_list_utils.cpp

[Unit Function:]{.underline}

This function creates and adds nodes to a linked list of
SLP_parm_no_value_pair_t

[Requirement to be validated:]{.underline}

-   ? - CASE: existing list pointer to begin with

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the function with a pointer to a
SLP_linked_query_parms_list_t struct, and a SLP_parm_no_value_pair_t
struct and verifying that a list is created or added to correctly.

[Input Data:]{.underline}

First call:

parms_list_ptr = NULL;

> query_parm.parm_number = SAFER_DOT_PARAM
>
> query_parm.parm_value = "654123"

Second call:

parms_list_ptr = parm.parm_number: SAFER_DOT_PARAM

parm.parm_value: "654321"

next: NULL

query_parm.parm_number = SAFER_STATE_PARAM

query_parm.parm_value = "12345"

[Expected Outcome:]{.underline}

\*parms_list_ptr =

parms_list = parm.parm_number = SAFER_DOT_PARAM

parm.parm_value = "654123"

next = \<some value\>

parm.parm_number: SAFER_STATE_PARAM

parm.parm_value: "12345"

next: NULL

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp at the first call to insert_parm

-   Select "Test-\>Go" from MS Developer menu.

-   When trap occurs, modify input parameters to match input data above.

-   Step over insert_parm

-   When trap occurs, modify input parameters to match input data above.

-   Step over insert_parm and examine result.

[Analysis Procedures:]{.underline}

-   If results match the "expected outcome" above, then function
    executed successfully

**Unit Test Report**

[Unit ID:]{.underline} insert_parm

[UTP ID:]{.underline} INSERT_PARM02

[Version Control ID:]{.underline} 142dev version 2:
slp_linked_list_utils.cpp [Test Seq Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/28/97

[Purpose of Test:]{.underline}

To test successful execution of insert_parm.

[Actual Results:]{.underline}

parms_list_ptr = parm.parm_number : SAFER_DOT_PARAM

parm.parm_value: "654321"

next: 0x010f0ad0

parm.parm_number SAFER_STATE_PARM

parm.parm_value "12345"

next: 0

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/28/97

[Unit ID:]{.underline} insert_pending_entry

[UTP ID:]{.underline} INSERT_PENDING_ENTRY01

[Version Control ID:]{.underline} 142dev version 2:
slp_linked_list_utils.cpp

[Unit Function:]{.underline}

This function creates and adds nodes to a linked list of
SLP_pending_entry_t

[Requirement to be validated:]{.underline}

-   ? - CASE: NULL list pointer to begin with

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the function with a pointer to a
SLP_linked_pending_entry_list_t struct, and a subscription_id,
SLP_date_t, SLP_carrier_id and verifying that a list is created or added
to correctly.

[Input Data:]{.underline}

pending_entry.subscription_id = 1

pending_entry.date = 1997082817

pending_entry.carrier_id = 654321

pending_entry_list_ptr = NULL;

[Expected Outcome:]{.underline}

pending_entry_list_ptr =

subscription_id: 1

> date: 1997082817
>
> carrier_id: 654321
>
> next: NULL

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp at the first call to insert_pending_entry

-   Select "Test-\>Go" from MS Developer menu.

-   When trap occurs, modify input parameters to match input data above.

-   Step over insert_pending_entry and examine result.

[Analysis Procedures:]{.underline}

-   If results match the "expected outcome" above, then function
    executed successfully

**Unit Test Report**

[Unit ID:]{.underline} insert_pending_entry

[UTP ID:]{.underline} INSERT_PENDING_ENTRY01

[Version Control ID:]{.underline} 142dev version 2:
slp_linked_list_utils.cpp [Test Seq Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/28/97

[Purpose of Test:]{.underline}

To test successful execution of insert_pending_entry.

[Actual Results:]{.underline}

pending_entry_list_ptr =

subscription_id: 1

> date: 1997082817
>
> carrier_id: 654321
>
> next: NULL

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/28/97

[Unit ID:]{.underline} insert_pending_entry

[UTP ID:]{.underline} INSERT_PENDING_ENTRY02

[Version Control ID:]{.underline} 142dev version 2:
slp_linked_list_utils.cpp

[Unit Function:]{.underline}

This function creates and adds nodes to a linked list of
insert_pending_entry

[Requirement to be validated:]{.underline}

-   ? - CASE: existing list pointer to begin with

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the function with a pointer to a
SLP_linked_pending_entry_list_t struct, and a subscription_id,
SLP_date_t, SLP_carrier_id and verifying that a list is created or added
to correctly.

[Input Data:]{.underline}

first call:

pending_entry_list_ptr = NULL;

> pending_entry.subscription_id = 1
>
> pending_entry.date = 1997082817
>
> pending_entry.carrier_id = 654321

second call:

> pending_entry.subscription_id = 6
>
> pending_entry.date = 1995082801
>
> pending_entry.carrier_id = 12345

[Expected Outcome:]{.underline}

pending_entry_list_ptr =

subscription_id : 1

> date: 1997082817
>
> carrier_id: 654321
>
> next: some value
>
> subscription_id: 6
>
> date: 1995082801
>
> carrier_id: 12345
>
> next: NULL

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp at the first call to insert_pending_entry

-   Select "Test-\>Go" from MS Developer menu.

-   When trap occurs, modify input parameters to match input data above.

-   Step over insert_pending_entry

-   When trap occurs, modify input parameters to match input data above.

-   Step over insert_pending_entry and examine result.

[Analysis Procedures:]{.underline}

-   If results match the "expected outcome" above, then function
    executed successfully

**Unit Test Report**

[Unit ID:]{.underline} insert_pending_entry

[UTP ID:]{.underline} INSERT_PENDING_ENTRY02

[Version Control ID:]{.underline} 142dev version 2:
slp_linked_list_utils.cpp [Test Seq Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/28/97

[Purpose of Test:]{.underline}

To test successful execution of insert_pending_entry.

[Actual Results:]{.underline}

pending_entry_list_ptr =

subscription_id: 1

> date: 1997082817
>
> carrier_id: 654321
>
> next: 0x010f0ac0
>
> subscription_id: 6
>
> date: 1995082801
>
> carrier_id: 12345
>
> next: 0

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} slp_create

[UTP ID:]{.underline} SLP_CREATE01

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function is responsible for receiving subscription requests,
validating those requests, adding the subscription to the database and
sending baseline information if necessary.

[Requirement to be validated:]{.underline}

-   3.1.4.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

packet header

request header

update header

[Expected Outcome:]{.underline}

a BOOLEAN value reflecting the status of all operations performed, and
functions called.

[Test Procedure Steps:]{.underline}

-   Test event_status ON branch

-   Test event_staus OFF branch

-   Call with valid view name in request (branch #3)

-   Call with invalid view name in request

-   Test with returned subscription_id = 0

-   Test with returned subscription_id != 0

-   Test with baseline_data_flag ON

-   Test with baseline_data_flag OFF

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} slp_create

[UTP ID:]{.underline} SLP_CREATE01

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/5/96

[Purpose of Test:]{.underline}

To test all branches and possible conditions and verify that function
executes as planned.

[Actual Results:]{.underline}

-   Event status flag OFF branch is ok

-   Event status flag ON branch is ok.

-   Invalid view name branch is ok

-   Valid view name branch is ok

-   subscription_id =0 branch is ok

-   subscription_id != 0 branch is ok.

-   baseline_data_flaog ON is ok

-   baseline_data_flag OFF branch is ok

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} sdb_slp_get_view

[UTP ID:]{.underline} SDB_SLP_GET_VIEW01

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function retrieves a view record from the database and returns a
data structure containing that view information.

[Requirement to be validated:]{.underline}

-   3.1.4.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

a view name

[Expected Outcome:]{.underline}

A structure containing view data from the database

[Test Procedure Steps:]{.underline}

-   Call with existing view name ( existing = in the db )

-   Call with a non-existent view name

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} sdb_slp_get_view

[UTP ID:]{.underline} SDB_SLP_GET_VIEW01

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/6/96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

[Actual Results:]{.underline}

-   Valid view name works ok

-   Invalid view name returns null view (ok)

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/27/97

[Unit ID:]{.underline} slp_listmov

[UTP ID:]{.underline} SLP_LISTMOV01

[Version Control ID:]{.underline} 142dev version 2

[Unit Function:]{.underline}

This function receives an integer and calls a DB function to retrieve
the subscription identified by the integer input. The subscription is
returned.

[Requirement to be validated:]{.underline}

-   Test for return of existing subscription

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling slp_listmov, modifying the input
parameters, and using the microsoft developer studio to halt execution
at the call to slp_listmov, and then step through the function to verify
correctness. A subscription with the ID = input data must exist in the
database.

[Input Data:]{.underline}

subscription_id = 2

[Expected Outcome:]{.underline}

slp_listmov will call sdb_get_subscription and pass it the value listed
in Input data and return a subscription_t struct.

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp at first call to slp_listmov

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, step into slp_listmov

-   Step over all function calls until funtion hits a return statement

[Analysis Procedures:]{.underline}

If slp_listmov returns a subscription_t struct after calling all
functions listed in expected outcome, then it has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_listmov

[UTP ID:]{.underline} SLP_LISTMOV01

[Version Control ID:]{.underline} 142dev version 2 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

To test successful execution of slp_listmov.

[Actual Results:]{.underline}

function returned an SLP_subscription_t struct containing data found in
database with subscrption_id equal to input parameter.

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/27/97

[Unit ID:]{.underline} slp_listmov

[UTP ID:]{.underline} SLP_LISTMOV02

[Version Control ID:]{.underline} 142dev version 2

[Unit Function:]{.underline}

This function receives an integer and calls a DB function to retrieve
the subscription identified by the integer input. The subscription is
returned.

[Requirement to be validated:]{.underline}

-   Test for return of existing subscription SUBSCRIPTION NOT FOUND CASE

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling slp_listmov, modifying the input
parameters, and using the microsoft developer studio to halt execution
at the call to slp_listmov, and then step through the function to verify
correctness. A subscription with the ID = input data must NOT exist in
the database.

[Input Data:]{.underline}

subscription_id = 99

[Expected Outcome:]{.underline}

slp_listmov will call sdb_get_subscription and pass it the value listed
in Input data and return a subscription_t struct with a subscription_id
= 0

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp at first call to slp_listmov

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, step into slp_listmov

-   Step over all function calls until funtion hits a return statement

[Analysis Procedures:]{.underline}

If slp_listmov returns a subscription_t struct after calling all
functions listed in expected outcome, then it has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_listmov

[UTP ID:]{.underline} SLP_LISTMOV02

[Version Control ID:]{.underline} 142dev version 2 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

To test successful execution of slp_listmov.

[Actual Results:]{.underline}

function returned an SLP_subscription_t struct containing data found in
database with subscrption_id equal to 0

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} slp_listmov

[UTP ID:]{.underline} SLP_LISTMOV01

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function receives an integer and calls a DB function to retrieve
the subscription identified by the integer input. The subscription is
returned.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

integer representing subscription id

[Expected Outcome:]{.underline}

The subscription with id = input integer

[Test Procedure Steps:]{.underline}

-   Call function with existing subscription id

-   Call function with negative subscription id

-   Call function with 0 subscription id

-   Call function with non-existent positive subscription id

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} slp_listmov

[UTP ID:]{.underline} SLP_LISTMOV01

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/5/96

[Purpose of Test:]{.underline}

The verify that the function executes as expected given valid and
invalid input.

[Actual Results:]{.underline}

-   Returned correct subscription

-   Returned subscription with id = 0 (correct action)

-   Returned subscription with id = 0 (correct action)

-   Returned subscription with id = 0 (correct action)

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/20/97

[Unit ID:]{.underline} matching_subscription_event

[UTP ID:]{.underline} MATCHING_SUBSCRIPTION_EVENT01

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp

[Unit Function:]{.underline}

This function compares a subscription mask and a snapshot mask and
determines whether or not a subscriber is interested in the snapshot
associated with the snapshot mask.

[Requirement to be validated:]{.underline}

-   ?

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the test functions SLP_build_mask
and matching_subscription_event from within test_slp.cpp, and using the
microsoft developer studio to halt execution at the call to
matching_subscription_event, modifying the event masks, and stepping
through the function to verify correctness.

[Input Data:]{.underline}

Snapshot Mask

[Mask Word Decimal Value]{.underline}

0 2147483664

1 2147483713

2 18

3 3

4 32772

5 1048581

6 6

7 7

8 2097208

9 9

Subscription Mask

[Mask Word Decimal Value]{.underline}

0 2147483664

1 2147483713

2 18

3 3

4 32772

5 1048581

6 6

7 7

8 2097208

9 9

[Expected Outcome:]{.underline}

matching_suscription_event should return TRUE

[Test Procedure Steps:]{.underline}

-   Call SLP_build_mask(subscription_mask)

-   Call SLP_build_mask(snapshot_mask)

-   Verify that snapshot_mask and subscription_mask are identical

-   Call matching_subscription_event(snapshot_mask, subscription_mask)

-   Verify that returned value is TRUE.

[Analysis Procedures:]{.underline}

-   If returned value = TRUE, then function has executed successfully.

**Unit Test Plan**

Date: 8/20/97

[Unit ID:]{.underline} matching_subscription_event

[UTP ID:]{.underline} MATCHING_SUBSCRIPTION_EVENT02

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp

[Unit Function:]{.underline}

This function compares a subscription mask and a snapshot mask and
determines whether or not a subscriber is interested in the snapshot
associated with the snapshot mask. CASE: TRUE

[Requirement to be validated:]{.underline}

-   ?

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the test functions SLP_build_mask
and matching_subscription_event from within test_slp.cpp, and using the
microsoft developer studio to halt execution at the call to
matching_subscription_event, modifying the event masks, and stepping
through the function to verify correctness.

[Input Data:]{.underline}

Snapshot Mask

[Mask Word Decimal Value]{.underline}

0 0

1 1

2 2

3 3

4 4

5 5

6 6

7 7

8 2097208

9 9

Subscription Mask

[Mask Word Decimal Value]{.underline}

0 2147483664

1 2147483713

2 18

3 3

4 32772

5 1048581

6 6

7 7

8 2097208

9 9

[Expected Outcome:]{.underline}

matching_suscription_event should return TRUE

[Test Procedure Steps:]{.underline}

-   Call SLP_build_mask(subscription_mask)

-   Call SLP_build_mask(snapshot_mask)

-   Verify that snapshot_mask and subscription_mask are identical

-   Call matching_subscription_event(snapshot_mask, subscription_mask)

-   Verify that returned value is TRUE.

[Analysis Procedures:]{.underline}

-   If returned value = TRUE, then function has executed successfully.

**Unit Test Plan**

Date: 8/20/97

[Unit ID:]{.underline} matching_subscription_event

[UTP ID:]{.underline} MATCHING_SUBSCRIPTION_EVENT03

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp

[Unit Function:]{.underline}

This function compares a subscription mask and a snapshot mask and
determines whether or not a subscriber is interested in the snapshot
associated with the snapshot mask. CASE: TRUE - No subscription events
defined

[Requirement to be validated:]{.underline}

-   ?

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the test functions SLP_build_mask
and matching_subscription_event from within test_slp.cpp, and using the
microsoft developer studio to halt execution at the call to
matching_subscription_event, modifying the event masks, and stepping
through the function to verify correctness.

[Input Data:]{.underline}

Snapshot Mask

[Mask Word Decimal Value]{.underline}

0 2147483664

1 2147483713

2 18

3 3

4 32772

5 1048581

6 6

7 7

8 2097208

9 9

Subscription Mask

[Mask Word Decimal Value]{.underline}

0 0

1 1

2 2

3 3

4 4

5 5

6 6

7 7

8 8

9 9

[Expected Outcome:]{.underline}

matching_suscription_event should return TRUE

[Test Procedure Steps:]{.underline}

-   Call SLP_build_mask(subscription_mask)

-   Call SLP_build_mask(snapshot_mask)

-   Verify that snapshot_mask and subscription_mask are identical

-   Call matching_subscription_event(snapshot_mask, subscription_mask)

-   Verify that returned value is TRUE.

[Analysis Procedures:]{.underline}

If returned value = TRUE, then function has executed successfully.

**Unit Test Plan**

Date: 8/20/97

[Unit ID:]{.underline} matching_subscription_event

[UTP ID:]{.underline} MATCHING_SUBSCRIPTION_EVENT04

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp

[Unit Function:]{.underline}

This function compares a subscription mask and a snapshot mask and
determines whether or not a subscriber is interested in the snapshot
associated with the snapshot mask. CASE: FALSE

[Requirement to be validated:]{.underline}

-   ?

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling the test functions SLP_build_mask
and matching_subscription_event from within test_slp.cpp, and using the
microsoft developer studio to halt execution at the call to
matching_subscription_event, modifying the event masks, and stepping
through the function to verify correctness.

[Input Data:]{.underline}

Snapshot Mask

[Mask Word Decimal Value]{.underline}

0 2147483664

1 2147483713

2 18

3 3

4 32772

5 1048581

6 6

7 7

8 2097208

9 9

Subscription Mask

[Mask Word Decimal Value]{.underline}

0 0

1 1

2 2

3 3

4 4

5 2147483664

6 6

7 7

8 8

9 9

[Expected Outcome:]{.underline}

matching_suscription_event should return TRUE

[Test Procedure Steps:]{.underline}

-   Call SLP_build_mask(subscription_mask)

-   Call SLP_build_mask(snapshot_mask)

-   Verify that snapshot_mask and subscription_mask match the "input
    data" section above.

-   Call matching_subscription_event(snapshot_mask, subscription_mask)

-   Verify that returned value is FALSE.

[Analysis Procedures:]{.underline}

-   If returned value = FALSE, then function has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} matching_subscription_event

[UTP ID:]{.underline} MATCHING_SUBSCRIPTION_EVENT01

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp
[Test Seq Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/20/97

[Purpose of Test:]{.underline}

To test successful execution of matching_subscription_event for the TRUE
case.

[Actual Results:]{.underline}

function returned TRUE

\_\_\_X\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Report**

[Unit ID:]{.underline} matching_subscription_event

[UTP ID:]{.underline} MATCHING_SUBSCRIPTION_EVENT02

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp
[Test Seq Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/20/97

[Purpose of Test:]{.underline}

To test successful execution of matching_subscription_event for the TRUE
case.

[Actual Results:]{.underline}

function returned TRUE

\_\_X\_\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Report**

[Unit ID:]{.underline} matching_subscription_event

[UTP ID:]{.underline} MATCHING_SUBSCRIPTION_EVENT03

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp
[Test Seq Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/20/97

[Purpose of Test:]{.underline}

To test successful execution of matching_subscription_event for the TRUE
case. ( where subscriber has no event data defined )

[Actual Results:]{.underline}

function returned TRUE

\_\_X\_\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Report**

[Unit ID:]{.underline} matching_subscription_event

[UTP ID:]{.underline} MATCHING_SUBSCRIPTION_EVENT04

[Version Control ID:]{.underline} 142dev version 2: slp_mask_utils.cpp
[Test Seq Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/20/97

[Purpose of Test:]{.underline}

To test successful execution of matching_subscription_event for the
FALSE case.

[Actual Results:]{.underline}

function returned FALSE

\_\_X\_\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/21/97

[Unit ID:]{.underline} slp_monitor

[UTP ID:]{.underline} SLP_MONITOR01

[Version Control ID:]{.underline} 142dev version 2

[Unit Function:]{.underline}

This function receives two snapshots, compares the snapshots, and if
there is a difference between the snapshots, it sends the newer snapshot
to all interested subscribers.

[Requirement to be validated:]{.underline}

-   3.1.4.1 - Compare a new snapshot with an old one, and send the new
    one to subscribers

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling test_slp_monitor, modifying the
input parameters, and using the microsoft developer studio to halt
execution at the call to slp_monitor, and then step through the function
to verify correctness.

[Input Data:]{.underline}

Two different snapshots

[Expected Outcome:]{.underline}

slp_monitor will call clear_mask(1), slp_newold(1), data_changed(1), and
slp_user(1)

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp_monitor at first call to slp_monitor

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, step into slp_monitor

-   Step over all function calls until funtion hits a return statement

[Analysis Procedures:]{.underline}

If slp_monitor calls all functions listed in expected outcome and
returns SLP_OK, then it has executed successfully.

**Unit Test Plan**

Date: 8/21/97

[Unit ID:]{.underline} slp_monitor

[UTP ID:]{.underline} SLP_MONITOR02

[Version Control ID:]{.underline} 142dev version 2

[Unit Function:]{.underline}

This function receives two snapshots, compares the snapshots, and if
there is a difference between the snapshots, it sends the newer snapshot
to all interested subscribers.

[Requirement to be validated:]{.underline}

-   3.1.4.1 - Compare identical snapshots and then return

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling test_slp_monitor, modifiying the
input parameters, and using the microsoft developer studio to halt
execution at the call to slp_monitor, and then step through the function
to verify correctness.

[Input Data:]{.underline}

Two identical snapshots

[Expected Outcome:]{.underline}

slp_monitor will call clear_mask(1), slp_newold(1), data_changed(1)

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp_monitor at first call to slp_monitor

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, step into slp_monitor

-   Step over all function calls until funtion hits a return statement

[Analysis Procedures:]{.underline}

If slp_monitor calls only all functions listed in expected outcome and
returns SLP_OK, then it has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_monitor

[UTP ID:]{.underline} SLP_MONITOR01

[Version Control ID:]{.underline} 142dev version 2 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/21/97

[Purpose of Test:]{.underline}

To test successful execution of slp_monitor.

[Actual Results:]{.underline}

1 call was made to clear_mask()

1 call was made to slp_newold()

1 call was made to slp_user()

status value was returned

\_\_[X]{.underline}\_\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Report**

[Unit ID:]{.underline} slp_monitor

[UTP ID:]{.underline} SLP_MONITOR02

[Version Control ID:]{.underline} 142dev version 2 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/21/97

[Purpose of Test:]{.underline}

To test successful execution of slp_monitor.

[Actual Results:]{.underline}

1 call was made to clear_mask()

1 call was made to slp_newold()

status value was returned

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} slp_monitor

[UTP ID:]{.underline} SLP_MONITOR01

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function is responsible for comparing a new and an old snapshot and
distributing it to interested subscribers.

[Requirement to be validated:]{.underline}

-   3.1.4.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

new snapshot

[Expected Outcome:]{.underline}

return BOOLEAN value indicating result of function calls.

[Test Procedure Steps:]{.underline}

-   Call slp_monitor with a valid new snapshot

-   Call slp_monitor with an invalid snapshot

[Analysis Procedures:]{.underline}

-   
-   
-   

**Unit Test Report**

[Unit ID:]{.underline} slp_monitor

[UTP ID:]{.underline} SLP_MONITOR01

[Version Control ID:]{.underline} SAIC V01-B01

[Test Seq Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton

[Test Date:]{.underline} 08/05/96

[Purpose of Test:]{.underline}

Verify that the function executes as planned.

[Actual Results:]{.underline}

-   Executed and returned a BOOLEAN value

-   Executed and returned a BOOLEAN value

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/21/97

[Unit ID:]{.underline} slp_newold

[UTP ID:]{.underline} SLP_NEWOLD01

[Version Control ID:]{.underline} 142dev version 2

[Unit Function:]{.underline}

This function compares two snapshots and returns the changed events

[Requirement to be validated:]{.underline}

-   3.1.4.2 - Identical snapshots

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling test_slp_newold, modifiying the
input parameters, and using the microsoft developer studio to halt
execution at the call to slp_newold, and then stepping through the
function to verify correctness.

[Input Data:]{.underline}

two identical carrier snapshots

[Expected Outcome:]{.underline}

slp_newold will call empty_snapshot()

slp_newold will call slp_compare_snapshots()

slp_newold will return a status value

[Test Procedure Steps:]{.underline}

-   Set breakpoint in slp_monitor at first call to slp_newold

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, verify that both snapshot inputs are identical

-   Step over all function calls until funtion hits a return statement

[Analysis Procedures:]{.underline}

If slp_newold returns a status code after calling all functions listed
in expected outcome, then it has executed successfully.

**Unit Test Plan**

Date: 8/21/97

[Unit ID:]{.underline} slp_newold

[UTP ID:]{.underline} SLP_NEWOLD02

[Version Control ID:]{.underline} 142dev version 2

[Unit Function:]{.underline}

This function compares two snapshots and returns the changed events

[Requirement to be validated:]{.underline}

-   3.1.4.2 - old_snapshot input is empty case

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling test_slp_newold, modifiying the
input paramters, and using the microsoft developer studio to halt
execution at the call to slp_newold, and then stepping through the
function to verify correctness.

[Input Data:]{.underline}

two identical carrier snapshots

[Expected Outcome:]{.underline}

slp_newold will call empty_snapshot()

slp_newold will call fill_mask()

slp_newold will return a status value

[Test Procedure Steps:]{.underline}

-   Set breakpoint in slp_monitor at first call to slp_newold

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, verify that both snapshot inputs are identical

-   Step over all function calls until funtion hits a return statement

[Analysis Procedures:]{.underline}

If slp_newold returns a status code after calling all functions listed
in expected outcome, then it has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_newold

[UTP ID:]{.underline} SLP_NEWOLD01

[Version Control ID:]{.underline} 142dev version 2 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/21/97

[Purpose of Test:]{.underline}

To test successful execution of slp_newold

[Actual Results:]{.underline}

1 call was made to empty_snapshot()

1 call was made to slp_compare_snapshots

status value was returned

\_\_[X]{.underline}\_\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Report**

[Unit ID:]{.underline} slp_newold

[UTP ID:]{.underline} SLP_NEWOLD02

[Version Control ID:]{.underline} 142dev version 2 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/21/97

[Purpose of Test:]{.underline}

To test successful execution of slp_newold

[Actual Results:]{.underline}

1 call was made to empty_snapshot()

1 call was made to fill_mask ()

status value was returned

\_\_[X]{.underline}\_\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} slp_start

[UTP ID:]{.underline} SLP_START01

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function validates the event names that are listed in a
subscription request

[Requirement to be validated:]{.underline}

-   3.1.4.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

subscription request pointer

view pointer

event element list pointer

[Expected Outcome:]{.underline}

a enumerated value indicating whether or not the event names listed in
the subscription request are valid or not.

[Test Procedure Steps:]{.underline}

-   Call function with valid subscription request pointer

-   Call function with invalid subscription request pointer

-   Call function with valid view pointer

-   Call function with invalid view pointer

-   Call function with valid element list pointer

-   Call function with invalid element list pointer

-   Call function with subscription request with valid event names

-   Call function with subscription request with invalid event names

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} slp_start

[UTP ID:]{.underline} SLP_START01

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 02

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/6/96

[Purpose of Test:]{.underline}

To verify that the function executes as planned given various inputs.

[Actual Results:]{.underline}

-   Works with valid subscription request pointer

-   Returns SLP_ERROR with NULL subscription request pointer

-   Works with valid view name

-   Returns SLP_ERROR with NULL view name

-   Works with valid element list pointer

-   Returns SLP_ERROR NULL element list pointer

-   Returns SLP_OK given valid event names

-   Returns SLP_ERROR given invalid event names

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} slp_start

[UTP ID:]{.underline} SLP_START01_1

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function validates the event names that are listed in a
subscription request

[Requirement to be validated:]{.underline}

-   3.1.4.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

subscription request pointer

view pointer

event element list pointer

[Expected Outcome:]{.underline}

a enumerated value indicating whether or not the event names listed in
the subscription request are valid or not.

[Test Procedure Steps:]{.underline}

-   Call function with valid subscription request pointer

-   Call function with invalid subscription request pointer

-   Call function with valid view pointer

-   Call function with invalid view pointer

-   Call function with valid element list pointer

-   Call function with invalid element list pointer

-   Call function with subscription request with valid event names

-   Call function with subscription request with invalid event names

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} slp_start

[UTP ID:]{.underline} SLP_START01_1

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/6/96

[Purpose of Test:]{.underline}

To verify that the function executes as planned given various inputs.

[Actual Results:]{.underline}

-   Works with valid subscription request pointer

-   Crashes with NULL subscription request pointer

-   Works with valid view name

-   Crashes with NULL view name

-   Works with valid element list pointer

-   Crashes with NULL element list pointer

-   Returns SLP_OK given valid event names

-   Returns SLP_ERROR given invalid event names

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/27/97

[Unit ID:]{.underline} slp_tempwrite

[UTP ID:]{.underline} SLP_TEMPWRITE01

[Version Control ID:]{.underline} 142dev version 2

[Unit Function:]{.underline}

This function writes entries to the sendlist q or sends snapshots to
subscribers depending upon each subscriber's process_time_type (
immediately, daily, weekly, etc. ).

[Requirement to be validated:]{.underline}

-   3.1.4.2 - SLP_IMMEDIATELY case

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling slp_tempwrite, modifiying the
input parameters, and using the microsoft developer studio to step
through the function to verify correctness.

[Input Data:]{.underline}

subscription_t pointer to valid subscription_t struct

update_data_t pointer to valid update_data_t struct containing a
snapshot

subscription.process_time_type = SLP_IMMEDIATELY

[Expected Outcome:]{.underline}

slp_tempwrite will call SDB_Get_Subscription_Users,
OMH_output_message_generator and then return a status value

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp at first call to slp_tempwrite

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, step into slp_tempwrite

-   Step over all function calls until function hits a return statement

[Analysis Procedures:]{.underline}

If slp_tempwrite returns a status code after calling all functions
listed in expected outcome, then it has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_tempwrite

[UTP ID:]{.underline} SLP_TEMPWRITE01

[Version Control ID:]{.underline} 142dev version 2 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

To test successful execution of slp_tempwrite

[Actual Results:]{.underline}

function called SDB_Get_Subscription_Users, OMH_output_message_generator
and returned a status value.

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 6/12/97

[Unit ID:]{.underline} slp_tempwrite

[UTP ID:]{.underline} SLP_TEMPWRITE02

[Version Control ID:]{.underline} 142dev version 2

[Unit Function:]{.underline}

This function writes entries to the sendlist q or sends snapshots to
subscribers depending upon each subscriber's process_time_type (
immediately, daily, weekly, etc. ).

[Requirement to be validated:]{.underline}

-   3.1.4.2 - NOT SLP_IMMEDIATELY case

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling test_slp_tempwrite, modifying the
input parameters, and using the microsoft developer studio to halt
execution at the call to slp_tempwrite, and then stepping through the
function to verify correctness.

[Input Data:]{.underline}

subscription_t pointer to valid subscription_t struct

update_data_t pointer to valid update_data_t struct containing a
snapshot

subscription.process_time_type = SLP_DAILY

[Expected Outcome:]{.underline}

slp_tempwrite will call sdb_insert_into_sendlist_q and then return a
status value

[Test Procedure Steps:]{.underline}

-   Set breakpoint in test_slp_tempwrite at first call to slp_tempwrite

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, step into slp_tempwrite

-   Step over all function calls until function hits a return statement

[Analysis Procedures:]{.underline}

If slp_tempwrite returns a status code after calling all functions
listed in expected outcome, then it has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_tempwrite

[UTP ID:]{.underline} SLP_TEMPWRITE02

[Version Control ID:]{.underline} 142dev version 2 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

To test successful execution of slp_tempwrite

[Actual Results:]{.underline}

function called sdb_insert_into_sendlist_q and returned a status value.

\_\_\_[X]{.underline}\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} slp_tempwrite

[UTP ID:]{.underline} SLP_TEMPWRITE01

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

Currently this function is responsible for receiving a pointer to a
subscription and a pointer to a snapshot, and sending the snapshot to
user defined in the subscription via the safety data manager.

[Requirement to be validated:]{.underline}

-   3.1.4.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

subscription pointer

snapshot pointer

[Expected Outcome:]{.underline}

function should call sdm with correct packet header, request header, and
data request, and then return a BOOLEAN value.

[Test Procedure Steps:]{.underline}

-   Call function with valid subscription pointer and snapshot pointer

-   Call function with invalid subscription pointer and valid snapshot
    pointer

-   Call function with invalid snapshot pointer and valid subscription.

-   Call function with invalid subscription pointer and invalid
    subscription

[Analysis Procedures:]{.underline}

**Unit Test Report**

[Unit ID:]{.underline} slp_tempwrite

[UTP ID:]{.underline} SLP_TEMPWRITE01

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 02

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/6/96

[Purpose of Test:]{.underline}

To verify function behaves as planned, given each possible input.

[Actual Results:]{.underline}

-   Function works fine with valid inputs

-   Function returns SLP_ERROR when given one or two null pointers

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} slp_tempwrite

[UTP ID:]{.underline} SLP_TEMPWRITE01_1

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

Currently this function is responsible for receiving a pointer to a
subscription and a pointer to a snapshot, and sending the snapshot to
user defined in the subscription via the safety data manager.

[Requirement to be validated:]{.underline}

-   3.1.4.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

subscription pointer

snapshot pointer

[Expected Outcome:]{.underline}

function should call sdm with correct packet header, request header, and
data request, and then return a BOOLEAN value.

[Test Procedure Steps:]{.underline}

-   Call function with valid subscription pointer and snapshot pointer

-   Call function with invalid subscription pointer and valid snapshot
    pointer

-   Call function with invalid snapshot pointer and valid subscription.

-   Call function with invalid subscription pointer and invalid
    subscription

[Analysis Procedures:]{.underline}

**Unit Test Report**

[Unit ID:]{.underline} slp_tempwrite

[UTP ID:]{.underline} SLP_TEMPWRITE01_1

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/5/96

[Purpose of Test:]{.underline}

To verify function behaves as planned, given each possible input.

[Actual Results:]{.underline}

-   Function works fine with valid inputs

-   Functions crashes when given one or two null pointers

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

Date: 8/21/97

[Unit ID:]{.underline} slp_user

[UTP ID:]{.underline} SLP_USER01

[Version Control ID:]{.underline} 142dev version 2

[Unit Function:]{.underline}

This function checks a given snapshot with every subscription in the
database to determine if each subscriber is interested in it. If the
subscriber is interested, then the subscribers event mask is compared to
the given event mask. If the subscriber is interested, and the event
masks have a matching value, then the snapshot is sent to slp_tempwrite
for further processing.

[Requirement to be validated:]{.underline}

-   3.1.4.2 - No subscribers are interested in snapshot based on carrier

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling slp_monitor, modifying the input
parameters, and using the microsoft developer studio to halt execution
at the call to slp_user, and then stepping through the function to
verify correctness.

[Input Data:]{.underline}

SLP_event_mask_t struct, and an update header struct containing a
snapshot that no subscriber in the database wants based on carrier.

[Expected Outcome:]{.underline}

slp_user will call sdb_get_newlist twice. The status code SLP_OK will be
returned by slp_user.

[Test Procedure Steps:]{.underline}

-   Set breakpoint in slp_monitor at first call to slp_user

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, step into slp_user

-   Step over all function calls

-   Verify that function calls listed above in "Expected Outcome" were
    made and SLP_OK was returned

[Analysis Procedures:]{.underline}

If slp_user returns a status code of SLP_OK after calling all functions
listed in expected outcome, then it has executed successfully.

**Unit Test Plan**

Date: 8/21/97

[Unit ID:]{.underline} slp_user

[UTP ID:]{.underline} SLP_USER02

[Version Control ID:]{.underline} 142dev version 2

[Unit Function:]{.underline}

This function checks a given snapshot with every subscription in the
database to determine if each subscriber is interested in it. If the
subscriber is interested, then the subscribers event mask is compared to
the given event mask. If the subscriber is interested, and the event
masks have a matching value, then the snapshot is sent to slp_tempwrite
for further processing.

[Requirement to be validated:]{.underline}

-   3.1.4.2 - Subscriber wants snapshot based on carrier but NOT event

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling slp_monitor, modifying the input
parameters, and using the microsoft developer studio to halt execution
at the call to slp_user, and then stepping through the function to
verify correctness.

[Input Data:]{.underline}

SLP_event_mask_t struct, and an update header struct containing a
snapshot that no subscriber in the database wants based on carrier.

[Expected Outcome:]{.underline}

slp_user will call sdb_get_newlist twice, slp_listmov once,
matching_subscription_event once, and the status code SLP_OK will be
returned by slp_user.

[Test Procedure Steps:]{.underline}

-   Set breakpoint in slp_monitor at first call to slp_user

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, step into slp_user

-   Step over all function calls

-   Verify that function calls listed above in "Expected Outcome" were
    made and SLP_OK was returned

[Analysis Procedures:]{.underline}

If slp_user returns a status code of SLP_OK after calling all functions
listed in expected outcome, then it has executed successfully.

**Unit Test Plan**

Date: 8/21/97

[Unit ID:]{.underline} slp_user

[UTP ID:]{.underline} SLP_USER03

[Version Control ID:]{.underline} 142dev version 2

[Unit Function:]{.underline}

This function checks a given snapshot with every subscription in the
database to determine if each subscriber is interested in it. If the
subscriber is interested, then the subscribers event mask is compared to
the given event mask. If the subscriber is interested, and the event
masks have a matching value, then the snapshot is sent to slp_tempwrite
for further processing.

[Requirement to be validated:]{.underline}

-   3.1.4.2 - Subscriber wants snapshot based on carrier AND event

[Test Tools, Drivers, or Special Conditions:]{.underline}

The function may be tested by calling slp_monitor, modifying the input
parameters, and using the microsoft developer studio to halt execution
at the call to slp_user, and then stepping through the function to
verify correctness.

[Input Data:]{.underline}

SLP_event_mask_t struct, and an update header struct containing a
snapshot that no subscriber in the database wants based on carrier.

[Expected Outcome:]{.underline}

slp_user will call sdb_get_newlist twice, slp_listmov once,
matching_subscription_event once, slp_tempwrite once, and the status
code SLP_OK will be returned by slp_user.

[Test Procedure Steps:]{.underline}

-   Set breakpoint in slp_monitor at first call to slp_user

-   Select "Test-\>Go" from MS Developer menu.

-   When trap is made, step into slp_user

-   Step over all function calls

-   Verify that function calls listed above in "Expected Outcome" were
    made and SLP_OK was returned

[Analysis Procedures:]{.underline}

If slp_user returns a status code of SLP_OK after calling all functions
listed in expected outcome, then it has executed successfully.

**Unit Test Report**

[Unit ID:]{.underline} slp_user

[UTP ID:]{.underline} SLP_USER01

[Version Control ID:]{.underline} 142dev version 2 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/25/97

[Purpose of Test:]{.underline}

To test successful execution of slp_user

[Actual Results:]{.underline}

slp_get_newlist was called twice

status value SLP_OK was returned

\_\_[X]{.underline}\_\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Report**

[Unit ID:]{.underline} slp_user

[UTP ID:]{.underline} SLP_USER02

[Version Control ID:]{.underline} 142dev version 2 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/25/97

[Purpose of Test:]{.underline}

To test successful execution of slp_user

[Actual Results:]{.underline}

slp_get_newlist was called twice

matching_subscription_event was called once.

status value SLP_OK was returned

\_\_[X]{.underline}\_\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Report**

[Unit ID:]{.underline} slp_user

[UTP ID:]{.underline} SLP_USER03

[Version Control ID:]{.underline} 142dev version 2 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/25/97

[Purpose of Test:]{.underline}

To test successful execution of slp_user

[Actual Results:]{.underline}

slp_get_newlist was called twice

matching_subscription_event was called once

slp_tempwrite was called once

status value SLP_OK was returned

\_\_\_\_\_ PASS \_\_\_\_\_ FAIL

^ ^Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Appendix F - Unit Test (IMH)**

**Input Message Handler (IMH)**

**Unit Test Plans**

**Unit Test Plan**

[Unit ID:]{.underline} IMH_Main

[UTP ID:]{.underline} IMH_Main

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine initializes all CVIEW functions, reads incoming mail
messages, and performs all processing. It is the top level routine for
the entire CVIEW system. It also contains all routines necessary to
initialize, run, and terminate CVIEW as an NT service.

[Requirement to be validated:]{.underline}

-   IMH can initialize database access using Oracle v7.3 and perform
    other initializations to support mail message access, EDI
    processing, and interfacing with the NT operating system.

-   IMH can read input messages from an NT mailbox.

-   IMH can run as an NT service.

-   IMH can correctly translate valid incoming messages and route them
    to the appropriate routines for processing. It can identify and
    reject invalid incoming messages without crashing.

-   IMH processing can be terminated gracefully without causing any
    supporting software to crash, hang, or corrupt a database.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage. The EudoraLite mail package was
used to send the email message to the CVIEW input mailbox. The Distinct
SMTP and POP mail protocol libraries, and associated MBX routines were
used to extract the message from the input mailbox into a temporary file
for further processing. The SQLPlus utility was used to view records in
the database tables. The ServiceInstall and ServiceDelete utilities were
used to test installation of IMH as an NT service.

[Input Data:]{.underline}

A lengthy sequence of input test messages were used and were saved in
EudoraLite mail queues. EDI test messages with line lengths too long for
convenient handling in EudoraLite were stored in text files and mailed
to the input mailbox using a utility developed with Visual C++ and the
Distinct libraries.

[Expected Outcome:]{.underline}

IMH_Main will run correctly as an NT service as well as with the command
line interface. It will successfully read any quantity of input test
messages sent to the input mailbox. It will route valid ones for
processing, and reject invalid ones. The service may be terminated by
using the services utility within the NT control panel.

[Test Procedure Steps:]{.underline}

-   Install IMH as an NT service. Start the service.

-   Send a variety of messages to the CVIEW input mailbox- carrier
    snapshot requests by DOT number, requests by ICC number, single
    record carrier snapshot updates, MCMIS file update messages,
    subscription requests. Include some invalid messages.

-   Verify that carrier snapshot requests resulted in either a valid
    snapshot or an error message being sent to the requester's mailbox.

-   Use SQLPlus to verify that database updates, whether single record
    or MCMIS, occurred.

-   Check that a valid CVIS file was produced during the MCMIS update.

-   Check subscriber mailboxes to ensure that they received all
    snapshots for which they held a subscription.

-   Verify that no extraneous data was sent to user or subscription
    mailboxes.

-   Verify that the NT service can be stopped without any problems.

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} IMH_Main

[UTP ID:]{.underline} IMH_Main

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

To insure that the IMH_Main routine can start, initialize, run, and
terminate properly as an NT service, can read mail messages from its
input mailbox, and can correctly route mail messages through the
processing cycle.

[Actual Results:]{.underline}

-   IMH_Main was able to start, run, and terminate as an NT service.

-   IMH_Main properly initialized database, EDI, and mail functions.

-   IMH_Main properly read mail messages from its input mailbox.

IMH_Main routed mail messages and subsequent filled CVIEW data
structures through the complete processing cycle.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} INPUT_distribute_message

[UTP ID:]{.underline} INPUT_distribute_message

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine receives all CVIEW data structures- packet_header,
request_header, request, data_header, and update data- filled with
information gleaned from the mail message, analyzes them to decide on
required processing, and routes them to the proper routines to complete
the processing.

[Requirement to be validated:]{.underline}

-   Transactions ( requests and updates) indicated in the packet header
    will be processed by being passed to the proper SDM and database
    access routines..

-   The data types, entities, and views indicated in the structures will
    be the ones used to fulfill the transactions.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage. The EudoraLite mail package was
used to send the email message to the CVIEW input mailbox. The Distinct
SMTP and POP mail protocol libraries, and associated MBX routines were
used to extract the message from the input mailbox into a temporary file
for further processing. The SQLPlus utility was used to view records in
the database tables.

[Input Data:]{.underline}

A lengthy sequence of input test messages were used and were saved in
EudoraLite mail queues. EDI test messages with line lengths too long for
convenient handling in EudoraLite were stored in text files and mailed
to the input mailbox using a utility developed with Visual C++ and the
Distinct libraries.

[Expected Outcome:]{.underline}

INPUT_distribute_message will correctly route update data and result in
the record being added to the database. It will correctly process
requests and return the correct snapshot to the user's mailbox.

[Test Procedure Steps:]{.underline}

-   Send a variety of messages to the CVIEW input mailbox- carrier
    snapshot requests by DOT number, requests by ICC number, single
    record carrier snapshot updates, MCMIS file update messages,
    subscription requests.

-   After IMH processes the message, use SQLPlus to verify that updates
    to the database were performed correctly.

-   Also check requester and subscriber mailboxes to be sure that
    snapshots were received and were in the correct format.

[Analysis Procedures:]{.underline}

**Unit Test Report**

[Unit ID:]{.underline} INPUT_distribute_message

[UTP ID:]{.underline} INPUT_distribute_message

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To ensure that incoming CVIEW data structures- packet_header,
request_header, request, data_header, and update data- containing
information from mail messages, are processed properly.

[Actual Results:]{.underline}

-   A complete set of valid test messages resulted in CVIEW data
    structures filled with data.

-   In each case, INPUT_distribute_message correctly analyzed the
    structures to decide on required processing, and routed the data to
    the correct routines to perform that processing.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} INPUT_initialize

[UTP ID:]{.underline} INPUT_initialize

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine executes when the CVIEW service starts. It initializes
database function, the EDI translator, and the mail function. It also
initializes timers controlling access to subscription mailboxes.

[Requirement to be validated:]{.underline}

-   INPUT_initialize correctly initializes database access.

-   INPUT_initialize correctly initializes the EDI translator.

-   INPUT_initialize correctly initializes the mail input and output.

-   INPUT_initialize correctly starts timers to control access to
    subscription mailboxes.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage.

[Input Data:]{.underline}

Two initialization files- WIN.INI and WINMBX.INI were used. The user
inputs a section name when starting the NT service to determine which
section within these initialization files are used.

[Expected Outcome:]{.underline}

The database indicated in the correct section of WIN.INI will be
successfully connected to.

The file WINMBX.INI will be located and read based on a pointer in
WIN.INI.

The input and output mailboxes indicated in the correct section of
WINMBX.INI will be successfully initialized.

The EDI translator will be successfully initialized based on a series of
parameters read from the correct section of WIN.INI.

Subscription mailbox timers will be started based on a series of
parameters read from the correct section of WINMBX.INI.

[Test Procedure Steps:]{.underline}

-   Start the CVIEW service in command line form so that the debugger
    can be used.

-   Step into the INPUT_initialize routine.

-   Step through section of code that initializes subscription mailbox
    timers and verify that success codes are returned.

-   Step through section of code that initializes the database function.
    Verify that database name, password, and host string match those
    requested in WIN.INI. Verify that SDB_init routine returns a success
    status code.

-   Step through section of code that initializes the EDI/IOT
    translator. Verify that filepaths are correctly set in the EDI/IOT
    structures. Verify that a success code is returned.

-   Step through section of code that initializes the CVIEW input and
    output mailbox. Verify that success codes are returned.

-   To double check, stop stepping through, use "Go" mode, and process a
    few messages to verify that all initializations are complete.

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} INPUT_initialize

[UTP ID:]{.underline} INPUT_initialize

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that all initializations required by the CVIEW process are
performed successfully.

[Actual Results:]{.underline}

-   Database function was initialized successfully.

-   Subscription timers were initialized successfully.

-   The EDI/IOT translator was initialized successfully.

-   The CVIEW input and output mailboxes were initialized successfully.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} INPUT_message_translator

[UTP ID:]{.underline} INPUT_message_translator

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine reads an input file containing a subscription request in
text format and transfers the information into the subscription request
structure.

[Requirement to be validated:]{.underline}

-   IMH can accept a subscription request via email message and
    correctly transfer the information into the SLP_subscription_req_t
    structure for further processing and insertion into the subscription
    database table.

-   IMH can also correctly interpret the subscriber parameters (dot
    number or state codes) in the email message for future insertion
    into the subscriber_parms database table.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage. The EudoraLite mail package was
used to send the email message to the CVIEW input mailbox. The Distinct
SMTP and POP mail protocol libraries, and associated MBX routines were
used to extract the message from the input mailbox into a temporary file
for further processing. The SQLPlus utility was used to view records in
the database tables.

[Input Data:]{.underline}

Input messages entitled SLP test 1, 2, and 3 were used and were saved in
EudoraLite mail queues.

[Expected Outcome:]{.underline}

A subscriber with the correct name (name of user mailing the message to
the CVIEW input mailbox) will be added to the subscription table in the
database. The new subscriber will have a unique subscription_id..

The list of DOT numbers contained in the message as subscriber
parameters will be added to the subscriber_parms table with this user's
subscription_id as the key and query_parm_value equal to 1.

The list of state two character codes will be added to the
subscriber_parms table with this user's subscription_id as the key and
query_parm_value equal to 6.

[Test Procedure Steps:]{.underline}

-   Obtain files containing valid subscription request message. Copy
    them into EudoraLite message windows and send to the CVIEW input
    mailbox.

-   Use SQLPlus manual database queries to verify that the subscription
    does not yet exist in the database.

-   Start the IMH (Input Message Handler) in command line form.

```{=html}
<!-- -->
```
-   Step through in the debugger. After executing
    INPUT_message_translator, use the debugger to view the entire
    SLP_subscription_req_t structure.

-   Check each field.

-   Double check by executing INPUT_distribute_message, which completes
    processing of each test message. Then use SQLPlus manual queries to
    verify that the subscription was correctly entered in the database.

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} INPUT_message_translator

[UTP ID:]{.underline} INPUT_message_translator

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

To insure that a text file containing a carrier snapshot in EDI record
format can be read and correctly copied into the cs_v1_t structure.

[Actual Results:]{.underline}

-   The information was correctly read from the text file and inserted
    into the cs_v1_t structure.

-   Repeating fields were properly counted and loaded. The counters were
    set correctly in the structure.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} INPUT_read_subscription_request

[UTP ID:]{.underline} INPUT_read_subscription_request

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine reads an input file containing a subscription request in
text format and transfers the information into the subscription request
structure.

[Requirement to be validated:]{.underline}

-   IMH can accept a subscription request via email message and
    correctly transfer the information into the SLP_subscription_req_t
    structure for further processing and insertion into the subscription
    database table.

-   IMH can also correctly interpret the subscriber parameters (dot
    number or state codes) in the email message for future insertion
    into the subscriber_parms database table.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage. The EudoraLite mail package was
used to send the email message to the CVIEW input mailbox. The Distinct
SMTP and POP mail protocol libraries, and associated MBX routines were
used to extract the message from the input mailbox into a temporary file
for further processing. The SQLPlus utility was used to view records in
the database tables.

[Input Data:]{.underline}

Input messages entitled SLP test 1, 2, and 3 were used and were saved in
EudoraLite mail queues.

[Expected Outcome:]{.underline}

A subscriber with the correct name (name of user mailing the message to
the CVIEW input mailbox) will be added to the subscription table in the
database. The new subscriber will have a unique subscription_id..

The list of DOT numbers contained in the message as subscriber
parameters will be added to the subscriber_parms table with this user's
subscription_id as the key and query_parm_value equal to 1.

The list of state two character codes will be added to the
subscriber_parms table with this user's subscription_id as the key and
query_parm_value equal to 6.

[Test Procedure Steps:]{.underline}

-   Obtain files containing valid subscription request message. Copy
    them into EudoraLite message windows and send to the CVIEW input
    mailbox.

-   Use SQLPlus manual database queries to verify that the subscription
    does not yet exist in the database.

-   Start the IMH (Input Message Handler) in command line form.

```{=html}
<!-- -->
```
-   Step through in the debugger. After executing
    INPUT_read_subscription_request, use the debugger to view the entire
    SLP_subscription_req_t structure.

-   Check each field.

-   Double check by executing INPUT_distribute_message, which completes
    processing of each test message. Then use SQLPlus manual queries to
    verify that the subscription was correctly entered in the database.

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} INPUT_read_subscription_request

[UTP ID:]{.underline} INPUT_read_subscription_request

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that a mail message containing a request to set up a
subscription and to add subscriber parameters (DOT numbers or state
codes) to the subscription can be parsed and the information stored in
CVIEW data structures for eventual updating of the database subscription
and subscriber_parms tables..

[Actual Results:]{.underline}

-   Subscription request messages were correctly processed and the
    information stored in CVIEW data structures.

-   Subscriptions were set up and subscriber parameters added to the
    database table.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} INPUT_subscription_update

[UTP ID:]{.underline} INPUT_subscription_update

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine executes when the subscription mailbox timer has rung and a
flag been set. The subscription mailbox is initialized and connected to.
All carrier snapshot updates in that mailbox are read and routed for
further processing that includes being written to the database and being
sent to subscribers. On completion, the subscription mailbox is
disconnected. Information is written to a mailbox timer log to record
that the mailbox was checked, and identifying the carrier snapshots (if
any) that were processed.

[Requirement to be validated:]{.underline}

-   A subscription mailbox can be checked based on a timer.

-   Subscription mailboxes can be connected to and disconnected from in
    this context.

-   Any carrier snapshot updates contained in that subscription mailbox
    can be read and processed correctly.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage.

The EudoraLite mail package was used to send the email message to the
CVIEW input mailbox. The Distinct SMTP and POP mail protocol libraries,
and associated MBX routines were used to extract the message from the
input mailbox into a temporary file for further processing. The SQLPlus
utility was used to view records in the database tables.

[Input Data:]{.underline}

A test subscription mailbox was loaded with data by running a test MCMIS
update with it as a subscriber for about ten DOT numbers known to exist
in the MCMIS file. The carrier snapshot updates were altered by adding
the number nine million to their DOT numbers. A copy of the subscription
mailbox was saved in case the test needed to be run more than once.

[Expected Outcome:]{.underline}

The mailbox timer will ring, set a flag, and INPUT_subscription_update
will be executed.

The subscription mailbox will be successfully initialized.

Each carrier snapshot in turn will be read from the subscription mailbox
and will be processed by calling other routines to write it to the
database.

The subscription mailbox will be disconnected.

The mailbox timer log will indicate that the subscription mailbox was
checked, at what time, and will list the DOT numbers of the carrier
snapshots read from it.

[Test Procedure Steps:]{.underline}

-   Have the subscription mailbox loaded with the carrier snapshots with
    DOT numbers altered to exceed nine million and therefor not equal
    any valid snapshots.

-   Verify that the test database contains no DOT numbers nine million
    or higher.

-   Using the debugger, set a break point at the
    INPUT_subscription_update routine.

-   Verify that the subscription mailbox initializes properly.

-   Verify that the first carrier snapshot update is read from the
    mailbox.

-   Change from step mode to run mode and allow CVIEW to process all
    remaining subscription updates.

-   Check the MailboxTimerLog to verify that time of subscription
    mailbox access and DOT numbers of carrier snapshot updates were
    recorded.

-   Use SQLPlus to verify that the ten subscription updates were written
    to the database.

-   Also use SQLPlus to delete the records from the database.

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} INPUT_subscription_update

[UTP ID:]{.underline} INPUT_subscription_update

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that all initializations required by the CVIEW process are
performed successfully.

To insure that a subscription mailbox can be read on a timer and any
carrier snapshot updates contained within it processed and written to
the database.

[Actual Results:]{.underline}

.

-   Ringing of the timer handed control to the INPUT_subscription_update
    routine.

-   Subscription mailbox was initialized, connected to, and disconnected
    from properly.

-   The test update messages were read from the subscription mailbox,
    processed, and written to the database.

-   The log indicated time of subscription mailbox access, and which DOT
    numbers were processed.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Appendix G - Unit Test (IOT)**

**Input/Output Translator (IOT)**

**Unit Test Plans and Test Reports**

**Unit Test Plan**

[Unit ID:]{.underline} IOT_add_outgoing_message

[UTP ID:]{.underline} IOT_ADD_OUTG1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

converts a single snapshot, query, subscription request, or other
transaction from internal form to application text file records and
appends the records to a file in order to generate a multi-transaction
outgoing message.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: multicsnapout.cpp

[Input Data:]{.underline}

Snapshot Query Type

Snapshot view

Snapshot Query Parameters

Message Format

Message Compression

[Expected Outcome:]{.underline}

carrier snapshot application text file records are appended to the
application text file

[Test Procedure Steps:]{.underline}

-   log onto CVIEW DB

-   Build and execute snapshot query

-   fill data structures with snapshot and other input data

-   call IOT_add_outgoing_transaction

[Analysis Procedures:]{.underline}

-   examine application text file and verify records are correct

**Unit Test Report**

[Unit ID:]{.underline} IOT_add_outgoing_message

[UTP ID:]{.underline} IOT_ADD_OUTG1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

To verify that a single transaction can be added to a multi-transaction
application text file

[Actual Results:]{.underline}

application text file records corresponding to a carrier snapshot were
added to the application text file

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_add_outgoing_message

[UTP ID:]{.underline} IOT_ADD_OUTG2

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

converts a single snapshot, query, subscription request, or other
transaction from internal form to application text file records and
appends the records to a file in order to generate a multi-transaction
outgoing message.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcqry.cpp

[Input Data:]{.underline}

Snapshot Query Type

Snapshot view

Snapshot Query Parameters

Overnight Flag

CDROM Flag

File Transfer Flag

Media Type

Message Format

Message Compression

[Expected Outcome:]{.underline}

carrier snapshot query application text file records are appended to the
application text file

[Test Procedure Steps:]{.underline}

-   fill data structures with input data

-   call IOT_add_outgoing_transaction

[Analysis Procedures:]{.underline}

-   examine application text file and verify records are correct

**Unit Test Report**

[Unit ID:]{.underline} IOT_add_outgoing_message

[UTP ID:]{.underline} IOT_ADD_OUTG2

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

To verify that a single transaction can be added to a multi-transaction
application text file

[Actual Results:]{.underline}

application text file records corresponding to a carrier snapshot query
were added to the application text file

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_build_C35_vrecord

[UTP ID:]{.underline} IOT_BLD_C35_1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

converts carrier operation type data contained in a CVIEW internal
snapshot data structure into a variable length application text file
record

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcsnap.cpp

[Input Data:]{.underline}

carrier snapshot with multiple carrier operation types set

[Expected Outcome:]{.underline}

a properly formatted C35 application text file record is generated for
each operation type set

[Test Procedure Steps:]{.underline}

-   fill data structures with carrier snapshot data

-   call iot_build_C35_vrecord for each operation type field set in
    snapshot

[Analysis Procedures:]{.underline}

-   examine resulting C35 record and verify it is correct

**Unit Test Report**

[Unit ID:]{.underline} iot_build_C35_vrecord

[UTP ID:]{.underline} IOT_BLD_C35_1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a properly constructed C35 record is built from carrier
snapshot operations information

[Actual Results:]{.underline}

C35 records containing appropriate operations codes were generated from
the carrier snapshot data

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_build_CS1_vrecord

[UTP ID:]{.underline} IOT_BLD_CS1_1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

converts portion of carrier snapshot data contained in CVIEW internal
data structure into a variable length application text file record

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcsnap.cpp

[Input Data:]{.underline}

Snapshot Data

Snapshot view

[Expected Outcome:]{.underline}

a properly formatted CS1 application text file record is generated

[Test Procedure Steps:]{.underline}

-   fill data structures with snapshot data

-   call iot_build_CS1_vrecord

[Analysis Procedures:]{.underline}

-   examine resulting CS1 record and verify it is correct

**Unit Test Report**

[Unit ID:]{.underline} iot_build_CS1_vrecord

[UTP ID:]{.underline} IOT_BLD_CS1_1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

to verify that a properly constructed CS1 record is built from carrier
snapshot information

[Actual Results:]{.underline}

a properly CS1 record containing appropriate data was generated from the
carrier snapshot

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_build_error_msg

[UTP ID:]{.underline} IOT_BLD_ERR_MSG1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

builds an application text file format error response transaction from
error data contained in internal data structures for conversion to EDI
824 transaction or as non EDI application text format message

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: gen_err_msg.cpp

[Input Data:]{.underline}

transaction tracking number

error status = did not process

error reason = no match

[Expected Outcome:]{.underline}

application text file records representing a NO MATCH error will be
generated

[Test Procedure Steps:]{.underline}

-   fill data structures with input data

-   call iot_build_error_msg

[Analysis Procedures:]{.underline}

-   examine application text file records and verify that they are
    correct

**Unit Test Report**

[Unit ID:]{.underline} iot_build_error_msg

[UTP ID:]{.underline} IOT_BLD_ERR_MSG1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that correct application text file records corresponding to a
"NO MATCH" error response message are generated

[Actual Results:]{.underline}

application text file records for a "NO MATCH" error response message
were generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_build_error_msg

[UTP ID:]{.underline} IOT_BLD_ERR_MSG2

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

builds an application text file format error response transaction from
error data contained in internal data structures for conversion to EDI
824 transaction or as non EDI application text format message

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: gen_err_msg.cpp

[Input Data:]{.underline}

transaction tracking number

error status = reject

error reason = bad value

several data element code values

error reason codes corresponding to each data element

[Expected Outcome:]{.underline}

application text file records representing a REJECTED transaction and
containing the data element values, error message text, and error reason
codes will be generated

[Test Procedure Steps:]{.underline}

-   fill data structures with input data

-   call iot_build_error_msg

[Analysis Procedures:]{.underline}

-   verify that generated records are correct

**Unit Test Report**

[Unit ID:]{.underline} iot_build_error_msg

[UTP ID:]{.underline} IOT_BLD_ERR_MSG2

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that correct application text file records corresponding to a
"REJECTED TRANSACTION" error response message are generated

[Actual Results:]{.underline}

application text file records for a "REJECTED TRANSACTION" error
response message were generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_build_insp_summary

[UTP ID:]{.underline} IOT_BLD_INSP_SUMM

[Version Control ID:]{.underline} IOT V1.2.2

[Unit Function:]{.underline}

generates records containing extracted data from inspection reports. The
records are stored in a file, which is compressed and added to the zip
archive containing the associated inspection report files (also in
compressed form), during the process of generating a response to a
inspection report query.

[Requirement to be validated:]{.underline}

-   generate inspection report summary records containing:

    \- inspection report number

    \- report file name

    \- license plate

    \- state

    \- driver\'s license number

    \- driver\'s license state

    \- county code

    \- inspection time 24 hr - (HH:MM)

\- inspection date (MM/DD/YY)

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: out_ir.cpp

[Input Data:]{.underline}

Inspection report Data

[Expected Outcome:]{.underline}

a file containing one record for each inspection report is generated

[Test Procedure Steps:]{.underline}

-   extract inspection report from SAFER DB via inspection report query

-   call IOT_start_outgoing_messsage

-   call IOT_add_transaction

[Analysis Procedures:]{.underline}

-   verify generated records contain correctly formatted data from the
    inspection reports extracted from the db

**Unit Test Report**

[Unit ID:]{.underline} iot_build_insp_summary

[UTP ID:]{.underline} IOT_BLD_INSP_SUMM

[Version Control ID:]{.underline} IOT V1.2.2

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

to verify that the appropriate inspection report summary records are
generated

[Actual Results:]{.underline}

inspection report summary records containing the 9 required data
elements were generated. The data in each record corresponded to the
associated inspection report.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_build_IR_app_file

[UTP ID:]{.underline} IOT_BLD_IR_APP1

[Version Control ID:]{.underline} IOT V1.2.2

[Unit Function:]{.underline}

generates a non EDI message file, which provides the contents of the
email message body that accompanies and identifies a zipped archive
containing inspection reports. The message file is sent by SAFER to
clients as the response to their inspection report query.

[Requirement to be validated:]{.underline}

generate an non EDI file, which can be converted to an EDI message and
will accompany an inspection report and identify the message as an
inspection report when received by the client.

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: out_ir.cpp

[Input Data:]{.underline}

Inspection report Data

Message format = Application text file

[Expected Outcome:]{.underline}

a non EDI message file is generated

[Test Procedure Steps:]{.underline}

-   extract inspection report from SAFER DB via inspection report query

-   call IOT_start_outgoing_messsage

-   call IOT_add_transaction to insert inspection report data

-   call IOT_finish_outgoing_message to cause non EDI IR application
    text file to be generated

[Analysis Procedures:]{.underline}

-   verify that the T01 and T02 records in the non EDI application text
    file are correctly formatted

**Unit Test Report**

[Unit ID:]{.underline} iot_build_IR_app_file

[UTP ID:]{.underline} IOT_BLD_IR_APP1

[Version Control ID:]{.underline} IOT V1.2.2

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

to verify that a correctly formatted non EDI application text file is
generated

[Actual Results:]{.underline}

a non EDI application text file containing T01 & T02 records was
generated..

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_build_query

[UTP ID:]{.underline} IOT_BLD_QRY1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

builds application text file records corresponding to a query
transaction: one T02 plus one or more REF records.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Driver: outcqry.cpp

[Input Data:]{.underline}

Tracking Number

Snapshot Query Type

Snapshot view

Snapshot Query Parameters

Overnight Flag

CDROM Flag

File Transfer Flag

Media Type

Message Format

Message Compression

[Expected Outcome:]{.underline}

T02 plus one or more REF records are generated

[Test Procedure Steps:]{.underline}

-   fill data structures with input data

-   call iot_build_query

[Analysis Procedures:]{.underline}

-   verify generated records are correct

**Unit Test Report**

[Unit ID:]{.underline} IOT_build_query

[UTP ID:]{.underline} IOT_BLD_QRY1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that application text file records corresponding to a properly
constructed snapshot query are generated

[Actual Results:]{.underline}

T01, T02, and REF records were generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_build_query

[UTP ID:]{.underline} IOT_BLD_QRY2

[Version Control ID:]{.underline} IOT V1.2.1

[Unit Function:]{.underline}

builds application text file records corresponding to a query
transaction: one T02 plus one or more REF records.

[Requirement to be validated:]{.underline}

-   generate inspection report query

[Test Tools, Drivers, or Special Conditions:]{.underline}

Driver: outcqry.cpp

[Input Data:]{.underline}

Tracking Number

Inspection report Query Parameters

Overnight Flag

CDROM Flag

File Transfer Flag

Media Type

Message Format

Message Compression

[Expected Outcome:]{.underline}

T02 plus one or more REF records are generated

[Test Procedure Steps:]{.underline}

-   fill data structures with input data

-   call iot_build_query

[Analysis Procedures:]{.underline}

-   verify generated records are correct

**Unit Test Report**

[Unit ID:]{.underline} IOT_build_query

[UTP ID:]{.underline} IOT_BLD_QRY2

[Version Control ID:]{.underline} IOT V1.2.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

to verify that application text file records corresponding to a properly
constructed inspection report query are generated

[Actual Results:]{.underline}

T01, T02, and REF records were generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_build_snapshot

[UTP ID:]{.underline} IOT_BLD_SNAP1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

converts snapshot data in internal data structures to application text
file records corresponding to a snapshot transaction: one T02 plus one
CS1 plus one or more TC2, C35, CFO, CSO, CP1, and CPJ records.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcsnap.cpp

[Input Data:]{.underline}

DB user

DB password

DB host

Snapshot Query Type

Snapshot view

Snapshot Query Parameters

Message Format

Message Compression Type

[Expected Outcome:]{.underline}

T02, CS1, TC2, C35, CFO, CSO, CP1, & CPJ carrier snapshot records are
generated

[Test Procedure Steps:]{.underline}

-   log onto CVIEW DB

-   Build and execute snapshot query

-   fill data structures with snapshot and other input data

-   call iot_build_snapshot

[Analysis Procedures:]{.underline}

-   verify generated records are correct

**Unit Test Report**

[Unit ID:]{.underline} IOT_build_snapshot

[UTP ID:]{.underline} IOT_BLD_SNAP1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that application text file records corresponding to a properly
constructed snapshot are generated

[Actual Results:]{.underline}

application text file records corresponding to a carrier snapshot
transaction were generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_build_subscription_req

[UTP ID:]{.underline} IOT_BLD_SUBRQ1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

builds application text file records corresponding to a subscription
request transaction: one T02 plus one SL1 plus or more SE1 and REF
records.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outsubreq.cpp

[Input Data:]{.underline}

Subscription Request ID

Subscription Event(s)

Subscription Event Type(s)

Subscription Process Interval

Snapshot Query Type

Snapshot view

Snapshot Query Parameters

Message Compression

[Expected Outcome:]{.underline}

T02, SL1, SE1, & REF records are generated

[Test Procedure Steps:]{.underline}

-   fill data structures with input data

-   call iot_build_subscription_req

[Analysis Procedures:]{.underline}

-   verify generated records are correct

**Unit Test Report**

[Unit ID:]{.underline} IOT_build_subscription_req

[UTP ID:]{.underline} IOT_BLD_SUBRQ1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that application text file records corresponding to a properly
constructed subscription request are generated

[Actual Results:]{.underline}

application text file records corresponding to a subscription request
transaction were generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_build_T01_vline

[UTP ID:]{.underline} IOT_BLD_T01_1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

builds a T01 application text file record, which contains interchange
data required for generation of EDI message.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcqry.cpp

[Input Data:]{.underline}

Transaction type

Trading Partner ID

Purpose Code

Reference ID

Date

Time

Time Code

Prior Reference ID

Sender Last Name

Sender First Name

Sender Middle Name

Sender Organization

[Expected Outcome:]{.underline}

properly formatted T01 record will be generated

[Test Procedure Steps:]{.underline}

-   fill data structures with input data

-   call iot_build_T01_vline

[Analysis Procedures:]{.underline}

-   examine record generated and verify it is correct

**Unit Test Report**

[Unit ID:]{.underline} iot_build_T01_vline

[UTP ID:]{.underline} IOT_BLD_T01_1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a properly constructed T01 application text file record
is generated

[Actual Results:]{.underline}

a T01 application text file record is generated from interchange input
data

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_build_T02_vline

[UTP ID:]{.underline} IOT_BLD_T02_5

[Version Control ID:]{.underline} IOT V1.2.2

[Unit Function:]{.underline}

builds a T02 application text file record, which contains entity,
tracking numbers, query, view, and other information associated with a
transaction

[Requirement to be validated:]{.underline}

-   build T02 record for inspection report

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: out_ir.cpp

[Input Data:]{.underline}

Inspection report Data

Message Format = Application Text File

[Expected Outcome:]{.underline}

T02 record formatted for an inspection report will be generated

[Test Procedure Steps:]{.underline}

-   extract inspection report from SAFER db

-   call iot_build_T02_vline for inspection report

[Analysis Procedures:]{.underline}

-   examine record generated and verify it is correct

**Unit Test Report**

[Unit ID:]{.underline} iot_build_T02_vline

[UTP ID:]{.underline} IOT_BLD_T02_5

[Version Control ID:]{.underline} IOT V1.2.2

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

to verify that a T02 application text file record for an inspection
report transaction is generated

[Actual Results:]{.underline}

a T02 application text file record with an entity=IP (inspection report)
is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_build_T02_vline

[UTP ID:]{.underline} IOT_BLD_T02_1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

builds a T02 application text file record, which contains entity,
tracking numbers, query, view, and other information associated with a
transaction

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcsnap.cpp

[Input Data:]{.underline}

Entity

Tracking Number

(Prior) Subscription List

View

[Expected Outcome:]{.underline}

T02 record formatted for a snapshot transaction will be generated

[Test Procedure Steps:]{.underline}

-   fill data structures with input data

-   call iot_build_T02_vline for snapshot transaction

[Analysis Procedures:]{.underline}

-   examine record generated and verify it is correct

**Unit Test Report**

[Unit ID:]{.underline} iot_build_T02_vline

[UTP ID:]{.underline} IOT_BLD_T02_1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a T02 application text file record for a carrier snapshot
transaction is generated

[Actual Results:]{.underline}

a T02 application text file record for a carrier snapshot transaction is
generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_build_T02_vline

[UTP ID:]{.underline} IOT_BLD_T02_2

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

builds a T02 application text file record, which contains entity,
tracking numbers, query, view, and other information associated with a
transaction

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcqry.cpp

[Input Data:]{.underline}

Entity

Tracking Number

Query

View

Overnight Flag

Cost Estimate Flag

File Transfer Flag

CD ROM Flag

[Expected Outcome:]{.underline}

T02 record formatted for a query transaction will be generated

[Test Procedure Steps:]{.underline}

-   fill data structures with input data

-   call iot_build_T02_vline for query transaction

[Analysis Procedures:]{.underline}

-   examine record generated and verify it is correct

**Unit Test Report**

[Unit ID:]{.underline} iot_build_T02_vline

[UTP ID:]{.underline} IOT_BLD_T02_2

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a T02 application text file record for a carrier snapshot
query transaction is generated

[Actual Results:]{.underline}

a T02 application text file record for a carrier snapshot query
transaction is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_build_T02_vline

[UTP ID:]{.underline} IOT_BLD_T02_3

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

builds a T02 application text file record, which contains entity,
tracking numbers, query, view, and other information associated with a
transaction

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outsubreq.cpp

[Input Data:]{.underline}

Entity

Tracking Number

Query

View

Status Report Flag

Baseline Data Flag

[Expected Outcome:]{.underline}

T02 record formatted for a subscription request transaction will be
generated

[Test Procedure Steps:]{.underline}

-   fill data structures with input data

-   call iot_build_T02_vline for subscription request transaction

[Analysis Procedures:]{.underline}

-   examine record generated and verify it is correct

**Unit Test Report**

[Unit ID:]{.underline} iot_build_T02_vline

[UTP ID:]{.underline} IOT_BLD_T02_3

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a T02 application text file record for a subscription
request transaction is generated

[Actual Results:]{.underline}

a T02 application text file record for a subscription request
transaction is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_build_T02_vline

[UTP ID:]{.underline} IOT_BLD_T02_4

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

builds a T02 application text file record, which contains entity,
tracking numbers, query, view, and other information associated with a
transaction

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: gen_err_msg.cpp

[Input Data:]{.underline}

Entity

Tracking Number

[Expected Outcome:]{.underline}

T02 record formatted for an error response transaction will be generated

[Test Procedure Steps:]{.underline}

-   fill data structures with input data

-   call iot_build_T02_vline for error response transaction

[Analysis Procedures:]{.underline}

-   examine record generated and verify it is correct

**Unit Test Report**

[Unit ID:]{.underline} iot_build_T02_vline

[UTP ID:]{.underline} IOT_BLD_T02_4

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a T02 application text file record for an error response
transaction is generated

[Actual Results:]{.underline}

a T02 application text file record for an error response transaction is
generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_build_TC2_vrecord

[UTP ID:]{.underline} IOT_BLD_TC2_1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

converts carrier commodity data (hazmat & non hazmat) contained in a
CVIEW internal snapshot data structure into a variable length
application text file record

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcsnap.cpp

[Input Data:]{.underline}

carrier snapshot with multiple carrier commodity values set, snapshot
view

[Expected Outcome:]{.underline}

a properly formatted TC2 application text file record is generated for
each commodity type set

[Test Procedure Steps:]{.underline}

-   fill data structures with carrier snapshot data

-   call iot_build_TC2_vrecord for each commodity field set in snapshot

[Analysis Procedures:]{.underline}

-   examine resulting TC2 records and verify it is correct

**Unit Test Report**

[Unit ID:]{.underline} iot_build_TC2_vrecord

[UTP ID:]{.underline} IOT_BLD_TC2_1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that TC2 application text file snapshot commodity records
containing appropriate commodity code values are generated from the
snapshot input data

[Actual Results:]{.underline}

TC2 commodity records are generated from the snapshot data

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_close_translator

[UTP ID:]{.underline} IOT_CLS_TRN1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

releases private IOT management memory allocated during initialization
and writes Reference ID sequence number of the next outgoing message to
win.ini file. If the IOT log file is open, a "closing log file" entry is
written and the log file is closed.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcqry.cpp

[Input Data:]{.underline}

section in win.ini file

win.ini file containing reference ID sequence number

[Expected Outcome:]{.underline}

allocated memory is freed

reference ID sequence number of next outgoing message is written to
win.ini file

closing log entry is written to log file & log file is closed

private management memory is released

[Test Procedure Steps:]{.underline}

-   initialize translator (IOT_initialize_translator)

-   manually delete Reference ID sequence number in win.ini file

-   call IOT_close_translator

[Analysis Procedures:]{.underline}

-   using debugger, verify that private memory is released

-   examine win.ini and verify that next sequence number is same as
    originally in the file

-   examine IOT log file and verify that "closing Log File" entry exists

**Unit Test Report**

[Unit ID:]{.underline} IOT_close_translator

[UTP ID:]{.underline} IOT_CLS_TRN1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that the IOT_close_transaction frees allocated memory, closes
the IOT log file, and writes the reference id sequence number for the
next outgoing message to the win.ini file

[Actual Results:]{.underline}

the IOT_close_transaction function worked correctly

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_do_translate_inb

[UTP ID:]{.underline} IOT_DO_TRANS_INB1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

invokes COTS EDI translator software to process inbound EDI messages

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsg.cpp

[Input Data:]{.underline}

EDI carrier snapshot message

[Expected Outcome:]{.underline}

application text file formatted carrier snapshot records are generated

[Test Procedure Steps:]{.underline}

-   call iot_do_translate_inb with EDI carrier snapshot message

[Analysis Procedures:]{.underline}

-   examine application text file carrier snapshot records and verify
    that they are correct

**Unit Test Report**

[Unit ID:]{.underline} iot_do_translate_inb

[UTP ID:]{.underline} IOT_DO_TRANS_INB1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that the EDI input message is correctly translated to an
application text file

[Actual Results:]{.underline}

the EDI carrier snapshot message was correctly translated to application
text file records

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_do_translate_inb

[UTP ID:]{.underline} IOT_DO_TRANS_INB2

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

invokes COTS EDI translator software to process inbound EDI messages

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsg.cpp

[Input Data:]{.underline}

EDI carrier snapshot query message

[Expected Outcome:]{.underline}

application text file formatted carrier snapshot query records are
generated

[Test Procedure Steps:]{.underline}

-   call iot_do_translate_inb with EDI carrier snapshot query message

[Analysis Procedures:]{.underline}

-   examine application text file carrier snapshot query records and
    verify that they are correct

**Unit Test Report**

[Unit ID:]{.underline} iot_do_translate_inb

[UTP ID:]{.underline} IOT_DO_TRANS_INB2

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that the EDI input message is correctly translated to an
application text file

[Actual Results:]{.underline}

the EDI carrier snapshot query message was correctly translated to
application text file records

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_do_translate_inb

[UTP ID:]{.underline} IOT_DO_TRANS_INB3

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

invokes COTS EDI translator software to process inbound EDI messages

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsg.cpp

[Input Data:]{.underline}

EDI subscription request message

[Expected Outcome:]{.underline}

application text file formatted subscription request records are
generated

[Test Procedure Steps:]{.underline}

-   call iot_do_translate_inb with EDI subscription request message

[Analysis Procedures:]{.underline}

-   examine application text file subscription request records and
    verify that they are correct

**Unit Test Report**

[Unit ID:]{.underline} iot_do_translate_inb

[UTP ID:]{.underline} IOT_DO_TRANS_INB3

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that the EDI input message is correctly translated to an
application text file

[Actual Results:]{.underline}

the EDI subscription request message was correctly translated to
application text file records

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_do_translate_inb

[UTP ID:]{.underline} IOT_DO_TRANS_INB4

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

invokes COTS EDI translator software to process inbound EDI messages

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsg.cpp

[Input Data:]{.underline}

EDI error response message

[Expected Outcome:]{.underline}

application text file formatted error response records are generated

[Test Procedure Steps:]{.underline}

-   call iot_do_translate_inb with EDI error response message

[Analysis Procedures:]{.underline}

-   examine application text file error response records and verify that
    they are correct

**Unit Test Report**

[Unit ID:]{.underline} iot_do_translate_inb

[UTP ID:]{.underline} IOT_DO_TRANS_INB4

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that the EDI input message is correctly translated to an
application text file

[Actual Results:]{.underline}

the EDI error response message was correctly translated to application
text file records

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_do_translate_outb

[UTP ID:]{.underline} IOT_DO_TRANS_OUTB1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

invokes COTS EDI translator software to generate an outbound EDI message

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsgo.cpp

[Input Data:]{.underline}

EDI carrier snapshot query message

[Expected Outcome:]{.underline}

an EDI formatted carrier snapshot message is generated

[Test Procedure Steps:]{.underline}

-   process query message

-   call iot_do_translate_outb with application text file containing
    carrier snapshot records

[Analysis Procedures:]{.underline}

-   compare generated EDI message to a known correct equivalent message

**Unit Test Report**

[Unit ID:]{.underline} iot_do_translate_outb

[UTP ID:]{.underline} IOT_DO_TRANS_OUTB1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a correct EDI carrier snapshot message is generated

[Actual Results:]{.underline}

a correct EDI carrier snapshot message is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_do_translate_outb

[UTP ID:]{.underline} IOT_DO_TRANS_OUTB2

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

invokes COTS EDI translator software to generate an outbound EDI message

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcqry.cpp

[Input Data:]{.underline}

carrier snapshot query data (query number, query view, query parameters)

[Expected Outcome:]{.underline}

an EDI formatted carrier snapshot query message is generated

[Test Procedure Steps:]{.underline}

-   call iot_do_translate_outb with application text file containing
    carrier snapshot query records

[Analysis Procedures:]{.underline}

-   compare generated EDI message to a known correct equivalent message

**Unit Test Report**

[Unit ID:]{.underline} iot_do_translate_outb

[UTP ID:]{.underline} IOT_DO_TRANS_OUTB2

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a correct EDI carrier snapshot query message is generated

[Actual Results:]{.underline}

a correct EDI carrier snapshot query message is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_do_translate_outb

[UTP ID:]{.underline} IOT_DO_TRANS_OUTB3

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

invokes COTS EDI translator software to generate an outbound EDI message

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outsubreq.cpp

[Input Data:]{.underline}

application text file containing subscription request records

[Expected Outcome:]{.underline}

an EDI formatted subscription request message is generated

[Test Procedure Steps:]{.underline}

-   call iot_do_translate_outb with application text file containing
    subscription request records

[Analysis Procedures:]{.underline}

-   compare generated EDI message to a known correct equivalent message

**Unit Test Report**

[Unit ID:]{.underline} iot_do_translate_outb

[UTP ID:]{.underline} IOT_DO_TRANS_OUTB3

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a correct EDI subscription request message is generated

[Actual Results:]{.underline}

a correct EDI subscription request message is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_do_translate_outb

[UTP ID:]{.underline} IOT_DO_TRANS_OUTB4

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

invokes COTS EDI translator software to generate an outbound EDI message

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: gen_err_msg.cpp

[Input Data:]{.underline}

internal error response data

[Expected Outcome:]{.underline}

an EDI formatted error response message is generated

[Test Procedure Steps:]{.underline}

-   call iot_do_translate_outb with application text file containing
    error response records

[Analysis Procedures:]{.underline}

-   compare generated EDI message to a known correct equivalent message

**Unit Test Report**

[Unit ID:]{.underline} iot_do_translate_outb

[UTP ID:]{.underline} IOT_DO_TRANS_OUTB4

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a correct EDI error response message is generated

[Actual Results:]{.underline}

a correct EDI error response message is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_fill_structures

[UTP ID:]{.underline} IOT_FILL_STRCT5

[Version Control ID:]{.underline} IOT V1.2.2

[Unit Function:]{.underline}

Moves data extracted from an application text file generated from an
incoming message and stores it in transaction specific packet header,
update data, data header, request header, and request structures.

[Requirement to be validated:]{.underline}

-   inspection report update processing is invoked

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsg.cpp

[Input Data:]{.underline}

non EDI inspection report message

inspection report archive

[Expected Outcome:]{.underline}

iot_process_inspection report is invoked

[Test Procedure Steps:]{.underline}

-   invoke_IOT_translate_incoming_message to process inspection report
    update message

-   invoke IOT_get_transaction to initiate copying of message data to
    data structures

[Analysis Procedures:]{.underline}

-   using debugger, verify that iot_process_inspection_reports is called

**Unit Test Report**

[Unit ID:]{.underline} iot_fill_structures

[UTP ID:]{.underline} IOT_FILL_STRCT5

[Version Control ID:]{.underline} IOT V1.2.2

[Test Seq Number]{.underline}:

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

to verify that iot inspection report processing is invoked when an
inspection report message is received

[Actual Results:]{.underline}

iot_process_inspection_reports is called

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_fill_structures

[UTP ID:]{.underline} IOT_FILL_STRCT1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

Moves data extracted from an application text file generated from an
incoming message and stores it in transaction specific packet header,
update data, data header, request header, and request structures.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsg.cpp

[Input Data:]{.underline}

EDI carrier snapshot message

[Expected Outcome:]{.underline}

target data structures will contain data elements from application text
file generated from incoming EDI message

[Test Procedure Steps:]{.underline}

-   invoke_IOT_translate_incoming_message to process EDI carrier
    snapshot message with EDI translator

-   invoke IOT_get_transaction to initiate copying of message data to
    data structures

[Analysis Procedures:]{.underline}

-   using debugger, examine data elements in packet header, update data,
    data header, request header, and request structures and verify that
    they are correct

**Unit Test Report**

[Unit ID:]{.underline} iot_fill_structures

[UTP ID:]{.underline} IOT_FILL_STRCT1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}:

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that data from input EDI message is correctly stored in
internal data structures

[Actual Results:]{.underline}

packet header, data header, update data, request, request header contain
data from input message

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_fill_structures

[UTP ID:]{.underline} IOT_FILL_STRCT2

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

Moves data extracted from an application text file generated from an
incoming message and stores it in transaction specific packet header,
update data, data header, request header, and request structures.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsg.cpp

[Input Data:]{.underline}

EDI carrier snapshot query message

[Expected Outcome:]{.underline}

target data structures will contain data elements from application text
file generated from incoming EDI message

[Test Procedure Steps:]{.underline}

-   invoke_IOT_translate_incoming_message to process EDI carrier
    snapshot query message with EDI translator

-   invoke IOT_get_transaction to initiate copying of message data to
    data structures

[Analysis Procedures:]{.underline}

-   using debugger, examine data elements in packet header, update data,
    data header, request header, and request structures and verify that
    they are correct

**Unit Test Report**

[Unit ID:]{.underline} iot_fill_structures

[UTP ID:]{.underline} IOT_FILL_STRCT2

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}:

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that data from input EDI message is correctly stored in
internal data structures

[Actual Results:]{.underline}

packet header, data header, update data, request, request header contain
data from input message

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_fill_structures

[UTP ID:]{.underline} IOT_FILL_STRCT3

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

Moves data extracted from an application text file generated from an
incoming message and stores it in transaction specific packet header,
update data, data header, request header, and request structures.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsg.cpp

[Input Data:]{.underline}

EDI subscription request message

[Expected Outcome:]{.underline}

target data structures will contain data elements from application text
file generated from incoming EDI message

[Test Procedure Steps:]{.underline}

-   invoke_IOT_translate_incoming_message to process EDI subscription
    request message with EDI translator

-   invoke IOT_get_transaction to initiate copying of message data to
    data structures

[Analysis Procedures:]{.underline}

-   using debugger, examine data elements in packet header, update data,
    data header, request header, and request structures and verify that
    they are correct

**Unit Test Report**

[Unit ID:]{.underline} iot_fill_structures

[UTP ID:]{.underline} IOT_FILL_STRCT3

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}:

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that data from input EDI message is correctly stored in
internal data structures

[Actual Results:]{.underline}

packet header, data header, update data, request, request header contain
data from input message

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_fill_structures

[UTP ID:]{.underline} IOT_FILL_STRCT4

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

Moves data extracted from an application text file generated from an
incoming message and stores it in transaction specific packet header,
update data, data header, request header, and request structures.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsg.cpp

[Input Data:]{.underline}

EDI error response message

[Expected Outcome:]{.underline}

target data structures will contain data elements from application text
file generated from incoming EDI message

[Test Procedure Steps:]{.underline}

-   invoke_IOT_translate_incoming_message to process EDI error response
    message with EDI translator

-   invoke IOT_get_transaction to initiate copying of message data to
    data structures

[Analysis Procedures:]{.underline}

-   using debugger, examine data elements in packet header, update data,
    data header, request header, and request structures and verify that
    they are correct

**Unit Test Report**

[Unit ID:]{.underline} iot_fill_structures

[UTP ID:]{.underline} IOT_FILL_STRCT4

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}:

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that data from input EDI message is correctly stored in
internal data structures

[Actual Results:]{.underline}

packet header, data header, update data, request, request header contain
data from input message

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_is_field_in_view

[UTP ID:]{.underline} IOT_FLD_IN_VW1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

specifies whether the specified snapshot field is in the specified view.
The address of the snapshot, the address of the field, the view, and the
type of snapshot (entity) are specified.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcsnap.cpp

[Input Data:]{.underline}

carrier snapshot data, including a snapshot view

[Expected Outcome:]{.underline}

all fields in the snapshot are correctly identified as being included or
excluded from the specified view

[Test Procedure Steps:]{.underline}

-   fill internal data structures with snapshot data

-   generate non EDI carrier snapshot message
    (IOT_generate_outgoing_messsage)

[Analysis Procedures:]{.underline}

-   using the debugger, verify that all fields in the snapshot are
    correctly identified as being included or excluded from the
    specified view

**Unit Test Report**

[Unit ID:]{.underline} iot_is_field_in_view

[UTP ID:]{.underline} IOT_FLD_IN_VW1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that fields in snapshot data are correctly identified as being
included or not included in the specified view

[Actual Results:]{.underline}

snapshot data fields are correctly identified as included

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_finish_outgoing_message

[UTP ID:]{.underline} IOT_FNSH_MSG1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

invokes COTS EDI translator to generate outgoing EDI message from
application text file, and/or compress resulting outgoing EDI message
file.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: multicsnapout.cpp

[Input Data:]{.underline}

carrier snapshot, snapshot view

[Expected Outcome:]{.underline}

properly formatted EDI carrier snapshot message will be written to disk

[Test Procedure Steps:]{.underline}

-   invoke IOT_finish_outgoing_message

[Analysis Procedures:]{.underline}

-   examine resulting EDI message and verify that it is correct

**Unit Test Report**

[Unit ID:]{.underline} IOT_finish_outgoing_message

[UTP ID:]{.underline} IOT_FNSH_MSG1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a correct EDI snapshot update message is generated

[Actual Results:]{.underline}

a valid EDI carrier snapshot message is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_finish_outgoing_message

[UTP ID:]{.underline} IOT_FNSH_MSG2

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

invokes COTS EDI translator to generate outgoing EDI message from
application text file, and/or compress resulting outgoing EDI message
file.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcqry.cpp

[Input Data:]{.underline}

carrier snapshot query data

[Expected Outcome:]{.underline}

properly formatted EDI carrier snapshot query message will be written to
disk

[Test Procedure Steps:]{.underline}

-   invoke IOT_finish_outgoing_message

[Analysis Procedures:]{.underline}

-   examine resulting EDI message and verify that it is correct

**Unit Test Report**

[Unit ID:]{.underline} IOT_finish_outgoing_message

[UTP ID:]{.underline} IOT_FNSH_MSG2

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a correct EDI snapshot query message is generated

[Actual Results:]{.underline}

a valid EDI carrier snapshot query message is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_finish_outgoing_message

[UTP ID:]{.underline} IOT_FNSH_MSG3

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

invokes COTS EDI translator to generate outgoing EDI message from
application text file, and/or compress resulting outgoing EDI message
file.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outsubreq.cpp

[Input Data:]{.underline}

subscription request data in subscription_req data structure

[Expected Outcome:]{.underline}

properly formatted EDI subscription request message will be written to
disk

[Test Procedure Steps:]{.underline}

-   invoke IOT_finish_outgoing_message

[Analysis Procedures:]{.underline}

-   examine resulting EDI message and verify that it is correct

**Unit Test Report**

[Unit ID:]{.underline} IOT_finish_outgoing_message

[UTP ID:]{.underline} IOT_FNSH_MSG3

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a correct EDI subscription request message is generated

[Actual Results:]{.underline}

a valid EDI subscription request message is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_finish_outgoing_message

[UTP ID:]{.underline} IOT_FNSH_MSG4

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

invokes COTS EDI translator to generate outgoing EDI message from
application text file, and/or compress resulting outgoing EDI message
file.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcsnap.cpp

[Input Data:]{.underline}

carrier snapshot, snapshot view

[Expected Outcome:]{.underline}

a properly formatted compressed EDI carrier snapshot zip archive file
will be written to disk

[Test Procedure Steps:]{.underline}

-   invoke IOT_finish_outgoing_message

[Analysis Procedures:]{.underline}

-   decompress generated zip archive using WINZIP and verify that it is
    identical to uncompressed EDI message

**Unit Test Report**

[Unit ID:]{.underline} IOT_finish_outgoing_message

[UTP ID:]{.underline} IOT_FNSH_MSG4

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a correct compressed EDI snapshot message is generated

[Actual Results:]{.underline}

a valid compressed EDI carrier snapshot message is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_finish_outgoing_message

[UTP ID:]{.underline} IOT_FNSH_MSG5

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

invokes COTS EDI translator to generate outgoing EDI message from
application text file, and/or compress resulting outgoing EDI message
file.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcqry.cpp

[Input Data:]{.underline}

carrier snapshot query data: (query type, view, query parameters)

[Expected Outcome:]{.underline}

a properly formatted compressed EDI carrier snapshot query zip archive
file will be written to disk

[Test Procedure Steps:]{.underline}

-   invoke IOT_finish_outgoing_message

[Analysis Procedures:]{.underline}

-   decompress generated zip archive using WINZIP and verify that it is
    identical to the uncompressed EDI message

**Unit Test Report**

[Unit ID:]{.underline} IOT_finish_outgoing_message

[UTP ID:]{.underline} IOT_FNSH_MSG5

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a correct compressed EDI snapshot query message is
generated

[Actual Results:]{.underline}

a valid compressed EDI carrier snapshot query message is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_finish_outgoing_message

[UTP ID:]{.underline} IOT_FNSH_MSG6

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

invokes COTS EDI translator to generate outgoing EDI message from
application text file, and/or compress resulting outgoing EDI message
file.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outsubreq.cpp

[Input Data:]{.underline}

subscription request data : subscription request ID, subscription
events, subscription request process type, query number, query
parameters

[Expected Outcome:]{.underline}

a properly formatted compressed EDI subscription request zip archive
file will be written to disk

[Test Procedure Steps:]{.underline}

-   invoke IOT_finish_outgoing_message

[Analysis Procedures:]{.underline}

-   decompress generated zip archive using WINZIP and verify that it is
    identical to uncompressed EDI message

**Unit Test Report**

[Unit ID:]{.underline} IOT_finish_outgoing_message

[UTP ID:]{.underline} IOT_FNSH_MSG6

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a correct compressed EDI subscription request message is
generated

[Actual Results:]{.underline}

A valid compressed EDI subscription request message is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_finish_outgoing_message

[UTP ID:]{.underline} IOT_FNSH_MSG7

[Version Control ID:]{.underline} IOT V1.2.2

[Unit Function:]{.underline}

invokes COTS EDI translator to generate outgoing EDI message from
application text file, and/or compress resulting outgoing EDI message
file.

[Requirement to be validated:]{.underline}

-   build inspection report application text file

-   build inspection report archive containing extracted inspection
    report files and summary file

-   return path to inspection report archive and application text file

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: out_ir.cpp

[Input Data:]{.underline}

inspection report data

[Expected Outcome:]{.underline}

a zip archive containing the extracted inspection report file plus the
IOT generated summary file is generated. Iot_build_ir_app_file is called
to build the non EDI message file that identifies the inspection report
archive to the recipient IOT.

[Test Procedure Steps:]{.underline}

-   invoke IOT_finish_outgoing_message

[Analysis Procedures:]{.underline}

-   examine resulting zip archive file and verify that it is correct

-   verify that iot_build_IR_app_file is called with the appropriate
    arguments

**Unit Test Report**

[Unit ID:]{.underline} IOT_finish_outgoing_message

[UTP ID:]{.underline} IOT_FNSH_MSG7

[Version Control ID:]{.underline} IOT V1.2.2

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
8/27/97

[Purpose of Test:]{.underline}

to verify that a correct inspection report archive is generated

[Actual Results:]{.underline}

a zipped archive file containing the inspection report file and summary
file is generated. iot_build_IR_app_file is called to build the
inspection report message body file. The path to the zip archive and
message body file are returned to the caller

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_generate_carrier_snapshot_vrecords

[UTP ID:]{.underline} IOT_GEN_CSNAP1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

converts snapshot data in internal data structures to application text
file records and writes the records to the application text file

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcsnap.cpp

[Input Data:]{.underline}

Snapshot Data

Snapshot view

Message Format

Message Compression Type

[Expected Outcome:]{.underline}

CS1, TC2, C35, CFO, CSO, CP1, & CPJ carrier snapshot records are
generated

[Test Procedure Steps:]{.underline}

-   fill data structures with snapshot and other input data

-   call iot_generate_carrier_snapshot_vrecords

[Analysis Procedures:]{.underline}

-   verify generated records are correctly added to the application text
    file

**Unit Test Report**

[Unit ID:]{.underline} IOT_generate_carrier_snapshot_vrecords

[UTP ID:]{.underline} IOT_GEN_CSNAP1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that the appropriate application text file records
corresponding to a carrier snapshot are generated

[Actual Results:]{.underline}

T01, T02, CS1, TC2, C35, CFO, CSO, CP1, nad CPJ records are generated
from snapshot input data

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_generate_carrier_snapshot_vrecords

[UTP ID:]{.underline} IOT_GEN_CSNAP1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

converts snapshot data in internal data structures to application text
file records and writes the records to the application text file

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcsnap.cpp

[Input Data:]{.underline}

Snapshot Data

Snapshot view

Message Format

Message Compression Type

[Expected Outcome:]{.underline}

CS1, TC2, C35, CFO, CSO, CP1, & CPJ carrier snapshot records are
generated

[Test Procedure Steps:]{.underline}

-   fill data structures with snapshot and other input data

-   call iot_generate_carrier_snapshot_vrecords

[Analysis Procedures:]{.underline}

-   verify generated records are correctly added to the application text
    file

**Unit Test Report**

[Unit ID:]{.underline} IOT_generate_carrier_snapshot_vrecords

[UTP ID:]{.underline} IOT_GEN_CSNAP1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
5/7/97

[Purpose of Test:]{.underline}

to verify that the appropriate application text file records
corresponding to a carrier snapshot are generated

[Actual Results:]{.underline}

T01, T02, CS1, TC2, C35, CFO, CSO, CP1, and CPJ records

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_generate_error_message

[UTP ID:]{.underline} IOT_GEN_ERR_MSG1

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

builds an 824 EDI or non EDI error response compressed or uncompressed
message from error data contained in internal data structures

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: gen_err_msg.cpp

[Input Data:]{.underline}

non EDI query message with carrier ID not in carrier table

[Expected Outcome:]{.underline}

a correctly formatted EDI 824 error response message representing a NO
MATCH error will be generated

[Test Procedure Steps:]{.underline}

-   fill data structures with input data

-   call IOT_generate_error_message

[Analysis Procedures:]{.underline}

-   examine generated EDI error response message and verify that it is
    correct

**Unit Test Report**

[Unit ID:]{.underline} IOT_generate_error_message

[UTP ID:]{.underline} IOT_GEN_ERR_MSG1

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a correct "NO MATCH" non EDI error response message is
generated

[Actual Results:]{.underline}

a valid "NO MATCH" error response message is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} IOT_generate_error_message

[UTP ID:]{.underline} IOT_GEN_ERR_MSG2

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

builds an 824 EDI or non EDI error response compressed or uncompressed
message from error data contained in internal data structures

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsge.cpp

[Input Data:]{.underline}

non EDI query message with invalid query criteria

[Expected Outcome:]{.underline}

a correctly formatted zip archive containing a non EDI error response
message representing invalid query criteria will be generated

[Test Procedure Steps:]{.underline}

-   process query message

-   call IOT_generate_error_message with zip compression

[Analysis Procedures:]{.underline}

-   extract error response non EDI message using WINZIP and verify that
    it is correct

**Unit Test Report**

[Unit ID:]{.underline} IOT_generate_error_message

[UTP ID:]{.underline} IOT_GEN_ERR_MSG2

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
11/13/23

[Purpose of Test:]{.underline}

to verify that a correct "REJECT TRANSACTION" error response message is
generated

[Actual Results:]{.underline}

a valid "REJECT TRANSACTION" non EDI error response message is generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_get_query_parm_no

[UTP ID:]{.underline} IOT_GET_PARM_TXT3

[Version Control ID:]{.underline} IOT V1.1

[Unit Function:]{.underline}

converts internal SAFER_parm_no_t query parameter type value to EDI
query parameter type text.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcqry.cpp

[Input Data:]{.underline}

carried id number

[Expected Outcome:]{.underline}

correct query parameter type text code value is returned

[Test Procedure Steps:]{.underline}

-   fill internal data structures with query data

-   invoke IOT_output_transaction to get query parameter type text

[Analysis Procedures:]{.underline}

-   examine generated EDI query message file for correct query parameter
    text

**Unit Test Report**

[Unit ID:]{.underline} iot_get_query_parm_no

[UTP ID:]{.underline} IOT_GET_PARM_TXT3

[Version Control ID:]{.underline} IOT V1.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
5/15/97

[Purpose of Test:]{.underline}

to verify that the query parameter text code corresponding to a carrier
id number query parameter is generated

[Actual Results:]{.underline}

the query parameter text corresponding to a carrier ID number was
generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_get_query_parm_no

[UTP ID:]{.underline} IOT_GET_PARM_TXT4

[Version Control ID:]{.underline} IOT V1.2.1

[Unit Function:]{.underline}

converts internal SAFER_parm_no_t query parameter type value to EDI
query parameter type text.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcqry.cpp

[Input Data:]{.underline}

inspection report number

[Expected Outcome:]{.underline}

correct query parameter type text code value is returned

[Test Procedure Steps:]{.underline}

-   fill internal data structures with query data

-   invoke IOT_output_transaction to get query parameter type text

[Analysis Procedures:]{.underline}

-   examine generated EDI query message file for correct query parameter
    text

**Unit Test Report**

[Unit ID:]{.underline} iot_get_query_parm_no

[UTP ID:]{.underline} IOT_GET_PARM_TXT4

[Version Control ID:]{.underline} IOT V1.2.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
8/15/97

[Purpose of Test:]{.underline}

to verify that the query parameter text code corresponding to a
inspection report number query parameter is generated

[Actual Results:]{.underline}

the query parameter text corresponding to a carrier ID number was
generated

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_get_query_type_text

[UTP ID:]{.underline} IOT_GET_QRY_TXT5

[Version Control ID:]{.underline} IOT V1.2.1

[Unit Function:]{.underline}

converts internal SAFER_query_no_t query number to EDI query number code
value text

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: outcqry.cpp

[Input Data:]{.underline}

inspection report number

inspection report data type

EDI message format

[Expected Outcome:]{.underline}

correct query code text is returned

[Test Procedure Steps:]{.underline}

-   fill data structures with inspection report query data

-   generate EDI query message (IOT_generate_outgoing_message)

[Analysis Procedures:]{.underline}

-   examine generated EDI query message and verify that query code text
    value is correct

**Unit Test Report**

[Unit ID:]{.underline} iot_get_query_type_text

[UTP ID:]{.underline} IOT_GET_QRY_TXT5

[Version Control ID:]{.underline} IOT V1.2.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
8/20/97

[Purpose of Test:]{.underline}

to verify that the internal query type value corresponding to an
inspection report number query text code is returned

[Actual Results:]{.underline}

the query type value representing an inspection report number query text
value was produced

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_get_query_no

[UTP ID:]{.underline} IOT_GET_QRY5

[Version Control ID:]{.underline} IOT V1.2.2

[Unit Function:]{.underline}

converts EDI query number code value to internal SAFER_query_no_t
representation

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsg.cpp

[Input Data:]{.underline}

EDI inspection report number query message

[Expected Outcome:]{.underline}

correct query no is returned

[Test Procedure Steps:]{.underline}

-   translate EDI inspection report query message

-   convert query number via call to IOT_get_transaction

[Analysis Procedures:]{.underline}

-   using the debugger, verify that query number returned is correct

**Unit Test Report**

[Unit ID:]{.underline} iot_get_query_no

[UTP ID:]{.underline} IOT_GET_QRY5

[Version Control ID:]{.underline} IOT V1.2.2

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
8/20/97

[Purpose of Test:]{.underline}

to verify that the internal query type corresponding to an inspection
report number (Q300) query text code is produced

[Actual Results:]{.underline}

the query type value representing an inspection report number query text
code was returned

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_validate_data

[UTP ID:]{.underline} IOT_VAL_DTA15

[Version Control ID:]{.underline} IOT V1.2.1

[Unit Function:]{.underline}

Based on the specified data type, the routine determines if the value of
the data, represented by a character string, is valid. It calls the
appropriate function used to convert the associated type of data from
character string to internal representation to convert the data and
determine if its value is correct.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsg.cpp

[Input Data:]{.underline}

inspection report query EDI message with valid entity

[Expected Outcome:]{.underline}

valid internal entity value is returned

[Test Procedure Steps:]{.underline}

-   translate EDI message (IOT_translate_incoming_message)

-   extract entity from query transaction (IOT_get_transaction)

[Analysis Procedures:]{.underline}

-   using the debugger, verify that valid data value is returned

**Unit Test Report**

[Unit ID:]{.underline} iot_validate_data

[UTP ID:]{.underline} IOT_VAL_DTA15

[Version Control ID:]{.underline} IOT V1.2.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
8/21/97

[Purpose of Test:]{.underline}

to verify that the specified text string representing an entity is
converted to an internal entity value

[Actual Results:]{.underline}

the specified text is converted to a valid entity value

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_validate_data

[UTP ID:]{.underline} IOT_VAL_DTA16

[Version Control ID:]{.underline} IOT V1.2.1

[Unit Function:]{.underline}

Based on the specified data type, the routine determines if the value of
the data, represented s a character string, is valid. It calls the
appropriate function used to convert the associated type of data from
character string to internal representation to convert the data and
determine if its value is correct.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsg.cpp

[Input Data:]{.underline}

inspection report query EDI message with invalid query number

[Expected Outcome:]{.underline}

invalid query number data flag is returned

[Test Procedure Steps:]{.underline}

-   translate EDI message (IOT_translate_incoming_message)

-   extract query number from query transaction (IOT_get_transaction)

[Analysis Procedures:]{.underline}

-   using the debugger, verify that invalid data value is returned

**Unit Test Report**

[Unit ID:]{.underline} iot_validate_data

[UTP ID:]{.underline} IOT_VAL_DTA16

[Version Control ID:]{.underline} IOT V1.2.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
8/21/97

[Purpose of Test:]{.underline}

to verify that the specified text string representing an invalid query
number is converted to an invalid query indicator value

[Actual Results:]{.underline}

an invalid query number indicator is returned

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} iot_validate_data

[UTP ID:]{.underline} IOT_VAL_DTA17

[Version Control ID:]{.underline} IOT V1.2.1

[Unit Function:]{.underline}

Based on the specified data type, the routine determines if the value of
the data, represented s a character string, is valid. It calls the
appropriate function used to convert the associated type of data from
character string to internal representation to convert the data and
determine if its value is correct.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

Test Driver: incmsg.cpp

[Input Data:]{.underline}

inspection report query EDI message with valid query number

[Expected Outcome:]{.underline}

valid internal query number is returned

[Test Procedure Steps:]{.underline}

-   translate EDI message (IOT_translate_incoming_message)

-   extract query number from query transaction (IOT_get_transaction)

[Analysis Procedures:]{.underline}

-   using the debugger, verify that valid data value is returned

**Unit Test Report**

[Unit ID:]{.underline} iot_validate_data

[UTP ID:]{.underline} IOT_VAL_DTA17

[Version Control ID:]{.underline} IOT V1.2.1

[Test Seq Number]{.underline}: 1

[Test Conductor:]{.underline} R.H. Goldfarb [Test Date:]{.underline}
8/21/97

[Purpose of Test:]{.underline}

to verify that the specified text string representing an query number is
converted to an internal query value

[Actual Results:]{.underline}

the specified text is converted to a valid query number

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Appendix H - Unit Test (OMH)**

**Output Message Handler (OMH)**

**Unit Test Plans and Test Reports**

**Unit Test Plan**

[Unit ID:]{.underline} OMH_output_message_generator

[UTP ID:]{.underline} OMH_output_message_generator

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

OMH_output_message_generator calls the IOT to produce an EDI message
containing the snapshot given to it in the CVIEW data structures and
send it to the proper recipient's mailbox.

[Requirement to be validated:]{.underline}

-   OMH_output_message_generator correctly calls the IOT to translate
    the information contained in the CVIEW data structures into an EDI
    snapshot message.

-   OMH_output_message_generator correctly calls MBX_Send to forward the
    EDI snapshot to the recipient's mailbox.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage. The EudoraLite mail package was
used to send the email message to the CVIEW input mailbox. The Distinct
SMTP and POP mail protocol libraries, and associated MBX routines were
used to extract the message from the input mailbox into a temporary file
for further processing.

[Input Data:]{.underline}

A carrier snapshot request message in EDI format with a DOT number known
to exist in the database was used as input.

[Expected Outcome:]{.underline}

OMH_output_message_generator correctly calls the IOT to translate the
CVIEW data structures into an EDI carrier snapshot message.

OMH_output_message_generator correctly calls MBX to send the EDI
snapshot to the correct recipient's mailbox.

[Test Procedure Steps:]{.underline}

-   Start the CVIEW service in command line form so that the debugger
    can be used.

-   Set a breakpoint at the beginning of OMH_output_message_generator.

-   Send a carrier snapshot request message to the input mailbox.

-   Run to the breakpoint.

-   Check that the CVIEW data structures contain the correct information
    for the requested carrier.

-   Check that IOT successfully produces an EDI carrier snapshot output
    message from the information.

-   Check that MBX_Send give a success status on forwarding the message
    to the recipient's mailbox

-   Use EudoraLite to actually read the EDI carrier snapshot from the
    recipient's mailbox.

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} OMH_output_message_generator

[UTP ID:]{.underline} OMH_output_message_generator

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that OMH_output_message_generator properly calls IOT to
produce a carrier snapshot message and properly calls MBX to send that
message to the recipient.

[Actual Results:]{.underline}

-   OMH_output_message_generator utilized IOT to translate the
    information contained in the CVIEW data structures into an EDI
    carrier snapshot output message.

-   OMH_output_message_generator utilized MBX to send the message to the
    recipient's mailbox.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} OMH_send_error_message

[UTP ID:]{.underline} OMH_send_error_message

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

OMH_send_error_message calls the IOT to produce an error message and
calls MBX to send it to the proper recipient's mailbox.

[Requirement to be validated:]{.underline}

-   OMH_send_error_message correctly calls the IOT to produce an error
    message.

-   OMH_send_error_message correctly calls MBX_Send to forward the error
    message to the recipient's mailbox.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage. The EudoraLite mail package was
used to send the email message to the CVIEW input mailbox. The Distinct
SMTP and POP mail protocol libraries, and associated MBX routines were
used to extract the message from the input mailbox into a temporary file
for further processing.

[Input Data:]{.underline}

A carrier snapshot request message in EDI format with an invalid DOT
number known NOT to exist in the database was used as input.

[Expected Outcome:]{.underline}

OMH_send_error_message correctly calls the IOT to produce an error
message.

OMH_send_error_message correctly calls MBX to send the error message to
the correct recipient's mailbox.

[Test Procedure Steps:]{.underline}

-   Start the CVIEW service in command line form so that the debugger
    can be used.

-   Set a breakpoint at the beginning of OMH_send_error_message.

-   Send a carrier snapshot request message with a nonexistent DOT
    number to the input mailbox.

-   Run to the breakpoint.

-   Check that IOT successfully produces an error message from the
    information.

-   Check that MBX_Send give a success status on forwarding the message
    to the recipient's mailbox

-   Use EudoraLite to actually read the error from the recipient's
    mailbox.

[Analysis Procedures:]{.underline}

**Unit Test Report**

[Unit ID:]{.underline} OMH_send_error_message

[UTP ID:]{.underline} OMH_send_error_message

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that OMH_send_error_message properly calls IOT to produce a
carrier snapshot message and properly calls MBX to send that message to
the recipient.

[Actual Results:]{.underline}

-   OMH_send_error_message utilized IOT to create an error message.

-   OMH_send_error_message utilized MBX to send the message to the
    recipient's mailbox.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Appendix I - Unit Test (SDB)**

**CVIEW Database (SDB) Library**

**Unit Test Plans and Test Reports**

**Unit Test Plan**

[Unit ID:]{.underline} sdb_get_available_sub_id

[UTP ID:]{.underline} SDB_GET_AVAILABLE_SUB_ID01

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function reads through the subscription table in the database and
returns the highest existing sub_id + 1

[Requirement to be validated:]{.underline}

-   3.1.4.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

none

[Expected Outcome:]{.underline}

The next available subscription_id

[Test Procedure Steps:]{.underline}

-   Query the database for the highest sub_id ( select subscription_id
    from subscription)

-   Call function and check answer against a manual sql query

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} sdb_get_available_sub_id

[UTP ID:]{.underline} SDB_GET_AVAILABLE_SUB_ID01

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/6/96

[Purpose of Test:]{.underline}

To verify that the function executes as planned.

[Actual Results:]{.underline}

-   Manual query showed 6 to be the highest sub_id function returned 7
    (ok)

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} sdb_get_subscription

[UTP ID:]{.underline} SDB_GET_SUBSCRIPTION

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function selects a subscription record from the database given an
intger value. It then puts that subscription record into a C data
structure and returns that structure.

[Requirement to be validated:]{.underline}

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

An integer value

[Expected Outcome:]{.underline}

A C data structure for a subscription with id =input found in the
database

[Test Procedure Steps:]{.underline}

-   Call function with existing subscription id

-   Call function with negative subscription id

-   Call function with 0 subscription id

-   Call function with non-existent positive subscription id

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} sdb_get_subscription

[UTP ID:]{.underline} SDB_GET_SUBSCRIPTION

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/5/96

[Purpose of Test:]{.underline}

The verify that the function executes as expected given valid and
invalid input.

[Actual Results:]{.underline}

-   Returned correct subscription

-   Returned subscription with id = 0 (correct action)

-   Returned subscription with id = 0 (correct action)

Returned subscription with id = 0 (correct action)

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} sdb_get_sub_id_list

[UTP ID:]{.underline} SDB_GET_SUB_ID_LIST01

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function reads all subscription ids found in the subscription table
and returns a linked list of those ids.

[Requirement to be validated:]{.underline}

-   3.1.4.2

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

none

[Expected Outcome:]{.underline}

Correct list of subscription ids

[Test Procedure Steps:]{.underline}

-   Use sqlplus to select list of subscription ids (select
    subscription_id from subscription)

-   Compare sql list to the list created and returned by
    sdb_get_sub_id_list

[Analysis Procedures:]{.underline}

**Unit Test Report**

[Unit ID:]{.underline} sdb_get_sub_id_list

[UTP ID:]{.underline} SDB_GET_SUB_ID_LIST01

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton T[est Date:]{.underline}
8/5/96

[Purpose of Test:]{.underline}

To verify that the list of ids returned matches the list produced by a
sql select command

[Actual Results:]{.underline}

function returns the correct list

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} sdb_insert_new_subscription

[UTP ID:]{.underline} SDB_INSERT_NEW_SUBSCRIPTION01

[Version Control ID:]{.underline} SAIC V01-B01

[Unit Function:]{.underline}

This function adds a new subscription to the subscription database table
and returns SLP_OK upon success.

[Requirement to be validated:]{.underline}

-   3.1.4.1

[Test Tools, Drivers, or Special Conditions:]{.underline}

[Input Data:]{.underline}

a new subscription ( C data structure )

[Expected Outcome:]{.underline}

an enumerated value indicating success or failure

[Test Procedure Steps:]{.underline}

-   Call function with a subscription

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} sdb_insert_new_subscription

[UTP ID:]{.underline} SDB_INSERT_NEW_SUBSCRIPTION01

[Version Control ID:]{.underline} SAIC V01-B01 [Test Seq
Number]{.underline}: 01

[Test Conductor:]{.underline} Curt Stapleton [Test Date:]{.underline}
8/6/96

[Purpose of Test:]{.underline}

To verify that the function executes as planned

[Actual Results:]{.underline}

The function inserted the subscription as planned

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Appendix J - Unit Test (SDM)**

**CVIEW Data Manager (SDM)**

**Unit Test Plans and Test Reports**

**Unit Test Plan**

[Unit ID:]{.underline} SDM_add_snap_record

[UTP ID:]{.underline} SDM_add_snap_record

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine is called when a carrier snapshot update is being
processed. It determines whether the update is a full snapshot update or
a MCMIS update and calls the appropriate database function.

[Requirement to be validated:]{.underline}

-   SDM_add_snap_record will determine type of database update, either
    FULL or MCMIS.

-   SDM_add_snap_record will call an appropriate database function to
    perform the update.

-   

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage.

The SQLPlus utility was used to verify that the database update was
performed. A mail send utility was used to send FULL updates to the
input mailbox because their line length is too long for the EudoraLite
package. EudoraLite was used to send a MCMIS file update message to the
input mailbox.

[Input Data:]{.underline}

Mail messages containing full carrier snapshots were used to test the
FULL update. A test MCMIS file and a MCMIS file update message were used
to test the MCMIS update.

[Expected Outcome:]{.underline}

A full snapshot will have the view set to SAFER_FULL_VIEW and will be
successfully written to the database using SDB_Update_Carrier_FULL.

A MCMIS snapshot will have the view set to SAFER\_ MCMIS \_VIEW and will
be successfully written to the database using SDB_Update_Carrier\_ MCMIS
.

[Test Procedure Steps:]{.underline}

-   Start the CVIEW service in command line form so that the debugger
    can be used.

-   Send a valid full carrier snapshot and a valid MCMIS file update
    message to the input mailbox.

-   Set a break point at SDM_add_snap_record and step through the
    routine to verify that the view is set correctly for each record and
    that the correct database function is called.

-   Also verify that the database functions return success code.

-   Use SQLPlus to verify that the database was updated.

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} SDM_add_snap_record

[UTP ID:]{.underline} SDM_add_snap_record

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that SDM_add_snap_record correctly updates the database for
FULL or MCMIS carrier snapshot views.

[Actual Results:]{.underline}

-   A full carrier snapshot had view set to FULL in the CVIEW data
    structure. The SDB_Update_Carrier_FULL function was successfully
    called to write it to the database.

-   A MCMIS carrier snapshot had view set to MCMIS in the CVIEW data
    structure. The SDB_Update_Carrier\_ MCMIS function was successfully
    called to write it to the database.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} SDM_convert_mcmis_snap

[UTP ID:]{.underline} SDM_convert_mcmis_snap

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine is used to convert each record read in from a MCMIS update
file into the format required by the database.

[Requirement to be validated:]{.underline}

-   SDM_convert_mcmis_snap reliably converts record input from a MCMIS
    file into the CVIEW data structure cs_v1_t in the form required by
    the database.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage. A test MCMIS file was used and a
MCMIS file update message was sent using the EudoraLite package.

[Input Data:]{.underline}

A test file containing MCMIS format data was used. A MCMIS file update
message in EudoraLite format was used.

[Expected Outcome:]{.underline}

The MCMIS record will be converted into the format needed by the
database.

[Test Procedure Steps:]{.underline}

-   Start the CVIEW service in command line form so that the debugger
    can be used.

-   Send a MCMIS file update message to the input mailbox.

-   Set a break point at the beginning of SDM_convert_mcmis_snap. On
    arrival there, check that the input cs_v1_t structure contains a
    carrier snapshot in MCMIS format.

-   Step through to check that the following modifications are made to
    the input snapshot

-   Leading zeroes are trimmed from CARRIER_ID_NUMBER.

-   If ISSUING_AUTHORITY equals "00" it is converted to a NULL.

-   If TERMINAL_ID equals "00" it is converted to a NULL.

-   If any of the three ICC numbers equal zero, it is converted to a
    NULL.

-   If any of the three ICC numbers have leading zeroes, they are
    removed.

-   Leading zeroes are removed from STATE_CARRIER_ID.

-   Other fields containing blanks are converted to NULL.

-   Other fields containing zero are converted to NULL.

-   Leading zeroes are trimmed from all other fields.

-   Convert date fields containing all zeroes to all blanks.

**Unit Test Report**

[Unit ID:]{.underline} SDM_convert_mcmis_snap

[UTP ID:]{.underline} SDM_convert_mcmis_snap

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that SDM_convert_mcmis_snap correctly modifies a CVIEW carrier
snapshot in a cs_v1_t data structure so that it will be written to the
database in the desired format.

[Actual Results:]{.underline}

-   A MCMIS record stored in a cs_v1_t structure was modified to have
    each field conform to the desired database format.

-   The modified record was correctly written to the database in the
    course of subsequent processing.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} SDM_initialize

[UTP ID:]{.underline} SDM_initialize

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine initializes the CVIS file pointer and saves the section
name from the WIN.INI file for future use during MCMIS processing.

[Requirement to be validated:]{.underline}

-   SDM_initialize sets the CVIS file pointer to NULL and saves the
    section name of the WIN.INI file.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage.

[Input Data:]{.underline}

None, except for the WIN.INI file.

[Expected Outcome:]{.underline}

SDM_initialize will set the CVIS file pointer to NULL and will correctly
save the section name used to access the WIN.INI file..

[Test Procedure Steps:]{.underline}

-   Start the CVIEW service in command line form so that the debugger
    can be used.

-   Set a breakpoint at the beginning of SDM_initialize.

-   Step through to check that the CVIS file pointer is set to NULL.

-   Check also that the section name used to access WIN.INI is saved in
    a global string.

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} SDM_initialize

[UTP ID:]{.underline} SDM_initialize

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that SDM_initialize sets the CVIS file pointer to NULL and
saves the name of the section used within WIN.INI in a global variable
for later use by SDM routines performing MCMIS processing.

[Actual Results:]{.underline}

-   SDM_initialize correctly set the CVIS file pointer to NULL.

-   SDM_initialize correctly saved the section name used to access the
    WIN.INI file.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} SDM_is_changed_CVIS_snap

[UTP ID:]{.underline} SDM_is_changed_CVIS_snap

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine compares each CVIS field in a new and old carrier snapshot
to determine whether or not to write the record to the CVIS file. The
old carrier snapshot is retrieved from the database, while the new one
comes in through a MCMIS file update.

[Requirement to be validated:]{.underline}

-   If one or more of the CVIS fields differ between the new and old
    carrier snapshot, SDM_is_changed_CVIS_snap returns TRUE, otherwise
    FALSE.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage. A test MCMIS file was used and a
MCMIS file update message was sent using the EudoraLite package.

[Input Data:]{.underline}

A test file containing MCMIS format data was used. A MCMIS file update
message in EudoraLite format was used.

[Expected Outcome:]{.underline}

If any CVIS fields have changed, the routine returns TRUE. If all CVIS
fields are the same in the record retrieved from the database and the
record derived from the MCMIS input file, the routine returns FALSE.

[Test Procedure Steps:]{.underline}

-   Start the CVIEW service in command line form so that the debugger
    can be used.

-   Send a MCMIS file update message to the input mailbox. Use a MCMIS
    file that has just been used to update the database so that there
    will be no changes unless changes are artificially inserted.

-   Set a break point at the beginning of SDM_is_changed_CVIS_snap.

-   Look for differences in the fields using the debugger. There should
    be none.

-   Step through a record without changes to insure that the routine
    returns FALSE.

-   On the next record, manually change some fields within the debugger.
    Choose obvious fields such as CARRIER_NAME.

-   Step through a record with changes to insure that the routine
    returns TRUE.

[Analysis Procedures:]{.underline}

**Unit Test Report**

[Unit ID:]{.underline} SDM_is_changed_CVIS_snap

[UTP ID:]{.underline} SDM_is_changed_CVIS_snap

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that SDM_is_changed_CVIS_snap returns TRUE if there are
changes to CVIS fields and FALSE if there are no changes.

[Actual Results:]{.underline}

-   A MCMIS record identical to that from the database caused
    SDM_is_changed_CVIS_snap to return FALSE.

-   A MCMIS record artificially altered to have CVIS fields differing
    from those in the database caused SDM_is_changed_CVIS_snap to return
    TRUE.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} SDM_is_null_snap

[UTP ID:]{.underline} SDM_is_null_snap

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine checks a pointer to a cs_v1_t carrier snapshot structure.
It returns TRUE if the pointer is NULL and FALSE if it is not.

[Requirement to be validated:]{.underline}

-   If the pointer to the carrier snapshot is NULL, SDM_is_null_snap
    returns TRUE, otherwise FALSE.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage. A test MCMIS file was used and a
MCMIS file update message was sent using the EudoraLite package.

[Input Data:]{.underline}

A test file containing MCMIS format data was used. A MCMIS file update
message in EudoraLite format was used.

[Expected Outcome:]{.underline}

If the pointer is NULL, the routine returns TRUE, and otherwise returns
FALSE.

[Test Procedure Steps:]{.underline}

-   Start the CVIEW service in command line form so that the debugger
    can be used.

-   Send a MCMIS file update message to the input mailbox. Use a MCMIS
    file that has just been used to update the database so that there
    will be no changes unless changes are artificially inserted.

-   Set a break point before the call to SDM_is_null_snap.

-   Set pointer to NULL if it is not. Step through to insure that
    SDM_is_null_snap returns FALSE..

-   Step through with a non-NULL pointer

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} SDM_is_null_snap

[UTP ID:]{.underline} SDM_is_null_snap

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that SDM_is_null_snap returns TRUE if called with a NULL
pointer as an argument and FALSE otherwise.

[Actual Results:]{.underline}

-   A NULL pointer resulted in a TRUE status being returned by
    SDM_is_null_snap.

-   A non-NULL pointer resulted in a FALSE status being returned by
    SDM_is_null_snap.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} SDM_process_exact_match

[UTP ID:]{.underline} SDM_process_exact_match

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine is called when a carrier snapshot request is received and
when a carrier snapshot update results in a subscription being
fulfilled. SDM_process_exact_match calls a database function to attempt
the retrieval. If successful, SDM_process_exact_match calls OMH to send
the carrier snapshot to the requester or subscriber. If unsuccessful,
SDM_process_exact_match calls OMH to send an error message to the
requester.

[Requirement to be validated:]{.underline}

-   SDM_process_exact_match will receive a snapshot request for a DOT or
    ICC number.

-   SDM_process_exact_match will call the database function to perform
    the retrieval.

-   SDM_process_exact_match will call OMH to send either a valid
    snapshot or an error message to the requester.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage.

The EudoraLite mail package was used to view the carrier snapshot or
error message in the requester's mailbox.

[Input Data:]{.underline}

Carrier snapshot requests containing valid DOT numbers, ICC numbers, and
nonexistent DOT or ICC numbers were sent to the input mailbox.
Processing occurring before calling SDM_process_exact_match stored the
information contained in these messages in the CVIEW data structures for
use by this routine.

[Expected Outcome:]{.underline}

Valid DOT or ICC numbers in the request will result in the carrier
snapshot being sent to the requester's mailbox..

Invalid DOT or ICC numbers, including blanks, will result in an error
message being sent to the requester's mailbox.

[Test Procedure Steps:]{.underline}

-   Start the CVIEW service in command line form so that the debugger
    can be used.

-   Send a number of valid and invalid DOT and ICC number requests to
    the CVIEW input mailbox.

-   Step through the SDM_process_exact_match routine.

-   On completion, check the requester's mailbox to verify that the
    snapshot or the error message was received.

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} SDM_process_exact_match

[UTP ID:]{.underline} SDM_process_exact_match

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that SDM_process_exact_match correctly sends carrier snapshots
to the requester for valid DOT or ICC number requests, and sends an
error message for invalid or nonexistent requests.

[Actual Results:]{.underline}

-   Valid DOT number requests resulted in a carrier snapshot being sent
    to the requester's mailbox.

-   Valid ICC number requests resulted in a carrier snapshot being sent
    to the requester's mailbox.

-   Invalid or nonexistent DOT and ICC number requests resulted in an
    error message being sent to the requester's mailbox.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} SDM_retrieve_safety_data

[UTP ID:]{.underline} SDM_retrieve_safety_data

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine receives an carrier snapshot request and routes it for
processing by simply calling SDM_process_exact_match.

[Requirement to be validated:]{.underline}

-   SDM_retrieve_safety_data calls SDM_process_exact_match with the
    correct CVIEW data structures, properly filled in.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage. A test MCMIS file was used and a
MCMIS file update message was sent using the EudoraLite package.

[Input Data:]{.underline}

A carrier snapshot request in DOT number format was used.

[Expected Outcome:]{.underline}

SDM_retrieve_safety_data will correctly call SDM_process_exact_match and
result in a carrier snapshot retrieval.

[Test Procedure Steps:]{.underline}

-   Start the CVIEW service in command line form so that the debugger
    can be used.

-   Set a breakpoint at the beginning of SDM_retrieve_safety_data.

-   Send a carrier snapshot request message with a valid DOT number.

-   Run to the breakpoint. Check that the request structure contains a
    valid snapshot request.

-   Step through and insure that SDM_process_exact_match gives a
    successful status code and returns a carrier snapshot in the update
    structure.

-   Check the requester's mailbox to be sure that the request was sent
    out.

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} SDM_retrieve_safety_data

[UTP ID:]{.underline} SDM_retrieve_safety_data

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that SDM_retrieve_safety_data results in a carrier snapshot
being retrieved and sent out.

[Actual Results:]{.underline}

-   SDM_retrieve_safety_data correctly called SDM_process_exact_match .

-   The requested snapshot was retrieved and sent to the requester's
    mailbox.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} SDM_setup_mcmis_processing

[UTP ID:]{.underline} SDM_setup_mcmis_processing

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine opens the CVIS file and the MCMIS log file during MCMIS
processing and stores the file pointers in global variables.

[Requirement to be validated:]{.underline}

-   SDM_setup_mcmis_processing creates files with unique names for the
    CVIS and MCMIS log files.

-   SDM_setup_mcmis_processing opens the files and stores the file
    pointers in globals for access by other SDM routines.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage. A test MCMIS file was used and a
MCMIS file update message was sent using the EudoraLite package.

[Input Data:]{.underline}

A test MCMIS file was used.

[Expected Outcome:]{.underline}

SDM_setup_mcmis_processing will open the CVIS and MCMIS files and store
the file pointers in globals.

[Test Procedure Steps:]{.underline}

-   Start the CVIEW service in command line form so that the debugger
    can be used.

-   Set a breakpoint at the beginning of SDM_setup_mcmis_processing.

-   Send a MCMIS file update message to the input mailbox.

-   Run to the breakpoint. Check that the CVIS and MCMIS files are
    created, with unique name.

-   Check that the file pointers are stored in globals.

-   Continue processing without stepping through to insure that data are
    written to both files.

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} SDM_setup_mcmis_processing

[UTP ID:]{.underline} SDM_setup_mcmis_processing

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that SDM_setup_mcmis_processing properly initializes the CVIS
and MCMIS log files.

[Actual Results:]{.underline}

-   SDM_setup_mcmis_processing opened a CVIS and a MCMIS log file with
    unique names

-   The file pointers were stored in globals and subsequent SDM
    processing was able to access them and write data to both files .

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} SDM_snap_data_manager

[UTP ID:]{.underline} SDM_snap_data_manager

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine handles carrier snapshot updates whether they originate
from a MCMIS update or from individual update records coming in through
a mailbox.

[Requirement to be validated:]{.underline}

-   SDM_snap_data_manager correctly handles a MCMIS update record-
    determines whether it should be written to the CVIS file, writes the
    CVIS file, updates the database, and calls SLP to fulfill any
    existing subscriptions.

-   SDM_snap_data_manager handles a snapshot update read in from a
    mailbox including a subscription timer mailbox. It updates the
    database and calls SLP to fulfill any existing subscriptions..

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage. A test MCMIS file was used and a
MCMIS file update message was sent using the EudoraLite package.
Individual snapshot updates in application file format and EDI format
were generated and placed in a subscription timer mailbox and into the
CVIEW input mailbox.

[Input Data:]{.underline}

A test MCMIS file was used. Individual snapshots in application file
format and EDI format were obtained by sending requests to the CVIEW
service and saving the returned snapshots.

[Expected Outcome:]{.underline}

SDM_snap_data_manager correctly handled a MCMIS update. It updated the
database, wrote all records with changes to CVIS fields to the CVIS
file, and fulfilled subscriptions.

SDM_snap_data_manager correctly handled individual snapshot update. It
updated the database, and fulfilled subscriptions. It did this whether
the snapshots came in through the CVIEW input mailbox or a subscription
timer mailbox. It did this for both EDI format and application file
format snapshots.

[Test Procedure Steps:]{.underline}

-   Start the CVIEW service in command line form so that the debugger
    can be used.

-   Set a breakpoint at the beginning of SDM_snap_data_manager.

-   Send a MCMIS file update message to the input mailbox.

-   Run to the breakpoint.

-   Check that the database is updated and that subscriptions are
    fulfilled.

-   Continue running without stepping to insure that data processing
    completes.

-   Stop the CVIEW service.

-   Load snapshots in EDI and/or application file format into a mailbox
    that can be used as a subscription timer mailbox.

-   Send snapshots in EDI and/or application file format to the CVIEW
    input mailbox.

-   Set up some test subscribers for these records in the
    subscriber_parms table.

-   Step through and check that the database is updated.

-   Check the subscribers' mailboxes to be sure that subscriptions are
    fulfilled.

[Analysis Procedures:]{.underline}

-   Following a MCMIS, subscriber mailboxes were thoroughly checked to
    prove that each record in the update that was contained in their
    subscriptions was actually sent to them. A SQL script was used to
    retrieve a list of DOT numbers contained in the update and also in
    the subscriber_parms list for each given subscriber. The mailboxes
    for three subscribers were then manually checked.

**Unit Test Report**

[Unit ID:]{.underline} SDM_snap_data_manager

[UTP ID:]{.underline} SDM_snap_data_manager

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that SDM_snap_data_manager properly processes MCMIS update
records and other carrier snapshot updates.

[Actual Results:]{.underline}

-   SDM_snap_data_manager wrote MCMIS records to the CVIS file if any
    CVIS fields had changed.

-   SDM_snap_data_manager wrote MCMIS records to the database and sent
    copies to all subscribers' mailboxes.

-   SDM_snap_data_manager updated the database with carrier snapshots
    received through subscription timer mailboxes and through the CVIEW
    input mailbox. It sent copies to all subscribers in this case also.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} SDM_update_safety_data

[UTP ID:]{.underline} SDM_update_safety_data

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

This routine calls SDM_update_safety_data to process MCMIS snapshot
updates as well as individual snapshot updates..

[Requirement to be validated:]{.underline}

-   SDM_update_safety_data correctly calls SDM_snap_data_manager with
    the needed CVIEW data structures to process a MCMIS snapshot update.

-   SDM_update_safety_data correctly calls SDM_snap_data_manager with
    the needed CVIEW data structures to process individual snapshot
    updates received from mailboxes.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage. A test MCMIS file was used and a
MCMIS file update message was sent using the EudoraLite package.
Individual snapshot updates in application file format and EDI format
were generated and placed in a subscription timer mailbox and into the
CVIEW input mailbox.

[Input Data:]{.underline}

A test MCMIS file was used. Individual snapshots in application file
format and EDI format were obtained by sending requests to the CVIEW
service and saving the returned snapshots.

[Expected Outcome:]{.underline}

SDM_update_safety_data correctly handled a MCMIS update..

SDM_update_safety_data correctly handled individual snapshot update.

[Test Procedure Steps:]{.underline}

-   Start the CVIEW service in command line form so that the debugger
    can be used.

-   Set a breakpoint at the beginning of SDM_update_safety_data.

-   Send a MCMIS file update message to the input mailbox.

-   Run to the breakpoint.

-   Check that SDM_snap_data_manager is called with the CVIEW data
    structures properly filled in.

-   Stop the CVIEW service.

-   Load snapshots in EDI and/or application file format into a mailbox
    that can be used as a subscription timer mailbox.

-   Send snapshots in EDI and/or application file format to the CVIEW
    input mailbox.

-   Step through and check that the database is updated.

-   Check that SDM_snap_data_manager is called with the CVIEW data
    structures properly filled in.

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} SDM_update_safety_data

[UTP ID:]{.underline} SDM_update_safety_data

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that SDM_update_safety_data properly processes MCMIS update
records and other carrier snapshot updates by calling
SDM_snap_data_manager.

[Actual Results:]{.underline}

-   SDM_update_safety_data correctly called SDM_snap_data_manager to
    process a MCMIS record.

-   SDM_update_safety_data correctly called SDM_snap_data_manager to
    process carrier snapshots received from the CVIEW input mailbox and
    from subscription timer mailboxes.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Unit Test Plan**

[Unit ID:]{.underline} SDM_write_cvis_record

[UTP ID:]{.underline} SDM_write_cvis_record

[Version Control ID:]{.underline} APL V01-B04

[Unit Function:]{.underline}

SDM_write_cvis_record writes each CVIS field in a MCMIS snapshot update
to the CVIS file.

[Requirement to be validated:]{.underline}

-   SDM_write_cvis_record writes every CVIS field in the MCMIS snapshot
    to the CVIS file with the correct field length and record length.

[Test Tools, Drivers, or Special Conditions:]{.underline}

The Visual C++ debugger was used as a test tool to step through the
routine and view data at each stage. A test MCMIS file was used and a
MCMIS file update message was sent using the EudoraLite package.

[Input Data:]{.underline}

A test MCMIS file and MCMIS update message were used.

[Expected Outcome:]{.underline}

SDM_write_cvis_record correctly wrote the CVIS fields of a MCMIS record
to the CVIS file.

Field lengths and record length were correct.

[Test Procedure Steps:]{.underline}

-   Start the CVIEW service in command line form so that the debugger
    can be used.

-   Set a breakpoint at the beginning of SDM_write_cvis_record.

-   Send a MCMIS file update message to the input mailbox.

-   Run to the breakpoint.

-   Check that each field is written.

-   Compare field and line lengths with those of a CVIS file known to be
    correct

[Analysis Procedures:]{.underline}

-   

**Unit Test Report**

[Unit ID:]{.underline} SDM_write_cvis_record

[UTP ID:]{.underline} SDM_write_cvis_record

[Version Control ID:]{.underline} APL V01-B04 [Test Seq
Number]{.underline}: 1

[Test Conductor:]{.underline} Grace McGonnigal [Test Date:]{.underline}
4/15/97

[Purpose of Test:]{.underline}

To insure that SDM_write_cvis_record properly writes CVIS records to the
CVIS file.

[Actual Results:]{.underline}

-   SDM_write_cvis_record correctly wrote all CVIS fields in a MCMIS
    record to the CVIS file.

-   All field lengths and record length were correct and were equal to
    those in a CVIS file known to be correct.

Reviewed By (SAIC): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approved By (JHU/APL): \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_