КГТУ Лекция 1: Обеспечение Качества Программного ОбеспеченияIosif Itkin
Курс Лекций:
Обеспечение Качества Программного Обеспечения
Вводная Лекция: Основные Принципы
Максим Рудовский, Инновационные Трейдинговые Системы
Иосиф Иткин, Exactpro Systems
Задорная презентация, посвещенная введению в разработку через тестирование. В частности, рассмотрены такие методологии как TDD (Test-Driven Development) и BDD (Behavior-Driven Devopment), их несомненные достоинства и недостатки, а также практическое применение.
Презентация подготовлена по материалам прошедшей 10.10.2013 конференции "Developers Software Conference 2013" в Витебске, организатором которой выступила компания "EPAM Systems".
ПРИМЕНЕНИЕ ГЕНЕТИЧЕСКИХ АЛГОРИТМОВ К ГЕНЕРАЦИИ ТЕСТОВ ДЛЯ АВТОМАТНЫХ ПРОГРАММITMO University
Описан подход к автоматизации тестирования автоматных программ. Для формализации требований спецификации к модели и объектам управления предлагается использовать контракты. Тест описывается как последовательность переходов в модели. Для автоматизации процесса создания кода теста предложен генетический алгоритм, который позволяет находить значения переменных, удовлетворяющие условиям на переходах.
Кирилл Черятов. Эволюция системы логирования интеграционного ПО. Сокращаем вр...ScrumTrek
Автоматизация бизнес-процессов часто подразумевает интеграцию большого количества IT систем. При производстве такого ПО серьезной проблемой является сбор и анализ логов систем. Эта проблема актуальная и для системы FORIS, которая поддерживает бизнес МТС.
Мы разберем проблемы, которые подтолкнули к разработке системы Central Logging, обозначим решение этих проблем, узнаем, какое отношение имеет игра пинг-понг к разработке программного обеспечения, а так же, как Central Logging помогла нам меньше играть в пинг-понг и больше времени тратить на разработку новых задач для заказчика.
Модели в профессиональной инженерии и тестировании программ. Александр Петрен...yaevents
Александр Петренко, ИСП РАН
Профессор, доктор физико-математических наук, заведующий отделом технологий программирования Института системного программирования (ИСП РАН), профессор ВМК МГУ. Основные работы в областях: формализация требований, генерация тестов на основе формализованных требований и формальных моделей (model based testing – MBT). Приложения: тестирование операционных систем и распределенных систем, тестирование компиляторов, верификация дизайна микропроцессоров, формализация стандартов на API операционных систем и телекоммуникационных протоколов. Сопредседатель оргкомитетов International MBT workshop (http://www.mbrworkshop.org/), Spring Young Researcher Colloquium on Software Engineering – SYRCoSE (http://syrocose.ispras.ru), городского семинара по технологиям разработки и анализа программ ТРАП/SDAT (http://sdat.ispras.ru/).
Тема доклада
Модели в профессиональной инженерии и тестировании программ.
Тезисы
Model Based Software Engineering (MBSE) является расширением подхода к разработке программ на основе моделей. В MBSE в отличие, например, от MDA (Model Driver Architecture) существенное внимание уделяется не только задачам собственно проектирования и разработки кода, но и задачам других фаз жизненного цикла – анализу требований, верификации и валидации, управлению требованиями на всех фазах жизненного цикла. Model Based Testing (MBT) хронологически возник гораздо раньше, чем MBSE и MDA, однако его место в разработке программ в полной мере раскрылось вместе с развитием MBSE. По этой причине MBT и MBSE следует рассматривать в тесной связке. В докладе будут рассмотрены концепции MBSE-MDA-MBT, основные источники и виды моделей, которые используются в этих подходах, методы генерации тестов на основе моделей, известные инструменты для
На встрече мы поговорим о том, как не бояться изменений и как быть к ним готовым. Дадим определение АОП. Рассмотрим проблемы, хорошо решаемые инструментами АОП. Построим модульную систему, применяя АОП. Сравним динамический и статический подходы в АОП. Дадим рекомендации по применению АОП.
Вас ждет река теории впадающая в море практики.
В любой программе разработчики сталкиваются с необходимостью обработки ошибок. Основной механизм работы с ошибками в .NET Framework — это исключения. Мы поговорим о преимуществах и недостатках их использования. Вы узнаете, используются ли исключения для обработки ошибок в программном обеспечении марсохода NASA, а также о том, какие способы обработки исключений имеются в нашем распоряжении. Также обсудим, можно ли не использовать исключения для обработки ошибочных ситуаций. Приходите, будет интересно.
Moscow .Net Meetup #3
13 октября 2016
Статья рассказывает о новом направлении в развитии статических анализаторов кода - верификации параллельных программ. В статье рассказывается о нескольких статических анализаторах, которые могут претендовать на звание "Parallel Lint".
Тестирование параллельного программного обеспечения представляет собой более сложную задачу по сравнению с тестированием последовательной программы. Программист должен знать о подводных камнях при тестировании параллельного кода, имеющихся методологиях и инструментарии.
КГТУ Лекция 1: Обеспечение Качества Программного ОбеспеченияIosif Itkin
Курс Лекций:
Обеспечение Качества Программного Обеспечения
Вводная Лекция: Основные Принципы
Максим Рудовский, Инновационные Трейдинговые Системы
Иосиф Иткин, Exactpro Systems
Задорная презентация, посвещенная введению в разработку через тестирование. В частности, рассмотрены такие методологии как TDD (Test-Driven Development) и BDD (Behavior-Driven Devopment), их несомненные достоинства и недостатки, а также практическое применение.
Презентация подготовлена по материалам прошедшей 10.10.2013 конференции "Developers Software Conference 2013" в Витебске, организатором которой выступила компания "EPAM Systems".
ПРИМЕНЕНИЕ ГЕНЕТИЧЕСКИХ АЛГОРИТМОВ К ГЕНЕРАЦИИ ТЕСТОВ ДЛЯ АВТОМАТНЫХ ПРОГРАММITMO University
Описан подход к автоматизации тестирования автоматных программ. Для формализации требований спецификации к модели и объектам управления предлагается использовать контракты. Тест описывается как последовательность переходов в модели. Для автоматизации процесса создания кода теста предложен генетический алгоритм, который позволяет находить значения переменных, удовлетворяющие условиям на переходах.
Кирилл Черятов. Эволюция системы логирования интеграционного ПО. Сокращаем вр...ScrumTrek
Автоматизация бизнес-процессов часто подразумевает интеграцию большого количества IT систем. При производстве такого ПО серьезной проблемой является сбор и анализ логов систем. Эта проблема актуальная и для системы FORIS, которая поддерживает бизнес МТС.
Мы разберем проблемы, которые подтолкнули к разработке системы Central Logging, обозначим решение этих проблем, узнаем, какое отношение имеет игра пинг-понг к разработке программного обеспечения, а так же, как Central Logging помогла нам меньше играть в пинг-понг и больше времени тратить на разработку новых задач для заказчика.
Модели в профессиональной инженерии и тестировании программ. Александр Петрен...yaevents
Александр Петренко, ИСП РАН
Профессор, доктор физико-математических наук, заведующий отделом технологий программирования Института системного программирования (ИСП РАН), профессор ВМК МГУ. Основные работы в областях: формализация требований, генерация тестов на основе формализованных требований и формальных моделей (model based testing – MBT). Приложения: тестирование операционных систем и распределенных систем, тестирование компиляторов, верификация дизайна микропроцессоров, формализация стандартов на API операционных систем и телекоммуникационных протоколов. Сопредседатель оргкомитетов International MBT workshop (http://www.mbrworkshop.org/), Spring Young Researcher Colloquium on Software Engineering – SYRCoSE (http://syrocose.ispras.ru), городского семинара по технологиям разработки и анализа программ ТРАП/SDAT (http://sdat.ispras.ru/).
Тема доклада
Модели в профессиональной инженерии и тестировании программ.
Тезисы
Model Based Software Engineering (MBSE) является расширением подхода к разработке программ на основе моделей. В MBSE в отличие, например, от MDA (Model Driver Architecture) существенное внимание уделяется не только задачам собственно проектирования и разработки кода, но и задачам других фаз жизненного цикла – анализу требований, верификации и валидации, управлению требованиями на всех фазах жизненного цикла. Model Based Testing (MBT) хронологически возник гораздо раньше, чем MBSE и MDA, однако его место в разработке программ в полной мере раскрылось вместе с развитием MBSE. По этой причине MBT и MBSE следует рассматривать в тесной связке. В докладе будут рассмотрены концепции MBSE-MDA-MBT, основные источники и виды моделей, которые используются в этих подходах, методы генерации тестов на основе моделей, известные инструменты для
На встрече мы поговорим о том, как не бояться изменений и как быть к ним готовым. Дадим определение АОП. Рассмотрим проблемы, хорошо решаемые инструментами АОП. Построим модульную систему, применяя АОП. Сравним динамический и статический подходы в АОП. Дадим рекомендации по применению АОП.
Вас ждет река теории впадающая в море практики.
В любой программе разработчики сталкиваются с необходимостью обработки ошибок. Основной механизм работы с ошибками в .NET Framework — это исключения. Мы поговорим о преимуществах и недостатках их использования. Вы узнаете, используются ли исключения для обработки ошибок в программном обеспечении марсохода NASA, а также о том, какие способы обработки исключений имеются в нашем распоряжении. Также обсудим, можно ли не использовать исключения для обработки ошибочных ситуаций. Приходите, будет интересно.
Moscow .Net Meetup #3
13 октября 2016
Статья рассказывает о новом направлении в развитии статических анализаторов кода - верификации параллельных программ. В статье рассказывается о нескольких статических анализаторах, которые могут претендовать на звание "Parallel Lint".
Тестирование параллельного программного обеспечения представляет собой более сложную задачу по сравнению с тестированием последовательной программы. Программист должен знать о подводных камнях при тестировании параллельного кода, имеющихся методологиях и инструментарии.
Использование шаблонов и RTTI для конфигурации симулятора флеш-накопителя - Г...Yandex
Флеш-накопители используются в самых разных устройствах, от мобильных телефонов до компьютеров и серверов. Для каждой модели накопителя нужна прошивка с определённым набором параметров, которые могут отличаться в зависимости от ситуации. В докладе будет описан универсальный фреймфорк на С++, который предоставляет разработчикам симуляторов простой, прозрачный и быстрый доступ к любому параметру. Тестировщикам же он позволяет управлять конфигурациями при помощи стандартных инструментов редактирования и слияния.
анализ кода: от проверки стиля до автоматического тестированияRuslan Shevchenko
Рассказ о истории и использовании в реальной жизни инструментов анализа кода на основе JavaChecker и TermWare
Сопустствующий текст: http://datacenter.gradsoft.ua/files/articles/OSDN2011/
Open Source Testing Framework: real project example and best practicesAliaksandr Ikhelis
Summary: Presentation on open source testing frameworks (improved version, more focus on real project example) at Software Engineering Forum 2009 (SEF-1) conference by Aliaksandr Ikhelis. Sponte framework developer and owner is Stanislaw Wozniak, Expedia Limited, UK. Sponte project homepage: http://rubyforge.org/projects/sponte/; http://github.com/swozniak/sponte/tree/master
Отладка и оптимизация многопоточных OpenMP-программTatyanazaxarova
Задача знакомства программистов с областью разработки параллельных приложений становится все актуальней. Данная статья является кратким введением в создание многопоточных приложений, основанных на технологии OpenMP. Описаны подходы к отладке и оптимизации параллельных приложений.
4. Проблемы тестирования Проблемы тестирования
Проблемы тестирования
What’s up, Doc? (с)
Проблема тестовых входных данных
Проблема наблюдаемости
Проблема «останова»
Проблема тестового оракула
Марат Ахин (СПбГПУ) NP 2014 150 / 320
5. Проблема «останова»
Содержание
1 Проблема «останова»
Проблема «останова» в тестировании
Тестовое покрытие
Покрытие потока управления
Покрытие потока данных
Мутационное тестирование
Оценка тестового покрытия
Марат Ахин (СПбГПУ) NP 2014 151 / 320
6. Проблема «останова» Проблема «останова» в тестировании
Проблема «останова» в тестировании
Проблема останова
По заданному алгоритму и входным данным определить, завершится
ли за конечное время его выполнение
При чем здесь тестирование?!
Марат Ахин (СПбГПУ) NP 2014 152 / 320
7. Проблема «останова» Проблема «останова» в тестировании
Проблема «останова» в тестировании
Алгоритм ⇔ процесс тестирования
Входные данные ⇔ тестируемая программа
В подавляющем большинстве случаев процесс тестирования является
бесконечным
Марат Ахин (СПбГПУ) NP 2014 153 / 320
8. Проблема «останова» Проблема «останова» в тестировании
Проблема «останова» в тестировании
Мы не можем позволить себе тестировать бесконечное время
Слишком долго
Слишком дорого
Слишком странно
Что же делать?
Марат Ахин (СПбГПУ) NP 2014 154 / 320
9. Проблема «останова» Проблема «останова» в тестировании
Проблема «останова» в тестировании
Останавливать процесс тестирования «вручную»
Когда?
У нас кончилось время и/или деньги на тестирование
Мы протестировали ПО достаточно хорошо
Марат Ахин (СПбГПУ) NP 2014 155 / 320
10. Проблема «останова» Проблема «останова» в тестировании
Проблема «останова» в тестировании
Проблема «останова» в тестировании
По заданному набору тестов и программе определить, протестировали
ли мы ее достаточно хорошо
Что такое – достаточно хорошо?
Марат Ахин (СПбГПУ) NP 2014 156 / 320
11. Проблема «останова» Тестовое покрытие
Тестовое покрытие
Мы протестировали программу достаточно хорошо, когда мы
нашли большую часть ошибок в программе
Чтобы найти ошибку, необходимо обеспечить выполнение трех
основных свойств
Обеспечение достижимости (reachability) и порчи (corruption)
требует, чтобы мы выполнили определенный участок кода с
определенными входными данными
Качество тестирования можно оценить через тестовое покрытие
Марат Ахин (СПбГПУ) NP 2014 157 / 320
12. Проблема «останова» Тестовое покрытие
Виды тестового покрытия
Выделяют два основных вида покрытия
Покрытие потока управления
Покрытие потока данных
Они работают с такими понятиями, как граф потока
управления (CFG) и граф потока данных (DFG)
Надеюсь, что все знают, что такое CFG и DFG?
Марат Ахин (СПбГПУ) NP 2014 158 / 320
13. Проблема «останова» Покрытие потока управления
Покрытие потока управления
Как мы можем покрыть данный
CFG?
По узлам
По дугам
По условиям
По путям
...
Марат Ахин (СПбГПУ) NP 2014 159 / 320
14. Проблема «останова» Покрытие потока управления
Покрытие операторов программы
Каждый узел CFG был пройден в
процессе тестирования хотя бы один раз
Самый слабый способ оценки тестового
покрытия
Сколько тестов требуется для того, чтобы
обеспечить полное покрытие операторов
программы для следующего примера?
Марат Ахин (СПбГПУ) NP 2014 160 / 320
15. Проблема «останова» Покрытие потока управления
Покрытие ветвлений программы
Каждая ветка программы была пройдена
хотя бы один раз
Несколько более сильный способ оценки
покрытия
Сколько тестов требуется для того, чтобы
обеспечить полное покрытие ветвлений
программы для следующего примера?
Марат Ахин (СПбГПУ) NP 2014 161 / 320
16. Проблема «останова» Покрытие потока управления
Покрытие ветвлений программы
Как соотносятся между собой покрытия
операторов и ветвлений?
1 Никак
2 Покрытие операторов включает покрытие
ветвлений
3 Покрытие ветвлений включает покрытие
операторов
Марат Ахин (СПбГПУ) NP 2014 162 / 320
17. Проблема «останова» Покрытие потока управления
Покрытие ветвлений программы
Никак
Почему покрытие ветвлений не включает
в себя покрытие операторов?
Потому что в программе может
присутствовать «мертвый код»
Потому что в программе могут вообще
отсутствовать ветвления
Марат Ахин (СПбГПУ) NP 2014 163 / 320
18. Проблема «останова» Покрытие потока управления
Покрытие условий программы
Каждое ветвление может выполняться по различным причинам
При покрытии условий программы мы требуем, чтобы все условия
ветвлений хотя бы один раз приняли значение true и false
1 if (req.isSsl () && (cfg.SslEnabled () || cfg.isDebug ())) {
2 ...
3 }
Как соотносятся между собой покрытия ветвлений и условий?
Марат Ахин (СПбГПУ) NP 2014 164 / 320
19. Проблема «останова» Покрытие потока управления
Покрытие условий программы
Никак
Разные комбинации условий могут приводить к выбору одного и
того же ветвления
1 if (req. isLocalhost () || cfg.isDebug () || cfg.isDevMode ()) {
2 ...
3 }
Марат Ахин (СПбГПУ) NP 2014 165 / 320
20. Проблема «останова» Покрытие потока управления
Покрытие ветвлений и условий программы
Комбинация соответствующих покрытий
Полностью их покрывает
Можно ли предложить что-то более сильное?
1 if (req.isSsl () && (cfg.SslEnabled () || cfg.isDebug ())) {
2 ...
3 }
Марат Ахин (СПбГПУ) NP 2014 166 / 320
21. Проблема «останова» Покрытие потока управления
Модифицированное покрытие ветвлений и условий
Также известное как MC/DC
Является одним из обязательных условий при тестировании ПО
на уровень A в рамках DO-178B
Чем оно отличается от обычного покрытия ветвлений и условий
программы?
1 if (req.isSsl () && (cfg.SslEnabled () || cfg.isDebug ())) {
2 ...
3 }
Марат Ахин (СПбГПУ) NP 2014 167 / 320
22. Проблема «останова» Покрытие потока управления
Модифицированное покрытие ветвлений и условий
Каждое условие независимо повлияло на выполнение программы
Как это проверить?
Изменить одно условие и проверить, изменилось ли ветвление
1 if (req.isSsl () && (cfg.SslEnabled () || cfg.isDebug ())) {
2 ...
3 }
Марат Ахин (СПбГПУ) NP 2014 168 / 320
23. Проблема «останова» Покрытие потока управления
Полное покрытие условий программы
Полный перебор всех возможных комбинаций условий всех
возможных ветвлений
Сколько вариантов необходимо перебрать, чтобы получить полное
комбинационное покрытие для следующего примера?
1 if (req.isSsl () && (cfg.SslEnabled () || cfg.isDebug ())) {
2 ...
3 }
Марат Ахин (СПбГПУ) NP 2014 169 / 320
24. Проблема «останова» Покрытие потока управления
Покрытие путей программы
Мы требуем, чтобы все возможные пути программы были
выполнены хотя бы один раз
Как данное покрытие соотносится с полным покрытием условий?
Обычно считается самым сильным типом покрытия потока
управления
Его можно было бы использовать, если бы не...
Циклы и рекурсия
Марат Ахин (СПбГПУ) NP 2014 170 / 320
25. Проблема «останова» Покрытие потока управления
Покрытие путей программы
Мы требуем, чтобы все возможные пути программы были
выполнены хотя бы один раз
Как данное покрытие соотносится с полным покрытием условий?
Обычно считается самым сильным типом покрытия потока
управления
Его можно было бы использовать, если бы не...
Циклы и рекурсия
Марат Ахин (СПбГПУ) NP 2014 170 / 320
26. Проблема «останова» Покрытие потока управления
Покрытие путей программы
Мы требуем, чтобы все возможные пути программы были
выполнены хотя бы один раз
Как данное покрытие соотносится с полным покрытием условий?
Обычно считается самым сильным типом покрытия потока
управления
Его можно было бы использовать, если бы не...
Циклы и рекурсия
Марат Ахин (СПбГПУ) NP 2014 170 / 320
27. Проблема «останова» Покрытие потока управления
Покрытие путей программы
450 возможных путей
Марат Ахин (СПбГПУ) NP 2014 171 / 320
28. Проблема «останова» Покрытие потока управления
Покрытие путей программы
450 возможных путей
Марат Ахин (СПбГПУ) NP 2014 171 / 320
29. Проблема «останова» Покрытие потока управления
Покрытие путей программы
Для борьбы с этим используют несколько подходов
Один из вариантов
Требуем, чтобы тело цикла было выполнено
0
1
k
max
Объясните, почему выбраны именно эти варианты
Марат Ахин (СПбГПУ) NP 2014 172 / 320
30. Проблема «останова» Покрытие потока данных
Покрытие потока данных
Что еще можно сделать?
Можно вспомнить о том, что программы работают не просто так
Основная цель работы любой программы – работа с данными
С этой точки зрения для тестирования представляет интерес
анализ таких путей выполнения программы, на которых активно
работают с данными
Сперва вспомним несколько определений
Марат Ахин (СПбГПУ) NP 2014 173 / 320
31. Проблема «останова» Покрытие потока данных
Определения и использования переменных
Определение переменной (Def)
Оператор программы, в котором значение переменной v может быть
изменено
v = 42
f(&v, ...)
scanf(fmt, &v)
Использование переменной (Use)
Оператор программы, в котором значение переменной v влияет на
выполнение программы тем или иным способом
q = v + 2
g(v, ...)
if (v != NULL) ...
Марат Ахин (СПбГПУ) NP 2014 174 / 320
32. Проблема «останова» Покрытие потока данных
Определения и использования переменных
Def-Use Chain
Пара (d, u) операторов программы, для которой выполняются
следующие условия
d – определение переменной v
u – использование переменной v
между d и u существует хотя бы один путь, на котором
переменная v не переопределяется
Рассмотрим данные определения на примере
Марат Ахин (СПбГПУ) NP 2014 175 / 320
34. Проблема «останова» Покрытие потока данных
Покрытие потока данных
Какие варианты покрытий можно предложить с использованием этих
понятий?
Покрытие всех определений
Для каждой интересующей нас переменной v должна быть
протестирована хотя бы одна Def-Use Chain от каждого
определения v до хотя бы одного использования v
Марат Ахин (СПбГПУ) NP 2014 177 / 320
35. Проблема «останова» Покрытие потока данных
All-Def Coverage
Рассмотрим следующие тесты
1 → 2 → 3 → 4 → 5 → 6
Марат Ахин (СПбГПУ) NP 2014 178 / 320
36. Проблема «останова» Покрытие потока данных
Покрытие потока данных
Покрытие всех использований
Для каждой интересующей нас переменной v должна быть
протестирована хотя бы одна Def-Use Chain от каждого
определения v до каждого использования v
Является ли All-Use более сильным критерием по сравнению с All-Def?
Марат Ахин (СПбГПУ) NP 2014 179 / 320
38. Проблема «останова» Покрытие потока данных
Покрытие потока данных
Покрытие всех Def-Use Chain
Для каждой интересующей нас переменной v должны быть
протестированы все возможные Def-Use Chain от каждого
определения v до каждого использования v
Как соотносится All-Def-Use-Chain с покрытием всех путей программы?
Марат Ахин (СПбГПУ) NP 2014 181 / 320
43. Проблема «останова» Мутационное тестирование
Другой способ оценки полноты
Какими способами можно управлять выполнением кода?
Изменением входных данных
Изменением самого исходного кода
Как можно оценить полноту тестирования, изменяя исходный код?
Марат Ахин (СПбГПУ) NP 2014 186 / 320
44. Проблема «останова» Мутационное тестирование
Идеальный тест
Идеальный тест работает только на тестируемой программе
При любом изменений он перестает проходить
В этом заключается основная идея мутационного тестирования
Марат Ахин (СПбГПУ) NP 2014 187 / 320
45. Проблема «останова» Мутационное тестирование
Мутационное тестирование
Исходная программа подвергается мутации, в результате
получается набор из N мутантов
После этого имеющиеся тесты запускаются на этих мутантах
Если тест не проходит на мутанте, то говорят, что тест «убивает»
этого мутанта
Доля «убитых» мутантов показывает, насколько полно данный
набор тестов покрывает нашу программу
Марат Ахин (СПбГПУ) NP 2014 188 / 320
46. Проблема «останова» Мутационное тестирование
Как сделать мутанта?
Что можно сделать с исходным кодом?
Добавить новый код
Удалить старый код
Изменить существующий код
Набор синтаксических трансформаций, изменяющих исходный код
Марат Ахин (СПбГПУ) NP 2014 189 / 320
47. Проблема «останова» Мутационное тестирование
Как сделать мутанта?
1 int sumCollection (final @NotNull Collection <Integer > c) {
2 int sum = 0;
3 for (int i : c) {
4 sum += i;
5 }
6 return sum;
7 }
Как можно мутировать данный фрагмент кода?
Марат Ахин (СПбГПУ) NP 2014 190 / 320
48. Проблема «останова» Мутационное тестирование
Как сделать мутанта?
Некоторые мутанты будут синтаксически некорректны
Другие мутанты будут семантически некорректны
Оставшиеся мутанты подходят для использования в мутационном
тестировании
Какие проблемы есть у мутационного тестирования?
Марат Ахин (СПбГПУ) NP 2014 191 / 320
49. Проблема «останова» Мутационное тестирование
Недостатки мутационного тестирования
Данный вид тестирования практически невозможно выполнять
вручную
Количество необходимых для оценки покрытия мутантов
пропорционально объему анализируемого ПО
Даже для небольшой программы получение достаточного числа
мутантов вручную является практически невозможным
Сильно возрастают затраты на проведение тестирования
Вместо одного запуска каждого теста требуется выполнить N
запусков
Кроме того, дополнительное время тратится на генерацию
мутантов
Марат Ахин (СПбГПУ) NP 2014 192 / 320
53. Проблема «останова» Оценка тестового покрытия
Оценка тестового покрытия
Мы же уже поговорили об оценке тестового покрытия?
Оценка тестового покрытия
программы
Оценка самого тестового
покрытия
Who observes the observer? c
Марат Ахин (СПбГПУ) NP 2014 196 / 320
54. Проблема «останова» Оценка тестового покрытия
Оценка тестового покрытия
Какая проблема есть у покрытия потока управления?
Чувствительность к изменениям в исходном коде
Марат Ахин (СПбГПУ) NP 2014 197 / 320
55. Проблема «останова» Оценка тестового покрытия
Оценка тестового покрытия
Какая проблема есть у покрытия потока управления?
Чувствительность к изменениям в исходном коде
Марат Ахин (СПбГПУ) NP 2014 197 / 320
56. Проблема «останова» Оценка тестового покрытия
Нестабильность тестового покрытия
1 ...
2 if (a && b && c) {
3 ...
4 }
1 bool cond = a && b && c;
2 if (cond) {
3 ...
4 }
Что будет с покрытием MC/DC?
Марат Ахин (СПбГПУ) NP 2014 198 / 320
57. Проблема «останова» Оценка тестового покрытия
Нестабильность тестового покрытия
Чем сильнее влияют изменения в программе на тестовое
покрытие, тем более нестабильным (fragile) является тестовое
покрытие
Чем более нестабильным является тестовое покрытие, тем менее
адекватно оно оценивает качество тестирования
Что же делать?
Марат Ахин (СПбГПУ) NP 2014 199 / 320
58. Проблема «останова» Оценка тестового покрытия
Оценка тестового покрытия
The whole is more than the sum of its parts c
Можно применить мутационное тестирование для оценки
тестового покрытия
Ограничить набор трансформаций
Посмотреть на изменение тестового покрытия для мутантов
...
PROFIT!
Марат Ахин (СПбГПУ) NP 2014 200 / 320
59. Проблема «останова» Оценка тестового покрытия
Оценка тестового покрытия
Какая проблема есть у мутационного тестирования?
Эквивалентные мутанты
Марат Ахин (СПбГПУ) NP 2014 201 / 320
60. Проблема «останова» Оценка тестового покрытия
Оценка тестового покрытия
Какая проблема есть у мутационного тестирования?
Эквивалентные мутанты
Марат Ахин (СПбГПУ) NP 2014 201 / 320
61. Проблема «останова» Оценка тестового покрытия
Эквивалентные мутанты
1 int sumCollection (final @NotNull Collection <Integer > c) {
2 int sum = 0;
3 for (int i : c) {
4 sum += i;
5 }
6 return sum;
7 }
Почему эквивалентные мутанты – это плохо?
Марат Ахин (СПбГПУ) NP 2014 202 / 320
62. Проблема «останова» Оценка тестового покрытия
Эквивалентные мутанты
Эквивалентные мутанты «зашумляют» итоговую оценку качества
тестирования
Из-за шума снижается адекватность оценки
Что же делать?
Марат Ахин (СПбГПУ) NP 2014 203 / 320
63. Проблема «останова» Оценка тестового покрытия
Оценка тестового покрытия
The whole is more than the sum of its parts c
Можно применить тестовое покрытие для оценки мутационного
тестирования
Для каждого мутанта записывается трасса его выполнения
У эквивалентных мутантов будут похожие трассы выполнения
...
PROFIT!
Марат Ахин (СПбГПУ) NP 2014 204 / 320
64. W.I.L.T. What I Learned Today?
W.I.L.T.
Марат Ахин (СПбГПУ) NP 2014 205 / 320