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

Question

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

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

Стюарт Хэллоуэй - тот, чьи проекты нацелены на 100% (или же сборка ломается!). Кто-нибудь на этом уровне?

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

Целью нашей компании является покрытие отчетности на 80%, включая код обработки исключений. Лично мне нравится быть выше 90% на всех вещах, которые я проверяю.

Answer 4

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

Answer 5

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

Answer 6

Пару лет назад Я измерил тестовое покрытие Perl . К концу 250 тестовых случаев он достиг 70% кода и 33% полностью протестированных веток

Answer 7

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

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

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

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