Как работают инструменты покрытия кода?

Ответ 1

Вот техническая статья о Как реализовать инструменты охвата тестирования для произвольных языков.

Моя компания создает семейство инструментов для тестирования на Java, С#, С++, PHP, COBOL, PLSQL,... на основе этого принципа.

Ответ 2

Цитата прямо из NCover Часто задаваемые вопросы: NCover сообщает о проценте веток в коде, который был взят в ходе вашего автоматизированного тестирования. Он достигает этого, используя исходный код в каждой ветки и записывая точки "попадания" в файл. Эти "хит" точки затем сравниваются с общими возможными точками, которые могли быть "удары".

Ответ 3

Я знаю, что это вопрос старый, но если вас все еще интересует, вы можете увидеть пример того, как такое инструментальное обеспечение выполняется для приложений .NET, рассматривая проект с открытым исходным кодом OpenCover.

OpenCover вставляет контрольные точки в значимые моменты кода.

• Для покрытия строки кода он использует точки последовательности, взятые из файла PDB
• Для охвата веток он набирает команды COND_BRANCH, набирая мишень перехода и следующую инструкцию после команды перехода, то есть без прыжка.
• Для инструментария инструмента он устанавливает первую инструкцию любого метода.

Все эти правила применяются в CoverageInstrumentation.cpp после того, как соответствующие точки были расположены с помощью Mono.Cecil и переданы профилировщику из консольный хост.

Исходный код для PartCover также доступен (как указано), но это намного сложнее, но он также использует точки последовательности из PDB для определения того, где он кодирует код.

Ответ 4

Из этот источник:

NCover использует API-интерфейс профилирования .NET Framework для мониторинга выполнения приложения. Когда метод загружается с помощью CLR, NCover извлекает IL и заменяет его с помощью кода IL-кода с инструментами

Короче говоря, он зацикливается на компиляции точно в срок.

Не все инструменты работают одинаково. Другие инструменты работают, изменяя байт-код вашего приложения после компиляции кода.

Ответ 5

Это требует, чтобы вы запускали свои тесты один раз с включенным анализом покрытия кода, а затем просто подсчитывали количество блоков (то есть блоков областей), которые покрывали и сравнивали с общим количеством блоков в тестируемых проектах (проектах).

Основная причина состоит в том, что если каждая возможная комбинация блоков кода покрыта, все пути кода покрываются ¹. Основной аргумент против слишком большого веса в номерах покрытия кода заключается в том, что "легкие" блоки, такие как геттеры и сеттеры, которые не дают реальной ценности (и вряд ли могут ошибиться...) подсчитывают столько же, сколько больше подверженных ошибкам блоков кода.

^{1) Как отмечено Ира Бакстер в комментарии, предыдущая формулировка этого предложения была неправильной. Пожалуйста, прочитайте комментарии для обсуждения этого вопроса.}