Мутационное тестирование (или анализ мутаций, или программная мутация ) используется для разработки новых тестов программного обеспечения и оценки качества существующих тестов программного обеспечения. Мутационное тестирование включает в себя небольшие изменения программы. [1] Каждая мутировавшая версия называется мутантом, и тесты обнаруживают и отклоняют мутанты, заставляя поведение исходной версии отличаться от мутанта. Это называется убийством мутанта. Наборы тестов измеряются процентом убитых ими мутантов. Новые тесты могут быть разработаны для уничтожения дополнительных мутантов. Мутанты основаны на четко определенных операторах мутации.которые либо имитируют типичные ошибки программирования (например, используют неправильный оператор или имя переменной), либо заставляют создавать ценные тесты (например, деление каждого выражения на ноль). Цель состоит в том, чтобы помочь тестировщику разработать эффективные тесты или найти слабые места в тестовых данных, используемых для программы, или в частях кода, которые редко или никогда не используются во время выполнения . Мутационное тестирование - это форма тестирования методом белого ящика . [2] [3]
Вступление
Большая часть этой статьи посвящена «мутации программы», при которой программа модифицируется. Более общее определение анализа мутаций - это использование четко определенных правил, определенных для синтаксических структур, для внесения систематических изменений в программные артефакты. [4] Мутационный анализ применялся к другим задачам, но обычно применяется к тестированию. Таким образом, мутационное тестирование определяется как использование анализа мутаций для разработки новых тестов программного обеспечения или для оценки существующих тестов программного обеспечения. [4] Таким образом, анализ и тестирование мутаций можно применять к моделям проектирования, спецификациям, базам данных, тестам, XML и другим типам программных артефактов, хотя программные мутации являются наиболее распространенными. [5]
Обзор
Тесты могут быть созданы для проверки правильности реализации данной программной системы, но создание тестов по-прежнему ставит вопрос о том, являются ли тесты правильными и достаточно ли они покрывают требования, которые послужили причиной реализации. [6] (Эта технологическая проблема сама по себе является примером более глубокой философской проблемы под названием « Quis custodiet ipsos custodes? » [«Кто будет охранять стражу?»].) Идея состоит в том, что если мутант представлен, не будучи обнаруженным набор тестов, это означает, что либо измененный код никогда не выполнялся (мертвый код), либо набор тестов не смог обнаружить ошибки, представленные мутантом.
Чтобы это работало в любом масштабе, обычно вводится большое количество мутантов, что приводит к компиляции и выполнению чрезвычайно большого количества копий программы. Эта проблема стоимости тестирования мутаций уменьшила его практическое использование в качестве метода тестирования программного обеспечения. Однако более широкое использование объектно-ориентированных языков программирования и сред модульного тестирования привело к созданию инструментов тестирования мутаций, которые тестируют отдельные части приложения.
Цели
У тестирования мутаций несколько целей:
- идентифицировать слабо протестированные фрагменты кода (те, для которых мутанты не убиваются) [1]
- выявить слабые тесты (те, которые никогда не убивают мутантов) [7]
- вычислить оценку мутации, [4] оценка мутации - это количество убитых мутантов / общее количество мутантов.
- узнать о распространении ошибок и состоянии заражения в программе [8]
История
Тестирование мутаций было первоначально предложено Ричардом Липтоном, студентом в 1971 г. [9], и впервые разработано и опубликовано ДеМилло, Липтоном и Сэйвордом. [1] Первая реализация инструмента тестирования мутаций была осуществлена Тимоти Баддом в рамках своей докторской работы (под названием « Анализ мутаций» ) в 1980 году в Йельском университете . [10]
В последнее время, с появлением огромных вычислительных мощностей, в сообществе компьютерных наук возродился анализ мутаций, и была проделана работа по определению методов применения тестирования на мутации к объектно-ориентированным языкам программирования и непроцедурным языкам, таким как XML , SMV и конечные автоматы .
В 2004 году компания Certess Inc. (ныне часть Synopsys ) распространила многие принципы на область проверки оборудования. В то время как анализ мутаций предполагает только обнаружение разницы в полученном выходе, Certess расширяет его, проверяя, действительно ли средство проверки в тестовой среде обнаружит разницу. Это расширение означает, что оцениваются все три этапа проверки, а именно: активация, распространение и обнаружение. Они назвали это функциональной квалификацией.
Нечеткость можно рассматривать как частный случай тестирования мутаций. При фаззинге сообщения или данные, которыми обмениваются внутри интерфейсов связи (как внутри, так и между экземплярами программного обеспечения), видоизменяются для выявления сбоев или различий в обработке данных. Codenomicon [11] (2001) и Mu Dynamics (2005) развили концепции фаззинга до платформы тестирования мутаций с полным отслеживанием состояния, в комплекте с мониторами для тщательного тестирования реализаций протоколов.
Обзор мутационного тестирования
Мутационное тестирование основано на двух гипотезах. Первая - гипотеза грамотного программиста . Эта гипотеза утверждает, что большинство ошибок программного обеспечения, вносимых опытными программистами, происходит из-за небольших синтаксических ошибок. [1] Вторая гипотеза называется эффектом связи . Эффект связи утверждает, что простые разломы могут каскадировать или объединяться, образуя другие возникающие разломы. [12] [13]
Тонкие и важные недостатки также выявляются мутантами более высокого порядка, что дополнительно поддерживает эффект сцепления. [14] [15] [7] [16] [17] Мутанты более высокого порядка становятся возможными благодаря созданию мутантов с более чем одной мутацией.
Тестирование мутаций выполняется путем выбора набора операторов мутации и последующего применения их к исходной программе по одному для каждого применимого фрагмента исходного кода. Результат применения к программе одного оператора мутации называется мутантом . Если набор тестов способен обнаружить изменение (т. Е. Один из тестов не проходит), то считается, что мутант погиб .
Например, рассмотрим следующий фрагмент кода C ++:
если ( а && б ) { с = 1 ; } else { c = 0 ; }
Оператор мутации условия заменит &&
на ||
и произведет следующий мутант:
если ( a || b ) { c = 1 ; } else { c = 0 ; }
Теперь, чтобы испытать этот мутант, должны быть выполнены следующие три условия:
- Тест должен достичь измененного утверждения.
- Входные данные теста должны влиять на состояние программы, вызывая разные состояния программы для мутанта и исходной программы. Например, тест с
a = 1
иb = 0
сделает это. - Неправильное состояние программы (значение 'c') должно распространяться на выходные данные программы и проверяться тестом.
Эти условия в совокупности называются моделью RIP . [9]
Слабое тестирование мутаций (или слабое покрытие мутаций ) требует, чтобы выполнялись только первое и второе условия. Для строгого тестирования мутаций необходимо, чтобы выполнялись все три условия. Сильная мутация более эффективна, поскольку гарантирует, что набор тестов действительно сможет выявить проблемы. Слабая мутация тесно связана с методами покрытия кода . Требуется гораздо меньше вычислительной мощности, чтобы гарантировать, что набор тестов удовлетворяет тестированию слабых мутаций, чем тестирование сильных мутаций.
Однако есть случаи, когда невозможно найти тестовый пример, который мог бы убить этого мутанта. Полученная программа поведенчески эквивалентна исходной. Такие мутанты называются эквивалентными мутантами .
Обнаружение эквивалентных мутантов - одно из самых больших препятствий для практического использования мутационного тестирования. Усилия, необходимые для проверки эквивалентности мутантов, могут быть очень высокими даже для небольших программ. [18] Систематический обзор литературы по широкому спектру подходов к решению проблемы эквивалентных мутантов [19] выявил 17 соответствующих методов (в 22 статьях) и три категории методов: обнаружение (DEM); предлагая (SEM); и избежание эквивалентного поколения мутантов (AEMG). Эксперимент показал, что мутация высшего порядка в целом и стратегия JudyDiffOp в частности обеспечивают многообещающий подход к проблеме эквивалентных мутантов.
Операторы мутации
Исследователями были изучены многие операторы мутации. Вот несколько примеров операторов мутации для императивных языков:
- Удаление выписки
- Дублирование или вставка операторов, например
goto fail;
[20] - Замена логических подвыражений на true и false
- Замена одних арифметических операций другими, например,
+
на*
,-
на/
- Замена одних логических отношений на другие, например,
>
на>=
,==
и<=
- Замена переменных другими из той же области видимости (типы переменных должны быть совместимы)
- Удалить тело метода, [21] реализовано в Pitest [22]
Эти операторы мутации также называются традиционными операторами мутации. Существуют также операторы мутации для объектно-ориентированных языков, [23] для параллельных конструкций, [24] сложных объектов, таких как контейнеры, [25] и т. Д. Операторы для контейнеров называются операторами мутации уровня класса . Например, инструмент muJava предлагает различные операторы мутации на уровне класса, такие как изменение модификатора доступа, вставка оператора приведения типов и удаление оператора приведения типов. Операторы мутации также были разработаны для тестирования уязвимостей безопасности программ. [26]
Смотрите также
- Bebugging (или посев ошибок)
- Проверка здравомыслия
- Внедрение неисправности
Рекомендации
- ^ a b c d Ричард А. Де Милло, Ричард Дж. Липтон и Фред Г. Сэйворд. Подсказки по отбору тестовых данных: Помощь практикующему программисту. IEEE Computer, 11 (4): 34-41. Апрель 1978 г.
- ^ Östrand, Томас (2002), "White-Box Testing" , Энциклопедия Software Engineering , American Cancer Society, DOI : 10.1002 / 0471028959.sof378 , ISBN 978-0-471-02895-6, получено 2021-03-16
- ^ Мисра, С. (2003). «Оценка четырех методологий тестового покрытия белого ящика» . CCECE 2003 - Канадская конференция по электротехнике и вычислительной технике. На пути к заботе и гуманным технологиям (Кат. № 03CH37436) . Монреаль, Квебек, Канада: IEEE. 3 : 1739–1742. DOI : 10,1109 / CCECE.2003.1226246 . ISBN 978-0-7803-7781-3.
- ^ a b c Пол Амманн и Джефф Оффатт. Введение в тестирование программного обеспечения. Издательство Кембриджского университета, 2008.
- ^ Цзя, Юэ; Харман, Марк (сентябрь 2009 г.). «Анализ и обзор развития тестирования мутаций» (PDF) . Центр CREST, Королевский колледж Лондона , Технический отчет TR-09-06 . Архивировано из оригинального (PDF) 04.12.2017. CS1 maint: обескураженный параметр ( ссылка )
- ^ Дассо, Аристидес; Фунес, Ана (2007). Верификация, валидация и тестирование в программной инженерии . Idea Group Inc. ISBN 1591408512.
- ^ a b Смит Б., «О руководстве по расширению автоматизированного набора тестов с помощью анализа мутаций», 2008 г.
- ^ Муско, Винченцо; Монперрус, Мартин; Preux, Филипп (2016). «Графический вывод на основе мутаций для локализации неисправности» . DOI : 10,1109 / SCAM.2016.24 . Цитировать журнал требует
|journal=
( помощь ) - ^ Б Мутация 2000: Объединить с ортогональным по А. Джефферсон Offutt и Roland H. Untch.
- ^ Тим А. Бадд, Мутационный анализ данных тестирования программ. Кандидатская диссертация, Йельский университет, Нью-Хейвен, штат Коннектикут, 1980.
- ^ Каксонен, Раули. Функциональный метод оценки безопасности реализации протокола (дипломная работа). Эспоо. 2001 г.
- ^ А. Джефферсон Оффутт. 1992. Исследование эффекта сопряжения тестирования программного обеспечения. ACM Trans. Софтв. Англ. Методол. 1, 1 (январь 1992 г.), 5-20.
- ^ AT Акри, TA Бадд, RA DeMillo, RJ Lipton, и FG Сейвард, "Мутация анализ," Технологический институт Джорджии, Атланта, штат Джорджия, Technique Отчет GIT-ICS-79/08, 1979.
- ^ Юэ Цзя; Харман, М., «Построение неявных неисправностей с использованием тестирования мутаций более высокого порядка», Анализ и обработка исходного кода, Восьмая международная рабочая конференция IEEE, 2008 г., том, №, стр. 249,258, 28-29 сентября 2008 г.
- ↑ Марьям Умар, «Оценка операторов мутаций для эквивалентных мутантов», MS Thesis, 2006
- ^ Поло М. и Пиаттини М., «Мутационное тестирование: практические аспекты и анализ затрат», Университет Кастилии-Ла-Манча (Испания), презентация, 2009 г.
- ↑ Андерсон С., «Тестирование мутаций», Эдинбургский университет, школа информатики, презентация, 2011 г.
- ^ PG Франкл, С.Н. Вайс, С. Ху. Тестирование универсальности и мутации: экспериментальное сравнение эффективности. Журнал систем и программного обеспечения , 38: 235–253, 1997.
- ^ Преодоление эквивалентной проблемы мутанта: систематический обзор литературы и сравнительный эксперимент мутации второго порядка Л. Мадейски, В. Ожешина, Р. Торкар, М. Йозала. IEEE Transactions по разработке программного обеспечения
- ^ Ошибка Apple SSL / TLS , Адам Лэнгли.
- ^ Нидермайр, Райнер; Юргенс, Эльмар; Вагнер, Стефан (14 мая 2016 г.). «Могут ли мои тесты сказать мне, если я нарушу этот код?» . Материалы международного семинара по непрерывной эволюции и доставке программного обеспечения . CSED '16. Остин, Техас: Ассоциация вычислительной техники: 23–29. arXiv : 1611.07163 . DOI : 10.1145 / 2896941.2896944 . ISBN 978-1-4503-4157-8.
- ^ Вера-Перес, Оскар Луис; Монперрус, Мартин; Бодри, Бенуа (2018). «Декарт: механизм PITest для обнаружения псевдотестированных методов: демонстрация инструмента» . Труды 33-й Международной конференции ACM / IEEE по автоматизированной разработке программного обеспечения - ASE 2018 . Монпелье, Франция: ACM Press: 908–911. arXiv : 1811.03045 . DOI : 10.1145 / 3238147.3240474 .
- ^ MuJava: Автоматическая система мутации классов Ю-Сын Ма, Джеффа Оффутта и Ён Рэ Кво.
- ^ Операторы мутации для параллельной Java (J2SE 5.0) Джереми С. Брэдбери, Джеймс Р. Корди, Юрген Дингел.
- ^ Мутация объектов Java Роджером Т. Александром, Джеймсом М. Биманом, Судипто Гошем, Биксией Джи.
- ^ Основанное на мутации тестирование переполнения буфера, SQL-инъекций и ошибок форматной строки Х. Шахриар и М. Зулкернин.