Path coverage testing is arguably the most thorough type of testing that seeks to test the critical paths of software code in an application. These major paths of code may have several decision points or "if" statements which branch off the main path. Branch coverage testing aims to ensure that each branch from each "if" statement is executed.
Hmm its difficult to answer this question...but i think it is "C"
A path is a sequence of executable statements. Testers are concerned with "entry-exit paths", which begin at the entry point into a given process and proceed to its exit point. (Why? Because you can't normally start or stop a process somewhere in the middle.)
"100% path coverage" requires that every entry-exit path be tested (not, as Gowtham suggested, every critical path). If a process consists of simple actions ("do A; do B; do C ..."), with no decisions, only one sequence of actions is possible, so 100% path coverage requires only one test case.
If the process includes a decision (e.g.: "do A; if (condition) then do B else do C endif; do D"), the number of possible paths increases--in this example, from one path to two (a "true" case and a "false" case, in terms of the decision). Adding more decisions creates more executable paths.
The real problem arises when the process contains a loop, as in your example. If "condition A" is already false when the WHILE statement is encountered for the first time, the loop body ("Do B") will not be executed at all. If "condition A" is initially true, but becomes false after one iteration, "Do B" is executed once. If "condition A" becomes false after two iterations, the sequence "Do B; Do B" occurs. If "condition A" becomes false after three iterations, you get the sequence, "Do B; Do B; Do B"; and so on.
Ignoring the WHILE and END WHILE statements, then, we have several different possible "sequences of executable statements", i.e., "paths". The first path omitted "Do B" altogether; then we had "Do B" (once), then "Do B; Do B", then "Do B; Do B; Do B", and so on, each forming a different sequence of executable statements--i.e., a different path. (Not the same thing as "a sequence of different executable statements". There's no requirement for the statements to be different, only for the sequences to be different.)
So the question is, what are the minimum and maximum numbers of times that your example loop can execute? If it's possible that "condition A" may never become false (e.g., "WHILE 1 = 1", or "WHILE true"), the loop has only one execution path, but requires an infinite number of iterations to complete it, which we may reasonably consider impossible to test to completion.
On the other hand, the conditions under which "condition A" is or becomes initially true, and the conditions under which it becomes false through execution of the loop, may guarantee that the loop must iterate (say) at least five times, but can't iterate more than ten times. In that case, there would be (5 iterations; 6 iterations; 7 iterations; 8 iterations; 9 iterations; 10 iterations) --> 6 execution paths to be tested in order to achieve 100% path coverage.
For example, suppose the loop is counting lines of text, of which there must be not less than 5 and not more than 10. In order to achieve 100% path coverage, you'd need a test case that counts 5 lines, plus one for 6 lines, plus one for 7 lines, and so on up to and including 10 lines of text.
But in your example, we don't know whether "condition A" is initially true or false; and if it does start off as true (meaning that we'll execute the loop body at least once), we don't know under what conditions it becomes false. Therefore, we can't know how many times the loop may iterate. Which means that the "number of paths [required] to achieve 100% path coverage is "indefinite" (answer (b)).
In general, software systems include many "open" loops which could potentially execute an infinite number of times. And sorry, "vijayabaskar": "knowing the dry run concept" doesn't make 100% path coverage "easy" or even possible in such cases. For this reason, 100% path coverage is said to be generally unachievable for a software system, though it might easily be achieved for specific components that are either loop-free, or have tightly constrained loops.
So much for path coverage. But your discussion is headed, "What is difference between Path coverage and Branch coverage?" Coverage attempts to measure the "thoroughness" of testing by counting what proportion of the software's internal "structures" get tested, including dynamic "structures" such as "paths". (This is to ignore coverage of "external" properties such as requirements.) The simple answer to your question is that the difference between "path coverage" and "branch coverage" is that they count different things: "paths" and "branches" respectively. After that, it gets a little difficult in that there are several competing definitions of branch in the testing literature; but none of them equates "branch" with "path", so there is always a difference between "branch coverage" and "path coverage".
I hope this helps, Dung Vu (and forgive me for not knowing whether you are "Dung" or "Vu"). Best wishes,