(Testing 102) 02

Проблема тестовых входных данных
Software Testing 101
Марат Ахин
Санкт-Петербургский политехнический университет
2018
Марат Ахин (СПбПУ) Input 2018 48 / 350

Quiz

Recap

Проблемы тестирования
What’s up, Doc? (с)

Проблема наблюдаемости
Проблема «останова»
Проблема тестового оракула

Содержание
1 Проблема тестовых входных данных

Обеспечение достижимости
Входные данные
Тестовые данные
Классы эквивалентности
2 Проблема неявных входных данных
3 Разработка через тестирование
4 Интеграционное тестирование

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

Изменением входных данных
Изменением самого исходного кода
Какой способ можно использовать для обеспечения достижимости

(reachability)?



(reachability)?



(reachability)?



(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


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

Покрывает ли спецификация все множество входных данных?

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

Текущая дата/время
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 t e s t L o g i n F o r V a l i d U s e r () {
3 IPasswordInfo passInfo = mock ( IPasswordInfo . class );
4 when ( passInfo . matches ( anyString ())). thenReturn ( true );
5
6 IAccount account = mock ( IAccount . class );
7 when ( account . ge t Pa ss w or d In fo ()). thenReturn ( passInfo );
8
9 I A c c o u n t R e p o s i t o r y repo = mock ( I A c c o u n t R e p o s i t o r y . 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 t e s t B l o c k O n I n c o r r e c t L o g i n () {
3 IPasswordInfo passInfo = mock ( IPasswordInfo . class );
4 when ( passInfo . matches ( anyString ())). thenReturn ( false );
5
6 IAccount account = mock ( IAccount . class );
7 when ( account . ge t Pa ss w or d In fo ()). 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 t e s t B l o c k O n I n c o r r e c t L o g i n P e r A c c o u n t () {
3 IPasswordInfo aliceInfo = g e t M o c k e d P a s s w o r d I n f o ( false );
4 IPasswordInfo bobInfo = g e t M o c k e d P a s s w o r d I n f o ( false );
5
6 IAccount aliceAcc = g e t M o c k e d A c c o u n t ( aliceInfo );
7 IAccount bobAcc = g e t M o c k e d A c c o u n t ( 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 6= Stubs 6= Fakes 6= Dummies
Разве есть разница?
Dummies
Объект-муляж, не обладающий собственным поведением
Fakes
Упрощенная реализация требуемой функциональности
Stubs
Тестовая заглушка, способная отвечать на внешние запросы
Mocks
Тестовая загрушка, способная отвечать на внешние запросы и
проверять их корректность


Test-driven development
Плюсы TDD
Минусы TDD

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

Для управления явными входными данными
А когда их следует использовать?

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

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

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

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

компонента, тем проще найти ошибки
После разработки компонента пишем для него тест

Отсутствующие части системы заменяем заглушками
...
PROFIT!

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

Пишем тест для компонента перед его разработкой

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

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

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

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

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

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

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

обнаружение ошибки
Малый размер тестов позволяет быстро найти причину ошибки

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

Облегчается раздельное владение кодом

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

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

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

Минусы TDD
Поддержание тестов в актуальном состоянии
При внесении изменений в интерфейсы компонентов системы

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

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

компонентов
Каждый тест проверяет ограниченный фрагмент

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

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

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

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

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

от поведения заглушки
Если заглушек было много...

Каскадное распространение сбоев

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

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

разработки
Заменять заглушки на реализацию инкрементально
Инкрементальное интеграционное тестирование

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

Тестирование начинается с верхних уровней системы

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

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

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

Тестирование начинается с нижних уровней системы

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

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

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

Проблемы тестирования
What’s up, Doc? (с)

Проблема наблюдаемости
Проблема «останова»
Проблема тестового оракула

Обеспечение порчи внутреннего состояния
Для того, чтобы обеспечить порчу внутреннего состояния

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

W.I.L.T.

(Testing 102) 02

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

(Testing 102) 02

Загружено:

Авторское право:

Доступные форматы

Проблема тестовых входных данных

Software Testing 101

Санкт-Петербургский политехнический университет

Марат Ахин (СПбПУ) Input 2018 48 / 350

Марат Ахин (СПбПУ) Input 2018 49 / 350

Марат Ахин (СПбПУ) Input 2018 50 / 350

What’s up, Doc? (с)

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

1 Проблема тестовых входных данных

2 Проблема неявных входных данных

3 Разработка через тестирование

Марат Ахин (СПбПУ) Input 2018 52 / 350

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

Какой способ можно использовать для обеспечения достижимости

Марат Ахин (СПбПУ) Input 2018 53 / 350

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

Какой способ можно использовать для обеспечения достижимости

Марат Ахин (СПбПУ) Input 2018 53 / 350

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

Какой способ можно использовать для обеспечения достижимости

Марат Ахин (СПбПУ) Input 2018 53 / 350

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

Какой способ можно использовать для обеспечения достижимости

Марат Ахин (СПбПУ) Input 2018 53 / 350

Марат Ахин (СПбПУ) Input 2018 54 / 350

Марат Ахин (СПбПУ) Input 2018 55 / 350

Почему бы просто не перебрать все возможные варианты?

1 int add ( int a , int b ) { ... }

А если у тестируемого модуля есть внутреннее состояние?

Марат Ахин (СПбПУ) Input 2018 56 / 350

Марат Ахин (СПбПУ) Input 2018 57 / 350

Все пространство входных состояний можно разбить на

Как найти классы эквивалентности?

Марат Ахин (СПбПУ) Input 2018 58 / 350

Тестирование методом «научного тыка»

Марат Ахин (СПбПУ) Input 2018 59 / 350

А что будет, если я нажму на эту

В чем проблемы при таком подходе к тестированию?

Марат Ахин (СПбПУ) Input 2018 60 / 350

Ad hoc testing + планирование

Марат Ахин (СПбПУ) Input 2018 61 / 350

Если ввести число «42», потом

В чем проблемы при таком подходе к тестированию?

Марат Ахин (СПбПУ) Input 2018 62 / 350

Баю баюшки баю, не ложися на краю...

Находим пограничные значения входных данных

Марат Ахин (СПбПУ) Input 2018 63 / 350

Если умножить любое число на «0»,

В чем проблемы при таком подходе к тестированию?

Марат Ахин (СПбПУ) Input 2018 64 / 350

Марат Ахин (СПбПУ) Input 2018 65 / 350

1 Проблема тестовых входных данных

2 Проблема неявных входных данных

3 Разработка через тестирование

Марат Ахин (СПбПУ) Input 2018 66 / 350

Покрывает ли спецификация все множество входных данных?

Марат Ахин (СПбПУ) Input 2018 67 / 350

Все это – примеры неявных входных данных

Марат Ахин (СПбПУ) Input 2018 68 / 350

Марат Ахин (СПбПУ) Input 2018 69 / 350

Марат Ахин (СПбПУ) Input 2018 70 / 350

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

Simulate and Stub