Основы тест дизайна Test Design

1.

Основы тест дизайна
Test Design

2.

7 Принципов тестирования
Тестирование показывает наличие дефектов (Тестирование может показать наличие дефектов в
программе, но не доказать их отсутствие.)
Исчерпывающее тестирование невозможно (Сколь бы скрупулёзным тестирование не было, нельзя
учесть все возможные сценарии, а значит и предвидеть все возможные ошибки.)
Раннее тестирование (Чем раньше начнутся активности тестирования, тем дешевле исправление
выявленных ошибок. )
Скопление дефектов (80 на 20) (Дефекты не размазаны равномерно по приложению, а
сконцентрированы в больших количествах в некоторых модулях системы)
Парадокс пестицида (Если вы долго проводите одни и те же проверки, скорее всего новых багов вы
не найдете. )

3.

7 Принципов тестирования
Тестирование зависит от контекста (Набор методологий и инструментов, а также подходов и
ресурсов для тестирования зависит от того, что именно вы тестируете и на сколько объект
тестирования важен)
Отсутствие найденных ошибок не есть отсутствие ошибок (Тот факт, что тестирование не
обнаружило дефектов, ещё не значит, что программа хорошая)

4.

Хорошие тесты
● Взаимонезависимы
● Недвусмысленны
● Имеют полную информацию
● Не имеют лишней информации
● Имеют однозначный ассерт
● Атомарны

5.

Test Cases
Позитивные тесты - тесты с данными, введения которых программный продукт ожидает от пользователя.
Которые приводят к получению результата.
Негативные тесты - с данными, которые программный продукт не ожидает от пользователя.
Т.е. такие, после ввода которых, результаты не описаны как ожидаемые
Тесты
Позитивные :)
Негативные :(

6.

Тест дизайн
Тест дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в
соответствии с определёнными ранее критериями качества и целями тестирования
техники тест-дизайна – это совокупность правил, позволяющих правильно определить список проверок для тестирования
задачами тест-дизайна являются:
Анализ требований и рисков тестирования
Определение проверок для тестирования
Формализация проверок в виде тестовых сценариев
Приоритезация проверок
Определение подходов к тестированию

7.

Тест дизайн
План работы над тест дизайном
• анализ имеющихся проектных артефактов: документация (спецификации, требования, планы), модели, исполняемый код
и т.д.
• написание спецификации по тест-дизайну
• проектирование и создание тест-кейсов
Роли, ответственные за тест дизайн
• Тест аналитик - определяет "ЧТО тестировать?"
• Тест дизайнер - определяет "КАК тестировать?"
Попросту говоря, задача тест аналитиков и дизайнеров сводится к тому, чтобы используя различные стратегии и техники тест
дизайна, создать набор тестовых случаев, обеспечивающий оптимальное тестовое покрытие тестируемого приложения.
Однако, на большинстве проектов эти роли не выделяется, а доверяется обычным тестировщикам, что не всегда
положительно сказывается на качестве тестов, тестировании и, как из этого следует, на качестве программного
обеспечения (конечного продукта).

8.

Основные техники тест-дизайна
• Классы эквивалентности
• Тестирование граничных значений
• Таблица принятия решений
• Диаграмма состояний и переходов
• Предугадывание ошибки
• Исчерпывающее тестирование
• …..

9.

Классы эквивалентности (Equivalence class)
Класс эквивалентности (Equivalence class) – это набор входных (или выходных) данных ПО, которые обрабатываются
программой по одному алгоритму или приводят к одному результаты.
То есть, это некое множество значений, которое вы можете подставлять в программу и получать один и тот же результат.
Результатом можем быть не только конкретные значения, действия программы, но и просто область применения. Поэтому,
самые простые классы эквивалентности, на которые делятся проверки, это 2 основных класса: позитивные и негативные
сценарии.

10.

Классы эквивалентности (Equivalence class)
Система для расчета процентной ставки по кредиту для клиента исходя из его возраста, который вводится в форму:
От 18 до 25 лет – 18%
От 25 до 45 лет – 16 %
Свыше 45 лет – 20%
Позитивные: все значения, которые приводят к получению результата
Негативные: значения, результаты которых не описаны, как ожидаемый результат

11.

Классы эквивалентности (Equivalence class)
22
0
-13
14
0
18
30
25
55
45

12.

Анализ Граничных Значений (Boundary Value Analysis)
Граничные значения - это значения, в которых один класс эквивалентности переходит в другой.
Эта техника основана на том факте, что одним из самых слабых мест любого программного продукта является область
граничных значений.
Для начала выбираются диапазоны значений – как правило, это классы эквивалентности.
Затем определяются границы диапазонов.
На каждую из границ создается 3 тест-кейса:
первый проверяет значение границы
второй – значение ниже границы
третий – значение выше границы

13.

Анализ Граничных Значений (Boundary Value Analysis)
17
-1
0
-13
18
19
44
22
1
14
45
30
18
25
24
25
55
45
0
26
46
MAX?

14.

Таблица принятия решений
Decision Table (таблица решений) — техника, помогающая наглядно изобразить комбинаторику условий из ТЗ.
Чем проще и понятнее требования, тем меньше будет разночтений. И тем меньше исправлений после реализации.
И тем проще нам, тестировщикам, писать тест-кейсы по таким требованиям.
В тестировании таблица решений используется для того, чтобы на основе требований составить тест-кейсы. И ничего
не забыть при сложных комбинациях входных условий! Ведь каждая строка или столбец таблицы → готовый тесткейс.

15.

Таблица принятия решений
У нас есть интернет-магазин, в котором можно заказать товар с доставкой или
самовывозом. И оплатить его при получении или заранее на сайте. При этом
Условия
оплата при получении возможна только при самовывозе, а пункт самовывоза
Оплата при получении
находится в Москве. В зависимости от выбранных условий мы ожидаем
Самовывоз
успешное или неуспешное оформление заказа.
Город Москва
Нам необходимо составить таблицу различных проверок, проанализировав
Действия
условия.
Заказ оформлен
1.
Создадим первый столбец с условиями и результатом

16.

Таблица принятия решений
2. Добавим колонки, которые послужат прототипами тест-кейсов
Количество проверок, то есть столбцов(колонок), считается по формуле: T = 2n
Условия
Оплата при получении
Самовывоз
Город Москва
Действия
Заказ оформлен

17.

Таблица принятия решений
3. Заполняем таблицу значениями Да/Нет по правилу:
В первом ряде чередуются значения «Да» и «Нет», начиная с «Да»;
В каждом следующем ряду каждое значение предыдущего ряда удваивается;
В каждый ряд вписывается столько значений, сколько помещается.
Условия
Оплата при получении
да
нет
да
нет
да
нет
да
нет
Самовывоз
да
да
нет
нет
да
да
нет
нет
Город Москва
да
да
да
да
нет
нет
нет
нет
Действия
Заказ оформлен

18.

Таблица принятия решений
4. Упрощаем полученные тест кейсы
В данном случае, если пользователь выбрал оплату при получении, но не самовывоз, то проверять, в каком он городе, не
нужно — такая комбинация параметров доставки не разрешается требованиями.
Условия
Оплата при получении
да
нет
да
нет
да
нет
да
нет
Самовывоз
да
да
нет
нет
да
да
нет
нет
Город Москва
да
да
-
да
нет
нет
-
нет
Действия
Заказ оформлен

19.

Таблица принятия решений
4. Удаляем повторяющиеся комбинации столбцов
В данном случае, если пользователь выбрал оплату при получении, но не самовывоз, то проверять, в каком он городе, не
нужно — такая комбинация параметров доставки не разрешается требованиями.
Условия
Оплата при получении
да
нет
да
нет
да
нет
нет
Самовывоз
да
да
нет
нет
да
да
нет
Город Москва
да
да
-
да
нет
нет
нет
да
да
нет
да
нет
нет
да
Действия
Заказ оформлен

20.

Parwise testing (попарное тестирование)
Суть техники заключается в минимизации вариативности комбинаций проверок, достаточных для обеспечения
высокого качества ПО.
Данная техника была выведена путем более 15-тилетнего исследования IEEE в области анализа причин возникновения
дефектов в системе. Результаты исследования показали, что 98% всех дефектов возникают при конфликте ПАР входных
данных или ОДНОГО входного параметра.
Когда мы с вами тестируем программу, всегда есть n количество элементов, которые влияют на результат, например,
форма заполнения данных по кредитной заявке. Там есть n количество полей, которые в совокупности дают результат.
Именно комбинаторику данных при заполнении полей мы проверяем с помощью попарного тестирования.

21.

Parwise testing (попарное тестирование)
Для Pairwise достаточно, чтобы каждое значение всех параметров хотя бы единожды сочеталось с другими значениями
остальных параметров.
Таким образом, матрицу можно значительно сократить.
Есть множество ресурсов, которые могут сделать все за вас, например: https://pairwise.yuuniworks.com/
Браузер
Chrome, Opera
ОС
Windows, Linux
Язык
RU, ENG

22.

Parwise testing (попарное тестирование)

23.

Тестирование состояний и переходов
Мы рисуем:
кружочки — состояния объекта;
стрелочки — то, благодаря чему из состояния А в
состояние В. Это действие, но его может
совершить не только пользователь, но и система
сама. Например, задача запустилась
автоматически в 10 часов вечера.
Такая схема позволяет нам сразу визуально оценить,
какие переходы вообще возможны и что надо
протестировать.

24.

Parwise testing (попарное тестирование)
Суть техники заключается в минимизации вариативности комбинаций проверок, достаточных для обеспечения
высокого качества ПО.
Данная техника была выведена путем более 15-тилетнего исследования IEEE в области анализа причин возникновения
дефектов в системе. Результаты исследования показали, что 98% всех дефектов возникают при конфликте ПАР входных
данных или ОДНОГО входного параметра.
Когда мы с вами тестируем программу, всегда есть n количество элементов, которые влияют на результат, например,
форма заполнения данных по кредитной заявке. Там есть n количество полей, которые в совокупности дают результат.
Именно комбинаторику данных при заполнении полей мы проверяем с помощью попарного тестирования.

25.

Тестирование состояний и переходов
выбор
билетов
подтвер
ждение
оплата
отмена
заказа
билет

26.

Тестирование состояний и переходов
выбор билетов
выбор билетов
подтверждение
оплата
билет
отмена заказа
+
-
-
+
+
-
+
+
+
подтверждение
-
оплата
-
-
билет
-
-
-
отмена заказа
-
-
-
-

27.

Задача 1 (граничные значения)
Автоматическая система выдачи кредита получает на вход возраст клиента
▪
▪
Не выдает кредит, если меньше 18
Выдает во всех остальных случаях

28.

Задача 2 (эквивалентные классы)
Автоматическая система выдачи кредита получает на вход возраст клиента
▪
▪
▪
Не выдает кредит, если меньше 18,
Выдает 50% кредита, от 18 до 25
Выдает 100% кредита во всех остальных случаях

29.

Задача 3 (таблица принятия решений)
Автоматическая система выдачи кредита получает на вход возраст клиента и данные о предыдущих
кредитах
▪
▪
▪
▪
Не выдает кредит, если меньше 18,
Выдает 150% кредита если прошлый кредит возвращен вовремя
Не выдает, если прошлый возвращен с опозданием
Выдает 100% кредита во всех остальных случаях

30.

Задача 4 (попарное тестирование)
▪ Как в задаче 3, только условий намного больше

31.

Задача 5 (диаграмма состояний и переходов)
▪
По заявке пользователя создается кредит
▪
Автоматическая программа либо одобряет кредит на N сумму или нет
▪
Если кредит одобрен подключается менеджер, набивая кредит документами
▪
Когда все бумаги и подписи есть, клиент получает деньги
▪
Если документов не хватает, заявка переходит в “ожидание документов”
▪
Если пользователь не платит кредит помечается как просроченный
▪
Если пользователь все оплатил кредит закрывается.