Unit Testing Phase:

Requirements Based Test Coverage Analysis :

This is done to verify whether the implementation matches the requirements and only the requirements.
Software requirements should contain a finite list of behaviors and features, and each requirement should be
written to be verifiable. Testing based on requirements is appealing because it is done from the perspective of
the user (thus providing a demonstration of intended function), and allows for development of test plans and
cases concurrently with development of the requirements. Given a finite list of requirements and a set of
completion criteria, requirements-based testing becomes a feasible process, unlike exhaustive testing.
The software verification test cases are to be created based on the software requirements specification. The first
step is to develop functional and robustness tests to completely test and verify the implementation of the
software requirements. The second step is to measure coverage (functional and structural). The measure of
structural coverage will help provide an indication of the software verification campaign completion status. The
tests stop criteria is not limited to a specific step but rather applied for all tests. For example, some high level
requirements can be covered by integration tests, i.e., structural coverage are measured on all tests levels.

The objectives of Requirements Based Testing are as follows:

1. At least one test case should be associated with each software requirement.
2. The test cases should satisfy the criteria for normal and abnormal range of inputs.

The objective of this analysis is to determine how well the requirements-based testing verified the
implementation of the software requirements. This analysis may reveal the need for additional requirementsbased
test cases. The requirements-based test coverage analysis should show that:

• Test cases exist for each software requirement.
• Test cases satisfy the criteria of normal and robustness testing

Requirements-based tests are subdivided into two categories:

• Normal Range Tests.
• Robustness Tests.

Robustness or Abnormal Tests :

The objective of robustness test cases is to demonstrate the ability of the software to respond to abnormal inputs
and conditions. This is done to verify robustness of the code under test. In robustness testing, the tester should
verify the behavior of the module under test when subjected to abnormal operational values. Robustness test
cases enable visibility of how the software responds to a range of abnormal inputs and conditions. Robustness
tests will be incorporated into functional tests if specifications exist for handling invalid input data. The Software
Design Standard [SDS] should mandatory require that handling of invalid input data be specified in the Software
Design Document [SDD].

Robustness test cases include:

• Exercise real and integer inputs using equivalence class of invalid boundary values.
• System initialization exercised with abnormal conditions.
• Determine the possible failure modes of incoming data especially complex, digital data strings from an
  external system.
• Compute out of range loop counts as appropriate.
• Check for arithmetic overflow for time related functions.
• Exercise transitions that are not allowed by the software requirements for state transitions.

Normal Range Tests :

The objective of normal range test cases is to demonstrate the ability of the software to respond to normal inputs
and conditions. Normal range test cases enable visibility of how the software responds to a range of normal
inputs and conditions. Normal range test cases include:

• Real and integer input variables should be exercised using valid equivalence classes and valid boundary
  values.
•  For time-related functions, such as filters, integrators and delays, multiple iterations of the code should be
  performed to check the characteristics of the function in context.
• For state transitions, test cases should be developed to exercise the transitions possible during normal
  operation.
• For software requirements expressed by logic equations, the normal range test cases should verify the
  variable usage and the Boolean operators.

The following sub-categories of tests are defined to achieve the above mentioned objectives:

• Arithmetic Tests.
• Singular Point Tests.
• Boundary Value Analysis Tests.
• In this type of testing tester should ensure each function entry and exit is encountered at least once and with the
  inputs subjected to normal operational values. Nodes are mathematical operations (+, -, *, /) within both control
  flow and signal flow diagrams.
• Floating-point nodes shall be tested to show that the operations are performed correctly.
• Integer or fixed-point nodes shall be stressed to a minimum and a maximum value.
  – Integer counters are a special case. If they are incremented only within a single unit and they
  are limited, they need only be tested at the limits. If they are incremented in multiple units they
  shall be tested at -32768 and 32767.
• The following restrictions shall be applied:
  – Addition and Subtraction: A test case must exist where all inputs are not 0.0
  – Multiplication: A test must exist where all inputs are not 1.0
  – Division: A test case must exist where the numerator and denominator are not 0.0
• During test development, the tester shall examine the logic for the following conditions:
  – divide by zero condition for a divider
  – a negative input to a square root
  – a negative input to the LOG or LN function
• Bullet proofing will be used for these conditions. Any unit that does not have this bullet proofing will be
  rejected out as not testable.

Arithmetic Tests:

The goal of arithmetic tests is to verify all computations and their precision using random input values. This is
achieved by fixing a random value (avoid round numbers) to all variables within the arithmetic expressions and
calculated manually. The result is verified by executing the unit code. The accuracy of the computation will be
calculated and expressed in terms of number of deltas.

In this type of testing each arithmetic expression is evaluated for its outcome when the resolution or DELTA of its
output value while DELTA for all input values is specified a priority.

If       Z = X +/- Y               then DELTA of Z = (DELTA of X + DELTA of Y)
If       Z = X * Y                   then DELTA of Z = (X * DELTA of Y + Y * DELTA of X)
If       Z = X / Y                   then DELTA of Z = (Y * DELTA of X + X * DELTA of Y) / Square (Y)