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

В тестировании программ очень часто встаёт задача проверки комбинаций входных параметров, от которых зависит итоговый результат программы. Типичный пример - диалоговое окно печати файла: оно имеет множество настроек, полей ввода, различных взаимозависимых опций, от включения или выключения которых итоговый результат может сильно различаться. Если бы даже все опции имели только два режима работы (вкл/выкл), а всего опций было бы 10, то это уже даёт 2 10 = 1024 их комбинаций.

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

После стандартной установки библиотеки AllPairs можно скопировать к себе в проект каталог \Lib\site-packages\metacomm\ для упрощения импортов и переноса проекта на другие компьютеры.

Рассмотрим ещё одну задачу из области тестирования. Пусть требуется проверить работоспособность веб-сайта в различных конфигурациях браузеров, операционных системах и на платформах с различной разрядностью. Например, заданы четыре конкретные операционные системы: Windows XP SP 3, Windows 7 SP 1, Debian 7.1, Ubuntu 12.04, для двух разрядностей: x86, x64, и три браузера: chrome, firefox, safari.

При этом получаем: 4 x 2 x 3 = 24 конфигурации для тестовых наборов, которые требуется проверить в общем случае. Можно уменьшить число тестовых наборов при помощи AllPairs.

Входные данные для модуля AllPairs могут быть заданы как список списков из строк, значения которых однозначно характеризуют параметры для тестовых наборов. Для нашей задачи это могут быть просто названия параметров для конфигураций:
список возможных ОС: Windows XP SP 3, Windows 7 SP 1, Debian 7.1, Ubuntu 12.04,
список разрядностей: x86, x64,
список браузеров: chrome, firefox, safari.

Задание входных параметров в Python-коде и использование AllPairs для построения их комбинаций может выглядеть как в спойлере ниже (предполагается, что каталог ext, содержащий пакет metacomm, уже лежит рядом со скриптом allpairs.py).

Код скрипта allpairs.py:

# -*- coding: utf-8 -*- # # (c) Gilmullin Timur Mansurovich, 2013. # Using AllPairs by MetaCommunications Engineering example. from ext.metacomm.combinatorics import all_pairs2 as ap def Generator(parameters): """ Use generator which work on AllPairs-algorithm. Input: parameters - list of list of different parameters, that looks like this: [ , , ... ] Output: list of enumerate possible unique combinations, that looks like this: [ (0, ), ... (N, ), ...] """ combinations = list(enumerate(ap.all_pairs2(parameters))) return combinations if __name__ == "__main__": # define list of list of different parameters: inputData = [ ["Windows XP SP 3", "Windows 7 SP 1", "Debian 7.1", "Ubuntu 12.04"], ["x86", "x64"], ["chrome", "firefox", "safari"] ] # get combinations and output it: outputData = Generator(inputData) with open("output.txt", "w") as fH: for line in outputData: stringData = "Combination {}:\t{}".format(str(line), str(line)) print(stringData) fH.write(stringData + "\n")

В скрипте каждая новая строка переменной inputData содержит список допустимых значений для отдельного параметра в тестируемых конфигурациях. После определения таким образом входных данных, нужно просто выполнить скрипт командой:
python allpairs.py

На выходе будет получен пронумерованный список строк вида:
Combination 0: ["Windows XP SP 3", "x86", "chrome"] ...
Как видим, комбинаций всего 12 - в два раза меньше, чем их полное число в общем случае. А если применить этот же алгоритм для примера в начале статьи, то вместо 1024 полных комбинаций, получим всего 8!

Затем полученные комбинации можно интерпретировать как тестовые случаи, например:
"Выполнить проверку работоспособности веб-сайта для конфигурации:
- ОС: Windows XP SP 3,
- разрядность системы: x86,
- браузер: chrome."

Скачать код скрипта allpairs.py для данной задачи можно по ссылке:
https://drive.google.com/file/d/0B-1rf8K04ZS5ZHJpdXRRd24zc0E/edit?usp=sharing
код на GitHub:
https://github.com/Tim55667757/AllPairs_example

Приложенный архив включает в себя каталог metacomm с библиотекой AllPairs, модуль allpairs.py с примером решения приведённой выше задачи и вывод результатов в файле output.txt .

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

Хотя популярность buzzword «pairwise» уже не та, на собеседованиях до сих пор задают вопрос о том, что представляет собой эта техника тест-дизайна. Однако, далеко не все тестировщики (как те, кто приходят на собеседование, так и те, кто его проводят) могут четко сформулировать ответ на вопрос, зачем нужны комбинаторные техники в общем и pairwise в частности (подавляющее большинство ошибок, все же, находятся на атомарных значениях параметров и не зависят от других). Простой ответ на этот вопрос, на мой взгляд - для нахождения багов, возникающих вследствие явных и неявных зависимостей между параметрами. Для простых случаев техника вряд ли принесет серьезную пользу, поскольку их можно проверить вручную, а для большого числа параметров и сложных зависимостей между ними количество тестов, скорее всего, будет слишком велико для ручного тестирования. Потому основное применение комбинаторных техник (и соответственно, инструментов, осуществляющих генерацию комбинаций параметров) - автоматизированное составление наборов тестовых данных по определенным законам.

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

Пример 1. Серия и номер паспорта

При условии использования автоматизированного тестирования для серии и номера паспорта можно составить исчерпывающий набор позитивных тестов, поскольку требования к этому полю строги - ровно две заглавных буквы украинского алфавита (кроме Ґ, Ї, Ь) и шесть цифр от 0 до 9. Всего таких тестов будет (33-3) 2 *10 6 = 9*10 8 . Однако, редко встречаются случаи, когда требования к полю настолько строгие, да и вряд ли нужно проводить исчерпывающее тестирование. Скорее всего, достаточно проверить возможность ввода каждой отдельной буквы и каждой отдельной цифры на каждой позиции соответственно. Задачу составления таких тестов вполне может решить инструмент комбинаторного тестирования:
SERIES_1: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я SERIES_2: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я NUMBER_1: 0,1,2,3,4,5,6,7,8,9 NUMBER_2: 0,1,2,3,4,5,6,7,8,9 NUMBER_3: 0,1,2,3,4,5,6,7,8,9 NUMBER_4: 0,1,2,3,4,5,6,7,8,9 NUMBER_5: 0,1,2,3,4,5,6,7,8,9 NUMBER_6: 0,1,2,3,4,5,6,7,8,9 {SERIES_1, SERIES_2, NUMBER_1, NUMBER_2, NUMBER_3, NUMBER_4, NUMBER_5, NUMBER_6} @ 1 Модель 1
Щ З 4 6 3 1 1 5 І Є 8 3 8 9 9 3 А Н 3 0 5 8 6 2 М С 4 3 4 1 3 1 Є Я 4 6 7 3 1 4 Г Ц 0 2 4 5 2 0

Аналогично можно составить негативные тесты (PICT позволяет пометить их специальным символом "~").
SERIES_1: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я SERIES_2: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я NUMBER_1: 0,1,2,3,4,5,6,7,8,9,~A,~B,~C,~D,~E,~F NUMBER_2: 0,1,2,3,4,5,6,7,8,9,~A,~B,~C,~D,~E,~F NUMBER_3: 0,1,2,3,4,5,6,7,8,9,~A,~B,~C,~D,~E,~F NUMBER_4: 0,1,2,3,4,5,6,7,8,9,~A,~B,~C,~D,~E,~F NUMBER_5: 0,1,2,3,4,5,6,7,8,9,~A,~B,~C,~D,~E,~F NUMBER_6: 0,1,2,3,4,5,6,7,8,9,~A,~B,~C,~D,~E,~F Модель 2
З У 1 3 7 2 7 4 Л Ю ~B 7 3 2 7 9 А Є 8 8 2 0 ~A 8 Часть результатов моделирования

Пример 2. Увеличение тестового покрытия с помощью дополнительного параметра

Иногда баги, связанные с валидациями, зависят от того, каким образом пользователь вводит невалидные данные: с клавиатуры (физической или экранной), с помощью контекстного меню копирования-вставки, горячих клавиш, перетаскивания выделенного текста. Например, часто перетаскивание текста не обрабатывается клиентской валидацией, если таким образом вводятся некорректные данные. Способ ввода можно ввести в модель в качестве дополнительного параметра и учесть его при составлении автотестов.
SERIES_1: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я SERIES_2: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я NUMBER_1: 0,1,2,3,4,5,6,7,8,9 NUMBER_2: 0,1,2,3,4,5,6,7,8,9 NUMBER_3: 0,1,2,3,4,5,6,7,8,9 NUMBER_4: 0,1,2,3,4,5,6,7,8,9 NUMBER_5: 0,1,2,3,4,5,6,7,8,9 NUMBER_6: 0,1,2,3,4,5,6,7,8,9 INPUT: keyboard, screen keys, context menu, copy paste, drag-n-drop Модель 3
М Л 0 8 0 8 5 9 keyboard Ю У 0 0 2 3 2 2 drag-n-drop С Ч 5 3 6 2 1 0 screen keys Я Д 3 9 4 1 6 7 context menu У Ш 9 9 0 7 4 4 copy paste Часть результатов моделирования

Пример 3. Тесты для систем принятия решений, валидация требований

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

Валидация требований - очень немаловажная часть тестирования в данном случае, поскольку можно обнаружить скрытые противоречия. Инструмент генерации комбинаторных тестов позволит не только составить тесты, но и задать условия, накладываемые на входные данные. Если эти условия делают какие-то из возможных данных недостижимыми, инструмент укажет на это, что может послужить сигналом тщательной проверки требований на непротиворечивость.
AGE: 0-17, 18-21, 22-65, >=66 CHILDREN: Y, N SMOKING: Y, N WORK: 0-5, 6-10, >=11 {AGE, CHILDREN, SMOKING, WORK} @ 4 IF = "0-17" THEN <> ">=11"; IF =">=11" THEN = "0-17"; Модель 4
Constraints Warning: Restrictive constraints. Output will not contain following values WORK: >=11 Реакция инструмента на противоречивые требования

В данной модели есть противоречивые требования, которые отсекают значение WORK: >=11, и оно не появляется ни в одном из тестов. К сожалению, инструмент не дает ответа на вопрос, какие именно условия вызывают противоречие, только показывает, какое значение исключено из тестов. Однако, этой информации может быть достаточно, чтобы выделить из всего массива ограничений те, что влияют на этот параметр, и проанализировать их на предмет противоречивости.

Исчерпывающий набор тестов в дальнейшем может быть использован для техники тест-дизайна «причина-следствие».

Пример 4. Формирование параметров окружений для конфигурационного тестирования

Инструменты для комбинаторного тестирования позволяют также составлять список возможных конфигураций, который потом можно отсортировать по популярности использования, вычеркнуть неподходящие и т.д. Если не обязательно проводить все тесты для каждой из конфигураций, можно поделить их равномерно между выбранными окружениями, добавив окружение в качестве еще одного параметра для генерации тестовых данных (так, как это делалось в примере со способом ввода данных).
BROWSER: IE, Firefox, Chrome, Opera LANG: en, ru, ua OS: win, linux, android {BROWSER, LANG, OS} @ 1 IF = "linux" THEN <> "IE"; Модель 5
IE ua win Firefox en win Opera ua linux Chrome ru android Результаты моделирования

SERIES_1: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я SERIES_2: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я NUMBER_1: 0,1,2,3,4,5,6,7,8,9 NUMBER_2: 0,1,2,3,4,5,6,7,8,9 NUMBER_3: 0,1,2,3,4,5,6,7,8,9 NUMBER_4: 0,1,2,3,4,5,6,7,8,9 NUMBER_5: 0,1,2,3,4,5,6,7,8,9 NUMBER_6: 0,1,2,3,4,5,6,7,8,9 ENVIRONMENT: IE ua win, Firefox en win, Opera ua linux, Chrome ru android Модель 6

Пример 5. Составление нескольких тестов с учетом большого количества ограничений

Безусловно, комбинаторное тестирование можно применять и для генерации тестов, которые выполняются вручную, но как мне кажется, это стоит делать, только если есть очень большое количество ограничений, которые трудно удержать в голове. Из-за наличия условий количество тестов может быть ограничено, так сказать, естественным образом, и инструмент позволит получить все возможные тестовые данные, подходящие под все накладываемые на них условия. При этом тесты можно выполнить и вручную.
AGE: 0-17, 18-21, 22-65, >=66 CHILDREN: 0, 1, 2, 3, 4, 5 SMOKING: Y, N WORK: 0-5, 6-10, >=11 IF = "0-17" THEN <> ">=11"; IF = "0-17" THEN = 0; IF = "18-21" THEN < 2; IF > 0 THEN = "N"; IF = ">=66" THEN <> "0-5"; IF = "0-17" OR = "18-21" THEN = "0-5"; Модель 6
22-65 2 N 0-5 18-21 1 N 0-5 >=66 2 N 6-10 22-65 4 N 6-10 22-65 5 N 6-10 22-65 3 N 6-10 >=66 4 N >=11 22-65 5 N >=11 0-17 0 Y 0-5 >=66 3 N >=11 22-65 4 N 0-5 22-65 2 N >=11 18-21 0 Y 0-5 22-65 0 Y >=11 22-65 1 N 6-10 22-65 3 N 0-5 >=66 1 N >=11 0-17 0 N 0-5 >=66 0 Y 6-10 >=66 5 N >=11 22-65 5 N 0-5 Результаты моделирования - 21 тест

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

Что такое «качественный программный продукт»? Это продукт, который выполняет поставленные перед ним задачи и удовлетворяет ожидания пользователей. Для достижения этого результата любая программа сначала проходит тестирование и только потом попадает в руки конечного потребителя. Так как сроки тестирования (как и любого процесса) имеют тенденцию стремиться к бесконечности, нам необходимо грамотное выстраивание процесса. И тут уже никак не обойтись без тест-дизайна.

Тест-дизайнер — что это за зверь и с чем его едят?

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

6. Доменный анализ (Domain Analysis Testing).
Это техника основана на разбиении диапазона возможных значений переменной (или переменных) на поддиапазоны (или домены), с последующим выбором одного или нескольких значений из каждого домена для тестирования. Во многом доменное тестирование пересекается с известными нам техниками разбиения на классы эквивалентности и анализа граничных значений. Но доменное тестирование не ограничивается перечисленными техниками. Оно включает в себя как анализ зависимостей между переменными, так и поиск тех значений переменных, которые несут в себе большой риск (не только на границах).

7. Сценарий использования (Use Case Testing).
Use Case описывает сценарий взаимодействия двух и более участников (как правило – пользователя и системы). Пользователем может выступать как человек, так и другая система. Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев (тест-кейсов), так как они описывают, в каком контексте должно производиться каждое действие пользователя. Use Case, по умолчанию, являются тестируемыми требованиями, так как в них всегда указана цель, которой нужно достигнуть, и шаги, которые надо для этого воспроизвести.

Что тут думать, трясти надо!

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

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

Действительно: какой смысл, допустим, от полного тестового покрытия формы авторизации, если при этом не будет корректно работать механизм оплаты за товар в интернет-магазине? Ведь за то время, пока тестировщик 100 тестами проверит 100 значений, тест-дизайнер придумает, как за 10 тестов проверить 1000 значений! Таким образом, усилия, затраченные на тест-дизайн, с лихвой окупятся качеством выполнения тестирования.

Pairwise testing (попарное тестирование) – это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.

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

Главные цели Pairwise Testing:

убрать избыточные проверки;
обеспечить хорошее тестовое покрытие;
выявить наибольшее количество багов на минимальном наборе тестов.

Рассмотрим более детально суть попарного тестирования на примерах.

Пример 1

Представим, что у нас есть параметры A, B и C принимающие значения Yes или No. Максимальное количество комбинаций значений этих параметров – 8. Но при использовании попарного тестирования достаточно четырех комбинаций, так как учитываются все возможные пары параметров (пара A и B, пара B и C, пара A и C):

Пример 2

Допустим, какое-то значение (например, налог) для человека рассчитывается на основании его пола, возраста и наличия детей – получаем три входных параметра, для каждого из которых для тестов выбираем любое из возможных значений. Например: пол – мужской или женский; возраст – до 25, от 25 до 60, более 60; наличие детей – да или нет. Для проверки правильности расчетов можно, конечно, перебрать все комбинации значений всех параметров:

№	Пол	Возраст	Дети
1	мужчина	до 25	детей нет
2	женщина	до 25	детей нет
3	мужчина	25-60	детей нет
4	женщина	25-60	детей нет
5	мужчина	старше 60	детей нет
6	женщина	старше 60	детей нет
7	мужчина	до 25	дети есть
8	женщина	до 25	дети есть
9	мужчина	25-60	дети есть
10	женщина	25-60	дети есть
11	мужчина	старше 60	дети есть
12	женщина	старше 60	дети есть

А можно решить, что не нужно проверять сочетания значений всех параметров со всеми, а только убедиться, что проверятся все уникальные пары значений параметров. Например, с точки зрения параметров пола и возраста нужно убедиться, что точно проверим мужчину до 25, мужчину между 25 и 60, мужчину после 60, а также женщину до 25, женщину между 25 и 60, также женщину после 60. И точно так же для всех остальных пар параметров. И таким образом, можем получить гораздо меньше наборов значений (в них есть все пары значений, правда некоторые дважды):

№	Пол	Возраст	Дети
1	мужчина	до 25	детей нет
2	женщина	до 25	дети есть
3	мужчина	25-60	дети есть
4	женщина	25-60	детей нет
5	мужчина	старше 60	детей нет
6	женщина	старше 60	дети есть

Пример 3

Есть два браузера Opera и Firefox. Есть две операционные системы Windows и Linux. Тут ничего не уменьшить, так как из них можно сложить 4 конфигурации:

№	Browser	OS
1	Opera	Windows
2	Firefox	Linux
3	Opera	Linux
4	Firefox	Windows

Допустим, сайт на двух языках: русский (RU) и английский (EN). Для полного эксперимента, умножим те 4 конфигурации на 2, т.е. каждую из предыдущих конфигураций проверить с обоими языками. Но зачем? Вместо этого воспользуемся попарным подходом и вместо 8 конфигураций получим опять 4:

№	Browser	OS	Language
1	Opera	Windows	RU
2	Firefox	Linux	RU
3	Opera	Linux	EN
4	Firefox	Windows	EN

Далее, сайт может использовать MySQL, Oracle и MSSQL как базу данных. Просто используя попарное тестирование получаем 7 конфигураций (а не 12 – предыдущие 4х3, и тем более не 24=2х2х2х3). Но тут опять стоит задуматься, а важно ли проверять каждую базу в сочетании с другими параметрами. Очевидно – нет. Важно посмотреть, например, как каждая база работает с каждым языком. Таким образом, введя ограничения, вместо 7 получим 6 конфигураций (3 базы х 2 языка):

№	Browser	OS	Language	Database
1	Opera	Windows	RU	MySQL
2	Firefox	Linux	EN	MySQL
3	Opera	Linux	EN	MSSQL
4	Firefox	Windows	RU	MSSQL
5	Opera	Linux	RU	Oracle
6	Firefox	Windows	EN	Oracle

Пример 4
Главный принцип попарного тестирования в том, что в подавляющем большинстве случаев не надо проводить полнофакторный эксперимент (т.е. перебирать все конфигурации, где все значения всех параметров встречаются друг с другом). Да и невозможно это зачастую из-за нехватки ресурсов. Поэтому декларируется, что достаточно проверить как работает ПО, когда каждое значение каждого параметра встретилось с другим значением каждого другого параметра хотя бы раз.
Допустим, необходимо протестировать комбинации настроек параметров окна «Font» в текстовом процессоре:

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

Parameter	Value 1	Value 2	Value 3	Value 4
Font	TT	Arial
Style	Regular	Italic	Bold	Bold Italic
Size	min	normal	max
Color	black	white	red
Underline style	none	words only	other
Strikethrough	on	off
Double Strikethrough	on	off
Superscript	on	off
Subscript	on	off
Shadow	on	off
Outline	on	off
Emboss	on	off
Engrave	on	off
Small caps	on	off
All caps	on	off
Hidden	on	off

2 * 4 * 3 * 3 * 3 * 2^11 = 442 368.

Таким образом, метод «Всех пар» позволяет существенно сократить количество проверок.

2. Инструменты

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

В данном материале будет рассмотрен инструмент PICT (Pairwise Independent Combinatorial Testing – инструмент для попарного тестирования от Microsoft).

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

Рассмотрим работу с программой. Запускается PICT из командной строки.

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

Рассмотрим работу программы на примере 2, который был приведен выше. Имеем следующие параметры и их значения: пол – мужской или женский; возраст – до 25, от 25 до 60, более 60; наличие детей – да или нет. Если перебирать все возможные значения, то количество сценариев будет 12. Составим модель и посмотрим какой результат выдаст программа.

Модель:

Используем модель в PICT и получим 6 тестовых сценариев (вместо 12):

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

Представим, что у нас есть следующие параметры для тестирования, которые относятся к тестированию создания разделов на жестком диске (пример взят из мануала к PICT):

7 * 7 * 2 * 3 * 8 * 2 = 4704

Будет очень сложно протестировать их за разумное время. Исследования показывают, что тестирование всех пар возможных значений обеспечивает очень хорошее покрытие и количество тест-кейсов остается в пределах разумного. К примеру, {Primary, FAT} это одна пара и {10, slow} другая; один тест-кейс может покрывать много пар. Для набора приведенных выше параметров PICT создаст всего 60 тест-кейсов:

Также, вместо обычного вывода в консоль, можно использовать прямой вывод и сохранение тест-кейсов в MS Excel:

В результате будет создан Excel файл со следующим содержанием:

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

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

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

3. Где и когда применяется Pairwise тестирование?

Метод эффективен лишь на поздних этапах разработки, либо дополненный основными функциональными тестами. Например, если проводить конфигурационное тестирование, то прежде чем использовать попарное тестирование следует убедиться, что основной сценарий функционирует на всех операционных системах с параметрами по умолчанию (провести Smoke testing (Дымовое тестирование ) или Build Verification Test (Тестирование сборки )). Это значительно облегчит локализацию будущих багов, ведь при попарном тестировании в одном тесте фигурирует множество параметров со значениями не по умолчанию, каждый из которых может стать причиной сбоя и его локализация в этом случае весьма затруднительна. А в случае провала тестирования сборки следует отказаться от использования метода попарного тестирования, так как многие тесты будут провальными, а исключение даже одного теста влечет за собой потерю, как правило, нескольких пар, и смысл использования метода теряется.

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

Таким образом, Pairwise Testing – специальный метод оптимизации составления тест-кейсов.

Основная суть техники Pairwise Testing – не проверить все сочетания всех значений, но проверить все пары значений.