Денис Виневцев

08 Июл 2014

Как мы тестируем анализаторы кода PVS-Studio и CppCat

Всем привет! Сегодня нам хотелось бы поделиться с вами как происходит тестирование наших анализаторов исходного кода С/С++ CppCat и PVS-Studio перед выпуском новых версий в свет. Если вы не знакомы с этой линейкой продуктов, рекомендуется сделать это прямо сейчас. Нет, нет, я вовсе не уговариваю вас обязательно установить эти замечательные продукты, просто вам будет гораздо легче и быстрее разобраться в смысле этой статьи :-).

Итак, на текущий день у нас есть два инструмента для анализа исходного кода в C/C++ проектах. Каждый из них позволяет указывать на потенциальные проблемы в коде. Всем практикующим разработчикам давно известен тот факт, что всех ошибок избежать невозможно. Способов успешно справляться с этой проблемой много, и каждая команда разработчиков выбирает тот, который наиболее подходит для текущего поддерживаемого и/или разрабатываемого проекта. Естественно, у каждого подхода есть свои достоинства и недостатки — важно пойти по пути наименьшего сопротивления и выбрать наиболее подходящий их них. Некоторые "покрывают" весь код тестами и буквально "тащат" за собой новый код вместе с новыми тестами, увеличивая время на разработку в разы. Конечно, если на это есть деньги и время, это наиболее надежный вариант, но в реальной жизни это бывает крайне редко, потому что ни менеджерам проектов, ни заказчикам не хочется платить лишние деньги, а объяснять пользу от этого людям, которые далеки от программирования напоминает попытку кошки поладить с собакой. Есть более разумный подход: TDD (Test-Driven Development ), в котором сначала пишутся тесты, а потом код. Так можно быть уверенным в том, что мы хотим протестировать только то, что нам интересно. Тот факт, что некоторые тесты никогда "не отваливаются" всегда наводит на мысль, что их слишком много. Немного подумав, можно прийти к выводу, что для библиотек и собственных каркасов разработки наиболее подходят модульное тестирование, а для бизнес-логики — интеграционное. Это наиболее безболезненный и надежный подход для обеих сторон: разработчиков и заказчиков.

К сожалению, так бывает не всегда и приходится искать совершенно другие варианты тестирования своих продуктов. Так случается, когда есть очень много (или хотя бы более одного) компонентов, которые не укладываются в общую архитектуру и могут совершенно независимо существовать друг от друга. CppCat и PVS-Studio — как раз тот самый случай. Конечно, мы можем запустить отладку для Visual Studio experimental instance, но подобный вариант не дает нам полной картины происходящего, другими словами — не подходит.

Но тестировать нужно! Поэтому у нас есть изолированное оконное приложение, которое позволяет убедится в полной корректности работы наших анализаторов (Рисунок 1).

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

Некоторое время тестер работал только для PVS-Studio. Он работал хорошо и нас это вполне устраивало. С появлением CppCat появилась необходимость в его расширении для работы в двух режимах. Писать для этого отдельное Stand-Alone приложение не стоит, поэтому нам пришлось интегрировать два режима работы в одном месте. Следует заметить, что это не создание нового режима тестирования, а всего лишь модификация одного из многих способов, описанных в статье по ссылке выше.

Рисунок 1 – Общий интерфейс тестера

Предлагаю немного погрузиться в ключевые моменты интерфейса программы для более полного понимания процесса:

Рисунок 2 – Текущие настройки запуска

Выпадающий список с текущими настройками для запуска тестера (Рисунок 2) позволяет нам указать, какие в данный момент режимы запуска мы хотим использовать. Все они хранятся в обычных xml-файлах. Существует несколько режимов запуска: настройки, адаптированные для запуска тестера в Visual Studio 2010 IDE; настройки, которые используют только препроцессор и компилятор с Visual C++; настройки по умолчанию, и т. д.

Рисунок 3 – Список проектов

Список проектов (Рисунок 3.) позволяет нам выбрать типовые проекты для тестирования наших анализаторов.

Рисунок 4 – Режим запуска

С режимом запуска (Рисунок 4) все понятно: он позволяет указать, какой анализатор мы хотим использовать в данных момент для прогона тестов.

Рисунок 5 – Хронология тестовых запусков

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

Рисунок 6 – Параметры запуска

Параметры запуска (Рисунок 6) позволяют указать интегрированные среды разработки, в которых нужно запускать анализ. Переключатель на панели Tasks позволяет указать, что мы хотим сделать: запустить тесты или сгенерировать эталоны (Об эталонах мы поговорим чуть позже)

Для того, чтобы убедится в корректной работе анализаторов, мы используем механизмы сравнения текущих полученных диагностик с эталонными. Эталонные диагностики — это диагностики, которые используются для сравнения с текущими полученными. Они хранятся в качестве обычных xml-файлах. Отличия, обнаруженные при сравнении — сигнал для нас, что тесты провалились и следует обратить внимание на последние правки кода, которые могли привести к неправильной работе.

Из-за того, что тестер изначально проектировался для PVS-Studio и не был предназначен для расширения, возник целый ряд проблем при интеграции с другим плагином. Не вдаваясь в детали, можно сказать, что CppCat и PVS-Studio работают по-разному. Именно поэтому поддерживать существующий тестер становится с каждым разом все сложнее и сложнее.

В ближайшем будущем, мы планируем переработать "с нуля" данный тестер, ориентируясь на Usability и максимальную независимость от поведения работа анализаторов. Цель– большее удобство использования внутреннего инструмента тестирования, а соответственно повышение качества наших инструментов для пользователя.

0

0

0

0

ПОДЕЛИТЬСЯ

Присылаем лучшие статьи раз в месяц