Оптимизация процесса тестирования по С с использованием эвристического анализа тестового покрытия кода (1187409), страница 4
Текст из файла (страница 4)
Определение затронутых тестовДля каждой строки существует три варианта изменений:1. Модификация. В данном случае необходимо запустить тесты,которые ранее покрывали данную строку.2. Удаление. Является подклассом модификации. Также запускаемтесты, которые ранее покрывали данную строку.3. Добавление новых строк. Наиболее сложный случай. Так как мыработаем с абстрактными данными о покрытии, мы не имеемникакой информации о синтаксическом дереве кода.
В данномслучае предлагается запускать тесты, покрывавшие строки, номеракоторых заняли новые, а также строку перед внесеннымиизменениями (с точки зрения покрытия). Такое решение негарантирует, что новый код будет покрыт. Простой пример - кодвыше и ниже новых строк - отдельные функции, никак с ним несвязанные. С другой стороны, согласно культуре разработки,разработчик обязан добавить тесты, покрывающие новый код. Такчто основным источником риска в данном случае являетсяразработчик, но не утилита.256.
ИмплементацияВ данной части будет описан процесс разработки непосредственнооптимизационной утилиты, а также возникшие в ходе него проблемы и ихрешения.6.1. Требования к имплементацииДля реализации алгоритма оптимизации требуется наличие следующегофункционала:1.
Работа с изменениями в кодовой базе. Возможность определять,какой тип модификации был произведен над кодом.2. Использованиераспространеннойивыгоднойутилиты,предоставляющей результаты покрытия3. Интерфейс для выбранной утилиты4. Хранение данных о тестах и покрытии5. Сопоставление покрытия, кода и изменений6. Вычисление разницы между областями покрытия7. Интерфейс для работы с тестирующей системой и интеграции8. Инициализация и поддержание актуальности своих данных9. Возможность запуска на различных платформах и различныхокружения6.2. Работа с изменениями в кодовой базеТак как одной из основных задач является упрощение процессаразработки, предполагается, что утилита должна отслеживать, какие частикода были изменены и каким образом.
Согласно Eclipse Community Survey,в котором респонденты в том числе, указывали используемую системуконтроля версий, в 2014 году git обошел svn по статистике использования.Данные выводы можно также подтвердить статистикой Google попоисковым запросам о VSC за 2016 год, в которой git занимает 70,7%. git26diff предоставляет весь функционал, необходимый для имплементацииутилиты. Более того, сама система может помочь в решении некоторыхдополнительных задач, в том числе в работе с тестами и покрытием.6.3.
Выбор утилитыВ первую очередь необходимо ограничить набор поддерживаемыхутилитой языков. Обратимся к исследованию компании TIOBE Inc за 2016год. Согласно исследованию, первые пять мест занимают C-подобныеязыки, а также python. Ограничимся этими языками.Входные данные о покрытии и тестах должны иметь определенныйстандартизированный формат, зависящий от анализатора покрытия,27используемого в проекте. Если в python данный анализатор, фактически,встроен в язык с помощью модуля coverage.py, то в остальных четырехслучаях необходимо использование внешних утилит анализа. Намнеобходимо выбрать наиболее популярную, удобную и совместимую сформатами,поддерживаемыми[10]coverage.py.Нижерассмотримподробнее конкретные решения.6.4. Обзор решений для анализа покрытия кодаТак как в данном подисследовании делается упор на работу скомпилируемыми языками, большинство решений будут представлять изсебя пару компилятор-анализатор.
Чтобы не заострять на этом вниманиекаждый раз, в общем случае данная связка работает так. Компилятор,который может являться расширением уже существующего для рабочейплатформы, производит инструментацию и компиляцию кода. Анализаторже потребляет результат работы инъецированных инструкций. Вследствии непосредственной интервенции в исполняемый код, скоростьработы тестов падает, а размер файла увеличивается. Однако этонеобходимые и неизбежные затраты, когда приходится иметь дело сподобными языками.6.4.1.
Testwell CTC++Мощная, но, с другой стороны, довольно простая утилита для анализатестового покрытия кода на C и C++. С некоторыми расширениями,способна так же работать с C#. Представляет с собой анализатор, спомощью компиляции инструментированного файла представляющийотчет по выполнению тестов. Поддерживаемые виды оценки покрытия —вызовы функций, покрытие ветвей (с различными уровнями сложности),строковое покрытие и покрытие утверждений.
Помимо того, чтонепосредственно интересует нас в нашей задаче, утилита предоставляет28дополнительныевозможности,позволяющиеоптимизироватьсамтестируемый код, такие как поиск узких мест и долго исполняемого кода.Однако с точки зрения современного подхода к тестированию, TestwellCTC++ выглядит серьезно устаревшим. Как пример, отсутствуетнепосредственная связь между конкретным тестом и кодом, который былим охвачен.6.4.2. Froglogic CocoБолее современный и мощный инструментарий, обладающий в несколькораз большим функционалом.
Не смотря на то, что с точки зрения методовполучения непосредственно информации о посещенных узлах данныйнабор утилит не сильно ушел вперед, он предоставляет серьезныйпотенциал для интеграции и различные форматы репортов. Но главноепреимущество, особенно для нашего случая, это связка непосредственнотестов и покрытия. Для примера, анализ позволяет выявить оптимальныйпорядок запуска тестов для получения максимального покрытия,сравнение качества покрытия для разных патчей, а также, самое главное,возможностьопределитьминимальноеподмножествотестов,необходимых для проверки патча. К сожалению, новизна данногопродукта, а также то, что в IT индустрии процесс миграции с заложенныхв прошлом решений является достаточно трудным и, зачастую, признаетсяне стоящим затраченных средств, не позволяет ему занять вполнезаслуженное место лидера.[16]6.4.3. Bullseye Covegare“Корпоративный стандарт” для утилит тестирования, данный анализаториспользуется такими гигантами, как Hp, Philips и Abode.
Продуктрассчитан на крупные проекты. Данная утилита позволяет работать смаксимальным количеством различных вариантов оценки покрытия,29например, DataFlow Coverage, или специфической метрикой, как RaceCoverage. И всего этого разработчики добились, работая с той же идеейинструктизации.Однимизпреимуществуказываетсяпростотаиспользования, однако множественные настройки и скрипты делают егодостаточно запутанным. Несмотря на это, возможность работы с отчетом опокрытии с помощью сторонних утилит, а также его распространенность,делаетBullseyeCoverageперспективнойцельюдляреализации[9]поставленной оптимизационной задачи.6.4.4.
GCTУказываемая разработчиками Bullseye как единственная утилита, котораяможет соперничать с их продуктом в области реализации метрик, этосвободное ПО было создано Брайеном Мариком (Brian Marick) в 1992 годуи базируется на компиляторе gcc. Использовалась для тестирования ядраUnix. В данный момент морально устарела, не поддерживая большинствоинноваций gcc вторых версий. Дальнейшая разработка в не ведется.6.4.5. GCOVПоставляетсякакстандартная утилита в составе пакета gcc ираспространяется под лицензией GNU GPL.
Многие проекты с открытымисходным кодом используют данное решение, что делает формат gcovперспективным для использования в реализации. Однако утилитапредоставляет только самые базовые возможности оценки покрытия,[15]например, покрытие по ветвям.6.4.6. Выбор утилитыМы остановились на двух возможных вариантах:1. Bullseye Coverage2. GCOV30Согласно обзору, Bullseye Coverage и GCOV являются наиболеераспространеннымиутилитами,причемBullseyeявляетсяболеекоммерчески-ориентированным платным продуктом, а gcov - открытым илегкодоступным.Сточкизренияэкономическогоприложения,использование Bullseye является более выгодным, в том числе потому, чтопроекты, завязанные не него, являются крупными комплекснымисистемами, для которых проблема загруженности тестами являетсядовольно серьезной.
С точки зрения разработчика утилиты, такие клиентыявляются приоритетными, так как данного функционала в виде плагина несуществует, а компании, уже купившие лицензию Bullseye, будут готовыкупить и дополнение. С другой стороны, крупные компании привозникновении серьезной проблемы обычно стремятся решить ее какможно быстрее, чтобы минимизировать потерю времени и ресурсов. Втаких случаях появляются внутренние решения для оптимизации процессатестирования, что сужает применимость нашего оптимизационногорешения.GCOV, в отличие от предыдущего решения, является бесплатной и,вследствие, более широко распространенной среди малых и среднихпроектов утилитой.Она куда проще и предоставляет меньшевозможностей, чем Bullseye, но является признанной сообществом инадежной.
Тренды к использованию более распространенных опенсорсрешений в IT-компаниях, наоборот, расширяют область применениянашего решения относительно предполагаемой аудитории. Более того,формат результата работы GCOV совпадает с выдачей модуля coverage.py.Учитывая эти преимущества, для исследования будет использованаименно эта утилита, однако поддержку Bullseye стоит рассматривать в31качестве возможного развития проекта в сторону монетизации иинтеграции в существующие крупные продакшн-системы.6.4.7.
Интерфейс для выбранной утилитыGCOV имеет два формата вывода - тестовый, а также XML-формат.Именно его мы и будем использовать. Основная задача - трансляцияданных из XML в хранилище, о котором ниже. Используя наработкиpython-пакета lcovparse для работы с xml, создадим скрипт, который будетбрать из репорта строки и помещать хэш текущего теста в хранилище.6.5. Хранение данных о тестах и покрытииДля начала, абстрактизируем данные. Каждому тесту необходимосопоставить уникальный идентификатор, например, хеш из пути к нему(считаем, для простоты, что каждый тест размещен в отдельном файле).Основным инструментом для хранения данных о покрытии будетSQLite-хранилище с простой схемой, указанной выше. Имеем тритаблицы: тесты, покрытие и файлы. В данной схеме хранится все, чтотребуется для работы алгоритма, а работа с данными - упрощается.Например, чтобы получить вес теста, посчитаем количество строк втаблицеCoverage,имеющихданныйtest_id,иразделимнаTest.running_time.6.6.