Quality Testing

Quality is delighting customers

How many test cases are necessary to cover all the possible sequences of 
statements (paths) for the following program fragment? Assume that the two
conditions are independent of each other : -
…………

if (Condition 1)

then statement 1





else statement 2

fi

if (Condition 2)

then statement 3

fi .

Please tell me the formula or the method to calculate the no of test cases
in such or similar scenarios.


Views: 7594

Reply to This

Replies to This Discussion

For every Scenario we need consider following types of test cases.

1. Functional Test Cases.(As per Requirement)
2. GUI & Usability test cases (As per standers and Req)
3. Entry and Exit criteria Tests.
4. Negative test cases
5. Performance Test Cases
6. Compatibility Test Cases (Different versions of OS/Browser Versions)...

Depends on time-line and scope we need to choose the types of tests as Test is never ending process.
Yes, Kiran is correct, to test an actual application that used this bit of code, you would have to go through all of that stuff But to answer you base question, I would start with 4 tests so as to test each possible outcome of the conditions. Case one for condition 1 true & condition 2 false. Case 2 for condition 1 false & 2 true. Case 3 both false. Case 4 both true. This would test all the combinations of the code. From that I would look at what the conditions are and what the requirement was that generated them. For example if requirement for condition 1 is "A greater than B" then I would add the test of A = B to ensure that it was coded correctly since I don't get to see the code usually.
Hope that helps.
4
how ? Is there any formula or method to calculate in this scenario ?
Abu, How u calculated it as 4 ?
Depends on the type and extent of coverage required, Divya. If 80% of all statements (instructions, including if statements) must be tested, one test case would suffice, taking the true branch out of each decision (so "statement 2" would not be executed). If all statements are to be executed (100% statement coverage), you'd need two test paths, whereas if all predicates (decision outcomes) must be tested, you'd also need two, but a different two. If a basis path set is wanted, you'd need three, but to cover all combinations of predicates (which is what I think you're asking for), you'd need four.
We'll assume that, whatever type of coverage is needed, it must be at the 100% level. If we start with decision coverage (meaning "decision outcome coverage"), a test case which selected the true ("then") outcome for each decision and a second which selected the two false ("else") outcomes would do it: two test cases. (Although "Condition 2" has no explicit else, compilers will generate an implicit one.) For statement coverage, though, you should not execute predicates (decision outcomes) that have no dependent statements, i.e., you should avoid implicit else outcomes and test only thens and explicit elses. This would mean amending our second test case for decision coverage so that it still took the else outcome at "Condition 1", but the then outcome at "Condition 2".
Decision coverage is often recommended as a minimum level of coverage for algorithms (including use cases, where "100% decision coverage" normally means "100% flow coverage"). If risks are higher than normal, "all decision combinations" might be attempted, which would take the two "decision coverage" cases (1: true, true; 2: false,false), and add two more: 3: true, false; 4: false,true. This is a form of exhaustive testing, however ("all possible combinations"), and in a worst case the number of test cases rises exponentially with the number of decisions: 2 test cases for 1 decision, 4 for 2 decisions, 8 for three, 16 for four, ..., 1024 for ten, 2048 for 11, and so on.
Basis path testing offers a very reasonable compromise in which the maximum number of test cases required is n+1, where n is the number of binary decisions (e.g., the number of if statements). Your algorithm would need three test cases, which you'd build systematically by taking an initial path (say, 1: true, true) and then building successive paths by changing one predicate at a time until all decision outcomes have been covered (e.g., 2: false, true; 3: false, false). Then stop. This will ensure that all statements are covered; all decision outcomes are covered; and the location of a defect found by a failed test case is isolated to the code segment tested for the first time in that test case, which can have a very beneficial effect on debug time. Additionally, the basis path method provides a very systematic way of designing test cases that’s generally lacking with most techniques. And because the majority of bugs involve only a single factor being wrong in the code, a basis test set of (say) 11 test cases might find as many as 90% of the bugs that a full “all decision combinations” set of 1024 test cases could find. (Exact percentages will vary from case to case, of course.)
There are other types and levels of coverage, such as Modified Condition / Decision Coverage (MC/DC), which is mandatory for life-, safety-, and mission-critical avionics software. But basis path coverage is probably the best bet for most levels of risk below that, as it’s simple and systematic, and gives excellent coverage and bug-return with quite small test sets.
Final comments: The “basis path” and “all decision combinations” are the only approaches that offer a simple computation of the size of the set, and in both cases it’s a maximum size; with all methods, nested and correlated decisions may reduce the number of paths that can actually be executed, sometimes quite drastically. And finally finally: As hinted above, these techniques are not restricted to code-based testing, but can apply with any kind of process (which is why I prefer "instruction" to "statement"), including use cases.
I hope this helps, Divya. Best, -- Don
Thanks to all of you guys..!!

RSS

TTWT Magazine


Advertisement

Advertisement

Advertisement

Advertisement

© 2022   Created by Quality Testing.   Powered by

Badges  |  Report an Issue  |  Terms of Service