Тест-дизайн

Селиверстова Наталия

Шаров Илья

О чем лекция?

Что такое тест-дизайн

Техники тест-дизайна

Приемы для проектирования тестов

Практика!

Часть 1

Теория

Исчерпывающее тестирование

Проверяем все воможные случаи/варианты значений

Если случай тривиальный или проверка экстремально важна

Исчерпывающее тестирование

Тест-дизайн

процесс проектирования тестовых случаев

Техники тест-дизайна

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

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

Техника для проверки разных наборов входных данных

Строится на предположениях:

• для тестов с элементами из одного класса одинаковый ожидаемый результат
• если один элемент класса находит ошибку, то и другой ее найдет

Пример: Длина метки

Длина названия метки не должна превышать 20 символов

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

Что проверим в итоге?

Граничные значения

Техника для проверки разных наборов входных данных

Строится на предположении:

• ошибки чаще всего случаются на границах классов эквивалентности

Граничные значения

Приграничные значения

Классы + границы = тесты:

• 0 символов
• 1 символ
• 12 символов
• 19 символов
• 20 символов
• 21 символ
• 35 символов

Правило!

Сначала всегда проверяются положительные тест-кейсы

Они самые важные

Классы могут быть разные

• по количеству символов
• по типу символов
• размер картинки в верстке
• размер загружаемого файла
• крайние даты месяца/года
• и т.д

Как искать классы и границы?

1. Каким бывает тестируемое поле?
2. Каким оно не бывает?
3. Какие есть границы между 1 и 2?

Какие проводить тесты?

1. Выбрать по 1 представителю от каждого класса
2. Выбрать значения на границах
3. Выбрать приграничные значения

Идеи для проверок полей ввода

• ограничения на длину поля (не больше 9)
• ограничения на вводимые символы (“,%@, abc)
• ограничения на положение символов (твит c #)
• валидность по типу поля (32 мая)
• обязательность/пустое поле
• лишние пробелы (в начале/конце/середине)

Попарное тестирование

Техника для формирования сочетания данных, когда есть зависимые поля, и нужно проверить все

Строится на предположении:

• большинство ошибок находятся на одном параметре или сочетании двух

Попарное тестирование

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

Попарное тестирование

Попарное тестирование

Правило!

Нельзя объединять два негативных кейса в один

Иначе будет непонятно, который обработался программой

Диаграмма состояний

Техника для сущностей, у которых есть жизненный цикл

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

Диаграмма состояний

Диаграмма состояний

• Состояние
• Переход
• Событие/условие
• Действие
• Точки входа/выхода

Что проверяем?

1. Как система ведет себя в определенном состоянии?
2. Факт перехода между состояниями?
3. Если не выполнены все условия для перехода?
4. Если выполнены все условия/события для перехода?

Диаграмма состояний

Что еще?

Найти и проверить запрещенные переходы при помощи матрицы переходов

Состояния письма

1. Сразу после получения сообщений с почтового сервера они помечены как непрочитанные.
2. Когда пользователь открывает письмо, сообщение становится прочитанным.
3. Пользователь может пометить ранее прочитанные сообщения как непрочитанные.
4. Пользователь может удалить сообщения (как прочитанные, так и непрочитанные), вернуть их нельзя

Диаграмма состояний

Матрица переходов

Пример диаграммы состояний

Пример диаграммы состояний

MindMap

Инструменты MindMap

• XMind
• MindJet Mindmanager
• Mindmeister
• FreeMind
• и др.

Декомпозиция при помощи MindMap

Другие приемы в тестировании

Прием "4 действия с объектом"

1. Создание
2. Просмотр
3. Редактирование
4. Удаление

Причина - следствие

Причина: Ввод значения в поле и нажатие "Добавить"

Следствие: Добаленное значение отображается во всех нужных местах

"НЕ" к каждому слову в требовании

Если (не) код (не) введен (не) верно, открывается страница регистрации

Предугадывание ошибки

"Пользователь должен ввести код"

1. А что если не ввел код?
2. А что если неправильный код?
3. и тд

Техники и приемы

• Классы эквивалентности и анализ граничных значений
• Попарное тестирование
• Диаграмма состояний и матрица переходов
• Приемы: 4 действия, причина-следтсвие, "не" и предугадывание

Зачем?

• Структурировать
• Найти все необходимые проверки
• Сделать тестов меньше, а покрытие больше

Покрытие

Метрика качества тестирования. Полнота охвата тестами требований или кода.

Отношение количества тестов к количеству требований.

Качество построенных тестов зависит от полноты информации о продукте.

Пример

Если при оформлении заказа товар закончился или цена изменилась, то нужно сообщить об этом покупателю

Пример

Пример

Пример

Обращение по API к магазину происходит трижды

(прием "причина-следствие")

Пример

Еще раз

Качество построенных тестов зависит от полноты информации о продукте.

Спасибо за внимание!

Вопросы?

Часть 2

Практика

Протестируем форму регистрации

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

Конфигурационное тестирование

Функциональное тестирование

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

Поле ввода "Имя"

Требования:

1. Принимает буквенные значения

2. Длина от 2 до 30 символов

3. Обязательно к заполнению

Определим классы эквивалентности

Определим граничные значения

Позитивные проверки

Негативные проверки

Поле ввода "Email"

Требования:

2. Поле проверяет, чтобы email был формата login@domain.tld

3. Максимальная длина 40 символов

4. Обязательно к заполнению

Позитивные проверки

Негативные проверки

Нашли Дефект!

Регистрация проходит без заполнения email

Что делаем?

Это баг?

Воспроизводится?

Известно ли о проблеме?

Сообщаем миру :)

Поле ввода "Возраст"

Требования:

1. Диапазон значений от 18 до 160

2. Принимает только числовые значения

3. Обязательно к заполнению

Позитивные проверки

Негативные проверки

Форма загрузки

Требования:

1. Только указанные форматы (zip,rar,jpeg)

2. Размер файла от 1 MB до 40 MB

3. Обязательно к заполнению

Позитивные проверки

Негативные проверки

Поле ввода "О себе"

Требования:

1. Вмещает 240 символов

2. Не обязательно к заполнению

Позитивные проверки

Негативные проверки

Можно ли как-то улучшить?

Подтверждение

Требования:

1. Обязательно к заполнению

Доработка формы

Заключительная часть

Тестирование - анализ продукта на соответствие требованиям

Важно анализировать требования

Вопросы?

Домашняя работа

Найти все варианты проверок поля First Name

Литература

Про Тест Дизайн

Техники Тест Дизайна

Чит листы

Как строить интеллектуальные карты

Классы эквивалентности. Баранцев А.

Переходя все границы. Баранцев А.