Техника тест-дизайна: Попарное тестирование (pairwise testing, all-pairs testing)
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для Вас с целью персонализации сервисов и предложений. Вы можете прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом без изменения настроек, вы даёте согласие на использование ваших cookie-файлов.
speech bubble

Техника тест-дизайна: Попарное тестирование (pairwise testing, all-pairs testing)

Техника тест-дизайна: Попарное тестирование (pairwise testing, all-pairs testing)

Попарное тестирование» сложнейшая из техник тест дизайна, как в плане понимания идеи сотворения, так и в отношении применения. Перечень понятий для применения pairwise:

  • Техника не покроет 100% тестируемой функции;
  • Попарное тестирование предназначено для нахождения проблемных мест с указанием параметров и значений, обнаружением максимум багов без избыточных проверок;
  • Полученные пары отличаются от пар других людей, программ;
  • Старайтесь составлять пары не ради количества, а анализировать сценарии, помогающие в тестовом покрытии приложения;

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

 

Внимание! Приводятся примеры попарного тестирования (pairwise testing, all-pairs testing) с позитивными сценариями тестирования. Негативные сценарии зависят от условий и требований в ТЗ. Примеры для попарного тестирования произвольные и не с действующих проектов. Совпадения случайны.

 

Введение в попарное тестирование (pairwise testing, all-pairs testing)

Попарное тестирование (pairwise testing) — техника тест-дизайна, используемая тестировщиками и тест-дизайнерами для формирования наборов (Test-suite) значений для тестирования с индивидуальным сочетанием каждых из проверяемых параметров хотя бы раз с остальными проверяемыми параметрами. Проверка тестируемых значений путём формирования уникальных пересекающихся комбинаций.

Сложно для понимания, попробуем объяснить попарное тестирование простыми словами и примерами. Возьмем рабочую область выбора шрифтов в MS Word:

 

Для выбора необходимого текста, пользователь указывает: шрифт, начертание, размер, цвет текста, подчеркивание, цвет подчеркивания, видоизменение. В параметрах достаточное количество значений для миллионных комбинаций. Для составления комбинаций, тест-кейсов, чек-листов тестировщику потребуется несоизмеримое количество времени, не говоря о прохождении тестов. Образовалась теория, которая гласит: «Максимальное количество дефектов появляется при комбинации двух параметров между собой». Пользователь выбирает следующие параметры: основной текст + обычный + 11 + красный + подчеркивание (нет) + с тенью + контур. Ошибка возникнет не при выборе параметров вместе, а при сочетании пары обычный + контур. Методика и кроется в all-pairs testing, в проверке двух параметров между собой, сокращая количество тестов и увеличивая эффективность тестового покрытия. С преимуществами попарного тестирования выявляются и недостатки. На практике недостатки упираются в опыт работы и знание слабых мест тестируемого ПО.

 

Недостатки попарного тестирования:

  • При неправильном использовании, образовываются бесполезные, "вредные",  излишние проверки для тестирования проверяемого функционала
  • При частых изменениях функционала, проверки становятся неактуальными и приходится подготавливать новый test-suite входных параметров
  • При ручном составлении пар появляется вероятность упустить необходимые проверки
  • При автоматическом составлении пар требуются ручные корректировки
  • Метод эффективен на поздних этапах разработанного функционала
  • Взаимосвязь между парами недостаточно изучена

 

Алгоритм составления пар pairwise, all-pairs:

  • выбрать параметр с самым большим количеством значений
  • составить уникальные пары с параметром
  • сравнить остальные параметры с последним
  • удалить повторяющиеся значения
  • получить результат
  • редактировать, выбрать и добавить интересующие проверки

 

Пример попарного тестирования для рецепта

По традиции приводим бытовой пример. Повару-тестировщику дали набор ингредиентов и попросили найти идеальный рецепт блинов:

  • Кефир 500 мл, 750мл, 1000 мл
  • Куриное яйцо 1 шт., 2шт, 3шт
  • Соль 0.5 ч. л., 0.75 ч. л., 1 ч. л.
  • Сахар 1 ст. л., 1,5 ст. л.
  • Сода 1 ч. л., 2 ч. л.
  • Пшеничная мука хлебопекарная 280 г, 430 г., 560 г
  • Молоко 250 мл, 400мл, 500 мл
  • Растительное масло 2 ст. л., 2,5 ст. л., 3 ст. л.

 

Если повар начнёт перебирать доступные комбинации, то компания не сильно обрадуется, когда предъявят счёт. На этом этапе решается использовать технику попарного тестирования. В конечном итоге, будет не только близок к идеальному рецепту, но возможно и получит его.

Выбираем параметр с максимальным количеством значением и идём по нисходящей. Составляем уникальные пары с параметром «Кефир» и «Куриное яйцо»:

Для двух параметров не составляет труда, но QA инженер в дальнейшем объединит доступные параметры. Делаем пары по алгоритму техники тест-дизайна для «Куриное яйцо» и «Соль»:

Обратите внимание, пары получились уникальными везде. Не спешите, будьте внимательны, в дальнейшем концепция формирования пар кардинально поменяется. По аналогии добавим «Соль», «Пшеничная мука хлебопекарная»:

Составляем пары до параметра «Сахар»:

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

Тестировщик включает голову и рассуждает логически: «Получил повторяющиеся пары в последнем и предпоследнем столбце, а так же повторяющиеся значения в первом столбце «Кефир». Как следствие, выберу пары,  удовлетворяющие требованиям»:

Повар-тестировщик удалил, руководствуясь ТЗ и здравым смыслом, неудачные пары, а для 1000мл поменял местами значения в параметре «Сахар». Проделываем аналогичные действия для параметра «Сода» и подкорректируем остальные параметры:

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

В конце таблицы добавили недостающие пары между собой.

Вопрос: «Зачем удаляли пары из таблицы, как получились последние 3 строки?».

Техника попарного тестирования скрывает логику в самом названии. До последнего шага сравнивали пару с предыдущей (кроме момента, когда значений стало меньше), а на конечном этапе добавили недостающие пары, такие как 500мл+3шт, 3шт+0.5ч.л, 0.5ч.л + 560 г. и так далее.

 

Пример попарного тестирования кроссбраузерности сайта

Для тестировщика подготовили требования:

  • П.1 Сайт поддерживается в браузерах последних версий Chrome, FireFox, IE.
  • П.2 Сайт локализован на русском и английском языках.
  • П.3 Поддерживает размеры экранов: 1920x1080 16:9 HD 1080, 1366x768 HD, 1536x864, 1440x900 8:5 WSXGA, 2560x1440, 1024x768 4:3 XVGA

 

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

Выберем первую пару «Размер экрана» и «Браузер». Исходя из требований о 3-х параметрах, умножаем каждую строку «Размер экрана» на три:

Размер экрана Браузер
1920x1080 16:9 HD 1080 Chrome
1920x1080 16:9 HD 1080 FireFox
1920x1080 16:9 HD 1080 IE
1366x768 HD Chrome
1366x768 HD FireFox
1366x768 HD IE
1536x864 Chrome
1536x864 FireFox
1536x864 IE
1440x900 8:5 WSXGA Chrome
1440x900 8:5 WSXGA FireFox
1440x900 8:5 WSXGA IE
2560x1440 Chrome
2560x1440 FireFox
2560x1440 IE
1024x768 4:3 XVGA Chrome
1024x768 4:3 XVGA FireFox
1024x768 4:3 XVGA IE

Уникально, но не эффективно при появлении параметра локализации. Действуем по алгоритму, составляем пары «Браузер» и «Локализация».

Размер экрана Браузер Локализация
1920x1080 16:9 HD 1080 Chrome RU
1920x1080 16:9 HD 1080 FireFox EN
1920x1080 16:9 HD 1080 IE RU
1366x768 HD Chrome EN
1366x768 HD FireFox RU
1366x768 HD IE EN
1536x864 Chrome RU
1536x864 FireFox EN
1536x864 IE RU
1440x900 8:5 WSXGA Chrome EN
1440x900 8:5 WSXGA FireFox RU
1440x900 8:5 WSXGA IE EN
2560x1440 Chrome RU
2560x1440 FireFox EN
2560x1440 IE RU
1024x768 4:3 XVGA Chrome EN
1024x768 4:3 XVGA FireFox RU
1024x768 4:3 XVGA IE EN

Наблюдаем повление повторов в таблице. Удалим с каждого значения размера экрана по одной строке и сделаем сочетание «Локализация» с «Размер экрана»:

Размер экрана Браузер Локализация
1920x1080 16:9 HD 1080 Chrome RU
1920x1080 16:9 HD 1080 IE EN
1366x768 HD Chrome EN
1366x768 HD IE RU
1536x864 Chrome RU
1536x864 FireFox EN
1440x900 8:5 WSXGA Chrome EN
1440x900 8:5 WSXGA FireFox RU
2560x1440 FireFox EN
2560x1440 IE RU
1024x768 4:3 XVGA FireFox EN
1024x768 4:3 XVGA IE RU

Вопрос: «Почему получились подобные пары, а не другие?». Не стоит терзать себя, пары будут отличаться, вместо "1920x1080 16:9 HD 1080 + Chrome + RU" изначально "1920x1080 16:9 HD 1080 + FireFox + EN".

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

 

Утилиты и инструменты попарного тестирования

Полезное, популярное ПО В интернете для автоматического формирования проверок попарного тестирования:

  • allpairs – консольное приложение для windows, linux.
  • PICT – Pairwise Independent Combinatorial Testing. Разработчик Microsoft.
  • Pairwise online tool  – бесплатное web приложение. Онлайн-генератор для попарного тестирования.
  • VPTag - бесплатный инструмент попарного тестирования
  • ACTS - расширенная комбинаторная система тестирования от NIST

Рекомендуем ознакомиться с инструментом allpairs в статье «Allpairs – утилита для попарного тестирования (pairwise testing, all-pairs testing)».

 

Материалы для скачивания:

 

Заключение

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

Вопрос: «Зачем знать устройство и механику ручного написания при существовании программ, автоматически создающие пары?». Утилиты бездушные и «беспощадные машины», создающие набор проверок, руководствуясь алгоритмом, но не здравым смыслом. Тестировщик выбирает, добавляет, редактирует проверки. В конечном итоге получает минимальное количество тестов с максимальным эффективным тестовым покрытием. Без понимания техники не получится грамотно разложить по полочкам таблицу сценариев.

 

Для комментирования необходимо авторизоваться