SlideShare une entreprise Scribd logo
1  sur  33
Мутационное
тестирование
или
“Quis custodiet ipsos custodes?”
“Кто устережёт самих
сторожей?”
Alex A. Yepishev
Содержание
Уровни тестирования
Темная сторона юнит-тестов
Что это за животное?
Цели
Инструменты
Pros & Cons
Примеры
Q&A
Уровни тестирования
Unit / Module
Unit vs Integration
Unit vs Integration
IntegrationSystem
Уровни тестирования
Темная сторона юнит-тестов
int multiply(int a, int b) {
return a * b;
}
- - - - - - - - - - - - - - - - - - - - -
Failed: 0
Passed: 1
Code coverage: 0
void testMultiply() {
// Необходимо создать тест? Вот он :)
Assert.assertTrue(true);
}
int multiply(int a, int b) {
return a * b;
}
- - - - - - - - - - - - - - - - - - - - -
Failed: 0
Passed: 2
Code coverage: 100%
void testMultiply2() {
Assert.assertTrue(multiply(2, 3) > 0);
}
Темная сторона юнит-тестов
int multiply(int a, int b) {
return a * b;
}
- - - - - - - - - - - - - - - - - - - - -
Failed: 0
Passed: 3
Code coverage: 100%
void testMultiply3() {
multiply(2,3);
}
Темная сторона юнит-тестов
int multiply(int a, int b) {
return a * b;
}
- - - - - - - - - - - - - - - - - - - - -
Failed: 0
Passed: 4
Code coverage: 100%
void testMultiply4() {
multiply(2,3);
Assert.assertTrue(true);
}
Темная сторона юнит-тестов
Что это за животное?
Мутационное тестирование (analysis/мутирование) -
основывающаяся на внедрении ошибок, техника
тестирования ПО, которая оценивает качество тестов
посредством изменения частей проверяемого кода
Обнаружение до 70%-90% ‘реальных’ ошибок
Acc
ptnc
System
API
Integration
Component
Unit
Что это за животное?
Source Мутант
Выжившие мутанты
Что это за животное?
Убитые мутанты
МУТАЦИОННЫЙ БАЛ
=
количество убитых мутантов / общее количество мутантов
Что это за животное?
Conditionals boundary </<=, >/ >=, <=/<, >=/>
Мутационные операторы Мутированные значения
Increments
Invert negatives
Negate conditionals
Math mutators
Void methods
Return values
i++ / i--;
-i / i;
+/-, *, /, %/*, &, |/&, ^/&, <<,
>>
<, <=, >, >=, !=, ==, true
true, false, 0, 1, x, x+1, null
void / non-void, primitives, 0
Что это за животное?
Conditionals
if (a < b) {
// do something
}
if (a <= b) {
// do something
}
if (a == b) {
// do something
}
if (true) {
// do something
}
Math
int a = b + c; int a = b - c;
public class A {
private int i;
public void foo() {
this.i++;
}
}
public class A {
private int i;
public void foo() {
this.i = this.i - 1;
}
}
Что это за животное?
Return values
public Object foo() {
return new Object();
}
public Object foo() {
new Object();
return null;
}
public void someVoidMethod(int i) {
// does something
}
public int foo() {
int i = 5;
doSomething(i);
return i;
}
public void someVoidMethod(int i) {
// does something
}
public int foo() {
int i = 5;
return i;
}
Increment
public int mtd(int i) {
i++;
return i;
}
public int mtd(int i) {
i--;
return i;
}
Void
methods
Что это за животное?
● Гарантировать достаточность покрытия кода юнит-тестами
○ Увеличить понимание правил кода среди разработчиков
■ Получить точные метрики покрытия кода
● Обезопасить код построчной, ветвлённой проверкой
○ Повысить общее качество продукта
Цели
Доступные инструменты
Pitest (PIT)
Major Framework
µJava
Comparative analysis of the tools
Pros Cons
Полное покрытие исходного кода
Тщательное тестирование мут-ов
Определение неоднозначностей
Скорость*
Open-source инструменты
TDD-ориентация
Инкрементальный анализ
Высокая стоимость и
времязатратность (геометрич.
прогрессия): количество данных
Должно быть автоматизировано
Только “белый ящик”
Необходимость множества тестов,
для отличия мутанта от исходного
кода
ExcuseMeIwriteGoodTests();
<build>
<plugins>
<plugin>
<groupId>org.pitest</groupId>
<artifactId>pitest-maven</artifactId>
<version>LATEST</version>
<configuration>
<mutators>
<mutator>ALL</mutator>
</mutators>
<targetClasses>
<param>com.myprojectName.classes*</param>
</targetClasses>
<timestampedReports>false</timestampedReports>
<verbose>true</verbose>
</configuration>
</plugin>
</plugins>
</build>
$ mvn clean -Dtest=NodeMapperTest#testGetMachineById test
jacoco:report
public class NodeMapper {
public static final String DEFAULT_MACHINE_NAME = "localhost";
//...
public String getMachineById(long nodeId) {
if(nodeId2machine.containsKey(nodeId)) {
return nodeId2machine.get(nodeId);
} else {
return DEFAULT_MACHINE_NAME;
}
}
}
@gsmirnov
$ mvn clean -Dtest=NodeMapperTest#testGetMachineById2 test pitest:mutationCoverage
Failed: 0
Passed: 1
Line Coverage: 100%
Mutation Coverage: 0%
@Test
public void testGetMachineById2() {
NodeMapper nodeMapper = new NodeMapper(MACHINES);
nodeMapper.getMachineById(0);
nodeMapper.getMachineById(1);
}
@gsmirnov
$ mvn clean -Dtest=NodeMapperTest#testGetMachineById test jacoco:report
public class NodeMapper {
//...
public String getMachineById(long nodeId) {
if( ! nodeId2machine.containsKey(nodeId)) {
return nodeId2machine.get(nodeId);
} else {
return DEFAULT_MACHINE_NAME;
}
}
}
@gsmirnov
34: 1. negated conditional → SURVIVED
34: 5. mutated return of Object value /*...*/ → SURVIVED
public String getMachineById(long nodeId) {
if(nodeId2machine.containsKey(nodeId)) {
if(nodeId2machine.get(nodeId) != null) {
return null;
} else {
throw new RuntimeException();
}
} else {
return DEFAULT_MACHINE_NAME;
}
}
34: 1. negated conditional → KILLED
34: 2. mutated return of Object value /*...*/ → KILLED
@Test
public void testGetMachineById3() {
NodeMapper nodeMapper = new NodeMapper(MACHINES);
Assert.assertEquals(NodeMapper.DEFAULT_MACHINE_NAME, nodeMapper.getMachineById(0));
Assert.assertEquals(TEST_MACHINE_NAME, nodeMapper.getMachineById(1));
}
● Недостаточность юнит-тестов и надежность code-coverage метрик
● Мутационное тестирование - тесты для тестов
● Широкий спектр мут-нных операторов => мутантов
● Необходимость детальной настройки для больших проектов
● “Точечные” запуски в целях экономии времени
● Выявление неявных ошибок в коде и тестах
● Точные метрики покрытия
Выводы
Bonus: SonarQube Mutation Analysis
Bonus: SonarQube Mutation Analysis
Bonus: SonarQube Mutation Analysis
Bonus: SonarQube Mutation Analysis
Q&A

Contenu connexe

Tendances

Использование юнит-тестов для повышения качества разработки
Использование юнит-тестов для повышения качества разработкиИспользование юнит-тестов для повышения качества разработки
Использование юнит-тестов для повышения качества разработкиvictor-yastrebov
 
Статический анализ кода: Что? Как? Зачем?
Статический анализ кода: Что? Как? Зачем?Статический анализ кода: Что? Как? Зачем?
Статический анализ кода: Что? Как? Зачем?Andrey Karpov
 
JPoint 2015 - Javassist на службе Java-разработчика
JPoint 2015 - Javassist на службе Java-разработчикаJPoint 2015 - Javassist на службе Java-разработчика
JPoint 2015 - Javassist на службе Java-разработчикаAnton Arhipov
 
Тестирование ПО (2016)
Тестирование ПО (2016)Тестирование ПО (2016)
Тестирование ПО (2016)Marat Akhin
 
Дебаггинг
ДебаггингДебаггинг
ДебаггингMarat Akhin
 
Регрессионное тестирование
Регрессионное тестированиеРегрессионное тестирование
Регрессионное тестированиеMarat Akhin
 
Учим автотесты человеческому языку с помощью Allure и PyTest
Учим автотесты человеческому языку с помощью Allure и PyTestУчим автотесты человеческому языку с помощью Allure и PyTest
Учим автотесты человеческому языку с помощью Allure и PyTestRina Uzhevko
 
Опыт применения активных объектов во встраиваемых системах. Архитектурные асп...
Опыт применения активных объектов во встраиваемых системах. Архитектурные асп...Опыт применения активных объектов во встраиваемых системах. Архитектурные асп...
Опыт применения активных объектов во встраиваемых системах. Архитектурные асп...Sigma Software
 
C++ refelection and cats
C++ refelection and catsC++ refelection and cats
C++ refelection and catscorehard_by
 
модульное тестирование для Perl. алексей шруб. зал 4
модульное тестирование для Perl. алексей шруб. зал 4модульное тестирование для Perl. алексей шруб. зал 4
модульное тестирование для Perl. алексей шруб. зал 4rit2011
 
Проблема тестовых входных данных
Проблема тестовых входных данныхПроблема тестовых входных данных
Проблема тестовых входных данныхMarat Akhin
 
Полнота тестирования ПО
Полнота тестирования ПОПолнота тестирования ПО
Полнота тестирования ПОMarat Akhin
 
Никита Глушков, К вопросу о реализации кроссплатформенных фреймворков
Никита Глушков, К вопросу о реализации кроссплатформенных фреймворковНикита Глушков, К вопросу о реализации кроссплатформенных фреймворков
Никита Глушков, К вопросу о реализации кроссплатформенных фреймворковSergey Platonov
 
Григорий Демченко, Универсальный адаптер
Григорий Демченко, Универсальный адаптерГригорий Демченко, Универсальный адаптер
Григорий Демченко, Универсальный адаптерSergey Platonov
 
Современный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтерыСовременный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтерыcorehard_by
 
Сложности performance-тестирования / Андрей Акиньшин (JetBrains)
Сложности performance-тестирования / Андрей Акиньшин (JetBrains)Сложности performance-тестирования / Андрей Акиньшин (JetBrains)
Сложности performance-тестирования / Андрей Акиньшин (JetBrains)Ontico
 
Шишки, набитые за 15 лет использования акторов в C++
Шишки, набитые за 15 лет использования акторов в C++Шишки, набитые за 15 лет использования акторов в C++
Шишки, набитые за 15 лет использования акторов в C++Yauheni Akhotnikau
 

Tendances (19)

Parallel STL
Parallel STLParallel STL
Parallel STL
 
Использование юнит-тестов для повышения качества разработки
Использование юнит-тестов для повышения качества разработкиИспользование юнит-тестов для повышения качества разработки
Использование юнит-тестов для повышения качества разработки
 
Статический анализ кода: Что? Как? Зачем?
Статический анализ кода: Что? Как? Зачем?Статический анализ кода: Что? Как? Зачем?
Статический анализ кода: Что? Как? Зачем?
 
JPoint 2015 - Javassist на службе Java-разработчика
JPoint 2015 - Javassist на службе Java-разработчикаJPoint 2015 - Javassist на службе Java-разработчика
JPoint 2015 - Javassist на службе Java-разработчика
 
Тестирование ПО (2016)
Тестирование ПО (2016)Тестирование ПО (2016)
Тестирование ПО (2016)
 
Дебаггинг
ДебаггингДебаггинг
Дебаггинг
 
Регрессионное тестирование
Регрессионное тестированиеРегрессионное тестирование
Регрессионное тестирование
 
Учим автотесты человеческому языку с помощью Allure и PyTest
Учим автотесты человеческому языку с помощью Allure и PyTestУчим автотесты человеческому языку с помощью Allure и PyTest
Учим автотесты человеческому языку с помощью Allure и PyTest
 
Опыт применения активных объектов во встраиваемых системах. Архитектурные асп...
Опыт применения активных объектов во встраиваемых системах. Архитектурные асп...Опыт применения активных объектов во встраиваемых системах. Архитектурные асп...
Опыт применения активных объектов во встраиваемых системах. Архитектурные асп...
 
C++ refelection and cats
C++ refelection and catsC++ refelection and cats
C++ refelection and cats
 
модульное тестирование для Perl. алексей шруб. зал 4
модульное тестирование для Perl. алексей шруб. зал 4модульное тестирование для Perl. алексей шруб. зал 4
модульное тестирование для Perl. алексей шруб. зал 4
 
Проблема тестовых входных данных
Проблема тестовых входных данныхПроблема тестовых входных данных
Проблема тестовых входных данных
 
Полнота тестирования ПО
Полнота тестирования ПОПолнота тестирования ПО
Полнота тестирования ПО
 
Никита Глушков, К вопросу о реализации кроссплатформенных фреймворков
Никита Глушков, К вопросу о реализации кроссплатформенных фреймворковНикита Глушков, К вопросу о реализации кроссплатформенных фреймворков
Никита Глушков, К вопросу о реализации кроссплатформенных фреймворков
 
Григорий Демченко, Универсальный адаптер
Григорий Демченко, Универсальный адаптерГригорий Демченко, Универсальный адаптер
Григорий Демченко, Универсальный адаптер
 
Современный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтерыСовременный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтеры
 
Сложности performance-тестирования / Андрей Акиньшин (JetBrains)
Сложности performance-тестирования / Андрей Акиньшин (JetBrains)Сложности performance-тестирования / Андрей Акиньшин (JetBrains)
Сложности performance-тестирования / Андрей Акиньшин (JetBrains)
 
Шишки, набитые за 15 лет использования акторов в C++
Шишки, набитые за 15 лет использования акторов в C++Шишки, набитые за 15 лет использования акторов в C++
Шишки, набитые за 15 лет использования акторов в C++
 
JRebel
JRebelJRebel
JRebel
 

Similaire à ОЛЕКСАНДР ЄПІШЕВ «Мутаційне тестування: тести для тестів» Lviv QA Day 2019

анализ кода: от проверки стиля до автоматического тестирования
анализ кода: от проверки стиля до автоматического тестированияанализ кода: от проверки стиля до автоматического тестирования
анализ кода: от проверки стиля до автоматического тестированияRuslan Shevchenko
 
Victor Kuliamin.CSEDays
Victor Kuliamin.CSEDaysVictor Kuliamin.CSEDays
Victor Kuliamin.CSEDaysLiloSEA
 
основы Java переменные, циклы
основы Java   переменные, циклыосновы Java   переменные, циклы
основы Java переменные, циклыSergey Nemchinsky
 
Дело тестера боится: как в опытных руках могут заиграть Java и TestNg
Дело тестера боится: как в опытных руках могут заиграть Java и TestNgДело тестера боится: как в опытных руках могут заиграть Java и TestNg
Дело тестера боится: как в опытных руках могут заиграть Java и TestNgIT61
 
тесты с фикстурами
тесты с фикстурамитесты с фикстурами
тесты с фикстурамиIvan Grishaev
 
Тестирование программных фильтров безопасности
Тестирование программных фильтров безопасностиТестирование программных фильтров безопасности
Тестирование программных фильтров безопасностиZestranec
 
QA Fest 2017. Яна Кокряшкина. Интеграция автоматизированных тестов с инструме...
QA Fest 2017. Яна Кокряшкина. Интеграция автоматизированных тестов с инструме...QA Fest 2017. Яна Кокряшкина. Интеграция автоматизированных тестов с инструме...
QA Fest 2017. Яна Кокряшкина. Интеграция автоматизированных тестов с инструме...QAFest
 
Модели в профессиональной инженерии и тестировании программ. Александр Петрен...
Модели в профессиональной инженерии и тестировании программ. Александр Петрен...Модели в профессиональной инженерии и тестировании программ. Александр Петрен...
Модели в профессиональной инженерии и тестировании программ. Александр Петрен...yaevents
 
C++ STL & Qt. Занятие 10.
C++ STL & Qt. Занятие 10.C++ STL & Qt. Занятие 10.
C++ STL & Qt. Занятие 10.Igor Shkulipa
 
Unit test быстрый старт
Unit test быстрый стартUnit test быстрый старт
Unit test быстрый стартAntonio
 
Статический анализ: вокруг Java за 60 минут
Статический анализ: вокруг Java за 60 минутСтатический анализ: вокруг Java за 60 минут
Статический анализ: вокруг Java за 60 минутAndrey Karpov
 
Тестируем тесты с PIT (мутационное тестирование)
Тестируем тесты с PIT (мутационное тестирование)Тестируем тесты с PIT (мутационное тестирование)
Тестируем тесты с PIT (мутационное тестирование)Vitebsk Miniq
 
Тестирование весна 2013 лекция 2
Тестирование весна 2013 лекция 2Тестирование весна 2013 лекция 2
Тестирование весна 2013 лекция 2Technopark
 
Использование комбинаторного тестирования для мобильных приложений
Использование комбинаторного тестирования для мобильных приложенийИспользование комбинаторного тестирования для мобильных приложений
Использование комбинаторного тестирования для мобильных приложенийSQALab
 
Let's Talk About Junit 5
Let's Talk About Junit 5Let's Talk About Junit 5
Let's Talk About Junit 5SQALab
 

Similaire à ОЛЕКСАНДР ЄПІШЕВ «Мутаційне тестування: тести для тестів» Lviv QA Day 2019 (20)

анализ кода: от проверки стиля до автоматического тестирования
анализ кода: от проверки стиля до автоматического тестированияанализ кода: от проверки стиля до автоматического тестирования
анализ кода: от проверки стиля до автоматического тестирования
 
Victor Kuliamin.CSEDays
Victor Kuliamin.CSEDaysVictor Kuliamin.CSEDays
Victor Kuliamin.CSEDays
 
основы Java переменные, циклы
основы Java   переменные, циклыосновы Java   переменные, циклы
основы Java переменные, циклы
 
Дело тестера боится: как в опытных руках могут заиграть Java и TestNg
Дело тестера боится: как в опытных руках могут заиграть Java и TestNgДело тестера боится: как в опытных руках могут заиграть Java и TestNg
Дело тестера боится: как в опытных руках могут заиграть Java и TestNg
 
тесты с фикстурами
тесты с фикстурамитесты с фикстурами
тесты с фикстурами
 
Тестирование программных фильтров безопасности
Тестирование программных фильтров безопасностиТестирование программных фильтров безопасности
Тестирование программных фильтров безопасности
 
QA Fest 2017. Яна Кокряшкина. Интеграция автоматизированных тестов с инструме...
QA Fest 2017. Яна Кокряшкина. Интеграция автоматизированных тестов с инструме...QA Fest 2017. Яна Кокряшкина. Интеграция автоматизированных тестов с инструме...
QA Fest 2017. Яна Кокряшкина. Интеграция автоматизированных тестов с инструме...
 
Модели в профессиональной инженерии и тестировании программ. Александр Петрен...
Модели в профессиональной инженерии и тестировании программ. Александр Петрен...Модели в профессиональной инженерии и тестировании программ. Александр Петрен...
Модели в профессиональной инженерии и тестировании программ. Александр Петрен...
 
C++ STL & Qt. Занятие 10.
C++ STL & Qt. Занятие 10.C++ STL & Qt. Занятие 10.
C++ STL & Qt. Занятие 10.
 
Qt tool evaluation
Qt tool evaluationQt tool evaluation
Qt tool evaluation
 
Unit test быстрый старт
Unit test быстрый стартUnit test быстрый старт
Unit test быстрый старт
 
Unit Testing
Unit TestingUnit Testing
Unit Testing
 
Статический анализ: вокруг Java за 60 минут
Статический анализ: вокруг Java за 60 минутСтатический анализ: вокруг Java за 60 минут
Статический анализ: вокруг Java за 60 минут
 
Тестируем тесты с PIT (мутационное тестирование)
Тестируем тесты с PIT (мутационное тестирование)Тестируем тесты с PIT (мутационное тестирование)
Тестируем тесты с PIT (мутационное тестирование)
 
Тестирование весна 2013 лекция 2
Тестирование весна 2013 лекция 2Тестирование весна 2013 лекция 2
Тестирование весна 2013 лекция 2
 
бегун
бегунбегун
бегун
 
Использование комбинаторного тестирования для мобильных приложений
Использование комбинаторного тестирования для мобильных приложенийИспользование комбинаторного тестирования для мобильных приложений
Использование комбинаторного тестирования для мобильных приложений
 
Async
AsyncAsync
Async
 
Luxoft async.net
Luxoft async.netLuxoft async.net
Luxoft async.net
 
Let's Talk About Junit 5
Let's Talk About Junit 5Let's Talk About Junit 5
Let's Talk About Junit 5
 

Plus de GoQA

АРТЕМ ГРИГОРЕНКО «Покращення процесів найму»
АРТЕМ ГРИГОРЕНКО «Покращення процесів найму»АРТЕМ ГРИГОРЕНКО «Покращення процесів найму»
АРТЕМ ГРИГОРЕНКО «Покращення процесів найму»GoQA
 
КАТЕРИНА ЖУПАН «Mobile Testing based on “ISTQB Mobile Application – Syllabus»
КАТЕРИНА ЖУПАН «Mobile Testing based on “ISTQB Mobile Application – Syllabus»КАТЕРИНА ЖУПАН «Mobile Testing based on “ISTQB Mobile Application – Syllabus»
КАТЕРИНА ЖУПАН «Mobile Testing based on “ISTQB Mobile Application – Syllabus»GoQA
 
МОРРІС-ВСЕСЛАВ ШОСТАК «Роль QA в індустрії програмного та апаратного забезпеч...
МОРРІС-ВСЕСЛАВ ШОСТАК «Роль QA в індустрії програмного та апаратного забезпеч...МОРРІС-ВСЕСЛАВ ШОСТАК «Роль QA в індустрії програмного та апаратного забезпеч...
МОРРІС-ВСЕСЛАВ ШОСТАК «Роль QA в індустрії програмного та апаратного забезпеч...GoQA
 
ОКСАНА ГОРОЩУК «Improving Quality Through Root Cause Analysis»
ОКСАНА ГОРОЩУК «Improving Quality Through Root Cause Analysis»ОКСАНА ГОРОЩУК «Improving Quality Through Root Cause Analysis»
ОКСАНА ГОРОЩУК «Improving Quality Through Root Cause Analysis»GoQA
 
ПАВЛО САФОНОВ «Як оцінити ефективність автоматизації»
ПАВЛО САФОНОВ «Як оцінити ефективність автоматизації»ПАВЛО САФОНОВ «Як оцінити ефективність автоматизації»
ПАВЛО САФОНОВ «Як оцінити ефективність автоматизації»GoQA
 
ГАННА КІЛІМОВА & СВІТЛАНА ЯКОВЛЄВА «ADA testing – те, що дуже на часі»
ГАННА КІЛІМОВА & СВІТЛАНА ЯКОВЛЄВА «ADA testing – те, що дуже на часі»ГАННА КІЛІМОВА & СВІТЛАНА ЯКОВЛЄВА «ADA testing – те, що дуже на часі»
ГАННА КІЛІМОВА & СВІТЛАНА ЯКОВЛЄВА «ADA testing – те, що дуже на часі»GoQA
 
СЕРГІЙ БРИТ «Як запускати тести з Playwright Java написані на Selenide. Не пе...
СЕРГІЙ БРИТ «Як запускати тести з Playwright Java написані на Selenide. Не пе...СЕРГІЙ БРИТ «Як запускати тести з Playwright Java написані на Selenide. Не пе...
СЕРГІЙ БРИТ «Як запускати тести з Playwright Java написані на Selenide. Не пе...GoQA
 
БОГДАН САВЧУК «IoT testing: Manual, Automation and Cyber Security techniques»
БОГДАН САВЧУК «IoT testing: Manual, Automation and Cyber Security techniques»БОГДАН САВЧУК «IoT testing: Manual, Automation and Cyber Security techniques»
БОГДАН САВЧУК «IoT testing: Manual, Automation and Cyber Security techniques»GoQA
 
ЕЛЬМІР ІСКАНДЕРОВ «Bulletproof Your Software: The Magic of Security Autotests»
ЕЛЬМІР ІСКАНДЕРОВ «Bulletproof Your Software: The Magic of Security Autotests»ЕЛЬМІР ІСКАНДЕРОВ «Bulletproof Your Software: The Magic of Security Autotests»
ЕЛЬМІР ІСКАНДЕРОВ «Bulletproof Your Software: The Magic of Security Autotests»GoQA
 
ІННА ДВОЙНІКОВА «Як вийти на Upwork та розширити горизонти QA»
ІННА ДВОЙНІКОВА «Як вийти на Upwork та розширити горизонти QA»ІННА ДВОЙНІКОВА «Як вийти на Upwork та розширити горизонти QA»
ІННА ДВОЙНІКОВА «Як вийти на Upwork та розширити горизонти QA»GoQA
 
КАТЕРИНА АБЗЯТОВА «Point of Growth: Transforming Challenges into Skill-Buildi...
КАТЕРИНА АБЗЯТОВА «Point of Growth: Transforming Challenges into Skill-Buildi...КАТЕРИНА АБЗЯТОВА «Point of Growth: Transforming Challenges into Skill-Buildi...
КАТЕРИНА АБЗЯТОВА «Point of Growth: Transforming Challenges into Skill-Buildi...GoQA
 
НАТАЛІЯ ТРОЙНІЧ «Редизайн всього продукту, коли на проекті залишилось два ман...
НАТАЛІЯ ТРОЙНІЧ «Редизайн всього продукту, коли на проекті залишилось два ман...НАТАЛІЯ ТРОЙНІЧ «Редизайн всього продукту, коли на проекті залишилось два ман...
НАТАЛІЯ ТРОЙНІЧ «Редизайн всього продукту, коли на проекті залишилось два ман...GoQA
 
РІНА УЖЕВКО «Вплив архітектури на стратегію тестування»
РІНА УЖЕВКО «Вплив архітектури на стратегію тестування»РІНА УЖЕВКО «Вплив архітектури на стратегію тестування»
РІНА УЖЕВКО «Вплив архітектури на стратегію тестування»GoQA
 
СЕРГІЙ РУСІНЧУК «Розкриття майстерності QA команд через KPI»
СЕРГІЙ РУСІНЧУК «Розкриття майстерності QA команд через KPI»СЕРГІЙ РУСІНЧУК «Розкриття майстерності QA команд через KPI»
СЕРГІЙ РУСІНЧУК «Розкриття майстерності QA команд через KPI»GoQA
 
КАТЕРИНА АБЗЯТОВА - Certify with confidence: ISTQB Foundation 4.0. Common err...
КАТЕРИНА АБЗЯТОВА - Certify with confidence: ISTQB Foundation 4.0. Common err...КАТЕРИНА АБЗЯТОВА - Certify with confidence: ISTQB Foundation 4.0. Common err...
КАТЕРИНА АБЗЯТОВА - Certify with confidence: ISTQB Foundation 4.0. Common err...GoQA
 
Слуцька Вікторія - Виступити і не наступити на граблі: Як виступати QA спеціа...
Слуцька Вікторія - Виступити і не наступити на граблі: Як виступати QA спеціа...Слуцька Вікторія - Виступити і не наступити на граблі: Як виступати QA спеціа...
Слуцька Вікторія - Виступити і не наступити на граблі: Як виступати QA спеціа...GoQA
 
ОЛЕКСАНДР ХОТЕМСЬКИЙ «Планування стратегії розвитку тестування на проекті»
ОЛЕКСАНДР ХОТЕМСЬКИЙ «Планування стратегії розвитку тестування на проекті»ОЛЕКСАНДР ХОТЕМСЬКИЙ «Планування стратегії розвитку тестування на проекті»
ОЛЕКСАНДР ХОТЕМСЬКИЙ «Планування стратегії розвитку тестування на проекті»GoQA
 
ОЛЕКСІЙ ОСТАПОВ «Створення плагінів для pytest»
ОЛЕКСІЙ ОСТАПОВ «Створення плагінів для pytest»ОЛЕКСІЙ ОСТАПОВ «Створення плагінів для pytest»
ОЛЕКСІЙ ОСТАПОВ «Створення плагінів для pytest»GoQA
 
РОМАН ДУМАНСЬКИЙ «Testing the application in the Amazon Cloud»
РОМАН ДУМАНСЬКИЙ «Testing the application in the Amazon Cloud»РОМАН ДУМАНСЬКИЙ «Testing the application in the Amazon Cloud»
РОМАН ДУМАНСЬКИЙ «Testing the application in the Amazon Cloud»GoQA
 
ВЯЧЕСЛАВ САХАРОВ “Баги, хотфікси та воркераунди в космічній галузі. Вчимось н...
ВЯЧЕСЛАВ САХАРОВ “Баги, хотфікси та воркераунди в космічній галузі. Вчимось н...ВЯЧЕСЛАВ САХАРОВ “Баги, хотфікси та воркераунди в космічній галузі. Вчимось н...
ВЯЧЕСЛАВ САХАРОВ “Баги, хотфікси та воркераунди в космічній галузі. Вчимось н...GoQA
 

Plus de GoQA (20)

АРТЕМ ГРИГОРЕНКО «Покращення процесів найму»
АРТЕМ ГРИГОРЕНКО «Покращення процесів найму»АРТЕМ ГРИГОРЕНКО «Покращення процесів найму»
АРТЕМ ГРИГОРЕНКО «Покращення процесів найму»
 
КАТЕРИНА ЖУПАН «Mobile Testing based on “ISTQB Mobile Application – Syllabus»
КАТЕРИНА ЖУПАН «Mobile Testing based on “ISTQB Mobile Application – Syllabus»КАТЕРИНА ЖУПАН «Mobile Testing based on “ISTQB Mobile Application – Syllabus»
КАТЕРИНА ЖУПАН «Mobile Testing based on “ISTQB Mobile Application – Syllabus»
 
МОРРІС-ВСЕСЛАВ ШОСТАК «Роль QA в індустрії програмного та апаратного забезпеч...
МОРРІС-ВСЕСЛАВ ШОСТАК «Роль QA в індустрії програмного та апаратного забезпеч...МОРРІС-ВСЕСЛАВ ШОСТАК «Роль QA в індустрії програмного та апаратного забезпеч...
МОРРІС-ВСЕСЛАВ ШОСТАК «Роль QA в індустрії програмного та апаратного забезпеч...
 
ОКСАНА ГОРОЩУК «Improving Quality Through Root Cause Analysis»
ОКСАНА ГОРОЩУК «Improving Quality Through Root Cause Analysis»ОКСАНА ГОРОЩУК «Improving Quality Through Root Cause Analysis»
ОКСАНА ГОРОЩУК «Improving Quality Through Root Cause Analysis»
 
ПАВЛО САФОНОВ «Як оцінити ефективність автоматизації»
ПАВЛО САФОНОВ «Як оцінити ефективність автоматизації»ПАВЛО САФОНОВ «Як оцінити ефективність автоматизації»
ПАВЛО САФОНОВ «Як оцінити ефективність автоматизації»
 
ГАННА КІЛІМОВА & СВІТЛАНА ЯКОВЛЄВА «ADA testing – те, що дуже на часі»
ГАННА КІЛІМОВА & СВІТЛАНА ЯКОВЛЄВА «ADA testing – те, що дуже на часі»ГАННА КІЛІМОВА & СВІТЛАНА ЯКОВЛЄВА «ADA testing – те, що дуже на часі»
ГАННА КІЛІМОВА & СВІТЛАНА ЯКОВЛЄВА «ADA testing – те, що дуже на часі»
 
СЕРГІЙ БРИТ «Як запускати тести з Playwright Java написані на Selenide. Не пе...
СЕРГІЙ БРИТ «Як запускати тести з Playwright Java написані на Selenide. Не пе...СЕРГІЙ БРИТ «Як запускати тести з Playwright Java написані на Selenide. Не пе...
СЕРГІЙ БРИТ «Як запускати тести з Playwright Java написані на Selenide. Не пе...
 
БОГДАН САВЧУК «IoT testing: Manual, Automation and Cyber Security techniques»
БОГДАН САВЧУК «IoT testing: Manual, Automation and Cyber Security techniques»БОГДАН САВЧУК «IoT testing: Manual, Automation and Cyber Security techniques»
БОГДАН САВЧУК «IoT testing: Manual, Automation and Cyber Security techniques»
 
ЕЛЬМІР ІСКАНДЕРОВ «Bulletproof Your Software: The Magic of Security Autotests»
ЕЛЬМІР ІСКАНДЕРОВ «Bulletproof Your Software: The Magic of Security Autotests»ЕЛЬМІР ІСКАНДЕРОВ «Bulletproof Your Software: The Magic of Security Autotests»
ЕЛЬМІР ІСКАНДЕРОВ «Bulletproof Your Software: The Magic of Security Autotests»
 
ІННА ДВОЙНІКОВА «Як вийти на Upwork та розширити горизонти QA»
ІННА ДВОЙНІКОВА «Як вийти на Upwork та розширити горизонти QA»ІННА ДВОЙНІКОВА «Як вийти на Upwork та розширити горизонти QA»
ІННА ДВОЙНІКОВА «Як вийти на Upwork та розширити горизонти QA»
 
КАТЕРИНА АБЗЯТОВА «Point of Growth: Transforming Challenges into Skill-Buildi...
КАТЕРИНА АБЗЯТОВА «Point of Growth: Transforming Challenges into Skill-Buildi...КАТЕРИНА АБЗЯТОВА «Point of Growth: Transforming Challenges into Skill-Buildi...
КАТЕРИНА АБЗЯТОВА «Point of Growth: Transforming Challenges into Skill-Buildi...
 
НАТАЛІЯ ТРОЙНІЧ «Редизайн всього продукту, коли на проекті залишилось два ман...
НАТАЛІЯ ТРОЙНІЧ «Редизайн всього продукту, коли на проекті залишилось два ман...НАТАЛІЯ ТРОЙНІЧ «Редизайн всього продукту, коли на проекті залишилось два ман...
НАТАЛІЯ ТРОЙНІЧ «Редизайн всього продукту, коли на проекті залишилось два ман...
 
РІНА УЖЕВКО «Вплив архітектури на стратегію тестування»
РІНА УЖЕВКО «Вплив архітектури на стратегію тестування»РІНА УЖЕВКО «Вплив архітектури на стратегію тестування»
РІНА УЖЕВКО «Вплив архітектури на стратегію тестування»
 
СЕРГІЙ РУСІНЧУК «Розкриття майстерності QA команд через KPI»
СЕРГІЙ РУСІНЧУК «Розкриття майстерності QA команд через KPI»СЕРГІЙ РУСІНЧУК «Розкриття майстерності QA команд через KPI»
СЕРГІЙ РУСІНЧУК «Розкриття майстерності QA команд через KPI»
 
КАТЕРИНА АБЗЯТОВА - Certify with confidence: ISTQB Foundation 4.0. Common err...
КАТЕРИНА АБЗЯТОВА - Certify with confidence: ISTQB Foundation 4.0. Common err...КАТЕРИНА АБЗЯТОВА - Certify with confidence: ISTQB Foundation 4.0. Common err...
КАТЕРИНА АБЗЯТОВА - Certify with confidence: ISTQB Foundation 4.0. Common err...
 
Слуцька Вікторія - Виступити і не наступити на граблі: Як виступати QA спеціа...
Слуцька Вікторія - Виступити і не наступити на граблі: Як виступати QA спеціа...Слуцька Вікторія - Виступити і не наступити на граблі: Як виступати QA спеціа...
Слуцька Вікторія - Виступити і не наступити на граблі: Як виступати QA спеціа...
 
ОЛЕКСАНДР ХОТЕМСЬКИЙ «Планування стратегії розвитку тестування на проекті»
ОЛЕКСАНДР ХОТЕМСЬКИЙ «Планування стратегії розвитку тестування на проекті»ОЛЕКСАНДР ХОТЕМСЬКИЙ «Планування стратегії розвитку тестування на проекті»
ОЛЕКСАНДР ХОТЕМСЬКИЙ «Планування стратегії розвитку тестування на проекті»
 
ОЛЕКСІЙ ОСТАПОВ «Створення плагінів для pytest»
ОЛЕКСІЙ ОСТАПОВ «Створення плагінів для pytest»ОЛЕКСІЙ ОСТАПОВ «Створення плагінів для pytest»
ОЛЕКСІЙ ОСТАПОВ «Створення плагінів для pytest»
 
РОМАН ДУМАНСЬКИЙ «Testing the application in the Amazon Cloud»
РОМАН ДУМАНСЬКИЙ «Testing the application in the Amazon Cloud»РОМАН ДУМАНСЬКИЙ «Testing the application in the Amazon Cloud»
РОМАН ДУМАНСЬКИЙ «Testing the application in the Amazon Cloud»
 
ВЯЧЕСЛАВ САХАРОВ “Баги, хотфікси та воркераунди в космічній галузі. Вчимось н...
ВЯЧЕСЛАВ САХАРОВ “Баги, хотфікси та воркераунди в космічній галузі. Вчимось н...ВЯЧЕСЛАВ САХАРОВ “Баги, хотфікси та воркераунди в космічній галузі. Вчимось н...
ВЯЧЕСЛАВ САХАРОВ “Баги, хотфікси та воркераунди в космічній галузі. Вчимось н...
 

ОЛЕКСАНДР ЄПІШЕВ «Мутаційне тестування: тести для тестів» Lviv QA Day 2019

  • 1. Мутационное тестирование или “Quis custodiet ipsos custodes?” “Кто устережёт самих сторожей?” Alex A. Yepishev
  • 2. Содержание Уровни тестирования Темная сторона юнит-тестов Что это за животное? Цели Инструменты Pros & Cons Примеры Q&A
  • 7. Темная сторона юнит-тестов int multiply(int a, int b) { return a * b; } - - - - - - - - - - - - - - - - - - - - - Failed: 0 Passed: 1 Code coverage: 0 void testMultiply() { // Необходимо создать тест? Вот он :) Assert.assertTrue(true); }
  • 8. int multiply(int a, int b) { return a * b; } - - - - - - - - - - - - - - - - - - - - - Failed: 0 Passed: 2 Code coverage: 100% void testMultiply2() { Assert.assertTrue(multiply(2, 3) > 0); } Темная сторона юнит-тестов
  • 9. int multiply(int a, int b) { return a * b; } - - - - - - - - - - - - - - - - - - - - - Failed: 0 Passed: 3 Code coverage: 100% void testMultiply3() { multiply(2,3); } Темная сторона юнит-тестов
  • 10. int multiply(int a, int b) { return a * b; } - - - - - - - - - - - - - - - - - - - - - Failed: 0 Passed: 4 Code coverage: 100% void testMultiply4() { multiply(2,3); Assert.assertTrue(true); } Темная сторона юнит-тестов
  • 11. Что это за животное? Мутационное тестирование (analysis/мутирование) - основывающаяся на внедрении ошибок, техника тестирования ПО, которая оценивает качество тестов посредством изменения частей проверяемого кода Обнаружение до 70%-90% ‘реальных’ ошибок
  • 13. Source Мутант Выжившие мутанты Что это за животное? Убитые мутанты
  • 14. МУТАЦИОННЫЙ БАЛ = количество убитых мутантов / общее количество мутантов Что это за животное?
  • 15. Conditionals boundary </<=, >/ >=, <=/<, >=/> Мутационные операторы Мутированные значения Increments Invert negatives Negate conditionals Math mutators Void methods Return values i++ / i--; -i / i; +/-, *, /, %/*, &, |/&, ^/&, <<, >> <, <=, >, >=, !=, ==, true true, false, 0, 1, x, x+1, null void / non-void, primitives, 0 Что это за животное?
  • 16. Conditionals if (a < b) { // do something } if (a <= b) { // do something } if (a == b) { // do something } if (true) { // do something } Math int a = b + c; int a = b - c; public class A { private int i; public void foo() { this.i++; } } public class A { private int i; public void foo() { this.i = this.i - 1; } } Что это за животное?
  • 17. Return values public Object foo() { return new Object(); } public Object foo() { new Object(); return null; } public void someVoidMethod(int i) { // does something } public int foo() { int i = 5; doSomething(i); return i; } public void someVoidMethod(int i) { // does something } public int foo() { int i = 5; return i; } Increment public int mtd(int i) { i++; return i; } public int mtd(int i) { i--; return i; } Void methods Что это за животное?
  • 18. ● Гарантировать достаточность покрытия кода юнит-тестами ○ Увеличить понимание правил кода среди разработчиков ■ Получить точные метрики покрытия кода ● Обезопасить код построчной, ветвлённой проверкой ○ Повысить общее качество продукта Цели
  • 19. Доступные инструменты Pitest (PIT) Major Framework µJava Comparative analysis of the tools
  • 20. Pros Cons Полное покрытие исходного кода Тщательное тестирование мут-ов Определение неоднозначностей Скорость* Open-source инструменты TDD-ориентация Инкрементальный анализ Высокая стоимость и времязатратность (геометрич. прогрессия): количество данных Должно быть автоматизировано Только “белый ящик” Необходимость множества тестов, для отличия мутанта от исходного кода ExcuseMeIwriteGoodTests();
  • 21.
  • 23. $ mvn clean -Dtest=NodeMapperTest#testGetMachineById test jacoco:report public class NodeMapper { public static final String DEFAULT_MACHINE_NAME = "localhost"; //... public String getMachineById(long nodeId) { if(nodeId2machine.containsKey(nodeId)) { return nodeId2machine.get(nodeId); } else { return DEFAULT_MACHINE_NAME; } } } @gsmirnov
  • 24. $ mvn clean -Dtest=NodeMapperTest#testGetMachineById2 test pitest:mutationCoverage Failed: 0 Passed: 1 Line Coverage: 100% Mutation Coverage: 0% @Test public void testGetMachineById2() { NodeMapper nodeMapper = new NodeMapper(MACHINES); nodeMapper.getMachineById(0); nodeMapper.getMachineById(1); } @gsmirnov $ mvn clean -Dtest=NodeMapperTest#testGetMachineById test jacoco:report
  • 25. public class NodeMapper { //... public String getMachineById(long nodeId) { if( ! nodeId2machine.containsKey(nodeId)) { return nodeId2machine.get(nodeId); } else { return DEFAULT_MACHINE_NAME; } } } @gsmirnov 34: 1. negated conditional → SURVIVED
  • 26. 34: 5. mutated return of Object value /*...*/ → SURVIVED public String getMachineById(long nodeId) { if(nodeId2machine.containsKey(nodeId)) { if(nodeId2machine.get(nodeId) != null) { return null; } else { throw new RuntimeException(); } } else { return DEFAULT_MACHINE_NAME; } }
  • 27. 34: 1. negated conditional → KILLED 34: 2. mutated return of Object value /*...*/ → KILLED @Test public void testGetMachineById3() { NodeMapper nodeMapper = new NodeMapper(MACHINES); Assert.assertEquals(NodeMapper.DEFAULT_MACHINE_NAME, nodeMapper.getMachineById(0)); Assert.assertEquals(TEST_MACHINE_NAME, nodeMapper.getMachineById(1)); }
  • 28. ● Недостаточность юнит-тестов и надежность code-coverage метрик ● Мутационное тестирование - тесты для тестов ● Широкий спектр мут-нных операторов => мутантов ● Необходимость детальной настройки для больших проектов ● “Точечные” запуски в целях экономии времени ● Выявление неявных ошибок в коде и тестах ● Точные метрики покрытия Выводы
  • 33. Q&A

Notes de l'éditeur

  1. Кратко вспомним об уровнях тестирования Слабые стороны юнит-тестирования Что такое мутационное тестирование? Основные цели, как причины для использования Доступные инструменты на разных языках Сильные стороны и недостатки Примеры Вопросы Вне поля нашего рассмотрения - организация и настройка соответствующей инфраструктуры для этого вида тестирования.
  2. Чтобы лучше понять место, занимаемое мутационным тестированием, полезным было бы вспомнить уровни тестирования. Понимая, что основной целью QA, использующего наиболее эффективные инструменты, техники и подходы, является удостоверение в том, что продукт содержит как можно меньше ошибок, т.е. его качество соответствует согласованным нормам, (CLICK 1) прежде всего, важно убедиться в том, что каждый индивидуальный юнит (неделимая единица бизнес логики) выполняет ожидаемую от него функцию. Такой уровень мы называем “юнит” и/или “модульным”. Тем не менее, даже не смотря на скорость и самые низкоуровневые проверки, ожидаемый результат далеко не всегда может соответствовать реальности (NEXT SLIDE)
  3. Эти гифки можно было бы назвать как на ролики ютубе: “Вы бы не поверили, если бы это не было записано” (“You would not believe it if it was not recorded”)
  4. Моей минимальной рекомендацией к разработчикам, было бы хотя бы попытка локально сбилдить артефакт перед пушем своих изменений в общий репозиторий. (помню обновился на последний коммит в ветке, которой велась разработка, попытка сбилдить, fail, лишь из-за того что разработчик оставил в новой строке кавычки (использующиеся для строк), сами по себе).
  5. (CLICK 1) Чтобы проверить, как отдельные модули взаимодействуют и обмениваются данными друг с другом, мы используем интеграционные тесты. (CLICK 2) Для верификации поведения модулей в соответствии с функциональными требованиями с точки зрения конечного пользователя, мы используем системное тестирование Каждый из вышеупомянутых уровней предполагает собственные метрики, выраженные в различных числовых показателях, как и других индикаторах. Одна из наиболее важных для разработчика - покрытие кода (code coverage). Покрытие кода, конечно же, может нам сообщить нечто о его качестве, особенно, если для кода нет или не было написано никаких тестов. И, тем не менее, высокий показатель покрытия кода, совершенно еще никак не гарантирует высокое качество этого же кода. Как следствие, такая метрика как “покрытие кода”, нередко может вводить разработчиков в заблуждение, или даже, самообман.
  6. На следующих слайдах показано, как делать НЕ СТОИТ. Надеюсь, что мы не малые дети, которые на подобное утверждение, хотят сделать всё с точностью до наоборот. Представим, что заказчик или БА попросил ваc написать функцию для умножения двух чисел, и согласно нормам разработки, использующимся в компании, вы должны покрыть эту функцию тестами. (CLICK) Вуаля, вы замечательны! Две минуты, всё готово! Тест проходит, ничего не фейлится, НО покрытие кода (который на джаве можно удобно выполнять с помощью библиотеки jacoco) на нуле. В таком случае, заказчика или БА, возможно мы и обведём вокруг пальца, однако скорее всего не надолго.
  7. Оптимизируем попытки… Ведь метрики покрытия кода, можно легко обхитрить. (CLICK1) Тест проходит, фейлов нет, и покрытие кода 100%. Наконец-то! Однако, в случае рефакторинга (например, по неизвестной причине будет добавлен минус), или же при передаче других параметров (нуля, или отрицательного числа) мы наверняка получим падающий тест или просто недостаточное количество тестов.
  8. Другой пример обхода покрытия кода - (CLICK) вызов в тесте только лишь функции, без проверок.
  9. И еще один lifehack, который позволяет не только обхитрить инструменты покрытия кода, но и самых внимательных код ревьюиров/тестировщиков, (CLICK) посредством вызова проверяемой функции, которая бы проходилась по условиям и неправильно сделанного ассерта. Итак теперь вы можете сдать экзамен начального уровня по хитростям в юнит-тестировании :) В сущности, через показанные примеры мы ставим под сомнение качество тестов (не качество продукта), а именно: Аккуратны или метрики покрытия кода? Можем ли мы быть уверены в том, что тесты действительно покрывают код? Проходят ли тесты по всем ветвлениям условий (code branches)? Хорошее ли качество и достаточность тестов? Техника мутационного тестирования не только дает ответы, но непосредственно позволяет предотвратить и избежать отрицательных ответов на вышеозвученные вопросы.
  10. КРАТКАЯ ИСТОРИЯ: Происхождение техники уходит корнями в далекий 1971 год к имени Ричарда Липтона, однако первая имплементация инструмента для мутационного тестирования была сделана спустя почти 10 лет, в 1980 году Тимоти Баддом из Йельского Университета в его диссертации “Мутационный анализ” (с использованием FORTRAN). Интересно то, что Мутационное тестирование начало набирать популярность и все более широко использоваться только за последнее десятилетие (с 2010гг). Существует множество определений, однако одно из наиболее простых гласит: мутационный анализ использует набор хорошо определенных правил для синтаксических структур, для того, чтобы делать систематические изменения внутри артефактов ПО. (CLICK) Некоторые из современных исследований показывают, что Мутационное тестирование способно обнаруживать до 70%-90% реальных ошибок.
  11. Основные уровни затрагиваемые техникой мутационного тестирования (CLICK1) Unit (CLICK2) Integration
  12. Давайте кратко рассмотрим алгоритм, назовем его “жизненный цикл мутационного тестирования”: Сбилдить исходный код (программу) (CLICK) запустить тесты (стрелки) (CLICK) Мутировать скомпилированный байткод (посредством изменений инструкций, условий, математических операторов, переменных, и т.д. PITtest использует ASM библиотеку для манипуляций с байткодом). Каждая версия с изменением называется мутантом. Запустить тесты на мутированном коде. Ошибки (или мутанты) автоматически помещаются в код, затем запускается существующий тест для этого кода - процесс называется “убиванием” мутанта. Получение результатов: (CLICK) если тесты упали (отреагировали на изменение кода), значит мутант считется убитым (убитые мутанты) (т.е. если изначальная программа и мутированная программа генерируют различные выходные данные в результате тестов, тогда можно говорить, что тест способен убить мутанта, поскольку он настолько хорош, что способен определить изменения между изначальным (правильным) и измененным (неправильным) кодом. (CLICK) В обратном же случае, если тест не упал, значит мутант выжил (выжившие мутанты). Итак закрепим информацию: Для того, чтобы тест мог убить этого мутанта, необходимо чтобы были выполнены следующие условия, RIP model: Reachability: Тест должен быть способен достигнуть мутированного оператора/инструкции. Infection: Infect the program state with the test data so it could result in incorrect state, that is, test input must produce different behavior on mutated and not mutated tested code (Входные данные теста должны привести к разным состояниям программы-мутанта (Infect) и исходной программы. Например, тест с a = 1 и b = 0 приведет к этому). Propagation: The incorrect state propagates to incorrect output, or, in other words, incorrect state must be checked by the test (Значение переменной c должно повлиять (Propagate) на вывод программы и быть проверено тестом). If only the first two point satisfied - weak killing of mutants (easier to kill mutants under this assumption and requires less analysis), if all three - strong killing of mutants. Практичный вопрос: Что же обозначает наличие выжившего мутанта? Не так уж много возможных вариантов: a) необходимо улучшить тесты (в большинстве случаев) b) внести изменения в исходный код c) ограничить используемые мутаторы, чтобы не получать ложно-положительные срабатывания (false positives).
  13. По завершению тестов мы получаем мутационный балл - количество убитых мутантов разделенное на общее количество мутантов
  14. Мутирование кода происходит за счет Мутационных операторов. Мутационный оператор - это правило изменения исходного кода, а примененное правило - мутант. Сразу же стоит ответить, что применять все возможные операторы нет необходимости, поскольку, использование этой техники станет еще одной головной болью. (CLICK) Conditionals boundary (replaces relational operators); (CLICK) Increments; (CLICK) Invert negatives; (CLICK) Math (instead of concatenated strings StringBuilder may be used); (CLICK) Negate conditionals; (CLICK) Return values; (CLICK) Void methods Other mutators usually deactivated by default: Constructor calls; Inline constants (mutates inline constants); Null returns mutator; Non void method calls; Remove conditionals; Experimental member variable (mutates classes by removing assignments to member variables, The members will be initialized with their Java Default Value for the specific type.); Experimental switch (finds the first label within a switch statement that differs from the default label. It mutates the switch statement by replacing the default label (wherever it is used) with this label. All the other labels are replaced by the default one) Mutants are based on well-defined mutation operators that either mimic typical programming errors (such as using the wrong operator or variable name) or force the creation of valuable tests (such as dividing each expression by zero).
  15. Несколько примеров применения мутационных операторов.
  16. Имея общее представление о том, что такое Мутационное тестирование, можно указать несколько основных целей, которые можно рассматривать причинами для использования данной техники: (CLICK) Гарантировать достаточность покрытия кода юнит-тестами (CLICK) Увеличить понимание правил кода среди разработчиков (CLICK) Получить точные метрики покрытия кода (CLICK) Обезопасить код построчной, ветвлённой проверкой (line, branch mutation walking) (CLICK) Увеличить общее качество продукта
  17. JS: Stryker Python: Cosmic Ray, Mutmut
  18. CONS: (CLICK) mutation testing is an extremely costly and time-consuming process because all the programs mutants should be separately generated. Worth to mention, however, there is no need to run mutation testing every time for the whole code base (it is enough to run it for the class we are writing tests for) and it is solvable by smart mutants’ selection; (CLICK) This type of testing should be automated, since afterwards activities and analysis takes a lot of human attention and time; (CLICK) Since this method involves changing the source code, it is not applicable for the black-box testing (CLICK) Not always clear and easy to distinguish the mutant from the original SW (CLICK) Do you know what is this point about? The most annoying problem is available to any developer the static function that may be accessed at any time from anywhere “Excuse me, I write good tests” PROS: (CLICK) Mutation testing allows to cover the entire source code; (CLICK) Program mutants are thoroughly tested; (CLICK) Easily defines ambiguities in the source code (CLICK) Overall performance (depending on the selected mutants, tests...) (CLICK) Free usage since tools are open-source (CLICK) TDD-oriented (CLICK) Incremental analysis (experimental feature to enable its use on very large codebases. If this option is activated, PIT will track changes to the code and tests and store the results from previous runs. It will then use this information to avoid re-running analysis when the results can be logically inferred (predictable). There are possible error, that may be caused not src code but by dependencies) Worth to mention not testable mutations: (original code) String isBigOrSmall(int x) { if x > 0 return “larger”; else if x < 0 return “smaller”; return “ ”; } (Mutation) - else if x < 0 + else if x != 0 => such mutation is not testable, since the logic itself (as well as tests) is mutually exclusive, x != 0 is equivalent to ((x < 0) & (x > 0)).
  19. Let’s take a class with a simple method which maps machine to be used in different nodes. This is an example taken from public sources not SwissQuote projects.
  20. This is an example of the very bad test, that may be written by the one who just want to make the appearance that a test was written. However, such workaround can simply be undiscovered by code coverage tools (like jacoco).
  21. The following slide show that PIT has change source code, by reverting expected result of condition, so called ‘negated conditional mutant’ and it survived, and no test failed after such mutations
  22. The other mutation is related to return value, which was changed to conditional statements and the test could not kill it
  23. So, as soon as the tests are failing against new mutants, they are considered as sufficient, and, correspondingly, mutants - killed. Show reports page of PIT (in the ‘pit-reports’ folder)
  24. Недостаточность юнит-тестов Ненадежность code-coverage метрик Мутационное тестирование - тесты для тестов Широкий спектр мут-нных операторов => мутантов Необходимость детальной настройки для больших проектов “Точечные” прогоны разработчиками Выявление неявных ошибок в коде и тестах Точные метрики покрытия
  25. Недостаточность юнит-тестов Ненадежность code-coverage метрик Мутационное тестирование - тесты для тестов Широкий спектр мут-нных операторов => мутантов Необходимость детальной настройки для больших проектов “Точечные” прогоны разработчиками Выявление неявных ошибок в коде и тестах Точные метрики покрытия
  26. Недостаточность юнит-тестов Ненадежность code-coverage метрик Мутационное тестирование - тесты для тестов Широкий спектр мут-нных операторов => мутантов Необходимость детальной настройки для больших проектов “Точечные” прогоны разработчиками Выявление неявных ошибок в коде и тестах Точные метрики покрытия
  27. Недостаточность юнит-тестов Ненадежность code-coverage метрик Мутационное тестирование - тесты для тестов Широкий спектр мут-нных операторов => мутантов Необходимость детальной настройки для больших проектов “Точечные” прогоны разработчиками Выявление неявных ошибок в коде и тестах Точные метрики покрытия
  28. Недостаточность юнит-тестов Ненадежность code-coverage метрик Мутационное тестирование - тесты для тестов Широкий спектр мут-нных операторов => мутантов Необходимость детальной настройки для больших проектов “Точечные” прогоны разработчиками Выявление неявных ошибок в коде и тестах Точные метрики покрытия