Singular Point Tests :

In this type of testing each comparison in the logical condition is evaluated with the values representing all
possibilities of the condition along with a resolution called DELTA. The purpose of this test is to implement
conditions such as comparisons that shall be verified by making minor variations (called delta) to the operands
involved. For each inequality (<, <=, >, >=) we will have two possible test cases:

• Case where the condition is verified
• Case where the condition is not verified

The singular point tests will be performed about the same point or value. Comparisons shall be tested as follows:

Floating-point except for equal to (=) and not equal to (!=) : Within 10% above and within 10% below (see
note)
Floating-point equal to (=) and not equal (!=) to : Within 10% above, equal to, within 10% below (see
note)
Signed and Unsigned Integer :                    1 count above, equal to, 1 count below
Discrete Word :                                              Equal to and not equal to
Boolean :                                                          Equal to and not equal to

Note: For the comparison “X < Y”, there must be one test case where Y < X < (1.1 * Y) and another test case
where (0.9 * Y) < X < Y, where 1.1 and 0.9 are DELTA. X and Y may be reversed. If the value is 0.0, use +1.0
and -1.0 instead of 10% above and below.

• During test development, the tester shall examine the logic for conditions other than equal to and not
  equal to on discrete words and Boolean. Any unit that has one of these conditions shall be kicked out as
  not testable.
• If there is an equal to or not equal to comparison on floating-point values, consult with the unit test
  coordinator. The unit may not work.
• Some examples of conditional testing:

Floating Point                                                                                             Integer
Condition: X < 55.0                                                                               Condition: X > 100
10% above test case X = 60.5                                                              +1 test case X = 101
= test case not required                                                                        = test case X = 100
10% below test case X = 49.5                                                                -1 test case X = 99

The following will be the test cases for the different inequalities:
Case A>B

• A=B (the condition is not verified, hence false)
• A=B+delta (the condition is verified, hence true)

Case A>=B

• A=B (the condition is verified)
• A=B-delta (the condition is not verified)

Case A<B

• A=B (condition is not verified)
• A=B-delta (condition is verified)

Case A<=B

• A=B (condition is verified)
• A=B+delta (condition is not verified)

Boundary Value Tests:

This is done to verify whether the test inputs are tested at the minimum, nominal and median ((minimum +
maximum)/2) values. In this testing inputs are made to represent their boundary limits of the range. The
minimum, maximum and median value of each variable in an expression and computation must be verified to
make sure that there is no overflow.

• For all numerical variables as input, we have to perform three tests:
• A test for the maximum value of the type of that variable,
• A test for the minimum value of the type of that variable and
• A test for the median value of the type of that variable.

Also the maximum, minimum and median for every calculation in the modules will be manually calculated and
compared to the results obtained using the testing tool. Moreover, some variables may be restricted to a range
of variation smaller than the range of its type; in this case two additional tests must be realized, each testing the
limit of the restricted range.

Boundary Value Analysis is required when inputs or initial values for states are used in mathematical operations
and shall be applied as shown below:

Floating-point                            : not required
Integer                                       : -32768 to 32767 (16-bit)              or -2147483648 to 2147483647 (32-bit)
Unsigned Integer                      : 0 to 65535 (16-bit)                       or 0 to 4294967295 (32-bit)
Discrete Word                            : 0000H to FFFFH (16-bit)          or 00000000H to FFFFFFFFH (32-bit)
Boolean                                       : FALSE to TRUE

For floating-point values, if tools require ranges, values should be selected to functionally test the unit. In
general, -100,000.0 to 100,000.0 will adequately test the unit

• For non floating-point adjustments, the min and max adjustment range values shall be used instead
  of the values described above. For floating-point adjustments, if tools require ranges, the
  adjustment range values should be used.
• For counters, see the exception under Nodal coverage.

Basis Path Tests :

It is a testing mechanism is proposed by McCabe. The aim of this is derive a logical complexity measure of a
procedural design and use this as a guide for defining a basic set of execution paths. The test cases, which
exercise the basic set, will execute every statement at least once.

The virtues of the basis path testing are defined by Cyclomatic Complexity. The Cyclomatic Complexity gives a
quantitative measure of the logical complexity. This value gives the number of independent paths in the basis set
and an upper bound for the number of tests to ensure that each statement is excused at least once. An
independent path is any path through a program that introduces at least one new set of processing statements
or a new condition.

The objective of independent path testing is to exercise all independent execution paths through a code
component. If all of the independent paths are executed then all statements in the code component must have
been executed at least once. Also, all conditional statements are tested for both true and false.

• These testing techniques shall only be used at the module/function level because as a program increases in
  size during integration then the number of paths grows quickly, thus making it infeasible to use these
  techniques.
• Independent path testing does not test all possible combinations of all paths through the program.

The following steps shall be followed for independent path testing:

Create a flow graph for the code component.
This flow graph can be obtained from LDRA Testbed (refer to relevant LDRA Testbed documentation) or
created by hand.
A flow graph consists of nodes that represent decisions and edges that show the control flow.
Example: Flow graph for the binary search routine.

• An independent path is one that traverses at least one new edge in the flow graph (i.e. exercising one or more
  new program conditions)
• Both the true and false branches of all conditions must also be executed.

Derive the independent paths.

From the example flow graph defined in Figure 5.3.4.1-1 we can derive the following independent paths:
1, 2, 3, 8, 9
1, 2, 3, 4, 6, 7, 2
1, 2, 3, 4, 5, 7, 2
1, 2, 3, 4, 6, 7, 2, 8, 9
If all of these paths are executed then:

a) every statement in the code has be executed at least once.
b) every branch has been exercised for true and false conditions.
The number of independent paths can be derived by calculating the Cyclomatic Complexity of the flow
graph. This is achieved with the following formula:
CC(G) = Number (edges) – Number (nodes) + 2
Thus the CC of the flow graph in Figure 5.3.4.1-1 is:
11 – 9 + 2
CC = 4

The Cyclomatic Complexity can also be obtained from LDRA Testbed (Refer to relevant LDRA Testbed
documentation).

Design Test Cases

The minimum number of test cases required to test all program paths is equal the Cyclomatic Complexity