Home

Автор: Никонов Владислав

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

Так вот, сценарии использования и альтернативные сценарии, мы обычно получаем от аналитиков из спецификации.. таблицы, деревья и диаграммы мало кто чертит, так как это занимает много времени (при дефиците ресурсов). Как правило, в ходу две популярные техники: классы эквивалентности и граничные значения, и только отдельные умнички используют pairwise ( попарное тестирование ). 

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

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

Попарное тестирование ручками

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

 Для начала выпишем наши параметры с их значениями:

Если использовать обычную комбинаторику, без оптимизации, мы получим 4*8*5*5*2*4*11*2 = 140800 кейсов, чтобы 100% покрыть весь функционал. Получил я эту цифру путем перемножения количества значений каждого параметра. Это я еще не посчитал цвета страниц при выборе чекбокса "Разноцветные страницы"...я если честно тут не уверен: по идее тут множественный выбор, а значит каждый цвет это не значение, а параметр, и правильнее сделать такую табличку:

С учетом корректировки, получается...эээм, 4*8*5*5*2*4*11*2*2^11 = 288 358 400 кейсов. Ожидаемо много, оптимизируем:

• Формат
  С точки зрения аналитики, А3 и А6 редко заказываемые форматы, давайте проверим самые ходовые: А4 и А5;

• Количество страниц
  Применяем наши любимые классы эквивалентности и граничные условия: 30, 50, 500, 1000;

• Плотность бумаги
  Да..тут тоже циферки, но на классы мы будем разбивать по технической информации: 40 г/м2 и 70 г/м2 входят в один класс, 80 г/м2 и 100 г/м2 в другой, а 120 г/м2 в третий. В результате: 40, 80, 120;

• Разметка и Обивка
  Значения уникальные, тут ничего не поделаешь..

• Цвет страницы
  А вот тут интересный момент. От цвета страниц ничего не зависит, они не уникальны. Конечно, объединив в один класс эквивалентности цветную бумагу мы возьмем, к примеру: "Черный", "Красный". А "Белый" выделим отдельно, так как это особое значение определяемое предметной областью;

• Разноцветные страницы
  Эх..вот тут чувствую, вы мне накидаете плюх в комментарии. Вообщем, моя логика такова:
  Так как мы определились, что цвет это нечто не уникальное, а в данном контексте, даже "Белый" не особое значение (мы проверили его ранее), то я просто буду оперировать значениями возможных выбранных цветов, засунув это в один класс эквивалентности. В результате получим: 1,2, 10, 11;

Вот как поменялась наша табличка:

Теперь, количество возможных комбинаций: 2*4*3*5*2*4*3*2*4 = 23040, что уже меньше чем 140800 кейсов. А теперь применим попарное тестирование ручками:

Шаг 1: Располагаем параметры от большего количества значений к меньшему и заполняем значениями, стараясь чтобы пары значений из разных параметров встречались хотя бы один раз:

Шаг 2: Ячейки помеченные желтым цветом, это любые значения параметров - можно вставить сюда любые значения:

У нас получилось 36 проверок. Не буду утверждать, что я сделал все без ошибок, но вроде как большинство пар всех значений нашел...

Шаг 3: Но согласитесь, в реальных кейсах не бывает такого, что бы не было бизнес логики.

1. Если количество страниц >= 200, то мы не можем использовать бумагу плотностью >= 70 г/м2

2. Если количество страниц >= 500, то мы не можем использовать бумагу плотностью >= 40 г/м2

3. Если количество страниц >= 500 и <= 50, то мы не можем использовать обивку "Дерево"

4. Если нумерация страниц включена, то мы не можем использовать цвет бумаги "Черный"

5. Если формат А4, то количество страниц не может быть >= 200

6. Если количество страниц <= 100 или формат >= A4, то мы не можем использовать опцию "Разноцветные страницы"

7. Если включена опция "Разноцветные страницы", то селект "Цвет страниц" не доступен.

8. Если выключена опция "Разноцветные страницы", то выбор цветов в "Разноцветность" не доступна.

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

Собственно, все =) На этом этапе, мы разобрались почему pairwise сложно применить ручками: это сложно, долго и безрезультатно в большинстве случаев.

Но, как я и говорил, забейте! Топаем сюда и скачиваем PICT (pict.exe) для Windows, а если у вас Unix, то почитайте тут .

Используем возможности PICT

Шаг 1: Откройте командную строку в директории, где находится pict.exe и запустите его:

Шаг 2: Создаем текстовый файл с содержимым:

# Параметры и их значения
#
Page format: A5, A4, A3, A6
Page count: 30, 50, 500, 1000
Paper density: 40, 80, 120
Page markup: without, incline, cell, line, music
Page numeric: yes, no
Page color: white, black|red|blue|green|yellow|salad|violet|pink|dark blue, NotUsed
Different color pages: yes, no
Different color pages combinations: 1, 2, 3|4|5|6|7|8|9, 10, 11 , NotUsed
Note cover: skin, wood, dermantin, textile 

# Условия
#
# Если включена опция "Разноцветные страницы", то селект "Цвет страниц" не доступен
# Если выключена опция "Разноцветные страницы", то выбор цветов в "Разноцветность" не доступна
if [Different color pages] = "yes" then [Page color] = "NotUsed";
if [Different color pages] = "no" then [Page color] <> "NotUsed";
if [Different color pages] = "no" then [Different color pages combinations] = "NotUsed";
if [Different color pages] = "yes" then [Different color pages combinations] <> "NotUsed";

# Если нумерация страниц включена, то мы не можем использовать цвет бумаги "Черный"
if [Page numeric] = "yes" then [Page color] <> "black";

# Если формат А4, то количество страниц не может быть >= 200
if [Page format] = "A4" then [Page count] <= 200;

# Если количество страниц >= 200, то мы не можем использовать бумагу плотностью >= 70 г/м2
if [Page count] >= 200 then [Paper density] >= 70;

# Если количество страниц >= 500, то мы не можем использовать бумагу плотностью >= 40 г/м2
if [Page count] >= 500 then [Paper density] >= 40;

# Если количество страниц >= 500 и <= 50, то мы не можем использовать обивку "Дерево"
if ( [Page count] >= 500 and [Page count] <= 50 ) then [Note cover] <> "wood";

# Если количество страниц <= 100 или формат >= A4, то мы не можем использовать опцию "Разноцветные страницы"
if ( [Page count] <= 100 or [Page format] in {"A4", "A3"} ) then [Different color pages] = "no";

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

1. Такая форма записи: black|red|blue|green|yellow|salad|violet|pink|dark blue обозначает, что это класс эквивалентности с перечисленными значениями. Вместо того что бы в каждом тесте использовать одно значение из класса эквивалентности, как мы это делали изначально, PICT будет рандомно проставлять в тестах разные значения из данного класса эквивалентности. Так мы сделаем наши тесты интереснее, разнообразнее и вдобавок покроем лишние значения..круто же)

2. Ключевое слово NotUsed необходимо для того, что бы реализовать в тестах противоположные условия. Нюанс состоит в том, что необходимо всегда явно прописывать условия когда параметр равен (=) и неравен (<>) значению NotUsed.

3. Также PICT поддерживает условие вхождения в диапазон значений: in {"A4", "A3"}

4. Другие возможности PICT неплохо описаны тут.

Шаг 3: Давайте скормим наш файл PICT и получим сгенерированный список тестов:

Для более удобной работы с получившимися кейсами, лучше направить вывод инструмента в .xls файл: pict note_tests.txt > note_tests.xls .

В результате получаем красивый список проверок:

PICT сгенерировал нам 43 проверки. А потратил я на составление текстового файлика буквально 30 минут, тогда как ручками таблицу я делал часа 2..если не дольше.

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

Пару слов о негативных сценариях

Да, PICT может вам помочь и в этом деле. Чтобы указать негативное значение у параметра используется префикс "~"

Шаг 1: В нашем файле с описанием параметров и условий добавим негативные значения в блок "Параметры и их значения" (Условия оставим без изменения):

# Параметры и их значения
#
Page format: A5, A4, A3, A6, ~NotSelected
Page count: 30, 50, 500, 1000, ~0
Paper density: 40, 80, 120, ~0
Page markup: without, incline, cell, line, music, ~NotSelected
Page numeric: yes, no
Page color: white, black|red|blue|green|yellow|salad|violet|pink|dark blue, NotUsed
Different color pages: yes, no
Different color pages combinations: 1, 2, 3|4|5|6|7|8|9, 10, 11 , NotUsed, ~0
Note cover: skin, wood, dermantin, textile, ~NotSelected

Там где строковые параметры, думаю, логично обозначить негативное значение как ~NotSelected, а там где числовые ~0

Шаг 2: Даем наш файл на обработку пикту: pict with_negative_note_tests.txt > with_negative_note_tests.xls и получаем результат:

Итого имеем 93 теста с позитивными и негативными сценариями! Да, все еще многовато, но тут уже вступает в игру приоритизация =)

Хочу еще указать на парочку интересных моментов при работе с PICT:

Регресс с PICT (Seeding)

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

Чтобы PICT понял нашу хотелку и работал со старым набором кейсов, необходимо указать ему на файл с ранее сгенерированными тестами, на базе которых будет сгенерирован новый набор:
pict with_negative_note_tests.txt > with_negative_note_tests.xls /e:with_negative_note_tests_seed.txt

, где /e:with_negative_note_tests_seed.txt - это указание на файл с базовыми сценариями, который можно сделать путем конвертации .xls файла с тестами в .txt формат.

PICT постарается максимально повторно использовать старые тестовые кейсы с учетом новых изменений!

Более подробно о seeding можно почитать тут.

Сокращаем количество тестов с PICT

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

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

Зная эту информацию мы можем воспользоваться опцией /r , которая позволит пикту минимизировать кол-во тестов, не теряя при этом в тестовом покрытии. Запустите инструмент с этим флагом несколько раз и выберите тот набор, где количество тестов минимальное.

Я запустил для тестового набора с негативными и позитивными тестами, где изначально было 93 теста:

pict with_negative_note_tests.txt > with_negative_note_tests.xls /r

Результат попыток такой: 93, 97, 99, 94, 98, 95... Получается, что в моем случае, самая первая попытка была оптимальной.

Зато когда я запустил seed для тестового набора с позитивными кейсами, где изначально было 43 теста:

pict note_tests.txt > note_tests.xls /r

То результат был следующий: 42 42 43 42. Таким образом мы сократили наш набор на 1 кейс =) Ну...тоже результат.

О других полезностях интсрумента PICT можно почитать в PICT User's Guide и microsoft/pict/doc .

И помните, PICT не боится большого количества параметров, он боится большого количества значений! Так что обязательно оптимизируйте данный момент перед тем как использовать попарное тестирование.

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

Данная статья для меня первая) Написана она в рамках моего личного блога о тестировании и QA : https://t.me/qanva_blog

Обсудить в форуме