! Разумеется техники тест-дизайна применяются не только в ручном тестировании, но на примере ручного тестирования их рассматривать легче всего !

Общая суть

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

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

Принцип работы

В приложении присутствует возможность купить или продать некоторые товары. Каждому товару системой присваивается уникальный идентификатор. Сервис работает в трех городах, в Москве, Санкт-Петербурге, Астрахани. Доступна как доставка, так и самовывоз. При этом можно выбрать время доставки/самовывоза. Таким образом имеем много параметров, каждый из которых может принимать ряд значений. Давайте сделаем все более нагляднее.

  1. Тип операции
    • 1.1. Покупка
    • 1.2. Продажа
  2. Идентификатор товара
    • 2.1 хххххх
    • 2.2 ххххху
    • …
    • 2.х zhesttt
  3. Город
    • 3.1 Москва
    • 3.2 Санкт-Петербург
    • 3.3 Астрахань
  4. Тип заказа
    • 4.1 Доставка
    • 4.2 Самовывоз
  5. Время доставки
    • 5.1 0:00
    • 5.2 0:01
    • …
    • 5.у 23:59

Таким образом, используя несложную математику, получаем, что нам необходимо вручную проверить всего лишь 2*х*3*2*у сочетаний параметров, чтобы удостовериться, что ни одно из них не ломает приложение. Давайте поступим немного умнее. Для начала, распределим их по классам эквивалентности.

Давайте поделим время заказа на 2 ключевых типа - рабочее и нерабочее. То же сделаем и с номерами заказа - поделим их на валидные и невалидные. Тогда задача немного упростится.

  1. Тип операции
    • 1.1. Покупка
    • 1.2. Продажа
  2. Идентификатор товара
    • 2.1 Валидный
    • 2.2 Невалидный
  3. Город
    • 3.1 Москва
    • 3.2 Санкт-Петербург
    • 3.3 Астрахань
  4. Тип заказа
    • 4.1 Доставка
    • 4.2 Самовывоз
  5. Время доставки
    • 5.1 Рабочие часы
    • 5.2 Нерабочие часы

Пересчитаем.

2*2*3*2*2=48 проверок. Все ещё слишком много.

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

Давайте вернемся к нашему простому примеру.

Путем нехитрой комбинаторики, более подробно про суть которой можно почитать тут (https://www.learnqa.ru/tpost/fzn80c7jr1-parnoe-testirovanie-pairwise-testing-osn), получаем следующие комбинации:

Рабочее-Доставка-Москва-Валидный-Покупка
Нерабочее-Самовывоз-Спб-Невалидный-Покупка
Нерабочее-Доставка-Астрахань-Валидный-Продажа
Рабочее-Самовывоз-Москва-Невалидный-Продажа
Рабочее-Самовывоз-Астрахань-Валидный-Покупка
Рабочее-Доставка-Спб-Валидный-Продажа
Нерабочее-Доставка-Москва-Невалидный-Покупка
Рабочее-Доставка-Астрахань-Невалидный-Покупка

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

Минусы

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

Реальный пример

Разберем работу метода на примере тестирования простенькой фичи. Допустим, у нас есть некая система, выполняющая какие-то задачи. Нам необходимо протестировать фичу - добавление расписания запуска этих задач. Расписание может быть либо включено, либо выключено. У него есть несколько форматов - ежедневно, по будням, по выходным, каждую неделю, каждый месяц, однократно. У расписания можно выставлять любое время, любые “границы”, когда оно будет выполняться, есть механика смены часовых поясов. Однако это еще не все. Помимо параметров для расписания, нужно не забывать и про те самые задачи, для которых мы это расписание выставляем. Конечно, для этого можно и нужно использовать и регресс-тесты(подробно о них - тут(Тут будет ссылка на соответствующий пост из канала который будет написан позже)), однако не стоит забывать, что задачи тоже бывают разных типов, и могут выполнять разные действия, в том числе, могут завершаться с ошибкой - поведение расписания в таких случаях тоже необходимо протестировать. Соответственно, руководствуясь только методом попарного тестирования получится огромное число проверок, при этом далеко не все возможные дефекты будут покрыты. Не стоит забывать и о том, что в нашем конкретном примере “поведение” системы будет изучить еще труднее, потому что расписание типа “раз в месяц”, “раз в неделю” необходимо будет проверить на фактическое выполнение, а сделать это будет непросто только из-за времени ожидания.

Поэтому в таких случаях нам необходимо использовать саму методологию, саму идею попарного тестирования. Необходимо находить во всей фиче те параметры, которые можно “скрестить”, чтобы уменьшить количество проверок, не потеряв в качестве. Например, в случае с расписанием, такими параметрами является “формат” расписания и его “статус”, в совмещении, например, с валидностью или невалидностью заданного интервала выполнения задачи, а также с условным параметром Х самой задачи, который, допустим, может принимать значения х_1 и х_2(это может быть, к примеру, статус завершения задачи - “успешно” или “неуспешно”)

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

Интервал  Формат  Статус
Валидный   Ежедневно Вкл
Невалидный По будням Вкл
Невалидный Ежедневно Выкл
Валидный По будням Выкл
Валидный   Каждый месяц Вкл
Валидный  По выходным Вкл
Валидный  Однократно Вкл
Невалидный Каждый месяц Выкл
Невалидный По выходным Выкл
Невалидный Однократно Выкл

Вторая будет проверять, сохранится ли расписание в зависимости от того, выполнялась задача раннее успешно или неуспешно


Статус завершения задачи  Формат  Статус
Успешный  Ежедневно  Вкл
Неуспешный  По будням  Вкл
Неуспешный  Ежедневно  Выкл
Успешный  По будням  Выкл
Успешный  Каждый месяц  Вкл
Успешный  По выходным  Вкл
Успешный  Однократно  Вкл
Неуспешный  Каждый месяц  Выкл
Неуспешный  По выходным  Выкл
Неуспешный  Однократно  Выкл

Попарное тестирование уже сократило количество проверок до 20, однако по 10 проверок на такие простые вещи - не очень приятно. Вручную их проводить еще имеет смысл(хоть и небольшой), а вот писать автотесты для дальнейших регрессивных проверок на все 20 кейсов - нет. Потому, имеет смысл еще больше сократить проверки. Оставим по 5 штук на каждую, удалив из первой - первые 5, из второй - вторые 5. Таким образом пары параметров, которые мы добавили самой фичей, все равно будут полностью покрыты, при этом мы избежим избыточного тестирования.

!!!!!!!!!!!!!!! Разумеется, последний абзац не применим для всех случаев. Необходим тщательный анализ каждой отдельной ситуации, анализ рисков при отказе от некоторых тест-кейсов. В некоторых случаях по 10 проверок действительно необходимы, но мы говорим про общий случай.

Итог

1️. Попарное тестирование (Pairwise Testing) – это техника тест-дизайна, которая сокращает количество тест-кейсов, сохраняя при этом высокое качество проверок. 2️. Применение: особенно полезно при работе с системами, где есть множество параметров с разными значениями.

  1. Принцип работы:
    • Каждый параметр разбивается на возможные значения.
    • Создаются комбинации параметров так, чтобы каждая пара значений встречалась хотя бы раз.
    • Это позволяет уменьшить количество тестов без значительной потери покрытия дефектов.
  2. Пример с маркетплейсом:
    • Без оптимизации: 2 * x * 3 * 2 * y проверок.
    • После применения классов эквивалентности: 2 * 2 * 3 * 2 * 2 = 48 проверок.
    • После применения pairwise testing – всего 8 тест-кейсов.
  3. Минусы:
    • Не универсальна, требует комбинирования с другими техниками.
    • Иногда сложно определить, какие параметры нужно учитывать.