Одним из самых популярных вопросов на собеседовании на позицию QA Engineer является следующий: «Что такое граничные значения? Что такое классы эквивалентности?». Чаще всего эти два вопроса задают вместе, как один.
Иногда, скажем, на позицию Senior QA Engineer этот вопрос может быть даже завуалирован. Например:
— Какие практики тест-дизайна вы знаете/применяете? — Как будете писать тест кейсы для каких-то определенных значений? — Какие значения будете проверять? — Как вы будете выделять граничные значения? — В чем разница граничных значений и классов эквивалентности? — И т.д.
Что ж, вопрос популярный, давайте разбираться.
Классы эквивалентности
Само собой, невозможно ввести все цифры, чтобы убедиться, что для каждой из них приложение будет работать правильно. Но давайте подумаем, а надо ли?
С точки зрения работы приложения между значением 500 и 600 разницы нет. Обе цифры будут умножены на соответствующий коэффициент. Следовательно, приложение будет работать одинаково в обоих случаях. Значит, эти проверки можно считать эквивалентными.
А вот еще пример. Для данного приложения целое число и дробное могут считаться эквивалентными значениями. Но только если дробное число имеет не более двух знаков после запятой: копейки и центы. Как будет обрабатываться дробное число с тремя знаками после запятой? Не важно, главное, что не так же, как целое число. И эта проверка уже эквивалентной не будет.
Суть разбиения проверок на классы эквивалентности в том, что в рамках одного класса достаточно совершить только одну проверку. Если все работает правильно, мы считаем, что для всех других эквивалентных значений все будет работать правильно.
Итак, какие проверки нам надо совершить для данного приложения?
— Проверить любое целое число или дробное с двумя знаками после запятой — Проверить любое дробное число более чем с двумя знаками после запятой — Проверить отрицательное число — Проверить не числовое значение (ввести любой символ)
Граничные значения
Техника граничных значений является идейным продолжением техники эквивалентных классов. Считается, что помимо проверки значений из середины класса (например, значения 500 в нашем случае) еще надо проверять значения на границах. В нашем случае это значение 0, потому что отрицательного значения валюты быть не может.
Какой профит от этих техник?
Я довольно часто провожу собеседования начинающих инженеров в тестировании. На просьбу протестировать какое-то выдуманное приложение многие начинают действовать хаотично: вводить какие-то данные, которые придут им в голову, совершать беспорядочные манипуляции. Их действия выглядят случайными и неорганизованными.
Когда такие ребята выдыхаются и фантазия их истекает, они еще долго смотрят на листочек и пытаются что-то додумать. Они никогда не уверены, что протестировали все разумные кейсы. Вдруг случайно “придумается” еще какая-нибудь проверка поинтереснее. Знакомо? 🙂
Вышеописанные техники позволяют систематизировать проверки. Когда есть четкий план действий, полагаться на случайность не надо. Ваши действия выглядят осознанными, а вы сами понимаете, закончили проверку или нет.
На практике классы эквивалентности практически обязательны при тестировании всевозможных форм и полей ввода. Но Если заглянуть немного в глубь реализации функционала то эта техника может стать полезной не только для тестирования форм и полей ввода. Приведем еще один пример (не такой классический как предыдущий, но не менее полезный): У нас есть система работы с файлами. В системе возможны четыре типа файлов А, В, С, D. Каждый файл может находиться в одном из пяти состояний: Created, Edited, Loaded, Saved, Deleted.
Файл типа А может быть удален только в состоянии Created; Файл типа В может быть удален только в состоянии Edited; Файл типа C может быть удален только в состоянии Loaded; Ну а файл типа D можно удалить только в состоянии Saved. Это громоздкое условие можно неплохо иллюстрирует следующая таблица:
В данном примере важно помнить что подобное применение классов эквивалентности возможно только в случае если есть полная уверенность в том что за обработку удалений отвечает один и тот же код. В любом случае возможность познать систему чуть глубже окажет позитивный эффект на тестирование.
Если же у вас достаточно времени на проведение 20ти тестов, то следует провести эти 20 тестов и спать спокойно. Жаль что времени почти всегда не хватает. Граничные значения В отличии от классов эквивалентности техника тест дизайна гордо именуемая Граничные значения произошла не из наблюдения за однотипным поведением тестируемых систем, а из часто наблюдаемых багов в определенных ситуациях. Довольно часто именно на границах диапазонов допустимых значений появляются довольно неприятные баги. Причин у этого может быть много но нас как тестировщиков не интересует что вызывает эти баги, нерадивость программиста или баг в фреймворке который он использует или возможно наш знак зодиака, нам важно знать в каких условиях возник баг.
Граничные значения являются идейным продолжением классов эквивалентности так как именно на границах этих классов проявляются, так интересующие нас, граничные значения.
Граничными значениями как видно являются 1 и 1000. Поскольку эта техника подразумевает проверку не только граничного значения но и двух соседних то к нашему набору тестов прибавятся еще 6 проверок (0, 1, 2, 999, 1000, 1001).
Сами диапазон допустимых значений и особенно их границы за частую не так тривиальны как в нашем примере, но если вы можете их выделить и скомбинировать с классами эквивалентности то вы получите хорошее (качественное) покрытие тестами вашей функциональности. Эпилог Классы эквивалентности и граничные значения одни из базовых техник тест дизайна, но несмотря на кажущуюся простоту и примитивность этих техник они очень полезны и могут в несколько раз сократить время необходимое на один тест раунд. А как показывает практика именно этот ресурс самый ценный в нашей жизни и работе и что особенно не честно невосполнимый.
Пусть %%R%% — отношение эквивалентности на множестве %%M%% и %%a%% — некоторый элемент из %%M%%. Рассмотрим множество всех элементов из %%M%%, находящихся в отношении %%R%% к элементу %%a%%.
Классом эквивалентности %%M_a%%
называется множество всех элементов %%M%%, находящихся в отношении %%R%% к элементу %%a%%, то есть множество
Пример
Пусть %%M%% — множество всех жителей России и %%R%% — отношение эквивалентности «проживать в одном городе». Найти классы эквивалентных элементов %%M_a%% для %%a \in M%%.
В зависимости от элемента %%a%% получаем несколько классов эквивалентности. Например, класс эквивалентности жителей Москвы или Санкт-Петербурга.
Свойства классов эквивалентности
Пусть %%R%% — отношение эквивалентности на множестве %%M%% и %%M_a, M_b, \dotsc, M_z, \dotsc%% — все классы эквивалентности для отношения %%R%%. Тогда эти классы имеют следующие свойства.
Свойство 1
Действительно, по определению, класс %%M_a = \
a\>%%. Тогда для элемента %%a%% должно выполняться условие %%a \in M_a \leftrightarrow a
a%%, которое выполняется в связи с тем, что отношение %%R%% рефлексивно по определению отношения эквивалентности. Следовательно, %%a \in M_a%%.
Как следствие этого свойства можно сказать, что всякий класс %%M_a%% является непустым множеством.
Свойство 2
Свойство 3
Свойство 4
Разбиение множества
Совокупностью подмножеств %%M_i%%, где %%i \in I%% (множеству индексов), множества %%M%% называется разбиением множества %%M%% если выполняются следующие условия:
Теорема. Пусть %%R%% — отношение эквивалентности на множестве %%M%%. Тогда совокупность классов эквивалентности множества %%M%% образует его разбиение.
Действительно, если в качестве подмножеств %%M_i%% взять классы эквивалентности %%M_a%%, то все три условия выполняются:
Все условия определения разбиения выполнены. Следовательно классы эквивалентности есть разбиение множества %%M%%.
Примеры
Пусть дано множество %%M = \<1, 2, 3, 4, 5, 6, 7, 8, 9, 0 \>%%, тогда разбиением этого множества могут быть следующие совокупности множеств:
Но следующие совокупности не являются разбиением:
Совокупность множеств %%C_i%% не является разбиением, т.к. оно не удовлетворяет условию 3 разбиения множеств: множества %%C_1%% и %%C_3%% имеют общий элемент %%3%%.
Совокупность множеств %%D_i%% не является разбиением, т.к. оно не удовлетворяет условию 1 разбиения множеств: множество %%D_4%% пусто.
Совокупность множеств %%E_i%% не является разбиением, т.к. оно не удовлетворяет условию 2 разбиения множеств: объединение множеств %%E_1, E_2%% и %%E_3%% не образует множество %%M%%.
Тест-дизайн. Классы эквивалентности и граничные значения
В этой статье мы разберем одну из самых известных и фундаментальных техник, технику выделения классов эквивалентности и граничных значений.
В чем суть техники?
Основная задача определения классов эквивалентности и граничных значений — «уйти» от дублирующих проверок. Таким образом, мы сократим количество однотипных тестов до необходимого минимума. Как это можно представить?
Предположим, у нас много-много разных булок, сделаны они по одному рецепту, а вот форма у них немного разная. А теперь представьте, что вам необходимо определить вкус каждой булки. Что вы будете делать? Попробуете все или возьмете только одну, потому что остальные сделаны аналогично? Я думаю второй вариант будет более оптимальным)
В тестировании ситуация аналогичная. Только вместо булок наши тесты. И все немного сложнее.
Классы эквивалентности
Сначала дадим определение классам эквивалентности.
Эквивалентная область (equivalence partition) —часть области входных или выходных данных, для которой поведение компонента или системы, основываясь на спецификации, считается одинаковым.
Скорей всего было не очень понятно…
Проще говоря, любой тест, выполненный из одного и того же класса эквивалентности, приведет к точно такому же результату, как и выполнение всех остальные тестов из этого же класса.
Например, у нас есть 10 тестов из одного класса. Если один из этих тестов проходит корректно, и то все остальные пройдут корректно. И наоборот, если один из тестов приведет к падению системы, то и все остальные тесты, также приведут к падению.
Пока все еще абстрактно, давайте конкретизируем. Предположим, у нас планируется акция «Скидка 10% на покупку от 5 товаров». Нам необходимо проверить функционал скидки в зависимости от количества товаров. Что будем делать? Есть два варианта проверки:
Тестов получается очень много.
2. Попробовать выделить классы эквивалентности и оптимизировать проверки.
Пойдем по второму варианту, он более эффективный. У нас всего два разных результата выполнения теста — со скидкой и без скидки. Логично предположить, что класса эквивалентности тоже будет два. В одном тесты будут проверять наличие скидки в 10%, в другом ее отсутствие.
Графически это можно представить следующим образом:
Т.е. какой бы мы тест не взяли из первого класса, мы получим скидку в 0%, аналогично для второго класса эквивалентности.
Теперь теория и здравый смысл подсказывают нам, что можно взять не все тесты, а только несколько из каждого класса эквивалентности. Этого должно быть достаточно, чтобы проверить оба случая со скидкой.
Но теперь вопрос, какие тесты брать? Есть ли разница между ними, может быть все-таки есть небольшие отличия?
Граничные значения
Путем долгого времени наблюдения за разработкой и анализа багов, специалисты пришли к выводу, что большинство ошибок возникает именно на границах между классами эквивалентности. Т.е. нам в первую очередь важно проверить переходы на стыке границ каждого класса, так как именно там велик риск возникновения ошибок.
Поэтому для эффективного тестирования нам необходимо выделить у каждого класса граничные значения. Давайте попробуем сделать на нашем примере:
Итого, 4 теста вместо 100 с учетом сохранения тестового покрытия.
Наша задача, как тестировщика, уметь правильно определить и работать с классами эквивалентности и граничными значениями. Выше мы рассмотрели пример с позиции черного ящика. У него есть существенные минус, мы не знаем как реализована работа функционала с точки зрения кода. Следовательно, не можем со 100% уверенностью правильно выделить классы эквивалентности.
Давайте рассмотрим пример посложней. Нам необходимо проверить корректность бокового меню на сайте из 10 страниц. Вот такое:
Страницы сами по себе одинаковые и отличаются только содержанием, боковое меню зрительно полностью идентично.
Только что пройденный материал подсказывает нам, что есть один класс эквивалентности и он включает в себя все 10 страниц. Но на практике есть как минимум два варианта: 1. Если сайт сделан на HTML, в том числе и боковое меню, то необходимо проверять КАЖДУЮ страницу, так как на каждой странице боковое меню работает отдельно от остальных. 2. Если сайт сделан с помощью, например, шаблонизаторов, то тогда выделить 10 страниц в класс эквивалентности можно, так как код меню хранится отдельно.
Т.е. в зависимости от реализации, классы будут разные. Как это определить? Если вы знаете языки программирования и у вас есть доступ в репозиторий, то посмотреть в код. Если вы не поняли, что я сейчас написал, то подойдет и второй вариант) Поговорите с программистом, который делал эту функциональность и уточните у него, правильно ли вы делаете.
Тестирование областей определения или нечто большее, чем анализ граничных значений
Все тестировщики как минимум наслышаны о таких техниках тест-дизайна, как классы эквивалентности и анализ граничных значений. Казалось бы, что может быть проще: выделить классы, взять по одному значению в каждом, проверить границы классов и значения слева и справа от границ. Но всегда ли дела обстоят настолько просто? Как быть, если после разбиения на классы оказывается, что с границами, в общем-то, проблема — их нельзя определить, поскольку данные невозможно упорядочить? Что если тестируемые параметры связаны между собой некоей логикой и зависят друг от друга? Сколько тестов достаточно? Ниже будут рассмотрены возможности двух основных техник тест-дизайна, превышающие те, что заложены в их непосредственном определении.
Область определения — математический термин — совокупность всех возможных значений переменной. Тестирование областей определения рассматривает программу как функцию многих переменных, каждая из которых принимает конечное множество значений. Каждое такое множество можно разбить как минимум на два класса эквивалентности — валидные и невалидные значения.
Классы эквивалентности
Типичные ошибки этого этапа тестирования областей определения: слишком много или слишком мало классов, классы выделены неправильно (по отношению к функциональности программы).
Выбор значений
Сочетания значений
Дефекты, зависящие от входных данных, можно поделить на те, которые возникают при конкретном значении одного параметра, и те, для возникновения которых нужно сочетание конкретных значений более чем одного параметра. Для обнаружения последних применяют комбинаторные техники тестирования, одной из которых является попарное тестирование (pairwise).
Очевидно, что при использовании сильного и/или надежного комбинирования количество тестов будет резко возрастать при увеличении количества значений какого-либо из параметров и, конечно, при увеличении количества самих параметров. Техника попарного перебора (pairwise) — один из способов уменьшить количество тестов, при этом попытавшись сохранить качество тестирования, т.е. свести к минимуму количество необнаруженных ошибок. Но применяя эту технику, важно понимать, что ошибки на стыке более чем двух значений параметров останутся ненайденными.
Другой способ уменьшить количество тестов — узнать, есть ли зависимости между входными параметрами, и учесть это в тестах. Это возможно далеко не всегда: часто тестирование черного ящика не позволяет «заглянуть внутрь». В этом случае можно попытаться выявить зависимости эмпирически и учесть их в комбинаторных тестах. Однако, есть риск ошибиться при выделении таких закономерностей.
Комбинаторные тесты можно и нужно составлять с помощью соответствующих инструментов, чтобы избежать человеческого фактора.
Искренне надеюсь, что вышеизложенное поможет вам проектировать эффективные тесты.
