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

Permalink

Important interview questions on testing

Permalink

How to write test cases for this condition and how many test casess we can write

A>15&&B<20

Permalink

Hi Ashok,

Please go through the basic concepts of Testing.

1. Find out the ranges of A, B

2. Find out the ranges of A, B types