t.me/atinfo_chat Telegram группа по автоматизации тестирования

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

Теги: #<Tag:0x00007f9b040409d8>

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

О каких тестах идёт речь? О функциональных? Почему метрика “покрытие кода” определена как важная?

О каких тестах идёт речь? О функциональных? 

О функциональных ГУИшных автотестах.

Почему метрика "покрытие кода" определена как важная?

Да какая разница почему!? Вопрос данной темы “Как”, а не “Почему”.

Вопрос топика звучит

То есть ты считаешь, что эту метрику собирают

Если метрика не важна, то её и не меряют. Никак.

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

P.S. В другой раз за такие возмущения тему буду скрывать пока не сформулируешь нормально вопрос. Прочитай FAQ на досуге

1 Симпатия
P.S. В другой раз за такие возмущения тему буду скрывать пока не сформулируешь нормально вопрос. Прочитай FAQ на досуге

Ок, закрывай тему.

Используйте code coverage tools. Какой именно из них использовать, зависит от того, на каком языке программирования написано тестируемое приложение. Например, для Java - Cobertura, JaCoCo, Clover, .NET - dotCover + есть еще поставляемый с Visual Studio набор performance tools. Самое главное, эти все средства оценки покрытия, как правило, имеют 2 основные стадии:

  • instrumentation - получение информации о всех классах, по которым нужно оценивать покрытие и установка прослушки
  • finalization - сбор данных по покрытию и формаирование единого отчета.
    Так что если вы хотите измерить покрытие кода, то вам нужно запустить тесты между этими стадиями. Если вы используете движки типа xUnit, то в ряде случаев запуск таких тестов в оценкой покрытия обеспечивается движками сборки (например, в Maven это так и делается). В остальных случаях все можно свести к запускам командной строки. Более конкретно можно эту тему осветить при наличии деталей касательно используемых технологий
2 Симпатий

В зависимости от типа тестов.

  1. Для юнит-тестов на Java мы рассчитываем покрытие прямо в Intellij IDEA - там есть встроенная кнопка. Или с помощью распространённой библиотеки JaCoCo. Для юнит-тестов JavaScript подойдёт Karma, она умеет считать покрытие.
  2. Для UI-тестов рассчитывать покрытие особо не имеет смысла, потому что при запуске UI-тестов помимо строк кода на Java, задействовано много других составляющих: JavaScript, CSS, Less, база данных и пр. На сегодняшний день, наверное, не существует технологии, позволяющий посчитать покрытие для всех этих созданий.
2 Симпатий

Немного странный вопрос ИМХО.
Code Coverage - адекватен для модульных тестов. Для функциональных тестов, где тестируется через чёрный ящик - данная метрика не будет иметь смысла, ибо при составлении тестов учитываются не ветвления кода (мы о них не имеем ни малейшего представления), а покрытие требований. В таком случае необходима traceability matrix, а не code coverage.
Где-то так…

1 Симпатия

Маленькое уточнение: оценка покрытия кода не имеет смысла, если доступа к коду нет вообще. То есть вам прислали продукт в коробке, вот и тестируйте его. Тогда действительно остается только оценивать покрытие требований или подобных артефактов. Но при этому такой оценки есть существенный недостаток: требование считается покрытым, если для него есть хотя бы один тест. И это при том, что не учитывается его детальность и охват. Вот покрытие кода могло бы и подсказать, насколько хорошо данный тест покрывает текущую реализацию и не нужно ли чего-то добавить, чтобы проверить какой-то специфический аспект реализации. И достаточно ли полно мы все покрываем, и нет ли у нас участков кода ,который реально нигде не используется.

Далее, некоторые участки кода можно полноценно проверить только в случае запуска компонента или системы в целом (как правило, это обработчики событий). Просто может выйти дешевле протестировать их на уровне системных тестов.

Ну и опять же, ничто не мешает нам ограничить часть, кода для которой меряется покрытие. Например, для юнит-тестов одна часть всего кода, на которую эти тесты направлены. Для более высокоуровневых - другие. Просто установить фильтр.

И наконец, ни одна метрика оценки покрытия (кода или требований) не дает полной картины реального покрытия. У всех есть недостатки. Чтобы с более-менее высокой уверенностью сказать, что тот или иной модуль протестирован на N%, нужно комбинировать метрики. И покрытие кода просто добавляет свою часть в общую картину