Predicates, Path Predicates and Achievable Paths in Software Testing

Applications of Path Testing

Integration, Coverage and Paths in called Components

Path testing methods are mainly used in unit testing, especially for new software

The new component is first tested as an independent unit with all called components and co-requisite components replaced by stubs. A simulator of low-level components that is more reliable than the actual component

Path testing clarifies the integration issues

C₁ coverage at the system level ranges from 50% to 85%

We gave no statistics for C₂ coverage in system testing because it is impossible to monitor C2 coverage without disrupting the system's operation

Note:

Co-requisite: A formal course of study required to be taken simultaneously with another

New Code:

New code should always be subjected to enough path testing to achieve C₂

Stubs are used where it is clear that the bug potential for the stub is significantly lower than that of the called components

Old, trusted components will not be replaced by stubs

Some consideration is given to paths within called components

Typically, we will try to use the shortest entry/exit path that will do the task

Maintenance:

There is a great difference between maintenance testing and new code testing

Maintenance testing is a completely different situation

It involves modifications which are accommodated in the system, as required

Path testing is used firstly on the modified component

Rehosting:

Path testing with C₁+C_{2 coverage is a powerful tool for rehosting old software}

We get a very powerful, effective, rehosting process when C₁+C₂ coverage is used in conjunction with automatic or semiautomatic structural test generators

Software is rehosted because it is no longer cost effective to support the environment in which it runs

The objective of rehosting is to change the operating environment and not the rehosted software

Rehosting from one COBOL environment to another is easy by comparison

Rehosted software can be modified to improve efficiency and/or to implement new functionality, which had been difficult in the old environments

The test suites(collection) and all outcomes of the old environment become the specification for the rehosted software