Каков процент покрытия кода для вашего проекта?

Question

Что такое% покрытия кода в вашем проекте? Мне любопытно, почему.

Разве команда разработчиков довольна этим? Если нет, то что стоит на пути от его увеличения?

Stuart Halloway - один из тех, чьи проекты направлены на 100% (или же разрывы строек!). Кто-нибудь на этом уровне?

Мы находимся в болезненном 25%, но стремимся к 80-90% для нового кода. У нас есть устаревший код, который мы решили оставить в покое, поскольку он испаряется (мы активно переписываем).

Answer 1

Мы работаем с охватом 85% кода, но падение ниже его не нарушает сборку. Я считаю, что использование кода в качестве важного показателя является опасной практикой. Просто потому, что что-то рассматривается в тесте, не означает, что покрытие является хорошим. Мы стараемся использовать его в качестве руководства для тех областей, в которых мы слабо охвачены, а не как факт.

Answer 2

80% - это критерии выхода для вехи. Если мы не сделаем это thrgouh спринт (хотя мы планируем время впереди), мы добавляем его через стабилизацию. Мы можем взять исключение для конкретного компонента или функции, но мы открываем элемент Pri 1 для следующей вехи.

Во время кодирования покрытие кода автоматически измеряется в ежедневной сборке, и отчет отправляется всей команде. Все, что подпадает под 70%, - желтый, менее 50% - красный. Мы не выходим из строя в настоящее время, но у нас есть план добавить это в следующую веху.

Не знаете, что делает dev, связанное с модульным тестированием. Devs нанимаются для создания качественного продукта, и должен быть процесс, обеспечивающий минимальное качество и способ его измерения. Если кто-то не удовлетворен процессом, они могут предложить другой способ проверки своего кода, прежде чем он будет интегрирован с остальными компонентами.

Кстати, мы также измеряем покрытие кода на автоматизированных сценариях. Таким образом, у нас есть три unmbers - unit, сценарий и комбинированный.

Answer 3

Я часто использую покрытие кода в нашем автоматизированном наборе тестов, но прежде всего для поиска непроверенных областей. Большую часть времени мы получаем около 70%, и по двум причинам никогда не будем бить по 100%;

1) Мы обычно автоматизируем новую функциональность после выпуск, который вручную протестирован для его первого выпуска и, следовательно, не включен в анализ покрытия. Автоматизация в первую очередь предназначена для функциональной регрессии в нашем случае и является лучшим местом для выполнения и улучшения охвата кода.

2) Для получения покрытия 100% требуется впрыск, так как вам нужно попасть внутрь обработчиков операций. Это сложно и требует много времени для автоматизации. В настоящее время мы этого не делаем и, следовательно, никогда не получим 100%. Книги Джеймса Уиттакерса на странице breaking software покройте эту тему хорошо для всех, кто интересуется.

Следует также помнить, что покрытие кода не соответствует испытанию покрытия, как это часто обсуждается в таких потоках, как this и this на SQAforums. Таким образом, 100% охват кода может быть ошибочным показателем.

Answer 4

Пару лет назад I measured Perl's test coverage. К концу 250 тестовых случаев он достиг 70% кода и 33% полностью протестированных филиалов

Answer 5

Наша цель компании - покрытие 80% заявлений, включая код обработки исключений. Лично мне нравится быть выше 90% от всего, что я проверяю.

Answer 6

0% к сожалению на нашем рабочем месте. Будет стремиться улучшить это, но, пытаясь рассказать боссам, что нам это нужно, это непросто, так как они видят тестирование! = Кодирование меньше денег.

Answer 7

Проект, который я сделал пару лет назад, достиг 100% покрытия линии, но у меня был полный контроль над ним, чтобы я мог обеспечить цель.
Теперь у нас есть цель получить 50% нового кода, цифра, которая будет расти в ближайшем будущем, но никак не может ее измерить. Скоро у нас появятся инструменты для измерения охвата кода при каждом ночном тестировании модульных тестов, поэтому я убежден, что наша позиция улучшится.