Зарегистрируйтесь, чтобы продолжить обучение

Техники тест-дизайна Рабочий процесс тестировщика

Тест-дизайн

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

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

Разработка тестов начинается после проведения исследования ПО, когда цели определены, а критерии тестирования заданы и выполняются.

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

Техники тест-дизайна помогают:

  1. Исключить непродуктивные тест-кейсы и сократить общее количество кейсов
  2. Покрыть тестами как можно больше функциональности
  3. Провести все тесты и не пропустить ничего важного

Для работы с кодом (white-box) важны такие аспекты:

  • Покрытие операторов
  • Покрытие условий
  • Покрытие путей
  • Покрытие функций
  • Покрытие вход/выход
  • Покрытие значений параметров

В работе с требованиями (black-box) тестирование проходит иначе:

  • Классы эквивалентности
  • Граничные значения
  • Попарное тестирование
  • Таблица принятия решений
  • Диаграмма состояний и переходов
  • Тестирование вариантов использования
  • Доменное тестирование.

Техники тест-дизайна на основании требований

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

Техника классов эквивалентности – это разделение диапазона возможных вводимых значений на группы эквивалентных по своему влиянию на систему. Эта техника помогает не только сокращать количество тестов, но и сохранять приемлемое тестовое покрытие.

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

  • от 1 до 999 долларов включительно – 0%
  • от 1000 до 4999 долларов включительно – 5%
  • от 5000 долларов – 7%

Максимальная сумма перевода – 100000 долларов, при этом дробные числа не учитываются.

Попробуем выяснить, сколько требований будет в этом случае. В этом помогут классы эквивалентности:

  • 1-999 => ожидаем комиссию 0%
  • 1000-4999 => ожидаем комиссию 5%
  • 5000-100000 => ожидаем комиссию 7%

Выбранные значения для проверки: 500, 2500, 7500.

  • На значение 500 система отреагирует так же, как и на любое другое значение из первого диапазона
  • На значение 2500 система отреагирует так же, как и на любое другое значение из второго диапазона
  • На значение 7500 система отреагирует так же, как и на любое другое значение из третьего диапазона

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

Граничные значения – это значения, в которых один класс эквивалентности переходит в другой. По своей сути это техника, которая дополняет технику классов эквивалентности.

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

Например, неопытный программист при постановке «не больше 1000» может поставить значение <1000.

Вернемся к примеру с комиссией:

  • от 1 до 999 долларов включительно – 0%
  • от 1000 до 4999 долларов включительно – 5%
  • от 5000 долларов – 7%

Максимальная сумма перевода – 100000 долларов, при этом дробные числа не учитываются. Вспомним классы эквивалентности:

  • 1-999 => ожидаем комиссию 0%
  • 1000-4999 => ожидаем комиссию 5%
  • 5000-100000 => ожидаем комиссию 7%

Граничные значения: 1, 999, 1000, 4999, 5000, 100000.

С учетом классов эквивалентности и граничных значений выбираем значения для проверки: 1, 500, 999, 1000, 2500, 4999, 5000, 7500, 100000.

Попарное тестирование (pairwise)

Попарное тестирование – техника тест-дизайна, при которой тест-кейсы создаются так, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров.

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

Рассмотрим пример. Возьмем наушники с такими характеристиками:

  • Тип подключения (беспроводной или проводной)
  • Микрофон (включен или выключен)
  • Подсветка (включена или выключена)

Полный перебор даст нам восемь тест-кейсов. Это 2 в третьей степени, потому что у каждого из трех параметров может быть всего два значения:

# Тип подключения Микрофон Подсветка
1 Проводной Включен Включена
2 Проводной Включен Выключена
3 Проводной Выключен Включена
4 Проводной Выключен Выключена
5 Беспроводной Включен Включена
6 Беспроводной Включен Выключена
7 Беспроводной Выключен Включена
8 Беспроводной Выключен Выключена

Как правило, подобных характеристик в реальном мире куда больше, что неизбежно увеличивает количество тест-кейсов.

При попарном тестировании достаточно проверить лишь пары значений. При успешном выполнении тестов на 97% мы можем быть уверены, что проверяемая функциональность работает корректно.

  • 1 нет, нет, нет -> нет, нет, нет -> нет, нет, нет (00, 00, 00)
  • 2 да, да, нет ->да, да, нет -> да, да, нет (11, 10, 10)
  • 3 нет, да, да -> нет, да, да -> нет, да, да (01, 11, 01)
  • 4 да, нет, да -> да, нет, да -> да, нет, да (10, 01, 11)

При трех параметрах, каждый из которых имеет 3 значения, количество вариантов полного перебора – 27 (три в третьей) Применив pairwise, количество тест-кейсов сведётся к 9.

# Тип подключения Микрофон Подсветка
1 Беспроводной Выключен Выключена
2 Проводной Включен Выключена
3 Беспроводной Включен Включена
4 Проводной Выключен Включена

Таблица принятия решений

Таблица решений или матрица решений — способ компактного представления модели со сложной логикой; инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте.

Это взаимосвязь между множеством условий и действий.

Таблица принятия решений содержит следующие элементы:

  • Условия — список возможных условий
  • Варианты — комбинация из выполнения и/или невыполнения условий этого списка
  • Действия — список возможных действий (вариантов исхода)

Например, кредит выдаётся людям, удовлетворяющим трём условиям:

  • Возраст: 18-60 лет
  • Гражданство: Россия
  • Стаж работы: более 5 лет ИЛИ средняя месячная зарплата за год больше 100 тысяч рублей
Условие Значение 1 Значение 2 Значение 3 Значение 4
Возраст 18-60 да да да нет
Гражданство РФ да да да да
Стаж больше 5 лет да нет да да
ЗП выше 100 тысяч рублей нет да да да
Действие
Кредит одобрен да да да нет

Диаграмма состояний и переходов

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

Диаграммы состояний и переходов показывают только действительные переходы и исключают недействительные переходы.

Состояние А ——переход—–> Состояние Б

переходы состояний для статьи на Хекслете

Тестирование вариантов использования

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

Вариант использования или юз-кейс – это описание конкретного использования системы субъектом или пользователем

Юз-кейсы содержат следующие сведения:

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

Доменное тестирование

Доменное тестирование (domain analysis) — методика разработки тестов, использующаяся для определения действенных и эффективных тестовых сценариев в случаях, когда множественные параметры могут или должны быть протестированы одновременно.

Доменное тестирование применяется для сокращения количества проводимых тестов без потери качества тестирования.

Очень часто классы эквивалентности, относящиеся к позитивным проверкам, можно проверять совместно.

Возьмем для примера такие требования:

  • Размер файла: до 200 МБ
  • Имя файла: от 5 до 24 символов, только латиница
  • Форматы файлов: только изображения

В этом случае нужны такие проверки:

  1. Загрузить файл менее 200 МБ
  2. Загрузить файл с именем hexlet
  3. Загрузить файл с расширением .jpg

Можно заменить одной проверкой:

  1. Загрузить файл менее 200 МБ, с именем hexlet.jpg

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

Например, не нужно проверять конфигурацию компьютера с комплектующими, которые никогда не будут поставляться вместе (слабый процессор и сильная видеокарта). Также не нужно проверять конфигурацию автомобиля с агрегатами, которые никогда не будут поставляться вместе (дизельный мотор + турбонаддув).

Часто такая же ситуация может возникнуть при тестировании фильтров в интернет-магазинах. Часто параметр2 имеет строго определенное значение при выборе параметра1, поэтому проверять все возможные значения параметра2 в паре с параметром1 – смысла не имеет.


Дополнительные материалы

  1. Pairwise Pict Online
  2. Pairwise Tool
  3. Pict

Для полного доступа к курсу нужен базовый план

Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.

Получить доступ
1000
упражнений
2000+
часов теории
3200
тестов

Открыть доступ

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

  • 130 курсов, 2000+ часов теории
  • 1000 практических заданий в браузере
  • 360 000 студентов
Отправляя форму, вы принимаете «Соглашение об обработке персональных данных» и условия «Оферты», а также соглашаетесь с «Условиями использования»

Наши выпускники работают в компаниях:

Логотип компании Альфа Банк
Логотип компании Aviasales
Логотип компании Yandex
Логотип компании Tinkoff