Добро пожаловать!

Ежедневной задачей инженера по контролю качества (QA Engineer) является создание тест-кейсов для проверки требований продукта. В этой статье я собрал для вас техники проектирования тестов, которые помогут оптимизировать ваш набор тестов.

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

Является основной техникой проектирования тестов, которую должен использовать каждый инженер по контролю качества.

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

Пример

У меня есть калькулятор инвестиций, который содержит поле процента прибыли, которое мне необходимо указать. Разрешенные значения находятся в диапазоне от 1 до 100 по требованию заказчика.

Шаг 1: Определите эквивалентные классы:

• Положительные числа (1–100)

• Отрицательные числа и ноль (<=0)

• Больше допустимого (>100)

• Буквы (a-z, a-Z, кириллица, арабский и т. д.)

• Специальные символы (!@# и т. д.)

Шаг 2: Выберите одно значение для каждого класса. И у нас есть следующие тест-кейсы для проверки: 50, -10, 146, aBc, !

Где использовать?

Везде! При тестировании пользовательского интерфейса (UI) - это поля, даты, конкретные кнопки. При тестировании API нам нужно проверить все возможные параметры в теле запроса (body), заголовках (headers), пути (path) или параметрах запроса (query parameters).

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

Эта техника является "братом" разбиения на классы эквивалентности.

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

Пример:

Интернет-магазин предоставляет скидку 10%, если сумма покупки превышает $100.

Шаг 1: Определите эквивалентные классы и границы каждого из них:

• Сумма покупки <= $100

• Сумма покупки > $100

Шаг 2: Выберите значения, находящиеся на границе этих классов с минимальным отклонением, а также само граничное значение:

• Сумма покупки = $99.99: скидка не применяется

• Сумма покупки = $100: скидка не применяется

• Сумма покупки = $100.01: скидка применяется

Где использовать?

Ответ тот же, что и для разбиения на классы эквивалентности - везде.

#3 Причинно-следственный анализ

Каждое приложение ведет себя схоже — производит определённый отклик на каждое действие пользователя.

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

Пример:

Как пользователь, я заполняю поля логина и пароля и нажимаю кнопку OK. Я ожидаю, что мои данные пользователя будут сохранены в базе данных. Это простой пример, чтобы помочь вам понять технику. Более сложные случаи могут быть рассмотрены в будущем.

• Шаг 1: Определите карту причин и откликов.

• Шаг 2: Создайте таблицу принятия решений на основе этой карты.

Где использовать?

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

#4 Прогнозирование ошибок

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

Пример

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

• Шаг 1: Определите отрицательные случаи для функциональности, которую нужно протестировать на основе каждой техники проектирования тестов.

• Шаг 2: Определите, что ожидается для каждого отрицательного сценария из шага #1.

Где использовать?

Везде, где пользователь может предоставлять данные. Для UI это могут быть формы, флажки, кнопки и т. д. Для API-сервисов - параметры запроса, параметры пути, параметры тела.

#5 Парное тестирование

Этот подход основан на большом количестве входных параметров. Чем больше параметров, тем больше вероятность ошибки. Наша цель как специалиста по тестированию — сократить количество тест-кейсов до оптимального. Подход парного тестирования поможет нам в этом.

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

• Шаг 1: Определите возможные параметры и их значения для функциональности, которую необходимо протестировать.

• Шаг 2: Создайте тест-кейсы, чтобы включить все возможные пары между каждыми 2 параметрами. Вы можете использовать инструменты, такие как https://pairwise.teremokgames.com/, чтобы облегчить свою работу.

Где использовать?

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

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

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

Смысл данного подхода заключается в создании карты переходов для каждого типа объекта и создании набора тестов, охватывающих все переходы между состояниями.

Пример:

Пользователь имеет возможность написать комментарий к посту. Затем он может изменить или удалить этот комментарий. У комментариев есть несколько состояний: создан, изменен, удален. Каждое из этих состояний может быть характеризовано набором уникальных свойств.

• Шаг 1: Определите объект, который мы хотим протестировать.

• Шаг 2: Нарисуйте прямоугольник для каждого состояния, определенного для объекта.

• Шаг 3: Создайте переходы между состояниями и отметьте каждый из них связанным действием.

• Шаг 4: Вы готовы создавать положительные и отрицательные тест-кейсы.

Где использовать?

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

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

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

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

Пример

Водитель хочет купить страховку. Цена зависит от общего опыта и прошлых инцидентов. Допустим, если у меня есть 5 лет опыта, я могу получить скидку 10% от базовой цены (100 долларов), а если у меня не было аварий за последний год, то я могу получить еще 10%.

• Шаг 1: Подготовьте список входных параметров с возможными доступными значениями:

• Шаг 2: Создайте строки с каждым именем параметра в первом столбце.

• Шаг 3: Создайте тестовую таблицу на основе всех возможных комбинаций параметров и заполните эти данные в следующих столбцах таблицы.

• Шаг 4: Попробуйте найти тестовые примеры, которые «дублируются», например, где результаты зависят от 1 параметра, а остальные параметры не имеют значения. Эти тестовые случаи могут быть исключены из окончательного набора тестов.

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

Где использовать?

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

Заключение

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

Вот список техник, которые я упомянул:

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

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

3. Причинно-следственный анализ

4. Прогнозирование ошибок

5. Парное тестирование

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

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

Желаю удачи и не останавливайтесь тестировать!