How does a DU path segment play a role in data flow testing?

Whenever you would have came across the topic of data flow testing, you surely would have heard about the term “du path segment” but still not familiar with it! This article if focussed up on the du path segments and what role it has got to play in the data flow testing. 

We will discuss the du path segments under the context of data flow testing and not as a separate topic so that it becomes easy for you to understand. 

The whole process of data flow testing is guided by a control flow graph that apart from just guiding the testing process also helps in rooting out the anomalies present in the data flow. With all the anomalies being already discovered one can now design better path selection strategies taking in to consideration these data flow anomalies. 

There are nine possible anomalies combinations as mentioned below:

1. dd: harmless but suspicious
2. dk: might be a bug
3. du: a normal case
4. kd: a normal situation
5. kk: harmless but might be containing bugs
6. ku: a bug or error
7. ud: not a bug because of re- assignment
8. uk: a normal situation
9. uu: a normal situation

For data flow testing some data object states and usage have been defined as mentioned below:

1.      Defined, initialized, created à d

2.      Killed, undefined, unreleased àk

3.      Used for:

(a)    Calculations à c

(b)   Predictions à p

Terminology associated with Data Flow Testing

Almost all the strategies that are implemented for the data flow testing are structural in nature. There are certain terminologies associated with the data flow testing as stated below:

1. Definition clear path segment
2. Loop free path segment
3. Simple path segment and lastly
4. Du path

What is a DU path Segment?

- DU path segment can be defined as a path segment which is simple and definition clear if and only if the last link or node of the path has a use of the variable x.

Let us take an example to make the concept of du path segment clearer. 

- Suppose a du path for a variable X exists between two nodes namely A and B such that the last link between the two nodes consists of a computational use of the variable X. 

- This path is definition clear and simple. 

- If there exists a node C  at the last but one position that is the path is having a predicate use and the path from the node A to node C is definition clear and does not contain any loop. 

- Several strategies have been defined for carrying out the data flow testing like:

1. ADUP or all du paths strategy
2. AU or all uses strategy
3. APU+ C or all p uses/ some c uses strategy
4. ACU +P or all c uses/ some p uses strategy
5. AD or all definitions strategy
6. APU or all predicate uses strategy
7. ACU or all computational uses strategy

Strategy for DU Path Strategy

We shall describe in detail here only the ADUP or all du paths strategy. 

- This strategy is considered to be one of the most reliable and strongest data flow testing strategy. 

- It involves the use or exercising of all the du paths included in the definition of the variables that have defined to every use of the definition.

- All the du paths suppose to be a strong criterion for testing but it does not involve as many tests as it seems.

- Simultaneously many criterion are satisfied by one test for several definitions and uses of the variables.

What is meant by code coverage? What are different types of code coverage?

- Code coverage can be defined as a measure to measure the extent to which the source code of a software system has been tested.
- Code coverage is categorized under white box testing techniques since the inspection of the code is carried out directly.
- Code coverage methodology was initially developed for systematic testing of software system. It was developed by two researchers:Miller and Maloney in year of 1963.
- Code coverage is regarded as one of the important considerations concerning the safety certification in the field of avionics equipment.
- Code coverage is not centralized on one idea. There are several different criteria or types to choose from. The criteria or type is chosen as per the requirement of the extent of testing. At a time one or more coverage criteria (types) can be used.

Different Coverage types have been discussed in details below:

Basic coverage type:
This category again has following criteria:
- Statement coverage: It determines whether or not each node in the program has been executed.
- Function coverage: It determines whether or not each function or sub routine in the program has been called.
- Decision coverage: It determines whether or not each edge in the program has been executed and it also ensures that requirements of every branch have been met.
- Predicate coverage: It is also known as condition coverage. It determines whether or each and every Boolean expression in the program has been evaluated to either true value or false value.
- Predicate/ decision coverage: It is combination of both predicate and decision coverage and determines whether or not both the types of coverage are satisfied. Fault injection technique becomes necessary here. It is done to ensure each and every part of the software system has got sufficient coverage.

Modified predicate/ decision coverage: It is usually abbreviated as MC/ DC. Some applications like avionics software applications are safety critical and they require satisfying the modified form of predicate/decisions coverage. The modification here is that each and every individual criterion for condition and decision should have a distinct affect on the outcome and it should be separately visible.

Multiple condition coverage: \
As the name suggests, this type of coverage has two or more conditions. The group of conditions is then tested. Multiple condition coverage determines whether or not all the combinations of the conditions in each decision are tested.

The above mentioned 3 code coverage types are frequently and mostly used coverage types. There are other types which are not so in use. They have also been discussed below:
- JJ path coverage:
It determines whether all the jump to jump kind of paths has been executed.
- Linear code sequence and jump coverage: It determines whether or not all LCSAJs have been executed.
- Entry coverage:
It determines whether or not every possible call has been executed.
- Exit coverage:
It determines whether or not every possible return of the functions has been executed.
- Path coverage:
It determines whether or not every possible path through a given unit has been executed.
- Loop coverage:
It determines whether or not all the loops have been executed.

Testing often achieves 100 percent of code coverage. This is verified through safety critical applications. Attaining full one kind of coverage is practically impossible. Most parts in a program are such that they cannot be accessed easily and therefore remain void of code coverage.There are certain things that are needed to be considered while implementing a code coverage type:

- Requirements of the code coverage for the certification of the finished product.
- Level of code coverage required.
- Testing of code coverage against the tests to verify the requirements.
- Direct generation of object code.