3

So I have a flow chart diagram (say A to E where many have bidirectional paths) and I am supposed to design test cases covering 100% of possible paths.

So I traverse the diagram and goes like:

ABCDE
ABCBDE
ABCBDCE
ABCDCBCDE etc.

etc.

I looked at state transition but that is not the same because it only deals with transition between two states, while I need to ensure all paths are covered.

|improve this question
  • You didn't say what A through E are. If they are GUI events (e.g. entering text or clicking a button), this paper might help you with the terminology: cs.umd.edu/~atif/papers/GaoFangMemonISSRE2015.pdf. The authors are students of Atif Memon. He and his graduate students have published dozens of papers on GUI testing. See cs.umd.edu/~atif/publications.shtml. – user246 Mar 8 '17 at 18:15
  • I think more details are needed. If it's a math proof then sure you need to do all combinations of the above to ensure it's covered, but usually in an application the relationships and underlying code usage are the important parts and as long as you ensure the relationships and code usage are covered it should be adequate, but we can't tell that from the example provided. – mutt Mar 8 '17 at 18:16
  • As I have written, it is a flow chart, so simply consider these states in a finite state machine. – John V Mar 8 '17 at 18:22
2

It sounds like Path Testing. Here's the description of Path Testing from Lessons Learned in Software Testing:

A path includes all of the steps that you took or all of the statements that the program passed through in order to get to your current state. Path testing involves many paths through the program.

When you diagram the paths, they can end up looking just like A -> B -> C -> D, etc. Here's a flowchart example.

There's another variation of path testing called control flow graph(ing) which seems to be the graphical representation of paths. Wikipedia has some interesting information on it as well.

All of these are coverage based test techniques which is about how much you test. In principle, coverage-based techniques direct you to run every test of a given type. In practice, you probably won't but you might measure your coverage of that type of testing. (Also from Lessons Learned)

|improve this answer
0

I don't think there's a formal name for what is basic testing different scenarios.

I'd probably consider unit testing of the algorithm that is choosing the paths to make sure correct paths are chosen for a given input.

I would choose some of what I tend to call workflows and create user acceptance testing for them.

Testing frequently involve using test examples and does not need to test every permutation. You may find it helpful to look at what expectations will be different for the different permutations, these can help drive you to select good representative test examples. Testing a lot of permutations call also require stubbing and mocking external resource as test run time starts to become a bigger factor.

|improve this answer
0

I think what is being described here is coverage testing, specifically the following:

1) Decision testing - a point at which a direction of a path may take.

and/or

2) Statement testing - the statements along the path influenced by any decisions. A path direction may have several statements.

In the example below you'd have 50% decision coverage and 75% statement coverage if the condition was false.

Example:

If condition = true then
    Do Action A
Else
    Do Action B
    Do Action C
    Do Action D

The coverage of these items are sometimes reported and it sounds like you're after 100% coverage of decisions in this case.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.