Лекция
Привет, Вы узнаете о том , что такое Мутационное тестирование и Мутационный анализ и метрики, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое Мутационное тестирование и Мутационный анализ и метрики , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..
Мутационное тестирование (или анализ мутаций, или программная мутация ) используется для разработки новых тестов программного обеспечения и оценки качества существующих тестов программного обеспечения. Мутационное тестирование включает в себя небольшие изменения программы. Каждая мутированная версия называется мутантом, и тесты обнаруживают и отклоняют мутанты, заставляя поведение исходной версии отличаться от мутанта. Это называется убийством мутанта. Наборы тестов измеряются процентом убитых ими мутантов. Новые тесты могут быть разработаны для уничтожения дополнительных мутантов. Мутанты основаны на четко определенных операторах мутациикоторые либо имитируют типичные ошибки программирования (например, используют неправильный оператор или имя переменной), либо заставляют создавать ценные тесты (например, деление каждого выражения на ноль). Цель состоит в том, чтобы помочь тестировщику разработать эффективные тесты или найти слабые места в тестовых данных, используемых для программы, или в частях кода, которые редко или никогда не используются во время выполнения . Мутационное тестирование - это разновидность тестирования методом белого ящика .
Большая часть этой статьи посвящена «мутации программы», при которой программа модифицируется. Более общее определение анализа мутаций - это использование четко определенных правил, определенных для синтаксических структур, для внесения систематических изменений в программные артефакты. Мутационный анализ применялся к другим задачам, но обычно применяется к тестированию. Таким образом, мутационное тестирование определяется как использование анализа мутаций для разработки новых тестов программного обеспечения или для оценки существующих тестов программного обеспечения. Таким образом, анализ и тестирование мутаций можно применять к моделям проектирования, спецификациям, базам данных, тестам, XML и другим типам программных артефактов, хотя программные мутации являются наиболее распространенным явлением.
Тесты могут быть созданы для проверки правильности реализации данной программной системы, но создание тестов по-прежнему ставит вопрос, являются ли тесты правильными и достаточно ли они покрывают требования, которые послужили причиной реализации. (Эта технологическая проблема сама по себе является примером более глубокой философской проблемы под названием « Quis custodiet ipsos custodes? » [«Кто будет охранять стражу?»].) Идея состоит в том, что если мутант вводится, не будучи обнаруженным набор тестов, это означает, что либо измененный код никогда не выполнялся (мертвый код), либо набор тестов не смог обнаружить ошибки, представленные мутантом.
Чтобы это работало в любом масштабе, обычно вводится большое количество мутантов, что приводит к компиляции и выполнению чрезвычайно большого количества копий программы. Эта проблема стоимости тестирования мутаций уменьшила его практическое использование в качестве метода тестирования программного обеспечения. Однако более широкое использование объектно-ориентированных языков программирования и сред модульного тестирования привело к созданию инструментов тестирования мутаций, которые тестируют отдельные части приложения.
Цели мутационного тестирования многочисленны:
Тестирование мутаций было первоначально предложено Ричардом Липтоном, студентом в 1971 г. , и впервые разработано и опубликовано ДеМилло, Липтоном и Сэйвордом. Первая реализация инструмента тестирования мутаций была осуществлена Тимоти Баддом в рамках своей докторской работы (под названием « Анализ мутаций» ) в 1980 году в Йельском университете .
В последнее время, с появлением огромных вычислительных мощностей, в сообществе компьютерных наук возродился анализ мутаций, и была проделана работа по определению методов применения тестирования на мутации к объектно-ориентированным языкам программирования и непроцедурным языкам, таким как XML , SMV и конечные автоматы .
В 2004 году компания Certess Inc. (ныне часть Synopsys ) распространила многие принципы на область проверки оборудования. В то время как анализ мутаций предполагает только обнаружение разницы в полученном выходе, Certess расширяет его, проверяя, действительно ли средство проверки в тестовой среде обнаружит разницу. Это расширение означает, что оцениваются все три этапа проверки, а именно: активация, распространение и обнаружение. Они назвали это функциональной квалификацией.
Нечеткое изображение можно рассматривать как частный случай тестирования мутаций. При фаззинге сообщения или данные, которыми обмениваются внутри интерфейсов связи (как внутри, так и между экземплярами программного обеспечения), мутируются, чтобы выявить сбои или различия в обработке данных. Codenomicon (2001) и Mu Dynamics (2005) развили концепции фаззинга до платформы тестирования мутаций с полным отслеживанием состояния, в комплекте с мониторами для тщательного тестирования реализаций протоколов.
Мутационное тестирование основано на двух гипотезах. Первая - гипотеза грамотного программиста . Эта гипотеза утверждает, что большинство ошибок программного обеспечения, вносимых опытными программистами, происходит из-за небольших синтаксических ошибок. Об этом говорит сайт https://intellect.icu . Вторая гипотеза называется эффектом связи . Эффект связи утверждает, что простые разломы могут каскадироваться или объединяться, образуя другие возникающие разломы.
Тонкие и важные недостатки также выявляются мутантами более высокого порядка, что дополнительно поддерживает эффект сцепления. Мутанты более высокого порядка становятся возможными благодаря созданию мутантов с более чем одной мутацией.
Тестирование мутаций выполняется путем выбора набора операторов мутации и последующего применения их к исходной программе по одному для каждого применимого фрагмента исходного кода. Результат применения к программе одного оператора мутации называется мутантом . Если набор тестов способен обнаружить изменение (т. Е. Один из тестов не проходит), то считается, что мутант погиб .
Например, рассмотрим следующий фрагмент кода C ++:
if ( a && b ) {
c = 1 ;
} else {
c = 0 ;
}
Оператор мутации условия заменит &&на ||и произведет следующий мутант:
if ( a || b ) {
c = 1 ;
} else {
c = 0 ;
}
Теперь, чтобы испытать этот мутант, должны быть выполнены следующие три условия:
a = 1и b = 0сделает это.Эти условия в совокупности называются моделью RIP .
Слабое тестирование мутаций (или слабое покрытие мутаций ) требует, чтобы выполнялись только первое и второе условия. Для строгого тестирования мутаций необходимо выполнение всех трех условий. Сильная мутация более эффективна, поскольку гарантирует, что набор тестов действительно сможет выявить проблемы. Слабая мутация тесно связана с методами покрытия кода . Требуется гораздо меньше вычислительной мощности, чтобы гарантировать, что набор тестов удовлетворяет тестированию слабых мутаций, чем тестирование сильных мутаций.
Однако бывают случаи, когда невозможно найти тестовый пример, который мог бы убить этого мутанта. Полученная программа поведенчески эквивалентна исходной. Такие мутанты называются эквивалентными мутантами .
Обнаружение эквивалентных мутантов - одно из самых больших препятствий для практического использования мутационного тестирования. Усилия, необходимые для проверки эквивалентности мутантов, могут быть очень высокими даже для небольших программ. Систематический обзор литературы по широкому спектру подходов к решению проблемы эквивалентных мутантов выявил 17 соответствующих методов (в 22 статьях) и три категории методов: обнаружение (DEM); предлагая (SEM); и избежание эквивалентного поколения мутантов (AEMG). Эксперимент показал, что мутация высшего порядка в целом и стратегия JudyDiffOp в частности обеспечивают многообещающий подход к проблеме эквивалентных мутантов.
Многие операторы мутации были изучены исследователями. Вот несколько примеров операторов мутации для императивных языков:
goto fail; +на *, -на/>на >=, ==и<=Эти операторы мутации также называются традиционными операторами мутации. Существуют также операторы мутации для объектно-ориентированных языков для параллельных конструкций, сложных объектов, таких как контейнеры, и т. Д. Операторы для контейнеров называются операторами мутации уровня класса . Например, инструмент muJava предлагает различные операторы мутации на уровне класса, такие как изменение модификатора доступа, вставка оператора приведения типов и удаление оператора приведения типов. Операторы мутации также были разработаны для тестирования программ на уязвимость
Какие метрики дает нам мутационное тестирование? К code coverage оно добавляет еще три, о которых мы сейчас поговорим.
Но для начала разберем терминологию.
Есть понятие убитых мутантов: это те мутанты, которых «прибили» наши тесты (то есть они их отловили).
Есть понятие escaped mutant (выживших мутантов). Это те мутанты, которым удалось избежать кары (то есть тесты их не поймали).
И есть понятия covered mutant — мутант, покрытый тестами, и обратный ему uncovered мутант, который вообще никаким тестом не покрыт (т.е. у нас есть код, в нем есть бизнес-логика, мы можем ее менять, но ни один тест эти изменения не проверяет).
Основной показатель, который нам дает мутационное тестирование, — MSI (mutation score indicator), отношение количества убитых мутантов к их общему количеству.
Второй показатель — это mutation code coverage. Он как раз является качественным, а не количественным, потому что показывает, какой объем бизнес-логики, которую можно ломать и делать это на регулярной основе, наши тесты отлавливают.
И последний показатель — это covered MSI, то есть более мягкий MSI. В этом случае мы рассчитываем MSI только для тех мутантов, которые были покрыты тестами.
Почему меньше половины программистов слышали об этом инструменте? Почему его не применяют повсеместно?
Первая проблема (одна из главных) — это скорость выполнения мутационного тестирования. В коде, если у нас десятки мутационных операторов, даже для простейшего класса мы можем сгенерировать сотни мутаций. На каждую мутацию нужно будет прогнать тесты. Если у нас, скажем, 5000 юнит-тестов, которые бегают десять минут, мутационное тестирование может занять часы.
Что можно сделать, чтобы это нивелировать? Запускайте тесты параллельно, в несколько потоков. Раскидывайте потоки на несколько машин. Это работает.
Второй способ — инкрементальные прогоны. Незачем каждый раз считать мутационные показатели для всей ветки — можно взять branch diff. Если вы используете фича-бранчи, вам будет легко это сделать: прогнать тесты только по тем файлам, которые изменились, и посмотреть, что у вас в данный момент в мастере творится, сравнить, проанализировать.
Следующая штука, которую можно делать, — это тюнинг мутаций. Так как мутационные операторы можно изменять, можно задавать некие правила, по которым они работают, то можно прекращать выполнение некоторых мутаций, если они заведомо ведут к проблемам.
Важный момент: мутационное тестирование подходит только для юнит-тестов. Несмотря на то, что его можно запустить и для интеграционных тестов, это заведомо провальная идея, потому что интеграционные (как и end-to-end) тесты выполняются гораздо медленнее и затрагивают гораздо больше кода. Вы просто никогда не дождетесь результатов. В принципе, этот механизм придуман и разработан исключительно для модульного тестирования.
Вторая проблема, которая может возникнуть с мутационными тестами, — это так называемые бесконечные мутанты. Например, есть простой код, простой цикл for:
Если заменить i++ на i--, то цикл превратится в бесконечный. Ваш код залипнет надолго. И мутационное тестирование довольно часто генерирует такие мутации.
Первое, что можно сделать, — тюнинг мутации. Очевидно, что менять i++ на i-- в цикле for — это очень плохая идея: в 99% случаев мы будем попадать на бесконечный цикл. Поэтому мы в своем инструменте такое делать запретили.
Второе и главное, что защитит вас от таких проблем, — это тайм-аут для прогона. Например, у того же PHPUnit есть возможность завершить тест по тайм-ауту независимо от того, куда он залип. PHPUnit через PCNTL вешает колбэки и сам считает время. Если тест не выполнился за какой-то период, он просто его прибивает и такой кейс считается убитым мутантом, потому что код, сгенерировавший мутации, действительно проверяется тестом, который действительно ловит проблему, указывая на то, что код стал нерабочим.
Эта проблема существует в теории мутационного тестирования. На практике с ней сталкиваются не очень часто, но знать о ней нужно.
Рассмотрим классический пример, ее иллюстрирующий. У нас есть умножение переменной А на -1 и деление А на -1. В общем случае эти операции приводят к одинаковому результату. Мы меняем знак у А. Соответственно, у нас есть мутация, которая позволяет два знака менять между собой. Логика программы такой мутацией не нарушается. Тесты и не должны ее ловить, не должны падать. Из-за таких идентичных мутантов возникают некоторые сложности.
Универсального решения нет — каждый решает эту проблему по-своему. Возможно, поможет какая-то система регистрации мутантов. Мы в Badoo сейчас о чем-то подобном думаем, будем мьютить их.
Code coverage — это важная метрика, ее надо отслеживать. Но этот показатель ничего не гарантирует: он не говорит о том, что вы в безопасности.
Мутационное тестирование поможет сделать ваши юнит-тесты лучше, а отслеживание code coverage — осмысленнее. Для вашего языка программирования и IDE уже есть инструмент, так что если у вас небольшой проект без заморочек, то прямо сегодня берите и пробуйте.
Начните хотя бы с прогона мутационных тестов вручную. Сделайте этот простой шаг и посмотрите, что вам это даст. Уверен, что вам понравится
Исследование, описанное в статье про Мутационное тестирование и Мутационный анализ и метрики, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое Мутационное тестирование и Мутационный анализ и метрики и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.
Комментарии
Оставить комментарий
Качество и тестирование программного обеспечения. Quality Assurance.
Термины: Качество и тестирование программного обеспечения. Quality Assurance.