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

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

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

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

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

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

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

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

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

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

Хотя популярность 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 тест

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 для подобной генерации сценариев. Все они тщательно рассмотрены в руководстве пользователя. Вот некоторые из них:

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

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

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

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

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

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

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

Не так давно (век живи - век учись) я наткнулась на понятие "pairwise testing" (переведу в лоб как "попарное тестирование", но лучше буду использовать английский термин), заинтересовалась и решила разобраться, что это такое. Достаточно быстро поняв, как работает данная э… техника, у меня сразу возникли вопросы по поводу причин и смысла её использования, найти ответы на которые на днях у меня наконец дошли руки. Обо всём этом я и решила написать (длинно, но короче не вышло:().

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

1. Что же это такое

Раз уж я взялась писать о pairwise testing, то, видимо, надо попытаться объяснять, в чём состоит суть данной техники. Не уверена, что у меня получится объяснить понятно и корректно, но я всё-таки попробую:)

Итак, pairwise testing - это техника формирования наборов тестовых данных. Сформулировать суть можно, например, вот так: формирование таких наборов данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров. Выходит не слишком понятно (и не факт, что правильно), так что можно попробовать объяснять на примере:)

Допустим, какое-то значений (налог) для человека рассчитывается на основании его пола, возраста и наличия детей - получаем три входных параметра, для каждого из которых для тестов выбираем каким-то образом значения. Например: пол - мужской или женский; возраст - до 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	дети есть

Такой подход примерно и составляет суть техники pairwise testing - мы не проверяем все сочетания всех значений, но проверяем все пары значений.

2. Что в этом хорошего

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

Наверное, по приведённому выше примеру может показаться, что разница между этой техникой и перебором всех значений не так и велика. Но это только при таком незначительном количестве параметров и их значений, а чем их больше - тем значительнее разница. Допустим, если есть 50 параметров, каждый из которых может принимать 2 значения, то для полного перебора потребуется количество комбинаций равное 2 в степени 50, т.е. 1 125 899 906 842 624:) А при использовании pairwise testing можно обойтись всего четырнадцатью комбинациями!

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

3. Почему пары

Лично у меня при знакомстве с этой техникой сразу возник вопрос - а почему именно пары? Почему не тройки значений или не какое-либо "квартетное тестирование"? Есть ли у такого подхода, например, какое-либо математическое обоснование, либо это с потолка взято?

Мне удалось найти вот такое объяснение: когда-то, на основании кем-то выполненного анализа по каким-то реальным данным был сделан вывод о том, что причиной возникновения большинства ошибок являются либо отдельные значения, либо сочетания пар значений (источник ). Это соображение судя по всему и легло в основу развития pairwise testing.

В принципе, обоснование более ли менее разумное, ведь какие-то исследования были проведены. Однако из такого объяснения также понятно, что правило это не однозначно верное и что справедливо оно будет далеко не для всех случаев. К тому же стоит задуматься и о понятии "большинство ошибок" :)

4. Как же и когда это (не) применять

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

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

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

Итак, если параметры задачи взаимодействуют, то, казалось бы, тут pairwise testing и станет тем чудесным решением, которое и силы сэкономит, и полное тестирование обеспечит. Но конечно, эта техника обеспечивает достаточно высокое покрытие, но далеко не полное - если вдруг ошибка возникает при сочетании трёх, четырёх или более параметров, то pairwise testing может и не помочь (это уж как повезёт). По-хорошему, применению pairwise testing должен предшествовать анализ тестируемого приложения на предмет того, насколько тестирование именно сочетаний пар параметров является для него целесообразным.

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

5. Так что же я хотела сказать

Конечно, я назвала только пару-тройку, но есть большое количество соображений, которые стоит принять во внимание, принимая решение о применении техники pairwise testing - стоит хотя бы обратиться к упомянутым выше статьям (их вообще стоит почитать при наличии интереса к данной теме). А pairwise testing - это просто инструмент, который, как и прочие инструменты, требует использования с умом.