What we understand by Path-based Testing (PT)?
Sadly, terminology in system testing is a bit heterogenic, so to prevent confusion, let us explain first, what we mean by PT in this project.
PT, as we understand it, formalizes one of essential approaches in system testing – sequencing actions or steps to be taken in a system under test (SUT). It typically consists of the following steps
- The process or state space of a selected part of SUT is modeled via a suitable mathematical structure (usually based on a directed graph)
- Test coverage criteria are selected
- Test paths are generated by an algorithm from the SUT model. These test paths (test set) satisfy given test coverage criteria.
In this sense, path-based testing is a subpart of Model-based Testing (MBT).
Compared to test paths created by a manual way, this model-based approach, when managed well, has typical advantages:
- Given test coverage criterion is satisfied. Informally speaking, this is a tool to prevent situations where there are parts of the process that are not tested.
- Unnecessary duplications in the test paths are reduced – meaning unnecessary duplications in a test set that has to satisfy given test coverage criterion. Duplications per se are not principally wrong – they may increase probability of the tests to detect defects. But most of the projects have limited budgets and time and test sets have to be optimized. Obviously, removal of duplications is a much better way than random reduction of test paths or not executing them, because time dedicated to testing has run out.
- The process of test creation is faster – modeling of a process is the most demanding part from test creation, the tests are then computed automatically. Honestly, if this process is done manually, test engineers still need some kind of model of the process to test, even if in their heads. If this is missing, the result can be practically random.
Don’t confuse to control flow testing
Sometimes, you might find “path testing” referring to executing possible paths in the control flow graph of a program. That might cause confusion. We understand path-based testing as a much broader technique applicable to other, more high-level types of tests, including integration tests or end-to-end (E2E) tests.