Тестирование ПО (2016)

Tестирование программного обеспечения
Что, зачем и почему?
Software Testing 101
Марат Ахин
Санкт-Петербургский политехнический университет
2016
Марат Ахин (СПбПУ) Intro 2016 1 / 359

Содержание
1 Прелюдия
Обеспечение качества ПО
Тестирование ПО
2 Тестирование за 45 минут
3 Тестирование в процессе разработки ПО
4 Проблема тестовых входных данных
5 Проблема неявных входных данных
6 Разработка через тестирование
7 Интеграционное тестирование

Функциональные vs нефункциональные требования

Функциональные требования
Адекватность
Точность
Интероперабельность
Безопасность
Нефункциональные требования
Надежность
Эффективность
Поддерживаемость
Переносимость
Как можно их проверять?

Thinking is hard, running is simple. (c)
Запустить программу просто и это можно сделать всегда
Думать о программе сложно и требует «высшего знания»
Будем запускать программу, чтобы проверить, отвечает ли она
предъявленным требованиям

Что такое тестирование ПО?
То, чем вы будете заниматься до 80% времени

Что за вопрос лежит в основе тестирования?
Работает ли это ПО правильно?
НЕТ
Работает ли это ПО неправильно?
ДА
Тестирование
=
Разрушение

Кому помогает тестирование?
Лучший друг верификации и валидации ПО
В чем разница?
Верификация – «мы сделали это правильно»
Валидация – «мы сделали то, что надо»

Можем ли мы что-то гарантировать при тестировании?
Данное ПО никогда не упадет
Потоки никогда не заблокируются
Вычисления всегда выполняются корректно
Временные характеристики всегда выдерживаются
Мы можем дать такие гарантии лишь в самых тривиальных случаях,
когда обычно все ясно и без тестирования

Почему тестировать сложно?
Brian Kernighan
«Debugging is twice as hard as writing the code in the ﬁrst place.
Therefore, if you write the code as cleverly as possible, you are, by
deﬁnition, not smart enough to debug it.»
Massimo Arnoldi (feat. Kent Beck)
«Unfortunately at least for me (and not only) testing goes against human
nature. If you realize the pig in you, you will see that you program without
tests.»

Почему тестировать нужно?
Если отложить сегодняшние дела на послезавтра, у вас появятся два
свободных дня! (с)

Что же делать?

1 Прелюдия
Тестирование ПО с точки зрения дилетанта
Модель программной ошибки
Модель тестирования ПО
Процесс тестирования ПО
7 Интеграционное тестированиеМарат Ахин (СПбПУ) Intro 2016 14 / 359

Тестирование ПО с точки зрения дилетанта
Запустили приложение
Проверили результаты выполнения на предмет наличия в них
ошибок
aka «багов»
aka «сбоев»
aka «дефектов»
aka «неудач»
Сперва надо разобраться, а что же такое «программная ошибка»?

FAILURE
FAULT
ERROR
Неудача – наблюдаемое снаружи
некорректное поведение программы
Сбой – некорректное состояние
программы из-за ошибки
Ошибка – ошибка в самой
программе, внесенная на этапе
разработки
Рассмотрим данную модель на примере

Найдите ошибку в следующей программе на Java
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 }
Возможное переполнение в строке 4

c = {}
Что будет?
2 int sum = 0;
3 for (int i : c) {
4 sum += i;
5 }
6 return sum;
7 }
Нет ни сбоя, ни неудачи – программа работает корректно

c = {1, 2, 3, 5}
Что будет?
2 int sum = 0;
3 for (int i : c) {
4 sum += i;
5 }
6 return sum;
7 }
Нет ни сбоя, ни неудачи – программа работает корректно

c = {1, 2, 3, 5, Integer.MAX_VALUE, Integer.MIN_VALUE}
Что будет?
2 int sum = 0;
3 for (int i : c) {
4 sum += i;
5 }
6 return sum;
7 }
Сбой есть – программа проходит через некорректное состояние
Но неудачи нет – результат работы программы корректен

c = {1, 2, 3, 5, Integer.MAX_VALUE}
Что будет?
2 int sum = 0;
3 for (int i : c) {
4 sum += i;
5 }
6 return sum;
7 }
Сбой есть – программа проходит через некорректное состояние
Неудача тоже есть – результат работы программы неправильный

Что мы делали?
Запускали ПО (мысленно)
Сравнивали результаты работы с ожидаемыми (логически)
Можно ли придумать другой способ тестирования?

Модель тестирования ПО
Эталонная модель может быть
представлена множеством различных
способов
неформальное представление о том,
«как должна работать программа»
формальная техническая
спецификация
набор тестовых примеров
корректные результаты работы
программы
другая (априори корректная)
реализация той же исходной
спецификации

Что может случиться?

Тест прошел
A-WE-SO-ME!

Тест не прошел
OH-MI-GOD!

Ошибка в ПО
Все просто и понятно, да?

Ошибка в эталонной модели
Некорректный тест? Ошибка в спецификации?

Ошибка в тестовом окружении
Баг в тестовой библиотеке?

Ошибка в платформе
Баг в ОС? Аппаратный сбой? Ошибка компилятора?

Является ли данная модель самодостаточной?

Откуда брать эталонную модель?
Как сравнивать результаты работы программы и модели?

Когда останавливать процесс тестирования?

Как подобрать входные данные, чтобы:
дойти до места с программной ошибкой (Reachibility)
испортить состояние программы с появлением сбоя (Corruption)
вызвать неудачу в работе программы (Propagation)

Проблемы тестирования
What’s up, Doc? (с)
Проблема тестовых входных данных
Проблема наблюдаемости
Проблема «останова»
Проблема тестового оракула

1 Прелюдия
Модели разработки ПО
Проблемы тестирования ПО

Модели разработки ПО
Чем активнее используется тестирование в процессе разработки,
тем важнее его правильное использование

Водопадная модель
Строго последовательная модель
Тестирование выполняется над всей
программой сразу
Имеется хорошая эталонная модель
Стоимость поиска и исправления
ошибок очень высока

Инкрементальная модель
Разработка проходит в несколько
итераций
Тестируются отдельные версии
программы
Имеется неплохая эталонная модель
ошибок высока

Гибкая модель
Все этапы разработки неразрывно
связаны друг с другом
Тестированию подвергаются как сама
программа, так и ее компоненты
Эталонная модель есть не всегда
ошибок относительно низка

Проблемы тестирования ПО
Разве что-то может пойти совсем плохо?

Розовые очки

Розовые очки
Неправильное тестирование создает иллюзию, что все хорошо...
...тогда как на самом деле все может быть очень и очень плохо
Все тесты проходят
Выпускаем код в релиз
...
BOOM!

Наводнение

Наводнение
Неправильное тестирование создает иллюзию, что все плохо...
...тогда как на самом деле все вполне себе ничего
Большинство тестов не проходит
Садимся и исправляем ошибки
...
UNREACHABLE!

Прятки

Прятки
Неправильное тестирование создает иллюзию, что все плохо...
...тогда как на самом деле все плохо в другом месте
Некоторые тесты не проходит
Садимся и ищем ошибки
...
HUH?

W.I.L.T.

Марат Ахин
2016
Марат Ахин (СПбПУ) Input 2016 51 / 359

Quiz

Recap

1 Прелюдия
Обеспечение достижимости
Входные данные
Тестовые данные
Классы эквивалентности
7 Интеграционное тестированиеМарат Ахин (СПбПУ) Input 2016 55 / 359

Обеспечение достижимости
Какими способами можно управлять выполнением кода?
Изменением входных данных
Изменением самого исходного кода
Какой способ можно использовать для обеспечения достижимости
(reachability)?

Что такое входные данные?

Файлы
Фактические аргументы функций
Сетевые пакеты
Результаты запроса к БД
Последовательность вызовов функций
Конфигурация ПО

Почему бы просто не перебрать все возможные варианты?
1 int add(int a, int b) { ... }
18,446,744,073,709,551,616 вариантов
А если у тестируемого модуля есть внутреннее состояние?

Классы эквивалентности
Все пространство входных состояний можно разбить на
множество классов эквивалентности
Каждый класс эквивалентности обрабатывается тестируемым
модулем одинаково с точки зрения спецификации
Тестирование всех классов эквивалентности позволяет найти
ошибки прямого нарушения спецификации
Как найти классы эквивалентности?

Ad hoc testing
Тестирование методом «научного тыка»
Запускаем ПО
Смотрим на результаты работы
...
PROFIT!

Ad hoc testing
А что будет, если я нажму на эту
кнопочку?
Если сложить два положительных
числа, то...
После умножения на ноль в
результате должен получится ноль
Если ввести очень большое число и
удвоить его, то...
В чем проблемы при таком подходе к тестированию?

Метод свободного поиска
Ad hoc testing + планирование
Описываем тест-план
Проверяем ПО на соответствие тест-плану
...
PROFIT!

Метод свободного поиска
Если ввести число «42», потом
нажать «+», потом ввести «1» и
нажать «=», в результате должно
получиться «43»
Многократные нажатия на «C» не
должны приводить к видимым
изменениям в интерфейсе

Анализ граничных значений
Баю баюшки баю, не ложися на краю...
Находим пограничные значения входных данных
Проверяем ПО вокруг выбранных пограничных значений
...
PROFIT!

Анализ граничных значений
Если умножить любое число на «0»,
должен получиться «0»
Деление любого числа на «0»
должно приводить к выводу
соответствующей ошибки
Если изменить знак наибольшего
представимого положительного
числа, должно получиться
соответствующее ему отрицательное
число

Примеры
kd-tree
stoi
md5sum
PDF reader

1 Прелюдия
Неявные входные данные
Использование заглушек

Покрывает ли спецификация все множество входных данных?
В некоторых случаях – да
В большинстве случаев – нет
Почему?
Проблема заключается в том, что на тестовый модуль, кроме
явных, влияет множество неявных входных данных
Неявные входные данные часто не находят отражения в
спецификации

Текущая дата/время
IP/MAC адрес
Локаль пользователя
Идентификаторы устройств
Контекстные переключения/планирование нитей
Скорость поступления IP пакетов
Ритм нажатия клавиш на клавиатуре
Все это – примеры неявных входных данных

Therac-25

Robot pharmacist

Как учесть неявные входные данные?
Simulate and Stub
Заменяем части модуля управляемыми заглушками
Это позволяет сделать неявные входные данные явными
Это также делает управление явными входными данными проще

Использование заглушек
Данный подход позволяет:
имитировать возникновение редких ситуаций
внести детерминизм там, где его нет
Для того, чтобы можно было использовать S&S, тестируемый
модуль должен разрабатываться соответствующим образом

Mock-объекты
Пример S&S – mock-объекты
Повторяют внешний интерфейс тестируемого объекта
Могут демонстрировать любое требуемое поведение

Mockito
1 @Test
2 void testFoo () {
3 List mockedList = mock(List.class );
4
5 when(mockedList.get (0)). thenReturn("first");
6 when(mockedList.get (1)). thenReturn("second");
7
8 assertEquals ("first", mockedList.get (0));
9 assertEquals ("second", mockedList.get (1));
10 assertEquals (null , mockedList.get (42));
11 }

Mockito
Сервис аутентификации и авторизации
Вход пользователя с корректными логином/паролем должен
приводить к переходу его учетной записи в активное состояние

Mockito
1 @Test
2 void testLoginForValidUser () {
3 IPasswordInfo passInfo = mock( IPasswordInfo .class );
4 when(passInfo.matches(anyString ())). thenReturn(true );
5
6 IAccount account = mock(IAccount.class );
7 when(account. getPasswordInfo ()). thenReturn(passInfo );
8
9 IAccountRepository repo = mock( IAccountRepository .class );
10 when(repo.find(anyString (), anyString ())). thenReturn(account );
11
12 AuthService service = new AuthService(repo );
13 service.login("marat", "password2");
14
15 verify(account ). setLoggedIn (true );
16 }

Mockito
Сервис аутентификации и авторизации
Три последовательные попытки входа пользователя с
некорректным паролем должны приводить к блокированию его
учетной записи

Mockito
1 @Test
2 void testBlockOnIncorrectLogin () {
3 IPasswordInfo passInfo = mock( IPasswordInfo .class );
4 when(passInfo.matches(anyString ())). thenReturn(false );
5
6 IAccount account = mock(IAccount.class );
7 when(account. getPasswordInfo ()). thenReturn(passInfo );
8
10 when(repo.find(anyString (), anyString ())). thenReturn(account );
11
13 service.login("bob", "111");
16
17 verify(account ). setBlocked(true );
18 }

Mockito
1 @Test
2 void testBlockOnIncorrectLoginPerAccount () {
3 IPasswordInfo aliceInfo = getMockedPasswordInfo (false );
4 IPasswordInfo bobInfo = getMockedPasswordInfo (false );
5
6 IAccount aliceAcc = getMockedAccount (aliceInfo );
7 IAccount bobAcc = getMockedAccount (bobInfo );
8
10 when(repo.find("alice", anyString ())). thenReturn(aliceAcc );
11 when(repo.find("bob", anyString ())). thenReturn(bobAcc );
12
15 service.login("alice", "111");
17 service.login("alice", "123");
19
20 verify(aliceAcc , never ()). setBlocked(true );
21 verify(bobAcc , times (1)). setBlocked(true );
22 }

Mocks = Stubs = Fakes = Dummies
Разве есть разница?
Dummies
Объект-муляж, не обладающий собственным поведением
Fakes
Упрощенная реализация требуемой функциональности
Stubs
Тестовая заглушка, способная отвечать на внешние запросы
Mocks
Тестовая загрушка, способная отвечать на внешние запросы и
проверять их корректность

1 Прелюдия
Test-driven development
Плюсы TDD
Минусы TDD

Нужны ли заглушки?
А как использовать mock-объекты в процессе разработки?
Для управления неявными входными данными
Для управления явными входными данными
А когда их следует использовать?

Заглушки не нужны?
Никогда!
Зачем тратить время на разработку и использование заглушек?
Можно просто подождать, пока не будут разработаны все
компоненты
Получится проще, дешевле и лучше, чем с заглушками!

Заглушки не нужны?
Все же будет хорошо, да?

Заглушки нужны?
Чем дольше итерация, тем сложнее и дороже исправление ошибок
Чем быстрее будут написаны тесты для разрабатываемого
компонента, тем проще найти ошибки
После разработки компонента пишем для него тест
Отсутствующие части системы заменяем заглушками
...
PROFIT!

Заглушки нужны?
А давайте писать тесты еще быстрее?

Пишем тест для компонента перед его разработкой
Заменяем сам компонент заглушкой
...
PROFIT???
Разве это будет работать?

Разве это будет работать?

Плюсы TDD
Разработка ведется небольшими контролируемыми фрагментами
В каждый момент времени разработчик думает об ограниченном
фрагменте спецификации
Это упрощает анализ возможного пространства входных данных
Кроме того, код получается более модульным и расширяемым

Плюсы TDD
Минимальная цена ошибки
В случае возникновения ошибки очень просто вернуть систему в
рабочее состояние
Практически отсутствует необходимость в отладке
Крайне просто использовать метод бисекции в случае, если
ошибка смогла пробраться в релиз

Плюсы TDD
Ошибки обнаруживаются сразу же после их появления
Постоянный запуск тестов гарантирует практически моментальное
обнаружение ошибки
Малый размер тестов позволяет быстро найти причину ошибки

Плюсы TDD
Сильно упрощается рефакторинг кода
Программист уверен в том, что его изменения ничего не ломают
Облегчается раздельное владение кодом

Почему я слышу о TDD впервые в жизни?
Почему TDD не используют везде и всюду?!

Минусы TDD
Синдром «розовых очков»
Большое количество тестов создает иллюзию бесконечной
надежности системы тестирования
При создании теста разработчик может сделать те же допущения,
что и при разработке самого компонента

Минусы TDD
Поддержание тестов в актуальном состоянии
При внесении изменений в интерфейсы компонентов системы
необходимо соответствующим образом изменить и все тесты
Большое количество тестов приводит к значительным затратам
на рефакторинг тестов

Минусы TDD
Невозможность тестирования сложного взаимодействия нескольких
компонентов
Каждый тест проверяет ограниченный фрагмент
функциональности системы
Взаимодействие компонентов затрагивает множество аспектов
системы сразу

Стоит ли использовать TDD?

1 Прелюдия
Проблема «Большого Взрыва»
Нисходящее интеграционное тестирование
Восходящее интеграционное тестирование

Когда приходит время заменять заглушки на реализацию...

Поведение реализации может (и скорее всего будет) отличаться
от поведения заглушки
Если заглушек было много...

Каскадное распространение сбоев
Сложность локализации ошибок
Большая стоимость исправления ошибок
Что мы можем сделать?

Интеграционное тестирование
Ускорить процесс замены заглушек на реализацию
Выполнять тестирование взаимодействия постоянно, в процессе
Заменять заглушки на реализацию инкрементально
Инкрементальное интеграционное тестирование

Интеграционное тестирование

Тестирование начинается с верхних уровней системы
Отсутствующие на данный момент модули заменяются
«заглушками»
По мере реализации новых модулей они подключаются к системе
вместо «заглушек»

Преимущества
Возможность ранней проверки корректности высокоуровневого
поведения
Модули могут добавляться по одному, независимо друг от друга
Не требуется разработка множества драйверов
Можно разрабатывать систему как в глубину, так и в ширину

Недостатки
Отложенная проверка низкоуровневого поведения
Требуется разработка «заглушек»
Крайне сложно корректно сформулировать требования ко
входам/выходам частичной системы

Тестирование начинается с нижних уровней системы
Отсутствующие на данный момент модули заменяются
драйверами
При реализации всех модулей нижнего уровня драйвер может
быть заменен на соответствующий модуль

Преимущества
Возможность ранней проверки корректности низкоуровневого
поведения
Не требуется написание заглушек
Просто определить требования ко входам/выходам модулей

Недостатки
Отложенная проверка высокоуровневого поведения
Требуется разработка драйверов
При замене драйвера на модуль высокого уровня может
произойти «мини-Большой Взрыв»

Обеспечение порчи внутреннего состояния
Для того, чтобы обеспечить порчу внутреннего состояния
(corruption), необходимо:
обеспечить достижимость
передать такие тестовые входные данные, которые вызывают
нарушение целостности внутреннего состояния
См. проблему тестовых входных данных

W.I.L.T.

Марат Ахин
2016
Марат Ахин (СПбПУ) PP 2016 116 / 359

Quiz

Recap

1 Прелюдия
8 Проблема наблюдаемости
Обеспечение распространения сбоя

Необходимо обнаружить сбой и распространить его, сделав
наблюдаемым снаружи (Propagation)

Assertions
Основной способ обеспечения наблюдаемости – assertions
1 private void checkInvariants () {
2 assert elements[tail] == null;
3 assert head == tail
4 ? elements[head] == null
5 : (elements[head] != null &&
6 elements [( tail - 1) & (elements.length - 1)] != null );
7 assert elements [( head - 1) & (elements.length - 1)] == null;
8 }

Assertions
Что такое assertion?
Формула в логике первого порядка
Проверяется на истинность во время выполнения программы
Также может проверяться на истинность статически
Допускает возможность отключения проверки истинности

Что дает использование assertions?
Проверка корректности внутреннего состояния
Внутреннее состояние обычно недоступно снаружи (полностью
или частично)
При изменении состояния хочется проверить, что оно остается
корректным

Неудача происходит ближе к причине ее возникновения
Чем больше задержка перед обнаружением неудачи, тем сложнее
найти ее исходную причину
Assertions позволяют найти неудачу практически в любой точке
программы

Явное документирование пред- и пост-условий
В общем случае программист ничего не знает о контракте
используемой функции
Использование assertions позволяет в явном виде описать
внешний контракт функции

Assertions

Какие проблемы связаны с assertions?
Ошибки в assertions
Побочные эффекты в assertions
Неправильное логическое условие срабатывания

Влияние на производительность
Проверка assertions занимает время
Чем сложнее assertion, тем больше он замедляет работу
программы

Эффект «вышибалы»
Сработавший assertion превращает любую ошибку в неудачу
Это полностью останавливает возможность дальнейшего
тестирования

Сложность проверки определенных условий
Некоторые просто формулируемые условия крайне сложно
проверить на практике
Их реализация в виде assertion является крайне затруднительной

Работают ли assertions?

1 int* ptr = malloc(sizeof(int) * 10);
2 assert(ptr);
Адекватный assertion в правильном месте

1 int* ptr = malloc(sizeof(int) * 10);
2 assert(ptr);
Замена обработки ошибок на assertion

Microsoft Oﬃce ≈ 1%
Proprietary software ≈ 3%
Open source software ≈ 5%
Eiﬀel software ≈ 7%
Сейчас assertions используются еще более широко

Работают ли assertions?1
LLVM
≈ 500,000 SLOC
≈ 7000 assertions
> 400 ошибок, относящихся к assertions
1
http://blog.regehr.org/

GCC
≈ 1,000,000 SLOC
≈ 9500 assertions
> 200 ошибок, относящихся к assertions
1

1 assert( BlockAddrFwdRefs .empty () && ...);
2 assert(Ty == V->getType () && ...);
3 assert ((Ty == 0 || Ty == V->getType ()) && ...);
4 assert(It != ResolveConstants .end() && ...);
5 assert(isa <ConstantExpr >( UserC) && ...);
6 assert(V->getType ()-> isMetadataTy () && ...);
7 assert ((! Alignment || isPowerOf2_32 (Alignment )) && ...);
8 assert (( Record[i] == 3 || Record[i] == 4) && ...);
9 assert(Record[i] == 0 && ...);
10 assert(Record[i] == 0 && ...);
11 assert(ResultTy && ...);
12 assert(TypeList[NumRecords] == 0 && ...);
13 assert(NextBitCode == bitc :: METADATA_NAMED_NODE );
14 assert ((CT != LandingPadInst :: Catch
15 || !isa <ArrayType >(Val ->getType ())) && ...);
16 assert ((CT != LandingPadInst :: Filter
17 || isa <ArrayType >(Val ->getType ())) && ...);
18 assert(DFII != DeferredFunctionInfo .end () && ...);
19 assert( DeferredFunctionInfo .count(F) && ...);
20 assert(M == TheModule && ...);
2

Журналирование

Журналирование (logging)
Запись хода выполнения программы в том или ином виде
В зависимости от необходимости журнал может быть более или
менее детализированным
По журналу выполнения при необходимости возможно
восстановить причину возникшей ошибки

Журналирование для
пользователя
Высокоуровневые
сообщения
Как можно меньше
«мусора»
Чем проще и понятнее
формат сообщений, тем
лучше
Журналирование для
программиста
Низкоуровневые
сообщения
Допустим любой шум
Никаких ограничений на
формат сообщений

Как вести журнал?
1 Result :: Ptr processBatchJob (Job :: Ptr job) {
2 // do the heavy lifting ...
3 }
Как записать ход выполнения программы?

1 Result :: Ptr ThreadedProcessor :: processBatchJob (Job:: Ptr job) {
2 log () << "Start of: " << job << endl;
3 // do the heavy lifting ...
4 log () << "End of: " << job << endl;
5 }
Ручная вставка журналирующих вызовов

1 aspect ProcessTracer {
2 advice call("% %Processor :: process %(%)") : before () {
3 log () << "Start of: " << * JoinedPoint ::arg <0 >() << endl;
4 }
5 advice call("% %Processor :: process %(%)") : after () {
6 log () << "End of: " << *JoinedPoint ::arg <0 >() << endl;
7 }
8 };
Журналирующие аспекты / интерсепторы

Logging as a Service

Основная проблема журналирования
INFO [http -thread -pool -8080(5)] Received token: e6749451
TRACE [http -thread -pool -8080(5)] Calling: AuthStorageBean . getAuthData
TRACE [http -thread -pool -8080(5)] Called: AuthStorageBean .getAuthData -> 2.0708E-5
INFO [http -thread -pool -8080(5)] Authentication data found: AuthData { authToken:e6749451
userId :1 firstName: lastName:Admin patrName: role:ru.korus.tmis.core.entity.model.
Role[id=1] spec: }
TRACE [http -thread -pool -8080(5)] Calling: AuthStorageBean . getAuthDateTime
TRACE [http -thread -pool -8080(5)] Called: AuthStorageBean . getAuthDateTime -> 1.9825E-5
INFO [http -thread -pool -8080(5)] Token is valid
TRACE [http -thread -pool -8080(5)] attempting to get session; create = false; session is
null = true; session has id = false
TRACE [http -thread -pool -8080(5)] Authentication attempt received for token [ru.korus.tmis
.core.auth. TmisShiroToken@37bd2b6 ]
DEBUG [http -thread -pool -8080(5)] Performing credentials equality check for
tokenCredentials of type [java.lang.String and accountCredentials of type [java.lang
.String]
DEBUG [http -thread -pool -8080(5)] Both credentials arguments can be easily converted to
byte arrays. Performing array equals comparison
DEBUG [http -thread -pool -8080(5)] Authentication successful for token [ru.korus.tmis.core.
auth. TmisShiroToken@37bd2b6 ]. Returned account [(admin ,ru.korus.tmis.core.entity.
model.Role[id =1])]
DEBUG [http -thread -pool -8080(5)] No SecurityManager available in subject context map.
Falling back to SecurityUtils . getSecurityManager () lookup.
Too much data!

Основная проблема журналирования
Чем больше мы хотим узнать о ходе выполнения программы, тем
больше мы должны журналировать
Чем больше мы журналируем, тем сложнее разобраться в журнале
Чем сложнее разобраться в журнале, тем меньше мы знаем о ходе
выполнения программы

Ограничение размера журнала
Необходимо ограничивать размер записываемых данных

Уровни журналирования
Сообщения пишутся в журнал с определенным уровнем
В дальнейшем возможно фильтровать сообщения по уровням
Error / Warning / Info / Debug / Trace

Домены журналирования
Домены ортогональны уровням журналирования
В зависимости от типа сообщения пишутся в разные домены
Database / Network / UI / Conﬁguration / ...

Стохастическое журналирование
В случае, если какие-то события встречаются очень часто,
достаточно записывать лишь их часть
1 if (_ok == true) {
2 _logger.log( Level.WARNING , "Server seen down: " + _addr , e );
3 } else if (Math.random () < 0.1) {
4 _logger.log( Level.WARNING , "Server seen down: " + _addr );
5 }

Сессионное журналирование
Часто работа ПО разбита на набор слабо связанных сессий
Каждая сессия может журналироваться независимо от других
1 try {
2 // logging ...
3 } catch (Exception ex) {
4 ctx.logging. dumpCurrentSession ();
5 throw;
6 } finally {
7 ctx.logging.reset ();
8 }

Структурированное журналирование
Вместо простого текста журнал ведется в определенном формате
Структурированный формат облегчает поиск и анализ по журналу
1 {
2 "session_id": "e6749451",
3 "event": " method_call",
4 "class_name": " AuthStorageBean ",
5 "method_name ": "getAuthData "
6 }

W.I.L.T.

Полнота тестирования ПО
Марат Ахин
2016
Марат Ахин (СПбПУ) TC 2016 156 / 359

Quiz

Recap

1 Прелюдия

Проблема «останова» в тестировании
Проблема останова
По заданному алгоритму и входным данным определить, завершится
ли за конечное время его выполнение
При чем здесь тестирование?!

Алгоритм ⇔ процесс тестирования
Входные данные ⇔ тестируемая программа
В подавляющем большинстве случаев процесс тестирования является
бесконечным

Мы не можем позволить себе тестировать бесконечное время
Слишком долго
Слишком дорого
Слишком странно

Останавливать процесс тестирования «вручную»
Когда?
У нас кончилось время и/или деньги на тестирование
Мы протестировали ПО достаточно хорошо

По заданному набору тестов и программе определить, протестировали
ли мы ее достаточно хорошо
Что такое – достаточно хорошо?

Тестовое покрытие
Мы протестировали программу достаточно хорошо, когда мы
нашли большую часть ошибок в программе
Чтобы найти ошибку, необходимо обеспечить выполнение трех
основных свойств
Обеспечение достижимости (reachability) и порчи (corruption)
требует, чтобы мы выполнили определенный участок кода с
определенными входными данными
Качество тестирования можно оценить через тестовое покрытие

Виды тестового покрытия
Выделяют два основных вида покрытия
Покрытие потока управления
Покрытие потока данных
Они работают с такими понятиями, как граф потока
управления (CFG) и граф потока данных (DFG)
Надеюсь, что все знают, что такое CFG и DFG?

Покрытие потока управления
Как мы можем покрыть данный
CFG?
По узлам
По дугам
По условиям
По путям
...

Покрытие операторов программы
Каждый узел CFG был пройден в
процессе тестирования хотя бы один раз
Самый слабый способ оценки тестового
покрытия
Сколько тестов требуется для того, чтобы
обеспечить полное покрытие операторов
программы для следующего примера?

Покрытие ветвлений программы
Каждая ветка программы была пройдена
хотя бы один раз
Несколько более сильный способ оценки
покрытия
Сколько тестов требуется для того, чтобы
обеспечить полное покрытие ветвлений
программы для следующего примера?

Как соотносятся между собой покрытия
операторов и ветвлений?
1 Никак
2 Покрытие операторов включает покрытие
ветвлений
3 Покрытие ветвлений включает покрытие
операторов

Никак
Почему покрытие ветвлений не включает
в себя покрытие операторов?
Потому что в программе может
присутствовать «мертвый код»
Потому что в программе могут вообще
отсутствовать ветвления

Покрытие условий программы
Каждое ветвление может выполняться по различным причинам
При покрытии условий программы мы требуем, чтобы все условия
ветвлений хотя бы один раз приняли значение true и false
1 if (req.isSsl () && (cfg.SslEnabled () || cfg.isDebug ())) {
2 ...
3 }
Как соотносятся между собой покрытия ветвлений и условий?

Покрытие условий программы
Никак
Разные комбинации условий могут приводить к выбору одного и
того же ветвления
1 if (req. isLocalhost () || cfg.isDebug () || cfg.isDevMode ()) {
2 ...
3 }

Покрытие ветвлений и условий программы
Комбинация соответствующих покрытий
Полностью их покрывает
Можно ли предложить что-то более сильное?
2 ...
3 }

Модифицированное покрытие ветвлений и условий
Также известное как MC/DC
Является одним из обязательных условий при тестировании ПО
на уровень A в рамках DO-178B
Чем оно отличается от обычного покрытия ветвлений и условий
программы?
2 ...
3 }

Модифицированное покрытие ветвлений и условий
Каждое условие независимо повлияло на выполнение программы
Как это проверить?
Изменить одно условие и проверить, изменилось ли ветвление
2 ...
3 }

Полное покрытие условий программы
Полный перебор всех возможных комбинаций условий всех
возможных ветвлений
Сколько вариантов необходимо перебрать, чтобы получить полное
комбинационное покрытие для следующего примера?
2 ...
3 }

Покрытие путей программы
Мы требуем, чтобы все возможные пути программы были
выполнены хотя бы один раз
Как данное покрытие соотносится с полным покрытием условий?
Обычно считается самым сильным типом покрытия потока
управления
Его можно было бы использовать, если бы не...
Циклы и рекурсия

450 возможных путей

Для борьбы с этим используют несколько подходов
Один из вариантов
Требуем, чтобы тело цикла было выполнено
0
1
k
max
Объясните, почему выбраны именно эти варианты

Что еще можно сделать?
Можно вспомнить о том, что программы работают не просто так
Основная цель работы любой программы – работа с данными
С этой точки зрения для тестирования представляет интерес
анализ таких путей выполнения программы, на которых активно
работают с данными
Сперва вспомним несколько определений

Определения и использования переменных
Определение переменной (Def)
Оператор программы, в котором значение переменной v может быть
изменено
v = 42
f(&v, ...)
scanf(fmt, &v)
Использование переменной (Use)
Оператор программы, в котором значение переменной v влияет на
выполнение программы тем или иным способом
q = v + 2
g(v, ...)
if (v != NULL) ...

Определения и использования переменных
Def-Use Chain
Пара (d, u) операторов программы, для которой выполняются
следующие условия
d – определение переменной v
u – использование переменной v
между d и u существует хотя бы один путь, на котором
переменная v не переопределяется
Рассмотрим данные определения на примере

Пример

Какие варианты покрытий можно предложить с использованием этих
понятий?
Покрытие всех определений
Для каждой интересующей нас переменной v должна быть
протестирована хотя бы одна Def-Use Chain от каждого
определения v до хотя бы одного использования v

All-Def Coverage
Рассмотрим следующие тесты
1 → 2 → 3 → 4 → 5 → 6

Покрытие всех использований
Для каждой интересующей нас переменной v должна быть
протестирована хотя бы одна Def-Use Chain от каждого
определения v до каждого использования v
Является ли All-Use более сильным критерием по сравнению с All-Def?

All-Use Coverage
Рассмотрим следующие тесты
1 → 2 → 3 → 4 → 5 → 6
1 → 2 → 3 → 4 → 6
1 → 3 → 4 → 5 → 6

Покрытие всех Def-Use Chain
Для каждой интересующей нас переменной v должны быть
протестированы все возможные Def-Use Chain от каждого
определения v до каждого использования v
Как соотносится All-Def-Use-Chain с покрытием всех путей программы?

Пример

Другой способ оценки полноты
Как можно оценить полноту тестирования, изменяя исходный код?

Идеальный тест
Идеальный тест работает только на тестируемой программе
При любом изменений он перестает проходить
В этом заключается основная идея мутационного тестирования

Мутационное тестирование
Исходная программа подвергается мутации, в результате
получается набор из N мутантов
После этого имеющиеся тесты запускаются на этих мутантах
Если тест не проходит на мутанте, то говорят, что тест «убивает»
этого мутанта
Доля «убитых» мутантов показывает, насколько полно данный
набор тестов покрывает нашу программу

Как сделать мутанта?
Что можно сделать с исходным кодом?
Добавить новый код
Удалить старый код
Изменить существующий код
Набор синтаксических трансформаций, изменяющих исходный код

2 int sum = 0;
3 for (int i : c) {
4 sum += i;
5 }
6 return sum;
7 }
Как можно мутировать данный фрагмент кода?

Некоторые мутанты будут синтаксически некорректны
Другие мутанты будут семантически некорректны
Оставшиеся мутанты подходят для использования в мутационном
тестировании
Какие проблемы есть у мутационного тестирования?

Недостатки мутационного тестирования
Данный вид тестирования практически невозможно выполнять
вручную
Количество необходимых для оценки покрытия мутантов
пропорционально объему анализируемого ПО
Даже для небольшой программы получение достаточного числа
мутантов вручную является практически невозможным
Сильно возрастают затраты на проведение тестирования
Вместо одного запуска каждого теста требуется выполнить N
запусков
Кроме того, дополнительное время тратится на генерацию
мутантов

Оценка тестового покрытия
Мы же уже поговорили об оценке тестового покрытия?
программы
Оценка самого тестового
покрытия
Who observes the observer? c

Какая проблема есть у покрытия потока управления?
Чувствительность к изменениям в исходном коде

Нестабильность тестового покрытия
1 ...
2 if (a && b && c) {
3 ...
4 }
1 bool cond = a && b && c;
2 if (cond) {
3 ...
4 }
Что будет с покрытием MC/DC?

Нестабильность тестового покрытия
Чем сильнее влияют изменения в программе на тестовое
покрытие, тем более нестабильным (fragile) является тестовое
покрытие
Чем более нестабильным является тестовое покрытие, тем менее
адекватно оно оценивает качество тестирования

The whole is more than the sum of its parts c
Можно применить мутационное тестирование для оценки
тестового покрытия
Ограничить набор трансформаций
Посмотреть на изменение тестового покрытия для мутантов
...
PROFIT!

Какая проблема есть у мутационного тестирования?
Эквивалентные мутанты

2 int sum = 0;
3 for (int i : c) {
4 sum += i;
5 }
6 return sum;
7 }
Почему эквивалентные мутанты – это плохо?

Эквивалентные мутанты «зашумляют» итоговую оценку качества
Из-за шума снижается адекватность оценки

The whole is more than the sum of its parts c
Можно применить тестовое покрытие для оценки мутационного
Для каждого мутанта записывается трасса его выполнения
У эквивалентных мутантов будут похожие трассы выполнения
...
PROFIT!

W.I.L.T.

Тестовый оракул: что, где, когда
Марат Ахин
2016
Марат Ахин (СПбПУ) TO 2016 215 / 359

Quiz

Recap

1 Прелюдия

Тестовый оракул
Magic 8-ball тестирования

В чем заключается проблема тестового оракула?
Его нет!

Вид тестового оракула очень сильно зависит от того, какую
эталонную модель мы используем
kd-tree
stoi
md5sum
PDF reader

Виды тестовых оракулов
Точность
vs
Полнота

Точность
Способность оракула избегать ложных обнаружений
Ложные обнаружения при тестировании – лишние затраты на их
обнаружение и игнорирование
Если их будет слишком много, оракул никто не будет
использовать из-за зашумления результатов

Полнота
Способность оракула находить все ошибки
Пропущенные ошибки при тестировании – дополнительные
затраты на их исправление позднее
Если оракул пропускает много ошибок, его необходимо усиливать
другими способами

Виды тестовых оракулов
Варьируя используемые подходы, можно получить те или иные виды
тестовых оракулов
Слабые
Средние
Сильные

Слабые оракулы
Падение
Segmentation fault
Core dump
Работают всегда
Практически ничего не говорят о причине ошибки

Сбой при работе в обычном окружении
NullPointerException
OutOfMemoryException
ClassNotFoundException
Работают при поддержке стандартной среды выполнения
Содержат определенную информацию о месте ошибки

Сбой при работе в специальном тестовом окружении
Valgrind
Предоставляют специальную среду выполнения
Позволяют весьма точно определить причину ошибок

Valgrind
Фреймворк для построения средств динамического анализа
программ
Включает встроенные реализации для
Memcheck
Cachegrind
Callgrind
Helgrind
DRD
Massif
DHAT
...

Хорошая точность
Плохая полнота

Средние оракулы
Assertions
Тесты
Требуют определенных усилий со стороны разработчиков
В зависимости от степени усилий, будут более или менее точно
указывать на место возникновения ошибки

Хорошая точность
Средняя полнота

Сильные оракулы
Эталонная реализация
Предыдущая версия программы
Формально верифицированная реализация
Автоматически сгенерированная версия

«Обратная функция»
Прямое/обратное преобразование Фурье
Архиватор/деархиватор
Кодер/декодер видео

Средняя точность
Хорошая полнота

Генерация оракулов
Можно ли генерировать оракула автоматически?
Да!

Генерация слабых оракулов
Все уже есть
Слабый оракул предоставляется средой выполнения
Если что-то упало, мы всегда об этом узнаем

Генерация слабых оракулов
В явном виде используются весьма редко
Случайное тестирование
...
Сложно понять, где произошла ошибка
Не всегда очевидно, в чем именно заключается ошибка

Генерация средних оракулов
Assertions
Тесты

Все уже есть
Средние оракулы разрабатываются параллельно с разработкой ПО
При возникновении проблемы мы сразу узнаем о ней
Зачем их генерировать автоматически?

Генерация assertions
Assertions проверяют корректность внутреннего состояния
Как автоматически сгенерировать assertions?
Machine learning

Собираем информацию о выполнении программы
Выводим определенные закономерности в работе программы
Генерируем assertion, проверяющий ненарушение закономерностей
...
PROFIT!
Хорошо работает для FSM-подобных программ
Плохо работает для всех остальных

Собираем информацию о выполнении программы
В случае падения определяем его причину
Генерируем защитный assertion
...
PROFIT!
Способ усиления слабых оракулов до средних
Не работает, если ничего не падает

Генерация тестов
Тесты – один из видов эталонной модели поведения
Как автоматически сгенерировать эталонную модель?

Вспомним, что:
Идеальный тест работает только на тестируемой программе
Если тест проходит на мутанте, это плохо
Собираем информацию о выполнении оригинальной программы и
мутанта
Анализируем разницу
...
PROFIT!

Генерация тестов для GUI
А если у нас есть GUI???
Что такое разница в работе GUI?
Как можно автоматически ее обнаружить?

Генерация тестов для GUI
Нужна модель самого GUI
Нужна модель изменений GUI
Извлечение моделей должно выполняться автоматически

Можно ли придумать что-то еще?

W.I.L.T.

Марат Ахин
2016
Марат Ахин (СПбПУ) RT 2016 253 / 359

Quiz

Recap

1 Прелюдия

Развитие идеи генерации тестовых оракулов
Полная автоматизация процесса тестирования

Основная идея
Заставить компьютер работать вместо нас
Дешевле
Быстрее
Нет человеческого фактора

Автоматическая генерация компонентов тестов
Последовательности вызовов API
Тестовые оракулы

Результаты очень сильно зависят от того, что именно мы тестируем...
kd-tree
stoi
md5sum
PDF reader

Fuzzing
Прародитель случайного тестирования
Полностью случайные данные
Вариант smoke testing
P8FT8PjBG7s71Bw1a8EP4svDPL5g4E791
TJcs5t9ZbxQAsLZx436PdJcxk3vq61192

Fuzzing
Используем слабые оракулы
При необходимости вставляем заглушки
Что такое случайные данные?
Набор байт
Вызовы функций API
Пользовательский ввод

Fuzzing
1989 – первое применение фаззинга на утилитах *NIX
1995 – повторная проверка утилит *NIX
2000 – проверка Windows NT/Windows 2000
2006 – проверка утилит Mac OS X
Стали ли результаты лучше?

Fuzzing
Нет!
Все стало еще хуже!
GUI: 26% -> 45% -> 64% -> 73%
Многие баги, обнаруженные фаззингом, были исправлены...
...но появилось еще больше новых!

Fuzzing

Fuzzing
md5sum
kd-tree
stoi
PDF reader
Работает для всех программ
Но есть одно «но»... c

Проблема валидности данных
Полностью случайные данные являются невалидными входными
данными для большинства программ

Проблема валидности данных
Большинство программ ожидают структурированные входные
данные
P8FT8PjBG7s71Bw1a8EP4svDPL5g4E791
TJcs5t9ZbxQAsLZx436PdJcxk3vq61192
vs
3.1415926535897932384626433832797
[(1,0,0),(0,1,0),(0,0,1),(1,1,1)]

Generative random testing
Если мы знаем структуру, то мы можем ей воспользоваться
Генерируем отдельные элементы
Комбинируем их в соответствии с заданной структурой
Вносим случайные нарушения структуры

Что такое структура?
Набор правил генерации
Грамматика
Формальная спецификация
Стандарт на формат входных файлов

kd-tree
stoi
PDF reader
Работает для структурированных входных данных

Проблема сложной структуры
Иногда структура входных данных является слишком сложной

Mutation random testing
Обычно у нас есть какой-то набор тестовых входных данных
Подвергаем тестовые данные мутации
При этом возможно использование знания структуры данных
Часть данных может генерироваться случайно

Какие могут быть мутационные трансформации?
Добавление нового фрагмента
Удаление старого фрагмента
Изменение фрагмента
Обмен двух фрагментов местами
Замена значений на граничные

PDF reader
Web browser
Работает практически для всего

Проблема скелета в шкафу
Добраться до самых дальних закоулков нельзя

Directed random testing
В чем заключаются основные проблемы случайного тестирования?
Некорректные тесты
Эквивалентные тесты
Длинные тесты

Некорректные тесты
Более строгие правила генерации/мутации
Явный учет некорректных тестов

Эквивалентные тесты
Обнаружение тестов, на которых программа ведет себя
одинаковым образом
Статически
Динамически
Вспомним про тестовое покрытие...

Длинные тесты
Минимизация тестов
Дихотомия
Стохастический поиск
Эволюционные алгоритмы
Delta debugging

А можно ли еще лучше?
Каждый новый тест минимально отличается от имеющихся
Каждый новый тест улучшает тестовое покрытие
Каждый новый тест должен генерироваться достаточно быстро

Concolic testing
Concolic testing
Комбинируем информацию о конкретных выполнениях
программы...
...и информацию о символическом поведении программы
Комбинация статического и динамического анализов

Satisﬁability modulo theories
1 void f(int x) {
2 int y = x^2;
3
4 bool A = x > 0;
5 bool B = x < 10;
6 bool C = y > 20;
7
8 if (B && C) {
9 if (A) {
10 ...
11 }
12 }
13 }
SMT to the rescue
1 x, y = Ints(’x y’)
2 A, B, C = Bools(’A B C’)
3
4 s = Solver ()
5
6 s.add(y == x * x)
7 s.add(A == (x > 0))
8 s.add(B == (x < 10))
9 s.add(C == (y > 20))

Satisﬁability modulo theories
1 print s.check(B and C, A)
2 print s.model ()
3 # sat
4 # [A = True , B = True , y = 25, x = 5, C = True]
5
6 print s.check(B and C, Not(A))
7 print s.model ()
8 # sat
9 # [A = False , B = True , y = 25, x = -5, C = True]
10
11 print s.check(Not(B and C))
12 print s.model ()
13 # sat
14 # [A = False , B = True , y = 0, x = 0, C = False]

Проблемы concolic testing
Почему я слышу об этом впервые в жизни?
Это сложно
Это очень сложно
Это очень-очень сложно

Проблемы concolic testing
Инструментирование программы
Моделирование памяти
Взрыв пространства состояний
Оптимизации!

Concolic testing
SAGE
Microsoft Research
500+ машино-лет
Более трети всех багов в различных проектах Microsoft
Развивается вместе с тестируемым им ПО

Visual Studio
Microsoft Oﬃce
Работает для всего

Проблема мистера Икс
Некоторые части системы могут быть «черным ящиком»

W.I.L.T.

Регрессионное тестирование
Марат Ахин
2016

Quiz

Recap

1 Прелюдия

Тестирование ПО в процессе разработки
Как ПО изменяется в процессе разработки?
Инкрементально, небольшими независимыми шагами
Изменение уже существующего кода
Исправление ошибок
Добавление новой функциональности
Адаптация имеющихся компонентов к новым задачам
Любые (даже самые незначительные) изменения могут серьезно
повлиять на качество ПО

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

Как выглядит одна итерация регрессионного тестирования?
1 Мы модифицируем программу P и получаем программу P
2 Из всего множества тестов T мы выбираем набор тестов T ,
который необходимо выполнить на P
3 Для новой функциональности мы разрабатываем новые тесты T
4 Полученный набор тестов T + T запускается на P
5 Результаты выполнения анализируются с последующей
возможной модификацией как программы, так и набора тестов
Какие проблемы связаны с РТ?

Проблема №1
Как выбрать набор тестов T после изменения в программе?
Консервативный подход
Выбираем все имеющиеся тесты
Полное регрессионное тестирование
Случайный подход
Выбираем случайное подмножество всех тестов
Случайное выборочное регрессионное тестирование

Каким свойствам должно удовлетворять выборочное регрессионное
тестирование?
Полнота – способность выбирать те тесты, которые могут
обнаружить ошибки, связанные с изменениями в коде
Точность – способность пропускать такие тесты, которые не
изменяют своего поведения на модифицированной программе
Эффективность – способность выполняться быстрее, чем полное
регрессионное тестирование
Универсальность – применимость в большинстве практических
ситуаций
«Качественно. Быстро. Дешево. Выберите любые два.»

Умный подход
Выбирать тесты, которые «затрагивают» при выполнении
измененные части программы
Выборочное регрессионное тестирование
Все подходы к ВРТ различаются по двум основным критериям
Способ идентификации измененных программных компонентов
Метод получения информации о покрытии элементов программы
тестами

Подход МакКарти
Анализ изменений на уровне целого модуля
Связь элементов программы с тестами задается вручную
разработчиком
Преимущества и недостатки?

Подход на основе концепции файервола
Анализ изменений на уровне целых модулей
Связь элементов программы с тестами задается вручную
разработчиком

Подход Ротермела и Харролд
Анализ изменений на уровне узлов CFG программы
Связь элементов программы с тестами задается на уровне CFG на
основе динамической информации о выполнении каждого теста

Подход Балла
Анализ изменений на уровне узлов CFG программы
Связь элементов программы с тестами задается на уровне CFG на

Подход на основе AST
Анализ изменений на уровне вершин AST программы
Связь элементов программы с тестами задается на уровне AST на

Управление регрессионными тестами
Как управлять набором регрессионных тестов?
Когда и как добавлять в набор новые тесты?
Когда можно удалять старые тесты?

Добавление новых тестов
Когда надо добавлять новый регрессионный тест?
Когда в ПО появилась новая функциональность
Когда в ПО была исправлена ошибка
Когда мы хотим улучшить тестовое покрытие ПО
Когда мы можем себе позволить добавить новый
неповторяющийся тест

Добавление новых тестов
С течением времени число тестов увеличивается
Чем больше тестов, тем лучше тестовое покрытие
Проблемы начинаются, когда тестов становится слишком много
Что такое «слишком много»?

Удаление старых тестов
Когда можно удалять старый тест?
Никогда
Когда тест дублирует другие тесты
Когда тест не улучшает тестовое покрытие
Когда тест ни разу не обнаружил ошибки за все время
Когда тест обнаруживает такие же ошибки, как и другие тесты

Приоритизация регрессионных тестов
Как запускать регрессионные тесты?
Взяли имеющийся набор тестов и запустили их
Такой подход может не всегда нас устраивать
Что мы можем изменить?

Мы можем изменить порядок, в котором мы запускаем
регрессионные тесты
Зачем?
Чем раньше мы узнаем о том, что в ПО появилась регрессионная
ошибка, тем скорее мы сможем приступить к ее исправлению
Часто причиной непрохождения различных (напрямую не
связанных друг с другом) тестов является одна и та же ошибка в
ПО
Иногда время на тестирование является ограниченным, и
необходимо найти наибольшее число ошибок с учетом всех
ограничений
Как мы можем приоритизировать регрессионные тесты?

При помощи интуиции
Подход работает, если у Вас хорошая интуиция
Кроме интуиции можно использовать имеющийся опыт разработки
ПО

На основе знаний о тестовом покрытии ПО
Сперва выполняются тесты, которые имеют наибольшее покрытие
ПО
Сперва выполняются тесты, которые покрывают более важные
компоненты ПО

На основе истории разработки
Приоритет отдается тестам, которые чаще других обнаруживали
регрессионные ошибки
Первыми выполняются тесты, проверяющие корректность работы
наиболее «проблемных» компонентов ПО

Случайным образом
Подход перекликается со случайным ВРТ
Если мы можем случайным образом поменять порядок
выполнения тестов, то почему бы это не сделать?

На основе характеристик тестов
Первыми выполняются тесты с наименьшим временем выполнения
Приоритет отдается тестам, которые наиболее активно работают с
окружением программной системы

Анализ результатов регрессионного тестирования
Что делать с результатами регрессионного тестирования?
Если все тесты проходят – все хорошо
Если тест не проходит – то все зависит от того, по какой причине
он не проходит
Варианты?

Регрессионное тестирование на практике
Как обстоит дело с РТ/ВРТ на практике?

РТ используется очень часто
TDD
Agile Development
RUP
ВРТ практически не используется
Почему?

Крайняя сложность выбора регрессионных тестов
Опасность пропустить регрессионную ошибку при использовании
небезопасного ВРТ
Страх перед использованием «непонятной» технологии
Простота экстенсивного пути решения проблем РТ

Отсутствие хорошей инструментальной поддержки
Test impact analysis
Chianti
Jimpa
...
Какие еще сложности связаны с ВРТ?

Недетерминизм в тестах
Если выполнение тестов может отличаться от запуска к запуску —
все плохо
Почему?
Эффект «лавины»
Пропущенный тест в ВРТ может дальше привести к каскадному
пропуску множества тестов
Что делать?

W.I.L.T.

Дебаггинг
Марат Ахин
2016
Марат Ахин (СПбПУ) DBG 2016 325 / 359

Quiz

Recap

1 Прелюдия

Поиск ошибок
Debugging
Процесс поиска ошибок в программе
Edsger Dijkstra
If debugging is the process of removing bugs, then programming must be
the process of putting them in.

Как найти ошибку?
Запустить тест
Тест выполнит фрагмент кода с ошибкой
Это вызовет порчу состояния программы
Результат работы программы будет некорректным

Если мы решили проблему наблюдаемости...
Debugging не нужен
Assertions
Журнал выполнения
Если наблюдаемости не хватает???

Основная проблема
Основная проблема
Наблюдение за состоянием программы

Debuggers
Debugger to the rescue!
Две основные задачи отладчика
Пошаговое выполнение программы
Наблюдение за внутренним состоянием программы
Как они это делают?

Debuggers
Тесная интеграция со средой выполнения
Понимание того, что такое инструкция
Возможность останавливать выполнение в произвольные
моменты времени
Знание модели памяти
Способность модифицировать выполняемый код
...

Процесс отладки
Дубль №1
1 Выдвигаем гипотезу о месте возникновения ошибки
2 Настраиваем отладчик на анализ выбранного фрагмента кода
3 Запускаем программу на выполнение
4 Возможные варианты
1 Ошибка найдена
2 Гипотеза не подтвердилась
Если все же не нашли?

Дубль №2
1 Выдвигаем другую гипотезу о месте возникновения ошибки
Если все равно не нашли?

Дубль №3
1 Выдвигаем еще одну гипотезу о месте возникновения ошибки
А если...

Много ручного труда
Надо что-то с этим делать!

One step forward, two steps back...
Гипотезы обычно раскручиваются в обратном порядке
vs
Выполнение программы идет в прямом порядке

Step back

Time-traveling debugging
Отладка с возможностью выполнения программы в обратную сторону
Возможность детального исследования поведения программы
Нет необходимости перезапускать программу
Как это можно сделать?

Обратные функции
Трассировка
Запись состояния памяти (memory snapshots)
Не все так просто...

Дата/время
Внешнее состояние (БД, сериализованные данные, и т.д.)
Работа с аппаратурой
Взаимодействие с другими программами
Чем больше неявных данных мы хотим учитывать, тем сложнее это
сделать эффективно

В самом плохом случае – полная запись всей трассы выполнения
Значение каждой переменной в каждый момент времени

Time-traveling virtual machine
Что еще можно сделать?
Все то же самое, но на уровне виртуальной машины
Запись взаимодействия ПО с аппаратурой
Возможность отладки целого ансамбля программ
Никаких проблем с неявными входными данными

Time-traveling virtual machine
Memory snapshots
Запись источников недетерминизма
Пользовательский ввод
Сетевое взаимодействие
Прерывания
TTVM позволяют отладить ошибки даже в ОС

Time travel

Дихотомия
Как поймать африканского льва?
Разделить Африку на две части стеной
Лев находится в одной из двух частей
Разделить часть со львом на две новой стеной
...
PROFIT!

Дихотомия в отладке
А можно ли то же самое сделать с тестом?
А можно ли это сделать автоматически?

Delta debugging
Способ автоматической минимизации теста
Дано: T = {Ci } : P(T) → fail
Найти: DD = min{Cj } ⊂ T : P(DD) → fail
Что такое Ci ?
Что такое min{Cj }?

Delta debugging
Ci – это...
Строка в файле
Вызов метода
Тэг в XML
Один байт данных
Коммит в VCS
Выбирается индивидуально в каждом конкретном случае

Delta debugging
DD = min{Cj } : ∀C ∈ DD P(DD C) → pass
Удаление любого компонента из минимального теста приводит к
исчезновению ошибки
Чем меньше тест, тем проще его анализировать

Минимизация теста
Субоптимальный способ
Дихотомия
1: function DD(CC)
2: L = {CC1, . . . , CC|CC|/2}
3: R = {CC|CC|/2+1, . . . , CC|CC|}
4: if only P(L) → fail then
5: return DD(L)
6: else if only P(R) → fail then
7: return DD(R)
8: else
9: return CC
10: end if
11: end function

«Оптимальный» способ
Полный перебор
1: function DD(CC)
2: CC = CC {CCi }
3: if P(CC ) → fail then
4: return DD(CC )
5: else if P(CC ) → pass then
6: return CCi ∪ DD(CC )
7: end if
8: end function

Оптимальный способ
Умный перебор
1: function DD(CC, N)
2: CC = CC1 ∪ . . . ∪ CCN
3: for all CCi do
4: if P(CCi ) → fail then
5: return DD(CCi )
6: else if P(CC CCi ) → fail then
7: return DD(CC CCi )
8: end if
9: end for
10: return DD(CC, 2 × N)
11: end function

Delta debugging на практике
Готовых средств для delta debugging над данными нет
Зависимость Ci от типа данных
Разные проекты могут накладывать дополнительные ограничения
git/hg bisect

W.I.L.T.

Q&A

Тестирование ПО (2016)

More Related Content

What's hot

Viewers also liked

Similar to Тестирование ПО (2016)

Тестирование ПО (2016)