**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:

- At least one test case should be associated with each software requirement.
- 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)

Permalink

Hi

can u send me complete answer of SDLC and V model.

Permalink

Hi,

Can any post Vmodel.

And also what’s the difference between black box,requirement based testing,functional testing.

IIY, white box testing,code based testing,structural testing difference.

plz tell the difference .

Thank you.

Permalink

Mr.Riyan Even I having same kind of doubts please could u discuss with me

Permalink

Hi Ryan,

May I know what are the doubts do you have?

Regards,

Siva

Permalink

hi,

please post how to test floating point .

Permalink

hi, iam new to testing.. so can you upload some sample unit testing requirement to write test case. so that it will be helpful..

Permalink

Hi,

When a variable is float type,How we can test +infinity,-infinity.