Техника тест-дизайна: Классы эквивалентности (equivalence partitioning)
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для Вас с целью персонализации сервисов и предложений. Вы можете прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом без изменения настроек, вы даёте согласие на использование ваших cookie-файлов.
speech bubble

Техника тест-дизайна: Классы эквивалентности (equivalence partitioning)

Техника тест-дизайна: Классы эквивалентности (equivalence partitioning)

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

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

Внимание! Мы приводим по большей части позитивные сценарии тестирования, так как негативные сценарии зависят от неких условий и требований в ТЗ. Все примеры являются произвольными и не являются примерам реальных проектов. Любые совпадения случайны.

 

 

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

В интернете полно примеров, подобных этому: «А давайте разобьём от 1 до 100 на классы эквивалентности!». А смысл, когда человек, читающий и ищущий ответ, в 100-й раз натыкается на один и тот же пример? Это знаете, как научить считать первоклассника  до десяти, а на контрольной дать вариант – «Вычислите интеграл».

Если не читали, то классы в данном случае будут:

  • от –бесконечности до 0;
  • от 1 до 100;
  • от 101 до плюс бесконечности;
  • проверки на буквы, символы.

Разобрались? А теперь задание «Найдите классы эквивалентности у поля логин и пароль и напишите тест-кейсы, чек-листы для проверки». Яркий пример, не так ли?

 

Техника анализа классов эквивалентности

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

Классы эквивалентности (equivalence partitioning) – это разбиение функционала(модуля) на наборы данных, которые ведут себя в пределах этих наборов одинаково.

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

Например, мы знаем, система должна вести себя на 1000-ти значениях одинаково. Зачем проверять всю 1000, если можно проверить самые необходимые места, сократив тестирование до 10 кейсов? В каждом из правил, есть исключения и не факт, что на 567 значении система или модуль не даст сбой. Мы можем только догадываться об этом. С обратной стороны, тестируя медицинское или сверхточное оборудование, необходимо проверить каждое из значений. Зависит от требований бизнеса.

Вы спросите: «Как возможно такое, когда мы проверили 500 значений из 1000, а ошибка будет на 501?»

Предположим, у нас интернет магазин, продающий кроссовки «Nike», «Adidas», «Puma» с разной ценой, имеющий в полном ассортименте 10000 наименований товара. 

Поступило требование, говорящее: «Кроссовки «Nike» с параметром в БД «Сезонный Nike» в ноябре 2021 года будут продаваться со скидкой в 15%».

Что делаем мы? Не проверяем все кроссовки фирмы «Nike», делаем выборочно по определенным параметрам, дабы несколько тысяч тестов превратить в 10. По итогу, так и получится, мы 10-ю кейсами проверим 99,99% требований, убедившись, что кроссовки фирмы «Nike» продаются с 15% скидкой. Молодцы? Но не учитываем человеческий фактор, где сотрудник в пятницу вечером, запаренный делами(да и домой хочется), один товар кроссовок «Nike» не обозначил как «Сезонный Nike». Получаем соответствующий результат, показывающий наглядно, что к данным кроссовкам не применится скидка в 15%. Чтобы это выявить, нам бы пришлось перебрать ассортимент в несколько тысяч товаров. Неуверен, что подобный расклад оценит руководство, когда вы положите на стол отчет о трудозатратах подобного исключения из правил.

Исходя из вышесказанного, можно выделить следующие тезисы признаков эквивалентности:

  • в случае выявления ошибки одним из тестов набора, то остальные, скорее всего, её тоже выявят;
  • в случае не выявления ошибки одним из тестов набора, то остальные, скорее всего, её тоже не выявят;
  • «разбивают» модуль на операции и соответствующее поведение при заданных параметрах;
  • использование схожих данных для получения одинакового результата из набора классов.

Для применения техники, достаточно следовать действиям: «Разбить» на классы эквивалентности по наборам -> Выбрать необходимые значения для проверок из каждого набора * -> При необходимости сочетать с другими техниками тестирования -> Провести тестирование

*Не стоит следовать правилу «Возьму, как в книге, по одному значению, так правильнее». Смотрите по обстоятельствам, порой бывает лучше потратить на 5 минут больше, взяв несколько значений, необходимых для лучшего покрытия возможных проблемных мест, нежели потерять ресурсы и времени в 10 раз больше.

Существует 2 типа класса эквивалентности:

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

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

 

Пример классов эквивалентности для времени (распорядка дня)

Весь день можно разбить на классы эквивалентности:

  1. Пробуждение 6:00-6:15;
  2. Зарядка 6:16-6:30;
  3. Завтрак 6:31-7:00;
  4. Умывание 7:01-7:20;
  5. Сбор на работу 7:21-7:40;
  6. Дорога на работу 7:41-9:00;
  7. Работа 9:01-18:00;
  8. Дорога домой 18:01-19:00
  9. Душ, отдых, ужин 19:01-20:00;
  10. Личные дела 20:01-22:00;
  11. Сон 22:01-5:59

Нет нужды проверять каждую минуту из каждого класса, достаточно выбрать значение из любого набора, например, 9:01-18:00, что в 9:02 мы на работе, что в 12:58, в 16:00, неважно. В данном наборе(диапазоне) мы на работе. И нет смысла проверять каждую минуту, ибо это не целесообразно, трудоемко и затратно. Нам достаточно взять пару значений, удостовериться в их одинаковом поведении, и вынести вердикт – да, протестировано и работает корректно «Passed».

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

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

 

Чек-лист для проверки распорядка дня, согласно классов эквивалентности

Tester Actions(Действие) Actual result(Результат) Comment(Комментарий)
Проверить статус «Пробуждение» Passed  
Проверить статус «Зарядка» Passed  
Проверить статус «Завтрак»  Passed  
Проверить статус «Умывание»  Failed В окне отображается «Сбор на работу»
Проверить статус «Сбор на работу»  Passed  
Проверить статус «Дорога на работу» Passed  
Проверить статус «Работа»  Passed  
Проверить статус «Дорога домой»  Passed  
Проверить статус «Душ, отдых, ужин» Passed  
Проверить статус «Личные дела» Passed  
Проверить статус «Сон» Passed  

*Добавлен провалившийся тест для примера.

 

Тест-кейс для проверки распорядка дня

IDEA(Идея): Реализация проверки распорядка дня сотрудником
Title(Наименование): Проверка статуса "Умывание" на странцие распорядка дня
Предусловие: Пользователь user_test 566passw0rd должен быть зарегистрирован в системе
DATA (Тестовые данные):
7:01, 7:15, 7:20
Steps(Шаги):
Tester Actions(Действие) Expected result(Ожидаемый результат) Actual result(Результат)
# Перейти на страницу распорядка дня /page/timeset Страница загружена. Блок распорядка присутствует Passed
# Раскрыть блок распорядка дня Блок раскрыт. В нем отображаются поля для ввода времени. Passed
# Ввести поочередно данные из Data Отображается статус «Умывание» Failed

Результат: Failed

Комментарий: При вводе в поле для времени значения 7:20, выдает сообщение "Сбор на работу" вместо "Умывание"

 

Пример классов эквивалентности для шумомера

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

Идея: При увеличении шума, индикатор cz-221(смотрите инструкцию) на приборе должен менять цвет.

Требования: П.1. Прибор измеряет в диапазоне от 0 до 130 ДБ. При низком уровне шума, индикатор горит зеленым, среднем желтым, высоком красным. Допускается погрешность в +-1 Дб.

 

Разбиваем на классы эквивалентности и составляем документацию для тестирования.

Выделенные классы(Уровень шума взят произвольно):

  1. 0-29 Дб – зеленый
  2. 30-31 – зеленый, либо желтый
  3. 32-59 Дб – желтый
  4. 60-61 – желтый, либо красный
  5. 62-130 Дб – красный
  6. Негативные классы, например, больше 130Дб или уменьшать и увеличивать уровень шума постепенно, резко. Зависит от потребностей бизнеса и условий ваших задач.

По требованиям допускается погрешность в +-1 Дб, логично выделить это в отдельный класс для проверки переходных состояний. Если мы выделим класс от 0-30 с цветом зеленый, а на 30 выдаст желтый, то не факт, что и на 29 не будет желтого. В принципе, можно и исходить из сложившихся обстоятельств, критичным ли является это для бизнеса.

Получив классы эквивалентности, пишем документацию.

 

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

Tester Actions(Действие) Expected result(Ожидаемый результат) Actual result(Результат) Comment(Комментарий)
Проверить индикатор на уровне шума 0-29 дБ Индикатор горит зеленым цветом Passed  
Проверить индикатор на уровне шума 30-31 дБ Индикатор горит либо зеленым, либо желтым цветом Passed  
Проверить индикатор на уровне шума 32-59 дБ Индикатор горит желтым цветом Passed  
Проверить индикатор на уровне шума 60-61 дБ Индикатор горит либо  желтым, либо красным цветом Passed  
Проверить индикатор на уровне шума 62-130 дБ Индикатор горит красным цветом Passed  
Проверить индикатор на уровне свыше 130 дБ Индикатор горит красным цветом Passed  

 

Пример тест-кейса для проверки индикатора cz-221, используя классы эквивалентности

IDEA(Идея): При увеличении шума, индикатор cz-221(смотрите инструкцию) на приборе должен менять цвет.
Title(Наименование): Проверка индикатора cz-221 на средний уровень шума
Предусловие: Получить шумоизолирующие наушники на складе. Получить разрешение на запуск генератора шума.
DATA (Тестовые данные):
Показатель уровня шума Expected result(Ожидаемый результат)
30 дБ Индикатор горит либо зеленым, либо желтым цветом
31 дБ Индикатор горит либо зеленым, либо желтым цветом
32 дБ Индикатор горит желтым цветом
45 дБ Индикатор горит желтым цветом
59 дБ Индикатор горит желтым цветом
60 дБ Индикатор горит либо желтым, либо красным цветом
61 дБ Индикатор горит красным цветом
Steps(Шаги):
Tester Actions(Действие) Expected result(Ожидаемый результат) Actual result(Результат)
# Надеть наушники Наушники плотно надеты, посторонних звуков не слышно Passed
# Включить шумомер cxRG-200 Прибор включен, индикатор cz-221  горит зеленым Passed
# Включить генератор шума Генератор включен, исправен Passed
# Настроить генератор на показатели с уровнем Data Генератор настроен Passed
# Запустить генератор Генератор запущен, на его панели отображается уровень шума согласно Data Passed
# Поднести шумомер cxRG-200 к генератору на расстоянии приблизительно 20 см Индикатор cz-221 шумомера cxRG-200 горит согласно ожидаемого результата Data Passed

 

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

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

Требования:

П.1. Поле "Имя пользователя" должно иметь возможность вводить от 1 до 50 символов. Пользователь может ввести кириллицу и латиницу, пробелы и дефис между именем. Спецсимволы, отличные от дефиса, запрещены. Имя не должно состоять только из пробелов, до и между словами не должно быть больше 1-ого пробела, все лишние пробелы должны удаляться после отправки. Если есть дефис, то имя должно состоять минимум из 3-х символов

П. 2. Поле находится на странице проверки имени

 

Требования для текстового поля получили и приступаем к разбиению на классы эквивалентности. Нам известно, что длина должна быть от 1 до 50 символов. Разбив на классы эквивалентности, подводим итоги: 0, 1-50, 51-+бесконечность. Составляем кейсы на длину поля 0, 1, 3, 25, 50, 51, 60. 3 выделили отдельно, исходя из полученных требований бизнеса, где указано минимальное количество символов с дефисом должно быть равным 3-м.

Следующим этапом будет проверка на спецсимволы, пробелы, кириллицу, латиницу, дефис. Здесь комбинирование будет зависеть от вашего опыта и требований. Главное, максимально эффективнее найти и покрыть модуль, при меньшем количестве тестов. Добавим от себя в тесты параметр «Метод ввода», включающий в себя «Ручной ввод», «Копипаст».

В итоге, получаем список выделенных классов эквивалентности:

Длина строки Язык/Кодировка/Ввод Метод ввода
0 Спецсимволы Ручной ввод
1 Пробелы Копипаст
2 Дефис  
3 Кириллица + Латиница + Дефис  
25 Кириллица + Латиница + Дефис + пробелы  
50 Индикатор cz-221 шумомера cxRG-200 горит согласно ожидаемого результата Data  
51 Пустое поле  
60 Кириллица + Латиница + спецсимволы  
  Кириллица + Латиница  

*Красным цветом помечены негативные сценарии

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

Длина строки Язык/Кодировка/Ввод Метод ввода
0 Пустое поле  
1 Спецсимволы Копипаст
1 Пробелы Ручной ввод
3 Кириллица + Латиница + Дефис Ручной ввод
25 Кириллица + Латиница + Дефис + пробелы Ручной ввод
50 Кириллица + Латиница + Дефис + пробелы Копипаст
50 Кириллица + Латиница + Дефис + пробелы Ручной ввод
25 Кириллица + Латиница + спецсимволы Копипаст
51 Кириллица + Латиница Копипаст
60 Кириллица + Латиница Ручной ввод
60 Кириллица + Латиница + пробелы Копипаст

И на основании данных проверок, вы можете составлять чек-листы и тест-кейсы. Помните, покрывайте и делайте свои тесты наиболее эффективными.

 

Чек-лист проверки модуля с использованием классов  эквивалентности

Tester Actions(Действие) Expected result(Ожидаемый результат) Actual result(Результат) Comment(Комментарий)
Оставить поле для имени пустым Появляется сообщение об ошибке «Введите имя» Passed  
Ввести в поле для имени «Кириллица + Латиница + Дефис + пробелы» В поле символы введены, на сервер отправляются Passed  
Ввести в поле для имени пробелы Появляется сообщение об ошибке «Введите имя» Passed  

 

Тест-кейс проверки модуля с использованием классов  эквивалентности

IDEA(Идея): Форма регистрации пользователя
Title(Наименование): Проверка ввода и отправки текстового поля "Имя пользователя" на странице для проверки имени
DATA (Тестовые данные):
Исходные данные Метод ввода Expected result(Ожидаемый результат)
Пустое поле Копипаст Ошибка «Введите имя пользователя»
- Ручной ввод Ошибка «Введите имя пользователя»
(Пробел) Ручной ввод Ошибка «Введите имя пользователя»
Я-v Ручной ввод Поле успешно отправлено на сервер
Кириллица-Латиница- Дефис Ручной ввод Поле успешно отправлено на сервер
Кириллица     Латиница     Defis     пробелы а дальшеNam Копипаст Поле успешно отправлено на сервер
Барняби Мармадюк Алоёзий Бенджи Kobveb Дартаньян Е Ручной ввод Поле успешно отправлено на сервер
#П)н,(ью*лл_а%;\СеXstтон/$ Копипаст Ошибка «Имя пользователя может содержать только кириллицу, латиницу и дефис»
Пабло Диего Hose Франциско де Паула Хуан Непомусено Копипаст Ошибка «Поле может содержать максимум 50 символов»
Axe Секстon Теddи Апвqд Виватма Уэйленд Ксилон ЯрдлиR Закари Ручной ввод Ошибка «Поле может содержать максимум 50 символов»
Axe Секстon Теddи           Апвуд Виватма Уэйленд Ксилон Fio Копипаст Поле успешно отправлено на сервер
Steps(Шаги):
Tester Actions(Действие) Expected result(Ожидаемый результат) Actual result(Результат)
# Зайти на страницу для проверки имени /name/proof Страница открыта, поле для имени присутствует, активно для ввода, фокус на нём Passed
#Ввести данные из таблицы Data Получить ожидаемый результат из таблицы Data Passed

 

Заключение

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

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

  • длина строки — например, валидный класс от 5 до 15 знаков, невалидный — всё остальное, то есть меньше 5 и больше 15;
  • спецсимволы — могут быть «Валидные», например в email символ @ и невалидными !»№\. Если вы тестируете поля на сайте. Обязательно проверяйте на следующие спецсимволы \ “ ‘ < > / ;
  • разрешение экрана — определяются согласно заявленным требованиям. Список тестируемых разрешений должен быть определен и упорядочен по приоритету;
  • версии браузеров — определяются согласно требованиям, чаще всего требуются последние и предпоследние версии.
  • метод ввода – ручной, копипаст. Немаловажно понимать, что пользователь может скопировать свой текст с дополнительными символами, не предусмотренными системой, например, расширенными символами ASCII
  • по объему используемой памяти, по объему передаваемых данных, по формату загружаемых данных и многое другое.

Применяйте технику грамотно. Например, сайт обрабатывает только файлы в форматах PNG, JPEG. Остальные форматы изображений загрузчиком не воспринимаются. Здесь бессмысленно говорить о диапазонах, границах и классах. Будет два класса «Валидный», включающий в себя PNG, JPEG и «Невалидный» - остальные форматы. Мы можем проверить все значения из валидного набора и парочку вариантов из невалидного, например svg, bmp, ico.

Для комментирования необходимо авторизоваться