Мутационное тестирование - Mutation testing

«Анализ мутаций» перенаправляется сюда. Для биологического термина см. Анализ мутации генов.

Мутационное тестирование (или же анализ мутаций или же программная мутация) используется для разработки новых тестов программного обеспечения и оценки качества существующих тестов программного обеспечения. Мутационное тестирование включает в себя небольшие модификации программы.[1] Каждая измененная версия называется мутант и тесты обнаруживают и отклоняют мутанты, заставляя поведение исходной версии отличаться от мутанта. Это называется убийство мутант. Наборы тестов измеряются процентом убитых ими мутантов. Новые тесты могут быть разработаны для уничтожения дополнительных мутантов. Мутанты основаны на четко определенных операторы мутации которые либо имитируют типичные ошибки программирования (например, используют неправильный оператор или имя переменной), либо заставляют создавать ценные тесты (например, деление каждого выражения на ноль). Цель состоит в том, чтобы помочь тестировщику разработать эффективные тесты или найти слабые места в тестовых данных, используемых для программы, или в частях кода, которые редко или никогда не доступны во время исполнение. Мутационное тестирование - это форма тестирование методом белого ящика.

Вступление

Большая часть этой статьи посвящена «мутации программы», при которой программа модифицируется. Более общее определение анализ мутаций использует четко определенные правила, определенные для синтаксических структур, для внесения систематических изменений в программные артефакты.[2] Мутационный анализ применялся к другим задачам, но обычно применяется к тестированию. Так мутации определяется как использование анализа мутаций для разработки новых тестов программного обеспечения или для оценки существующих тестов программного обеспечения.[2] Таким образом, анализ и тестирование мутаций можно применять к моделям проектирования, спецификациям, базам данных, тестам, XML и другим типам программных артефактов, хотя программные мутации являются наиболее распространенными.[3]

Обзор

Тесты могут быть созданы для проверки правильности реализации данной программной системы, но создание тестов по-прежнему ставит вопрос о том, являются ли тесты правильными и достаточно ли они покрывают требования, которые послужили причиной реализации.[4] (Эта технологическая проблема сама по себе является примером более глубокой философской проблемы под названием "Quis custodiet ipsos custodes? «[« Кто будет охранять стражников? »].) Идея состоит в том, что если мутант вводится без обнаружения тестовым набором, это указывает либо на то, что измененный код никогда не выполнялся (мертвый код), либо что Набор тестов не смог обнаружить неисправности, представленные мутантом.

Для того, чтобы это работало в любом масштабе, обычно вводится большое количество мутантов, что приводит к компиляции и выполнению чрезвычайно большого количества копий программы. Эта проблема стоимости тестирования мутаций уменьшила его практическое использование в качестве метода тестирования программного обеспечения. Однако более широкое использование объектно-ориентированные языки программирования и модульное тестирование frameworks привел к созданию инструментов тестирования мутаций, которые тестируют отдельные части приложения.

Цели

У тестирования мутаций несколько целей:

  • идентифицировать слабо протестированные фрагменты кода (те, для которых мутанты не убиваются)[1]
  • определить слабые тесты (те, которые никогда не убивают мутантов)[5]
  • вычислить оценку мутации,[2] оценка мутации - это количество убитых мутантов / общее количество мутантов.
  • узнать о распространении ошибок и состоянии заражения в программе[6]

История

Тестирование мутаций было первоначально предложено Ричардом Липтоном, студентом в 1971 году.[7] и впервые разработан и опубликован DeMillo, Lipton и Sayward.[1] Первая реализация инструмента тестирования мутаций была сделана Тимоти Бадд как часть его кандидат наук работа (под названием Мутационный анализ) в 1980 г. Йельский университет.[8]

Недавно, с появлением огромных вычислительных мощностей, в сообществе компьютерных наук возродился анализ мутаций, и была проделана работа по определению методов применения тестирования на мутации к объектно-ориентированные языки программирования и непроцедурные языки Такие как XML, SMV, и конечные автоматы.

В 2004 году компания Certess Inc. (ныне часть Synopsys ) распространил многие принципы на область проверки оборудования. В то время как анализ мутаций предполагает только обнаружение различий в полученных результатах, Certess расширяет его, проверяя, действительно ли средство проверки в тестовой среде обнаружит разницу. Это расширение означает, что оцениваются все три этапа проверки, а именно: активация, распространение и обнаружение. Они назвали это функциональной квалификацией.

Расплывание можно рассматривать как частный случай мутационного тестирования. При фаззинге сообщения или данные, которыми обмениваются внутри интерфейсов связи (как внутри, так и между экземплярами программного обеспечения), мутируются, чтобы выявить сбои или различия в обработке данных. Коденомикон[9] (2001) и Mu Dynamics (2005) эволюционировал расплывание от концепций до платформы для тестирования мутаций с полным отслеживанием состояния, в комплекте с мониторами для тщательного тестирования реализаций протоколов.

Обзор мутационного тестирования

Мутационное тестирование основано на двух гипотезах. Первый - это грамотный программист гипотеза. Эта гипотеза утверждает, что большинство ошибок программного обеспечения, вносимых опытными программистами, происходит из-за небольших синтаксических ошибок.[1] Вторая гипотеза называется эффект сцепления. Эффект связи утверждает, что простые неисправности могут каскадировать или пара для формирования других возникающих неисправностей.[10][11]

Тонкие и важные ошибки также выявляются мутантами более высокого порядка, что дополнительно поддерживает эффект сцепления.[12][13][5][14][15] Мутанты более высокого порядка становятся возможными благодаря созданию мутантов с более чем одной мутацией.

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

Например, рассмотрим следующий фрагмент кода C ++:

если (а && б) {    c = 1;} еще {    c = 0;}

Оператор мутации условия заменит && с || и произвести следующего мутанта:

если (а || б) {    c = 1;} еще {    c = 0;}

Теперь, чтобы испытать этот мутант, должны быть выполнены следующие три условия:

  1. Тест должен достигать измененное утверждение.
  2. Входные данные теста должны заразить состояние программы, вызывая разные состояния программы для мутанта и исходной программы. Например, тест с а = 1 и б = 0 сделал бы это.
  3. Неправильное состояние программы (значение 'c') должно размножаться к выходу программы и проверяться тестом.

Эти условия в совокупности называются Модель RIP.[7]

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

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

Обнаружение эквивалентных мутантов - одно из самых больших препятствий для практического использования мутационного тестирования. Усилия, необходимые для проверки, эквивалентны ли мутанты или нет, могут быть очень высокими даже для небольших программ.[16] Систематический обзор литературы по широкому спектру подходов к решению проблемы эквивалентных мутантов.[17] определили 17 соответствующих методов (в 22 статьях) и три категории методов: обнаружение (DEM); предлагая (SEM); и избегая поколения эквивалентных мутантов (AEMG). Эксперимент показал, что мутация высшего порядка в целом и стратегия JudyDiffOp в частности обеспечивают многообещающий подход к проблеме эквивалентных мутантов.

Операторы мутации

Многие операторы мутации были изучены исследователями. Вот несколько примеров операторов мутации для императивных языков:

  • Удаление выписки
  • Дублирование или вставка оператора, например перейти к неудаче;[18]
  • Замена логических подвыражений на истинный и ложный
  • Замена одних арифметических операций другими, например + с *, - с /
  • Замена одних булевых отношений другими, например > с >=, == и <=
  • Замена переменных другими из той же области видимости (типы переменных должны быть совместимы)
  • Удалить тело метода,[19] реализовано в Питесте[20]

Эти операторы мутации также называются традиционными операторами мутации. Существуют также операторы мутации для объектно-ориентированных языков,[21] для параллельных построек,[22] сложные объекты, такие как контейнеры,[23] и т.д. Операторы для контейнеров называются уровень класса операторы мутации. Например, инструмент muJava предлагает различные операторы мутации на уровне класса, такие как изменение модификатора доступа, вставка оператора приведения типов и удаление оператора приведения типов. Операторы мутации также были разработаны для выполнения тестирования программ на уязвимость.[24]

Смотрите также

Рекомендации

  1. ^ а б c d Ричард А. ДеМилло, Ричард Дж. Липтон и Фред Г. Сэйворд. Подсказки по отбору тестовых данных: Помощь практикующему программисту. IEEE Computer, 11 (4): 34-41. Апрель 1978 г.
  2. ^ а б c Пол Амманн и Джефф Оффатт. Введение в тестирование программного обеспечения. Издательство Кембриджского университета, 2008.
  3. ^ Цзя, Юэ; Харман, Марк (Сентябрь 2009 г.). "Анализ и обзор развития мутационного тестирования" (PDF). Центр CREST, Королевский колледж Лондона, Технический отчет TR-09-06.
  4. ^ Дассо, Аристидес; Фунес, Ана (2007). Верификация, валидация и тестирование в программной инженерии. Idea Group Inc. ISBN  1591408512.
  5. ^ а б Смит Б., «О руководстве по расширению автоматизированного набора тестов с помощью анализа мутаций», 2008 г.
  6. ^ Муско, Винченцо; Монперрус, Мартин; Preux, Филипп (2016). «Графический вывод на основе мутаций для локализации неисправности». Дои:10.1109 / SCAM.2016.24. Цитировать журнал требует | журнал = (помощь)
  7. ^ а б Мутация 2000: объединение ортогональных к А. Джефферсон Оффатт и Роланд Х. Унч.
  8. ^ Тим А. Бадд, Мутационный анализ данных тестирования программ. Кандидатская диссертация, Йельский университет, Нью-Хейвен, Коннектикут, 1980.
  9. ^ Каксонен, Раули. Функциональный метод оценки безопасности реализации протокола (дипломная работа). Эспоо. 2001 г.
  10. ^ А. Джефферсон Оффутт. 1992. Исследование эффекта сопряжения тестирования программного обеспечения. ACM Trans. Софтв. Англ. Методол. 1, 1 (январь 1992 г.), 5-20.
  11. ^ А. Т. Акри, Т. А. Бадд, Р. А. Де Милло, Р. Дж. Липтон и Ф. Г. Сэйворд, «Анализ мутаций», Технологический институт Джорджии, Атланта, Джорджия, технический отчет GIT-ICS-79/08, 1979.
  12. ^ Юэ Цзя; Харман, М., «Построение неявных неисправностей с использованием тестирования мутаций более высокого порядка», Анализ и обработка исходного кода, Восьмая международная рабочая конференция IEEE, 2008 г., том, №, стр. 249,258, 28-29 сентября 2008 г.
  13. ^ Марьям Умар, "Оценка операторов мутаций для эквивалентных мутантов", дипломная работа, 2006 г.
  14. ^ Поло М. и Пиаттини М., «Мутационное тестирование: практические аспекты и анализ затрат», Университет Кастилии-Ла-Манча (Испания), презентация, 2009 г.
  15. ^ Андерсон С., «Тестирование мутаций», Эдинбургский университет, школа информатики, презентация, 2011 г.
  16. ^ П. Г. Франкл, С. Н. Вайс и К. Ху. Универсальное использование и тестирование на мутации: экспериментальное сравнение эффективности. Журнал систем и программного обеспечения, 38:235–253, 1997.
  17. ^ Преодоление проблемы эквивалентного мутанта: систематический обзор литературы и сравнительный эксперимент мутации второго порядка Л. Мадейски, В. Ожешина, Р. Торкар, М. Йозала. IEEE Transactions по разработке программного обеспечения
  18. ^ Ошибка SSL / TLS от Apple пользователя Адам Лэнгли.
  19. ^ Нидермайр, Райнер; Юргенс, Эльмар; Вагнер, Стефан (14 мая 2016 г.). «Могут ли мои тесты сказать мне, если я нарушу этот код?». Материалы международного семинара по непрерывной эволюции и доставке программного обеспечения. CSED '16. Остин, Техас: Ассоциация вычислительной техники: 23–29. Дои:10.1145/2896941.2896944. ISBN  978-1-4503-4157-8.
  20. ^ Вера-Перес, Оскар Луис; Монперрус, Мартин; Бодри, Бенуа (2018). «Декарт: механизм PITest для обнаружения псевдотестированных методов: демонстрация инструмента». Материалы 33-й Международной конференции ACM / IEEE по автоматизированной разработке программного обеспечения - ASE 2018. Монпелье, Франция: ACM Press: 908–911. Дои:10.1145/3238147.3240474.
  21. ^ MuJava: автоматическая система мутации классов Ю-Сын Ма, Джефф Оффатт и Ён Рэ Кво.
  22. ^ Операторы мутации для параллельной Java (J2SE 5.0) Джереми С. Брэдбери, Джеймс Р. Корди, Юрген Дингел.
  23. ^ Мутация объектов Java Роджер Т. Александер, Джеймс М. Биман, Судипто Гош, Биксия Джи.
  24. ^ Тестирование на основе мутаций переполнения буфера, SQL-инъекций и ошибок форматной строки Х. Шахриар и М. Зулкернин.