Что такое попарное тестирование
Попарное тестирование: суть техники, инструменты и примеры
Что такое попарное тестирование и почему оно является эффективной техникой тест-дизайна? Поговорим об этом ниже. Статья предназначена для начинающих специалистов по тестированию.
В этой статье пойдет речь о комбинаторной технике попарного тестирования (известной также как Pairwise testing или All-pairs testing).
Умное тестирование служит во благо экономии времени. Часто команда тестировщиков вынуждена работать в рамках жестких сроков 90% своего времени. По этой причине техники тест-дизайна должны быть эффективными, чтобы с их помощью можно было достичь максимально возможной степени покрытия тестами и вероятности обнаружения дефектов.
Что такое попарное тестирование?
Попарное тестирование — это техника тест-дизайна, которая обеспечивает полное тестовое покрытие.
ISTQB определяет попарное тестирование как технику тест-дизайна методом черного ящика, при которой тест-кейсы создаются таким образом, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров.
Результат работы приложения зависит от многих факторов, например, входных параметров, переменных состояний и конфигураций среды. Для определения возможных значений могут быть полезны такие техники, как анализ граничных значений и использование классов эквивалентности. Однако тестировать все возможные комбинации значений для всех факторов — непрактично. Поэтому, чтобы удовлетворить все факторы, генерируется подмножество комбинаций.
Техника попарного тестирования очень помогает при разработке тестов для приложений, включающих множество параметров. Тесты разрабатываются таким образом, что для каждой пары входных параметров существуют все возможные комбинации этих параметров. Тестовые наборы (тест-сьюты, Test suite) охватывают все комбинации. Поэтому техника хоть и не обеспечивает исчерпывающее тестирование, но все же является эффективной для поиска ошибок.
Давайте посмотрим, как применять технику попарного тестирования на примере.
Пример применения попарного тестирования
Приложение для заказа автомобиля:
С помощью приложения можно покупать и продавать машины. Приложение должно поддерживать оказание услуг в Дели и Мумбаи.
В приложении должны содержаться регистрационные номера, которые могут быть валидными и невалидным. Оно должно разрешать продажу следующих марок автомобилей: BMW, Audi и Mercedes.
Доступны два типа бронирования: бронирование через интернет и в офлайн-магазине.
Заказы доступны к размещению только в рабочие часы.
Шаг 1. Перечислим задействованные переменные.
Категория заказа
а. Купить
б. Продать
Местоположение
а. Дели
б. Мумбаи
Марка автомобиля
а. BMW
б. Audi
в. Mercedes
Регистрационные номера
а. Валидные (5000)
б. Невалидные
Тип заказа
а. Заказ через Интернет
б. Заказ в магазине
Время заказа
а. Рабочие часы
б. Нерабочие часы
Если тестировать все возможные допустимые комбинации: 2 X 2 X 3 X 5000 X 2 X 2 = получаем 240 тысяч комбинаций 🙁 Кроме того, недопустимых комбинаций вообще может быть бесконечное количество.
Шаг №2: Давайте упростим
Используем умную репрезентативную выборку.
Используем классы эквивалентности и граничные значения, даже если данные — непрерывные.
Сокращаем регистрационные номера до двух типов:
Валидный регистрационный номер
Невалидный регистрационный номер
Теперь посчитаем количество возможных комбинаций: = 2 X 2 X 3 X 2 X 2 X 2 = 96
Шаг 3. Упорядочивание задействованных переменных и значений.
Когда мы классифицируем задействованные переменные и значения, то получим что-то вроде этого:
Теперь отсортируем переменные так, чтобы переменные с наибольшим количеством значений шли первыми, а с наименьшим — последними.
Шаг 4. Расставляем переменные для создания набора тестов.
Давайте начнем заполнять таблицу столбец за столбцом. Изначально таблица выглядит примерно таким образом. Три значения в столбце «Марка авто» (переменная с наибольшим количеством значений) напишем дважды каждое (потому что следующая переменная, «Категория заказа», содержит два значения.
Столбец «Категория заказа» содержит два значения. И именно столько раз нам надо вставить значения первого столбца «Марка авто».
Для каждого набора значений в первом столбце мы помещаем оба значения второго столбца. Повторяем то же самое для третьего столбца.
Теперь у нас есть Покупка&Дели, но нет Покупка&Мумбаи. Есть Продажа&Мумбаи, но нет Продажа&Дели. Давайте поменяем значения из второго набора в третьем столбце.
Так уже выглядит получше.
Повторим шаги для столбцов 3 и 4.
Если сравнить столбцы 3 и 4, каждое значение из столбца 3 имеет пару с обоими значениями из столбца 4. Но если сравнить второй и четвертый столбец, у нас есть комбинации Покупка&Валидный и Продажа&Невалидный, но нет комбинаций Покупка&Невалидный и Продажа&Валидный. Следовательно, нам надо поменять местами последний набор значений в четвертом столбце.
С шестым столбцом (Время заказа) у нас проблемка: не хватает пар Покупка&Нерабочие часы и Продажа&Рабочие часы. Нам не удастся получить недостающие пары, поменяв значения местами, поскольку мы ранее уже поменяли местами все строки, и если мы снова начнём их менять, то есть риск пропустить другие возможные пары. Поэтому добавим еще два тестовых случая, которые содержат эти пары. Заполним пустые строки!
Теперь мы заполним пустые ячейки на свое усмотрение, потому что другие значения переменных являются произвольными (обозначим знаком тильды
Итого мы получили всего 8 тест-кейсов вместо 96.
Мы увидели, насколько эффективной может быть техника попарного тестирования. Она здорово повышает шансы найти баги, при этом сохранив время.
Однако эта техника имеет и некоторые ограничения. Она не сработает, если:
выбранные для тестирования значения некорректны;
мало внимания уделяется комбинациям, которые могут привести к ошибке с высокой долей вероятности;
взаимодействие между переменными недостаточно изучено.
Инструменты попарного тестирования:
Приведем примеры популярных инструментов, которые помогают эффективно автоматизировать процесс дизайна тест-кейсов путем создания компактного набора значений параметров в качестве желаемых тест-кейсов:
PICT – Попарное независимое комбинаторное тестирование от Microsoft Corp.
IBM FoCuS – Единое решение для функционального покрытия от IBM.
ACTS – Расширенная комбинаторная система тестирования от NIST, агентства правительства США.
VPTag – бесплатный инструмент попарного тестирования
Заключение:
Техника попарного тестирования помогает существенно уменьшить количество комбинаций проверок, достаточных для обеспечения необходимого уровня качества программного обеспечения. Это в самом деле умная техника тест-дизайна, которая гарантирует беспроигрышный результат как с точки зрения усилий и задействованных ресурсов, так и с точки зрения эффективности тестирования.
Об этой технике стоит помнить на этапе планирования тестирования. Независимо от того, генерируются ли тестовые случаи вручную или используется какой-либо вспомогательный инструмент, она становится необходимым компонентом тест-плана, потому что влияет на оценку тестирования.
Всех желающих приглашаем на бесплатное demo-занятие «Теория тестирования: виды тестирования». Чтобы быть хорошим специалистом, нужно понимать, какие виды тестирования бывают. На этом занятии мы:
— обсудим, по каким направлениям можно протестировать наш программный продукт;
— узнаем, что скрывается за белыми и черными ящиками;
— а также обсудим, чем отличаются стресс тесты от нагрузочных.
говориМ о тестировании
простым языком
Тест-дизайн. Техника попарного тестирования
Как быть в ситуации, когда необходимо не просто протестировать продукт, а продукт с множеством взаимосвязанных входных данных? Здесь нам на помощь опять приходит тест-дизайн.
Сегодня мы поговорим об еще одной технике составления тестов — техника попарного тестирования (не путать с парным тестированием) или, как ее еще называют, Pairwise testing.
Эта техника используется, когда нам необходимо комбинировать очень много различный вариантов входных данных. Цель ее состоит в том, чтобы сократить количество полученных тестов, но при этом сохранить качественное покрытие.
По традиции приведу определение из ISTQB:
Попарное тестирование (pairwise testing) — разработка тестов методом черного ящика, в которой тестовые сценарии разрабатываются таким образом, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров.
Ее стоит использовать в том случае, когда входные данные связаны друг с другом. Точнее результат выполнения теста напрямую зависит от того, какие комбинации данных будут подаваться на входе.
Рассмотрим очень простой пример. Предположим, у нас есть форма с полями “Логин”, “Пароль” и кнопкой “Войти”.
Каждое поле может принимать два значения: пустое и заполненное. В обычной ситуации, когда результат работы формы не зависит от того, какие именно комбинации полей подаются на вход, нам достаточно провести всего три теста
Т.е. мы в наших тестах проверяем отдельно работу каждого поля, не задумываясь о том, что различные комбинации Логина/Пароля могут сломать систему. Но что, если у нас добавляется еще и зависимость полей? Тогда нам необходимо рассмотреть все возможные комбинации значений между полей. Для нашего примера это означает, что добавится еще один тест.
На первый взгляд выглядит достаточно просто, добавился всего один тест. Но давайте посмотрим на более реальном примере.
Опять же, даже здесь немного упростим проверку и выделим только самые базовые значения.
Таким образом общее количество тестов будет следующим: 2*2*2*2*2*2 = 64
Даже сейчас это большая цифра. Такое тестирование будет малоэффективным и потребует большое количество ресурсов. Вот здесь на помощь приходит техника попарного тестирования, которая позволяет сократить количество тестов во много раз.
Суть ее состоит в том, что мы берем только комбинации пар каждых значений, вместо комбинаций всех значений:
Вручную комбинировать каждую пару нет необходимости. Существуют программы, которые позволяют это сделать автоматически, достаточно только указать параметры и значения. Например, PICT, либо онлайн генераторы https://pairwise.teremokgames.com и т.д.
В нашем случае, после комбинации тестов с помощью попарного тестирования мы сократили количество проверок до 4-х
В каждом тесте мы проверяем сразу несколько пар комбинаций: E-mail — Никнейм, Никнейм — Пароль, Условия — Символы, E-mail — Пароль и т.д.
Подведем итог. Если мы столкнулись с тестированием механики, которая предусматривает различные комбинации входных данных, то в сокращении числа тестов нам как раз и поможет техника попарного тестирования.
И не забывайте пользоваться программами, которые избавят вас от ручного комбинирования.
Меньше, чем пара. Еще один способ сокращения количества тестов
Любому QA известен такой метод минимизации тест-кейсов, как Pairwise Testing — попарное тестирование. Метод отличный, достаточно простой и проверенный множеством команд. Но что делать, если после его применения кейсов остается слишком много?
Именно так произошло в моем проекте, и сегодня я расскажу, как можно еще сильнее сократить количество тест-кейсов, не теряя при этом в качестве.
Тестируемый объект
Для начала расскажу немного о продукте. В Тинькофф наша команда разрабатывала блоки — это React-компоненты, состоящие из реализации и конфигурации. Реализация — это непосредственно сам компонент, который мы разработали и который видит пользователь в браузере. Конфигурация — это JSON, который задает параметры и наполнение этого объекта.
Главная задача блоков — быть красивыми и одинаково отображаться у разных пользователей. При этом от конфигурации и контента блок может очень значительно меняться.
Например, блок может быть таким — без фона, с кнопкой и картинкой справа:
Или вот таким — с фоном, без кнопки и с картинкой слева:
Или вообще вот таким — со ссылкой вместо кнопки и без списка в тексте:
Все примеры выше — это один и тот же блок, который имеет одну версию конфигурации (структура JSON, которую умеет обрабатывать конкретно этот React-компонент), но разное ее наполнение.
Кейсы из сочетания параметров
В этой статье я не буду касаться вопросов версионирования схемы блоков, правил наполнения контентом или того, откуда в блок приходят данные. Все это — отдельные темы, которые никак не влияют на составление набора тест-кейсов. Главное, знать: у нас есть много параметров, влияющих на наш компонент, и каждый из них может принимать свой набор значений.
Для примера выше я выбрала блок с достаточно простой конфигурацией. Но даже в нем проверка всех сочетаний значений всех параметров займет непозволительно много времени, особенно если придется учитывать кроссбраузерность. Обычно здесь на помощь приходит Pairwise Testing, или попарное тестирование. Про него уже написаны тонны статей и есть даже обучения. Если вдруг не сталкивались — обязательно почитайте.
Давайте прикинем, сколько тест-кейсов у нас получится при его применении. Мы имеем больше 25 параметров, и некоторые из них принимают аж 7 и 9 вариантов значений. Да, можно чем-то пренебречь: например, если вы проверяете верстку, guid вам не важен. Но при применении Pairwise Testing все равно получится больше 80 тест-кейсов. И это, как я уже писала, для не самого сложного блока и без учета кроссбраузерности. Блоков у нас сейчас больше 150, и их количество растет, так что позволить себе столько кейсов мы не можем, если хотим сохранить скорость тестирования и выпуска новых версий.
Кейсы из одного параметра
Метод попарного тестирования основан на утверждении о том, что большинство дефектов вызвано взаимодействием не более двух факторов. То есть большинство багов проявляются либо на одном значении какого-то параметра, либо на сочетании значений двух параметров. Мы решили пренебречь второй частью этого утверждения и предположили, что при проверке одного параметра все равно будет найдено большинство багов.
Тогда получается, что для тестирования нам нужно проверить каждое значение каждого параметра хотя бы один раз. Но при этом каждый блок несет в себе всю конфигурацию. Тогда можно в каждом новом кейсе проверять максимум еще не проверенных значений, чтобы минимизировать количество кейсов.
Разберем алгоритм построения кейсов на упрощенном примере. Возьмем из нашей схемы компонент button и составим для него тест-кейсы:
Шаг 1. Составляем варианты контента для каждого поля
Здесь, на мой взгляд, важно очень четко определить границы и функциональность своей системы и не проверять лишнее. То есть если проверка на обязательность ключей или валидация значения реализованы в сторонней системе, то и проверять эту функциональность нужно в сторонней системе. А мы должны в качестве кейсов использовать только «правильные» данные.
По большому счету этот же принцип используется в пирамиде тестирования. При желании самые критичные интеграционные тесты можно добавить к нам — например, проверять обработку не пришедшего ключа. Но таких тестов должно быть минимальное количество. Иной подход — стремление к исчерпывающему тестированию, которое, как всем известно, невозможно.
Итак, мы определили варианты контента для каждого поля и составили такую таблицу:
В эту таблицу входит каждый класс эквивалентности каждого параметра, но только один раз.
Вот такие классы значений в нашем случае классы:
Шаг 2. Обогащаем таблицу данными
Поскольку каждый блок несет в себе полную конфигурацию, нам нужно добавить какие-нибудь релевантные данные в пустые ячейки:
Теперь каждый столбец — это один кейс.
При этом, поскольку недостающие данные мы выбираем сами, мы можем генерировать кейсы исходя из приоритета. Например, если мы знаем, что в кнопке короткий текст используется чаще, чем текст средней длины, то и проверять его стоит чаще.
В примере выше также можно обратить внимание на «выпавшие» кейсы — кейсы, в которых какой-то параметр вообще не проверяется, хотя и присутствует в таблице. В данном случае button.color.style: secondary не будет проверен на внешний вид, потому что неважно, какой стиль у отключенной кнопки.
Чтобы «выпавшие» кейсы не привели к багам, раньше мы анализировали полученные наборы значений. Анализ происходил один раз при генерации тестовых наборов, и все «выпавшие» кейсы добавлялись вручную в итоговый тестовый набор. Такое решение проблемы достаточно топорное, но дешевое (если, конечно, у вас редко меняются конфигурации тестируемых объектов).
Более универсальное решение — разделить все значения на две группы:
Шаг 3. Уточняем значения
Теперь осталось только сгенерировать конкретные значения вместо классов эквивалентности.
Здесь каждому проекту придется подобрать свои варианты значений, опираясь на особенности тестируемого объекта. Некоторые значения генерировать очень просто. Например, цвет для большинства полей можно просто брать любой. Для некоторых блоков при проверке цвета приходится добавлять градиент, но он вынесен в отдельный класс эквивалентности.
С текстом чуть сложнее: если сгенерировать строку из случайных символов, то не будут протестированы переносы, списки, теги, неразрывные пробелы. Мы генерируем короткие и средней длины строки из реального текста, обрезая его до нужного количества символов. А в длинном тексте проверяем:
Получается, что для каждого проекта нужно составить свой актуальный набор контента исходя из реализации тестируемого объекта.
Алгоритм
Конечно, на первый взгляд может показаться, что алгоритм сложный и не стоит потраченных усилий. Но если опустить все детали и исключения, которые я постаралась описать в каждом пункте выше, получается достаточно просто.
Шаг 1. Добавляем в таблицу параметров все возможные значения:
Шаг 2. Дублируем значения в пустые ячейки:
Шаг 3. Превращаем абстрактные значения в конкретные и получаем кейсы:
Каждый столбец таблицы — это один кейс.
Преимущества подхода
Такой способ генерации тест-кейсов имеет несколько важных преимуществ.
Меньше кейсов
Первое и очевидное — кейсов значительно меньше, чем в попарном тестировании. Если брать упрощенный пример с кнопкой — у нас получилось 4 кейса вместо 8 в попарном тестировании.
Чем больше параметров в тестируемом объекте, тем значительнее будет экономия кейсов. Например, для полного блока, представленного в начале статьи, у нас получается 11 кейсов, а с помощью попарного — 260.
Не раздувается количество кейсов при усложнении функциональности
Второй плюс — при появлении новых параметров, учитывающихся при тестировании, количество кейсов увеличивается далеко не всегда.
Количество кейсов увеличится только в том случае, если у какого-то параметра станет больше значений, чем было кейсов.
Можно чаще проверять важное
За счет обогащения значениями (шаг 2 в алгоритме) можно чаще проверять более приоритетные или более рискованные значения.
Например, если мы знаем, что раньше пользователи чаще использовали короткий текст, а теперь — более длинный, мы можем обогащать кейсы более длинным текстом и чаще попадать в реальные пользовательские кейсы.
Можно автоматизировать
Алгоритм, приведенный выше, вполне поддается автоматизации. Конечно, сгенерированные алгоритмом кейсы будут меньше походить на реальные, чем сгенерированные человеком. Хотя бы за счет подбора цветов и обрезания текста.
Но зато уже в процессе разработки без участия тестировщика появляются кейсы, что очень сильно сокращает петлю обратной связи.
Недостатки
Естественно, такая генерация кейсов — далеко не серебряная пуля и имеет свои недостатки.
Сложно анализировать результат
Думаю, вы обратили внимание, что в процессе генерации кейсов происходит смешивание тестовых данных друг с другом. Из-за этого при падении кейса усложняется процесс выявления причины падения. Ведь часть параметров, задействованных в кейсе, никак не влияет на результат теста.
Это правда затрудняет разбор результатов тестов, с одной стороны. Но, с другой стороны, если тестируемый объект требует большой объем обязательных параметров, это тоже затрудняет нахождение причины бага.
Могут быть пропущены баги
Возвращаясь к самому началу статьи: при применении этого метода мы допускаем возможность пропуска багов, вызванных сочетанием двух и более параметров. Зато выигрываем в скорости, так что только вам решать, что важнее на каждом конкретном проекте.
Чтобы не пропускать баги дважды, мы ввели Zero Bug Policy и стали закрывать каждый пропущенный баг дополнительным тест-кейсом — уже не автоматически сгенерированным, а написанным вручную. Это дало отличные результаты: сейчас у нас более 150 блоков (тестируемых объектов), несколько релизов в день и от 0 до 3 пропущенных некритичных багов в месяц.
Выводы
Если в вашем тестируемом объекте широкий набор входных параметров и вы хотите попробовать сократить количество кейсов и, как следствие, время на тестирование, я рекомендую попробовать приведенный выше метод генерации кейсов через один параметр.
На мой взгляд, для фронтовых компонентов он подходит идеально: можно более чем в три раза сократить время, например, на проверку внешнего вида через скриншот-тестирование. Да и разработка пойдет быстрее за счет появления кейсов на самых ранних этапах.
Конечно, если вы тестируете автопилот новой «Теслы» — нельзя пренебрегать даже малой вероятностью пропуска бага. Но в большинстве случаев не стоит забывать, что скорость в современном мире — это весьма важный критерий качества. А прирост скорости дает больше положительного результата, чем пара найденных минорных проблем.
А для самых ответственных в следующей статье я расскажу, как можно дополнительно предохраниться от хитрых багов, вызванных сочетанием параметров, при помощи пользовательских кейсов и StoryBook.
Что такое попарное тестирование
Что пишут в блогах
2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Онлайн-тренинги
Что пишут в блогах (EN)
Software Testing
Разделы портала
Про инструменты
Если в качестве инструмента у вас имеется лишь молоток, каждая проблема начинает напоминать гвоздь. Абрахам Маслоу
В этой небольшой заметке я бы хотел рассмотреть инструмент для попарного тестирования от Microsoft – PICT (Pairwise Independent Combinatorial Testing). Уже несколько раз я применял его в своей работе и был доволен теми гибкими опциями, которые он имеет.
Для начала неплохо вспомнить, что такое Pairwise Testing. Есть интересная статья про парное тестирование на MSDN. Также про это можно почитать тут. Вкратце, Pairwise testing – это техника формирования наборов тестовых данных. Заключается она в следующем: формируются такие наборы данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров. Предыдущее предложение может быть не совсем понятным, но принцип можно легко проиллюстрировать на следующем примере. Представим, что у нас есть параметры A, B и C принимающие значения Yes или No. Максимальное количество комбинаций значений этих параметров – 8. Но при использовании попарного тестирования достаточно четырех комбинаций, так как учитываются все возможные пары параметров (пара A и B, пара B и C, пара A и C):
Эту технику полезно применять тогда, когда нам не нужны все возможные сочетания значений параметров (особенно когда параметров много), а мы хотим только убедиться, что мы проверим все уникальные пары значений параметров.
Так что же PICT? PICT позволяет генерировать компактный набор значений тестовых параметров, который представляет собой все тестовые сценарии для всестороннего комбинаторного покрытия ваших параметров. К примеру представим, что у нас есть следующие параметры для тестирования (параметры относятся к тестированию создания разделов на жестком диске и взят из мануала к PICT):
Существует больше 4700 комбинаций этих значений. Будет очень сложно протестировать из за разумное время. Исследования показывают, что тестирование всех пар возможных значений обеспечивает очень хорошее покрытие и количество тест кейсов остается в пределах разумного. К примеру, это одна пара и другая; один тест кейс может покрывать много пар. Для набора приведенных выше параметров PICT создаст всего 60 тест кейсов (сравните с цифрой 4700!).
Рассмотрим работу с программой. Запускается PICT из командной строки.
На вход программа принимает простой текстовый файл с параметрами и их значениями, называемый Моделью, а на выход выдает сгенерированные тестовые сценарии.
Рассмотрим работу программы на примере из приведенной выше статьи из блога. Имеем следующие параметры и их значения: пол – мужской или женский; возраст – до 25, от 25 до 60, более 60; наличие детей – да или нет. Если перебирать все возможные значения, то количество сценариев будет 12. Составим модель и посмотрим какой результат нам выдаст программа.
Используем модель и получим 7 тестовых сценариев (вместо 12):
Разница не такая ощутимая, но она будет становится все более и более заметной при увеличении количества параметров или их значений.
Можно использовать прямой вывод и сохранение тест кейсов в Excel.
В результате будет создан Excel файл со следующим содержанием:
Но самое интересное это те возможности, которые предоставляет PICT для подобной генерации сценариев. Все они тщательно рассмотрены в мануале. Вот некоторые из них: