Тестирование ПО (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

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

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

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

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