Tag Info

Hot answers tagged

7

I always like to get code coverage for my functional tests, but not because I want to hit a certain percentage of code coverage. I like it because: It points me to areas of the code that are not covered. There are areas of the code that are very difficult to unit/integration test without having the entire system in place and doing end to end tests, so I ...


2

What you really want to measure with functional tests is functional coverage: how much of the functionality of the program was tested? Unfortunately, that's hard to measure in an automated fashion; the best measurement we have is by hand, correlating tests to requirements and counting up what didn't get covered. Code coverage can be used as an indicator of ...


2

Coverage is always coverage related to some model. This often gets skipped over, which leads to much confusion "you said you had 100% coverage so how come there's a bug?!" When you're looking at unit tests, then it's possible to use code coverage as an indicator (there are tools that can measure what percentage of the lines in your code are exercised when ...


2

There are the following types of test coverage criteria: structural criteria data criteria fault-model criteria requirements-based criteria criteria based on explicit test case specifications criteria based on statistical methods for random test data generation criteria based on mutation-analysis All criteria except the first one are ...


1

Coverage of state transitions Coverage of environment combinations It says, that structural is everything which is based un underlying code or alike. But I don't really see any practical use of this division.


1

Coverage should be done by developers, especially coverage by unit tests. You can track the numbers and suggest that if code is added to a module, test is added so new code is covered. But there is nothing you can do (as QA) to increase code coverage by unit tests. So if you responsible for that, it is by definition an exercise in frustration (because you ...


1

Yes, we do just that. We use Python and Coverage. I am curious what is business reason to eliminate unit tests. Unit tests are much closer to code and if any fails, finding and fixing the bug is much easier. The only reason to eliminate unit test is if another unit test covered the same execution path. OK, after comment from OP: yes, it is valid reason to ...



Only top voted, non community-wiki answers of a minimum length are eligible