Mena1710

 Profile Answers by Mena1710 Questions by Mena1710

• Feb 13th, 2008

 

Hi poonam gawde

Basically the above all deals with white box testing.  WE need to  test all statements, Decission, condition and the path coverage of code.  Normally it comes under Unit testing of code.  We have many unit test tools like NUNIT etc.  This all developers do it before the code is delivered

Hope this clarifies your doubt

Thanks
Anna

jawad akhtar

 Profile Answers by jawad akhtar 

• Apr 4th, 2008

 

i am currently working for my iseb foundation soft ware testing exam. i am struggling with the "number of tests required for 100% statement coverage and decission coverage questions" Please help. I have no programming knowledge and run a mile from it.

Sarita123

 Profile Answers by Sarita123 

• Jul 11th, 2008

 

Code coverage is a way to measure the level of testing you've performed on your software. Gathering coverage metrics is a straightforward process: instrument your code and run your tests against the instrumented version. This produces data showing what code you did -- or, more importantly, did not -- execute. Coverage is the perfect complement to unit testing: unit tests tell you if your code performed as expected, and code coverage tells you what remains to be tested.

How can 100% coverage be insufficient? Because statement and branch coverage does not tell you if the logic in your code was executed. Statement and branch coverage is great for uncovering glaring problems found in unexecuted blocks of code, but often misses bugs related to both decision structures and decision interactions. Path coverage, on the other hand, is a more robust and comprehensive technique that helps reveal defects early.

Statement coverage identifies which statements in a method or class have been executed. It is a simple metric to calculate, and a number of open source products exist that measure this level of coverage. Ultimately, the benefit of statement coverage is its ability to identify which blocks of code have not been executed. The problem with statement coverage, however, is that it does not identify bugs that arise from the control flow constructs in your source code, such as compound conditions or consecutive switch labels. This means that you can easily get 100% coverage and still have glaring, uncaught bugs.
A branch is the outcome of a decision, so branch coverage simply measures which decision outcomes have been tested. This sounds great because it takes a more in-depth view of the source code than simple statement coverage, but branch coverage can also leave us wanting more.
A path represents the flow of execution from the start of a method to its exit. A method withNdecisions has 2^N possible paths, and if the method contains a loop, it may have an infinite number of paths. Fortunately, we can use a metric called cyclomatic complexity to reduce the number of paths we need to test.