Как составить класс эквивалентности

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

В чем суть техники?

Основная задача определения классов эквивалентности и граничных значений — «уйти» от дублирующих проверок. Таким образом, мы сократим количество однотипных тестов до необходимого минимума. Как это можно представить?

Предположим, у нас много-много разных булок, сделаны они по одному рецепту, а вот форма у них немного разная. А теперь представьте, что вам необходимо определить вкус каждой булки. Что вы будете делать? Попробуете все или возьмете только одну, потому что остальные сделаны аналогично? Я думаю второй вариант будет более оптимальным)

В тестировании ситуация аналогичная. Только вместо булок наши тесты. И все немного сложнее.

Классы эквивалентности

Сначала дадим определение классам эквивалентности.

Эквивалентная область (equivalence partition) —часть области входных или выходных данных, для которой поведение компонента или системы, основываясь на спецификации, считается одинаковым.

Скорей всего было не очень понятно…

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

Например, у нас есть 10 тестов из одного класса. Если один из этих тестов проходит корректно, и то все остальные пройдут корректно. И наоборот, если один из тестов приведет к падению системы, то и все остальные тесты, также приведут к падению.

Пока все еще абстрактно, давайте конкретизируем. Предположим, у нас планируется акция «Скидка 10% на покупку от 5 товаров». Нам необходимо проверить функционал скидки в зависимости от количества товаров. Что будем делать? Есть два варианта проверки:

1. Проверить, что скидки нет при покупке 1-го, 2-х, 3-х и 4-х товаров, начиная с 5 и так далее скидка в 10%. Т.е. на каждое число товаров проводить 1 тест.

Тестов получается очень много.

2. Попробовать выделить классы эквивалентности и оптимизировать проверки.

Пойдем по второму варианту, он более эффективный. У нас всего два разных результата выполнения теста — со скидкой и без скидки. Логично предположить, что класса эквивалентности тоже будет два. В одном тесты будут проверять наличие скидки в 10%, в другом ее отсутствие.

Графически это можно представить следующим образом:

Т.е. какой бы мы тест не взяли из первого класса, мы получим скидку в 0%, аналогично для второго класса эквивалентности.

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

Но теперь вопрос, какие тесты брать? Есть ли разница между ними, может быть все-таки есть небольшие отличия?

Граничные значения

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

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

1. Скидка 0% действует при покупке от 1 до 4 товаров, следовательно будут два граничных значения: 1 и 4.
2. Скидка 10 % действует при покупке от 5 товаров и выше, т.е. граничное значения для второго будет — 5. По поводу второй границы класса необходимо смотреть в реализацию, она должна быть равна максимальному числу товаров, которое можно положить в корзину. Чтобы не усложнять себе работу, возьмем максимальное число товаров — 100.
3. Таким образом, мы с вами определили верхнюю и нижнюю границу каждого класса. Эти значения мы и возьмем в тестирование. Получаем таблицу:

Итого, 4 теста вместо 100 с учетом сохранения тестового покрытия.

Наша задача, как тестировщика, уметь правильно определить и работать с классами эквивалентности и граничными значениями. Выше мы рассмотрели пример с позиции черного ящика. У него есть существенные минус, мы не знаем как реализована работа функционала с точки зрения кода. Следовательно, не можем со 100% уверенностью правильно выделить классы эквивалентности.

Давайте рассмотрим пример посложней. Нам необходимо проверить корректность бокового меню на сайте из 10 страниц. Вот такое:

Страницы сами по себе одинаковые и отличаются только содержанием, боковое меню зрительно полностью идентично.

Только что пройденный материал подсказывает нам, что есть один класс эквивалентности и он включает в себя все 10 страниц. Но на практике есть как минимум два варианта:
1. Если сайт сделан на HTML, в том числе и боковое меню, то необходимо проверять КАЖДУЮ страницу, так как на каждой странице боковое меню работает отдельно от остальных.
2. Если сайт сделан с помощью, например, шаблонизаторов, то тогда выделить 10 страниц в класс эквивалентности можно, так как код меню хранится отдельно.

Т.е. в зависимости от реализации, классы будут разные. Как это определить? Если вы знаете языки программирования и у вас есть доступ в репозиторий, то посмотреть в код. Если вы не поняли, что я сейчас написал, то подойдет и второй вариант) Поговорите с программистом, который делал эту функциональность и уточните у него, правильно ли вы делаете.

Время на прочтение
10 мин

Количество просмотров 249K

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

И да, сегодня мы поговорим именно об обычных ручных (функциональных) тестировщиках, без уклона в автоматизацию, нагрузку и другие технические виды тестирования!

Сейчас профессия ручного тестировщика – это одна из самых востребованных процессий ИТ и один из самых простых способов попасть в ИТ.

Почему?

Потому что тестировщики ничего не делают, им не нужны знания. Тестировать может каждый!

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

Hard skills всегда можно научить, а вот soft skills к сожалению научить очень сложно, потому что это характер человека, его отношение к чему-либо и т.д. Обычно я косо смотрю на руководителей, которые набирают себе специалистов по ручному тестирования по hard skills. Зачем Вы это делаете??? (ответы можете оставить в комментариях) Ну да ладно, продолжим:)

Если рассматривать технические особенности тестирования, которые должен знать ручной тестировщик, то их можно поделить на 2 основных части

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

– это подготовка к тестированию и выполнение тестирования.

Мы с вами рассмотрим самую интересную и увлекательную часть тестирования – подготовку к тестированию. Именно от этой части процесса тестирования зависит то, насколько качественно и правильно вы выполните само тестирования, найдете необходимые дефекты и обеспечите

довольное лицо Заказчика (ну или продукт овнера)

качество задачи после внедрения.

Многие из вас, кто занимался тестированием, так или иначе, занимался подготовкой к тестированию. Отличие обычно лишь в том, насколько вы этот этап процесса тестирования формализуете. Если вы занимаете исследовательским тестированием, не пишите тестовые сценарии,

вам дают систему и вы сразу кидаетесь в бой,

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

И в этом цикле статей поговорим об этом.

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

Выглядит это так:

• Зачем нам нужны техники тест-дизайна?
• Чтобы правильно определить проверки для тестирования.
• А используете ли Вы их в работе?
• В явном виде нет, мы сами определяем то, что нужно проверить.

Почему так происходит? Ведь техники тест-дизайна – это основа составления сценариев тестирования. Это тоже самое, что уметь водить машину, но при этом не знать ПДД. Почему же тестировщики не применяют их в работе?

Ответ прост.

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

Если говорить простыми словами, то техники тест-дизайна – это совокупность правил, позволяющих правильно определить список проверок для тестирования. И самое важное, это

использовать эти правила всегда и везде 🙂

уметь на интуитивном уровне применять данные правила. Именно умение «проводить аналитику в голове» отличает хорошего тестировщика!

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

• Анализ требований и рисков тестирования
• Определение проверок для тестирования
• Формализация проверок в виде тестовых сценариев
• Приоритезация проверок
• Определение подходов к тестированию

В этом цикле статей я постараюсь вам рассказать не только о техниках тест-дизайна, но и о том, как их ВСЕ (именно все вместе, а не конкретную одну или две) применять на практике, в том числе на примере функционала нашего банка. Как формировать проверки к тестированию с применением техник тест-дизайна для больших систем и процессов. И самое главное, вы получите ответ на то, в каких случаях и при каких проверках применять техники тест-дизайна.

Итак, начнем.

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

Что же такой классы эквивалентности?

Класс эквивалентности (Equivalence class) – это набор входных (или выходных) данных ПО, которые обрабатываются программой по одному алгоритму или приводят к одному результаты.

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

Они есть всегда. Каждый тестировщик делит проверки на эти классы, но не каждый тестировщик знает, почему он это делает. Ответ – классы эквивалентности.

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

Рассмотрим пример:

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

• От 18 до 25 лет – 18%
• От 25 до 45 лет – 16 %
• Свыше 45 лет – 20%

Мы определяем 2 основных класса – это позитивные и негативные сценарии.

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

Далее мы делим класс позитивных сценариев 3 класса вводимых значений 18-24, 25-44 и 45 +

В классе негативных сценариев мы формируем значения, исходя из необходимости проверки отказов программы, поэтому мы имеем 0, 1-17, отрицательные значения, ввод символов и т.д.

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

Итого мы имеем.

• Позитивные проверки: Ввод значений: 19, 30, 48 (значения могут быть любыми из данного диапазона класса)
• Негативные проверки: 0, 3, -1, А и т.д.

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

Еще одна особенность классов эквивалентности – это их применение. Я выделяю 3 уровня применения техник тест-дизайна для подготовки к тестированию.

• Первый уровень – проверка элементов системы (например, полей, чекбоксов, кнопок и т.д.)
• Второй уровень – проверка логики работы системы при комбинации данных в элементах системы
• Третий уровень – проверка бизнес- процесса системы и логики работы программы.

Визуально это выглядит так:

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

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

Граничные значения дополняют эквивалентные классы, тем самым полностью покрывая проверки элемента ПО.

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

Вроде все просто!

Вернемся к нашему примеру ранее.

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

• От 18 до 25 лет – 18%
• От 25 до 45 лет – 16 %
• Свыше 45 лет – 20%

Что же здесь будет границей?

Если вы подумали о длине поля на страничке Хабры, или об отпуске в теплых странах, хочу вас расстроить, это не так 🙂

Что определить граничные значения нужно нечто иное. А именно, определить, какие значения являются начальным и конечным для нашего класса. И самое важное!!! Годы исследований в области тестирования показали, что бОльшая часть дефектов находится тестировщиками именно на стыке значений, которые меняют условия работы программы.

Поэтому, помимо граничного значения мы используем для тестирования дополнительно 2 значения, значение перед границей и значение после границы.

В итоге мы имеем:

Границы наших классов: 17, 18, 19, 24, 25, 26, 44, 45, 46 и max.

Также, у нас есть негативный класс, это от 0 до 18. Поэтому тут мы тоже должны использовать для тестирования граничные значения: -1, 0, 1, 17,18

Далее исключаем повторяющиеся значения, и получаем значения для проверки элемента ввода данных.

-1, 0, 1, 17, 18, 19, 24, 25, 26, 44, 45, 46, max.

Значение max обычно уточняется у Заказчика или аналитика. Если не могут предоставить, то следует бросить его и не проверять необходимо подобрать значение, соответствующее здравому смыслу (вряд ли кто-то придет за кредитов в возрасте 100 лет).

Следующий шаг, это наложить граничные значения на значения классов эквивалентности, исключить лишние проверки, пользуясь правилом «достаточно одного значения для проверки одного класса» и финализировать список.

Если ранее у нас были 3 значения для 3-х классов, 19, 30 и 48, то после определения граничных значений, мы можем исключить из списка значения 30 и 48 и заменить их предграничными значениями, такими как 26 (вместо 30) и 46 (вместо 48).

Граничные значения определяются не только для числовых значений, но и для буквенных (например, границы алфавита и кодировки), даты и времени, смысловых значений. Граница числовых значений зависит от формата ввода, если у вас целые числа, например, 2, то граничные значения будут 1 и 3. Если дробные значения, то границы для числа 2 уже будут 1,9 (1,99) или 2,1 (2,01) и т.д.

Техники тест-дизайна 1-го уровня достаточно просты и понятны. Я думаю, вы скажете, да это легко, но зачем досконально проверять каждый элемент. И будете правы!..

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

Что ж, слишком легко??? Сейчас начнем разбирать более сложные техники, готовьтесь.

Техники тест-дизайна 2-го уровня отвечают за вариативность и комбинаторику данных при проверке ПО.

Основной техникой тест-дизайна parwise testing (попарное тестирование). Суть техники заключается в минимизации вариативности комбинаций проверок, достаточных для обеспечения высокого качества ПО.

Простыми словами, в данной технике применяется правило Парето, 80 % качества можно достичь всего 20% проверок комбинаций данных.

Данная техника была выведена путем более 15-тилетнего исследования IEEE в области анализа причин возникновения дефектов в системе. Результаты исследования показали, что 98% всех дефектов возникают при конфликте ПАР входных данных или ОДНОГО входного параметра.

Почему же была выбрана пара?

Погрузимся в дебри математической статистики и теории вероятности, чтобы найти ответ

.

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

Пусть выпадение значения 2 – это дефект, тогда вероятность появления дефекта при кидании кубика равна 1/6=0,167.

Если мы бросаем 2 кубика, то вероятность выпадения 2-х двоек (2 дефекта) становиться ниже и равна 0,167*0,167 = 0,028, для 3-х уже 0,005 и т.д.

Получается, что вероятность возникновения дефекта при комбинации 3-х и более параметров настолько мала, что ее можно отбросить.

Когда мы с вами тестируем программу, всегда есть n количество элементов, которые влияют на результат, например, форма заполнения данных по кредитной заявке. Там есть n количество полей, которые в совокупности дают результат. Именно комбинаторику данных при заполнении полей мы проверяем с помощью попарного тестирования.

Давайте рассмотрим на примере функциональности дистанционного оформления карты в банке.

Если мы внимательно посмотрим, то увидим с Вами пять полей заполнения данных:

• ФИО
• Дата рождения
• Мобильный телефон
• Серия номер паспорта
• Электронная почта,
• а также 2 чек-бокса.

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

Очень ВАЖНО, при использовании техники попарного тестирования, мы не говорим о результате тестирования. Нам важно проверить вариативность данных при заполнении заявки.

Итак,

Поле ФИО может принимать значения (классы):

• ФИО на русском
• Невалидное значение
• Пустое значение

Очень часто тестировщики не понимают, какие значения выбирать для данной техники, если они не ограничены возможностью ввода. Например, если у нас есть возможность выбора пола человека М или Ж, то тут все просто, есть 2 значения. Но когда у нас есть строка для ввода данных, то при попарном тестировании мы не проверяем корректность заполнения конкретного поля, т.к. эти проверки должны быть выполнены на первом уровне тест-дизайна (либо совместить их с попарным тестированием). Мы используем класс эквивалентности для данного поля, потому что нам не важно, какое именно это будет значение.

Идем дальше, дата рождения, также как и мобильный телефон, серия и номер паспорта можем иметь тоже 3 состояния:

• Валидное значение
• Невалидное значение
• Пустое значение

Т.к. электронная почта необязательно, то данное поле имеет 2 значения:

• Валидное значение
• Невалидное значение

Чек-боксы обычно имеют всего 2 состояния – Y или N.

Чтобы проверить все комбинации данной формы нам бы понадобилось сделать свыше 1000 тестов, но используя попарное тестирование нам достаточно всего 9 тестов!
Магия, не думаю:)

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

Мы берем ФИО и серия номер паспорта. Наша задача – перебрать все значения данной пары между собой:

После перебора одной пары, мы создаем другую пару и начинаем перебирать значения (например номер мобильного телефона)

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

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

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

Больше полезной информации о тестировании, а также практику можно получить на нашей платформе: TestGrow

Надеюсь было полезно!

В этом уроке мы рассмотрим следующие темы:

• Тест-дизайн
• Техники тест-дизайна
  • Классы эквивалентности
  • Граничные значения
  • Попарное тестирование
  • Таблица принятия решений
  • Диаграмма состояний и переходов
  • Тестирование вариантов использования
  • Доменное тестирование

Тест-дизайн

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

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

Разработка тестов начинается после проведения исследования ПО, когда цели определены, а критерии тестирования заданы и выполняются.

Техники тест-дизайна

Техники тест-дизайна помогают:

1. Исключить непродуктивные тест-кейсы и сократить общее количество кейсов
2. Покрыть тестами как можно больше функциональности
3. Провести все тесты и не пропустить ничего важного

Для работы с кодом (white-box) важны такие аспекты:

• Покрытие операторов
• Покрытие условий
• Покрытие путей
• Покрытие функций
• Покрытие вход/выход
• Покрытие значений параметров

В работе с требованиями (black-box) тестирование проходит иначе:

• Классы эквивалентности
• Граничные значения
• Попарное тестирование
• Таблица принятия решений
• Диаграмма состояний и переходов
• Тестирование вариантов использования
• Доменное тестирование.

Техники тест-дизайна на основании требований

Классы эквивалентности

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

Рассмотрим для примера перевод денег в банке. Размер комиссии зависит от суммы перевода:

• от 1 до 999 долларов включительно – 0%
• от 1000 до 4999 долларов включительно – 5%
• от 5000 долларов – 7%

Максимальная сумма перевода – 100000 долларов, при этом дробные числа не учитываются.

Попробуем выяснить, сколько требований будет в этом случае. В этом помогут классы эквивалентности:

• 1-999 => ожидаем комиссию 0%
• 1000-4999 => ожидаем комиссию 5%
• 5000-100000 => ожидаем комиссию 7%

Выбранные значения для проверки: 500, 2500, 7500.

• На значение 500 система отреагирует так же, как и на любое другое значение из первого диапазона
• На значение 2500 система отреагирует так же, как и на любое другое значение из второго диапазона
• На значение 7500 система отреагирует так же, как и на любое другое значение из третьего диапазона

Граничные значения

Граничные значения – это значения, в которых один класс эквивалентности переходит в другой. По своей сути это техника, которая дополняет технику классов эквивалентности.

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

Например, неопытный программист при постановке «не больше 1000» может поставить значение <1000.

Вернемся к примеру с комиссией:

• от 1 до 999 долларов включительно – 0%
• от 1000 до 4999 долларов включительно – 5%
• от 5000 долларов – 7%

Максимальная сумма перевода – 100000 долларов, при этом дробные числа не учитываются. Вспомним классы эквивалентности:

• 1-999 => ожидаем комиссию 0%
• 1000-4999 => ожидаем комиссию 5%
• 5000-100000 => ожидаем комиссию 7%

Граничные значения: 1, 999, 1000, 4999, 5000, 100000.

С учетом классов эквивалентности и граничных значений выбираем значения для проверки:
1, 500, 999, 1000, 2500, 4999, 5000, 7500, 100000.

Попарное тестирование (pairwise)

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

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

Рассмотрим пример. Возьмем наушники с такими характеристиками:

• Тип подключения (беспроводной или проводной)
• Микрофон (включен или выключен)
• Подсветка (включена или выключена)

Полный перебор даст нам восемь тест-кейсов. Это 2 в третьей степени, потому что у каждого из трех параметров может быть всего два значения:

#	Тип подключения	Микрофон	Подсветка
1	Проводной	Включен	Включена
2	Проводной	Включен	Выключена
3	Проводной	Выключен	Включена
4	Проводной	Выключен	Выключена
5	Беспроводной	Включен	Включена
6	Беспроводной	Включен	Выключена
7	Беспроводной	Выключен	Включена
8	Беспроводной	Выключен	Выключена

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

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

• 1 нет, нет, нет -> нет, нет, нет -> нет, нет, нет (00, 00, 00)
• 2 да, да, нет ->да, да, нет -> да, да, нет (11, 10, 10)
• 3 нет, да, да -> нет, да, да -> нет, да, да (01, 11, 01)
• 4 да, нет, да -> да, нет, да -> да, нет, да (10, 01, 11)

При трех параметрах, каждый из которых имеет 3 значения, количество вариантов полного перебора – 27 (три в третьей)
Применив pairwise, количество тест-кейсов сведётся к 9.

#	Тип подключения	Микрофон	Подсветка
1	Беспроводной	Выключен	Выключена
2	Проводной	Включен	Выключена
3	Беспроводной	Включен	Включена
4	Проводной	Выключен	Включена

Таблица принятия решений

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

Это взаимосвязь между множеством условий и действий.

Таблица принятия решений содержит следующие элементы:

• Условия — список возможных условий
• Варианты — комбинация из выполнения и/или невыполнения условий этого списка
• Действия — список возможных действий (вариантов исхода)

Например, кредит выдаётся людям, удовлетворяющим трём условиям:

• Возраст: 18-60 лет
• Гражданство: Россия
• Стаж работы: более 5 лет ИЛИ средняя месячная зарплата за год больше 100 тысяч рублей

Условие	Значение 1	Значение 2	Значение 3	Значение 4
Возраст 18-60	да	да	да	нет
Гражданство РФ	да	да	да	да
Стаж больше 5 лет	да	нет	да	да
ЗП выше 100 тысяч рублей	нет	да	да	да
Действие
Кредит одобрен	да	да	да	нет

Диаграмма состояний и переходов

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

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

Состояние А ——переход—–> Состояние Б

Тестирование вариантов использования

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

Вариант использования или юз-кейс – это описание конкретного использования системы субъектом или пользователем

Юз-кейсы содержат следующие сведения:

• Кто использует сайт или приложение
• Что пользователь хочет сделать
• Какие шаги делает пользователь, чтобы совершить определенное действие
• Как сайт или приложение реагируют на действия пользователя

Доменное тестирование

Доменное тестирование (domain analysis) — методика разработки тестов, использующаяся для определения действенных и эффективных тестовых сценариев в случаях, когда множественные параметры могут или должны быть протестированы одновременно.

Доменное тестирование применяется для сокращения количества проводимых тестов без потери качества тестирования.

Очень часто классы эквивалентности, относящиеся к позитивным проверкам, можно проверять совместно.

Возьмем для примера такие требования:

• Размер файла: до 200 МБ
• Имя файла: от 5 до 24 символов, только латиница
• Форматы файлов: только изображения

В этом случае нужны такие проверки:

1. Загрузить файл менее 200 МБ
2. Загрузить файл с именем hexlet
3. Загрузить файл с расширением .jpg

Можно заменить одной проверкой:

1. Загрузить файл менее 200 МБ, с именем hexlet.jpg

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

• Что это
• Особенности
• Стандартные действия
• Примеры
• Типы
• Советы
• Преимущества/недостатки
• Чем отличается от анализа граничных значений

Что такое классы эквивалентности

Коротко: выбранные тестировщиком наборы данных (диапазоны), которые подаются на ввод в модуль, и это должно приводить к одинаковым результатам.

Методика группировки и разделения тестовых входных данных на некие эквивалентные классы. Широко применяемая техника тестирования черного ящика; относится к базовым; всегда спрашивают на собеседованиях. Альтернативное название: эквивалентное разбиение.

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

Например, слушатель курсов программирования написал простейший калькулятор, и нужно протестировать в нем (хотя бы) все возможные операции сложения (а их 10 в 16 степени, то есть 10 квадриллионов), на это понадобятся миллиарды лет.

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

Особенности

• Это методика черного ящика (то есть тестировщик не видит код, является “внешним наблюдателем” по отношению к программе)
• Еще одна формулировка КЭ: формируются группы (классы) тестовых вводов с одинаковым поведением
• Суть в том, что если один член класса ведет себя каким-то образом, то и все остальные члены должны вести себя так же
• Применяется на любом этапе жизненного цикла тестирования
• В том числе в юнит-тестировании, интеграционном, системном и приемочном тестировании
• Тест-кейсы основаны на классах (а не на отдельных тестовых вводах, которых может быть огромное количество). Это экономит рабочее время, потому как не создается много избыточных тест-кейсов.
• Техника применяется, когда тестовые данные можно поделить на интервалы и наборы дискретных значений (то есть почти всегда)
• Как правило, в QA применяется сочетание классов эквивалентности и граничных значений — это дает более надежные результаты.

Стандартные действия по методике

1. Правильно определяются классы эквивалентности, это главное.
2. Выбирается один представитель (член) в каждом классе. Из каждого эквивалентного набора тестов выбирается один тест.
3. Выполнение тестов от каждого класса.
4. Если времени достаточно (или ситуация требует, см. далее о типах), берутся несколько членов из каждого класса. Но у опытного тестировщика классы определены правильно с начала, поэтому несколько членов будут не обязательны (избыточны = покажут те же результаты).

Пример

Есть приложение, принимающее на ввод число из 2 или 3 цифр. Из условия понятно, что диапазон возможных чисел — достаточно большой, и все варианты проверить получается неэкономно. 

• Теперь эти числа группируем, формируя из них классы эквивалентности. Вместо проверки сотен чисел сформируем из них 4 эквивалентных класса, и разделим вводы на категорию валидных и невалидных.
• Один элемент из класса как бы представляет весь класс. Например, число 122 представляет класс “трехзначные числа”. Поданное на ввод, число 122 не вызывает ошибку в приложении (тест пройден). Из этого делаем вывод, что все другие члены класса “Трехзначные” также будут нормально приняты приложением. А если тест не пройдет с числом 122, то предполагается, что все трехзначные числа будут вызывать ошибку.
• А теперь берем число 7 из класса “однозначные числа”, то есть невалидный ввод. Ожидается, что приложение выдаст ошибку в ответ на заведомо невалидный ввод, и это будет значить, что оно работает правильно, и предполагается, что остальные однозначные числа также будут вызывать ошибку.

Еще пример

Есть приложение, в которое подается число от 10 до 100, и затем вычисляется его корень. Эквивалентные классы будут такими:

Класс	Описание
Числа от 10 до 100	Дата-сет для позитивного сценария
Числа от 0 до 9	Дата-сет для негативного сценария
Числа больше 100	Тоже не примет приложение
Отрицательные числа	Усложняем задачу
Буквы	Еще усложняем
Специальные символы типа %^&#	И еще такой отдельный класс

Типы классов эквивалентности ( * )

• Weak Normal. Тестируется по одной переменной из каждого класса. Поэтому еще называется предположением об одной ошибке (single fault assumption)
• Strong Normal, или предположение о нескольких ошибках. Создаются тест-кейсы из каждого элемента в множестве прямого произведения эквивалентности. Это улучшает охват тестирования, поскольку покрывает все возможные классы, позволяя проверить все возможные комбинации вводов.
• Weak Robust, как и Weak Normal, тестирует одну переменную из каждого КЭ, но фокусируется на тест-кейсах с невалидными значениями.
• Strong Robust. Создаются тест-кейсы для всех валидных и невалидных элементов произведения эквивалентного класса. Это “неэкономный” тип КЭ, не уменьшающий избыточность тест-кейсов.

Советы 

• Robust-типы применяются, если условия ошибки являются высокоприоритетными для проверки, и в сложных функциях
• Robust применяется, если невалидные значения вызывают runtime-ошибки в системе (в языках со строгой типизацией)
• Берутся одно валидное и оно невалидное значение, если входные условия в приложении не очень ясны
• Установление правильной эквивалентности может требовать опыта, и усилий
• Чем больше создано классов, тем вероятнее, что много тестов окажутся избыточными
• И чем меньше классов, тем выше вероятность пропуска ошибок

Преимущества и недостатки

Плюсы

• Главное — уменьшает количество тест-кейсов, не уменьшая покрытие
• Уменьшает время тестирования и упрощает процесс, меньше данных обрабатывается
• Применяется на всех этапах и уровнях тестирования
• Позволяет сфокусироваться на небольших наборах данных, что улучшает вероятность найти больше багов
• Тесты получаются более структурированными
• Подходит для проектов с ограничением времени и ресурсов (то есть всегда)

Минусы

• Не учитывает условия по граничным значениям (поэтому надо сочетать с анализом граничных значений)
• Подбор эквивалентных классов — сложная вещь для новичков

Разница между классами эквивалентности и анализом граничных значений

Классы эквивалентности	Граничные значения
Стандартная техника «черного ящика», с которой начинают тестирование	Часто последующий этап «черного ящика», продолжение тестирования после эквивалентных классов
Применяется на любом этапе тестирования: юнит-, интеграционное, системное, и пр.	Как дополнение к КЭ и как часть негативного или стресс-тестирования
Техника: тестовые данные делятся на эквивалентные классы, которые “должны вести себя одинаково”	Техника: проверяются “значения на границах” классов
Экономит время на тестирование, меньше тест-кейсов и они более эффективные	Уменьшает общее время выполнения тестов, делая поиск багов быстрее и проще
Стандартно тестируется только по одному значению из каждого эквивалентного класса	Тест-кейсы создаются из граничных значений классов
Альтернативное название: эквивалентное разбиение	Альтернативное название: проверка границ диапазона

Техника эквивалентных классов так важна в тестировании, и настолько часто применяется, что в ISTQB есть отдельный тип тестового покрытия — покрытие эквивалентного разбиения, «процент эквивалентных областей, проверенных набором тестов».

Определим алгоритм использования техники классов эквивалентности:

1. Определить классы эквивалентности.

2. Выбрать по одному тесту для каждого класса, выписать все тесты для всех классов.

3. Выполнить тесты.

Пример использования классов эквивалентности по алгоритму

на примере формы обратной связи сайта radar4site.ru:

На странице “Обратная связь” есть всего два элемента: поле для ввода сообщения и кнопка «Отправить».

1. Определим классы эквивалентности для поля ввода сообщения:

Попробуем выделить классы эквивалентности по двум направлениям: 

• По количеству символов.
• По типу символов (буквы, цифры, специальные символы).

1.1. По количеству символов:

1.1.1. Начнём вводить текст в поле ввода до тех пор, пока не появится ограничение на длину. В нашем случае интерфейс подсказал нам, что больше 1000 символов ввести не сможем в это поле. На всякий случай определим количество символов при помощи инструмента Количество символов.

1.1.2. Таким образом, найдено ограничение для длину поля — 1000 символов, т.е. это верхняя граница.

1.1.3. Какой будет нижняя граница? Меньше нуля ввести не сможем. А можно ли ввести 0 символов? Можно оставить поле пустым и нажать «Отправить», в таком случае считаем, что 0 символов допустимы. Поэтому нижняя граница — 0 символов.

1.1.4. Таким образом, определен класс эквивалентности «по количеству символов» с допустимой нижней границей 0 символов и допустимой верхней границей 1000 символов.

1.2. По типу символов:

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

1.2.2. Таким образом, определен класс эквивалентности «по типу символов».

2. Выбираем по одному тесту в каждом классе эквивалентности:

2.1. По количеству символов: любой текст длиной в 101 символов, например «Здравствуйте. Ваш сайт помог мне чуть лучше понять, чем занимаются тестировщики. Спасибо Вам большое!».

2.2. По типу символов: текст, содержащий символы разного типа, например: «йцукенгшщзхъфывапролджэячсмитьбю.,1234567890-=ё!»№;%:?*()_+@#$^&|/}{[]><“.

3. Выполним тесты (введя наши значения в поле ввода и нажав на кнопку «Отправить»). В нашем случае уже проверил — значения обработались успешно, ошибок нет, сообщение отправилось.

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

Как ещё можно докрутить технику? Мы можем определить ещё несколько классов эквивалентности, например, проверить символы английского алфавита (других алфавитов), проверить другие специальные символы, проверить эмодзи, смайлики и т.д.

Похожие заметки:

Классы эквивалентности определение

Классы эквивалентности в тестировании